Operation
The product has a configuration lock feature, which prevents unauthorized access to the module. When configuration lock has been enabled, a device-specific Product Access Key (PAK) will be needed to access the device. Keys are managed in a secure way using Elvaco’s OTC solution which includes the mobile application for configuration.
Note
For more information about security and access control for the product, refer to the One-touch commissioning (OTC) documentation, available on the Elvaco website.
The granularity and timing of data sent from the CMi6160 is based two settings. Firstly, it is how often the module is reading data from meter, referred to as the Report interval. Secondly, it based on how often the module sends data to a receiving system, referred to as the Transmit interval. These settings combined governs the amount and how often data will be sent to the receiving system. This e.g. means that if the Report interval is shorter than the Transmit interval, several meter readouts are sent in the same transmission. What data that is transmitted is decided by the configured message format, see Message formats for a complete definition of every message format available. The way the message format is encoded is also configurable, see Message encoding for details.
Below table summarize the essential settings to govern the data sent from the CMi6160.
Table 31. Essential module settings
|
Setting |
Description |
|---|---|
|
Report interval |
Determines how often the meter is read by the module. Read values are stored in the module until the next transmission. A short report interval means the meter is read often, meaning a higher data granularity can be acheived. |
|
Transmit interval |
Determines how often data is sent from the module to the receiving system. A short transmit interval means the module will send data more frequent, allowing the system to get data from more recent meter readouts. |
|
Message format |
Determines what content from the meter readout that is sent to the receiving system. It is possible to choose from several message formats. |
|
Message encoding |
Determines how the data is encoded before being sent. Choose the alternative that suits receiving system and other needs best. |
Tip
Transmitting data is a far more energy consuming operation than reading the meter. For battery operated devices, it is thus wisely to set a larger transmit interval than the report interval to achieve a decent data granularity.
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 used 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.
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 ours given a set transmission interval (Ttransmit). The figure below illustrates this. The transmissions are planned at time T1. The actual Ttransmit is a random time between (T1 + Toffset) and (T1 + Toffset + Tdelay).
Ttransmit, Toffset and Tdelay are parameters in the product.
The module sends meter data messages according to it’s transmit interval settings. Meter read out is always related to meter’s clock at time 00:00:00. Transmission time is randomized between read outs.
Transmitting and interpreting meter data from the module is flexible and the user can choose among different encoding techniques, and message formats. Chosen message format dictates what data is sent, while the encoding technique determines how that data in should be interpreted. In the following paragraphs, the available message formats and encoding techniques are described in detail.
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.
Example 5. Example 1
A device is configured the following way:
-
Message encoding: M-Bus
-
Auto upload order: FIFO
-
Measurement interval: 60 minutes
-
Transmit interval: 60 minutes
-
Transmit offset: 15 minutes
-
Transmit delay: 30 minutes
-
Maximum uploads per transmission: 4
-
Upload maximum age 72h
A network issue caused the module to be offline for 5 days, while still reading and storing measurement data. When the device manages to go online the following scenario takes place.
-
The device will start by transmitting measurement data that is 3 days old (FIFO order)
-
The device will send 4 measurement telegrams per hour, at a randomly chosen time between minute 15 and 45
-
Each telegram contains a single readout, totaling 4 readouts per transmission
-
The device will take approximately 1 day to “catch up” and start sending one measurement per hour
Example 6. Example 2
A device is configured the following way:
-
Message encoding: SenML/CBOR/M-Bus
-
Auto upload order: FIFO
-
Measurement interval: 60 minutes
-
Transmit interval: 60 minutes
-
Transmit offset: 15 minutes
-
Transmit delay: 30 minutes
-
Maximum uploads per transmission: 4
-
Upload maximum age 72h
-
Device max payload size: 12 (readouts per telegram)
A network issue caused the module to be offline for 5 days, while still reading and storing measurement data. When the device manages to go online the following scenario takes place.
-
The device will start by transmitting measurement data that is 3 days old (FIFO order)
-
The device will send 4 measurement telegrams per hour, at a randomly chosen time between minute 15 and 45
-
Each telegram contains 12 meter readouts, totaling 4 x 12 = 48 readouts per transmission
-
The device will take approximately 2 hours to “catch up” and start sending one measurement per hour
The product has three options when it comes to message encoding:
-
M-Bus
-
JSON
-
SenML/CBOR
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 a detailed examples of how data is encoded when using message encoding M-Bus.
Table 32. Payload, M-Bus encoded message
|
DIB |
Field |
Size |
Data type |
Description |
|---|---|---|---|---|
|
1 |
Date/time |
6 bytes |
INT32 |
Meter date and time (YY-MM-DD HH:MM) Mapped to OBIS 9.36 046Dxxxxxxxx Bit 31-28 = Year-high* Bit 27-24 = Month Bit 23-21 = Year-low* Bit 20-16 = Day Bit 15 = Summer time flag** Bit 14-13 = Century Bit 12-8 = Hour Bit 7 = Error flag Bit 6 = Reserved for future use*** Bit 5-0 = Minute *The year is read by combining the yearhigh and year-low field. For example, year-high = 0010 and year-low = 010 => year = 0010010 **0 = standard time, 1= daylight-saving time ***0 = timestamp is valid, 1 = timestamp is not valid |
|
2 |
Meter ID |
6 bytes |
According to M-Bus EN13757- 3 identification field |
Meter ID 0C78xxxxxxxx |
|
3 |
Energy |
6-7 bytes |
INT32 |
Energy consumption (Wh, J) 0406xxxxxxxx = xxxxxxxx * 0.001 MWh (kWh) 0407xxxxxxxx = xxxxxxxx * 0.01 MWh 04FB00xxxxxxxx = xxxxxxxx * 0.1 MWh 04FB01xxxxxxxx = xxxxxxxx MWh 040Exxxxxxxx = xxxxxxxx * 0.001 GJ (MJ) 040Fxxxxxxxx = xxxxxxxx * 0.01 GJ 04FB08xxxxxxxx = xxxxxxxx * 0.1 GJ 04FB09xxxxxxxx = xxxxxxxx GJ |
|
4 |
Volume |
6 bytes |
INT32 |
Volume (m3) 0413xxxxxxxx = xxxxxxxx * 0.001 m3 0414xxxxxxxx = xxxxxxxx * 0.01 m3 0415xxxxxxxx = xxxxxxxx * 0.1 m3 0416xxxxxxxx = xxxxxxxx m3 |
|
5 |
Power |
4 bytes |
INT16 |
Power (W) 022Bxxxxxx = xxxxxx * 0.001 kW (W) 022Cxxxxxx = xxxxxx * 0.01 kW 022Dxxxxxx = xxxxxx * 0.1 kW 022Exxxxxx = xxxxxx kW |
|
6 |
Flow |
4 bytes |
INT16 |
Flow (m3/h) 023Bxxxxxx = xxxxxx * 0.001 m3/h 023Cxxxxxx = xxxxxx * 0.01 m3/h 023Dxxxxxx = xxxxxx * 0.1 m3/h 023Exxxxxx = xxxxxx m3/h |
|
7 |
Fw temp |
4 bytes |
INT16 |
Forward temperature (°C) 025Axxxx = xxxx * 0.1 °C 025Bxxxx = xxxx * °C |
|
8 |
Rt temp |
4 bytes |
INT16 |
Return temperature (°C) 025Exxxx = xxxx * 0.1 °C 025Fxxxx = xxxx °C |
|
9 |
Error flags |
5 bytes |
INT16 |
Error and warning flags 02FD17xxxx For further information about Error flags, refer to the latest meter’s manual |
|
10 |
Tariff 1 Energy |
7 bytes |
INT32 |
Tariff 1 Energy consumption (Wh, J) 841003xxxxxxxx = xxxxxxxx Wh 841003xxxxxxxx = xxxxxxxx * 10 Wh 841003xxxxxxxx = xxxxxxxx * 100 Wh 841003xxxxxxxx = xxxxxxxx kWh 841003xxxxxxxx = xxxxxxxx *10 kWh 841003xxxxxxxx = xxxxxxxx MJ 841003xxxxxxxx = xxxxxxxx * 10 MJ |
|
11 |
Tariff 2 Energy |
7 bytes |
INT32 |
Tariff 2 Energy consumption (Wh, J) 842003xxxxxxxx = xxxxxxxx Wh 842003xxxxxxxx = xxxxxxxx * 10 Wh 842003xxxxxxxx = xxxxxxxx * 100 Wh 842003xxxxxxxx = xxxxxxxx kWh 842003xxxxxxxx = xxxxxxxx *10 kWh 842003xxxxxxxx = xxxxxxxx MJ 842003xxxxxxxx = xxxxxxxx * 10 MJ |
|
12 |
Tariff 3 Energy |
7 bytes |
INT32 |
Tariff 3 Energy consumption (Wh, J) 843003xxxxxxxx = xxxxxxxx Wh 843003xxxxxxxx = xxxxxxxx * 10 Wh 843003xxxxxxxx = xxxxxxxx * 100 Wh 843003xxxxxxxx = xxxxxxxx kWh 843003xxxxxxxx = xxxxxxxx *10 kWh 843003xxxxxxxx = xxxxxxxx MJ 843003xxxxxxxx = xxxxxxxx * 10 MJ |
|
13 |
Missing time |
6 bytes |
INT32 |
3C22xxxxxxxx = xxxxxxxx hours 3C23xxxxxxxx = xxxxxxxx days |
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.
Table 33. Payload, JSON encoded message
|
Field |
JSON key |
|---|---|
|
Meter ID |
ID |
|
Meter date / time |
TS |
|
Energy |
E |
|
Energy unit |
U |
|
Volume |
V |
|
Volume unit |
VU |
|
Power |
P |
|
Power unit |
PU |
|
Flow |
F |
|
Flow unit |
FU |
|
Forward temperature |
FT |
|
Forward temperature unit |
TU |
|
9eturn temperature |
RT |
|
Return temperature unit |
RU |
|
Error flags |
EF |
|
Tariff 1 Energy |
T1 |
|
Tariff 1 Energy unit |
U1 |
|
Tariff 2 Energy |
T2 |
|
Tariff 2 Energy unit |
U2 |
|
Tariff 3 Energy |
T3 |
|
Tariff 3 Energy unit |
U3 |
|
Missing time |
MT |
|
Missing time unit |
MU |
Example payload, JSON:
{
"TS":"2019-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 might be necessary 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 save (in terms of 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 readout.
Note
SenML, CBOR and M-Bus are separate standards, this section describes how products can use these three in conjunction for representing multiple measurement values in a compact format suitable for radio transmission over for instance NB-IoT.
Meter readout data is sent as SenML, i.e., a list (aka array) of readout values (records), encoded using CBOR. Each record is a map of key/value pairs using SenML.
Note
Each product that uses the SenML/CBOR format shall follow the requirements below. In addition, it shall specify the exact contents of the data values included, meter ID format etc. Thus, this specification alone is not sufficient for building a parser for a specific product.
Base time is used to set a reference time.
-
Timestamps are always encoded according to SenML (i.e., UNIX time)(SenML label -1 “Base time”, SenML definition of Time field)
-
This value must be included in the first record of the pack
-
All other values have a time value that is added to the base time to define the exact time of the readout
Base name is used to represent the MeterID (Meter identification in M-Bus) for products that deliver measurement data for one meter.
-
If base name is used
-
This value MUST be included in the first record of the pack
-
This is represented as a string array (CBOR Major Type 3 - SenML label -2 “Base name”)
-
The product shall specify the exact format for this field, as it may vary depending on what type of “meter” is used. For an M-Bus format it is typically the M-Bus data without DIF/VIF.
-
-
No name is set for remaining meter readout values, only values belonging to a single meter can be represented in one pack.
-
-
If readouts to be sent contain different MeterIDs (module moved between meters for instance) they must NOT be sent in the same SenML pack
-
All values within a SenML pack MUST be for the same MeterID
-
The data values SHALL NOT have a name value further specifying the name for each value.
-
-
Base name SHALL NOT be used for SenML packs that have data for multiple meters. In such cases each record shall contain the MeterID of the meter.
-
The actual values from the meter can be encoded using multiple methods, such as M-Bus.
-
The first record can also contain a data value field containing more information than the remaining records in the pack. This is to include more information for the first reading and then only a subset of values for the remaining records to save space. (SenML label 8 - “Data value”)
-
(Base) Unit is not used, since the unit is specified by the M-Bus data
-
An “Encoder Version field” is used in a separate record to define the type and version of the encoded payload data.
All records in the SenML pack are expected to contain measurement values. If there is a need for transmitting additional information in the same pack additional records can be added. For such records the name field shall be used by defining a name of at least a single character. In SenML the base name and the name fields are appended to result in the final record name.
The name shall contain at least one character outside [A-Fa-f0-9] which signifies non-hexadecimal representation, since meter-id is typically decimal/hexadecimal, and this makes it easier to check the record name for validity.
If a parser finds a record with a name field like described above that it does not recognize it shall ignore the record.
The following additional records are currently used:
|
Record |
Name field |
Comment |
|---|---|---|
|
Encoder Type & Version |
”V” |
This field allows defining versions for the contents of the measurement field. |
The following table defines allowed encoder types and versions. The information is sent in a special record “Encoder Version field”.
-
This field encapsulates both the encoding of the data and versioning
-
It contains no timestamp
-
It is encoded as a SenML Value
-
It has a Name field with the single letter “V”
-
If, when parsing, an invalid version is encountered the parsing shall stop with an error
-
The value shall be interpreted as an UINT16
-
The first byte is the encoder type and the second is the encoder version, both interpreted as UINT8.
Example: value 0x0102 means Encoder type 0x01 and Encoder version 0x02.
-
Defined valid encoder types and versions are found in a table below on this page o
-
Size of whole record is maximum 7 bytes
-
-
If record is excluded, encoder type is 0 and encoder version is 0
|
Record |
Name field |
Data |
Comment |
|---|---|---|---|
|
0 (M-Bus) |
0 |
0x0000 |
M-Bus encoding of payload data. Each data record contains all DIF/VIF/Values according to M-Bus. Note that M-Bus uses LSB first byte order for the data and it shall be preserved here as well. |
Below is some real-life sample payload. Note that this is not identical to the one above in a few regards:
-
BaseTime contains a tag(1) (Epoch-based date/time). This is not mandated by SenML/CBOR.
-
The Encoder Type/Ver record is placed last in the base array.
Raw (Base64):
hqMhaDcxOTUxMzE4IsEaZtB0VAhYIQQGAHcDAAQUYdgKAAItEwACO1QBAlogAgJe8AEC/RcAAKIGOQODCFghBAYAdwMABBRY2AoAAi0TAAI7VAECWh8CAl7wAQL9FwAAogY5BwcIWCEEBv92AwAEFFDYCgACLRgAAjteAQJaHwICXuMBAv0XAACiBjkKiwhYIQQG/3YDAAQUR9gKAAItEwACO1QBAloeAgJe7wEC/RcAAKIGOQ4PCFghBAb+dgMABBQ/2AoAAi0UAAI7SgECWiACAl7sAQL9FwAAogBhVgIA
Decoded using CBOR decoder.:
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)
At https://cbor.me/, there's a Validator available for CBOR. Note that it does not understand SenML or M-Bus.
Note
A small bug has been identified in the hex interpretation of negative numbers in the validator. Please have this in mind if using the validator.
SenML/CBOR is to be considered a message encoding. It defines how the messages are encoded, but not the actual contents of the messages (which fields from the meter are included). SenML/CBOR/M-Bus is one such encoding, but there could be several based on this SenML/CBOR specification and the encoder version field above defines exactly which type and version is used.
The contents of the message are defined by the message format. The message format sets which fields are to be included in both the first and the subsequent records of the SenML pack.
The number of records included in a pack is set by the readout and transmit intervals. See Scheduling Readouts for more details. If the readout interval is 120 minutes and the transmit interval is 1440 minutes 12 readouts in total will be included.
Each product may have different maximum payload sizes in a single telegram. Also depending on configuration (DTLS or not for instance) the net payload size may vary. Therefore, the device shall “fill up” as many telegrams as required to send the data. It is for the user to define a configuration that gives a reasonable tradeoff between power consumption (send fewer telegrams) and functional requirements (much data is sent).
If a device is configured using a Message Format and many readouts the data may not fit in a single telegram. In such cases multiple telegrams shall be sent and each telegram shall be fully self-described, i.e., contain Meter ID, timestamps etc.
|
Parameter |
Value |
|---|---|
|
Readout interval |
60 |
|
Transmit interval |
1440 (daily) |
|
Message encoding |
SenML/CBOR/M-Bus version 0 |
|
Message format |
Standard |
|
Max transmissions per day |
3 |
This example results in the transmission of one message per day, containing 24 readings, all with the contents defined in the Standard message format. Data is encoded using SenML/CBOR/M-Bus. Maximum 3 unsent such messages are sent each time (if for some reason the messages were not sent “last time”). So maximum transmitted messages per day is 3 (containing 3x24=72 readings, covering 3 days)
|
Parameter |
Value |
|---|---|
|
Readout interval |
120 |
|
Transmit interval |
720 |
|
Message encoding |
SenML/CBOR/M-Bus version 0 |
|
Message format |
Tariff |
|
Max transmissions per day |
2 |
This example results in the transmission of one message every 12h, containing 6 readings, all with the content defined in the Tariff message format. Data is encoded using SenML/CBOR/M-Bus. Maximum 2 unsent such messages are sent each time (if for some reason the messages were not sent “last time”), so maximum transmitted messages per day is 4 (containing 4x6=24 readings, covering 2 days).
To reboot the module use the Elvaco OTC app.
To switch off the module use the Elvaco OTC app.
-
Open the Elvaco OTC app.
-
Scan the module.
-
Go to Apply mode.
-
Choose the switch off switch and apply changes.
Comments (0 comments)