Configurable Measurement Definition

[jmoo900]

Is this feature or enhancement request related to a problem?

• Yes

Feature/Enhancement Description

Would be nice if there was some configurability in terms of how measurements are sent in. Cumulocity charges based on consumption metrics which include the number of Measurements, Alarms and Events are sent in from a device. For instance, lets say we configure 20 tags to be sent to the Cumulocity platform. The way that the agent currently runs, it would create 20 measurements each loop that would be sent in like:

{ "time": xxxxx, "type": "xxxxx", "Temperature": { "T": { "value": ##, "unit": "xxxx" } } }

This may be how we want to send them in especially if the values may be changing independently of other tags that we have configured to send. But what if all 20 measurements are sent in with the same timestamp and are all being sent at the same time.

Feature/Enhancement Alternatives

The option to send data as a single measurement could reduce consumption by 1/20th (as well as device class reduction leading to lower cost). I noticed you are currently using tag groups. Seems like an opportunity to use this grouping in order to format the measurements in this way:

{ "time": xxxxx, "type": "xxxxx", "Tag_Group": { "Temperature": { "value": ##, "unit": "xxxx" }, "Vibration": { "value": ##, "unit": "xxxx" }, "Humidity": { "value": ##, "unit": "xxxx" } } }

In addition to the reduction in the consumption, since the values are all part of the same measurement, the streaming analytics on the Cumulocity side will only trigger a single time instead of triggering 20 times for each measurement that is sent in with the current approach.

Additional Information

No response

Code of Conduct

• I agree to abide by the Code of Conduct.

[it-hms]

@jmoo900 this feature has been implemented. Please see the data aggregation feature of the connector.
Cumulocity Connector Data Aggregation

[jmoo900]

@it-hms thanks for the feedback. I did take a look at the feature you mentioned and did some testing with our customer. There are some subtle differences between my proposal and what was implemented with Data Aggregation, but those differences will have a potentially big difference on the Cumulocity side.

The implemented approach will minimize the amount of API calls that are made to the platform; however, the measurement count will remain the same. I recreated a simple example of what I was seeing during testing when using the data aggregation feature of the Ewon connector. This single API call will create 3 measurements (temp, vibration, humidity) each with a series of "0" and the associated values.

{
	"time": "xxxxx",
	"type": "xxxxx",
	"Temperature": {
		"0": {
			"value": 10,
			"unit": "xxxx"
		}
	},
	"Vibration": {
		"0": {
			"value": 10,
			"unit": "xxxx"
		}
	},
	"Humidity": {
		"0": {
			"value": 10,
			"unit": "xxxx"
		}
	}
}

Below you will see what I proposed in my request. Instead of having each tag represent a measurement, I proposed using the tag group as the measurement and then each tag would be represented as a series on that measurement. This format would result in a single measurement being sent in representing each of the tags as series of that measurement and would count as a single measurement against their consumption model.

{
	"time": "xxxxx",
	"type": "xxxxx",
	"Tag_Group": {
		"Temperature": {
			"value": 10,
			"unit": "xxxx"
		},
		"Vibration": {
			"value": 10,
			"unit": "xxxx"
		},
		"Humidity": {
			"value": 10,
			"unit": "xxxx"
		}
	}
}

In the case of our customer, they are sending in 26 tags which would result in a reduction of their measurement count by 1/26th.

[it-hms]

@jmoo900,
For the tag groups concept do you mean the Flexy Tag groups? There are only four Flexy tag groups: A,B,C,D.

[jmoo900]

Hey @it-hms ,

That was my thought. Use the tag groups defined on the Flexy as the measurement grouping.

Jake