Modbus TCP Master MQTT Gateway

Summary

In this guide, Modbus TCP master MQTT Gateway function will be configured with two different types of MQTT Brokers. First using third-party MQTT Broker services (in this example Flespi.io). Second, using the RUT240 router as MQTT Broker. Two routers will be used as Modbus TCP Master and Slave, and the PC acts as MQTT Publisher and Subscriber.

Configuration overview & prerequisites

• Two routers - RUT1 as Modbus TCP Server (Slave) and RUT2 as Modbus TCP Client (Master)
• Flespi.io account to act as an MQTT Broker/Publisher/Subscriber (for first configuration example)
• RUT241 with a Public IP address to act as MQTT Broker (for second configuration example)
• An end device (PC, Laptop) to act as MQTT Subscriber/Publisher (for second configuration example)

Configuration using flespi.io as MQTT Broker

Configuring Modbus TCP Server

---

Open RUT1 router's WebUI and navigate to Services → Modbus → Modbus TCP Server

1. Check Enable
2. Enter port that will be used, in this example 502 will be used
3. Enter device ID
4. Press

*In this configuration LAN port is used hence “Allow Remote Access” is not needed

Modbus TCP Server is now configured.

Configuring Modbus TCP Client

---

Open RUT2 router's WebUI and navigate to Services → Modbus → Modbus TCP Client

1. Press

2. Check Enable
3. Enter the name for the Server device
4. Server ID must match with the previously configured Modbus TCP Server device ID
5. Enter the IP address of the Modbus TCP Server device
6. Chose same Port as in Server device - 502
7. Enter Period in seconds, how often requests will be sent to the Server device

8. Enter new request name and press in Requests configurations

9. Choose "Data type" - ASCII, "Function" - Read holding resgiter (3), enter "First register number" - 72 and "Register count/Values" - 3 You can name each individual configuration, and then select enable on configurations that you want to use. In this example, register to get Routers name is used.
10. Press the "Test" button in Request Configuration Testing to see if the Slave device responds to requests, a response similar to the image below should be shown.

11. Press to save the configuration

List of available Modbus parameters can be found [here]

Configuring Flespi.io MQTT Broker

---

Log in or create an account on https://flespi.io

Once logged in:

1. Navigate to MQTT Board on the left side of the screen and press it.
2. On the right-hand panel, top right corner, next to the name of the MQTT board, press the cogwheel-looking icon to open Connection Settings
3. In the opened window, press "Get flespi token" to generate a username
4. Enter Client name
5. Copy Host address
6. Copy Username
7. Create a password
8. Press Save

Configuring Flespi.io MQTT Broker

---

Log in or create an account on https://flespi.io

Once logged in:

1. Navigate to MQTT Board on the left side of the screen and press it.
2. On the right-hand panel, top right corner, next to the name of the MQTT board, press the cogwheel-looking icon to open Connection Settings
3. In the opened window, press "Get flespi token" to generate a username
4. Enter Client name
5. Copy Host address
6. Copy Username
7. Create a password
8. Press Save

• 
• 
• 
• 

Configuring MQTT Modbus Gateway

---

Open RUT2 router's WebUI and navigate to Services → Modbus → MQTT Modbus Gateway

1. Select Enable
2. Enter Host (copied from flespi connection settings without 'wss://' and port)
3. Select QoS (Quality of Service) level
4. Enter Username (Copied from flespi Connection settings generated token)
5. Enter Password
6. Press to save the configuration

You can change Request and Response topics that you will have to publish and subscribe to get information from Modbus TCP Master through MQTT Gateway, but for this example, they are left on default topics

Message format for MQTT publisher

---

The format is in the text - heavier and slower, but less difficult to edit.

1. Format version	0
2. Cookie	from 0 to 264 -1
3. IP Type	0 - IPv4; 1 - IPv6; 2 - hostname
4. IP	IPv6 must be in full format (for example: 2001:0db8:0000:0000:0000:8a2e:0370:7334)
5. Port	Port number (for example: 502)
6. Timeout in seconds (time to wait for response)	from 1 to 999
7. Slave ID - Indicates to which slave request is sent	from 1 to 255
8. Function	3 - read registers; 6 - write single register; 16 - write multiple registers
9. Number of the first register from which information will be read or written	from 1 to 65535
10. Registry value	If function is 3 - from 1 to 123 (first register + registry value can not go out of range); If function is 6 - from 0 to 65535 If function is 16 - from 1 to 123 (first register + registry value can not go out of range), Registry values separated by commas without spaces. Example.: 1,2,3,654,21,789. There has to be as many values, as specified number of registers, and each value must be between 0 and 65535. If number of registries is 0, there should be no registry values

