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

[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)

[skywatch]

@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!

[Daniele]

@skywatch source and value looks very good to me!

[jkandasa]

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

[skywatch]

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

[Daniele]

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

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

[Avamander]

I too like source and data.

The demo is also looking rather nice.

[skywatch]

@avamander Thanks my friend!

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