Add support for Q-walk_by to Wireless-MBus

[zuckschwerdt]

As analyzed an protoyped by Detlef (Boing) Hassper

[merbanan]

LGTM

[zuckschwerdt]

TODO:

• [x] Binary int vs BCD for the values?
• [x] DATA_COND vs an new else if
• [x] CI == 0x78 in output vs a flag on block1
• [x] role of A_DevType for this mode?

[zuckschwerdt]

@merbanan checking the offsets in parsing block 2 I stumbled upon the CRC data, the application specific payload for QDS 0x78 seems to span 3 blocks. Is there a particular reason to feed link-layer data (data->in) to parse_block2() or should we maybe feed the application-layer data (payload, data->out)? I.e. perhaps make that parse_block2pp()? Or should parse_block2() employ it's own checks and "de-blocking" for needed further blocks? Although I'm not clear on wether all further blocks will actually be 16 bytes wide?

edit Or maybe we should not parse a payload in parse_block2() but rather branch parse_payload() for QDS… seems like that was the intended flow.

[merbanan]

@merbanan checking the offsets in parsing block 2 I stumbled upon the CRC data, the application specific payload for QDS 0x78 seems to span 3 blocks. Is there a particular reason to feed link-layer data (data->in) to parse_block2() or should we maybe feed the application-layer data (payload, data->out)? I.e. perhaps make that parse_block2pp()? Or should parse_block2() employ it's own checks and "de-blocking" for needed further blocks? Although I'm not clear on wether all further blocks will actually be 16 bytes wide?

It sounds like this is not really wmbus/OMS compliant data. In that case it can be whatever.

edit Or maybe we should not parse a payload in parse_block2() but rather branch parse_payload() for QDS… seems like that was the intended flow.

I dont really understand, can you post a few telegrams ?

[merbanan]

https://github.com/wmbusmeters/wmbusmeters/blob/master/src/driver_qwater.cc

wmbusmeters seem to have a driver

[zuckschwerdt]

Test data for -y is 55555555543d54cd49449344259764131806fa2f780dff5f3500828a0000110007c113ff5d24ff69540400ff2c452304001e36325104720200780000005d00140026005100000000aa8f0000005a0093002a002f046d02090f37537270 which is

in  : 494493442597641318 06 fa2f 780dff5f 3500828a0000110007c113ff 5d24 ff 69540400 ff2c 45230400 1e36 325104 7202 00 780000005d00140026005100000000 aa8f 0000005a0093002a00
out : 474493442597641318 06  CRC 780dff5f 3500828a0000110007c113ff  CRC ff 69540400 ff2c 45230400 1e36 325104  CRC 00 780000005d00140026005100000000  CRC 0000005a0093002a002f046d02090f37 5372
                                                                           ^^^^^^^^      ^^^^^^^^      ^^^^^^      ^^

the marked (8 char) BCDs are decoded by this PR.

[zuckschwerdt]

I guess I answered my own question, parse_block2() should just parse the block2 headers and full payload should be parsed in parse_payload(). There we can simply place a switch to not assume standard data when custom QDS is detected.

[merbanan]

If applicable send some telegrams to the wmbusmeeters projects @weetmuts.

But from your comments it sounds like the correct place to add handling of non standards compliant data data.

[weetmuts]

Does this make sense? https://wmbusmeters.org/analyze/49449344259764131806fa2f780dff5f3500828a0000110007c113ff5d24ff69540400ff2c452304001e36325104720200780000005d00140026005100000000aa8f0000005a0093002a002f046d02090f37537270

[merbanan]

https://wmbusmeters.org/analyze/47449344259764131806780dff5f3500828a0000110007c113ffff69540400ff2c452304001e3632510400780000005d001400260051000000000000005a0093002a002f046d02090f375372

This is what I think is one telegram.

[zuckschwerdt]

And this should be for HCA https://wmbusmeters.org/analyze/4944934490130127350837ab780dff5f3500820200007e0007b06effcd6cff09000000ff2c510000001e3608000096070009000c000c00000001000000cdff0027d20000000000030005002f046d0d090f37955754 Readings would be: total 9, lastyear 51, lastmonth 8 as raw values for v*K kWh.

[merbanan]

@weetmuts I guess the red part is think that is currently unknown in wmbusmeters. If you look at the patch you can see that some of the unknown things are at an offset of 10.

[weetmuts]

Yes manufacturer specific binary blobs inside a wmbus telegram are colored red. Any driver specific decoding that extracts from this blob are then printe below ***.

[weetmuts]

Wmbusmeters focuses on mbus compliant meter values. For all these it is now possible to write text drivers that can be loaded at runtime. https://github.com/wmbusmeters/wmbusmeters/blob/master/drivers/src/eltako.xmq

