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 for keeping time. Time in the meter is assumed to be in 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 indicates 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, due for instance 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.

If using meter-controlled mode, the customer-defined telegram, as specified in the Diehl SHARKY or SCYLAR meter, is sent transparently without modification. Typically, this telegram is preconfigured in the meter at delivery but can also be adjusted in the field. When using this mode, message encoding is automatically set to SenML/CBOR to accommodate larger customer-defined telegrams. Since the protocol used in Diehl SHARKY and SCYLAR is M-Bus, the payload delivered in the SenML/CBOR packages will also be in M-Bus format

In the module-controlled mode, the data sent depends on the selected message format. CMi6160 has two different message formats to choose from, Standard and Tariff. See section Message formats for a complete list of included records in each format.

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 Tariff, a typical payload can look like:

04139C2E0000023B0000325A0000325E0000841006000000008420FD320000000001FD1750

If the same payload is sent as an alarm message, the extended error codes will be appended to the payload:

04139C2E0000023B0000325A0000325E0000841006000000008420FD320000000001FD175002FD180800

The extended meter codes are identified by the M-Bus DIF/VIF 2FD18, Error Mask, and is here followed by the two error bytes 0x0800. Since M-Bus is encoded using little endian, the resulting complete error mask is 0b0000 0000 0000 1000. This means error bit 3 is set, indicating there is some issue with the temperature measurements (see meter error interpretation table).

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 will be 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 of 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 offers data encoding that is human-readable, at the expense of not being equally compact as e.g. SenML/CBOR.

Example payload, JSON:

{"TS":"2025-08-27T07:36:01Z "," ID":81493511, "E":0, "U":"kWh", "V":0, "VU":"m3", "P":5012, "PU":"W", "F":212, "FU":"l/h", "FT":30.1, "TU":"C", "RT":22.5, "RU": "C", "I":"0x0010", "EF":"0x70"}

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.

1  83                                      # array(3)
2  
3  ** Record for defining encoder and version **
4  
5     A2                      # map(2)
6        00                   # unsigned(0)   ## Key 1: Name
7        61                   # text(1)       ## Value 1:
8           56                # "V"           ## "V" = version
9        02                   # unsigned(2)   ## Key 2: Value
10       19 0300              # unsigned(768) ## Value 2: enc=3, ver=0
11 
12 ** first record of the pack **
13     
14    A2                      # map(2)
15       22                   # negative(2)          ## Key 1: Base Time
16       C1                   # tag(1)               ## Value 1:
17          1A 6835B149       # unsigned(1748349257) ## 2025-05-27T12:28:33+00:00
18       08                   # unsigned(8)          ## Key 2: Data value
19       58 36                # bytes(54)            ## Value 2: M-Bus telegram
20          6830306808007274
21          031961A51140048B
22          0000000C06080000  # Payload data, line breaks added for readbility
23          00046D220C3B350C
24          13377400008C10FD
25          32000000008C2013
26          000000006D16
27 
28 ** second record of the pack, containing extended information **
29 
30    A3                      # map(3)
31       00                   # unsigned(0)          ## Key 1: Name
32       61                   # text(1)              ## Value 1:
33          49                # "I"                  ## "I" = extended information
34       08                   # unsigned(8)          ## Key 2: Data value
35       45                   # bytes(5)             ## Value 2: M-Bus data
36          02FD187000        # "\u0002\xFD\u0018p\u0000"
37       06                   # unsigned(6)          ## Key 3: Timestamp
38       00                   # unsigned(0)          ## Value 3: Relative time 0

By performing a factory reset, the device reverts its settings to factory default. It will also delete all meter data and syslog entries stored in the module. Factory reset can be done either via the Elvaco OTC app, or remotely over LwM2M (resource 3/./5).