ModBus sensor

Declaration of conformity


Download the declaration of conformity.

Presentation


The ModBus sensor is a LoRaWAN class A sensor. It 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 ModBus sensor integrates all the connections needed for a RS485 bus: A, B and GND. It also includes an internal antenna.

modbus_nke

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-xxx

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.

cable-gland2

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

modbus_rs485

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) : https://fr.rs-online.com/web/p/cables-industriels-multipaires-torsades/3827000/ (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:

din

For more information about the casing, visit: www.spelsberg.com

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 positionned downward.

propagation-radio-pulse

Autonomy


When powered by its internal disposable battery 3.6V/3.6Ah, the 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.

Human Machine Interface


Starting the  ModBus Sensor

When the ModBus sensor is delivered, its On/Off switch is put on “On” and 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.

 

modbus_nke_magnet

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.

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

Association

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.

Action
Magnet
Buzzer
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 : « 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 :

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 :

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. That means that up to 8 requests can be managed by the ModBus sensor, thus up to 8 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

These 8 Endpoints allow a big diversity in the exchanges between the nke Watteco’s ModBus sensor and the ModBus equipment.

The ModBus device is a sleepy Class A device. It integrates the following clusters.

ClusterCluster name Managed attributes
0x0000 BasicAll
0x0050ConfigurationAll
0x8004LoRaWANAll
0x8006Serial InterfaceAll
0x8007Serial Master/Slave protocolAll

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


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: http://www.modbus.org/docs/Modbus_Application_Protocol_V1_1b.pdf

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 )

Print Friendly