ModBus RTU to TCP gateway

[TheChatty]

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)

[jeroenst]

I'm still in the works with figuring out what TrovisView does.

But to the modbus TCP bridge standard:

• config is not persisted as is with serial and tcp bridge (try Baudrate <x> and TCPBaudrate <y>for yourself)
• asking for baudrate like ModBusBaudrate always returns RESULT = {"ModbusBaudrate":8912700}, e.g. destroys current config

Check out the latest pull request.

[TheChatty]

Settings are persisted now. I'd recommend the merge now. Thank you for your contribution!

Yet I have the following problem: TrovisView@TCP --> python-TCP-RTU-Conv --> Tasmota-plain-TCP-bridge works sometimes. log

TrovisView@TCP --> w/ or w/o python-TCP-TCP-Proxy --> Tasmota-Modbus-TCP-bridge doesn't worrk. log

Still investigating...

[jeroenst]

I forgot to begin the serial port on (boot) init.. Tested also the data you send to modbusbridge and it seems ok.

TX: 0x00 0x01 0x00 0x00 0x00 0x06 0xf7 0x03 0x00 0x01 0x00 0x01 
RX: 0x00 0x01 0x00 0x00 0x00 0x05 0xf7 0x03 0x02 0x00 0x01 

Fix can be found here: https://github.com/jeroenst/Tasmota/commit/7fab74bc8f0c4a034c7710682cd45995dbb161c6

[jeroenst]

Hi @TheChatty,

Did you do some more testing?

[TheChatty]

I had to figure out a bug in pymodbus.datastore with Jan Iversen. Now this is resolved I have the following effect in these use cases:

A1: pymodbus.client with ModbusSocketFramer (TCP) requesting single holding register A2: pymodbus.client with ModbusRtuFramer (RTU) requesting single holding register A3: TrovisView requesting loads of arbitrary registers B1: pymodbus.forwarder TCP⇒TCP B2: pymodbus.forwarder TCP⇒RTU C1: Tasmota Modbus TCP bridge C2: Tasmota plain TCP bridge D: real modbus hardware

UC1: A1 ⇒ B1 ⇒ C1 ⇒ D works UC2: A1 ⇒ B2 ⇒ C2 ⇒ D works UC3: A1 ⇒ C1 ⇒ D works UC4: A2 ⇒ C2 ⇒ D works UC5: A3 ⇒ B1 ⇒ C1 ⇒ D works UC6: A3 ⇒ B2 ⇒ C2 ⇒ D works UC7: A3 ⇒ C1 ⇒ D does not work

I can now try to log UC5 and repeat all requests manually but I reckon it is timing issue.

This is the Tasmota console in UC7 while TrovisView is trying to connect:

