I couldn’t really believe this, but checking it out, this really is the case. Units are such a fundamental part of Cumulocity that I didn’t even think of this as a possibility. We even ran into bugs in Cumulocity because we currently don’t send units with our measurements (using Thin Edge). And the response in that ticket included the statement:
Note there is a value, but no unit - what use is a value without a unit?
The only way I currently found to include units that are delivered to Cumulocity is to use the static SmartRest templates 200/201.
As far as I can tell, using data types and adding units to those data types using the “telemetry type metadata” doesn’t lead to units being included in Cumulocity.
So two questions:
Is using the SmartREST template the only way to include units when using Cumulocity (and when will that change)?
Is there a big performance difference between using the SmartREST templates and using the thin-edge json? Are there other follow-on effects of using SmartREST instead of thin-edge json?
The measurement you are sending to the thin-edge MQTT topics is meant to be cloud-agnostic and is not the format that is submitted 1:1 towards Cumulocity. Thin-Edge’s mapper component is taking care of converting from this cloud-agnostic format towards cloud-specific messages. For Cumulocity this mapper is using the JSON-via-MQTT API - which does support units.
Your alternative could be to use the very same API. On a thin-edge device you would send your Cumulocity-compliant JSON (including units) to the c8y/measurement/measurements/create and c8y/measurement/measurements/createBulk topics of your local MQTT Broker. Here is an example payload.
Note that this is just an additional option which might be handy as it’s pretty close to the “standard” thin-edge JSON format. But there is nothing coming to my mind that would speak against using the 200 or 201 templates for SmartREST 2.0 either. If minimizing network/mobile traffic is a topic for you…SmartREST 2.0 consumes less due to its CSV nature.
I couldn’t really believe this, but checking it out, this really is the case. Units are such a fundamental part of Cumulocity that I didn’t even think of this as a possibility.
Yeah, this is has been deferred for a long time. One reason is that sending the units along each and every measurements - as done with C8Y JSON API, is not network efficient.
Anyway, I propose to move forward with the implementation proposed here
which let thin-edge users describe the measurements sent by a device using metadata.
Right, of course we can bypass the thin edge topic and directly post on the c8y topics - which I did for the smartREST example. I just didn’t immediately think of doing the same for the JSON case. It does however kind of defeat the purpose of using the thin edge mqtt topic and data structures.
It might be interesting to be able to tell thin edge to use smartREST when communicating with c8y instead of JSON.
That implementation sounds reasonable, as Cumulocity really requires a unit to be included with every single measurement sent. Setting that unit only once and then letting thin edge handle the rest of the logistics sounds like a good solution.