• Categories
  • Recent
  • Tags
  • Popular
  • Register
  • Login
  • Categories
  • Recent
  • Tags
  • Popular
  • Register
  • Login

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

Scheduled Pinned Locked Moved General Discussion
2.0mycontrollernaming
9 Posts 4 Posters 669 Views 3 Watching
Loading More Posts
  • Oldest to Newest
  • Newest to Oldest
  • Most Votes
Reply
  • Reply as topic
Log in to reply
This topic has been deleted. Only users with topic management privileges can see it.
  • J Offline
    jkandasa
    last edited by jkandasa 3 Oct 2021, 09:01 7 Mar 2021, 04:57

    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)

    S 1 Reply Last reply 7 Mar 2021, 09:42 Reply Quote 1
    • S Offline
      skywatch @jkandasa
      last edited by 7 Mar 2021, 09:42

      @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 1 Reply Last reply 7 Mar 2021, 17:03 Reply Quote 2
      • D Offline
        Daniele @skywatch
        last edited by 7 Mar 2021, 17:03

        @skywatch source and value looks very good to me!

        1 Reply Last reply Reply Quote 1
        • J Offline
          jkandasa
          last edited by 7 Mar 2021, 17:17

          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

          S D 2 Replies Last reply 7 Mar 2021, 21:54 Reply Quote 0
          • S Offline
            skywatch @jkandasa
            last edited by 7 Mar 2021, 21:54

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

            1 Reply Last reply Reply Quote 1
            • D Offline
              Daniele @jkandasa
              last edited by 8 Mar 2021, 08:47

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

              S 1 Reply Last reply 8 Mar 2021, 18:53 Reply Quote 1
              • S Offline
                skywatch @Daniele
                last edited by skywatch 3 Sept 2021, 01:32 8 Mar 2021, 18:53

                @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?).

                1 Reply Last reply Reply Quote 1
                • A Offline
                  Avamander
                  last edited by 9 Mar 2021, 17:18

                  I too like source and data.

                  The demo is also looking rather nice.

                  S 1 Reply Last reply 10 Mar 2021, 18:04 Reply Quote 1
                  • S Offline
                    skywatch @Avamander
                    last edited by 10 Mar 2021, 18:04

                    @avamander Thanks my friend! 😉

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

                    1 Reply Last reply Reply Quote 1
                    8 out of 9
                    • First post
                      8/9
                      Last post

                    0

                    Online

                    589

                    Users

                    530

                    Topics

                    3.4k

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