16:48:37.702 TCP: MBS: MBRTCP Got connection from 192.168.178.53
16:48:37.704 MBS: MBRTCP to Modbus Transactionid:6680, deviceAddress:247, functionCode:3, startAddress:0, Count:1
16:48:37.822 MBS: MBRTCP from Modbus deviceAddress 247, writing 11 bytes to client
16:48:40.854 MBS: MBRTCP to Modbus Transactionid:6936, deviceAddress:247, functionCode:3, startAddress:0, Count:1
16:48:40.935 MBS: MBRTCP from Modbus deviceAddress 247, writing 11 bytes to client
16:48:43.991 MBS: MBRTCP to Modbus Transactionid:7192, deviceAddress:247, functionCode:3, startAddress:0, Count:1
16:48:44.110 MBS: MBRTCP from Modbus deviceAddress 247, writing 11 bytes to client
16:48:45.423 WIF: Sending Gratuitous ARP
16:48:46.523 WIF: Prüfe Verbindung...
16:48:47.135 MBS: MBRTCP to Modbus Transactionid:7448, deviceAddress:247, functionCode:3, startAddress:0, Count:1
16:48:47.224 MBS: MBRTCP from Modbus deviceAddress 247, writing 11 bytes to client
16:48:47.227 MBS: MBRTCP to Modbus Transactionid:7704, deviceAddress:247, functionCode:3, startAddress:0, Count:1
16:48:47.349 MBS: MBRTCP from Modbus deviceAddress 247, writing 11 bytes to client
16:48:50.413 MBS: MBRTCP to Modbus Transactionid:7960, deviceAddress:247, functionCode:3, startAddress:0, Count:1
16:48:50.525 MBS: MBRTCP from Modbus deviceAddress 247, writing 11 bytes to client
16:48:50.528 MBS: MBRTCP to Modbus Transactionid:8216, deviceAddress:247, functionCode:3, startAddress:0, Count:1
16:48:50.649 MBS: MBRTCP from Modbus deviceAddress 247, writing 11 bytes to client
16:48:50.651 MBS: MBRTCP to Modbus Transactionid:8472, deviceAddress:247, functionCode:3, startAddress:0, Count:1
16:48:50.828 MBS: MBRTCP from Modbus deviceAddress 247, writing 11 bytes to client
16:48:50.830 MBS: MBRTCP to Modbus Transactionid:8728, deviceAddress:247, functionCode:3, startAddress:0, Count:1
16:48:50.961 MBS: MBRTCP from Modbus deviceAddress 247, writing 11 bytes to client
16:48:50.964 MBS: MBRTCP to Modbus Transactionid:8984, deviceAddress:247, functionCode:3, startAddress:0, Count:1
16:48:51.085 MBS: MBRTCP from Modbus deviceAddress 247, writing 11 bytes to client
16:48:51.088 MBS: MBRTCP to Modbus Transactionid:9240, deviceAddress:247, functionCode:3, startAddress:0, Count:1
16:48:51.210 MBS: MBRTCP from Modbus deviceAddress 247, writing 11 bytes to client
16:48:51.213 MBS: MBRTCP to Modbus Transactionid:9496, deviceAddress:247, functionCode:3, startAddress:0, Count:1
16:48:51.344 MBS: MBRTCP from Modbus deviceAddress 247, writing 11 bytes to client
16:48:51.347 MBS: MBRTCP to Modbus Transactionid:9752, deviceAddress:247, functionCode:3, startAddress:0, Count:1
16:48:51.458 MBS: MBRTCP from Modbus deviceAddress 247, writing 11 bytes to client
16:48:51.461 MBS: MBRTCP to Modbus Transactionid:10008, deviceAddress:247, functionCode:3, startAddress:0, Count:1
16:48:51.585 MBS: MBRTCP from Modbus deviceAddress 247, writing 11 bytes to client
16:48:51.588 MBS: MBRTCP to Modbus Transactionid:10264, deviceAddress:247, functionCode:3, startAddress:0, Count:1
16:48:51.708 MBS: MBRTCP from Modbus deviceAddress 247, writing 11 bytes to client
16:48:54.773 MBS: MBRTCP to Modbus Transactionid:10520, deviceAddress:247, functionCode:3, startAddress:0, Count:1
16:48:54.884 MBS: MBRTCP from Modbus deviceAddress 247, writing 11 bytes to client
16:48:54.886 MBS: MBRTCP to Modbus Transactionid:10776, deviceAddress:247, functionCode:3, startAddress:0, Count:1
16:48:55.008 MBS: MBRTCP from Modbus deviceAddress 247, writing 11 bytes to client
16:48:55.011 MBS: MBRTCP to Modbus Transactionid:11032, deviceAddress:247, functionCode:3, startAddress:0, Count:1
16:48:55.132 MBS: MBRTCP from Modbus deviceAddress 247, writing 11 bytes to client
16:48:55.177 MBS: MBRTCP to Modbus Transactionid:11288, deviceAddress:247, functionCode:3, startAddress:0, Count:1
16:48:55.319 MBS: MBRTCP from Modbus deviceAddress 247, writing 11 bytes to client
16:48:55.321 MBS: MBRTCP to Modbus Transactionid:11544, deviceAddress:247, functionCode:3, startAddress:0, Count:1
16:48:55.443 MBS: MBRTCP from Modbus deviceAddress 247, writing 11 bytes to client
16:48:55.446 MBS: MBRTCP to Modbus Transactionid:11800, deviceAddress:247, functionCode:3, startAddress:0, Count:1
16:48:55.568 MBS: MBRTCP from Modbus deviceAddress 247, writing 11 bytes to client
16:48:55.571 MBS: MBRTCP to Modbus Transactionid:12056, deviceAddress:247, functionCode:3, startAddress:0, Count:1
16:48:55.691 MBS: MBRTCP from Modbus deviceAddress 247, writing 11 bytes to client
16:48:55.694 MBS: MBRTCP to Modbus Transactionid:12312, deviceAddress:247, functionCode:3, startAddress:0, Count:1
16:48:55.818 MBS: MBRTCP from Modbus deviceAddress 247, writing 11 bytes to client
16:48:55.821 MBS: MBRTCP to Modbus Transactionid:12568, deviceAddress:247, functionCode:3, startAddress:0, Count:1
16:48:55.944 MBS: MBRTCP from Modbus deviceAddress 247, writing 11 bytes to client
16:48:55.946 MBS: MBRTCP to Modbus Transactionid:12824, deviceAddress:247, functionCode:3, startAddress:0, Count:1
16:48:56.108 MBS: MBRTCP from Modbus deviceAddress 247, writing 11 bytes to client
16:48:56.110 MBS: MBRTCP to Modbus Transactionid:13080, deviceAddress:247, functionCode:3, startAddress:0, Count:1
16:48:56.199 MBS: MBRTCP from Modbus deviceAddress 247, writing 11 bytes to client
16:49:05.295 MBS: MBRTCP to Modbus Transactionid:13848, deviceAddress:247, functionCode:3, startAddress:0, Count:1
16:49:05.406 MBS: MBRTCP from Modbus deviceAddress 247, writing 11 bytes to client
16:49:05.409 MBS: MBRTCP to Modbus Transactionid:14104, deviceAddress:247, functionCode:3, startAddress:0, Count:1
16:49:05.532 MBS: MBRTCP from Modbus deviceAddress 247, writing 11 bytes to client
16:49:05.535 MBS: MBRTCP to Modbus Transactionid:14360, deviceAddress:247, functionCode:3, startAddress:0, Count:1
16:49:05.705 MBS: MBRTCP from Modbus deviceAddress 247, writing 11 bytes to client
16:49:05.707 MBS: MBRTCP to Modbus Transactionid:14616, deviceAddress:247, functionCode:3, startAddress:0, Count:1
16:49:05.898 MBS: MBRTCP from Modbus deviceAddress 247, writing 11 bytes to client
16:49:05.901 MBS: MBRTCP to Modbus Transactionid:14872, deviceAddress:247, functionCode:3, startAddress:0, Count:1
16:49:06.069 MBS: MBRTCP from Modbus deviceAddress 247, writing 11 bytes to client
16:49:06.072 MBS: MBRTCP to Modbus Transactionid:15128, deviceAddress:247, functionCode:3, startAddress:0, Count:1
16:49:06.154 MBS: MBRTCP from Modbus deviceAddress 247, writing 11 bytes to client
16:49:06.501 WIF: Prüfe Verbindung...

