• header.categories
    • header.recent
    • header.tags
    • header.popular
    • register
    • login

    Your suggestions to choose naming for "sensor" and "variable"

    scheduled pinned locked moved General Discussion
    2.0mycontrollernaming
    9 posts 4 posters 1.1k views 3 watching
    loading-more-posts
    • oldest-to-newest
    • newest-to-oldest
    • most-votes
    reply
    • reply-as-topic
    guest-login-reply
    deleted-message
    • jkandasaJ offline
      jkandasa
      global:last-edited-by, jkandasa

      Hello,
      MyController 2.0 is in the development stage. I hope we can do a pre-release soon.
      I do not want to limit MyController usage not only to the sensors world. can be used for another use case too.

      Example:

      • monitor stock market and act based on that
      • monitor GitHub issues, JIRA issues act based on that
      • Monitor an application on a computer
      • We have many use cases...

      The names should be generic and can be adaptable for all use cases.
      So we need a better common name for the sensor and variable.

      Current approach (In Version 1.x): Gateway >> Node >> Sensor >> Variable

      Sensor:

      • The sensor will be renamed as element
      • I need better naming here if this is not looking good

      Variable:

      • We cannot use the name variable, it is more confusing.
      • The Variable will be renamed as field (inputs are welcome)

      Please respond back with your suggestions

      between, Current work of MyController 2.0 deployed at https://demo-v2.mycontroller.org (Username:admin Password: admin)

      skywatchS one-reply-to-this-post last-reply-time reply quote 1
      • skywatchS offline
        skywatch @jkandasa
        global:last-edited-by,

        @jkandasa I think that instead of 'sensor' you could use 'source' as all data has to come from somewhere!

        Variable vould become 'value' or 'info' or 'data'.

        Just my thoughts on an early Sunday morning!

        D one-reply-to-this-post last-reply-time reply quote 2
        • D offline
          Daniele @skywatch
          global:last-edited-by,

          @skywatch source and value looks very good to me!

          one-reply-to-this-post last-reply-time reply quote 1
          • jkandasaJ offline
            jkandasa
            global:last-edited-by,

            Thanks, @skywatch, and @Daniele
            source looks ok.
            But we may not use value. It may lead to confusion.

            Here is the sensor and field (current names) for a better understanding

            Reference: sensor

            // Sensor model
            type Sensor struct {
            	ID             string               `json:"id"`
            	GatewayID      string               `json:"gatewayId"`
            	NodeID         string               `json:"nodeId"`
            	SensorID       string               `json:"sensorId"`
            	Name           string               `json:"name"`
            	Labels         cmap.CustomStringMap `json:"labels"`
            	Others         cmap.CustomMap       `json:"others"`
            	LastSeen       time.Time            `json:"lastSeen"`
            	LastModifiedOn time.Time            `json:"lastModifiedOn"`
            }
            

            Reference: field

            // Field model
            type Field struct {
            	ID               string               `json:"id"`
            	GatewayID        string               `json:"gatewayId"`
            	NodeID           string               `json:"nodeId"`
            	SensorID         string               `json:"sensorId"`
            	FieldID          string               `json:"fieldId"`
            	Name             string               `json:"name"`
            	MetricType       string               `json:"metricType"`
            	Payload          Payload              `json:"payload"`
            	PreviousPayload  Payload              `json:"previousPayload"`
            	Unit             string               `json:"unit"`
            	Labels           cmap.CustomStringMap `json:"labels"`
            	Others           cmap.CustomMap       `json:"others"`
            	NoChangeSince    time.Time            `json:"noChangeSince"`
            	PayloadFormatter PayloadFormatter     `json:"payloadFormatter"`
            	LastSeen         time.Time            `json:"lastSeen"`
            	LastModifiedOn   time.Time            `json:"lastModifiedOn"`
            }
            
            // Payload model
            type Payload struct {
            	Value      interface{} `json:"value"`
            	IsReceived bool        `json:"isReceived"`
            	Timestamp  time.Time   `json:"timestamp"`
            }
            
            // PayloadFormatter model
            type PayloadFormatter struct {
            	OnReceive string `json:"onReceive"`
            }
            

            in the field, we call field.payload.value and field.previousPayload.value.
            if we change it to value, it will be like value.payload.value and value.previousPayload.value.

            I feel field is ok, we need better naming for sensor

            skywatchS D topic:replies-to-this-post, 2 last-reply-time reply quote 0
            • skywatchS offline
              skywatch @jkandasa
              global:last-edited-by,

              @jkandasa How about 'content' or 'contents' for field?

              one-reply-to-this-post last-reply-time reply quote 1
              • D offline
                Daniele @jkandasa
                global:last-edited-by,

                @jkandasa Maybe I misunderstood the meaning of this class, but what about "message" instead of "field"?

                skywatchS one-reply-to-this-post last-reply-time reply quote 1
                • skywatchS offline
                  skywatch @Daniele
                  global:last-edited-by, skywatch

                  @daniele Yes, Message would be good!

                  The 'source' sends a 'message' to the controller, no problem there.... But then the controller sends a 'message' to the, er, 'destination'.....

                  But we can't have both can we?

                  Now I think about it the controller becomes the 'source' of the data in the same way as a node would be considered a 'source'. it's all about where we are looking at the data 'message' from (Einstein had something to say about relative points of viewing the same thing, didn't he?).

                  one-reply-to-this-post last-reply-time reply quote 1
                  • AvamanderA offline
                    Avamander
                    global:last-edited-by,

                    I too like source and data.

                    The demo is also looking rather nice.

                    skywatchS one-reply-to-this-post last-reply-time reply quote 1
                    • skywatchS offline
                      skywatch @Avamander
                      global:last-edited-by,

                      @avamander Thanks my friend! 😉

                      OK Mr. MyController prog, How about SOURCE and ATTRIBUTE ?

                      one-reply-to-this-post last-reply-time reply quote 1
                      • first-post
                        last-post

                      0

                      online

                      644

                      users

                      532

                      topics

                      3.4k

                      posts
                      Copyright © 2015-2025 MyController.org | Contributors | Localization