Open trsqr opened 2 years ago
@trsqr Thanks for your report. Is it okay for you to let us integrate the M-Bus telegram in libmbus test data?
Absolutely.
Today i had some time to look into this. At first the behavior of mbus-tcp-request-data is expected, because most of the examples uses the non-normalized output which is dedicated for humans (like M-Bus in general). Since this commit 2f9fa5ccc8aa032556ab77b7cafcb24670b6bf8d the libmbus is able to handle F as a negative value.
So your next question would be like: why doesn't mbus-tcp-request-data use this feature? Answer: it's not that simple. Unfortunately all the other hex values A-E are also valid values, so simply enabling this for every BCD value would break error values. So it's very hard for a machine to decided how to decode.
A possible hack could be to handle "Value during error state" as hex value and the other one as integer.
The hack is available as PR #197
I've got a Techem Ultra S3 (which is basically a rebranded Sharky 775) heat meter. For some reason the negative values show up prefixed with F. Is this expected?
Here for example we should have a negative power of 99 watts:
This didn't happen previously on my old system, but unfortunately that one crashed, so I can't really go back and see which version of libmbus I was running there.