And this is working connect from UC5:

16:51:35.443 TCP: MBS: MBRTCP Got connection from 192.168.178.53
16:52:28.893 MBS: MBRTCP to Modbus Transactionid:1, deviceAddress:247, functionCode:3, startAddress:0, Count:1
16:52:28.976 MBS: MBRTCP from Modbus deviceAddress 247, writing 11 bytes to client
16:52:28.979 MBS: MBRTCP to Modbus Transactionid:2, deviceAddress:247, functionCode:3, startAddress:144, Count:1
16:52:29.100 MBS: MBRTCP from Modbus deviceAddress 247, writing 11 bytes to client
16:52:29.102 MBS: MBRTCP to Modbus Transactionid:3, deviceAddress:247, functionCode:3, startAddress:144, Count:1
16:52:29.228 MBS: MBRTCP from Modbus deviceAddress 247, writing 11 bytes to client
16:52:29.231 MBS: MBRTCP to Modbus Transactionid:4, deviceAddress:247, functionCode:3, startAddress:4, Count:1
16:52:29.396 MBS: MBRTCP from Modbus deviceAddress 247, writing 11 bytes to client
16:52:29.450 MBS: MBRTCP to Modbus Transactionid:5, deviceAddress:247, functionCode:3, startAddress:4, Count:1
16:52:29.692 MBS: MBRTCP from Modbus deviceAddress 247, writing 11 bytes to client
16:52:29.746 MBS: MBRTCP to Modbus Transactionid:6, deviceAddress:247, functionCode:3, startAddress:2, Count:1
16:52:29.847 MBS: MBRTCP from Modbus deviceAddress 247, writing 11 bytes to client
16:52:29.850 MBS: MBRTCP to Modbus Transactionid:7, deviceAddress:247, functionCode:3, startAddress:5301, Count:1
16:52:29.980 MBS: MBRTCP from Modbus deviceAddress 247, writing 11 bytes to client
16:52:29.982 MBS: MBRTCP to Modbus Transactionid:8, deviceAddress:247, functionCode:3, startAddress:4, Count:1
16:52:30.097 MBS: MBRTCP from Modbus deviceAddress 247, writing 11 bytes to client
16:52:30.100 MBS: MBRTCP to Modbus Transactionid:9, deviceAddress:247, functionCode:3, startAddress:4, Count:1
16:52:30.226 MBS: MBRTCP from Modbus deviceAddress 247, writing 11 bytes to client
16:52:30.229 MBS: MBRTCP to Modbus Transactionid:10, deviceAddress:247, functionCode:3, startAddress:0, Count:1
16:52:30.345 MBS: MBRTCP from Modbus deviceAddress 247, writing 11 bytes to client
16:52:30.389 MBS: MBRTCP to Modbus Transactionid:11, deviceAddress:247, functionCode:3, startAddress:2, Count:1
16:52:30.538 MBS: MBRTCP from Modbus deviceAddress 247, writing 11 bytes to client
16:52:30.628 MBS: MBRTCP to Modbus Transactionid:12, deviceAddress:247, functionCode:3, startAddress:0, Count:4
16:52:30.726 MBS: MBRTCP from Modbus deviceAddress 247, writing 17 bytes to client
16:52:30.815 MBS: MBRTCP to Modbus Transactionid:13, deviceAddress:247, functionCode:3, startAddress:0, Count:7
16:52:30.913 MBS: MBRTCP from Modbus deviceAddress 247, writing 23 bytes to client
16:52:30.000 MBS: MBRTCP to Modbus Transactionid:14, deviceAddress:247, functionCode:3, startAddress:0, Count:4
16:52:31.130 MBS: MBRTCP from Modbus deviceAddress 247, writing 17 bytes to client
16:52:31.185 MBS: MBRTCP to Modbus Transactionid:15, deviceAddress:247, functionCode:3, startAddress:0, Count:7
16:52:31.288 MBS: MBRTCP from Modbus deviceAddress 247, writing 23 bytes to client
16:52:31.427 MBS: MBRTCP to Modbus Transactionid:16, deviceAddress:247, functionCode:3, startAddress:0, Count:3
16:52:31.534 MBS: MBRTCP from Modbus deviceAddress 247, writing 15 bytes to client
16:52:31.537 MBS: MBRTCP to Modbus Transactionid:17, deviceAddress:247, functionCode:3, startAddress:3999, Count:100
16:52:31.763 MBS: MBRTCP from Modbus deviceAddress 247, writing 209 bytes to client
16:52:31.766 MBS: MBRTCP to Modbus Transactionid:18, deviceAddress:247, functionCode:3, startAddress:4099, Count:100
16:52:32.008 MBS: MBRTCP from Modbus deviceAddress 247, writing 209 bytes to client
16:52:32.011 MBS: MBRTCP to Modbus Transactionid:19, deviceAddress:247, functionCode:3, startAddress:4199, Count:100
16:52:32.362 MBS: MBRTCP from Modbus deviceAddress 247, writing 209 bytes to client
16:52:32.372 MBS: MBRTCP to Modbus Transactionid:20, deviceAddress:247, functionCode:3, startAddress:4299, Count:100
16:52:32.571 MBS: MBRTCP from Modbus deviceAddress 247, writing 209 bytes to client
16:52:32.574 MBS: MBRTCP to Modbus Transactionid:21, deviceAddress:247, functionCode:3, startAddress:4399, Count:100
16:52:32.825 MBS: MBRTCP from Modbus deviceAddress 247, writing 209 bytes to client
16:52:32.828 MBS: MBRTCP to Modbus Transactionid:22, deviceAddress:247, functionCode:3, startAddress:4499, Count:100
16:52:33.074 MBS: MBRTCP from Modbus deviceAddress 247, writing 209 bytes to client
16:52:33.077 MBS: MBRTCP to Modbus Transactionid:23, deviceAddress:247, functionCode:3, startAddress:4599, Count:100
16:52:33.326 MBS: MBRTCP from Modbus deviceAddress 247, writing 209 bytes to client
16:52:33.339 MBS: MBRTCP to Modbus Transactionid:24, deviceAddress:247, functionCode:3, startAddress:4699, Count:100
16:52:33.574 MBS: MBRTCP from Modbus deviceAddress 247, writing 209 bytes to client
16:52:33.577 MBS: MBRTCP to Modbus Transactionid:25, deviceAddress:247, functionCode:3, startAddress:4799, Count:100
16:52:33.826 MBS: MBRTCP from Modbus deviceAddress 247, writing 209 bytes to client
16:52:33.829 MBS: MBRTCP to Modbus Transactionid:26, deviceAddress:247, functionCode:3, startAddress:4899, Count:100
16:52:34.072 MBS: MBRTCP from Modbus deviceAddress 247, writing 209 bytes to client
16:52:34.075 MBS: MBRTCP to Modbus Transactionid:27, deviceAddress:247, functionCode:3, startAddress:4999, Count:100
16:52:34.322 MBS: MBRTCP from Modbus deviceAddress 247, writing 209 bytes to client
16:52:34.325 MBS: MBRTCP to Modbus Transactionid:28, deviceAddress:247, functionCode:3, startAddress:5099, Count:100
16:52:34.570 MBS: MBRTCP from Modbus deviceAddress 247, writing 209 bytes to client
16:52:34.573 MBS: MBRTCP to Modbus Transactionid:29, deviceAddress:247, functionCode:3, startAddress:5199, Count:100
16:52:34.821 MBS: MBRTCP from Modbus deviceAddress 247, writing 209 bytes to client
16:52:34.824 MBS: MBRTCP to Modbus Transactionid:30, deviceAddress:247, functionCode:3, startAddress:5299, Count:100
16:52:35.067 MBS: MBRTCP from Modbus deviceAddress 247, writing 209 bytes to client
16:52:35.070 MBS: MBRTCP to Modbus Transactionid:31, deviceAddress:247, functionCode:3, startAddress:5399, Count:100
16:52:45.221 MBS: MBRTCP from Modbus deviceAddress 247, writing 209 bytes to client
16:52:45.224 MBS: MBRTCP to Modbus Transactionid:46, deviceAddress:247, functionCode:3, startAddress:4199, Count:100
16:52:45.465 MBS: MBRTCP from Modbus deviceAddress 247, writing 209 bytes to client
16:52:45.468 MBS: MBRTCP to Modbus Transactionid:47, deviceAddress:247, functionCode:3, startAddress:4299, Count:100
16:52:45.473 WIF: Sending Gratuitous ARP
16:52:45.718 MBS: MBRTCP from Modbus deviceAddress 247, writing 209 bytes to client
16:52:45.721 MBS: MBRTCP to Modbus Transactionid:48, deviceAddress:247, functionCode:3, startAddress:4399, Count:100
16:52:45.974 MBS: MBRTCP from Modbus deviceAddress 247, writing 209 bytes to client
16:52:45.977 MBS: MBRTCP to Modbus Transactionid:49, deviceAddress:247, functionCode:3, startAddress:4499, Count:100
16:52:46.222 MBS: MBRTCP from Modbus deviceAddress 247, writing 209 bytes to client
16:52:46.225 MBS: MBRTCP to Modbus Transactionid:50, deviceAddress:247, functionCode:3, startAddress:4599, Count:100
16:52:46.474 MBS: MBRTCP from Modbus deviceAddress 247, writing 209 bytes to client
16:52:46.477 MBS: MBRTCP to Modbus Transactionid:51, deviceAddress:247, functionCode:3, startAddress:4699, Count:100
16:52:46.534 WIF: Prüfe Verbindung...
16:52:46.719 MBS: MBRTCP from Modbus deviceAddress 247, writing 209 bytes to client
16:52:46.722 MBS: MBRTCP to Modbus Transactionid:52, deviceAddress:247, functionCode:3, startAddress:4799, Count:100
16:52:46.971 MBS: MBRTCP from Modbus deviceAddress 247, writing 209 bytes to client
16:52:46.974 MBS: MBRTCP to Modbus Transactionid:53, deviceAddress:247, functionCode:3, startAddress:4899, Count:100
16:52:47.218 MBS: MBRTCP from Modbus deviceAddress 247, writing 209 bytes to client
16:52:47.221 MBS: MBRTCP to Modbus Transactionid:54, deviceAddress:247, functionCode:3, startAddress:4999, Count:100
16:52:47.468 MBS: MBRTCP from Modbus deviceAddress 247, writing 209 bytes to client
16:52:47.473 MBS: MBRTCP to Modbus Transactionid:55, deviceAddress:247, functionCode:3, startAddress:5099, Count:100
16:52:47.715 MBS: MBRTCP from Modbus deviceAddress 247, writing 209 bytes to client
16:52:47.718 MBS: MBRTCP to Modbus Transactionid:56, deviceAddress:247, functionCode:3, startAddress:5199, Count:100
16:52:47.965 MBS: MBRTCP from Modbus deviceAddress 247, writing 209 bytes to client
16:52:47.968 MBS: MBRTCP to Modbus Transactionid:57, deviceAddress:247, functionCode:3, startAddress:5299, Count:100
16:52:48.215 MBS: MBRTCP from Modbus deviceAddress 247, writing 209 bytes to client
16:52:48.218 MBS: MBRTCP to Modbus Transactionid:58, deviceAddress:247, functionCode:3, startAddress:5399, Count:100
16:52:48.467 MBS: MBRTCP from Modbus deviceAddress 247, writing 209 bytes to client
16:52:48.470 MBS: MBRTCP to Modbus Transactionid:59, deviceAddress:247, functionCode:3, startAddress:5499, Count:100
16:52:48.711 MBS: MBRTCP from Modbus deviceAddress 247, writing 209 bytes to client
16:52:48.714 MBS: MBRTCP to Modbus Transactionid:60, deviceAddress:247, functionCode:3, startAddress:5599, Count:100
16:52:49.269 MBS: MBRTCP from Modbus deviceAddress 247, writing 209 bytes to client
16:52:49.272 MBS: MBRTCP to Modbus Transactionid:61, deviceAddress:247, functionCode:3, startAddress:5699, Count:100
16:52:49.831 MBS: MBRTCP from Modbus deviceAddress 247, writing 209 bytes to client
16:52:49.834 MBS: MBRTCP to Modbus Transactionid:62, deviceAddress:247, functionCode:3, startAddress:5799, Count:100
16:52:50.393 MBS: MBRTCP from Modbus deviceAddress 247, writing 209 bytes to client
16:52:50.396 MBS: MBRTCP to Modbus Transactionid:63, deviceAddress:247, functionCode:3, startAddress:5899, Count:100
16:52:50.956 MBS: MBRTCP from Modbus deviceAddress 247, writing 209 bytes to client
16:52:50.959 MBS: MBRTCP to Modbus Transactionid:64, deviceAddress:247, functionCode:3, startAddress:5999, Count:48
16:52:51.291 MBS: MBRTCP from Modbus deviceAddress 247, writing 105 bytes to client

