Closed RalfJL closed 2 years ago
Hi RalfJL,
could you record some samples of your Q caloric 5.5 for a few minutes with following command
rtl_sdr -f 868.625M -s 1600000 - 2>/dev/null | tee qaloric_q55_f868.625M_s1.6M.bin | rtl_wmbus -s
and provide me with qaloric_q55_f868.625M_s1.6M.bin somehow? I will look into it. Hopefully I'll have more time on Christmas. ;)
Xael
Hi Xael, unfortunately you will not be happy with the output. The Q does send only every 7.5 Minutes but rtl_sdr produces more than 150MB per minute of output. Yes, it is very noisy here because there are a lot of weather stations around and my MySensors Arduino devices add even more noise.
Could you live with the rtl_433 data field? As you see, rtl_433 is interpreting the values quite strange. It can't even decode the Techem right. Interestingly a Qundis does send 2 different messages:
time : 2021-11-28 11:06:45 model : Wireless-MBus Mode : C Manufacturer: QDS ID : 96615935 Version : 53 Device Type: 0x08 Device Type String: Heat Cost Allocator Control : 0x44 Data Length: 50 Data : 2f4493443559619635087a1e0000200b6e0000004b6e000000426cffffcb086e000000c2086cffff326cffff046d0b0bbc2b488a Integrity : CRC Control Info: 0x7A Access number: 0x1E Device Type: 0x00 Configuration Word: 0x2000 HCA[0] : 0.000 HCA[1] : 0.000 Date[1] : invalid HCA[17] : 0.000 Date[17] : invalid Err Date[0]: invalid TimeDate[0]: 21-11-28T11:11:00
time : 2021-11-28 11:08:29 model : Wireless-MBus Mode : C Manufacturer: QDS ID : 96615935 Version : 53 Device Type: 0x08 Device Type String: Heat Cost Allocator Control : 0x44 Data Length: 74 Data : 47449344355961963508780dff5f3500821e0000610107b06effff00000000ffff00000000ffff000000000080008000800080008000800080008000800080008000802f046d0d0bbc2b2c65 Integrity : CRC Control Info: 0x78 Access number: 0x00 Device Type: 0x00 Configuration Word: 0x0000 Volume flow[1]: 0.093 m3/min Power[1] : 89904776.900 MJ/h
Sorry, clicked too much
Mabye it might help to see what rtl_433 thinks that rtl_wmbus should produce. But that output is not recognized by wmbusmeters. rtl_433 -f 868.95M -s 1600k -F json|./rtl_433_json_to_rtlwmbus.py C1;1;1;2021-11-28 11:24:31.000;54;46;26867779;0x47449344797786263508780dff5f350082370000ef0007b06effff03000000ffff00000000ffff000000000080008000800080008000800080008000800080008000802f046d190bbc2b340a C1;1;1;2021-11-28 11:25:38.000;54;46;96615935;0x47449344355961963508780dff5f350082200000ef0007b06effff00000000ffff00000000ffff000000000080008000800080008000800080008000800080008000802f046d1e0bbc2b959a T1;1;1;2021-11-28 11:25:45.000;54;46;72500832;0x30446850320850726980a0919f290000c0370a0079067f060a0000000000000000000000000000000000000000000000000000ffff C1;1;1;2021-11-28 11:26:24.000;54;46;26867779;0x47449344797786263508780dff5f3500823700007e0007b06effff03000000ffff00000000ffff000000000080008000800080008000800080008000800080008000802f046d1b0bbc2b426a C1;1;1;2021-11-28 11:27:28.000;54;46;96615935;0x47449344355961963508780dff5f350082200000810007b06effff00000000ffff00000000ffff000000000080008000800080008000800080008000800080008000802f046d200bbc2bcb4b C1;1;1;2021-11-28 11:28:15.000;54;46;26867779;0x47449344797786263508780dff5f350082370000100007b06effff03000000ffff00000000ffff000000000080008000800080008000800080008000800080008000802f046d1c0bbc2be3fa C1;1;1;2021-11-28 11:28:31.000;54;46;26867779;0x2f4493447977862635087a380000200b6e0300004b6e000000426cffffcb086e000000c2086cffff326cffff046d1d0bbc2b2685 C1;1;1;2021-11-28 11:29:21.000;54;46;96615935;0x47449344355961963508780dff5f3500822000000f0007b06effff00000000ffff00000000ffff000000000080008000800080008000800080008000800080008000802f046d220bbc2bbd2b
The json file: {"time" : "2021-11-28 11:24:31", "model" : "Wireless-MBus", "mode" : "C", "M" : "QDS", "id" : 26867779, "version" : 53, "type" : 8, "type_string" : "Heat Cost Allocator", "C" : 68, "data_length" : 74, "data" : "47449344797786263508780dff5f350082370000ef0007b06effff03000000ffff00000000ffff0 00000000080008000800080008000800080008000800080008000802f046d190bbc2b340a", "mic" : "CRC", "CI" : 120, "AC" : 0, "ST" : 0, "CW" : 0, "inst_volume _flow_min_1" : "0.093 m3/min"} {"time" : "2021-11-28 11:25:38", "model" : "Wireless-MBus", "mode" : "C", "M" : "QDS", "id" : 96615935, "version" : 53, "type" : 8, "type_string" : "Heat Cost Allocator", "C" : 68, "data_length" : 74, "data" : "47449344355961963508780dff5f350082200000ef0007b06effff00000000ffff00000000ffff0 00000000080008000800080008000800080008000800080008000802f046d1e0bbc2b959a", "mic" : "CRC", "CI" : 120, "AC" : 0, "ST" : 0, "CW" : 0, "inst_volume _flow_min_1" : "0.093 m3/min", "inst_power_jh_1" : "89904776.900 MJ/h"} {"time" : "2021-11-28 11:25:45", "model" : "Wireless-MBus", "mode" : "T", "M" : "TCH", "id" : 72500832, "version" : 105, "type" : 128, "type_stri ng" : "", "C" : 68, "data_length" : 51, "data" : "30446850320850726980a0919f290000c0370a0079067f060a000000000000000000000000000000000000000000000 0000000ffff", "mic" : "CRC", "CI" : 160, "AC" : 0, "ST" : 0, "CW" : 0, "err_volume_flow_min_0" : "20.584 m3/min", "err_energy_j_0" : "29264.000 J ", "min_energy_wh_1" : "0.000 Wh", "inst_volume_flow_min_0" : "0.000 um3/min", "inst_energy_wh_0" : "0.679 Wh", "err_energy_wh_1" : "0.000 kWh"} {"time" : "2021-11-28 11:26:24", "model" : "Wireless-MBus", "mode" : "C", "M" : "QDS", "id" : 26867779, "version" : 53, "type" : 8, "type_string" : "Heat Cost Allocator", "C" : 68, "data_length" : 74, "data" : "47449344797786263508780dff5f3500823700007e0007b06effff03000000ffff00000000ffff0 00000000080008000800080008000800080008000800080008000802f046d1b0bbc2b426a", "mic" : "CRC", "CI" : 120, "AC" : 0, "ST" : 0, "CW" : 0, "inst_volume _flow_min_1" : "0.093 m3/min"} {"time" : "2021-11-28 11:27:28", "model" : "Wireless-MBus", "mode" : "C", "M" : "QDS", "id" : 96615935, "version" : 53, "type" : 8, "type_string" : "Heat Cost Allocator", "C" : 68, "data_length" : 74, "data" : "47449344355961963508780dff5f350082200000810007b06effff00000000ffff00000000ffff0 00000000080008000800080008000800080008000800080008000802f046d200bbc2bcb4b", "mic" : "CRC", "CI" : 120, "AC" : 0, "ST" : 0, "CW" : 0, "inst_volume _flow_min_1" : "0.093 m3/min", "inst_power_jh_1" : "89904776.900 MJ/h"} {"time" : "2021-11-28 11:28:15", "model" : "Wireless-MBus", "mode" : "C", "M" : "QDS", "id" : 26867779, "version" : 53, "type" : 8, "type_string" : "Heat Cost Allocator", "C" : 68, "data_length" : 74, "data" : "47449344797786263508780dff5f350082370000100007b06effff03000000ffff00000000ffff0 00000000080008000800080008000800080008000800080008000802f046d1c0bbc2be3fa", "mic" : "CRC", "CI" : 120, "AC" : 0, "ST" : 0, "CW" : 0, "inst_volume _flow_min_1" : "0.093 m3/min"} {"time" : "2021-11-28 11:28:31", "model" : "Wireless-MBus", "mode" : "C", "M" : "QDS", "id" : 26867779, "version" : 53, "type" : 8, "type_string" : "Heat Cost Allocator", "C" : 68, "data_length" : 50, "data" : "2f4493447977862635087a380000200b6e0300004b6e000000426cffffcb086e000000c2086cfff f326cffff046d1d0bbc2b2685", "mic" : "CRC", "CI" : 122, "AC" : 56, "ST" : 0, "CW" : 8192, "inst_hca_0" : "3.000 ", "inst_hca1" : "0.000 ", "inst date_1" : "invalid", "inst_hca_17" : "0.000 ", "inst_date_17" : "invalid", "err_date_0" : "invalid", "inst_timedate_0" : "21-11-28T11:29:00"} {"time" : "2021-11-28 11:29:21", "model" : "Wireless-MBus", "mode" : "C", "M" : "QDS", "id" : 96615935, "version" : 53, "type" : 8, "type_string" : "Heat Cost Allocator", "C" : 68, "data_length" : 74, "data" : "47449344355961963508780dff5f3500822000000f0007b06effff00000000ffff00000000ffff0 00000000080008000800080008000800080008000800080008000802f046d220bbc2bbd2b", "mic" : "CRC", "CI" : 120, "AC" : 0, "ST" : 0, "CW" : 0, "inst_volume _flow_min_1" : "0.093 m3/min", "inst_power_jh_1" : "89904776.900 MJ/h"}
Well, I see that I have a lot of noise on the radio. Today I ordered a SDR with an aluminium case. See if this helps.
Hi Xael, unfortunately you will not be happy with the output. The Q does send only every 7.5 Minutes but rtl_sdr produces more than 150MB per minute of output. Yes, it is very noisy here because there are a lot of weather stations around and my MySensors Arduino devices add even more noise.
If I had the raw data I could debug rtl-wmbus searching for errors. It's possible that filter settings need some tuning for better processing of C1 datagrams. I could live with a 1 GB large file to download. ;)
Could you live with the rtl_433 data field?
Not really ;)
As you see, rtl_433 is interpreting the values quite strange. It can't even decode the Techem right.
I will look into it.
Interestingly a Qundis does send 2 different messages:
This stuff here is very interesting! The first datagram carries a consumption value with a timestamp only - nothing spectacular. The second datagram reveals something about a flow and even the power! I ask myself how it's possible?! As I know, there is no heat cost allocator on the maket that is capable of measuring the volume flow and temperatures of flow and return for calculating power. Heat cost allocating is more about consumption estimating rather than accurate measurement.
time : 2021-11-28 11:06:45 model : Wireless-MBus Mode : C Manufacturer: QDS ID : 96615935 Version : 53 Device Type: 0x08 Device Type String: Heat Cost Allocator Control : 0x44 Data Length: 50 Data : 2f4493443559619635087a1e0000200b6e0000004b6e000000426cffffcb086e000000c2086cffff326cffff046d0b0bbc2b488a Integrity : CRC Control Info: 0x7A Access number: 0x1E Device Type: 0x00 Configuration Word: 0x2000 HCA[0] : 0.000 HCA[1] : 0.000 Date[1] : invalid HCA[17] : 0.000 Date[17] : invalid Err Date[0]: invalid TimeDate[0]: 21-11-28T11:11:00
time : 2021-11-28 11:08:29 model : Wireless-MBus Mode : C Manufacturer: QDS ID : 96615935 Version : 53 Device Type: 0x08 Device Type String: Heat Cost Allocator Control : 0x44 Data Length: 74 Data : 47449344355961963508780dff5f3500821e0000610107b06effff00000000ffff00000000ffff000000000080008000800080008000800080008000800080008000802f046d0d0bbc2b2c65 Integrity : CRC Control Info: 0x78 Access number: 0x00 Device Type: 0x00 Configuration Word: 0x0000 Volume flow[1]: 0.093 m3/min Power[1] : 89904776.900 MJ/h
Mabye it might help to see what rtl_433 thinks that rtl_wmbus should produce. But that output is not recognized by wmbusmeters. rtl_433 -f 868.95M -s 1600k -F json|./rtl_433_json_to_rtlwmbus.py C1;1;1;2021-11-28 11:24:31.000;54;46;26867779;0x47449344797786263508780dff5f350082370000ef0007b06effff03000000ffff00000000ffff000000000080008000800080008000800080008000800080008000802f046d190bbc2b340a
The hex data after "0x" looks little strange to me:
I see in the line 46 of https://github.com/merbanan/rtl_433/blob/master/examples/rtl_433_json_to_rtlwmbus.py following: print("%s1;1;1;%s.000;54;46;%s;0x%s" % (event['mode'], event['time'], event['id'], event['data']) )
Th first "1" (just after "%s1;") stands in the rtl-wmbus output for a "good" CRC. No idea where in rtl433 the CRC check of received datagram takes place and if. But in rtl_433_json_to_rtlwmbus.py definitely not. ;)
I think I am collecting a lot of noise with my cheap USB stick. When I insert the stick into my PC and try to hear some radio with AirSpy I can hear almost nothing but noise. Today I ordered a stick with an aluminium housing in the hope that this will perform better. There are some Youtube videos adressing exactely this.
Let me come back to you, when the new stick arrived and I had the chance to do some more tests.
To me, it looks like the noise is too much and that will lead to misinterpretation. As you said, the CRC is wrong and the telegram should not be processed at all. By the way, changing antenna did not help with the reception
Thank you very much for the help. Ralf
Today the new USB stick with the aluminium case arrived and the reception is much better. I have to apologise, rtl-wmbus is now reliably detecting all HCA's, both Qundis and the Techem. Near or far, doesn't matter.
For others I want to clarify, what confused me and please correct me if I am wrong. Using wmbusmeters with the rtlwmbus driver correctly did not show values with the old stick. Checksums were simply most of the time not correct and telegrams are drop. Using wmbusmeters with the rtl433 driver did show values but they are wired. e.g. a HCA's does not have a inst_volume_flow_min_1 or a inst_power_jh_1 The same if you use rtl_433 in standalone mode. Even now with the better stick it delivers strange values. If you pipe the rtl_433 output through rtl_433_json_to_rtlwmbus.py it is not getting better. rtl_433_json_to_rtlwmbus.py does not calculate wmbus checksums and fools wmbusmeter into receiving a good telegram. But that is something for the rtl_433 maintainer.
I am still looking for a software way to reduce the noise delivered by the stick to make debugging easier.
So if you don't mind, I am closing the topic. If you like you could change the topic to something like "use a better stick" or "noisy stick" Thank you very much for your analysis and for the prompt help. Ralf
hi sorry for reopening this issue, yesterday they mount us on the heating block an Caloric 5.5. Im trying to decode the data with rtlsdr dongle and rtl_433, rtl_433 -f 868.625M -s 1024k but my output looks like this
time : 2021-12-15 22:29:04 model : Wireless-MBus Mode : C Manufacturer: QDS ID : 28786752 Version : 53 Device Type: 0x08 Device Type String: Heat Cost Allocator Control : 0x44 Data Length: 50 Data : 2f4493445267782835087ac10000200b6e0000004b6e000000426cffffcb086e000000c2086cbe2b326cffff046d1c16af2c0e00 Integrity : CRC Control Info: 0x7A Access number: 0xC1 Device Type: 0x00 Configuration Word: 0x2000
I have no info about Volume flow or Power , like you. Can you help me, please. What i do wrong. Also the output rtl_433 -f 868.625M -s 1600k -F json|./rtl_433_json_to_rtlwmbus.py end with error ^CTraceback (most recent call last):
File "/home/pi/Downloads/./rtl_433_json_to_rtlwmbus.py", line 61, in
and no file is created or i don´t see anything in folder from which i run the command. Any idea.? Thanks.
@kuno23 you are in the wrong forum. Rtl_wmbus is about low level radio decoding. To translate bytes into useful values you use https://github.com/weetmuts/wmbusmeters
Hi, my new Q caloric 5.5 meters are not seen by rtl_wmbus. They can be received by the SDR dongle with: rtl_433 -f 868.625M -s 1024k
time : 2021-11-27 08:53:22 model : Wireless-MBus Mode : C Manufacturer: QDS ID : 96615935 Version : 53 Device Type: 0x08 Device Type String: Heat Cost Allocator Control : 0x44 Data Length: 74 Data : 47449344355961963508780dff5f3500824b0000100007b06effff00000000ffff00000000ffff000000000080008000800080008000800080008000800080008000802f046d3a08bb2b0a38 Integrity : CRC Control Info: 0x78 Access number: 0x00 Device Type: 0x00 Configuration Word: 0x0000 Volume flow[1]: 0.093 m3/min Power[1] : 89904776.900 MJ/h
time : 2021-11-27 08:53:47 model : Wireless-MBus Mode : T Manufacturer: TCH ID : 72500832 Version : 105 Device Type: 0x80 Device Type String: Control : 0x44 Data Length: 51 Data : 30446850320850726980a0919f290000b03708006e067c06080000000000000000000000000000000000000000000000000000ffff Integrity : CRC Control Info: 0xA0 Access number: 0x00 Device Type: 0x00 Configuration Word: 0x0000 Err Volume flow[0]: 20.584 m3/min Err Energy[0]: 29264.000 J Min Energy[1]: 0.000 Wh Power[0] : 0.000 J/h Energy[0]: 0.000 Wh
time : 2021-11-27 08:54:11 model : Wireless-MBus Mode : C Manufacturer: QDS ID : 26867779 Version : 53 Device Type: 0x08 Device Type String: Heat Cost Allocator Control : 0x44 Data Length: 74 Data : 47449344797786263508780dff5f3500826300007f0007b06effff00000000ffff00000000ffff000000000080008000800080008000800080008000800080008000802f046d3608bb2b021d Integrity : CRC Control Info: 0x78 Access number: 0x00 Device Type: 0x00 Configuration Word: 0x0000 Volume flow[1]: 0.093 m3/min
The Techem with T1 Protocol shows up fine, but the 2 Caloric with C1 protocol are not reported by rtl_wmbus running rtl_sdr -f 868.625M -s 1600000 - 2>/dev/null | rtl_wmbus -s shows only the Techem
I use the latest release from github and I am using wmbusmeters for further processing.
Any help would be great Thanks Ralf