You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
We're trying to make sense of the Unit field of the data record, which seem to lack consistency. For instance:
"Volume (m m^3)"
"Volume (my m^3)"
"Volume (1e-1 m^3)"
"External temperature (1e-2 deg C)"
"Energy (100 Wh)"
"C"
"Time Point (time & date)"
It seems to me that the Unit element is based on three parts:
Type - E.g "Volume"
Scale - E.g "1e-2" or "0.001" or "100"
Unit - E.g "m^3" or "deg C"
... but sometimes the scale comes as scientific number, sometimes as a decimal value and sometimes not at all
I understand that reverse-engineering the field might never get fully accurate, but if feels like it's just a free text field. Having a look at the mbus-protocol-aux.c, it looks like pretty structured, but perhaps the Unit value is derived from somewhere else?
In an effort to understand if we would be able to parse the Unit element, I created a function that tries reverse-engineer the text, and then wrote another program that went through all test files in the libmbus repo and extracted every Unit element. Lastly I ran my function on every one of those Units to create the table at the bottom of this issue.
The report shows three columns:
Unit field - The Unit value as part of the XML telegram Predicted Scale - The identified scale value in decimal Predicted Unit - The identified unit value
The reverse-engineering function works as follows
Ignore Unit fields with no parentheses
If the Unit field has parentheses…
a. …and the parentheses value can be split on double spaces, then assume the first value is the scale and the second is the unit
b. …or the parentheses value cannot be split on double spaces, then assume the value is the unit
After further investigation it seems I'm using the VIF output from mbus-protocol.c, rather than mbus-protocol-aux.c. Is there a setting or compile flag I can use?
In order to use mbus-protocol-aux decoding, you can use test/mbus_parse_hex which support the parameter -n. The default output of mbus-protocol is more intended for human. AFAIK the M-Bus protocol wasn't designed for machines.
We're just using the mbus_is_secondary_address method. Is there a compile flag or some other global options that I can set to force using mbus_vif_unit_normalize?
We're trying to make sense of the
Unit
field of the data record, which seem to lack consistency. For instance:It seems to me that the Unit element is based on three parts:
... but sometimes the scale comes as scientific number, sometimes as a decimal value and sometimes not at all
I understand that reverse-engineering the field might never get fully accurate, but if feels like it's just a free text field. Having a look at the mbus-protocol-aux.c, it looks like pretty structured, but perhaps the Unit value is derived from somewhere else?
In an effort to understand if we would be able to parse the Unit element, I created a function that tries reverse-engineer the text, and then wrote another program that went through all test files in the libmbus repo and extracted every Unit element. Lastly I ran my function on every one of those Units to create the table at the bottom of this issue.
The report shows three columns:
Unit field - The Unit value as part of the XML telegram
Predicted Scale - The identified scale value in decimal
Predicted Unit - The identified unit value
The reverse-engineering function works as follows
a. …and the parentheses value can be split on double spaces, then assume the first value is the scale and the second is the unit
b. …or the parentheses value cannot be split on double spaces, then assume the value is the unit
PS. http://www.rscada.se/ is not accessable....(internal server error)
The text was updated successfully, but these errors were encountered: