Receiving Wireless-M-Bus (wM-Bus) meter data
Introduction
Wireless-M-Bus (EN13757-4:2014-2) is integrated in a lot of modern smart meters. My water utility company replaced the old analog meter with a Kamstrup Multical 21 water meter. It includes a wM-Bus module and transmits data every 16 seconds.
Software
I’ll be using the ‘wmbusmeters’ project to receive the meter data. The package is included in latest Fedora Linux, together with rtl-sdr, so installation was quick and easy.
Hardware
There are different hardware options to receive wM-Bus signals on a linux based computer. There are specialised USB dongles built upon IMST 871a (im871a) and Amber 8465 (amb8465) chipsets. But the software that I’m going to use does also support RTL chip based DVB-T dongles (via rtl-sdr) and the CUL device family.
RTL-SDR
As I had a RTL-SDR based stick available, I’ve used this for the first tests. The DVB modules need to be unloaded.
# wmbusmeters --debug --listento=c1,t1,s1 rtlwmbus
(wmbusmeters) version: 0.9.30
(config) using device: rtlwmbus
(config) number of meters: 0
(detect) "rtlwmbus" ""
(detect) driver: rtlwmbus
(rtlwmbus) using command: rtl_sdr -f 868.95M -s 1.6e6 - 2>/dev/null | rtl_wmbus
(bgshell) exec background "/bin/sh"
(bgshell) arg "-c"
(bgshell) arg "rtl_sdr -f 868.95M -s 1.6e6 - 2>/dev/null | rtl_wmbus"
(serialcmd) opened /bin/sh
(config) all possible link modes that the meters might transmit on: none
No meters configured. Printing id:s of all telegrams heard!
(config) listen to link modes: any
(serial) waiting for stop
Right after startup of wmbusmeters, the first telegrams was received:
(rtlwmbus) checkRTLWMBusFrame "C1;1;1;2020-07-16 15:17:24.000;8;8;77261984;0x25442d2c841926771b168d20af01984a20b2c390456baf632c3a70729840a06e0d28f72e<0A>"
(rtlwmbus) received full frame
(wmbus) parseDLL @0 36
(wmbus) parseELL @10 26
Received telegram from: 77261984
manufacturer: (KAM) Kamstrup Energi
device type: Cold water meter
(wmbus) 00: 23 length (35 bytes)
(wmbus) 01: 44 dll-c (from meter SND_NR)
(wmbus) 02: 2d2c dll-mfct (KAM)
(wmbus) 04: 84192677 dll-id (77261984)
(wmbus) 08: 1b dll-version
(wmbus) 09: 16 dlltype (Cold water meter)
(wmbus) 0a: 8d ell-ci-field (ELL: Extended Link Layer II (8 Byte))
(wmbus) 0b: 20 ell-cc (slow_resp sync)
(wmbus) 0c: af ell-acc
(wmbus) 0d: 01984a20 sn (AES_CTR)
(wmbus) 11: b2c3 payload crc (calculated 3b65 ERROR)
(wmbus) "telegram=||23442D2C841926771B168D20AF01984A20B2C390456BAF632C3A70729840A06E0D28F72E|+8607"
(serial) received ascii "C1;1;1;2020-07-16 15:17:56.000;8;10;77261984;0x2c442d2c841926771b168d20b103984a20d60b038c5ce4da206029ace0984846deaaf55a9006f36976689b<0A>"
(rtlwmbus) checkRTLWMBusFrame "C1;1;1;2020-07-16 15:17:56.000;8;10;77261984;0x2c442d2c841926771b168d20b103984a20d60b038c5ce4da206029ace0984846deaaf55a9006f36976689b<0A>"
(rtlwmbus) received full frame
Yay. It works. The downside of this approach is that the rtl-sdr backend eats a lot of CPU cycles.
CUL family
Firmware installation
The CUL device family does use a CC1101 based RF chipset together with an Atmel microcontroller. Make sure to get the 868MHz version. I’ve grabbed a nanoCUL on ebay for a few buckets. The board.h header file in the Devices/nanoCUL directory needs some changes. I did uncomment HAS_CC1100_433 to use 868MHz. I did also uncomment all protocols that I don’t need. #define HAS_MBUS will enable wMBus support. Compilation and flashing worked flawless with make program. To verify the firmware operation, I did open the serial port with picocom. Entering a capital ‘V’ followed by ‘Enter’ did show the firmware string:
# picocom -b 38400 /dev/ttyUSB0
picocom v3.1
[...]
Type [C-a] [C-h] to see available commands
Terminal ready
V 1.67 nanoCUL868
Usage
Rigth after starting wmbusmeters, I did receive another frame from the neighbourhood:
# wmbusmeters --debug --listento=t1 /dev/ttyUSB0:cul
(wmbusmeters) version: 0.9.30
(config) using device: /dev/ttyUSB1
(config) with: cul
(config) number of meters: 0
(detect) "/dev/ttyUSB1" "cul"
(detect) is_tty=1 is_stdin=0 is_file=0
(cul) on /dev/ttyUSB1
(serialtty) opened /dev/ttyUSB1
(config) all possible link modes that the meters might transmit on: none
No meters configured. Printing id:s of all telegrams heard!
(cul) set link mode t
(serial /dev/ttyUSB1) sent "6272740A0D"
(serial) received binary "544D4F44450D0A"
(cul) checkCULFrame "TMODE<0D><0A>"
(cul) no leading 'b' so it is text and no frame
(cul) received "TMODE"(serial /dev/ttyUSB1) sent "5830310A0D"
(config) listen to link modes: t1
(serial) waiting for stop
(cul) received full T1 frame
(wmbus) parseDLL @0 52
(wmbus) parseELL @10 42
(wmbus) parseAFL @10 42
(wmbus) parseTPL @10 42
(telegram) DLL L=33 C=44 (from meter SND_NR) M=5068 (TCH) A=11767594 VER=94 TYPE=80 (Heat Cost Allocator)
(telegram) TPL CI=a2
Received telegram from: 11767594
manufacturer: (TCH) Techem Service
device type: Heat Cost Allocator
(wmbus) 00: 33 length (51 bytes)
(wmbus) 01: 44 dll-c (from meter SND_NR)
(wmbus) 02: 6850 dll-mfct (TCH)
(wmbus) 04: 94757611 dll-id (11767594)
(wmbus) 08: 94 dll-version
(wmbus) 09: 80 dll-type (Heat Cost Allocator)
(wmbus) 0a: a2 tpl-ci-field (Mfct specific)
(wmbus) "telegram=||33446850947576119480A20F9F279205F00F7203018B097009000000000003132028476663647397967F8C6B6036000000000000|+297"
Summary
The nanoCUL is a very cheap option to receive wMBus data. Kudos to the authors of wmbusmeters for their nice software. Now I’m waiting for the AES key from the utility company, as the Kamstrup Multical transmits all data encrypted.
Links
https://github.com/weetmuts/wmbusmeters