Negative water flow direction is displayed incorrectly about wmbusmeters HOT 16 CLOSED

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!

from wmbusmeters.

from wmbusmeters.

Fix pushed! @a-wing66 please test.

Your flow is now negative:

https://wmbusmeters.org/analyze/4944C5144404752100047AC10000202F2F046D142D073404068847000001FD170004138E8A4000043BF7FFFFFF042B00000000025B3E00025F360002612F0303FD0C05010002FD0B2011

from wmbusmeters.

Great that wmbusmeters is now doing the right thing. Now you have to figure out why the water flows backwards. :-)

from wmbusmeters.

Could the unit be cum/h, perhaps? Huh, this number resembles 2^32 if not for the arbitrarily placed decimal point.

from wmbusmeters.

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. :-)

from wmbusmeters.

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.

from wmbusmeters.

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

from wmbusmeters.

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

from wmbusmeters.

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.

from wmbusmeters.

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

from wmbusmeters.

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:

https://wmbusmeters.org/analyze/3E44934486707945211A7801FD08F081027C034955230082026CFFFF81037C034C41230082036CFFFF03FD17000000326CFFFF046D0F0ABC2B02FDAC7E1100

You can see that the counter value 240 (an assumed unsigned single byte) is re-intepreted as a signed value -16.

from wmbusmeters.

@Zeppelin500 Do you have a link to the german forum where this was discussed?

from wmbusmeters.

@Zeppelin500 Do you have a link to the german forum where this was discussed?

https://www.photovoltaikforum.com/thread/195016-auslesen-von-w%C3%A4rmemengenz%C3%A4hlern-alles-%C3%BCber-m-bus-modbus-und-co/?postID=3694607#post3694916

...and 3 or 4 sites before.

PS: but for me, with my two screenshots is well referenced. Why do you think it's unclear?

from wmbusmeters.

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

from wmbusmeters.

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

from wmbusmeters.