ModBus sensor

 

Declaration of conformity

---

Download the declaration of conformity.

Presentation

---

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 3.6V A-type battery. To use the external power supply, simply connect a compatible unit on the “Ext power” connector.

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

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

The ModBus sensor allows communication (via the LoRaWAN network) with any equipment that implements 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 an RS485 bus as the physical link. Moreover, the ModBus equipment must support at least one of the baud rates in the following list: 1200, 2400, 4800, 9600, 19200, 38400, 57600 or 115200 bit/s.

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

Family code:

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

User guide

Notice installateur FR

Installation and operation

---

The housing is intended to be installed inside or outside a building but it must be protected from vertical water spray 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 wires to the different signal or power terminals that will be used.

For the connectors, we recommend using several 20-26 AWG single wires. As the connectors pinch the wires plugged inside approximately 4mm from the wire end, strip the wires over a length of approximately 5 to 6mm before plugging them into the connectors.

The cable to be used for RS485 communication must have some features to allow the signals to be correctly transferred from the ModBus sensor to the ModBus equipment, especially when there is a long distance to cover.

Watteco recommends the cable type (with cable lugs to crimp) shown in the following page: https://fr.rs-online.com/web/p/cables-industriels-multipaires-torsades/3827000/ (BELDEN 3105A.00152)

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

Moreover, a terminating resistor for the RS485 bus is available on the ModBus sensor. By default, this resistor is enabled thanks to a jumper placed over the 2 contact pads. This resistor is not always needed to achieve good communication on the RS485 bus. The choice of enabling or disabling it is at the user's discretion. To enable it, leave the jumper on the pad. To disable it, remove the jumper.

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

The housing is compatible with the following DIN rail adapter:

Radio propagation

In order for the sensor to operate correctly, the number of obstacles should be limited in order to avoid excessive radio wave attenuation. It is also important to place the sensor as high as possible. The cable gland should be positioned downward.

Autonomy

---

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

More examples of ModBus sensor autonomy on its disposable battery are shown below.

Transmission periodicity	Number of ModBus registers reported	Battery life
10 minutes	2 or 3	2 years
30 minutes	2 or 3	7 years
1 hour	2 or 3	> 10 years
2 hours	2 or 3	> 15 years
24 hours	2 or 3	> 15 years

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

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

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 storage mode, a magnet must be placed near the reed switch for 1 second, until the device starts beeping regularly. The picture below shows where to place the magnet.

The table below describes the actions to be performed on the reed switch to disable or enable the storage mode.

Action	Magnet	Buzzer
Switch ON (disable storage mode)	1 second
Switch OFF (enable storage mode)	5 seconds

Class C

When the class C ModBus sensor is delivered, it is ready to operate. It simply needs to be powered using an external power supply. Once powered, the device starts immediately and tries to connect to the LoRaWAN network.

Association

Once the ModBus sensor starts, it tries to associate to a LoRaWAN network. During that time, it beeps regularly every 2 seconds.

Once the association is completed, the ModBus sensor beeps 4 times and then stops beeping.

The table below summarizes this.

Action	Magnet	Buzzer
Association in progress	-----
Association completed	-----

User commands

With the reed switch on the ModBus sensor and a magnet, several commands can be sent to the sensor. Below is the list of commands.

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

Standard reports are disabled in this mode.

Configuration mode
Way to trigger it	One 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
Duration	The configuration mode lasts 10 minutes

• Reassociation (class A and class C sensor) :

The ModBus sensor automatically executes a reassociation procedure if no downlink 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 acknowledgement received). However, a reassociation procedure can be requested by sending an applicative frame to the sensor or via the sensor’s IHM.

The sensor keeps the AppEUi and DevAddr configured, Confirmed/Unconfirmed configuration and all applicative configurations. However, LoRaWAN configurations (channel, data rate…) are lost.

ReAssociation Mode
Way to trigger it	Three 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 Watteco’s sensors. It deletes all the applicative settings saved in the flash memory (i.e. configured batches and reports will be deleted).

The sensor keeps the AppEUi and DevAddr configured. However, LoRaWAN configurations (channel, data rate…) and applicative configurations are lost.

