ModBus sensor

Declaration of conformity

Download the declaration of conformity.


The ModBus sensor can either be a LoRaWAN class A sensor (50-70-080) or a LoRaWAN class C sensor (50-70-109).

The class A sensor manages two different power supplies, one is external and may range from 9 to 24V, the other one is internal on a disposable A 3.6V battery. To use the external power supply, just connect a compatible one on the “Ext power” connector.

The class C sensor only manages the external power supply which ranges from 9 to 24V.

The ModBus sensor integrates all the connections needed for a RS485 bus: A, B and GND. It also includes an internal antenna.


The ModBus sensor allows to communicate (throught the LoRaWAN network) with any equipment implementing the ModBus protocol as slave. Thus, it works as a ModBus master.

The ModBus equipment to communicate with, must use the RTU coding type and a RS485 bus as the physical link. Moreover, the ModBus equipment must support at least one of the baudrates in the following list: 1200, 2400, 4800, 9600, 19200, 38400, 57600 or 115200 bit/s.

If these prerequisites are fulfilled, the nke Watteco ModBus sensor is compatible with the equipment, and thus, can correctly communicate with it to get or set any modbus registers presents inside the equipment. So, the ModBus equipment is now LoRaWAN ready thanks to the sensor.

Family code:

The family code of the ModBus sensor is: 50-70-080 (class A) or 50-70-109 (class C)

Installation and use

The housing is intended to be installed inside or outside a building but to the shelter of a vertical splash water and direct sunlight.

The product is delivered disassembled. This enables the connection to the screw terminals.

Before connecting your cable strands to the product’s screw terminals, you must insert the cable gland’s nut and the seal.


Then connect the wire on the different signals or power that will be used.


For connectors, it is preferable to use several single wires with a gauge of 20-26 AWG. As the connectors pluck the wires plugged inside at about 4mm of the wire-end, strip the wires on about 5 to 6 mm of their extremity before plugging them into the connectors.

The cable to use for the RS485 communication must have some features allowing to correctly bring the signals from the ModBus sensor to the ModBus equipment. Especially when there is a long distance to cover.

Nke Watteco recommends this kind of cable (with cable lugs to crimp) : (BELDEN 3105A.00152)

The RS485 bus signals must be connected with the correspondant signals on the ModBus equipment side. The Ground signal of the RS485 is generally connected to the shielding braid on both sides.

Moreover, a termination resistor for the RS485 bus is available on the ModBus sensor. By default, this resistor is enabled thanks to a jumper put on the 2 plots connector. This resistor is not always needed to have a correct communication on the RS485 bus. It is at the user discretion to enable or disable it. To enable it, let the jumper on the connector. To disable it remove the jumper.

Once the assembly is done, the casing can be closed.

The housing is compatible with the following DIN rail adapter:


For more information about the casing, visit:

Propagation radio

In order for the sensor to work correctly, it is better to limit the number of obstacles to avoid excessive attenuation of the radio wave, it is also important to put the sensor as high as possible. The cable gland should be positioned downward.



When powered by its internal disposable battery 3.6V/3.6Ah, the class A ModBus sensor autonomy is higher than 10 years for a report of 4 bytes (2 ModBus registers) in SF12 every 1 hour.

More examples of ModBus sensor autonomy on its disposable battery can be found here below.

Transmission periodicityNumber of ModBus registers reportedBattery life
10 minutes2 or 32 years
30 minutes2 or 37 years
1 hour2 or 3> 10 years
2 hours2 or 3> 15 years
24 hours2 or 3> 15 years

N.B.: The autonomy times here above are given for an end-device in SF12 in unconfirmed mode.

N.B. 2: As the class C device is only powered by an external power supply, it has no limitation in autonomy.

Human Machine Interface

Starting the  ModBus Sensor

Class A

When the class A ModBus sensor is delivered, the sensor is in storage mode.

To get the end-device out of the storage mode, a magnet must be placed near the reed switch for 1 second, until the device starts to beep regularly. An illustration showing where to put the magnet can be seen here below.



Here below can be seen the tab containing the action to do on the reed switch to get out or get in the storage mode.

Swicth ON
(get out from storage mode)
1 second
Swicth OFF
(get in storage mode)
5 seconds

Class C

When the class C ModBus sensor is delivered, it is ready for use. The only thing to do is to power it, thanks to an external power supply. Once powered, the device starts immediately and try to join the LoRaWAN network.


Once the ModBus sensor started, it tries to associates itself to a LoRaWAN network. During this time it beeps regularly every 2 seconds.

At the moment of the association, the ModBus sensor beeps 4 time and then stops beeping.

Here below can be seen a tab summarizing this.

Trying association-----
Association success-----

User commands

