Repeater Add-On — wM-Bus Telegram Formats
The repeater has no cloud connection. What it "uploads" are wireless M-Bus telegrams on the radio: the meter telegrams it repeats, each with a footer appended, and its own status telegrams. A receiving wM-Bus gateway forwards both to the backend like any other telegram.
All telegrams are sent in C1 mode; a repeated telegram keeps the frame format (A or B) of the original.
Repeated Meter Telegrams
The meter telegram is passed on byte for byte – header, encryption and payload unchanged. The repeater increments the hop count, sets the hop bit where the telegram type has one, appends its footer and recalculates the CRC.
Repeater footer (10 bytes)
| Bytes | Content |
|---|---|
0C 78 | DIF/VIF: 8-digit BCD, serial number |
| 4 bytes | serial number of the repeater, BCD, least significant byte first (wM-Bus ID format) |
01 FD 71 | DIF/VIFE: 8-bit integer, RSSI |
| 1 byte | signal strength at which this repeater received the telegram, in −dBm |
Each hop appends one more footer, in the order of the hops: a telegram that passed two repeaters carries two footers, the first one from the repeater next to the meter. The format is the same as that of other common wM-Bus repeaters, so mixed chains can be read as one path.
Short footer (very long telegrams)
A wM-Bus telegram can be at most 255 bytes long. When the 10-byte footer no longer fits (telegrams longer than 244 bytes), the repeater appends a short footer instead:
0F 4C ss ss first short hop (4 bytes)
4C ss ss every further short hop (3 bytes)
| Bytes | Content |
|---|---|
0F | DIF: manufacturer-specific data follows (standard parsers stop here) |
4C | marker of one short hop |
ss ss | last four digits of the repeater's serial number, BCD, least significant byte first (repeater 00143384 → 84 33) |
The short footer carries no RSSI and only part of the repeater's serial number: two repeaters whose serial numbers end in the same four digits look the same in a short hop. The meter ID in the telegram header is not affected. Footers already in the telegram are kept, so a chain can mix both forms, for example two 10-byte footers followed by one short hop:
... 0C 78 11 34 14 00 01 FD 71 40 0C 78 49 75 12 00 01 FD 71 41 0F 4C 84 33
To parse the short hops, read 3-byte groups 4C ss ss from the end of the telegram as long as ss ss is valid BCD, until a single 0F precedes them. BCD bytes never contain 0F or 4C, so this is unambiguous; without the 0F there is no short footer.
A telegram for which not even the short footer fits is not repeated.
Own Status Telegrams
The repeater sends its own status telegram every statusInterval seconds (default 300 s). It is unencrypted and forwarded by other repeaters like a meter telegram, so after passing a chain it carries one footer per hop – the path and the signal strength of every link between the repeaters.
| Field | Content |
|---|---|
| M-field | LOB (E2 31) |
| ID | serial number of the repeater, BCD |
| Version | protocol version of the repeater's telegrams, currently 0x01. It is incremented whenever the status telegram layout or the footer format changes in a way a receiver has to know about; appended data records do not change it |
| Device type | 0x32, unidirectional repeater |
| CI | 0x7A, short transport header, unencrypted |
| TPL.acc | access number, incremented with each status telegram |
| TPL.sts | 0x00 = OK, 0x43 = RTC error alarm (no valid time at boot) |
02 FD 46 + 2 bytes | battery voltage in mV |
06 6D + 6 bytes | date and time (type I): second, minute, hour, day, month, year |
04 6E + 4 bytes | number of telegrams repeated since boot |