Factory reset
Way to trigger it	Two 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

---

Codecs are available to decode frames: Downloads

In the ModBus sensor, the Serial Master/Slave Protocol implements 8 EndPoints (software version v3.5.0.4294.4338) or 10 EndPoints (from 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 configurations and different ModBus requests.

End Point	Cluster	Fctrl
0	Serial Master Slave Protocol	0x11
1	Serial Master Slave Protocol	0x31
2	Serial Master Slave Protocol	0x51
3	Serial Master Slave Protocol	0x71
4	Serial Master Slave Protocol	0x91
5	Serial Master Slave Protocol	0xB1
6	Serial Master Slave Protocol	0xD1
7	Serial Master Slave Protocol	0xF1
8 (from v3.5.0.4740)	Serial Master Slave Protocol	0x13
9 (from v3.5.0.4740)	Serial Master Slave Protocol	0x33

This number of Endpoints allows a wide variety of exchanges between Watteco’s ModBus sensor and the ModBus equipment.

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

Cluster	Cluster name	Managed attributes
0x0000	Basic	All
0x0050	Configuration	All
0x8004	LoRaWAN	All
0x8006	Serial Interface	All
0x8007	Serial Master/Slave protocol	All
0x8009 (from v3.5.0.4740)	Multi Master/Slave answers	All

Default configuration

Since the ModBus sensor 50-70-080 and 50-70-109 is a very open sensor that is compatible with wide range of equipment, there is no default report configuration on the “Serial Master/Slave Protocol” cluster.

For these reference the “Serial Interface” cluster, the default values for the attributes are as follows:

• Speed : 9600 bit/s
• Data bits : 8 bits
• Parity : None
• Stop bits : 1 bit

Every change made to the default configuration must comply with the legal duty cycle (for example, the most restrictive in the EU is 0.1%, which corresponds to approximately 1 frame per hour with SF12)

ModBus exchange 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 changes it to 1 minute. If the minimum value is more than 1 minute, the exchange periodicity depends on the minimum and maximum intervals in the report configuration.

If the minimum is set at 0 and the maximum at another value, then an exchange will be carried out every minute, and a report will be sent when the time reaches the maximum value (if delta is set to 0). If delta is set to 1, a first report will be sent after 1 minute. Afterwards, a report will be sent each time the answer from the ModBus equipment changes.

If the minimum is set at a value other than 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 and 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 port 125

Configuration of serial link parameters

• Situation: the ModBus equipment to which the ModBus sensor is connected uses 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 using the “Serial Interface” cluster. There is just one EndPoint for this cluster on the ModBus sensor, thus the EndPoint is 0, we will use the “Write attribute no response” command (0x05) and the cluster ID is 0x8006. Thus, the different payloads to be sent to the ModBus sensor to correctly configure the serial link (on the FPort 125) can be found below. It can be seen that the payload to change the stop bit is here. However, it is not necessary since 1 bit is its actual default value.

Speed change on the serial interface

 

Data bits change on the serial interface

 

Parity change on the serial interface

 

Stop bit change on the serial interface

 

Configure a ModBus request

• Situation: we want to save a ModBus request on the second EndPoint of the ModBus sensor. This request should allow 2 registers of the ModBus equipment to be read 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 2^nd EndPoint (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

For more details about the different ModBus commands, please refer 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 EndPoint 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 EndPoint (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

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 one go and with the same periodicity. It allows the duty cycle of the sensor to be optimised. 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 EndPoint (0x11) of the cluster “Multi Master/Slave Answers” (0x8009), on the Attribute “Present Value” (0x0000) with a periodicity of two hours. The cluster used is described in details here.

Configure a report on all the slave ModBus answers

Known Issues

---

• Modbus ClassC may stop periodic reports, on two fast successive DL "Direct exchanges" :
  • Version : All
  • Issue: The periodic reportings of configured Answers may stop when :
    • Two consecutive Modbus commands "Direct exchanges" are quickly send one after each other,
    • AND the modbus commands return the 0x81 code (modbus command without response (timeout)).
  • Workaround: Wait for the answer UL or at least 5seconds, before any new downlink modbus request from your application