Operation

Meter data can be transmitted using either MQTT-SN or LwM2M Send. The protocols cannot be used simultaneously, but it's possible to configure via LwM2M or the Elvaco OTC App. Regardless of the chosen transport protocol, the content of the transmitted data remains the same. When a meter data transmission is scheduled, the data being sent is defined by the chosen message format. If there are any unsent meter data available in the module, they will be transmitted according to the chosen recovery strategy (First in First out (FiFO) or Last in First out (LiFo)).

The module relies on the meter’s clock to keep time. The meter time is assumed to be standard local time (no DST). When synchronizing time in the meter using the Elvaco OTC App, local standard time is always used, even if DST is in effect. The timestamped meter data sent from the module can be adjusted to be sent in UTC by specifying the “UTC offset” configuration parameter. The UTC offset will be subtracted from the timestamp prior to transmission. If the meter is in Sweden, which uses CET (Central European Time), it should have UTC offset set to +60 (+1h). In this case at time 12:00 a telegram is sent with timestamp 11:00 as this is the corresponding UTC time. A meter in New York (USA) should have a UTC offset of "-300" (-5h) etc. A UTC offset of "0" means the meter time is used as-is.

If the meter is set to use DST this is ignored by the module and the standard time is used. Thus, the time on the meter’s display may not match the time in the telegram or in the Elvaco OTC App.

All schedules are based on a synchronization with a clock. This means that if a readout schedule of 60 minutes is used, it is synchronized on top of the hour, so 11:00, 12:00, 13:00 etc.. 120 minutes will give 12:00, 14:00, 16:00 etc.. When time in the module (or meter) is synchronized, a rescheduling takes place such that the next meter readout is made according to an updated time. Synchronization of the meter clock can be done in various ways, either periodically (automatically) or manually. It is recommended using a periodic approach to avoid the risk of letting the clock drift too much.

To handle the case where time synchronization “moves time” past a previously planned readout (like 23.58 → 00.02) the module will always make a readout and transmission of a new value when time is synchronized. The device will, therefore, send an additional readout which can be masked on the server side.

In order to prevent a large population of devices from transmitting data at exactly the same time the devices have a random delay before transmitting data. The delay is configurable via either the Elvaco OTC App and the NFC interface, or remotely via a device management system.

Readouts from the meter are always performed on top of the hour, 11.00, 13.00 etc. Transmissions can be carried out at other times but are planned at full hours given a set transmission interval (T_transmit). The figure below illustrates this. The transmissions are planned at time T₁. The actual T_transmit is a random time between (T₁ + T_offset) and (T₁ + T_offset + T_delay).

T_transmit, T_offset and T_delay are parameters in the product.

Conditions

• T_offset + T_delay <= T_transmit

This should be checked by the device and the OTC App.

• If T_transmit is reduced below T_offset + T_delay , then T_offset should be set to 0 and T_delay = T_transmit.

If data cannot be sent, for instance due to network issues, there will be a number of retries after which the device will give up and leave the readout as “unsent” in its storage. Next time a transmission is attempted unsent data will be resent (if possible). Retransmission can be done by FIFO or LIFO.

Rules for retransmissions include maximum age of data, order of data, number of retransmitted data / transmission interval.

Meter alarms are transmitted using the chosen transport protocol, which can be either MQTT-SN or LwM2M Send. Regardless of the chosen transport protocol, the content of the transmitted data remains the same. When an alarm is triggered, the message follows the selected format, with Extended Error Codes appended to it. If there are any unsent meter data available in the module, they will be transmitted simultaneously with the alarm.

Each bit in the alarm mask is directly mapped to a meter error. The different alarm masks used for controlling the alarm monitor have the same mapping. The sections below describe how each bitmask should be managed and interpreted.

The table below specifies available meter errors and how they are mapped to the bitmask.

Using message format Standard, a typical payload can look like:

046D002A323B0C7837266966040637570A000414EF472000022B0000023BFCFF025B0000025F000002FD170400

0x02FD17 is the M-Bus DIF/VIF indicator for error flags, and the following two bytes 0x0400 indicates there's an error. Given that M-Bus encoding using LSB, the corresponding bit map is read as 0x00 04, giving the resulting bits 0b0000 0000 0000 0100. This means that bit 2 is set, meaning there is an issue with the return temperature sensor (see Meter error interpretation table above).

If a payload instead is sent as an alarm message, it will look similar, but the extended error codes will also be appended to the message:

046D0F2A323B0C7837266966040637570A000414EF472000022B0000023BFCFF025B0000025F000002FD17040002FD180400

0x02FD17 again indicates the error flags, and the following two bytes 0x04 00 are identical to the example above. Since this message has been triggered as an alarm, the extended error codes are appended to the payload, see 02FD180400. The FD18 indicates it's an M-Bus error mask. The bytes in the error mask are decoded in the same way as the error flags, following the information given the Meter error interpretation table above.

The module system log can be transmitted using either MQTT-SN or LwM2M Send. Which one is used depends on the chosen transport protocol for the meter data. Regardless of the choice, the content of the transmitted data remains the same. When a system log entry, having a system log level that is configured to be sent, is stored in the module, it will be sent together with the subsequent meter data transmission. All unsent log entries that are supposed to be sent will be included.

Regardless if the system log is sent using MQTT-SN or LwM2M Send, the payload is structured according to the SenML data model and encoded using CBOR. The system log message itself is stored as an ASCII text string inside the SenML record.

