Cumulocity’s data model is build around the concept of “fragments”. Fragments are objects that you can compose to build devices, measurements, alarms and so forth. Cumulocity uses fragments to interpret the structure of the data that it receives without you having to configure this structure in advance.
For this, it assumes that the structure is not arbitrarily changing. For example, a geographic location should include latitude and longitude all the time. It can have additional properties, but a device cannot send a geographic location with entirely different properties not including latitude and longitude.
This applies similarly to measurements. It is not advisable for a device to, for example, send first a measurement fragment
“myMeasurement”: { “a”: { “value”: 10, “unit”: “C” }, “b”: { “value”: 20, “unit”: “kg” } }
and then
“myMeasurement”: { “c”: { “value”: 5, “unit”: “m” }, “d”: { “value”: -10, “unit”: “F” } }
This will not work in some user interface parts and may break some clients and applications. Instead, use a different fragment name for different structures. For example
“myOtherMeasurement”: { “c”: { “value”: 5, “unit”: “m” }, “d”: { “value”: -10, “unit”: “F” } }