Siemens Logo! modbus server and TRB140 MQTT gateway

[PDOU]

Dear Support Team,

I’m trying to access the HR of the Logo, in reading and writing, via MQTT gateway and modbus protocol. The topology is quite simple :

Logo! as modbus server, connected via its ethernet port to the TRB140.
TRB140 as modbus client, and modbus mqtt gateway.
I use mqttboard on flespi.io, as suggested in your example for the wiki.

This is what I can achieve :

• Read and write Logo! HR using modbus request, via the TRB140 WebUI (this way, I can assume that everything has been set properly on the logo).
• Read HR in the TRB140 with MQTT request from Flespi mqtt dashboard
  (for example, local IP adress :
  Publisher request : 0 65000 0 10.0.0.10 502 5 5 3 395 2
  Subscribe answer : 65000 OK 2560 10 ).

But I can not manage to reach the logo! behind and get any answer from a mqtt request. I got the following message on flespi Subscribe topic : “read register failure. Connection reset by peer”.
(for example, read HR nb 2 in the logo :
0 65000 0 10.0.0.2 502 5 1 3 2 2 )
nb : Logo local IP address is 10.0.0.2, slave device number 1

What am I missing?

Thanks for your help.

[AndzejJ]

Hello,

I have tried to replicate this, but everything works properly. Could you please clarify what firmware version you are using?

Have you tried reading other registers?

Are you sure that the logo! has the IP address of 10.0.0.2?

Kind Regards,

[PiM]

Hello,
this issue is similar of the one i have. My setup is almost identical, but i try to access the registers of a solar inverter instead of the LOGO.
I’ve tried with varous firmwares, different hardware, and different brokers (Moskitto and Flespi) but the problem remains.
Really interested in a solution.

[PDOU]

Dear AndzejJ,

I’m using the last firmware, upgrading is the first thing I’ve done.
However, since my last message, now it seems to work, even if sometimes, it still fails to read logo register (and I get the same message error).

For @PiM, please be sure that you configured properly all the readings in the Logo! registers (by testing them using teltonika WEBUI), but also, that they are active using the toggle. I think it’s the only thing that was missing…

Now, I’m clearly struggling to use the JSON sent via MQTT on the thingsboard platform. All the tutorials out there seems to use an older version of teltonika’s WEBUI, and options seem to have evolved. Thus, the payload sent is no more like {“ts”: xxxx, “reg”: xxxx, “data”: xxxx}, but rather {LogoData: {“ts”: xxxx, “reg”: xxxx, “data”: xxxx}}, making it impossible to use without converting it…

[AndzejJ]

Hello,

It seems that the issue may be coming from the Logo! itself. Make sure you do not send too many requests in quick succession.

As for the formating, you can select custom data format for your Modbus data input and change it according to your needs. For example:

If you do not want any other data appended to your Modbus data, you can edit the format of the collection itself. For example, from this:

To this:

I suggest making your own changes and see in what format do you receive messages.

Kind Regards,

[PDOU]

Thanks so much AndzejJ !
This is probably the most helpful message that I got for the past 10 days.
My problem was that I selected JSON as format type for the modbus data collection (instead of custom, so that I can choose only the desired modbus infos) :

…as well as JSON instead of custom (as you suggested) in format type in collection configuration.
No that i’ve followed your suggestion, everthing works properly.
The payload is in the proper configuration, despite the fact that thingsboard should normally deal with “classic” json payload. I still ignore why it couldn’t.
Thanks again!

[sommerseth]

Hi AndzejJ,

I’m also having the same issue and setup as the other two posters. I use a TRB255 though.
This problem has been present also with other modbus TCP slaves besides the Logo, and has been present across many firmware versions and 15 or so different TRB255 units.

For clarity I’ll explain my setup as well.

TRB255 acts as a modbus TCP server and client.
The TRB unit polls its own modbus registers and the registers of a connected PLC.
This data is then sent through a MQTT data sender. This works flawlessly.
However, when I want to write to the registers of the connected PLC, it often fails giving either:
“ERROR: Connection failed” or “ERROR: write single register failure - Connection reset by peer”
To me, this sounds like a modbus problem, and I’m guessing it has to do with request timing.

Thus far, I have solved it by just repeating the requests until I get a confirmation, but this is obviously super hacky.

I’ve been stuck with this issue for close to a year, so I’m hoping for some guidance to finally solve this.

Here is an example:

Thanks!
-Sommerseth

[AndzejJ]

Hello @sommerseth ,

I assume you are using Modbus TCP as well. Is that correct?

How many Modbus servers are connected to TRB? Are you reading Modbus data from the TRB too?

Could you please try changing the port number on your Modbus server? For example, use port 2502 for Modbus. Then, specify this port number in the MQTT message. Something like:

0 65000 0 192.168.1.100 2502 5 1 3 2 2

If the issue persists, could you try to disable Modbus requests and try sending modbus requests through MQTT only. Try sending requests at intervals such as 10, 20, 30, 60, and 120 seconds between each request.

Let me know how it goes.

Kind Regards,

[sommerseth]

Changing the port worked! Thank you so much!
Yes, modbus TCP was used, and I was reading modbus data from the TRB as well.

For anyone else having trouble with this specifically with the Siemens Logo:

In logo soft, set up two different modbus server connections.
Set the TRB up so that the Modbus client connects to one of the ports, and set up your MQTT requests to poll through the other connection.

AndzejJ:
Would you mind taking the time to tell me why this works?
As I mentioned, I’ve had this problem before with other PLC’s. Knowing the cause might make it easier for me to prevent the issue from happening again.