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!
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:
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:
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.
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:
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’)
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.
Would you be willing to share you lua scripts? I haven’t landed on the right documentation to figure out how to read the data polled over modbus outside of the Data to Server functionality. How did you get your scripts to automatically execute on schedule? Simple cron?
Yes, I can share my LUA scripts, why not? After all, it was my first experiment to let an AI (perplexity) to work instead of me. Which means I didn’t write the code, I only instructed the AI on what to do and what to avoid, etc. Don’t get me wrong, I can program in many different languages, golang being my favorite, but LUA was the obvious choice because of the limitations of the TRB145. And I am not an expert in LUA.
Please give me some days to prepare it for sharing.
And yes, I think I used cron for automatic execution.
modbus_servers.lua:
this contains the parameters, like the API endpoint and the modbus units,
json.lua:
a complete copy of the open source pure lua implementation of a json extention for lua (maybe the copywrite notice is missng, sorry, that is needed…)
check_modbus_rest_scripts.sh:
A script that checks if the two main lua scripts are running or not. It is impotant that you have to insert the following line into crontab to let it run: * * * * * /storage/check_modbus_rest_scripts.sh >> /tmp/modbus_rest.log 2>&1
modbus_enqueuer-4.lua:
This program (script) continuosly reads data from the modbus units and inserts them in a sqlite database. It also samples the data every 5 minutes (this is set in the parameters file) and if the data is valid (not older than 5 minutes, also set in the parameter file) then it puts it in another sqlite queue that stores tha data to be sent by the rest sender.
rest_sender-4.lua:
This is the rest sender. If data is available in the sqlite queue, it sends it and deletes it. If there is no answer from the rest API endpoint, it tryes to send it later.
All lua files should be copied to the /storage folder. Logging and sqlite database are creted in the /tmp folder.
I must emphasize that the code is published “as it is”, there is no warranty whatsoever that it will work for you or any other person reading this article.
Of course I am ready to answer questions regarding its use. And modifications, extensions, etc. are all wellcome! trb145_to_publish.zip (7.8 KB)
I have Just encountered the same issue and managed to find a fix.
if you add “option delay ‘100’” to each of your meters in the /etc/config/modbus_client file
it seems to resolve the problem.
Hi,
According to Teltonika support it “delays how fast the client starts collecting the data after connection establishment.” Apparently meant for TCP, but it has fixed the issue 100% for me.
Regards,