Page History

...

Support for Modbus ASCII, RTU and TCP.

...

The Gateway can be used to communicate with Modbus Slave devices (ASCII/RTU /TCP) on a RS-485 bus, TCP on over Ethernet) over NB-IoT, LTE-CatM1, LoRaWAN or LAN. Modbus commands can be transmitted via Downlink message to the Gateway and are forwarded by the Bridge to the connected Slave Devices. Received responses are forwarded as Uplink messages to the Lobaro IoT Platform. The Modbus Gateway can also be configured to execute Modbus commands regularly and report the responses at time of execution.

The Modbus Gateway supports reading of all four object types that can be provided by Modbus slave devices: Coil, Discrete Input, Input Register, and Holding Register. It also supports writing values to all writable objects: Coils and Holding Registers. Multiple different slave devices on the Bus can be accessed individually by a single Gateway device, even if the slave devices have a different Modbus configuration. Reading intervals and register definitions can be configured very flexibly to suit individual requirements.

...

• Make sure the SIM card is inserted correctly when using NB-IoT or LTE-CatM1.
• Connect the Modbus Gateway to your Modbus Slave Devices
  • Via RS485 connector using a twisted pair cable: A to A, B to B, and GND to GND (GND is not strictly necessary but enhances the connection. Not all slave devices supply a GND connector).
  • Via ETH connector for Modbus TCP using a RJ45 LAN cable.
• Connect the Modbus Bridge to a computer using the Lobaro Configuration Adapter and the Lobaro Maintenance Tool.
• Connect power to the device - powering with the configuration adapter does not work.
• Make sure the configuration is correct to connect to the Internet (depends on you connection method: Mobile, LoRaWAN or LAN.
• Make sure the configuration is correct to read out your desired Modbus device (e.g. ASCII/RTU, Baud, Data Length, Stop Bits, Parity and Modbus Command).
• Optionally: Switch to the Log tab of the Lobaro Tool to see if the device is connecting and working as expected.
• Go to The Lobaro Platform and log into your account.
• Go to "Devices" and select your "Hybrid Modbus Gateway".
• If you have several Gateways: the "Address" is printed on the device's case as "DevEUI".
• You should see all uplinks Uplinks the Gateway collected so sent far. Next step is to configure your individual Device Type to display you slaves data or forward data to your own IT.

...

The Lobaro Modbus Gateway works with all devices that act as a Modbus Client using RTU, ASCII or TCP. (or, in a future release TCP). Some devices that have been used successfully with the Gateways are:

...

For a deeper introduction into Modbus please visit https://en.wikipedia.org/wiki/Modbus.

Setting up the device

Interfaces

Connections as on the label:

, which is a good place to start.

Setting up the device

Interfaces

Connections as on the label:

1. Vin - Supply voltage 12 - 24 Volt DC
2. GND - Ground
3. Vout - same as Vin
4. A - Modbus ASCII/RTU line
5. B - Modbus ASCII/RTU line
6. GND - Ground
7. ETH - Ethernet connection for LAN Uplink or Modbus TCP

• Connected cables must be between 0.05 mm² (AWG30) and 1.31 mm² (AWG16).
• Inserted cable length must be between 6mm and 7mm.
• Recommended wire termination: 
  • Weidmüller:  H0H0,14/10 GR SV, Article NrNo.:  90051800009005180000, 8mm/6mm, max. AWG26

Power Supply

• Power supply via external mains adapter with 12 - 24 Volt DC
• Power output must be at least 2W and maximum 100W.

...

RESET-Button

• Press the RESET Button to restart the deivcedevice
• The RESET Button can be pressed through a small hole in the cover (e.g. with a paper clip). The position is marked with a ring on the label.

...

• The config port can only be reached when the cover is removed
• The configuration port is compatible with our 6-pin Lobaro USB Configuration Adapter (Arcticle NrArticle No. 8000005).
• A free to use configuration tool can be downloaded from the Lobaro website. 

...

• Status information is visualized via the RGB LED

Mobile operator and LTE band configuration

...

The device is manufactured with a globaly 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.

...

When using ABP, the device will use the parameters DevEUI and AppKey for genrating 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 comming 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.

...

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 diffent different Modbus parameters to address incompatible Slaves on the same installation. Any Modbus command can be sent, including writing registers or diagnostic messages.

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 holdingregisters holding registers from a single slave device.

The parameter consists of up to 32 entries, separated by semicolons. Each entry consists of thre 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 Checksums check sums will be added my by the device according to the protocol used.

...

...

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 Lobaro tool over the config adapter, by sending a reboot command via downlinkDownlink, of if a fatal error occurs during opeartion 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 obious obvious errors (like invalid syntax or impossile 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 (normaly 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 Downlink reception from the Network, where an OTAA Join cannot be performed, but Uplink messages still might be comming 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.

...

The actions executed by the device during normal operation are controlled by a scheduler that executes a list of jons 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 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 Uplinks are generated faster than they can be sent, the queue will run full and new uplinks 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 Uplink sent, the device will look for downlinks comming 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.

...

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 conguration configuration fails to connect to the Network, the previous configuration is restored.

Mobile data consumption

Uploading one uplink Uplink with 400 bytes including all metadata (might be less, depending on the configuration).

...

Data messages differ between LoRaWAN and LTE/LAN upload. While LoRaWAN messages are defined by Port and Byte pattern, LTE/LAN Uplinks are encoded as structured data (CBOR).

Since LoRaWAN uplinks Uplinks are limited to ~50 Bytes some information that are avaliable available on other transport might be skipped.

...