Please find below the ubus commands we were using for sensors and plc data polling from respective modbus serial clients. Now we have upgraded to the latest firmware available on teltonika website and found that the same ubus commands are not giving expected output values after polling real-time data from serial clients. Support to resolve this issue.
Before the firmware upgrade on TRB245, the data type ASCII was used with function 4 for reading input registers (first screenshot). Based on your description, for parsing data from sensors (which I assume are connected to TRB245), function 3 and data type 16bit_int_hi_first should be used.
From your screenshot, it seems you are using different data types and function 2 (in the last command) in each Modbus RTU request:
Could you clarify how the Modbus serial servers (sensors, PLCs) are connected to your TRB and RUT devices?
Additionally, please double-check for any typos in the functions, data types, or other parameters in the ubus call modbus request commands. From the screenshots, the provided commands do not fully align with the ones listed in your description.
all the modbus serial clients are connected to RS485 terminals of respective TRB and RUT gateways in daisy chain. we have tested it repeatedly - it is found that till the firmware version TRB2_R_00.07.12 | 2025.01.20 - all ubus commands are returning correct values for each modbus register but when we install the latest firmware 07.12.3 of 14.02.2025 - the returning values is 0 for all ubus commands which seems peculiar to me. for existing TRB245 and RUT we are installing the previous firmware and closing the issue but what will happen when we purchase and install new gateway devices - do we have to maintain the same firmware. If yes - we wont be able to upload latest firmware for any of our new gateway devices.
From your provided screenshots (ubus calls on TRB245 and RUT906), it does not appear that the returned Modbus serial server values are 0. The "error": 0 indicates that no errors occurred during data parsing.
Could you clarify and provide additional screenshots where the returned data is displayed as 0?
Also, just to confirm, does the issue not occur on FW 7.11.3, and does data parsing work correctly with that version?
Yes ubus commands are giving correct output values when tested in TRB245/RUT906 CLI for all previous firmware versions except for 7.12.3 dtd 14.02.2025. for FW 7.11.3 too - ubus commands are giving output values. Now since we had changed all firmware versions to 7.12 dtd 20.12.25 to maintain consistency for existing gateways on RMS. It seems we have to maintain the same firmware for all our future RUT906 configurations too. Another problem is - when i change fimrware versions on RMS platform - specially for the TRB245 (with M2M 4G SIM) - firmware does not get updated for days - i have to take local access of the gateway for firmware and backup upload.
I have the same issue. The ubus library no longer works at all and immediately just returns a counter value form what I can see. This is the code I was using:
for i in $(seq 1 $MAX_RETRIES); do
echo “Attempting to connect to MQTT broker (Attempt $i)…”
mosquitto_pub -h $BROKER -p $PORT -t "$/test/connection" -u $USERNAME -P $PASSWORD -m "test" -q $QOS
if [ $? -eq 0 ]; then
echo "Connected to MQTT broker successfully."
mosquitto_sub -h $BROKER -p $PORT -t $TOPIC -u $USERNAME -P $PASSWORD -q $QOS | while IFS=',' read -r ID FUNCTION FIRST_REG VALUE DATA_TYPE
do
echo "Received command: ID=$ID, FUNCTION=$FUNCTION, FIRST_REG=$FIRST_REG, VALUE=$VALUE, DATA_TYPE=$DATA_TYPE"
RESPONSE=$(ubus call modbus_client.rpc serial.test "{
\"serial_type\": \"/dev/rs485\",
\"baudrate\": 9600,
\"databits\": 8,
\"stopbits\": 1,
\"parity\": \"none\",
\"flowcontrol\": \"none\",
\"timeout\": 5,
\"id\": $ID,
\"function\": $FUNCTION,
\"first_reg\": $FIRST_REG,
\"reg_count\": \"$VALUE\",
\"data_type\": \"$DATA_TYPE\",
\"no_brackets\": 1
}")
echo "Sent Modbus request"
if [ $? -eq 0 ]; then
echo "Command executed successfully. Response: $RESPONSE"
timeout 4 mosquitto_pub -h $BROKER -p $PORT -t "$RESPONSE_TOPIC" -u $USERNAME -P $PASSWORD -m "$RESPONSE" -q $QOS
else
echo "Failed to execute write command."
echo "Response was: $RESPONSE"
fi
done
break
else
echo "Failed to connect to MQTT broker. Retrying in $RETRY_INTERVAL seconds..."
sleep $RETRY_INTERVAL
fi
done
It worked perfectly and I have used this code on many teltonika routers without fail. However with the new firmware it no longer works at all.
This is the output im getting at the moment. When I am monitoring the output it is clear that the ubus library isn’t even trying to read a register from the modbus device because the results are returned almost immediately. This is a major issue for me because I use this script to remotely setup and calibrate modbus devices.
Atleast in my case i was unable to update the firmware or even upload backup from RMS - RUT906 which has a stable wired-Ethernet connectivity. Had to take local access of the device to change the firmware and backup in each RUT906. With 7.12 firmware - things are fine now and i am able to make configuration changes and work in CLI for running scripts.
I too am struggling with this issue. I have TRB142 devices running 7.11.3 firmware, ubus call modbus_client.rpc serial.test is working fine. Then, updating to the newest firmware 7.13.1, the modbus_client.rpc serial.test is returning Error: 0, result: 1 as others have pointed out.
Have encounter the same issue as you with the latest FW -release (07.13.1).
Teltonika have made a major change blocking “ubus call” and suggest to use the API-requests instead.
After Teltonika confirmed the forwarding moving strategy blocking “ubus call” i tried the suggested API approach, documented in this case: CLI Modbus scripts debricated in 07.13.1?
The API-solution is for me really slow and inconsistent (4-12 sec. between requests) compared to ubus call and the workflow troublesome compared to direct scripting. With this performance it is not usable for my current applications.
I hope Teltonika will make a opening for us favoring scripting and response requirements…
They have also recommended to use the api for me. I am reading 6 registers every 10 seconds so as you said a delay of 4-12s would make it completely unusable.
After some testing I have found out what the issue is with ubus. Usually we just used ubus call modbus_client.rpc serial.test then it would return the modbus result. However ubus call modbus_client.rpc serial.test now returns a request id. You then need to take that request id and use ubus call modbus_client.rpc request_status ‘{“id”:id_number}’. This will then return the results of the ubus call. The only other issue I see is that it is caching the ubus results which could become and issue if it doesn’t clear it.
Thank you so much Chrish, this is working perfectly nice and are almost as responsive as earlier.
You saved my use case with quite many RUT956 devices interfacing Modbus-devices and the ability to keep the firmware updated!
Since you pointed out that catching ubus could create an issue, maybe with memory?, i made a test script for tcp.test, doing the job continuously and flawlessly.
After running 90k+ calls i cannot see any significant changes in memory use(terminal → top). But maybe you have observed something ?
Earlier i had problems that “modbus_client” service seams to fill the memory (easily solved by crontab and a reset eg. 05 */3 * * * /etc/init.d/modbus_client restart ) but now it seams fine.
while true
do
RESPONSE=$(ubus call modbus_client.rpc tcp.test
‘{“ip”:"’“$IP”‘",“port”:“502”,“id”:1,“timeout”:5,“function”:3,“first_reg”:1125,“reg_count”:“2”,“data_type”:“32bit_float3412”,“no_brackets”:1,“garbage”:1}’)
ID=$(echo “$RESPONSE” | jsonfilter -e ‘@.result’)
if [ -z “$ID” ]; then
echo “Failed to extract ID.”
exit 1
fi
