ModBus RTU to TCP gateway

Have you looked for this feature in other issues and in the docs?
I did. It's not implemented yet. Here is an existing gateway in C or stripped down in python. This is the basic idea behind a RTU/TCP gateway.

Is your feature request related to a problem? Please describe.
I want to be able to poll certain registers from my modbus device regularly via MQTT and be able to configure it via a TCP-based Windows app.

Describe the solution you'd like
Implement a RTU/TCP gateway in Tasmota which allows concurrent access to a modbus device on Tx/Rx.

Describe alternatives you've considered
Alternatively I can either connect Tasmota for MQTT-based access or my PC directly for TCP-based access.

Additional context
This gateway is a litte bit more than a simple serial TCP bridge in the sense that it adds and also strips a few bytes from each request/response.

(Please, remember to close the issue when the problem has been addressed)

Tasmota always prefers MQTT protocol wherever it's possible. We strongly suggest to use the Mqtt gateway instead.

At least I need Tasmota to act as TCP gateway because my heating regulator Trovis 5573 can only be configured using a software called Trovis View which only supports communication via TCP. My idea is to enhance your code with an option "TCP_BRIDGE_MODBUS" for according byte mangling (see python solution linked in description).

Tasmota already has a TCP gateway. See config example used for the ZbBridge for connecting with HomeAssistant (ZHA)
https://zigbee.blakadder.com/Sonoff_ZBBridge.html
Command TCPStart <Port>
Sorry a implementation for all different special use cases for a TCP bridge will not be done

I linked to Tasmota TCP bridge already in the first post. But I need the gateway to mangle the bits a little.

Another option would be to implement the gateway in the SML interface. The meter is already defined (baudrate, protocol, pins, etc) and thus the gateway only needs to insert its TCP commands along the other commands from the MQTT/console stream.

Since a meter can only be connected to one host it would be great if continous meter value logging could be combined with (rare) meter configuration stuff (in my case with a TCP-based Windows app, a TCP-based smartphone app is available as well).

The use case is very specific. So it will be probably not done from the main contributors. Maybe you are lucky and someone has the need too and provides a PR.
With the solution as it is now, the needed manipulations can be done on receiver side with a little (Python?) tool and providing the data to your Application.

Closing this request as there is no active development on this. Please, ask to reopen if you want to work on this. Thanks.

@TheChatty

@TheChatty Can you try this?

I have added the modbustcpstart en modbustcpconnect functions.

I also removed the (u)int8 option for modbus send command, because modbus registers are always 16 bits.

The data received from the tcp client is not checked btw, it's just send to the modbus client.

I will also write a small tcpclient to test this added feature.

https://github.com/jeroenst/Tasmota/tree/ModbusTCP

I flashed the .gz you provided but are unable to select "ModBr .." in Configuration? It's not listed.

I will look at it tomorrow. Otherwise compile it from my branch.

@Jason2866

@Jason2866: A ModBus TCP gateway is a widely requested feature I'd say. Enhancing driver 41 or 63 is not really important. The code impact is rather small, the usage gain is much bigger. If implemented in driver 41 TCP/RTU protocol conversion could be handled by a new option for instance.

@jeroenst

@jeroenst: I compiled db4f710 myself and it offered ModBr Tx/Rx. But I don't receive anything yet (trying to read outside temp like in my SML script):

# ModBusBaudrate 19200
# ModBusSerialConfig 3
# ModBusSend {"deviceaddress": 247, "functioncode": 3, "startaddress": 9, "type":"int16", "count":1}

I need to check via plain serial bridge if communication is a problem atm... tomorrow or so...

@TheChatty

@TheChatty I did some improvements in my latest branch, try that instead.

I was confused with the registers which are not 8 but 16 bits.

https://github.com/jeroenst/Tasmota/tree/ModbusTCP

Also have a look at the logging when using weblog 4

I will also have a look at it tomorrow if it still doesn't work.

All code is now in the arendst/Tasmota development branch.

Please create a new bug report if any bug is found, this issue is getting to long.

@josegardo

@josegardo I don't forget about you, over a few weeks I will include your code/feature request in ModbusBridge.

You are also welcome to create a patch file leaving all other functionality in ModbusBridge in tact.

I did some testing and bugfixing for functioncode 1 and 2. For functioncode 1 and 2 also an odd number of bytes can be returned, but this is not supported by TasmotaModbus.cpp.

For function code 15 it's also allowed to send single bytes as data I discovered.

I will adapt TasmotaModbus for this later.

https://ozeki.hu/p_5876-mobdbus-function-code-1-read-coils.html https://ozeki.hu/p_5877-mobdbus-function-code-2-read-discrete-inputs.html https://ozeki.hu/p_5882-mobdbus-function-code-15-write-multiple-coils.html

Read the code of TasmotaModbus.
When the number of DO/DI of plc is greater than 16. It is not possible to read and write all points at once.
The DI/DO of low cost PLCs I know can go up to 32 points (dedicated PLC cascades can be up to hundreds). At least two WORD lengths need to be read. When the number of the latest code DO/DI is greater than 16, it needs to be read twice.

