lvogt / ioBroker.wireless-mbus

ioBroker wireless M-Bus adapter
GNU General Public License v2.0
6 stars 4 forks source link
adapter iobroker mbus wireless wmbus

Logo

ioBroker.wireless-mbus

installed-count stable-version

This adapter allows to receive wireless M-Bus data from supported receivers. The extent of device implementation varies, but wMBus modes can be configured for all listed devices.

The WMBUS stack has been "re-ported" from FHEM project and was extensively fixed and refactored. Testing was done with raw data picked up on the internet, OMS sample data and some test data from the jmbus library. Some edge cases are still untested.

The device creation, updating, etc is mostly based of Apollon77's M-Bus adapter (see below).

If the adapter receives encrypted telegrams the AES key configuration tab should list the device ID automatically.

If the parser fails the raw telegram data will be saved to the info.rawdata state.

Attention: The Amber receiver seems to crash after some time (or amount of received messages) in C mode? Hardware flaw?

IMST iM871A variant: There exists a "RWE Smart Home" USB receiver which is in principle a IMST iM871A, but the kernel will not automatically load the corresponding driver. This is a one-liner to create a udev rule to fix that:

sudo bash -c "echo \$'ACTION==\"add\", ATTRS{idVendor}==\"10c4\", ATTRS{idProduct}==\"87ed\", RUN+=\"/sbin/modprobe cp210x\" RUN+=\"/bin/sh -c \\'echo 10c4 87ed > /sys/bus/usb-serial/drivers/cp210x/new_id\\'\"' > /etc/udev/rules.d/99-imst.rules"

Links:

Initial setup

The initial setup requires to configure the basics (hardware connection to the wmbus receiver) and to setup AES keys for all encrypted wmbus nodes to be collected. The most tricky part are the AES keys.

Basic setup

This requires to select the appropriate USB device and the correct baud rate (usually for IMST: 57600 baud; Amber: 9600 baud; Embit: 9600 baud, CUL: 38400 or 9600 baud). Most meters will send in "T Mode".

From version 0.9.0 on, the adapter also supports to connect to serial devices reachable via a TCP socket. However, the admin interface does not really reflect that (for now) and you have to select "custom port" and enter the host as tcp://host:port.

Other options

AES keys

The device identifier is a combination of the manufacturer code and the device ID (e.g. AAA-12345678). The key can be entered either as a plain-text key with 16 characters or as a hex string with 32 characters (16 bytes).

The easiest way to setup the keys is to start the adapter without any key setup and to wait for an encrypted telegram, after which an entry with "UNKNOWN" key is generated by the adapter. Then you can fill in the corresponding key and save the settings. If you see devices you don't know or just want to get rid of (e.g. devices from neighbours), you can enter them in the blocked devices tab (see below).

Blocking unwanted devices

The "blocked devices" tab allows you to complete stop the adapter from handling telegrams from unwanted devices.

You only need to enter the device ID (e.g. AAA-12345678), which you can get from the object tree after a telegram has been received and parsed or from the (debug) log.

Afterwards, when you delete the device from the object tree, the adapter will not recreate it again.

ToDo

Changelog

0.9.4

0.9.3

0.9.2

0.9.1

0.9.0

0.8.10

0.8.9

0.8.8

0.8.7

0.8.3 / 0.8.4 / 0.8.5 / 0.8.6

0.8.2

0.8.1

0.8.0

0.7.9

0.7.8

0.7.7

0.7.5 / 0.7.6

0.7.3 / 0.7.4

0.7.1 / 0.7.2

0.7.0

0.6.2

0.6.0 / 0.6.1

0.5.2

0.5.1

0.5.0

0.4.7

0.4.6

0.4.5

0.4.2 / 0.4.3 / 0.4.4

0.4.1

0.4.0

0.3.0

0.2.0 (not tagged)

0.1.0

License

Copyright (c) 2019 ISFH - Institute for Solar Energy Research www.isfh.de Copyright (c) 2021 - 2024 Christian Landvogt

Licensed under GPLv2. See LICENSE and NOTICE