With the reed switch on the ModBus sensor and a magnet, several commands can be sent to the sensor. Here below, a list.

  • Configuration mode (only for class A sensor) : « void » frames are sent every minute during 10 minutes.

Standard reports are not functioning during this mode.

Configuration mode
Way to trigger itOne passage of the magnet near the reed switch or specific ZCL command
Way to stop it Another passage of the magnet or specific ZCL command
Effects on the sensor
Time durationThe configuration mode lasts 10 minutes
  • Re-association (class A and class C sensor) :

By itself, the ModBus sensor does a reassociation if no down frame is received by the sensor during a given periodicity (4 days by default) or if a given number of confirmed frames (100 by default) are considered as failure (no acquittement is received). However, it is also possible to ask a re-association by sending an applicative frame to the sensor or by the IHM of the sensor.

The sensor keeps the AppEUi and DevAddr configured, Confirmed/Unconfirmed configuration and all applicative configurations. On the other hand, LoRaWAN configuration (channel, datarate …) are lost.

ReAssociation Mode
Way to trigger itThree passages of the magnet near the reed switch or ZCL command from LoRaWAN cluster.
Effects on the sensor
  • Factory reset (class A and class C sensor) :

A factory reset is available on nke Watteco’s sensors. It deletes all the applicative settings saved in the flash memory (i.e.: the configured batches and reports will be deleted).

The sensor keeps the AppEUi and DevAddr configured. On the other hand, LoRaWAN configurations (channel, datarate …) and applicative configurations are lost.

Factory reset
Way to trigger itTwo quick passages and a very long passage (until the sensor rings for the reset) of the magnet near the reed switch
Effects on the sensor

Applicative layer

Codec are available to decode frame: Downloads

In the ModBus sensor, the Serial Master/Slave Protocol implement 8 EndPoints (software version v3.5.0.4294.4338) or 10 EndPoints (software version v3.5.0.4740). That means that up to 8 (or 10) requests can be managed by the ModBus sensor, thus up to 8 (or 10) reports with different configuration and different ModBus request.

End PointCluster Fctrl
0Serial Master Slave Protocol0x11
1Serial Master Slave Protocol0x31
2Serial Master Slave Protocol0x51
3Serial Master Slave Protocol0x71
4Serial Master Slave Protocol0x91
5Serial Master Slave Protocol0xB1
6Serial Master Slave Protocol0xD1
7Serial Master Slave Protocol0xF1
8 (uniquely v3.5.0.4740)Serial Master Slave Protocol0x13
9 (uniquely v3.5.0.4740)Serial Master Slave Protocol0x33

This number of Endpoints allow a big diversity in the exchanges between the nke Watteco’s ModBus sensor and the ModBus equipment.

Furthermore, the ModBus sensors (class A or class C) integrate the following clusters.

ClusterCluster name Managed attributes
0x0000 BasicAll
0x8006Serial InterfaceAll
0x8007Serial Master/Slave protocolAll
0x8009 (uniquely v3.5.0.4740)Multi Master/Slave answersAll

Default configuration

The ModBus sensor being a very open sensor and as it is compatible with a lot of different equipment, there is no default report configuration on the “Serial Master/Slave Protocol” cluster.

For the “Serial Interface” cluster, the default values for the attributes are the following:

  • Speed : 9600 bit/s
  • DataBits : 8 bits
  • Parity : None
  • StopBits : 1 bit

Every change on the default configuration must respect the legal duty cycle. (For example the most restrictive in EU is 0.1%, so in SF12 it is around 1 frame each hour)

ModBus exchanges periodicity

The minimum ModBus exchange periodicity available is 1 minute. If in the configuration of the report, the minimum value is set under 1 minute, the sensor put it to 1 minute. If the minimum value is more than 1 minute, the exchange periodicity depends on the minimum and the maximum interval in the report configuration.

If the minimum is set at 0 and the maximum at another value, then an exchange will be done every minute, and a report will be sent when the time reach the maximum value (if the delta is set at 0). If the delta is set at 1, a first report will be sent after 1 minute, afterwards, a report will be send each time that the answer from the ModBus equipment changed.

If the minimum is set at a value different from 0 and above 1 minute, then this value is the periodicity used by the sensor to send the request to the ModBus equipment.

Finally, if the maximum value and the minimum values are under 1 minute, the report will be sent every maximum period, but the ModBus answer sent on the LoRaWAN network will only be updated every minute.

Frame examples

All frames have to be sent on the port 125

