Negative water flow direction is displayed incorrectly
a-wing66 opened this issue · comments
Type of request
Bug
HAOS version
Core 24.3.3 HA-OS 12.1
wmbusmeters version
1.16.1-19
Your message goes here
Hello, I use Google Translate. I have a negative water flow on the SensoStar-U in my heating system under unfavorable conditions (microcirculation). The sending telegram looks like this.
- telegram=|4944C5144404752100047AC1000020_2F2F046D142D073404068847000001FD170004138E8A4000043BF7FFFFFF042B00000000025B3E00025F360002612F0303FD0C05010002FD0B2011|+120242
- telegram=|4944C5144404752100047AC2000020_2F2F046D162D073404068847000001FD170004138E8A4000043BF6FFFFFF042B00000000025B3F00025F360002616C0303FD0C05010002FD0B2011|+120362
- telegram=|4944C5144404752100047AC3000020_2F2F046D182D073404068847000001FD170004138E8A4000043BF5FFFFFF042B00000000025B3F00025F36000261810303FD0C05010002FD0B2011|+120483
Can WMBusmeters even handle negative values? The telegrams show me a current water flow of 4294967.29 sqm/h in HA. Can you understand this or do you need more information?
Greetings Andreas
Could the unit be cum/h, perhaps? Huh, this number resembles 2^32 if not for the arbitrarily placed decimal point.
There is (to me at least) an uncertainty in the specification for (w)mbus, when should binary values be interpreted as signed? For bcd values its easy, if the top nybble is F (which is an invalid bcd 0-9) then the remaining digits are negative.
But not so for binary values. Up til now, you have to specify in the driver if the VifScaling is Auto (never signed for binary, signeds handled for bcd), AutoSigned which assumes signed for binary.
We could implement all sorts of heuristics, but its all a bit shaky. Depending on VIF power/flow are always signed.
Total m3 is never signed, etc... We could also look at the top 4 bits, if they are all 1 and the data is stored in 4 or more bytes, then its perhaps a negative number.
The best would be if an expert on the OMS/wmbus standard could explain how this is done. :-)
Hello,
@weetmuts
I wrote the ESP M-Bus decoder library MBusinoLib.
https://github.com/Zeppelin500/MBusinoLib
As I understand the standard, all integers are signed.
My solution ist to copy first the value to the right sized Integer and than cast it to a Int64.
With this method, the negative values are remained.
But I'm only a hobbyist.
Thanks @Zeppelin500 ! If everything is signed then the fix is easy!
But where is this specified? I have been searching for signed and 2s complement in the specs but have not found it. Do you have a reference?
//Fredrik
Hi Fredrik,@weetmuts,
No, but I think, if the table mean unsigned int, then they would have written unsigned integer, not only Integer. An integer is signed.
Regards Matthias
I just received a hint about the reference in a german forum were the problem was first discussed.
The specification references to the IEC 870-5-4.
Below the table is the reference to type B for integers.
Thanks to everyone who helps me explain this and I hope it helps @weetmuts to work out a solution. Thank you weetmuts for the good support for your software.
Greetings Andreas
Thank you Matthias, yes I did see those mentions of Type B and C. I just find the text so indirect and off-beat, but perhaps this is the case because everyone assumed it should be signed so no-one ever needed to explain it more. :-)
I posted a question in the OMS linkedin group, maybe someone there will answer.
I tried to just force every binary to be signed and all tests pass, only this meter triggers different values:
You can see that the counter value 240 (an assumed unsigned single byte) is re-intepreted as a signed value -16.
@Zeppelin500 Do you have a link to the german forum where this was discussed?
@Zeppelin500 Do you have a link to the german forum where this was discussed?
...and 3 or 4 sites before.
PS: but for me, with my two screenshots is well referenced. Why do you think it's unclear?
I think that KaVauA gave a great explanation:
"Der Dreh- und Angelpunkt ist, dass der Datentyp "Binary Integer" in der M-Bus-Spec im Sinne der IEC 870-5-4 verwendet wird, die ihn als vorzeichenbehaftet definiert. Das ist auf den ersten Blick nicht unbedingt klar, vor allem weil in anderen Bereichen oft explizit "SINTxx" und "UINTxx" zur Unterscheidung verwendet wird, und deswegen es nicht abwegig ist, dass nur "INT" beides zulassen könnte. Der Hinweis auf die IEC 870-5-4 in der M-Bus-Spezifikation ist wohl das, was auch dem Kollegen weetmuts fehlt."
"The pivotal point is that the "Binary Integer" data type is used in the M-Bus spec in the sense of IEC 870-5-4, which defines it as signed. This is not necessarily clear at first glance, especially because in other areas "SINTxx" and "UINTxx" are often explicitly used to differentiate, and therefore it is not unreasonable that only "INT" could allow both. The reference to IEC 870-5-4 in the M-Bus specification is probably what my colleague weetmuts is also missing."
It makes sense that there is such a lack of explanation of signedness because this was already explained in IEC 870-5-4 ( IEC 60870-5-4 Telecontrol equipment and systems - Part 5: Transmission protocols - Section 4: Definition and coding of application information elements). But alas, I have not read this spec, nor do I have it.
So, yes, it seems like the integers should be signed by default. Yay!
Many many thanks Matthias for sorting this out!
Fix pushed! @a-wing66 please test.
Your flow is now negative:
Hello, as soon as the Updated to version 1.16.1-22 has been installed automatically on HA, I will give you feedback if the case of negative water flow occurs. First of all, thank you very much for the quick support.
Greetings Andreas
Thanks @weetmuts for the quick update. Yesterday it was that time again for the special constellation of a negative water flow and yes, your changes to the SW now cause negative values to be displayed correctly in Home Assistant (see picture). Thanks again.
Greetings Andreas
Great that wmbusmeters is now doing the right thing. Now you have to figure out why the water flows backwards. :-)