Open wmmihaa opened 3 years ago
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
?
PS(2). http://www.rscada.se/ is not accessable....(internal server error)
any news ?
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:
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
PS. http://www.rscada.se/ is not accessable....(internal server error)