Configure the serial link parameters

  • Situation : The ModBus equipment on which the ModBus sensor is connected, use the following parameters on the serial link:
    • Speed: 19200 bit/s
    • Data Bits: 7 bits
    • Parity: Even
    • Stop Bits : 1 bit
  • Solution : The solution is to configure all the serial link parameters thanks to the “Serial Interface” cluster. There is just one end-point for this cluster on the ModBus sensor, thus the End-Point is 0, we will used the “Write attribute no response” command (0x05) and the cluster ID is 0x8006. Thus, here below can be found the different payloads to send to the ModBus sensor to correctly configure the serial link (on the FPort 125). It can be seen that the payload to change the stop bit is here. Nevertheless in reality it is not necessary since 1 bit it’s its default value.

Speed change on the serial interface

→ Applicative payload is: 11 05 8006 0000 22 004B00

0000 : Attribute ID (0x0000 -> Speed)

22 : Attribute Type (0x22 -> UINT24_TYPE)

004B00 : New value for the attribute (0x004B00 -> 19200 bits/s) 


Data bits change on the serial interface

→ Applicative payload is: 11 05 8006 0001 20 07

0001 : Attribute ID (0x0001 -> DataBits)

20 : Attribute Type (0x20 -> UINT8_TYPE)

07 : New value for the attribute (0x07 -> 7 bits) 


Parity change on the serial interface

→ Applicative payload is: 11 05 8006 0002 20 02

0002 : Attribute ID (0x0002 -> Parity)

20 : Attribute Type (0x20 -> UINT8_TYPE)

02 : New value for the attribute (0x02 -> Even parity) 


Stop bit change on the serial interface

→ Applicative payload is: 11 05 8006 0003 20 01

0001 : Attribute ID (0x0003 -> StopBits)

20 : Attribute Type (0x20 -> UINT8_TYPE)

01 : New value for the attribute (0x01 -> 1 bit) 


Configure a ModBus request

  • Situation : We want to save a ModBus request on the second End-point of the ModBus sensor. This request should allow to read 2 registers of the ModBus equipment from the address 0x140. The ModBus address of the equipment (thus, the ModBus slave address) is 0x23.
  • Solution : The solution is to configure the request (Attribute ID: 0x0000) to use on the 2nd End-Point (0x31) thanks to the command “Write Attribute No Response” (0x05), in the cluster “Serial Master/Slave Protocol” (0x8007)

Save a ModBus request on EndPoint 2

→ Applicative payload is: 31 05 8007 0000 41 06 230301400002

0000 : Attribute ID (0x0000 -> Request)

41 : Attribute Type (0x41 -> BYTES_STRING)

06: Bytes string size (0x06 -> 6 bytes) 

230301400002 : ModBus Request (without CRC) :

ModBus Slave Address : 0x23

ModBus Command : 0x03 (Read Holding Registers)

ModBus register address : 0x0140

Number of registers to read : 0x0002

For more details about the differents ModBus command, please refers to the ModBus Application Protocol Specification, available on the official ModBus website:

Configure a report on the ModBus answer

  • Situation : Now that the request on the second End-Point has been correctly saved (see paragraph above), we want to report the answer of the ModBus slave to this request every 1 hour. In other words, we want to have the content of the 0x0140 and 0x0141 ModBus register every 1 hour.
  • Solution : The solution is to configure a report with the command “Configure reporting” (0x06), on the second End-Point (0x31) of the cluster “Serial Master/Slave Protocol” (0x8007), on the Attribute “Answer” (0x0001) with a periodicity of one hour.

Configure a report on the slave answer of EndPoint 2

→ Applicative payload is: 31 06 8007 00 0001 41 803C 803C 01 00

0001 : Attribute ID (0x0001 -> Answer)

41 : Attribute Type (0x41 -> BYTES_STRING)

803C: Minimum reporting interval (0x803C -> 60 minutes or 1 hour) 

803C: Maximum reporting interval (0x803C -> 60 minutes or 1 hour) 

00 : Reportable change (0x00 : a change in the ModBus answer do not trig a report to be sent )

Configure a report on all the ModBus answers

  • Situation : Let’s imagine that several ModBus requests have been saved on the ModBus sensor. And now the user wants to get all the ModBus answers from the requests, in once and with the same periodicity. It allows to optimise the duty-cyle of the sensor. The user wants to have all these answers every 2 hours.
  • Solution : The solution is to configure a report with the command “Configure reporting” (0x06), on the first End-Point (0x11) of the cluster “Multi Master/Slave Answers” (0x8009), on the Attribute “Present Value” (0x0000) with a periodicity of two hour. The cluster used is described in details here.

Configure a report on all the slave ModBus answers

→ Applicative payload is: 11 06 8009 00 0000 41 8078 8078 01 00

0000 : Attribute ID (0x0000 -> Present value)

41 : Attribute Type (0x41 -> BYTES_STRING)

8078: Minimum reporting interval (0x8078 -> 120 minutes or 2 hours) 

8078: Maximum reporting interval (0x8078 -> 120 minutes or 2 hours) 

00 : Reportable change always disable for this cluster

Print Friendly