When using the “Data to Server” service with Modbus Serial Client Data on a RUT955 router, configured with an MQTT type, we observed an unexpected behavior:
The first Modbus register is sent hundreds of times to the MQTT broker, while the remaining registers are sent only once.
This causes a device with just four registers to exceed the MQTT broker’s rate limits within a second.
Troubleshooting steps attempted:
Changed the external MQTT broker to use the RUT955’s internal MQTT gateway.
Adjusted the QoS settings.
Deleted and recreated Modbus clients and registers (without using the test function).
Synchronized the polling periods between the “Data to Server” and Modbus services (tried equal, greater, and lesser values).
Performed a factory reset and full reconfiguration.
Updated to the latest firmware
There are at least four Modbus slaves connected. All data is filtered by Slave ID in the “Data to Server” service.
Despite these efforts, the issue persists.
I believe this is a MQTT issue.
to my understanding its to do with the QOS settings.
In my case when ever the readings change within the modbus registers there is a new mqtt message created.
Meaning if for example we send the data every 1 minute to the broker but the reading of the register happens every 5 seconds (and those registers hold new data each of those 5 seconds) there will be 12 MQTT messages created for that one register and sent every minute to the broker.
And if we are using QOS 0 then it will not check if there is any variation within each message and as they say in the article attached it will “fire and forget“.
I was also polling my serial connected device every minute which was causing the teltonika deice to run out of memory.
I could also be totally wrong and I am no network engineer
Thank you for your response. I’ve tested various QoS configurations between the RUT and the broker, including direct connections to HiveMQ and the local MQTT broker, but the issue persists. I’ve also adjusted the timing between Modbus polling and data transmission intervals. Based on these tests, I suspect the problem may lie within the router’s Modbus Server service, as the behavior improves when other clients are disabled in the data-to-server collections.
Did modifying the QoS resolve the issue on your end?
your welcome!
I have actually discovered through trying to debug your issue that I have the same problem.
So you can ignore my previous suggestions, but my multiple message issue is tied to changes in the data that the registers are holding.
Hello, @fcaverzan and @J_Dev , I’ve sent both of you a form to fill out so we can continue our conversation in private, to avoid accidentally leaking any sensitive information. In the Ticket ID field, simply enter the thread’s number, which is 14987 (fcaverzan) and 14987-2 (J_Dev). We’ll collect the logs from your devices and forward them to the RnD for analysis.
I’m having exact same issue. Also tried opc ua client to mqtt using data to server and still see multiple messages with a very short delays (couple of ms) sent together.
We haven’t received further responses from either of the users, however, one of them have provided some logs to which our R&D have responded with the following:
Based on the short set of messages provided, it looks like some messages might have been duplicated, which can happen with QoS 1. Regarding “synchronizing the polling periods between the Data to Server and Modbus services” — when using scheduled data sending, the sending time should be set slightly after the data collection time. In practice, you can use short sending periods; the device will simply check for new entries and send them if available.
