Conversion of Measurement Unit

Problem description

09

Sometimes your devices send a measurement in a unit that your user cannot interpret or understand. E.g. the device sends 5 unit a. By interpreting this, some people wants to see the values not as unit a they want to see them as unit b.

A different Scenario would be that your device sends for example 5 mV (milli Volt) and you need to convert this to meter or inches or kilogram.

There are some questions out of this which you need to answer yourself.

  • In which unit are you storing the measurement in the platform?
  • Which are the unit my users want to see?
  • Where do I manage and maintain the unit conversion from a UI perspective?
  • How often do I need one measurement in the platform?

Assumption

It is assumed that the device sends a unit which cannot be changed on the device.

How to convert

Several options are available to solve this.

Option 1

This option uses a self-developed microservice that receives the measurement from the device and uses one or multiple managed objects to convert the unit.

Option 2

This option uses a self-developed microservice which polls for a new measurement from the device and uses one or multiple managed objects to convert the unit to create a second measurement.

Option 3

This option uses a self developed Apama code to poll for a new measurement from the device and uses Apama Memory to convert the unit to create a second measurement.

Option 4

This option uses a self developed Apama code to receive a new measurement from the device directly to CEP Engine and uses Apama Memory to convert the unit to create a the measurement.

Option 5

This Option uses a self developed UI Application which will do the unit conversion every time the user access the measurement.

Conclusion

Out there are different kinds of devices with a Hugh variety of measurement type’s. I would differentiate them into categories.

  • Devices that can send a measurement in cumulocity style like where the unit and value already made cumulocity ready on the Agent side
"c8y_SpeedMeasurement": {
      "Speed": { "value": 1234, "unit": "km/h" }
}
  • Devices which can send a measurement in cumulocity style like where the unit and value already made cumulocity ready on the Agent side but the unit need to be convert to the users extend
"c8y_BatteryLevel": {
      "level": { "value": 1234, "unit": "mV" }
}
  • Devices which can send only values to the platform and based on some additional information (stored in a managed object) the value needs to converted into a measurement with a converted value and an unit. e.g a sensor sends the value of 12 and the system needs to convert this 12 mV into a distance of 10 cm.
"c8y_Compression": {
      "comp": { "value": 12}
}

Try to find the best solution for your use case. My Intention was to give you something on the hand to solve this problem.

Hi Kai,

there is another option.

Do the conversion only in the frontend on the fly. This is what i would prefer. You will store a lot of redundant data if you store the other units as measurement as well. I mean value conversion is something which can be done really fast. I see this a little bit like translations, which is also done by frontend.

Best regards,
Alex

2 Likes

Hi Alex

sure this can be an option but how would you to this from UI-only if you have to deal with a thousands of measurements in a datapoint graph?
I believe you run in UI-Performance issues!
and if you you have much lesser amount of measurements you still have the graph problem… I believe.

regards
Kai

Hi Kai,

that shouldn’t be a problem as the operation itself is trivial. Think about the fact that you can select the unit of measure in the UI and it will change on the fly without querying all data again (that would be really expensive in my view).

I don’t think that you run in Performance issues in the UI by selecting the unit of measure. The only thing that will have an impact of performance are the number of measurements you have to visualize at the same time not the unit conversation.

I’m on Alex side and would also prefer the UI Unit conversation.

Regards
Stefan

Hi Stefan
maybe I was not clear at my problem description.
Let me rephrase it and than it make more sense to NOT use the UI variant.

Regards Kai

I don’t see a big performance issue. The UI is already fetching the complete data and keeping that in memory. UI code is already iterating and rendering this, adding an additional step to conversion will not add much more effort for the browser. Yes, sure it will add a small percentage more time, but really a small fraction.

Stefan pointed to another positive impact that you don’t need to get the data again. So, if you switch between different units it will be much faster than getting other measurement.

However, there is one big problem. The standard widgets do not support that. This is actually a good aha idea, i will create one, if not yet exist. Of course, if you write additional measurements, all existing widgets will allow you to show other unit. My proposal is not working out of the box. Again, writing additional measurements has a lot of disadvantages regarding memory and performance, be careful.

There is already an idea:

https://trendminer.aha.io/ideas/ideas/C8YCPT-I-30

2 Likes

https://trendminer.aha.io/ideas/ideas/C8YCPT-I-43

1 Like

I created that idea a while ago, there was already some discussions in aha!. Looking forward to a more detailed specification discussion and a planning @Nikolaus_Neuerburg.

2 Likes