Examples

---

Setting relay (on) (Relay address is 202, which means 'Number of first register will be 203)	0 65432 0 192.168.1.1 502 5 1 6 203 1
Getting uptime	0 65432 0 192.168.1.1 502 5 1 3 2 2

Testing MQTT Publisher and Subscriber on flespi.io

---

Log in and navigate to MQTT Board on https://flespi.io

Add a Subscriber:

1. Press button on the top right corner
2. Select 'Subscriber'
3. In the topic field enter 'response'
4. Press 'Subscribe' button

Add a Publisher:

1. Press button on the top right corner
2. Select 'Publisher'
3. In the topic field enter 'request'
4. In the message field enter message, for this example 'Getting uptime' is used
5. Press 'Publish' button

Check the response in the 'Subscriber' tab, you should receive a message similar to the one below.

When the value climbs over 65535 the counter resets and the value held by the first register increases by 1. So one way to interpret the results would be to multiply the value in the first register by 2¹⁶ and add it to the value of the second register. In this example: 0 * 65536 + 31539 = 31539s or 0 days 8 hours 45 minutes and 39 seconds.

This Means that MQTT Gateway on Modbus TCP Client router is working correctly and Modbus TCP Server receives requests.

Configuration using RUT241 router as MQTT Broker

The same configuration will be used for Modbus TCP Client and Server routers as in the previous example, only settings in Modbus TCP Client router will be changed to match MQTT Broker on RUT241 router

Configuring MQTT Modbus Gateway settings

---

Open RUT2 router's WebUI and navigate to Services → MQTT Modbus Gateway

1. Enable
2. Host: Enter Public IP address of the new MQTT Broker (RUT241)
3. Username: N/A
4. Password: N/A
5. Press

Configuring MQTT Broker settings on RUT241 device

---

Open RUT241 router's WebUI and navigate to Services → MQTT → Broker

1. Select Enable
2. Check Enable Remote Access

3. Scroll down to "Broker settings" and select "Miscellaneous" tab
4. Enable "Allow anonymous"

5. Press to save the configuration

Configuring MQTT Publisher/Subscriber on PC & testing MQTT Gateway

---

For testing purposes, two terminal windows will be used on the same PC.

To get Ubuntu terminal on Windows 10/11, refer to the following link for instructions: https://tutorials.ubuntu.com/tutorial/tutorial-ubuntu-on-windows#0

• Open first terminal, which will act as Subscriber. Type in:

mosquito_sub -h [Host_address] -p [Port] -t [Topic]

• Open second terminal, which will act as Publisher. Type in:

mosquito_pub -h [Host] -h [Host_address] -p [Port] -m [‘Message’] -t [Topic]

• On the first window - Subscriber, a response should appear

MQTT Modbus Gateway JSON format

---

JSON Request Structure

1. Cookie	64-bit integer. Used to match request and response. Range: 0 to 264 -1
2. Type	Request type: 0 - TCP; 1 - Serial; 2 - Connection Control
3. Connection	(Type = 0 only) Connection index. Optional if host is given
4. Host	(Type = 0 or 2) IPv4, IPv6, or FQDN address of server. Required if connection is not used or if type = 2 and action = open
5. Port	(Type = 0 or 2) Server port. Optional for type = 0, required for type = 2 with action = open (for example: 502)
6. Timeout in seconds	(Type = 0, 1, or 2) How long to wait for response. From 1 to 999
7. Device ID	(Type = 1 only) Serial device ID
8. Server ID	(Type = 0 or 1) Modbus slave/server ID. From 1 to 255
9. Function	(Type = 0 or 1) Modbus function: 3 - read registers; 6 - write single register; 16 - write multiple registers
10. Register number	First register address. From 1 to 65535
11. Register count	Number of registers to read. If function is 3 or 16: from 1 to 123
12. Coil number	First coil address (for coil operations only)
13. Coil count	Number of coils to read (for coil operations only)
14. Value	Single value to write (used with function 6). Must be from 0 to 65535
15. Values	Array of values (used with function 16). Comma-separated without spaces (e.g. 1,2,3,654,21,789). Number of values must match register count. Each value: 0–65535
16. Action	(Type = 2 only) "open", "close", or "status"

JSON Response Structure

1. Cookie	Copied from request to identify it
2. Success	true if the request succeeded, false otherwise
3. Data	If success: can be a boolean or array of integers
4. Error	If success is false: a string containing an error message

JSON Message Examples

---

Read uptime from Modbus TCP Server (using TCP)

Request:
{
  "cookie": 65432,
  "type": 0,
  "host": "192.168.1.1",
  "port": 502,
  "timeout": 1,
  "server_id": 1,
  "function": 3,
  "register_number": 2,
  "register_count": 2
}
Response:
{
  "cookie": 65432,
  "success": true,
  "data": [0, 5590]
}

Read uptime from Modbus TCP Server (using serial)

Request:
{
  "cookie": 65432,
  "type": 1,
  "device_id": "my_serial_device",
  "timeout": 1,
  "server_id": 1,
  "function": 3,
  "register_number": 2,
  "register_count": 2
}
Response:
{
  "cookie": 65432,
  "success": true,
  "data": [0, 5590]
}

Read uptime from Modbus TCP Server (using TCP connection)

Request:
{
  "cookie": 65432,
  "type": 0,
  "connection": 1,
  "timeout": 1,
  "server_id": 1,
  "function": 3,
  "register_number": 2,
  "register_count": 2
}
Response:
{
  "cookie": 65432,
  "success": true,
  "data": [0, 5590]
}

Read coils from server

Request:
{
  "cookie": 65432,
  "type": 0,
  "host": "192.168.1.1",
  "port": 502,
  "timeout": 1,
  "server_id": 1,
  "function": 1,
  "coil_number": 2,
  "coil_count": 2
}
Response:
{
  "cookie": 65432,
  "success": true,
  "data": [0, 1]
}

Write multiple registers to server

Request:
{
  "cookie": 65432,
  "type": 0,
  "host": "192.168.1.1",
  "port": 502,
  "timeout": 1,
  "server_id": 1,
  "function": 16,
  "register_number": 2,
  "values": [1, 2, 3]
}
Response:
{
  "cookie": 65432,
  "success": true
}

Write multiple coils to server

Request:
{
  "cookie": 65432,
  "type": 0,
  "host": "192.168.1.1",
  "port": 502,
  "timeout": 1,
  "server_id": 1,
  "function": 15,
  "coil_number": 2,
  "values": [1, 2, 3]
}
Response:
{
  "cookie": 65432,
  "success": true
}

Write single register to server

Request:
{
  "cookie": 65432,
  "type": 0,
  "host": "192.168.1.1",
  "port": 502,
  "timeout": 1,
  "server_id": 1,
  "function": 16,
  "register_number": 2,
  "value": 1
}
Response:
{
  "cookie": 65432,
  "success": true
}

Write single coil to server

Request:
{
  "cookie": 65432,
  "type": 0,
  "host": "192.168.1.1",
  "port": 502,
  "timeout": 1,
  "server_id": 1,
  "function": 16,
  "coil_number": 2,
  "value": 1
}
Response:
{
  "cookie": 65432,
  "success": true
}

Open TCP connection

Request:
{
  "cookie": 65432,
  "type": 2,
  "action": "open",
  "connection": 1,
  "host": "192.168.1.1",
  "port": 502,
  "timeout": 1
}
Response:
{
  "cookie": 65432,
  "success": true
}

Close TCP connection

Request:
{
  "cookie": 65432,
  "type": 2,
  "action": "close",
  "connection": 1
}
Response:
{
  "cookie": 65432,
  "success": true
}

Check TCP connection status

Request:
{
  "cookie": 65432,
  "type": 2,
  "action": "status",
  "connection": 1
}
Response:
{
  "cookie": 65432,
  "success": true,
  "data": false
}

See Also

• Modbus Master RutOS configuration example
• Monitoring via Modbus