Modes of Operation

warning

Subject to change! This product is still very young and experience might lead to adjustments in the future.

This chapter explains how the device starts and works to collect and upload data.

Startup process

The starting process of the device is linear and executed the following steps in the order given here. The startup is triggered on power on or after a reset was triggered; this can happen over the reset button, by using the Lobaro tool over the config adapter, by sending a reboot command via Downlink, of if a fatal error occurs during operation of the device.

• On power on (or after a reset), the device will start by verifying the signature of the installed firmware. It will only continue the boot process if the signature is valid.
• The device will then activate the Arm TrustZone of its central processor, to prepare an isolated environment for the actual firmware to run. This activates hardware security mechanisms that protect the device from a wide range of errors and manipulations while it is running.
• Only then, the application program is started, having restricted access to the hardware.
• The application reads and outputs the configuration parameters programmed into it and verifies the configuration does not contain any obvious errors (like invalid syntax or impossible value combinations). If any fatal errors exist, the device will output information about it in the Log and then reboot, so that you spot invalid configurations directly when you set them.
• At this point the RGB-LED starts to continuously output the state of the Modbus connection and the connection to the backend.
• The device will try and execute every Modbus command from every entry in the configuration parameter MbCmd, using the Modbus configuration of the entry (writing operations are skipped to avoid side effects). This allows you to check your Modbus configuration and the connection to the slave devices early on boot and even without a config adapter attached. The device will continue execution, even if the Modbus Commands fail, so that you can check the connection to the backend even when not connected to the Modbus slaves.
• After testing Modbus, the device will try to connect to the network for connection to the backend. The exact action will depend on your configuration:
• For NB-IoT or LTE-M the Gateway will activate its Modem and try to attach to the mobile provider. If that succeeds, it will try to connect to the backend configured (normally an instance of the Lobaro Platform). If that succeeds, the device will upload some information about itself to the backend (including its configuration) and than synchronise its internal clock over the connection. Only if all this succeeds, the device will move on.
• For LoRaWAN with OTAA, the device will perform an OTAA Join operation with the LoRaWAN Network Server. If that succeeds, the device will upload a Status Message that will also be used to synchronise its internal clock with the network. Only if that succeeds, the device will move on. On failure, the device will retry with increasing timeouts to perform the join operation and time sync, until it succeeds.
• For LoRaWAN with ABP there is no explicit joining operation, as the session must already exist between Network Server and Device. It simply uploads a Status Message that will also be used to synchronise the internal clock. If the synching fails multiple times, the device will skip synchronisation and just move on to start normal operations. Be aware that this can lead to the Device operating with a clock that does not match real time. The Modbus Commands will be executed according to that clock, which will most likely not be consistent with what you expect. This exception is introduced on purpose, as ABP is meant to make the device usable in locations, where there is poor Downlink reception from the Network, where an OTAA Join cannot be performed, but Uplink messages still might be coming through to the Network. The device will continue to try and synchronise its clock every day and might succeed at some point in the future. The changing of the clock will be compensated as well as possible, but the exact times when commands are executed is most likely to change at that point.
• When the connection to the backend has been established (this is not certain to have succeeded when using LoRaWAN ABP), the device will start its internal scheduler and will from this moment on be running in normal operation mode.

Normal operation

The actions executed by the device during normal operation are controlled by a scheduler that executes a list of jobs whenever it is their time to run. Only a single job will be executed at any time, so if a job is running for some time, other jobs will be executed delayed (but the execution will not be skipped). Each entry you add to the MbCmd config parameter will have its own job in the scheduler. The Cron Expression of the entry will control, how often and when the job will be executed. In addition to that there will be a Status job which runs once every day and triggers the upload of a status message which will also perform a clock synchronisation. When your configuration has multiple entries that are scheduled for the same time, they will be executed in the order you put them in the configuration.

The jobs will generate Uplink messages that need to be uploaded. Those will be queued and upload in the order they are generated. The device will continue to execute jobs while handling uploads. When Uplinks are generated faster than they can be sent, the queue will run full and new Uplinks will be dropped silently. This is most likely to happen when using LoRaWAN on higher spreading factors, as the Gateway can read data over Modbus much faster than it can be sent over LoRaWAN.

After each Uplink sent, the device will look for Downlinks coming from the Network (this is done for both, LoRaWAN and LTE configurations). Downlinks can contain remote commands controlling the device (like configuration changes, reboot requests, or (for LTE only) remote firmware updates). There can also be Modbus commands sent via Downlink that will be executed on the bus by the Gateway directly (the response from the slave will be sent as Uplink). Downlink Modbus commands are currently only supported for LoRaWAN.

