Configuration Parameters
The device is shipped with default configuration parameters. The configuration can be changed via the 6-pin config port using the Lobaro USB Configuration Adapter.
More information about the usage of the configuration tools can be found in our documentation.
Remote Configuration is also supported after initial network connection.
Networking Parameters (NB-IoT / LoRaWAN)
| Name | Description | Default Value | Value Description & Examples |
|---|---|---|---|
| WAN | Radio technology used for connection to backend | lte |
|
| Host | Hostname / IP of the Lobaro Platform API Not used for LoRaWAN uplink | 94.130.20.37 | 94.130.20.37 = platform.lobaro.com # DNS is not supported yet |
| Port | Port number of the Lobaro Platform API Not used for LoRaWAN uplink | 5683 | |
| Lost Reboot | Days without connectivity until device reset | 3 |
NB-IoT Parameters (WAN = "lte", "nbiot", "ltem")
The LTE functionality is enabled if the WAN parameter is set to lte, nbiot, or ltem. Using this mode requires an appropriate SIM-Card to be inserted.
| Name | Description | Default Value | Value Description & Examples |
|---|---|---|---|
| Operator | Mobile Operator Code (optional) | 26201 | 26201 (=Deutsche Telekom), for other operators, see above. Empty = Auto detect (longer connecting time) |
| Band | NB-IoT Band | 8 | "8", "20", "8,20", Empty = Auto detect (longer connecting time) |
| APN | Mobile operator APN (optional) | iot.1nce.net | APN provided by your SIM card operator |
| PIN | SIM PIN (optional) | Empty or 4 digits (e.g. 1234) |
LoRaWAN Parameters (WAN = "lorawan", "lorawan-abp")
| Name | Description | Default Value | Value Description & Examples | Since |
|---|---|---|---|---|
| DevEUI | DevEUI used to identify the Device | Device's own DevEUI as printed on label | 8 bytes = 16 hex digits, e.g. 0123456789abcdef | |
| JoinEUI | EUI used for OTAA (aka AppEUI) | Individual default value for each device | 8 bytes = 16 hex digits, e.g. 0123456789abcdef | |
| AppKey | AES Key used for LoRaWAN | Individual default value for each device | 16 bytes = 32 hex digits, e.g. 0123456789abcdef001122334455667788 | |
| SF | Minimal Spreading Factor used | 12 | 7-12, used after reset, can be decreased by ADR during operation (but not increased) | |
| OpMode | LoRaWAN Operation Mode | A | A = Class A, C = Class C | v0.2.1 |
Keep the value of AppKey secret. If you change it, make sure you are using a good random source.
OTAA - Over the Air Activation
The preferred method to use LoRaWAN is Over The Air Activation (OTAA). When WAN="lorawan" the device uses the values to perform an OTAA Join with the LoRaWAN Network Server. Make sure the values for DevEUI, JoinEUI, and AppKey match.
The device is manufactured with a globally unique EUI64 that is used as DevEui. This EUI is printed on the devices label and can be used to identify a device. You can change the DevEUI used for LoRaWAN by changing the configuration parameter DevEUI. The device will still keep it's unique EUI64 it was delivered with. You can see it in the Log output during booting, even if a different value is used for the DevEUI.
Each Device will be configured with a unique JoinEUI and AppKey that are generated using a cryptographic hashing algorithm. Those values will seem random and are very likely to be unique for each device. These values are known to Lobaro but will not be made public. You can change the AppKey if you prefere to have Keys that are known only to you. Be sure to use a good random source when generating keys.
ABP - Activation by personalisation
Our devices support activation by personalisation (ABP) when WAN="lorawan-abp". This mode is useful for devices that have a bad reception. You will have to synchronise session keys by hand between the device and your Network Server when using ABP.
When using ABP, the device will use the parameters DevEUI and AppKey for generating the session parameters:
- DevAddr will consist of the last for bytes of DevEUI
- NetSKey will be cryptographically derived from AppKey
- AppSKey will be cryptographically derived from AppKey
The values will be printed out in the Log after boot, so you can copy them to the configuration in your Network Server. Do change the DevAddr, alter the DevEUI value in the configuration. To create a different pair of session keys, change the value of AppKey in the configuration. Best practise is, to change it to randomly generated bytes coming from a good random source. The generated Session Keys will be deterministic for a given value of AppKey, even if used on different devices.
LAN Parameters (WAN = "ethernet"; WAN = "ethernet+lte"; WAN = "ethernet+nbiot")
Communication over Ethernet ist only supported for the devices #8000159, #8000166, #8000200
Combined WAN mode and Platform Communication
With firmware versions >= 0.14.0, a combined WAN mode can be set up:
WAN = ethernet+nbiotWAN = ethernet+lte
This way, the gateway operates in a prioritized failover mode. This is not a dual-active WAN configuration. Ethernet is always prioritized (default interface).
However, for the current version of the Hybrid Modbus Gateway, CoAPS communication over Ethernet is not supported. Platform communication over Ethernet therefore uses plain CoAP. Cellular communication supports CoAPS.
For Ethernet and cellular fallback operation, both platform endpoints should be configured in the Host parameter:
coaps://platform.lobaro.com,coap://platform.lobaro.com
The communication behavior depends on the configured WAN mode:
WAN = ethernet: Ethernet is used exclusively. Platform communication is only possible via CoAP.WAN = ethernet+lte: Ethernet via CoAP is prioritized. If Ethernet communication fails, LTE-M is used as fallback via CoAPS.WAN = ethernet+nbiot: Ethernet via CoAP is prioritized. If Ethernet communication fails, NB-IoT is used as fallback via CoAPS.
When using WAN = lte without Ethernet, cellular communication is used exclusively. CoAPS is prioritized and CoAP is used as fallback.
The configured WAN mode determines the interface priority. The order of the entries in the Host parameter does not change the Ethernet-first behavior of the combined WAN modes.
On boot, the gateway:
- Activates the Ethernet interface
- Waits for network availability
- Attempts to establish a platform connection over Ethernet
As long as the platform is reachable via Ethernet, all uplinks and downlinks are handled over Ethernet.
Reset Behavior and Fallback (Ethernet → Cellular)
If repeated uplink attempts over Ethernet fail, the gateway will trigger an internal system reset. If the platform cannot be reached via Ethernet after the reset, the gateway switches to the configured cellular interface. Fallback is triggered when:
- Platform DNS resolution fails
- Platform connection fails
- Repeated uplink attempts fail
After fallback:
ethernet+nbiot→ NB-IoT is usedethernet+lte→ LTE-M / NB-IoT are used
The gateway continues normal operation over cellular.
Important: No Automatic Switchback
Once the gateway has switched to LTE/NB-IoT, it does not automatically switch back to Ethernet, even if Ethernet connectivity becomes available again. Ethernet is only re-evaluated during a reboot sequence. This behavior prevents interface oscillation in unstable network environments.
Cellular Failure After Fallback
If the gateway has already fallen back to LTE/NB-IoT and the cellular connection subsequently fails, the device does not automatically switch back to Ethernet, even if Ethernet is physically connected and operational. In this situation:
- The gateway remains offline.
- No automatic interface re-selection takes place.
- Ethernet is not reactivated during runtime.
- Recovery occurs only after a device reboot.
A reboot may be triggered automatically by the parameter:
LostReboot = <days>
This parameter defines the number of days without successful platform communication after which the device performs an automatic reset. After such a reboot:
- Ethernet is again prioritized.
- The normal Ethernet-first failover sequence applies.
Platform Security Setting
Since communication over Ethernet uses plain, unencrypted and unauthenticated CoAP, the option "Allow unencrypted, unauthenticated CoAP uplinks" must be enabled in the Security tab of the device in the Lobaro Platform when Ethernet is used:
If this option is disabled, the Lobaro Platform rejects uplinks received via plain CoAP.
As a result:
- With
WAN = ethernet, communication with the Lobaro Platform is not possible. - With
WAN = ethernet+lte, Ethernet communication cannot be used and the gateway has to fall back to LTE-M/CoAPS. - With
WAN = ethernet+nbiot, Ethernet communication cannot be used and the gateway has to fall back to NB-IoT/CoAPS.
Plain CoAP does not provide encryption or authentication. It is required for Ethernet communication on this Gateway version because CoAPS over Ethernet is not supported. Cellular communication should use CoAPS whenever possible.
Modbus related Parameters
| Name | Description | Default Value | Values Description & Examples |
|---|---|---|---|
| MbCmd | List of Modbus Commands with Cron and Modbus parameters (see below). | 0 0/5 * * * *:R,9600,8N1:010300000003 | Zero or more entries of Modbus commands to be executed by the device. Each entry starts with a Cron expression defining when to execute the commands followed by the bus parameters used to address the Modbus slave devices. Each entry can contain multiple commands. See description below for a detailed explanation. † |
† See also our Introduction to Cron expressions.
MbCmd defines, what Modbus commands are executed on the Bus, when, and what Modbus Configuration to use for them. The configuration is very flexible and allows complex setups, that include executing different commands at individual intervals or times or using multiple different Modbus parameters to address incompatible Slaves on the same installation. Any Modbus command can be sent, including writing registers or diagnostic messages.
The parameter consists of up to 32 entries, separated by semicolons. Each entry consists of three parts, separated by colons: its individual Cron expression, the Modbus configuration used, and the Modbus commands to be executed. Each entry can have multiple Modbus commands to execute on activation, separated by comma. A Modbus command must be written as the Bytes to be sent on the bus in Hex notation. The check sums will be added by the device according to the protocol used.
The command is entered in Hex and without any check sums and is 6 bytes long (12 hexdigits). The default value is 010300000003, it consists of 4 hex parts: 01, 03, 0000, 0003
0x01
Address of the Slave Device. 1 byte: often 01 new devices
0x03
What kind of Modbus Register to read. 1 byte. 03 stand for Holding Register.
0x0000
Number/address of the first register to read. 2 bytes. Many devices have some value to read out at 0000.
0x0003
Number of consecutive registers to read from the first register. 2 bytes. This would read the registers #0, #1, and #2 in one command.
The default value of 0 0/5 * * * *:R,9600,8N1:010300000003 shows a very basic example with a single entry executed every 5 minutes using Modbus RTU to read 3 consecutive holding registers from a single slave device.
MbCmd = "<Entry1>;<Entry2>;...;<Entry32>"
Entry = "<Cron>:<MbParm>:<Command1>,<Command2>,...,<CommandN>"
MbParm = "<Protocol>,<Baud>,<SymbolCfg>"
Protocol = "R" for Modbus RTC, "A" for Modbus ASCII
Baud = Baud rate, any of: 2400, 4800, 9600, 19200, 38400, 57600, 115200
SymbolConfig = Token string defining Data Length, Parity, and Stop Bits. Any of: "7E1", "7E2", "8N1", "8N2"
Command = "<bytes to be sent in hex without checksum>"
Example A:
"0 0/5 * * * *:R,9600,8N1:010300000003"
Entry 1:
Cron: "0 0/5 * * * *": Execute entry every 5 minutes, on minutes 0, 5, 10, 15, ..., 55
Config: "R,9600,8N1": Use Modbus RTU on 9600 Baud, Datalength: 8, Parity: None, 1 stop bit
Commands:
"010300000003": Read 3 holding registers of Slave 1, starting at register 0
Example B:
"0 * * * * *:A,9600,7E1:0e0400100004,0f400100004;0 0 * * * *:A,9600,7E1:0e0400200020"
Entry 1:
Cron: "0 * * * * *": Execute entry every full minute
Config: "A,9600,7E1": Use Modbus ASCII on 9600 Baud, Datalength:7, Parity: Even, 1 stop bit
Commands:
"0e0400100004": Read 4 input registers of Slave 14, starting at register 16
"0f0400100004": Read 4 input registers of Slave 15, starting at register 16
Entry 2:
Cron: "0 0 * * * *": Execute entry every full hour
Config: "A,9600,7E1": Use Modbus ASCII on 9600 Baud, Datalength:7, Parity: Even, 1 stop bit
"0e040a800020": Read 32 input registers of Slave 14, starting at register 2688
Maximum registers / salves
The maximum amount of registers / slaves that can be setup is only limited by the available configuration memory, which is about 4 kB in total. In doubt try out a long MbCmd using the configuration adapter and see if it fits into the device. If not the device log would indicate it and the device enter a reset loop. If the config will be set remotely the previous config would be restored.
Wireless M-Bus related Parameters
Subject to change! Many feature of this device are still under development; wireless M-Bus support is still experimental. When updating firmware, check the changelog for breaking changes.
| Name | Description |
|---|---|
| wMbusCmd | List of wM-Bus collection entries with cron, mode, and duration. Multiple entries can be added, separated by ";". See below for examples. |
| mFilter | wMBus manufacturer filter sep. by "," e.g. "dme,itw" (Comma separated list WITHOUT spaces) |
| typFilter | wMBus device type filter e.g. 08,07 for Heat Cost and Water |
| devFilter | meter id filter e.g.
Up to 500 wMBus-IDs or 400 Sensus-RF-IDs are supported. |
| ciFilter | Collect only telegrams with specific values in the ci-Field, must we written as 2 hex digits (with leading zeros). (Comma separated list WITHOUT spaces, e.g.: "8a,07,71") |
| maxTelegrams | Set hard limit on how many telegrams will be collected and uploaded. The bridge will stop collection, once this number has been collected, regardless of the passed time. Can be used save battery / data volume, should the device be in an area with a large number of meters. Set to 0 for no limit. |
Example Commands
| wMbusCmd | Description |
|---|---|
| 0 0 12 * * *:C=180 | Each day at 12h UTC collect C/T-Mode for 180 seconds. |
| 0 0 5,17 * * *:X=100,U=120 | Each day at 5h and 17h UTC collect Sensus-RF for 100 seconds and Müller-Funk for 120 seconds. |
| 0 0 * * * *:C=120;0 0 10 * * *:S=120 | Collect C/T-Mode for 120 seconds every hour. Collect S-Mode every day at 10h UTC for 120 seconds. |
Wired M-Bus related Parameters
Subject to change! Many feature of this device are still under development; wired M-Bus support is still experimental. When updating firmware, check the changelog for breaking changes.
You need an M-Bus converter attached to the RS-485 connector of the Industrial Gateway to use wired M-Bus. Lobaro offers a complete solution including a converter under order number 8000200.
| Name | Description |
|---|---|
| MbusCmd | List of M-Bus reading entries with Cron, Baud rate and list of addresses. Multiple entries can be added, separated by ";". |
Entries
Entries in MbusCmd must be of the form "<cron>:<baud rate>:<address>,<address>,...". Primary and secondary (253/0xFD) addresses are supported.
Scanning
The Gateway supports scanning for primary addresses on the bus. This can be activated by using "*" instead of an address list. The Gateway will run a scan process once after booting. Scanning will take about 1 minute on Baud rate 2400. A special discovery message will be uploaded after booting that lists all discovered devices.
Examples
| MBusCmd | Explanation |
|---|---|
0 0 * * * *:2400:* | Run primary addresses discovery with 2400 Baud on boot. Readout discovered devices once every hour and upload telegrams. |
0 0/15 * * * *:4800:1,2,4,5 | Readout devices on primary addresses 1, 2, 4, and 5 with 4800 Baud every 15 minutes. |
0 0 * * * *:2400:12345678,87654321 | Readout devices on secondary addresses 12345678 and 87654321 with 2400 Baud every hour. |
0 0 12 1W * *:9600:*;0 0 * * * *:9600:1 | Two separate entries that will be executed using different Cron expressions (both use 9600 Baud for communication):
|