But if someone cares to decode mfct specific data this decoding will be in the processContent function in driver cc source file. https://github.com/wmbusmeters/wmbusmeters/blob/master/src/driver_qwater.cc

[weetmuts]

But the mftct specific blob will still be red even after some parts of it has been decoded. You see the *** as proof that something was extracted.

[merbanan]

So this is missing from the driver ?

di.addDetection(MANUFACTURER_QDS, 0x08, 0x35);

With regards to being able to parse the HCA telegram.

[merbanan]

Well I guess detect. Parsing might need more stuff.

[merbanan]

@weetmuts looks like that is the only part missing for HCA support.

[merbanan]

@weetmuts I have opened a ticket :).

[AkaBoing]

some more QDS hca CI fields 780dff5f3500823b0000ee0007b06effff10000000ff2c510000001e360800000009000c000c00000001000000cdff000000000000030005002f046d190812373588 780dff5f350082af0000800007b06effff35020000ff2c780500001e363502000003000300020017006400870047fe32002c000300000001002f046d23081237290b 780dff5f3500823c0000ef0007b06effff10000000ff2c510000001e360800000009000c000c00000001000000cdff000000000000030005002f046d21081237f1f9 780dff5f350082af00000e0007b06effff35020000ff2c780500001e363502000003000300020017006400870047fe32002c000300000001002f046d25081237b3ab 780dff5f350082b00000600107b06effff35020000ff2c780500001e363502000003000300020017006400870047fe32002c000300000001002f046d27081237c5cb 780dff5f3500823d00005f0107b06effff10000000ff2c510000001e360800000009000c000c00000001000000cdff000000000000030005002f046d260812375069 780dff5f350082b00000110007b06effff35020000ff2c780500001e363502000003000300020017006400870047fe32002c000300000001002f046d2c0812376c7e 780dff5f350082b100005e0107b06effff35020000ff2c780500001e363502000003000300020017006400870047fe32002c000300000001002f046d2e0812371a1e

[AkaBoing]

Good work. short way from draft to final i think

[AkaBoing]

2nd change with timestamps compiled and running thx

[AkaBoing]

changes from 21.7.2024 19:45 compiled and running. thx

[zuckschwerdt]

Reading some values for HCA I get the keys "inst_hca_0", "inst_date_1", "inst_hca_1", "inst_date_17", "inst_hca_17", "inst_timedate_0" pretty names are "HCA[0]", "Date[1]", "HCA[1]", "Date[17]", "HCA[17]", "TimeDate[0]" which looks useable.

But for reading values for Warm Water I get the keys "inst_volume_0", "inst_date_1", "inst_volume_1", "inst_date_17", "inst_volume_m10_9", "inst_timedate_0" pretty names are "Volume[0]", "Date[1]", "Volume[1]", "Date[17]", "Volume of month -10", "TimeDate[0]"

Note the key "inst_volume_m10_9" (pretty: "Volume of month -10"). (mapped by https://github.com/jedi7/rtl_433/blob/master/src/devices/m_bus.c#L198)

I guess this special decoding is some OMS extension? Is this even used with Wireless MBus? Shouldn't we simply output the "17" postfixed key?

This change was added with #1610 from @jedi7 -- was this a bulk change "by spec" or is this actually used?

Is it possible to limit the renaming to detected OMS messages?

At a minimum the _9 suffix is plain wrong. It should not be there as _m10 (month ten) is already added, and the real storage number is 17, not the adjusted value for the months table. (Bug is https://github.com/jedi7/rtl_433/blob/master/src/devices/m_bus.c#L537)

[AkaBoing]

The OMS specs (the findable) are from 2008, a few from 2014, all for wired "M-Bus" devices. "EN 1434" Wireless M-Bus started 2018 (Europe) now EN 1434-4 (costs 212 Euro+) in short: "inst_date_17", "inst_volume_17" is OK for me. just my 17cents

[AkaBoing]

QDS HCA: desciption

consumption current total : 235 Deadline : MD 31.12 consumption Deadline : 578 last month Date : MD 07.30 consumption last month : 190 check number : c 3360 P K-Level :060 Identifier Info : FC-2.2 S : Ident Q-walk_by & Q-AMR Mode C : algorithm 20x : 2-sensor measuring system

[AkaBoing]

QDS Warm Water Error Code if present : b43 Error Date : MDY 24.12.16 cum. volume : 1.823 m3 Deadline : MDY 31.12.23 consumption Deadline : : 1.567 m3 last month Date : MD 07.30 consumption last month : 0.302 m3 Identifier Info :FC C 7908 Mode C