Question

I'm operating a large fleet of RUT995s (06.08.6) to gather Modbus parameters over the RS-485 interface. I'm using the Modbus Serial Master function to poll 7 register banks across two Modbus devices on a regular (either 30 or 300 seconds) basis. Then the Data to Server function to post the results of those queries over MQTT to a remote server. In general it works well. However, every now and then it will generate hundreds of MQTT messages per second for several hours. 

The MQTT JSON received is coherant, it reports apparently valid data with valid timestamps; those timestamps not being every 30/300 seconds but every second. Between one and four messages will have the same timestamp. The data reported in such groups can be seen to vary and that is not possible. It may be an function of the configuration but all the timesreported are "whole" seconds 

• 1678263022000
• 1678263023000
• 1678263024000

I do not know if it is the Modbus Serial Master function generating the raw data or the Data to Server. I think the former would be constrained by the speed Modbus interface and would also not report differing values for the same time. So I'm suspecting it is the Data to Server function.

The Record Format used is : {"E:","%n", "T":%t, "R":%s, "D":%a}

I can't see a pattern in the data to predict which RUT (of hundreds) will next generate the problem, so it'll be difficult to identify a device to upgrade to v7 to see if that cures the problem.

Any ideas?

thanks,

Dominic.

Answer 1

Hello,

Without some logging information from the specific device it is difficult estimate the reason.

Do you have Retry on fail option enabled in Data sender configuration? As in this case, I would assume that one of the routers has lost data connection and during the disconnection time, data was stored within the router. Once connection was restored, all of the collected data was immediately forwarded to the server.

Best regards,

Comments

But then it looks like, the timestamp is generated when message is transmitted. Wouldn't it be better to generate the timestamp, when message is generated, before either being TXed, or being queued ? At, least, thats what I am doing in custom code. Has an advantage, in case of messages are queued up :-)

---

I have simulated a data loss scenario, however, data stamps were received correctly corresponding to configured data collection periods.

Thus, what can be suggested is to locate the device causing this surge of data and try updating it first.

If the issue continues, further investigation will be required.

Best regards,