Configuration
This page outlines all common configuration parameters of the firmware. Default settings are preconfigured to ensure a seamless initial operation experience. Gateways running add-on firmware use additional, add-on-specific configuration parameters alongside the configuration parameters listed below (see Add-Ons).
For larger orders, Lobaro can apply customer-specific configurations to all parameters prior to delivery.
Firmware Configuration Parameter
The configuration parameters described here are common to all products running this firmware. However, some products may include additional parameters or modify the parameters listed here, such as allowing additional values to be set. In all cases, the specific product's documentation takes precedence over this general description and should be reviewed carefully.
General Parameters
| Key | Type | Default | Description |
|---|---|---|---|
WAN | String | lte | Uplink channel selection |
listenCron | String | H H 10 * * * | Schedule for wireless M-Bus and radio listening periods |
LostReboot | Number | 3 | Days without connectivity before the device resets |
statusHour | Number | 0 | Hour when the device sends the status message |
TxDelay | String | 0s | Random delay before uplinks to reduce collisions |
WAN Parameter
This parameter selects the LPWAN technology used for backend communication. The device can use either cellular LTE (NB-IoT or LTE-M) or LoRaWAN.
lte: Uses cellular technologies, either NB-IoT or LTE-M.lorawan: Uses LoRaWAN with OTAA (Over-The-Air Activation).
- LoRaWAN uplinks and downlinks are limited to 52–222 bytes, depending on the data rate.
- Uplinks containing longer wM-Bus telegrams are split across multiple LoRaWAN messages.
- Uplinks with many wM-Bus telegrams may take significant time because of LoRaWAN duty-cycle limitations.
- Downlinks with large configuration values, such as long whitelists, must be split into multiple messages.
- Status telegrams include less information because uplink capacity is reduced.
- Remote firmware updates are not available.
listenCron Parameter
The listen cron defines when the device wakes up to receive data via enabled wireless M-Bus and other radio protocols. Each listening period is followed by data upload using the configured WAN technology.
The ideal interval depends mainly on the power supply (battery-powered vs. externally powered) and on how frequently the application needs new metering data. Typical intervals range from every 15 minutes to 14 days between readouts.
Learn more about CRON configuration parameters.
statusHour Parameter
Defines the hour of the day when the device sends its status message. The minutes and seconds are initially generated pseudo-randomly and remain fixed for the device afterwards.
- Values from
0to23define a fixed hour (UTC). Henables a pseudo-random hour selection.
When using H, the device randomly selects a fixed hour from 0 to 23, so different devices are evenly distributed over time.
TxDelay Parameter
TxDelay replaces the deprecated RndDelay parameter. While RndDelay was previously only available for LoRaWAN, TxDelay can be used for both LTE and LoRaWAN.
TxDelay introduces a randomized delay before data transmission to reduce network collisions.
Timing Behavior
Each program cycle is divided into four phases:
- t0: Time from wake-up until the end of wM-Bus data collection (influenced by parameters such as
cmodeDurSec,smodeDurSec,xmodeDurSec, andumodeDurSec) - TxDelay: Delay between the end of data collection and the start of transmission; during this time, the device enters deep sleep
- t1: Time between the end of
TxDelayand the actual data upload - t2: Time after data upload until the device returns to deep sleep again
Maximum Cycle Duration Constraint
The total cycle duration is limited to t0 + TxDelay + t1 + t2 ≤ 15 minutes.
If this limit is exceeded, TxDelay is automatically reduced, down to 0s if necessary, to keep the cycle within the allowed time window.
Randomization
TxDelay is calculated individually for each program cycle and varies randomly within the configured range. It supports fixed values as well as ranges:
- Fixed delay:
10s→ always 10 seconds5m→ always 5 minutes
- Randomized range:
10s-30s→ random value between 10 and 30 seconds5m-15m→ random value between 5 and 15 minutes
Supported suffixes:
s= secondsm= minutes
Wireless M-Bus Meter Reading
| Key | Type | Default | Description |
|---|---|---|---|
cmodeDurSec | Number | 300 | WMBUS C1/T1 listen duration in seconds |
smodeDurSec | Number | 0 | WMBUS S1 listen duration in seconds |
xmodeDurSec | Number | 0 | Sensus RF listen duration in seconds |
umodeDurSec | Number | 0 | Müller-Funk listen duration in seconds |
devFilter | String | [not set] | Filter list for device IDs |
typFilter | String | [not set] | Filter list for device types |
mFilter | String | [not set] | Filter list for manufacturer codes |
ciFilter | String | [not set] | Filter list for CI fields |
maxTelegrams | Number | 0 | Maximum number of telegrams to collect and upload |
rxTune | String | [not set] | Additional compatibility readout mode |
*modeDurSec Parameters
Parameters: cmodeDurSec, smodeDurSec, xmodeDurSec, umodeDurSec
The duration in seconds, for example 300 for 5 minutes, defines how long the device collects metering data for each corresponding wireless protocol. Each listening period is executed sequentially based on the configured durations. After all listening periods are complete, the collected meter telegrams are transmitted using the configured WAN technology.
The maximum configurable duration is 10 hours, which equals 36000 seconds.
Please note that such long listening periods will drain the battery very quickly. If in doubt, please consult Lobaro.
*Filter Parameters
Parameters: devFilter, ciFilter, mFilter, typFilter
Filters are applied to Wireless M-Bus-related fields to determine which telegrams are collected and uploaded. These filters include:
mFilter: Manufacturer filter for the 3-letter manufacturer code included in every telegram, for exampleLOBfor Lobaro GmbHtypFilter: Device type filter for the 2-digit hex code that defines the sender type, for example07for water metersdevFilter: Device filter for the mandatory 8-digit sender ID, for example87654321ciFilter: CI-field filter for the 2-digit hex code that describes the telegram purpose, for example8a
These filters help refine data collection to target specific devices or device types.
For a detailed explanation, read more about telegram filter parameterization.
Blacklist
Each filter parameter can be prefixed with an exclamation mark (!) to convert the whitelist into a blacklist.
This applies to the entire filter parameter, not to individual entries within the list. For example:
mFilter=LOBcollects only telegrams from Lobaro GmbH (whitelist)mFilter=!LOBexcludes telegrams from Lobaro GmbH (blacklist)
maxTelegrams Parameter
Sets a hard limit on the number of telegrams that are collected and uploaded. The firmware stops collecting once this limit is reached, regardless of the elapsed time.
This can help conserve battery life and data volume, especially in areas with a high density of meters.
When filtering for a single telegram, set the parameter to 1 so the device stops listening immediately after the desired telegram is received.
rxTune Parameter
Selects an additional compatibility readout mode. When set, the extra mode runs in addition to the standard T1/C1 readout.
| Value | Description |
|---|---|
axi | Axioma meter compatibility mode |
rxTune=axi — Axioma Compatibility Mode
When rxTune is set to axi, the device performs a second wM-Bus collection run after the standard C1/T1 run, using radio parameters tuned for Axioma Qualcosonic E3 and E4 meters. This enables reliable readout of these meters that are not detected in a standard C1/T1 scan.
Setting rxTune=axi implicitly doubles the total wM-Bus collection duration: the cmodeDurSec listening time is executed twice — once with standard parameters, once with Axioma-adapted parameters. Plan battery life and uplink intervals accordingly.
LTE Connection
| Key | Type | Default | Description |
|---|---|---|---|
Host | IP / URL | coaps://platform.lobaro.com | Lobaro Platform host endpoint |
Operator | Number | [not set] | LTE MCC+MNC code |
Band | Number | 3,8,20 | LTE band selection |
APN | String | LTE APN | |
PIN | Number | [not set] | LTE SIM PIN |
UseNbiot | Bool | true | Enable NB-IoT |
UseLtem | Bool | true | Enable LTE-M |
DNS | IP | 9.9.9.9,1.1.1.1 | DNS servers used by LTE |
UdpHost | IP | [not set] | Plain UDP upload target host |
UdpPort | Number | [not set] | Plain UDP upload target port |
Host
The Host parameter defines the backend server the device connects to. The format depends on the uplink protocol.
CoAP (Lobaro Platform)
| Mode | Value |
|---|---|
| Secure (DTLS) (recommended) | coaps://platform.lobaro.com |
| Unsecured | coap://platform.lobaro.com |
| Plain IP | 94.130.20.37 |
Syntax: coaps://host or coap://host
Multiple URLs as comma-separated fallback list: coaps://platform.lobaro.com,coap://platform.lobaro.com
🔍 Details on CoAP Interface
- CoAP uses CBOR as data format.
- The protocol is designed exclusively for the Lobaro Platform and is not a stable public API.
- For third-party integration, MQTT is the officially supported path.
- Plain
coap://should only be used if object-level security is in place.
MQTT (third-party or Lobaro Platform)
| Mode | Example |
|---|---|
| Lobaro Platform, secure (recommended) | mqtts://platform.lobaro.com |
| Custom broker, cert-based auth | mqtts://example.com |
| Custom broker, no client cert | mqtts://example.com?cert=0 |
| Custom broker, JSON format | json+mqtts://example.com?cert=0 |
Syntax: [format+]protocol://[user[:password]@]host[:port][/topic-prefix/][?arguments]
🔍 Details on MQTT Interface
- Authentication: Certificate-based (MQTTS) is strongly recommended — username/password is discouraged.
- Format: Default is CBOR. Use
json+prefix for JSON. - Network: MQTT requires LTE-M — NB-IoT is automatically disabled when MQTT is configured.
→ Full syntax and generator: MQTT → Host Parameter
LTE Parameters
Parameters: APN, Operator, Band, PIN
These basic parameters configure the NB-IoT or LTE-M connection. They must match the SIM card and network provider in use.
APN — Always set the APN explicitly. While the LTE-M / NB-IoT specification allows an empty APN, some providers such as 1NCE require it. Do not use * with 1NCE SIM cards: newer firmware versions no longer auto-detect to iot.1nce.net but will set no APN at all.
⚠️ 1NCE SIM cards — check your platform version
1NCE operates two platforms with different APNs:
- Platform V1 (existing customers): APN
iot.1nce.net - Platform V2 (new customers since Oct 2025): APN
sensor.net
Using * will attempt auto-detection, which previously defaulted to iot.1nce.net. In newer firmware versions, auto-detection no longer sets any APN at all for 1NCE — always set the APN explicitly to match your 1NCE platform version.
Operator, Band, PIN — These parameters do not need to be set in normal operation. The modem automatically selects the correct operator and band based on the SIM card. Locking to a specific operator or band can actually prevent the device from connecting in some cases and is generally not recommended. Only set these if explicitly required for your deployment.
Read more about LTE network configuration parameters.
UseNbiot and UseLtem
The modem supports both NB-IoT and LTE-M technologies. By default, both are enabled so the modem can automatically choose the most suitable network type for the location.
To force one technology, set one parameter to false while keeping the other set to true. At least one technology must always remain enabled.
UdpHost and UdpPort
This feature is deprecated and not recommended for production use. Lobaro provides limited support for errors caused by using raw UDP upload.
Instead of sending metering data to the Lobaro IoT Platform, the data can alternatively be sent to an external UDP socket. This is useful if you prefer to keep metering data off external servers while still using the Lobaro Platform to control your gateways.
UdpHost: IP address for uploading plain telegrams via UDP[not set]: Upload data to the Lobaro IoT Platform using the configuredHostparameterUdpPort: Port number for uploading plain telegrams via UDPUdpPortis only used ifUdpHostis set
Even when metering data is sent to an external server, the firmware usually still requires a connection to a Lobaro Platform instance to send status information, perform remote configuration, or handle firmware updates.
For solutions that allow all communication without the Lobaro Platform, such as direct MQTT to an external broker, contact Lobaro for possible options.
LoRaWAN Connection
| Key | Type | Default | Description |
|---|---|---|---|
DevEUI | byte[8] | Device EUI64 | Device EUI |
AppEUI / JoinEUI | byte[8] | random | Application EUI or JoinEUI for LoRaWAN 1.1 |
AppKey | byte[16] | random | Application key |
NwkKey | byte[16] | 00000000000000000000000000000000 | Network key for LoRaWAN 1.1 |
TimeSync | Number | 3 | Days between time synchronizations |
PayloadFormat | Number | 0 | Encoding of the wM-Bus LoRaWAN uplink payload |
OTAA | Bool | true | Enable OTAA |
RndDelay | Number | 10 | Random transmit delay in seconds |
SF | Number | 12 | Spreading factor |
TxPower | Number | 14 | Transmission power |
ADR | Bool | true | Adaptive data rate |
loraPLMax | Number | 100 | Maximum LoRaWAN payload length for Modbus uplinks |
LoRaWAN 1.1 is experimental and not certified. For production environments, we recommend using LoRaWAN 1.0.2.
Depending on the selected configuration, some parameters may not be available.
NwkKey Parameter
The network key (NwkKey) is used for LoRaWAN 1.1. If it is set to all zeros (00000000000000000000000000000000) or to the same value as AppKey, the device stays on LoRaWAN 1.0.2, which is the recommended mode of operation.
PayloadFormat Parameter
Defines the encoding of the wM-Bus LoRaWAN uplink payload.
0= Encoding in ports with static message length (max. 50 bytes per uplink)1= Prefix bytes and timestamp2= Prefix bytes, timestamp, and RSSI
For payload formats 1 and 2, the gateway automatically uses the maximum available payload size depending on network conditions, for example the spreading factor.
loraPLMax Parameter
Maximum payload size in bytes for LoRaWAN uplink packets.
This parameter is only relevant for Modbus-related functionality and is not used for Wireless M-Bus (wM-Bus) data transmission.
For wM-Bus communication, the payload size behavior is defined by the selected PayloadFormat.
Changing loraPLMax has no effect on LoRaWAN transmission in wM-Bus applications.
For a detailed specification of the payload formats, please refer to the LoRaWAN Communication page.
Special
| Key | Type | Default | Description |
|---|---|---|---|
verbose | Bool | false | Enable verbose UART logging |
extRam | String | [not set] | Add-on RAM configuration |
liveMode | String | [not set] | Configure live mode behavior |
opMode | Number | 1 | Internal operation mode |
liveMode Parameter
An empty string disables live mode.
suppression=<seconds> enables live mode with suppression of duplicate telegrams for the specified number of seconds.