Add measurement type to thinedge JSON

[jvanderl]

Is your feature request related to a problem? Please describe. I am setting up a demo using a custom device that has an Accelerometer sensor, and I would like to use the standard rotation widget in Cumulocity. The message published on the thinEdge topic looks like: {"c8y_Acceleration":{"accelerationX":-0.957764,"accelerationY":0.046143,"accelerationZ":-0.004395}} The c8y mapper always inserts "type": "ThinEdgeMeasurement", while the rotation widget looks for "type": "c8y_Acceleration". The result is that the rotation widget has nothing to show.

Describe the solution you'd like I would like to be able to add a measurement type as part of the offered JSON as input to the mapper, much the same as it is already possible to offer a timestamp that doesn't get overwritten by the mapper. In my example that would look something like {"type":"c8y_Acceleration","c8y_Acceleration":{"accelerationX":-0.957764,"accelerationY":0.046143,"accelerationZ":-0.004395}}

Describe alternatives you've considered I have considered making a copy of the rotation widget in Cumulocity, but that would just be a workaround for one specific problem.

Additional context Next thing I'm thinking about is another part in Cumulocity where measurement type is specifically used: DataHub. Here we use the measurement type to determine subsets of data that get offloaded to a data lake at different intervals per type. If all measurements coming from all thin edge devices connected to a Cumulocity instances would keep using measurement type "ThinEdgeMeasurement" there would be a big limitation in effectively using DataHub. In addition, lot's of real-time analytics models would probably also want to use the measurement type.

[didier-wenzek]

This is indeed something that is missing with the current version of thin-edge JSON.

We have discarded that feature for the very first versions of thin-edge because we saw no use for such a type outside of the scope of Cumulocity. Today, we are working on how to improve thin-edge JSON, and I will add this request as a requirement.

However, I see another approach. Would you be happy with a solution where the mapping to a Cumulocity type would be done on the Cumulocity mapper using some configuration (still to be defined)?

[jvanderl]

Hi Didier,

Thanks for picking this up. I will follow the progress on the JSON improvement.

The mapper approach could be interesting, and makes sense if it's only Cumulocity making use of measurement types. I can see how that would work if just one measurement type would apply, but would like to understand how that would work when there are multiple measurement types offered to the mapper. Probably then still some part of the topic name would have to be used, or are there other ideas?

[didier-wenzek]

I have no definitive solution for now. I'm looking for a way to configure the Cumulocity mapper to associate a measurement type to some measurement names or group of measurement names.

For instance:

• location measurement group -> c8y_Location measurement type.
• c8y_Acceleration measurement group is also a Cumulocity measurement type.

In case an input thin-edge json message contains several types of measurement, this message might have to be broken in several output Cumulocity messages - one per measurement type. But this should be transparent.

[reubenmiller]

Closing I did not find any additional points which are not already covered by #770 (though please correct me if I am wrong)