[jeroenst]

UC7 doesn't work indeed because trovisview doesn't respect the ModbusTCP standard although I see the sending and receiving to modbus on Tasmota seems working, so possible trovisview does send ModbusTCP like requests but can't handle modbusTCP replies.

Maybe I can create a trovis define or flag for that but I need a detailed description of the bytes send and received between A3 and B1 (or B2).

[TheChatty]

I need to install Wireshark to really see what's different between UC5 and UC7. pymodbus has no "Trovis define" but A3 is working fine with B1 nevertheless.

[jeroenst]

I think the logging of pymodbus in UC6 can give enough details.

[jeroenst]

@TheChatty any news on this?

[josegardo]

@TheChatty Here is a bin file based on my latest commit in the modbustcp branch.

Can you give it a try?

tasmota.bin.gz

Hi, I am trying to carry out a modbus (TCP) communication but the modbus commands are unknown. I have compiled the 12.0.2.4 with defines (#define USE_MODBUS_BRIDGE, #define USE_MODBUS_BRIDGE_TCP) and also I tried the binary that you uploaded in this post with the same result. RSL: RESULT = {"Command":"Unknown"}

I am using the shelly plug S device. What is the problem?

Thank you!

[TheChatty]

I'm busy atm. I'll try to find some time next week.

[jeroenst]

Probably you didn't configure modtx and modrx pins in module configuration.

https://github.com/arendst/Tasmota/discussions/15703#discussioncomment-3323545

[josegardo]

I tried to do this but once the pins are configured, the device restarts and the configuration dissapears. This is the configuration (ModTx and ModRx do not exist, I configured them to ModBrTx and ModBrRX, is it correct?

But when device restarts this configuration is erased.

And the modbus commands are still unknown

[josegardo]

I solved this setting first the template for Shelly S plug and then configuring the modbus pins.

Now, the modbus commands are recognized.

The next week I'll try the communications. But let me ask you something. I want to be able to write the slave registers. I see on https://github.com/tasmota/docs/blob/development/docs/Modbus-Bridge.md documentation page that only Function Codes for reading are implemented. Is it correct? Or functional code for writing registers are also available?

Thank you!

[jeroenst]

Yes, only reading is supported at the moment.

[jeroenst]

Strange that the configuration is not saved before restart, I will have a look at it.

[barbudor]

Set Weblog 3 and check the logs close to the restart. Look for logs with something like 'FRC Some setti gs have been resetted' This would be the clue for Fast Reboot Check when tasmota crash on boot. In order to try to stop the crash loop tasmota disable settings once after the other Disabling gpio configuration is one of those

[barbudor]

I just tried to build Tasmota current dev with USE_MODBUS_BRIDGE and loaded on a NodeMCU Assigning ModBr TX/RX GPIO on 1/3 Device reboots and I can see in the boot logs:

00:00:00.055 FRC: Some settings have been reset (5)

which is the proof of a crash/boot loop which, as expected, has been mitigated by Tasmota by disabling the GPIO configuration So that means the ModbusBridge driver is making Tasmota to crash at boot Some debugging required

[barbudor]

It's difficult to debug without serial link but by commenting/uncommenting block of code it see that it is crashing in the call to tasmotaModbus->Begin(...) Can't do more for now

[jeroenst]

I will take a look at it next week. Serial debugging is possible when the modrx and modtx pins are configured on different pins than the serial pins I think.

I think it is caused because the baudrate is not yet configured and tasmota serial is initialized with an invalid not existing baudrate.

[jeroenst]

@josegardo

I fixed the issue you encountered.

Here is the pre-compiled modbusbridge enabled Tasmota bin file:

tasmota.bin.gz

@barbudor thanx for pointing me into the right direction.

[darcyg]

No modbus write function? Can it be provided?

[jeroenst]

@darcyg I will take a look at it

[jeroenst]

@darcyg

you can try this test firmware, it supports function 5 (write coil) and 6 (write register). Only the returned data is not shown yet.

You can specify the data by "data": in the json parameters.

tasmota.bin.gz

Please let me know if writing works ok.

[josegardo]

Thank you! I can also test it on Monday. However, can you attach the modification in the source code? I am compiling with defines for AWS IoT connection which I guess the attached binary does not have.

One more question, I am only interested in modbus TCP, do the pins for Modbus RTU always have to be defined to enable modbus?

El dom, 7 ago 2022 a las 15:03, Jeroen @.***>) escribió:

@darcyg https://github.com/darcyg

you can try this test firmware, it supports function 5 and 6. Only the returned data is not shown yet. tasmota.bin.gz https://github.com/arendst/Tasmota/files/9276837/tasmota.bin.gz

Please let me know if writing works ok.

— Reply to this email directly, view it on GitHub https://github.com/arendst/Tasmota/issues/9586#issuecomment-1207403975, or unsubscribe https://github.com/notifications/unsubscribe-auth/A2MJ53TXDLCNP2KERA5OQT3VX6XZFANCNFSM4SYASSUA . You are receiving this because you were mentioned.Message ID: @.***>

[darcyg]

@jeroenst thx Can you provide esp32 / tasmota32 version? I don't have an esp8266 module.

[jeroenst]

@darcyg unfortunately Tasmota did disable modbus on esp32. I don't know why, but when I compile it, the compilation fails. @arendst told me it is by design.

Maybe you can open a new issue for supporting esp32 modbus bridge so someone with knowledge about tasmota32 can take a look at it.

[josegardo]

@darcyg

you can try this test firmware, it supports function 5 (write coil) and 6 (write register). Only the returned data is not shown yet.

You can specify the data by "data": in the json parameters.

tasmota.bin.gz

Please let me know if writing works ok.

I tried the provided firmware but I am not able to perform a tcp modbus communication. This is my setup:

I have installed a modbus slave (python program) on my computer, running at 192.168.1.49 address and 502 port. I have defined four Holding registers starting at 1280 address:

In the console of tasmota, I connect to this slave and the connection is sucessfully (I tried to connect to another port where nothing is running and it fails, so the modbus connection is sucessfully).

However if I tried to send a functioncode 3 request, it returns nothing. Moreover, the python modbus slave program has a TCP monitor and nothing is received by TCP

The python modbus slave is working well. I have another program (called modbuspoll) that simulates a modbus master. When I tried to read these register I can see traffic on bus monitor and the register value are read.

[jeroenst]

Here is my latest code. It is in development so it's not finished and not bugfree.

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

[jeroenst]

@josegardo

I'm first implementing the modbussend command via console and mqtt. The bridge is to be done when that is finished.

Did you configure modbusbaudrate and modbussetserialconfig?

[josegardo]

@josegardo

I'm first implementing the modbussend command via console and mqtt. The bridge is to be done when that is finished.

Did you configure modbusbaudrate and modbussetserialconfig?

Yes, but I am not sure if the functionality that I want it is implemented. Taking a simple look at the source code, it seems that modbussend only sends for TX pin (modbus RTU) (a), and the modbus RTU frame received for RX pin is sent to TCP port in modbus TCP format (b). In the same way, Modbus TCP frame received are sent to TX pin (Modbus RTU) (c). It is correct?

a) modbussend -> TX pin (Modbus RTU) b) RX pin (Modbus RTU) --> MQTT & TCP c) Modbus TCP -> TX pin (Modbus RTU)

What I am looking for is that tasmota acts as modbus TCP master. I want to comunicate tasmota with a solar inverter. Solar inverter implements modbus over TCP, not over serial port (RTU). Only TCP frames are involved in the comunication. What I want is that modbussend sends a modbus TCP frame and the response to this frame is sent to MQTT client

a) modbussend -> Modbus TCP frame transmission b) Modbus TCP frame response --> MQTT client

I think I can implement (a) shortcuiting TX and RX pin, but I dont know how implement (b). Note that Modbus TCP is nothing more than a frame over TCP over IP. If Tasmota implements a simple TCP comunication, it can be used.

[jeroenst]

@josegardo this is indeed not the way that it is designed/implemented.

I will take a note of this use case but I can't guarantee this will be implemented.

[josegardo]

@jeroenst thx.

Please, let me know if you implement any of this.

[darcyg]

Tested the modbus of tasmota many problems Read Coils and Read Discrete Inputs Unable to return data Read Multiple Holding Registers and Read Input Registers can return normally But count cannot be set > 9. No return if more than 9

[darcyg]

cmnd command

ModbusBaudrate 9600 ModbusSerialConfig 3 ModbusSend {"deviceAddress":1,"functionCode":1,"startAddress":1,"type":"bit","count":1}

no return data

ModbusSend {"deviceAddress":1,"functionCode":3,"startAddress":1,"type":"uint16","count":8}

return data

{"ModbusReceived":{"DeviceAddress":1,"FunctionCode":3,"StartAddress":1,"Length":21,"Count":8,"Values":[0,0,0,0,0,0,0,0]}}

in berry script

def slog(val) var len=size(val) print(len," | ",val) end ser=serial(16, 4, 9600, serial.SERIAL_8N1)

ser.write(bytes().fromhex("01020000000879CC")) tasmota.delay(1000) msg=ser.read() slog(msg.tohex()) slog(msg.asstring())

return data:

12 | 01020100A188

[jeroenst]

I will test this asap

[darcyg]

I will test this asap

I have found the problem, I will submit a patch later. The main reason is that the data returned by some devices during DO/DI is uint8. I use a low-cost PLC control DO/DI/AI control module The price is about CNY 50-400 (USD 8-50)

[jeroenst]

Hmmz, I removed uint8 because modbus registers are always 16 bits according to the specification for what O have read. If corse I can re-add them.

Also try weblog 3 command so you can see he error codes.

[darcyg]

This is a code patch, based on https://github.com/jeroenst/Tasmota ModbusBridgeWrite branch Added data types int8/uint8/hex. The behavior of hex is similar to raw, except that the values output is a hex number When functionCode is less than 3, multiple bit operations are performed, and different types of returned data are correct.

read bit

ModbusSend {"deviceAddress":1,"functionCode":1,"startAddress":0,"type":"bit","count":12}

{"ModbusReceived":{"DeviceAddress":1,"FunctionCode":1,"StartAddress":0,"Length":7,"Count":12,"Values":[0,0,0,0,0,1,0,1,1,1,1,1]}}

read raw

ModbusSend {"deviceAddress":1,"functionCode":1,"startAddress":0,"type":"raw","count":12}

{"ModbusReceived":{"RAW":[1,1,2,160,15,129,248]}}

read hex

ModbusSend {"deviceAddress":1,"functionCode":1,"startAddress":0,"type":"hex","count":12}

{"ModbusReceived":{"HEX":[0x01,0x01,0x02,0xA0,0x0F,0x81,0xF8]}}

read uint8/int8

ModbusSend {"deviceAddress":1,"functionCode":1,"startAddress":0,"type":"uint8","count":12}

{"ModbusReceived":{"DeviceAddress":1,"FunctionCode":1,"StartAddress":0,"Length":7,"Count":12,"Values":[160,15]}}

read uint16/int16

ModbusSend {"deviceAddress":1,"functionCode":1,"startAddress":0,"type":"uint16","count":12}

{"ModbusReceived":{"DeviceAddress":1,"FunctionCode":1,"StartAddress":0,"Length":7,"Count":12,"Values":[4000]}}

read uint32/int32

ModbusSend {"deviceAddress":1,"functionCode":1,"startAddress":0,"type":"uint32","count":12}

{"ModbusReceived":{"DeviceAddress":1,"FunctionCode":1,"StartAddress":0,"Length":8,"Count":12,"Values":[4000]}}

The write function has not been tested yet.

0000-modbus-coils-discreteinputs-read-fix.zip

[jeroenst]

I will add this to my modbus branch later today, thank you for your effort!

[jeroenst]

Ok I added your patch to my branch and pushed it to github.

I think getuint and getint where incorrect, so I changed them: https://github.com/jeroenst/Tasmota/commit/a429e5df9b85673a9889d11e537af322ea2865b0

Please let me know any further issues so this module can be pushed to arendst/Tasmota.

Thank you

[jeroenst]

I'm testing your patch, but a few things don't work right I think.

When I read bit, (u)int8 or (u)int32 i get an MBR Recv Error 6 (wrongdataCount).

For the (u)int32 I solved this in my latest commit: jeroenst@9f82e8ce2241745521b7dabf715df635da3164a6

For the (u)int8 I have a question:

Normally when requesting a register 2 bytes are returned. How is this whenusing (undocumented) 8 bit registers? The modbus slave can't determine by a request if it is 8, 16 or 32 bits. It only receives how many 16 bits registers it has to return according to the documentation.

When reading bits and the count is 10, 10 registers are read, not 10 bits (which is a part of 1 16 bit register)..

[jeroenst]

I think this is working right for (u)int8 and bits, I tested with my modbus rtu simulator which seems right. Please check: jeroenst@fe4879703b566a212a32c2396db40fbf6259c2d3

[jeroenst]

I saw my modbus simulator was handling input and coil registers wrong.

Now it seems to be working according to the specification I found here: https://www.fernhillsoftware.com/help/drivers/modbus/modbus-protocol.html#:~:text=Modbus%20Read%20Coils%2C%20function%20code,(bits)%20from%20the%20PLC.&text=Note%3A%20The%20total%20number%20of,will%20also%20return%203%20bytes.

Please check https://github.com/jeroenst/Tasmota/tree/ModbusBridgeWrite

[jeroenst]

Writing coils is not working at the moment, I have to change code for that.

Writing registers should work ok.

[darcyg]

I'm testing your patch, but a few things don't work right I think.

When I read bit, (u)int8 or (u)int32 i get an MBR Recv Error 6 (wrongdataCount).

For the (u)int32 I solved this in my latest commit: jeroenst/Tasmota@9f82e8c

For the (u)int8 I have a question:

Normally when requesting a register 2 bytes are returned. How is this whenusing (undocumented) 8 bit registers? The modbus slave can't determine by a request if it is 8, 16 or 32 bits. It only receives how many 16 bits registers it has to return according to the documentation.

When reading bits and the count is 10, 10 registers are read, not 10 bits (which is a part of 1 16 bit register)..

I will test your code. Many low cost plc or modbus protocol devices. Handling data is not necessarily exactly the same as the modbus standard. I've seen devices that skip the crc check entirely. I have been using libraries such as libmodbus and cli to read and write this plc on linux. I'm worried that the modbus protocol written is poor in fault tolerance. I prefer to use arduinomodbus or esp-modbus to implement protocol read and write. But I can't add third-party library compilation in tasmota.

[darcyg]

I developed it directly with hardware. I can't do some tests, such as int32 / uint32 / float.

I can't test AO. My current PLC does not support AO.

[darcyg]

DO/DI handling uint8/int8 is problematic.. The PLC in the picture is the hardware I use. The above indicator shows the status of 12 D0 should be 0,0,0,0,0,1,0,1,1,1,1,1 The data read out with your code is 1,0,1,0,0,0,0,0,0,0,0,0

[darcyg]

This is a screenshot of the DO status I read with third-party software tool: https://www.modbusdriver.com/modpoll.html

[jeroenst]

What data is returned when you use the type raw?