Hello,
sorry, it is hard to keep track of this development by reading this issue.
Is this Gateway working now?
Is there any documentation?

Best regards,
Hendrik

Code is finished but on beta status.

Here you can find the documentation:

https://tasmota.github.io/docs/Modbus-Bridge/

It is working for me in a low looad environment already, e.g. I can run a python script (ModbusTcpClient) and request single registers from a serial RTU modbus client connected to Tasmota.

What doesn't work for me atm is an application which causes heavy load on the wires (vendor app to configure the heating regulator). The connection seems to choke. I need to further evaluate this.

Hello,

I am not sure, I understand the feature well.
Is it possible with this to receive Modbus RTU values and send (all) of them via Modbus TCP? (or/and the other way around)

Best regards,
Hendrik

Yes, it's a TCP/RTU gateway. It connects your serial-only modbus device to your Wifi. And you can also send MQTT requests at the same time. Awesome piece of code.

Great!

But when I go through the documentation, it is not at all clear how to configure that. Please see this as constructive feedback, not as criticism.

The Modbus Bridge driver features 2 kind of bridges.

USE_MODBUS_BRIDGE: The bridge can be used by commands in the console and via MQTT messages.
USE_MODBUS_BRIDGE_TCP: The bridge can be used by commands in the console and via MQTT messages but also as Modbus TCP/IP bridge

It is not clear where to configure that.

Then, it goes directly to Commands.

I would expect something like

In order to use the Modbus Bridge, configure USE_MODBUS_BRIDGE or ..._TCP in config.h and compile Tasmota. This feature is not part of any precompiled Binary and only available for ESP32.
Once, this feature is compiled in, and the GPIOs for ModBus RTU are selected, the Bridge will automatically relay all Data from RTU to TCP and vice versa.

Furthermore, it is possible to send data from MQTT to Modbus (it will send to both RTU and TCP at the same time).
Relaying data from Modbus to MQTT is not supported (?)

A question on this:

ModbusTcpStart | Start the Modbus TCP bridge on the specified tcp port

Is that required to start the Bridge? Autostart possible?

You've got a couple of mistakes in your reply.

The base is to define USE_MODBUS_BRIDGE in user_config_override.h like any other feature that doesn't come precompiled. You have to define GPIOs like they are configured for your serial modbus device. Then you can use MQTT to send modbus requests which will be received via MQTT as well.

Defining USE_MODBUS_BRIDGE_TCP additionally gives you something like Serial to TCP bridge except it provides transparent TCP/RTU protocol translation. No additional GPIOs are required but a start of the TCP server (see similar bridge feature). This start can be automated with rules.

Requests sent with TCP part will only be answered via TCP. Likewise with MQTT.

I haven't tried ESP32 myself yet but I can promise it works well with ESP8266.

You're invited to improve documentation once you got acquainted with this feature. I haven't done so yet because I still analyze a failing heavy load scenario. The similar TCP bridge serves a good start for TCP part of this bridge.

@TheChatty

@TheChatty thank you for supporting other users.

Maybe for the heavy load scenario I can add a little delay before processing. I can imagine that tasmota gets to little time to process other tasks in heavy load.

test for arendst#9586 (comment)

@TheChatty

@TheChatty can you give my latest commit a try?

@jeroenst

@jeroenst I'm helping others because you did a wonderful job already.

Unfortunately I won't get to test any of this until two weeks. I'll give feedback then.

@TheChatty

@TheChatty no problem👍

Navigation Menu

Repository navigation

ModBus RTU to TCP gateway #9586

254 remaining items

Metadata

Assignees

Labels

Projects

Milestone

Relationships

Development

ModBus RTU to TCP gateway #9586

Description

Activity

s-hadinger commented on Oct 20, 2020

TheChatty commented on Oct 20, 2020

Jason2866 commented on Oct 21, 2020

TheChatty commented on Oct 21, 2020

Jason2866 commented on Oct 21, 2020

ascillato2 commented on Nov 9, 2020

jeroenst commented on Jul 20, 2022

TheChatty commented on Jul 20, 2022

jeroenst commented on Jul 20, 2022

TheChatty commented on Jul 20, 2022

TheChatty commented on Jul 20, 2022

jeroenst commented on Jul 20, 2022

254 remaining items

jeroenst commented on Aug 27, 2022

jeroenst commented on Aug 27, 2022

darcyg commented on Aug 29, 2022

henfri commented on Sep 2, 2022

jeroenst commented on Sep 2, 2022

TheChatty commented on Sep 2, 2022

henfri commented on Sep 10, 2022

TheChatty commented on Sep 10, 2022

henfri commented on Sep 10, 2022

TheChatty commented on Sep 10, 2022

jeroenst commented on Sep 10, 2022

jeroenst commented on Sep 10, 2022

TheChatty commented on Sep 10, 2022

jeroenst commented on Sep 10, 2022

Metadata

Metadata

Assignees

Labels

Projects

Milestone

Relationships

Development

Issue actions