Operation
Before being able to transmit data over a LoRaWAN® network, the device must be personalized and activated. This can be done in two ways: Over-the-air activation (OTAA) or Activation by Personalization (ABP). For security reasons, Elvaco strongly recommends using OTAA, where all network keys are generated each time the device joins the LoRaWAN® network. In contrast, for ABP, all keys are set manually and stay constant over time. The tables below list the required information depending on the activation mode.
|
Device EUI |
16-digit unique identification number (not configurable). |
|
Application key |
The application key of each device is generated by Elvaco and used in OTAA mode to generate network keys when it joins the LoRaWAN® network. |
|
JoinEUI |
Sets the identification number of the join server. The identification number is set to a default value in all devices. The default value is presented in Elvaco OTC configuration options. |
Tip
The NFC field is easiest accessible if placing the phone in the middle part of the front.
The transmit interval is used to set how frequently the module should transmit data on the LoRaWAN® network. The parameter can be set to a value between 10 and 1440 minutes (i.e. from 10 minutes to once per day). It is possible to fix the transmit interval, but for battery-operated devices where battery lifetime is critical, Elvaco recommends using the EcoMode feature, which adapts the transmit interval depending on prevailing radio conditions.
When EcoMode is active, the module has a battery lifetime of 6+1 or 10+1 years, depending on what EcoMode alternative is set. EcoMode setting is ignored when PSU (external power supply Engelmann) is connected. The module can achieve battery life of 6+1 or 10+1 years by using a table of allowed transmit intervals settings for each data rate.
When radio conditions are poor (and data rate is low), the module will send data less frequently to conserve battery-life. When signal conditions are good, the module will send data more frequently. When EcoMode is enabled, the module will continuously check if the set transmit interval is “allowed” by the EcoMode table. If a lower transmit interval is needed for the specific data rate to achieve 6+1 or 10+1 years of battery life, the module will adjust the parameter accordingly.
See the following tables for the transmit interval allowed in each data rate.
Caution
Anticipated battery lifetime cannot be assured if:
-
EcoMode is disabled (Even if EcoMode is activated later)
-
Changing from 6+1 to 10+1 years battery lifetime in EcoMode
Note
When using the “Engelmann” message format, the transmit interval is doubled to compensate for the additional telegrams transmitted in this message format, with the exception of DR0 in 10 year EcoMode where the transmit interval is capped at 1440 minutes (corresponding to once every 24 hours).
Table 346. EcoMode transmit interval settings, EcoMode (6 years)
|
Data rate |
Transmit interval (minutes) |
Transmit interval, Engelmann message format (minutes) |
|---|---|---|
|
DR0 |
180 |
360 |
|
DR1 |
120 |
240 |
|
DR2 |
60 |
120 |
|
DR3 |
30 |
60 |
|
DR4 |
15 |
30 |
|
DR5 |
15 |
30 |
Table 347. EcoMode transmit interval settings, EcoMode (10 years)
|
Data rate |
Transmit interval (minutes) |
Transmit interval, Engelmann message format (minutes) |
|---|---|---|
|
DR0 |
1440 |
1440 |
|
DR1 |
360 |
720 |
|
DR2 |
180 |
360 |
|
DR3 |
120 |
240 |
|
DR4 |
90 |
180 |
|
DR5 |
60 |
120 |
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.
ADR is part of the LoRaWAN® standard where the network server determines the optimal rate for the module based on current signal conditions. In the best radio conditions, the module will use its highest data rate (DR5) in order to be as energy-efficient as possible. When signal conditions are poor, the network server will incrementally lower the data rate until it is able to receive the message. When the data rate is low, the energy consumption per telegram will increase.
All message formats encoded to M-Bus standard will have the following structure. Each telegram begins with one byte specifying the message format. Then follows a sequence of data information blocks (DIBs). The data and structure of the DIBs depends on the message type set. Each DIB contains a data information field (DIF), a value information field (VIF) and a data field (DATA), where the actual payload is stored.
M-Bus message structure
Note
When using the message format JSON, the data will be presented as plain text, and not according to the M-Bus structure as presented above.
The product has a configuration lock feature, which prevents unauthorized access to the module. When the configuration lock has been enabled, a device-specific Product Access Key (PAK) will be needed to access the device. Keys are managed securely 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.
Payloads using M-Bus encoded data use the Function field of the DIF to indicate errors. In this case, it is set to “value during error state” (M-Bus standard EN 13757-3:2013) and the value sent should not be used. A typical case for this is when the module is unable to communicate with the meter and retrieve meter values, in which case all the fields in the payload have the DIF indicating “value during error state”. In case of erroneous data or if the module is unable to communicate with the meter, bits 4–5 of the DIF code (first byte of each index field) will be set to 11b.
Example 16. Example
A DIF code of 0x02 will be set to 0x32 in case of error. (This applies to all message formats except JSON.) For message format JSON, the actual value will be replaced with “null” in case of error state. If no meter communication is possible at all, all fields have this error indication set.
Comments (0 comments)