Compile under MacOSX (and support for Qundis Q Caloric Heat Cost Allocator) #8
Comments
|
This looks fun! From what you write, it seems that it should be possible to receive the meter wmbus messages using a generic RTL-SDR usb dongle and the software rtl-wmbus. (wmbusmeters currently expects you to have either an im871A or an amber usb stick.) If you can send me some example output from running the "rtl_sdr | rtl-wmbus" software when it captures your meter using the RTL-SDR dongle, then I can add a generic way of piping the output from rtl-wmbus into wmbusmeters. Please also send the command line you use to capture the wmbus data. I will take a look at compiling for macosx as well. |
|
Wow, your are super quick! Thanks! I'm not sure if I understand the First, my exact HW is : My output (truncated and filtered only lines with |
|
Thanks, wmbusmeters seems to parse (at least part of) that output. I added a work-in-progress Take the bytes you posted: Now run: ./build/wmbusmeters --c1 --debug simulation_kidpixo.txt HeatMe qcaloric 94740459 "" |
|
Assuming that my mbus parser works correctly, it looks like the meter produces a large chunk If you have some known readings from the meter, that would help in decoding... |
|
Wow! I'm impressed! Thanks! You're right, it is indeed the Qcaloric5.5 Heat cost allocators – QUNDIS EN . As far I understood, the data could be send AES-128 encrypted, the binary blob could indicate that it is the case. I can try to get some reading from the cost allocator display directly, but I cannot sync it directly with a telegram. I must ask the producer for the AES key I guess... |
|
I found a reference to their wmbus protocol also in OpenHub (search THING_TYPE_NAME_QUNDIS_QCALORIC_5_5 ) > openhab-binding-wmbus/WMBusHKVDiscoveryService.java at 4cbc7257285e815bb4b837b9814e6f07603615f5 · pokerazor/openhab-binding-wmbus |
|
I do not think it is encrypted, as you can see the data here: Thanks for the link, I will take a look, and also take a look at the macosx build problem. |
That is ok, as long as it is relatively close, it would help a lot. I am also interested in which |
|
Sorry for the delay, here some data I got from the sensor and from the datasheet Data-sheet_Q-caloric-5.5_DST2-QCAL-GB0-P2P3_Qcal_55_070518_V260_FINAL.pdf EDIT : This should be the ID of the sensor : 94740407 Those the data I got from reading the display directly :
Variable display shows the actual sensor configuration:
Measuring system table from the datasheet:
Seems that we should find the One of the temperature should be around 20-ish degree C (room temp). Searching around seems that the values from the sensor should be adjusted with some "magic" factor from the producer (this take in account the temperature gradient between the sensor and the heater), that obviously behind a customer login for Qundis. How did you find out the Manufacturer ID ? I was searching for the data but I found nothing! I extracted only some the telegrams for the sensor ID I found above: |
|
Thanks Kidpixo! I got myself a rtl-sdr dongle and I can listen to FM radio using gqrx. But I have trouble receiving wmbus messages. Do I need to do something special or have a special antenna for it to work? |
The decode of the telegram reported the QDS as the triplet that identifies the manufacturer, this was not in my list, but simply googling for heat cost allocators and qds will give you Qundis, which clearly is the only manufacturer that would choose the abbreviation QDS. :-) |
Uhm I did nothing special: on a Mac, just plugged in and rtl_sdr or rtl_test could use it. The same cheap antenna I got with the stick is working fine, I receive also a loto of AMR readings via https://github.com/bemasher/rtlamr |
Clever :-D 👍 |
|
About my data, I do think they are encoded, and I have a crazy idea about the encryption. Above I posted the photo of one sensor and the ID printed on the cover is 94740407. Would make sense that each device use a different encryption key? I figure something like this : the technician install the device, scan the code and add is to the client pool with a dedicated encryption key unique to the device. Maybe I'm just in a scifi movie and the real key is |
|
It now compiles under MacOSX 10.14.3 with a recent XCode. (clang-1000.10.44.4) |
|
EDIT : the debug mode works, but the USB is not detected. |
|
Another thing I notice: That comes from this check Shouldn't it work anyway? |
|
A last question, do you think the messages are encrypted now? Or you think it is possible to decode them? |
|
Just committed a fix, so that the file simulation_yyy.txt can be located in some other directory than cwd. I have not yet had time to examine the messages. But I still do not believe that they are encrypted per se. But lets see! :-) |
|
Now there is support for receiving data from rtlwmbus. Try this command line, Please test! It should work for you on macosx. |
|
Thanks! You're surely really active! I think this latest push could be useful to a lot of users.
I have some problem with installing stuff system wide (laptop provided from my work, nice IT , the usual) and normally symlink the self-compiled stuff in ~/.local/bin/ or I just leave them where they are built. Would be a huge deal to :
|
|
Ok, I made the following changes and pushed the code to github. wmbusmeters rtlwmbus Heater qcaloric 12345678 "" You can also specify Or you can specify the entire command line: Add --verbose to see the command line it uses. |
|
Hi Fredrik Would wmbusmeters rtlwmbus work with Kampstup watermeter ? /Kenneth |
|
Yes, I am assuming and hoping it should work with with Kamstrup watermeters. But I have not yet got my rtl-sdr.com dongle to work with my multical21, but it could be a faulty antenna connecter. I have ordered another dvb-t dongle, compatible with rtl_sdr, to see if I can get that working. |
|
Hi so rtlwmbus instead of usbdevice ? |
|
Cool! Yes, please test! You build https://github.com/xaelsouth/rtl-wmbus and put the rtl_wmbus binary in your path. If you have such a water meter nearby, you can listen to it without having the key, simply You will get output like: No meters configured. Printing id:s of all telegrams heard! Received telegram from: 12345678 |
|
Hi wmbusmeters --c1 rtlwmbus Watermeter multical21 57722892 1B83B875A45F97A35XXXXXXXXXXXXX ? |
|
Yep. You do not need --c1 when you know the meter. Also rtlwmbus can listen to both C1 and T1 traffic at the same time. |
|
Aha! @kidpixo your heat cost allocator sends two kinds of wmbus messages interleaved. So I just pushed code to github that makes it possible for you to do: ./build/wmbusmeters --format=json simulations/simulation_kidpixo.txt MyElement qcaloric 78563412 "" I invented the unit hca, since I do not know what heat cost allocation is actually reported as. If you run with --debug you see those telegrams decoded as: I'll try to fix the date time extraction code. Please check if you |
weetmuts
changed the title
|
So in the above telegram we got: |
|
Thank you so much @weetmuts ! I'm less and less happy with non-standard standard and industry not making open their stuff based on open standard/projects.... I would really like to crack open those telegrams, thank a lot for your work! I remember that project like FHEM should already have some wmbus device integrated, maybe QDS is somewhere... I found some reference to QDS heat allocator in :
No. 1. has a whole telegram from QDS decoded, but it is encrypted... From 1. the telegram should contain:
Cheers |
|
Cool does this mean that you have succesfully run wmbusmeters on MacOSX using rtl_wmbus? Thanks for the links to the docs. It seems like your meter outputs exactly the data in your second link. {"media":"heat_cost_allocation","meter":"qcaloric","name":"Element","id":"94740258","current_consumption_hca":127.000000,"set_date":"2018-12-31","consumption_at_set_date_hca":145.000000,"set_date_17":"2019-01-31","consumption_at_set_date_17_hca":79.000000,"error_date":"2127-15-31","device_date_time":"2019-02-20 11:45","timestamp":"2019-03-01T14:41:59Z"} And then, there is the raw vendor specific string, but it is only shown in the debug output for the moment. But if you run with --debug and grep "vendor extension data", then you will see those. |
|
Yes, I did it! Thanks a lot! Here an example of visualisation with python+pandas
I feel we over used this github issue, this thread should have been cut in 2-3 different issues. If you want, I can cut this answer and start a new issue. For the data itself, I would like to see if I can decode the private packets, I'll search around. Thanks a lot!! My latest question is, now that I have a working chain to get the radio signal (rtl_sdr) > extract wmbus packet (rtl-wmbus) > decode my HCA sensors (wmbusmeters) : I would like to run a single instance of wmbusmeters to get all my sensor , normally I use a grep regex in the |
|
Hi weetmuts and kidpixo, really nice work that you both are doing here. :) weetmuts, i have found your project more than a year ago, just after rtl-wmbus was on github, but have not had enough elan to participate in wmbusmeters. Anyway, some of wireless MBus devices are reverse engineered by FHEM people. These devices use proprietary but unencrypted dataformat. Last time more and more manufacturers shift to Open Metering (OMS) and using encrypted datagrams only. https://github.com/mhop/fhem-mirror/tree/master/fhem/FHEM Another interesting link for you is (probably) https://github.com/rscada/libmbus , see for wired M-Bus datagram examples. You can test your own software by converting these into wireless M-Bus datagrams: first cut the M-Bus trailer and replace the M-Bus header with the wireless one. Just in case, you will find windows port of libmbus https://github.com/xaelsouth/libmbus-winport Xael |
|
Thanks @xaelsouth! @kidpixo yep, I think we can safely close this issue and open up new ones. :-) Please do so! |
|
Hi @xaelsouth , thanks but I did absolutely nothing, apart more workload for @weetmuts :-D I'm aware of FHEM, but personally using HomeAssistant, that's why I was searching for a more modular *NIX style solution : testing my sensors and maybe integrate in hass. They use a docker container instead of a plugin architecture, I find it really nice. Thanks for the link! @weetmuts doing it! |
Fixes the following crash: (gdb) bt #0 0x00005555555738d0 in abort@plt () wmbusmeters#1 0x0000555555589888 in std::__replacement_assert (__file=<optimized out>, __line=<optimized out>, __function=<optimized out>, __condition=<optimized out>) at /usr/include/c++/9/x86_64-redhat-linux/bits/c++config.h:2533 wmbusmeters#2 0x00005555555d1e37 in std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >::front (this=0x7ffff7a226d0) at /usr/include/c++/9/bits/basic_string.h:1123 wmbusmeters#3 0x00005555555ce8c5 in doesIdMatchExpression (id=..., match=...) at src/util.cc:513 wmbusmeters#4 0x00005555555cea92 in doesIdMatchExpressions (id=..., mes=...) at src/util.cc:560 wmbusmeters#5 0x000055555558aa56 in MeterCommonImplementation::isTelegramForMe (this=0x555555661c28, t=0x7ffff7a227b0) at src/meters.cc:188 wmbusmeters#6 0x000055555558c0e0 in MeterCommonImplementation::handleTelegram (this=0x555555661c28, input_frame=...) at src/meters.cc:289 wmbusmeters#7 0x000055555558c87a in MeterCommonImplementation::<lambda(std::vector<unsigned char, std::allocator<unsigned char> >)>::operator() (__closure=<optimized out>, input_frame=...) at /usr/include/c++/9/bits/stl_algobase.h:465 wmbusmeters#8 std::_Function_handler<bool(std::vector<unsigned char, std::allocator<unsigned char> >), MeterCommonImplementation::MeterCommonImplementation(WMBus*, MeterInfo&, MeterType, int)::<lambda(std::vector<unsigned char, std::allocator<unsigned char> >)> >::_M_invoke(const std::_Any_data &, std::vector<unsigned char, std::allocator<unsigned char> > &&) (__functor=..., __args#0=...) at /usr/include/c++/9/bits/std_function.h:285 wmbusmeters#9 0x00005555555da01f in std::function<bool (std::vector<unsigned char, std::allocator<unsigned char> >)>::operator()(std::vector<unsigned char, std::allocator<unsigned char> >) const (__args#0=..., this=0x7ffff7a22c70) at /usr/include/c++/9/bits/std_function.h:685 wmbusmeters#10 WMBusCommonImplementation::handleTelegram (this=this@entry=0x555555661b40, frame=...) at src/wmbus.cc:3328 wmbusmeters#11 0x00005555555fbf7b in WMBusRTLWMBUS::processSerialData (this=0x555555661ad0) at /usr/include/c++/9/bits/stl_algobase.h:465 wmbusmeters#12 0x00005555555cb001 in std::function<void ()>::operator()() const (this=<optimized out>) at /usr/include/c++/9/bits/std_function.h:685 wmbusmeters#13 SerialCommunicationManagerImp::eventLoop (this=0x5555556617c0) at src/serial.cc:795 wmbusmeters#14 0x00007ffff7f554e2 in ?? () wmbusmeters#15 0x0000000000000000 in ?? () Signed-off-by: Damian Wrobel <dwrobel@ertelnet.rybnik.pl>
Fixes the following crash: (gdb) bt #0 0x00005555555738d0 in abort@plt () wmbusmeters#1 0x0000555555589888 in std::__replacement_assert (__file=<optimized out>, __line=<optimized out>, __function=<optimized out>, __condition=<optimized out>) at /usr/include/c++/9/x86_64-redhat-linux/bits/c++config.h:2533 wmbusmeters#2 0x00005555555d1e37 in std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >::front (this=0x7ffff7a226d0) at /usr/include/c++/9/bits/basic_string.h:1123 wmbusmeters#3 0x00005555555ce8c5 in doesIdMatchExpression (id=..., match=...) at src/util.cc:513 wmbusmeters#4 0x00005555555cea92 in doesIdMatchExpressions (id=..., mes=...) at src/util.cc:560 wmbusmeters#5 0x000055555558aa56 in MeterCommonImplementation::isTelegramForMe (this=0x555555661c28, t=0x7ffff7a227b0) at src/meters.cc:188 wmbusmeters#6 0x000055555558c0e0 in MeterCommonImplementation::handleTelegram (this=0x555555661c28, input_frame=...) at src/meters.cc:289 wmbusmeters#7 0x000055555558c87a in MeterCommonImplementation::<lambda(std::vector<unsigned char, std::allocator<unsigned char> >)>::operator() (__closure=<optimized out>, input_frame=...) at /usr/include/c++/9/bits/stl_algobase.h:465 wmbusmeters#8 std::_Function_handler<bool(std::vector<unsigned char, std::allocator<unsigned char> >), MeterCommonImplementation::MeterCommonImplementation(WMBus*, MeterInfo&, MeterType, int)::<lambda(std::vector<unsigned char, std::allocator<unsigned char> >)> >::_M_invoke(const std::_Any_data &, std::vector<unsigned char, std::allocator<unsigned char> > &&) (__functor=..., __args#0=...) at /usr/include/c++/9/bits/std_function.h:285 wmbusmeters#9 0x00005555555da01f in std::function<bool (std::vector<unsigned char, std::allocator<unsigned char> >)>::operator()(std::vector<unsigned char, std::allocator<unsigned char> >) const (__args#0=..., this=0x7ffff7a22c70) at /usr/include/c++/9/bits/std_function.h:685 wmbusmeters#10 WMBusCommonImplementation::handleTelegram (this=this@entry=0x555555661b40, frame=...) at src/wmbus.cc:3328 wmbusmeters#11 0x00005555555fbf7b in WMBusRTLWMBUS::processSerialData (this=0x555555661ad0) at /usr/include/c++/9/bits/stl_algobase.h:465 wmbusmeters#12 0x00005555555cb001 in std::function<void ()>::operator()() const (this=<optimized out>) at /usr/include/c++/9/bits/std_function.h:685 wmbusmeters#13 SerialCommunicationManagerImp::eventLoop (this=0x5555556617c0) at src/serial.cc:795 wmbusmeters#14 0x00007ffff7f554e2 in ?? () wmbusmeters#15 0x0000000000000000 in ?? () Signed-off-by: Damian Wrobel <dwrobel@ertelnet.rybnik.pl>
Fixes the following crash: (gdb) bt #0 0x00005555555738d0 in abort@plt () wmbusmeters#1 0x0000555555589888 in std::__replacement_assert (__file=<optimized out>, __line=<optimized out>, __function=<optimized out>, __condition=<optimized out>) at /usr/include/c++/9/x86_64-redhat-linux/bits/c++config.h:2533 wmbusmeters#2 0x00005555555d1e37 in std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >::front (this=0x7ffff7a226d0) at /usr/include/c++/9/bits/basic_string.h:1123 wmbusmeters#3 0x00005555555ce8c5 in doesIdMatchExpression (id=..., match=...) at src/util.cc:513 wmbusmeters#4 0x00005555555cea92 in doesIdMatchExpressions (id=..., mes=...) at src/util.cc:560 wmbusmeters#5 0x000055555558aa56 in MeterCommonImplementation::isTelegramForMe (this=0x555555661c28, t=0x7ffff7a227b0) at src/meters.cc:188 wmbusmeters#6 0x000055555558c0e0 in MeterCommonImplementation::handleTelegram (this=0x555555661c28, input_frame=...) at src/meters.cc:289 wmbusmeters#7 0x000055555558c87a in MeterCommonImplementation::<lambda(std::vector<unsigned char, std::allocator<unsigned char> >)>::operator() (__closure=<optimized out>, input_frame=...) at /usr/include/c++/9/bits/stl_algobase.h:465 wmbusmeters#8 std::_Function_handler<bool(std::vector<unsigned char, std::allocator<unsigned char> >), MeterCommonImplementation::MeterCommonImplementation(WMBus*, MeterInfo&, MeterType, int)::<lambda(std::vector<unsigned char, std::allocator<unsigned char> >)> >::_M_invoke(const std::_Any_data &, std::vector<unsigned char, std::allocator<unsigned char> > &&) (__functor=..., __args#0=...) at /usr/include/c++/9/bits/std_function.h:285 wmbusmeters#9 0x00005555555da01f in std::function<bool (std::vector<unsigned char, std::allocator<unsigned char> >)>::operator()(std::vector<unsigned char, std::allocator<unsigned char> >) const (__args#0=..., this=0x7ffff7a22c70) at /usr/include/c++/9/bits/std_function.h:685 wmbusmeters#10 WMBusCommonImplementation::handleTelegram (this=this@entry=0x555555661b40, frame=...) at src/wmbus.cc:3328 wmbusmeters#11 0x00005555555fbf7b in WMBusRTLWMBUS::processSerialData (this=0x555555661ad0) at /usr/include/c++/9/bits/stl_algobase.h:465 wmbusmeters#12 0x00005555555cb001 in std::function<void ()>::operator()() const (this=<optimized out>) at /usr/include/c++/9/bits/std_function.h:685 wmbusmeters#13 SerialCommunicationManagerImp::eventLoop (this=0x5555556617c0) at src/serial.cc:795 wmbusmeters#14 0x00007ffff7f554e2 in ?? () wmbusmeters#15 0x0000000000000000 in ?? () Signed-off-by: Damian Wrobel <dwrobel@ertelnet.rybnik.pl>
Fixes the following crash: Thread 1 "wmbusmeters" received signal SIGABRT, Aborted. [Switching to Thread 0x7ffff7a16e00 (LWP 33345)] 0x00007ffff7a9d9e5 in raise () from /lib64/libc.so.6 (gdb) bt #0 0x00007ffff7a9d9e5 in raise () from /lib64/libc.so.6 wmbusmeters#1 0x00007ffff7a86895 in abort () from /lib64/libc.so.6 wmbusmeters#2 0x00005555555962cc in std::__replacement_assert (__file=0x5555556af910 "/usr/include/c++/10/bits/stl_vector.h", __line=1045, __function=0x5555556af7f0 "std::vector<_Tp, _Alloc>::reference std::vector<_Tp, _Alloc>::operator[](std::vector<_Tp, _Alloc>::size_type) [with _Tp = unsigned char; _Alloc = std::allocator<unsigned char>; std::vector<_Tp, _Alloc"..., __condition=0x5555556af7c0 "__builtin_expect(__n < this->size(), true)") at /usr/include/c++/10/x86_64-redhat-linux/bits/c++config.h:2560 wmbusmeters#3 0x000055555559dbe5 in std::vector<unsigned char, std::allocator<unsigned char> >::operator[] (this=0x7fffffffd9e0, __n=0) at /usr/include/c++/10/bits/stl_vector.h:1045 wmbusmeters#4 0x000055555569191f in detectRC1180 (detected=0x7fffffffdba0, manager=std::shared_ptr<SerialCommunicationManager> (use count 3, weak count 0) = {...}) at src/wmbus_rc1180.cc:344 wmbusmeters#5 0x0000555555674e7c in detectWMBusDeviceOnTTY (tty="/dev/ttyS0", handler=std::shared_ptr<SerialCommunicationManager> (use count 3, weak count 0) = {...}) at src/wmbus.cc:4201 wmbusmeters#6 0x00005555556a1d3c in perform_auto_scan_of_serial_devices (config=0x555555769790) at src/main.cc:870 wmbusmeters#7 0x00005555556a1b11 in perform_auto_scan_of_devices (config=0x555555769790) at src/main.cc:845 wmbusmeters#8 0x00005555556997d3 in detect_and_configure_wmbus_devices (config=0x555555769790) at src/main.cc:557 wmbusmeters#9 0x00005555556a322a in start (config=0x555555769790) at src/main.cc:1104 wmbusmeters#10 0x0000555555694796 in main (argc=3, argv=0x7fffffffe228) at src/main.cc:192 (gdb) fr 4 wmbusmeters#4 0x000055555569191f in detectRC1180 (detected=0x7fffffffdba0, manager=std::shared_ptr<SerialCommunicationManager> (use count 3, weak count 0) = {...}) at src/wmbus_rc1180.cc:344 344 if (data[0] != '>') (gdb) p data $1 = std::vector of length 0, capacity 1024 Signed-off-by: Damian Wrobel <dwrobel@ertelnet.rybnik.pl>
Hi,
sorry for the dumb question: I compiled wmbusmeters in a docker/debian container , but docker under mac cannot pass usb device to the hypervisor.
Under mac I cannot get it to compile. Here my g++ compiler specs and the output below.
I see in the Travis tests here that you are using C++ 4.8.something, maybe my problem is there?
A side question:
I cannot find a driver for mac to expose my cheap usb SDR (a chinese Realtek RTL28380, confirmed working with rtl_sdr and rtl-wmbus) under /dev/. I guess the rtl_sdr uses directly libusb to search for the device. There is a way to pass the data from stdin? Or any suggestion for running under mac?
In the future I'll switch this to a raspberry.
Thanks!
The text was updated successfully, but these errors were encountered: