TRB145, Modbus Serial Client problem

NETWORKING SOLUTIONS
1

Hello,

Once again, I need help. The configuration is simple, Modbus Serial Clients with Data-to-Server sending data with POST calls to a remote server. Software is TRB1_R_00.07.14.3.

So, I have two TRB145-s in different locations. Both have 5 Modbus RTU thermometers and 3 Modbus RTU electrical meters connected. Both run 19200 Baud, no parity, the Modbus RTU sensors are connected in a chain, with the proper resistors at the end. The data from the thermometers are read in one request configuration (per thermometer), while from the electrical meter the data is read in three request configurations (per meter). This means that there are 5 x 1 + 3 x 3 = 14 requests in every circle. The data is read every 300 seconds, that is every 5 minutes. The problem is that very often there are missing requests, meaning that the TRB145 could not read in that cycle the data from the Modbus RTU sensor. Missing data exists for both thermometers and electrical meters. Sometimes there is no data from a sensor for almost 45 minutes! The weird thing is that if I go into the WebUI, and press “Request configuration testing” for the long-time missing data, I always get valid data. Even if I push it several times. The problem is present in both installations and none of them have a cabling longer than 40 meters!

It seems to me that the problem is not with the sensors, but with the way that “Modbus Serial Client” runs its “Requests configuration”-s. Could it be that there is not enough guard after each Modbus call? I have tried several different possibilities for timeout and repeats (even timeout:10 and repeats: 10), but the problem persists. Another interesting thing is that if I have only 4 sensors connected with 3 requests for each, then there is no problem at all!

For double checking, I have downloaded /tmp/modbus_db from both TRB145-s to check if the problem is with Data-to-Server, but not, the Sqlite3 database itself is missing the missing data!

People from Teltonika! Please try to convince me that I have done a mistake and that there is no problem with the software of the TRB145!

Any help is appreciated!

3

Greetings,

From the first glance, it does indeed sound like the Modbus database or request handling process might occasionally be getting overloaded or not processing all requests within the configured polling interval, especially with multiple chained requests in a relatively tight loop.

To test and confirm this theory, could you please try modifying the database storage path (to flash memory) and allocation by adjusting the following parameters:

In your TRB device /etc/config/modbus_client file, change the following:

config main 'main'
        option enabled '1'
        option debug '0'
        option db_max_page_count '20'
        option db_path '/usr/local/share/modbus_db'

Alternatively these parameters can be changed using the API with a PUT method to /api/modbus/client/global endpoint and the following data in the body:

{
    "data": {
        "enabled": "1",
        "db_path": "/usr/local/share/modbus_db",
        "db_max_page_count":"20"
    }
}

This change will move the Modbus database from volatile /tmp to persistent flash storage and increase the allowed maximum database size pages.

After applying the change, restart the Modbus service or reboot the device, and monitor if all Modbus requests get read successfully and forwarded to your server.

If this stabilizes the readings, it would indicate that the issue is indeed related to how the temporary database buffer behaves under load.

Let me know the outcome, and if the issue still persists, we’ll need to take a deeper look into it privately.

Best regards,

4

Hello,

Thanks for your reply. I will be able to do the changes only on Friday. I will get back to you.

Regards,

PS: In the meanwhile, as we need to fix the problem ASAP, I wrote two separate lua scripts that run in the background, using another sqlite3 db:

  1. Script ‘one’ continuously (every 5 seconds) reads each of the modbus calls and stores data in an sqlite3 table (named ‘read_data’). It also runs a sampling every 5 minutes to enqueue the latest (not older than 3 minutes) read data into another table (called ‘rest_queue’)

  2. Script ‘two’ continuously (every 5 seconds) tries to send unsent data in table ‘rest_queue’ using REST API calls, effectively implementing a FIFO queue pattern.