Technical reference | Published 2026-08-27 | Reviewed 2026-08-27
M-Bus, Modbus, BACnet, and LoRaWAN solve different parts of a metering architecture. This reference helps consultants, integrators, and facility teams decide where each protocol belongs, what must be mapped, and what should be tested before handover.
By ConnectME Engineering. Reviewed by ConnectME Technical Services.
There is no universal best meter protocol. M-Bus is purpose-built for meter collection, Modbus is common for device registers and industrial integration, BACnet represents building-automation objects and services, and LoRaWAN carries low-power wireless device data through a network server. Interoperability usually requires a governed gateway or software mapping layer plus tested semantics, timestamps, quality states, and capacity limits.
Use this matrix to frame the architecture review, then verify the current specification and manufacturer implementation for the selected equipment.
| Protocol | Typical role | Topology | What must be mapped | Strength | Design caveat |
|---|---|---|---|---|---|
| M-Bus | Meter data collection | Wired bus with master and secondary devices; wireless variants use a different radio layer | Primary or secondary address, records, units, tariffs, status, and read schedule | Meter-focused data model and efficient collection of utility values | Master capacity, cable design, addressing, telegram variation, and polling time must be engineered |
| Modbus RTU or TCP | Device register access and industrial integration | RS-485 multidrop or Ethernet client-server communication | Register address, data type, byte order, scale, unit, write permission, and exception behavior | Widely supported and straightforward when a controlled register map exists | Registers have little meaning without current vendor documentation and agreed polling limits |
| BACnet/IP or MS/TP | Building automation objects, alarms, trends, and supervisory integration | Ethernet or token-passing field bus with BACnet devices and objects | Device and object identifiers, object type, unit, priority, status flags, and change-of-value behavior | Rich building-automation semantics and services for interoperable supervisory control | Device IDs, network numbers, broadcast management, profiles, and writable priorities need governance |
| LoRaWAN | Low-power wide-area transport for wireless meters and sensors | End devices through gateways to a network server and application integration | Device identity, payload codec, units, frame counters, timestamps, data rate, and application endpoint | Long-range, low-power wireless coverage for suitable low-throughput telemetry | Coverage, duty cycle, payload size, downlink limits, key ownership, and battery budget constrain design |
Translate meaning, not just bytes.
Size the architecture from the real workload.
Plan ownership for the full operating life.
An M-Bus master reads the meters, then a gateway or AMR layer maps selected values into Modbus registers or BACnet objects. The handover must identify both the source records and the destination points so scaling and diagnostics remain traceable.
The device sends compact payloads through one or more gateways to a network server. An application codec converts the payload, applies identity and units, and forwards governed readings to AMR, MDMS, or billing workflows. Radio reception alone does not prove billing completeness.
A gateway can expose selected Modbus registers as BACnet objects for the BMS. Confirm data types, units, status behavior, polling load, BACnet identifiers, and any writable priority rules instead of relying on an automatic one-to-one conversion.