I’m working on integrating a Modbus RTU device with the Teltonika TRB245 using the RS-485 half-duplex interface. Despite setting everything up according to the manual, I keep encountering “failed request” errors when trying to query registers on the connected device.
Here’s an overview of my setup:
Physical Wiring:
RS-485 D+ and D- lines from the device are connected to the TRB245’s A and B terminals, respectively.
TRB245 Configuration:
Serial interface is set to RS-485 half-duplex.
Baud rate, parity, and stop bits are matched with the device’s settings.
Modbus Client is configured with the correct Slave ID, register address, and function code (03 - Read Holding Registers).
The Issue:
Any query sent via the TRB245’s Modbus Client results in a “failed request” error.
Logs indicate no response from the device.
Steps I’ve already tried:
Verified wiring and swapped D+ and D- as a precaution.
Tested with increased timeout and multiple retries in the TRB245 Modbus settings.
Used an RS-485 to USB adapter with Modbus Poll software on a PC, which successfully communicated with the device using the same parameters.
It seems the issue might be specific to the TRB245 configuration or compatibility with this device. Has anyone else encountered a similar issue or successfully used the TRB245 for Modbus communication in a half-duplex RS-485 setup?
Any guidance or suggestions would be greatly appreciated!
The first thing to check in your setup is the wiring. Ensure that the R+ and D+ terminals are connected (shortened) and the R- and D- terminals are also connected (shortened), as shown in the wiring example below:
unfortunately I still am receiving the “failed request” error after wiring up as recommended. - This maybe a configuration problem but I cannot see one.
When setting up the Modbus Serial Client (as I need to be able to read certain holding registers of my sensor)
NOTE:
The client signals as up.
The device also signals as up.
For testing purposes, could you try the following:
Change Period and Timeout values to their default settings (e.g., Period: 60 seconds, Timeout: 1 second).
Ensure that the data type matches the requirements specified in your server device’s manual.
Try adjusting the baud rate to common values such as 9600 or 115200.
If the issue persists, performing a factory reset and setting up the configuration from scratch might help eliminate any misconfigurations.
Regarding your question about Modbus to MQTT:
Yes, it’s possible to send Modbus data to an MQTT broker using the Modbus serial client MQTT gateway functionality on the TRB245. A detailed configuration example can be found in this guide: Modbus RTU Client MQTT Serial Gateway
Feel free to reach out if you have further questions or need additional assistance.
I have made all the suggested changes, including a factory reset and unfortunately the problem still persists.
One thing of note is, (which may or may not be relevant) that the failed request counter is not always consistent in the time of when the first failed request is registered.
For example, with the settings I sent you yesterday I received the first failed request after 3 seconds.
After adjusting the period to the default 60 seconds and timeout to 1 second, I receive a failed request immediately - meaning not even 1 second.
Re MQTT set up you have sent me,
Is the same setup possible with just one trb245 gateway?
Could you let me know which firmware version is currently installed on your TRB245?
Regarding the inconsistent Failed requests counter, it is not directly tied to the issue. The counter updates only after the specified Period parameter. However, the error message “failed to test request, check your configuration” is often related to wiring issues, so I would not dismiss the possibility of incorrect wiring being the root cause.
Could you provide a picture of how your wiring looks? This would help confirm if there’s any potential misconnection or fault in the setup.
As for your question, yes, the same Modbus RTU client to MQTT serial gateway setup is possible using only the TRB245 as the Modbus Serial Client, with your sensor device acting as the server (slave).
Happy new year, I hope you managed to get a break at some point over the holiday period!
Just looking for a bit more clarification on the set up of the TRB245,
I have wired it up as suggested, which was a great help and solved the previous issues!
I basically just need another point/push in the right direction if possible.
As previously mentioned, I have connected the trb245 via serial connection to a sensor that measures various conditions e.g temperature and pressure.
with the goal of sending the conditions via mqtt to a broker and be used in prediction models.
I currently have a modbus tcp server → modbus tcp client set up (see screenshots), am I right in thinking this configuration is not able to monitor the sensor via serial and only able to monitor the trb245 itself - the reason I believe is is because when accessing the modbus registers of the sensor (5th register for a total of two registers, which should give me temperature)I get a return of [0.000, 0.000] but if I access the registers of the trb245 I receive a return of expected results e,g the name of the of teltonika device.
I am assuming I have to set up a Modbus Serial Server and Modbus serial client to have access to the sensor connected via serial - is this the correct assumption?
or am I totally off track?
Please feel free to reach out for clarifying questions,
Thanks again for the support!
Regarding your setup with the TRB245, you’re absolutely correct in identifying the issue with the current configuration. Right now, you’ve enabled the Modbus TCP Server on the TRB245 itself (as per your first screenshot), which is why you’re receiving inappropriate register values This setup essentially allows you to read registers from the TRB245, not the sensor connected via the serial interface.
To access data from your sensor connected via serial, you only need to configure the Modbus Serial Client. Here’s how to set it up:
Steps to Configure Modbus Serial Client:
Disable Modbus TCP Server/Client:
Navigate to Services → Modbus and disable the current Modbus TCP Server/Client to avoid conflicts.
Set Up Modbus Serial Client:
Go to Services → Modbus → Modbus Serial Client and create a new Serial Device instance.
Set the Interface to RS485 (or the correct one based on your sensor’s communication method).
Configure the parameters (baud rate, parity, data bits, stop bits, etc.) to match your sensor’s settings.
Press Save & Apply.
Add a Modbus Device Instance:
Add a new Modbus Device and assign it to the Modbus Serial Client instance you just created.
Configure the device settings, such as the sensor’s Modbus address.
Create a Request:
Add a request to query the specific registers of your sensor.
Test the configuration to ensure you’re receiving the expected data (e.g., temperature, pressure, etc.).
Sending Data to MQTT Broker:
Once the data is correctly parsed from the sensor, you can send it to your MQTT broker. We have a similar Modbus RTU Client (Master) MQTT Serial Gateway wiki configuration example that might be useful available here.
Feel free to reach out if you have any additional questions or need further clarification.
I am unable to see a breaking configuration problem.
I have been in contact with our local suppliers technical support and they suggested in this particular instance there may be a setting that needs to be implemented.
Thank you for providing detailed information about your setup and troubleshooting steps so far.
Here are a few suggestions that might be helpful checking:
RS485 Cable Check:
Can you confirm that your RS485 cable is functioning properly? If possible, try using a different cable to eliminate any potential hardware issues.
Test Serial Communication:
Could you test the serial communication by connecting your computer to the TRB245 using an RS485-USB adapter and using ModRSsim2 software to simulate a Modbus serial server (slave)?
Detailed instructions for testing with ModRSsim2 can be found in wiki example here.
Reset Modbus Settings to default:
For testing purposes, try setting the following parameters to their default values (if not already done):
Period: 60
Number of Timeouts: 0
Timeout: 5
Factory Reset:
If feasible, perform a factory reset of the TRB245, reconfigure the Modbus serial client settings, and test again to see if there is any improvement.
Let me know if these suggestions help or if further assistance is needed.
Hello @J_Dev ,
sorry if this has already been mentioned in the thread, I didn’t bother to read everything, to be honest. The entire thing sounds very familiar to me, not being able to read from RS485, despite everything seems to be set up OK.
Measure your Bias across the RS485 bus. It should be somewhere around 0.4VDC (-200mV to +200mV). The Teltonika Master does not provide a bias, so if no other device on your bus does ito it, you have to do it manually by connecting a power source to the bus. I did that by connecting a small power supply that I turned up until I could read the 0.4V.
I actually also connected the bus to a USB charger with some resistors in between (to get to the 400mV) at some point.
Thanks for reaching out,
I have still had no success.
This sounds like an interesting lead, so I’ll pass this suggestion on to our senior technical specialist and get his thoughts on it.
I appreciate the insights and well wishes!
Hello, Martynas I am writing to express my significant concern regarding the persistent issues I’ve been experiencing with the TRB245 integration. Despite my thorough troubleshooting efforts, I continue to encounter critical connectivity failures that are impeding our project timeline. While trying to connect the trb245 to the sensor (see the thread for details),
When connecting to the sensor I am having a “request failed, result: communication error”
Variables I can confirm are correct and true.
The sensor and the TRB245 have a single power source with the correct polarity.
The Modbus registers we are calling are correct and the correct value and data type.
The values for the modbus device configuration are all consistent with the sensor settings, i.e server ID is the address of the sensor.
Unfortunately there is no way to interrogate this error via the web ui or as I can tell via the cli.
I am in contact with the local teltonika (Australian office) and was told to make sure the TRB245 is registered on the RMS so that I can organise a remote debugging option for the technician, but this leads to my second issue.
The TRB245 will not show as active on the RMS despite still having the the 30 free trial and 5038MB of data to use.
I have unregistered the device and re-registered
Confirmed the Authentication code is correct.
While I understand these represent two distinct technical issues, I must express my disappointment regarding the level of support provided and the absence of clear debugging procedures within the documentation. These limitations significantly impact our ability to implement and deploy the teltonika based setup effectively and we may be forced to look at other solutions.
I would appreciate your prompt attention to these matters and clear guidance on how to proceed.
For anyone following who may have the same issue as me,
Be sure to double check the polarity of all cabling, this was causing significant issues and the problem is now solved. due to the nature of my background (web dev) I was not able to know that this was an issue, but due the nature of teltonikas error reporting there was also no way of knowing this could be an issue.
The RMS issue is also now solved, the problems was the password you are asked to enter is not the password for the device itself as suggested by the UI, it is the password used to log into the RMS.
Thank you for confirming. I’m glad to hear your matter was finally resolved.
In cases like this, it is always recommended to check and ensure that the serial RS485/RS232 wiring is connected properly, as a “communication error” usually indicates a problem with cabling or polarity, as was the case here.
I appreciate the time you and your colleagues spent troubleshooting this matter, and thank you for sharing the root cause of the issue; it may help others facing a similar problem.
