wM-Bus platform, no cabling.

What is wM-Bus?

Wireless M-Bus is the short-range radio built into most water, heat, gas and sub-metering meters sold in Europe, standardised in EN 13757-4 and sitting alongside the wired M-Bus that runs on two-wire cabling inside buildings. The meter transmits on its own schedule, usually one short telegram every few seconds to few minutes, and does not wait for a request. In the common T and C modes it sends at 868 MHz; the C mode is the more efficient of the two and what most new meters ship with. On top of the radio, the Open Metering System (OMS) specification defines how the telegram is structured and encrypted, which is why a Kamstrup receiver can read an Apator meter and a Lobaro gateway can read both.

The trade-off is range. A wM-Bus meter reaches tens of metres inside a building and a few hundred outdoors, and spends almost nothing on radio to do so; that is where the ten- to sixteen-year battery comes from. The distance is bridged by whatever collects the telegrams. Inside a building that is a gateway on the wall. Across a town it is a fixed network of collectors, a car with a receiver driving the streets, or a bridge that repacks the telegram onto LoRaWAN or a mobile network. Divako reads from all of them, which is why the meter choice and the collection choice can be made separately.

How it works on Divako

1. Device. The meter arrives with its serial number and, from the manufacturer or supplier, its AES-128 key. Both are imported into Divako by CSV or API and bound to a device profile from the library, so the OMS or manufacturer-specific telegram is already understood before the first one arrives.
2. Network. The meter transmits. A collector picks up the telegram: a Lobaro gateway with NB-IoT or LTE-M uplink, a Kamstrup READy collector, a wM-Bus-to-LoRaWAN bridge, or the drive-by reader in the field. Divako manages the Lobaro gateways directly and takes the others in through native connectors.
3. Platform. The telegram is decrypted with the meter’s key, decoded against the profile and normalised: volume, energy, flow, timestamp, quality and the meter’s own status flags. Signal level per collector is kept, so a meter that only one gateway can hear is visible before it goes silent.
4. Analysis. Leak, burst, backflow, frost and drift rules run per device type, and alarms route to email, webhook, MQTT or your incident system. A wM-Bus meter follows the same rules as a LoRaWAN or NB-IoT one.
5. Integration. Readings leave over REST, MQTT, webhooks or SFTP, and through native connectors to billing systems such as Komtek and Gemini, SCADA or ERP.

What to watch out for

• Encryption keys are an essential part of the project. A missing or wrong key means the telegram arrives but its contents cannot be read. Agree the key handover format and process at the start of procurement, and check the first batch’s keys before the wider installation continues.
• A fixed network and drive-by serve different needs. Drive-by needs no separate infrastructure, but data only reaches the system during a reading round. A fixed network delivers hourly or even minute-level data, but needs collectors, power and network planning. Both can be used together; on Divako the data lands in the same data model regardless of how it was collected.
• The transmission interval sets the level of detail. The more often a meter transmits, the sooner consumption changes and possible leaks become visible. The interval depends on the meter and may be configurable or fixed at the factory, so decide it before ordering.
• T and C modes need a suitable receiver. An existing meter fleet may use several wM-Bus modes at once. When choosing collectors, check which modes the existing and new meters use and that the chosen receiver supports all of them.