The daily Status message Uplink makes sure that the device can be reached for remote configuration within 24 hours, independent of the current configuration.

Changing configuration or performing a firmware update will result in the Gateway rebooting. We try our best to keep our devices from ever reaching a state that makes them unreachable. A new configuration set via Downlink will be temporary until a connection to the Network can be established again. If the new configuration fails to connect to the Network, the previous configuration is restored.

LED patterns

DIN-Rail Variant

The DIN-Rail Hybrid Modbus Gateway has an RGB LED that can be seen with closed or open box. It signals the state of the device.

• special patterns:
• constant MAGENTA: Device is in Bootloader Mode (not actively running, remove config adapter and press reset to leave Bootloader Mode).
• GREEN on for ~2 s and off again: Device just booted, either after power on, reset b button or software, or after a hard failure.
• CYAN flashes on and off once a second: Device is is Dialog Mode. To leave the Dialog Mode, change the configuration using the config adapter.

During normal operation (when the device finished booting and is not running any special modes), the device will continuously flash its LED twice, each flash giving a different piece of information:

• The first flash indicates the state of the connected sensors/Modbus slaves. This state is first set when the device tests all Modbus commands after boot. It will be updated during operations whenever Modbus commands are executed.
• BLUE: State of the sensors has not been determined. This is the state after booting, while the device is trying to execute all Modbus commands in its configuration.
• GREEN: All Modbus commands from config have been executed successfully.
• RED: None of the Modbus commands could where successful. There is most likely a problem in the connection (wires) or in the configuration.
• YELLOW: At least one Modbus command has been successful, but at least one Modbus command failed. Will only happen when multiple Modbus commands and/or entries are present in MbCmd. This can happen though a miss-configuration, when one of multiple slaves could not be reached, or if only one entry has failed and one succeeded - maybe they are executed during different times and the disruption only lasted for a short while.
• The second flash indicates the state of the connection to the backend. This can be a connection to the Lobaro Platform via NB-IoT/LTE-M or Ethernet, or a LoRaWAN connection to a Network Server. -BLUE: State of connection has not been determined, yet. This is the situation after boot, when the device has not yet finished connecting. -GREEN: Connection to the Platform/Network Server has been established successfully.

Battery Variant

Since v0.8.5: The Battery Hybrid Modbus Gateway has three separate LEDs, Blue, Green, and Red (left to right) in a square labeled "STATUS" 🔵🟢🔴. The patterns look different from the DIN-Rail variant, as the colours are not combined:

• special patterns:
• 🔵⚪🔴 constant BLUE and RED: Device is in Bootloader Mode (not actively running, remove config adapter and press reset to leave Bootloader Mode).
• ⚪🟢⚪ GREEN on for ~2 s and off again: Device just booted, either after power on, reset b button or software, or after a hard failure.
• 🔵🟢⚪ BLUE and GREEN flashes on and off once a second: Device is is Dialog Mode. To leave the Dialog Mode, change the configuration using the config adapter. During normal operation (when the device finished booting and is not running any special modes), the device will continuously flash its LEDs twice, each flash giving a different piece of information. The information is repeated every second for the first 15 minutes. After 15 minutes, the interval is changed to only give the information once per minute, to save battery power.
• The first flash indicates the state of the connected sensors/Modbus slaves. This state is first set when the device tests all Modbus commands after boot. It will be updated during operations whenever Modbus commands are executed.
• 🔵⚪⚪ BLUE: State of the sensors has not been determined. This is the state after booting, while the device is trying to execute all Modbus commands in its configuration.
• ⚪🟢⚪ GREEN: All Modbus commands from config have been executed successfully.
• ⚪⚪🔴 RED: None of the Modbus commands could where successful. There is most likely a problem in the connection (wires) or in the configuration.
• ⚪🟢🔴 RED and GREEN: At least one Modbus command has been successful, but at least one Modbus command failed. Will only happen when multiple Modbus commands and/or entries are present in MbCmd. This can happen though a miss-configuration, when one of multiple slaves could not be reached, or if only one entry has failed and one succeeded - maybe they are executed during different times and the disruption only lasted for a short while.
• The second flash indicates the state of the connection to the backend. This can be a connection to the Lobaro Platform via NB-IoT/LTE-M or Ethernet, or a LoRaWAN connection to a Network Server.
• 🔵⚪⚪ BLUE: State of connection has not been determined, yet. This is the situation after boot, when the device has not yet finished connecting.
• ⚪🟢⚪ GREEN: Connection to the Platform/Network Server has been established successfully.