To get a complete description on how the SenML/CBOR packages are encoded, see section SenML/CBOR. Below example shows a simplified way to decode a system log message, from the raw payload to a human readable system log message.

If using M-Bus as message encoding technique, data is divided into Data Information Blocks (DIB) that include Data information field (DIF code), Value information field (VIF code) and a data field (DATA) where the actual payload is stored (illustrated in the following image).

DIB structure

The table below provides detailed examples of how data is encoded when using message encoding M-Bus.

When using JSON message encoding, messages sent consist of an object with a list of key – value pairs. Example of the names for each value type and unit are presented in the table below. The values are encoded as numbers or strings and the units are encoded as strings. JSON provides human-readable encoding, at the expense of not being equally compact as e.g. SenML/CBOR.

Example payload, JSON:

{
"TS":"2025-11-28T20:39Z",
"ID":87654321,
"E":12345.678,
"U":"MWh",
"V":3456.7,
"VU":"m3",
"P":5012,
"PU":"W",
"F":212,
"FU":"l/h",
"FT":80.3,
"TU":"C",
"RT":53.8,
"RU":"C",
"EF":"0x4012"
}

For battery-powered devices it is recommended to send several measurements in the same UDP frame to save energy. In order to achieve this, SenML (Sensor Measurement Lists) + CBOR (Concise Binary Object Representation) is used to define a measurement list.

The idea is to send a list of measurements, where the first entry contains the base time for all the readouts (which only need to specify an offset) and the meter id shared by all readouts. The other records in the list may contain fewer readout fields to save space. The format allows sending all the data for every readout, in which case the savings (in bytes) is smaller and lies in that fewer telegrams are sent, some data needs not be transferred for every reading (like meter-id) and timestamps can be handled more efficiently. SenML/CBOR also provides one way to structure lists of readings in an efficient manner.

Elvaco uses SenML/CBOR/M-Bus data representation for transferring meter data in a compact and self-describing manner. The data being transferred is referred to as a pack, containing one record per measurement.

01 83                                      # array(3)
02    A2                                   # map(2)
03       00                                # unsigned(0)
04       61                                # text(1)
05          56                             # "V"
06       02                                # unsigned(2)
07       00                                # unsigned(0)
08    A3                                   # map(3)
09       21                                # negative(1)
10       68                                # text(8)
11          3636363932363337               # "66692637"
12       22                                # negative(2)
13       C1                                # tag(1)
14          1A 691C43A0                    # unsigned(1763460000)
15       08                                # unsigned(8)
16       58 21                             # bytes(33)
17          040637570A000414EF472000022B0000023BFDFF025B0000025F000002FD170400 # "\u0004\u00067W\n\u0000\u0004\u0014\xEFG \u0000\u0002+\u0000\u0000\u0002;\xFD\xFF\u0002[\u0000\u0000\u0002_\u0000\u0000\u0002\xFD\u0017\u0004\u0000"
18    A3                                   # map(3)
19       00                                # unsigned(0)
20       61                                # text(1)
21          49                             # "I"
22       08                                # unsigned(8)
23       45                                # bytes(5)
24          02FD180400                     # "\u0002\xFD\u0018\u0004\u0000"
25       06                                # unsigned(6)
26       00                                # unsigned(0)

[{0: "V", 2: 0}, {-2: "66692637", -3: 1(1763460000), 8: h'040637570A000414EF472000022B0000023BFDFF025B0000025F000002FD170400'}, {0: "I", 8: h'02FD180400', 6: 0}]

1  86                                      # array(6)
2     A3                                   # map(3)
3        21                                # negative(1)
4        68                                # text(8)
5           3731393531333138               # "71951318"
6        22                                # negative(2)
7        C1                                # tag(1)    
8           1A 66D07454                    # unsigned(1724937300)  # "2024-08-29T13:15:00Z"
9        08                                # unsigned(8)
10       58 21                             # bytes(33)
11          040600770300041461D80A00022D1300023B5401025A2002025EF00102FD170000
12    A2                                   # map(2)
13       06                                # unsigned(6)
14       39 0383                           # negative(899) # "2024-08-29T13:00:00Z"
15       08                                # unsigned(8)
16       58 21                             # bytes(33)
17          040600770300041458D80A00022D1300023B5401025A1F02025EF00102FD170000
18    A2                                   # map(2)
19       06                                # unsigned(6)
20       39 0707                           # negative(1799) # "2024-08-29T12:45:00Z"
21       08                                # unsigned(8)
22       58 21                             # bytes(33)
23          0406FF760300041450D80A00022D1800023B5E01025A1F02025EE30102FD170000
24    A2                                   # map(2)
25       06                                # unsigned(6)
26       39 0A8B                           # negative(2699) # "2024-08-29T12:30:00Z"
27       08                                # unsigned(8)
28       58 21                             # bytes(33)
29          0406FF760300041447D80A00022D1300023B5401025A1E02025EEF0102FD170000
30    A2                                   # map(2)
31       06                                # unsigned(6)
32       39 0E0F                           # negative(3599) # "2024-08-29T12:15:00Z"
33       08                                # unsigned(8)
34       58 21                             # bytes(33)
35          0406FE76030004143FD80A00022D1400023B4A01025A2002025EEC0102FD170000
36    A2                                   # map(2)
37       00                                # unsigned(0)
38       61                                # text(1)
39          56                             # "V"
40       02                                # unsigned(2)
41       00                                # unsigned(0)