Update parsing of plain text VIF - #229
Conversation
|
@johvik There is also no example in the test directory? Usually I prefer to have a test frame to "prove" features. |
296863a to
bc3fbdd
Compare
|
I've added a test, what do you think @lategoodbye? |
|
I had some time to look deeper in the code and it doesn't look like a clean solution to me. Interestingly the mbus-protocol-aux seems to be able to parse the frame before. But there is a mismatch between unit/quantity in the xml files? Just for understanding, this change is to handle M-Bus devices which doesn't follow the specification? |
It is actually the other way around, this is to handle M-Bus devices which follows the specification. The second pass is to try to remain compatible with e.g. some ELV CMa10 which does it wrong. To be more specific the problem arise when plain-text VIF with extensions is used (0xFC). Quoted from the specification:
So for 0xFC it should be For reference some ELV CMa10 devices seems to have this (wrong) order About the xml output I haven't look too much into that code but it seems to be how the xml currently outputs it ( I agree this is not ideal and isn't guaranteed to always work either. I guess its possible to introduce a new API but then it will become harder for the users to know how to do things correctly. |
The plain text VIF is specified to be "given in the first byte" so it should be read after VIF extension(s). The parsing is updated to be done in two passes to remain compatible with the old code (and devices using the wrong placement): 1. As per the specification, after VIF extension(s) 2. If variable length VIF with extension(s) is seen another attempt with the wrong placement is performed for compatibility I don't have a device using the specified way of doing it however I have an (older) ELV CMA10 which uses the immediate bytes (matches the way the code was written prior to this commit). A handcrafted hex for the expected placement of the plain text VIF is added. In addition to this mbus_vib_unit_lookup() is patched so it prints the custom_vif value when it has extensions instead of "Custom VIF". The proper fix would be to also add support for the orthogonal VIF extensions.
2 participants
The plain text VIF is specified to be "given in the first byte" so it should be read from the data part.
I don't have a device using the specified way of doing it however I have an older ELV CMA10 which uses the immediate bytes (matches the way the code was written prior to this commit) so the parsing is updated to be done in two passes to work with both interpretations: