wmbusmeters: Reading Wired and Wireless Utility Meters

What wmbusmeters acquires and who needs it

wmbusmeters solves a specific acquisition problem: it receives utility-meter telegrams and turns their encoded measurement values into readable records. It supports wired m-bus meters and wireless wm-bus meters compatible with the documented wmbus and OMS formats. The intended users are operators who need meter data from physical hardware, including Raspberry Pi installations and systems connected to supported dongles. A meter reading can be published using MQTT, sent with curl to a REST API, inserted into a database, or stored in a log file.

The program does not stop at copying raw telegram bytes. Its drivers translate meter-specific measurements into named key-value pairs. The README gives the following distinction: a binary word in a storage slot can represent a volume, but that alone does not establish whether it is a billing total, a monthly value, or another period. A driver supplies that context by matching fields such as measurement type, VIF range, storage number, and quantity.

This makes wmbusmeters more useful than a raw serial or radio logger for an engineer who needs normalized readings. It is less suitable as a complete data-management product. The documentation does not describe dashboards, billing logic, historical analysis, alert rules, or a built-in database schema. Those responsibilities remain with the configured destinations or with other software.

How telegram decoding and output flow through wmbusmeters

The documented data path begins with a source. A source can be a radio dongle, an RTL-SDR software radio dongle, a serial port connected to an M-Bus meter, a file, or a pipe. After acquisition, wmbusmeters processes incoming telegrams using a meter driver. The driver converts the encoded fields into measurements with names and quantities that describe the utility value. Output can then be rendered as human-readable text, CSV, or JSON.

The README shows a raw telegram being converted into a readable line containing a meter name, identifier, volume, flow, and timestamp. It also shows CSV output, which uses semicolon separators in the example. The JSON example identifies the media as water, includes the meter name and identifier, and exposes fields such as `max_flow_m3h`, `total_m3`, and a timestamp. Those names are examples of output fields, not a promise that every meter uses the same fields.

Driver definitions are central to correctness. The documented XMQ-style field definition associates a field name and information string with a quantity and a match block. The match identifies the measurement type, VIF range, and storage number. The README says that native drivers are being rewritten in this form and that new drivers should be written directly in XMQ rather than added as C++ code. That policy reduces the amount of new native driver logic in the project, but it also means a meter with an unusual encoding needs an appropriate driver definition before its values will be interpreted correctly.

The output destination is therefore part of the decoding design, not an afterthought. A correct measurement name still needs to reach a destination with enough context for later processing. The documentation gives examples for MQTT, REST, database, and log output, but it does not provide a single universal message schema for every meter.

Choosing a dongle and configuring wmbusmeters

wmbusmeters supports several hardware paths, so the first configuration decision is the source type. The README names `im871a`, `iu891a`, `amb8465(metis)`, `amb3665`, `cul`, `rc1180`, and generic `RTL2832U` devices. Serial devices use device paths and a dongle or mode specification. Examples include `/dev/ttyUSB0:iu891a:c1` and `/dev/ttyUSB1:amb8465:c1,t1`. The documented device selector `auto:t1` scans for supported devices and is convenient for testing, although the README warns that startup scanning can take time.

For a stable production setup, the README recommends replacing `auto:t1` with a full device path such as `/dev/ttyAMA0:iu891a:c1,t1`. That avoids probing every possible dongle during startup. If a serial identifier such as `ttyUSB0` may change, `device=iu891a:c1,t1` can probe serial devices while restricting the scan to `iu891a`. A full path, `rtlwmbus`, or `rtl433` bypasses serial-device probing. The configuration also supports `donotprobe=/dev/ttyUSB0` and `donotprobe=all` when probing must be prevented.

RTL-SDR devices are different from ordinary serial devices. The README says they are accessed through character device files from `/dev/swradio0` through `/dev/swradio255`, and that wmbusmeters uses `librtsldr` to probe them. This distinction matters when diagnosing a missing device: looking only under `/dev/tty...` will not cover the documented SDR path.

Building wmbusmeters and starting the first daemon

The README gives a short source installation path for GNU/Linux. It instructs users to remove the wmbus dongle before building, then run the configure script, compile the project, and install the daemon. The resulting installation expects configuration under `/etc/wmbusmeters.conf`.

./configure
make
sudo make install

After installation, inspect `/etc/wmbusmeters.conf` and confirm that its `device` setting matches the attached dongle. If it contains `device=auto:t1` and the hardware is one of the supported types, the daemon can be started through systemd. The direct command is useful for the first launch because it exposes the process in the foreground.

sudo systemctl start wmbusmeters

wmbusmeters auto:t1

The README says the program scans for wmbus devices every few seconds and detects when a device is plugged in or removed. It also notes that supporting several dongle types makes the scan slower. For the first use, `auto:t1` helps identify a dongle. A later production configuration should use the full path or a narrower selector, because device names and USB assignments can change.

The daemon can be enabled at boot with the documented systemd command. Configuration can be reloaded with `killall -HUP wmbusmetersd`, and an alternate configuration directory can be supplied with `wmbusmetersd --useconfig=/path/to/config`. The alternate directory must contain `wmbusmeters.conf` and the `wmbusmeters.d` meters directory. The README states that `make install` works for GNU/Linux, while macOS users should start `wmbusmetersd /path/to/thepidfile` from a script.

Drivers, formats, and practical configuration limits

The driver layer is both a feature and a dependency. wmbusmeters can explain a measurement such as `total_m3` only when a driver knows how the meter encodes that field and how the storage slot relates to the value's meaning. If no suitable driver exists, the repository documentation gives no basis for assuming that arbitrary storage slots will be correctly labeled. The README's advice is specific: create a new driver directly in XMQ form, not as C++ code.

The format options are useful when integrating the daemon with other software. CSV suits line-oriented ingestion, while JSON carries named fields and metadata such as media, meter, identifier, and timestamp. Human-readable output is convenient for direct inspection but is less structured for downstream automation. The examples do not define whether a missing measurement is omitted, represented as null, or emitted with a default value, so that behavior should be checked against the selected driver and output configuration.

The program also has hardware-specific constraints. The README warns that random data sent to `/dev/ttyAMA0` can upset some Raspberry Pi configurations when that port is used for Bluetooth, and gives `donotprobe=/dev/ttyAMA0` as a remedy. Multiple RTL-SDR dongles can be distinguished with identifiers assigned through `rtl_eeprom`, such as `my name` in the example `rtl_eeprom -s myname`. This identifier mechanism matters when more than one radio is attached and each has a different antenna or role.

The documentation does not specify a universal retry policy for radio interference, missing telegrams, malformed frames, or offline meters. It also does not claim that wmbusmeters can decode every OMS implementation. Its scope is tied to incoming telegrams, supported dongles, and available drivers.

Maintenance, licensing, and alternatives

The repository is not archived, and its last push was on 2026-10-17. That is recent enough to indicate continued repository activity, but it is not a guarantee of compatibility with every meter, dongle, or host configuration. The release list includes versions 1.20.0 and 2.0.0 on 2026-03-01 and 3.0.0 on 2026-06-17. The presence of versioned releases gives users a basis for checking upgrade notes and selecting a deployment version, although the documentation does not describe the upgrade procedure or migration policy in detail.

The primary language is C++, and the repository identifies its license as GPL-3.0. The Makefile header states GPL-3.0-or-later. Distribution, modification, and integration implications therefore need to be reviewed against the applicable GPL terms. This is a licensing boundary, not a claim about suitability for every deployment model.

A practical alternative is to collect the raw telegram stream with a dedicated radio or serial receiver and perform decoding in a separate application. That approach can fit a system that already owns meter semantics, historical storage, and output schemas. wmbusmeters instead combines acquisition, driver-based interpretation, and multiple output adapters in one program. The choice depends on where the existing responsibility lies: use wmbusmeters when the system needs an integrated meter reader, and use separate acquisition plus decoding when the meter interpretation belongs in a different data pipeline.

wmbusmeters checks before production deployment

The first verification point is hardware discovery. Use `auto:t1` to identify the attached device, then replace it with a full path when the device is known. Confirm whether the hardware is a serial dongle or an RTL-SDR device, since the README documents different access paths for them. Next, verify that the configured driver matches the meter's protocol and measurement layout. A decoded value such as `total_m3` is meaningful only when its field definition reflects the meter's actual encoding and storage semantics.

The second point is output behavior. Decide whether the first integration should use MQTT, REST, a database, a log, CSV, or JSON, and inspect the generated records for the expected meter identifier, timestamp, media, and measurement names. The examples do not guarantee identical fields across drivers, so field-level inspection is necessary.

The third point is service lifecycle. If systemd is used, verify the daemon starts with the chosen configuration and that reloads are sent in the documented way. For nonstandard installations, check the alternate `--useconfig` directory and its `wmbusmeters.d` layout. Finally, compare the selected release with the hardware and driver requirements, especially when moving from version 1.x to 2.x or 3.x. The repository's recent development activity is favorable for continued work, but adoption still depends on the specific meter and dongle combination.

Editorial conclusion

Adopt wmbusmeters when you need to acquire utility-meter telegrams from supported serial or radio hardware and can provide the correct driver configuration. Do not choose it as a general-purpose meter database or billing system, because its documented scope begins with telegram acquisition and decoding. Before adoption, verify dongle type, device path, meter driver coverage, output destination, and the meaning of each decoded measurement. The repository's last push was on 2026-10-17, and its documented license is GPL-3.0, so distribution and modification terms should be checked before integration.

Frequently asked questions

Official sources

1. Issues
2. License: GPL-3.0
3. README
4. Releases
5. wmbusmeters/wmbusmeters on GitHub