Modbus bridge : forward responses in passive listener / sniffer mode to MQTT

[relyd]

Referring to the excellent work of @jeroenst at https://tasmota.github.io/docs/Modbus-Bridge :

Situation:

• There is a (mandatory) Modbus Master (eg Solar Inverter, EV Charger etc) and a Slave ( eg. power meter)
• We do not control the Master. Master continuously polls the slave (eg Voltage)
• Only one master is allowed on the bus

We would like to like to fetch the responses from the slave and publish for further processing/monitoring, i.e.

• Listen for any response
• Publish response to MQTT

Suggested :

• Tasmota Modbus Bridge listens passively on Modbus for responses only (ModbusMonitor mode)

• You may start/stop Monitor Mode by sending a command like ModbusMonitor2MqttStart , ModbusMonitor2MqttStop

• Starting ModbusMonitor mode would inhibit sending Modbus requests.

• Publish values {[value1,value2,valueN]} in received responses to a MQTT topic

• Suggested topic for values /ModbusBridge/ModbusReceived/DeviceAddress/FunctionCode/StartAddress/ eg
  /ModbusBridge/ModbusReceived/1/5/1/

• Publish raw (hex) responses to a MQTT topic

• Suggested topic for raw /ModbusBridge/ModbusReceivedRaw/

Please let me know your thoughts,

[jeroenst]

Maybe I can create that one day, your request is clear to me.

Separate topics will not be available, messages will be send in json to the same topic (tasmota design). These can be manipulated with nodered for example.

Data wil indeed always be raw bytes because the format is unknown.

Command will be modbusmonitorstart and modbusmonitorstop imo.

Only drawback, I don't have a setup to test this at the moment.

[jeroenst]

1st try, not tested: https://github.com/jeroenst/Tasmota/tree/modbusmonitor

Responses are raw values (not hex).

[analystcmyk]

I am really sorry I missed the update, will compile and test....

[pepelillo]

I would like to test your code, can you give a clue on how to use it? I need a monitor mode, have to put a listener in the middle and it seems to be what I need.

[jeroenst]

You can compile https://github.com/jeroenst/Tasmota/tree/modbusmonitor and install the binairy.

Use modbusmonitorstart command in the console to start monitoring the modbus channel.

[jeroenst]

Do you have any progress on testing? Did you manage to compile the modbusmonitor branch or do you need a binairy for esp8266 or esp32 ?

[pepelillo]

Yes, i have a binary in a wemos, is a 12.5 versión......is weird because the first time i launched the command i see some entries in my mqtt Explorer but after that any updates in the data. I've tried the standard modbustcp Bridge and works as expected. My aim is to have the monitor working and suscribe to some data without using the estándar Bridge and make active queries. The reason is avoid the double máster issues in my bus (i have a máster already id0 and a slave of course id1) I do not see any log in the console when It worked. El 18 de noviembre de 2023 10:37:22 CET, JeroenSt ***@***.***> escribió:

…

Do you have any progress on testing? Did you manage to compile the modbusmonitor branch or do you need a binairy for esp8266 or esp32 ? -- Reply to this email directly or view it on GitHub: #18618 (reply in thread) You are receiving this because you commented. Message ID: ***@***.***>

[jeroenst]

What do you see in the console of Tasmota, are there any modbus errors displayed?

[jeroenst]

Are you using modbusbridge and modbusmonitor simultaneously?

That is not working (yet).

[pepelillo]

In monitor mode nothing at all. Even when I Saw data in mqtt Explorer. El 18 de noviembre de 2023 13:48:12 CET, JeroenSt ***@***.***> escribió:

…

What do you see in the console of Tasmota, are there any modbus errors displayed? -- Reply to this email directly or view it on GitHub: #18618 (reply in thread) You are receiving this because you commented. Message ID: ***@***.***>

[jeroenst]

What is the Loglevel in the console? You can try weblog 4

[pepelillo]

No. I started monitor mode first when It stops working i reset tasmota and uses Bridge mode. Bridge mode worked fine, but the multimaster issues I found. El 18 de noviembre de 2023 13:54:47 CET, JeroenSt ***@***.***> escribió:

…

Are you using modbusbridge and modbusmonitor simultaneously? That is not working (yet). -- Reply to this email directly or view it on GitHub: #18618 (reply in thread) You are receiving this because you commented. Message ID: ***@***.***>

[pepelillo]

I think tha this monitor mode would be very usefull when some kind of not máster Mode is needed. El 18 de noviembre de 2023 13:54:47 CET, JeroenSt ***@***.***> escribió:

…

Are you using modbusbridge and modbusmonitor simultaneously? That is not working (yet). -- Reply to this email directly or view it on GitHub: #18618 (reply in thread) You are receiving this because you commented. Message ID: ***@***.***>

[analystcmyk]

I compiled the branch with gitpod, for ESP-8266 , reporting

Tasmota Version 13.2.0.2(tasmota)-2_7_4_9(2023-11-16T09:28:14)

modbusmonitorstart (loglevel 4) gives

17:19:49.791 CMD: Grp 0, Cmd 'MODBUSMONITORSTART', Idx 1, Len 0, Pld -99, Data '' 17:19:49.796 RSL: RESULT = {"Command":"Unknown"}

My question in order to proceed testing :

• Should this even run on 8266? Considering the modbusbridge should technically not be run on an ESP8266
• I have trouble setting the right compiler options/flags. Could someone add the compiled assets (bin)?
• If possible I would run this on an ESP8266, if not ESP32.

Thank you,

[AndresL71]

did you configure your pins as ModBrTx Rx and Tx ENA?

[jeroenst]

Modbusbridge is currently in use on an esp8266 with a solar inverter at a friend of mine which works flawless. But for monitor mode I don't know if the functionality is ready for use because I don't have a test setup for it.

[ghost]

Can you explain how to config of the pins has to be done in detail?
Which one have to be used?
ModBr Tx
ModBr Tx ENA
ModBr Rx

[AndresL71]

Only getting CRC Errors
in monitor mode in between the master and slave (inverter--meter)
using a rs485 with gnd--DE-RE

16:47:58.216 MBS: MBR Driver receive error 9
16:47:58.573 MBS: MBR Driver receive error 9
16:47:59.134 MBS: MBR Driver receive error 9
16:47:59.475 MBS: MBR Driver receive error 9
16:47:59.633 MBS: MBR Driver receive error 9
16:47:59.778 MBS: MBR Driver receive error 9

any suggestions?

[AndresL71]

Different values…. Same results.

what Hw setup are you using. ?

I am trying to sniff a rs485 channel between a huawei inverter (modus master) and a dsu666 meter (slave)

[danielkucera]

Then it probably doesn't comply to modbus specification what seems quite common, see this part:
https://minimalmodbus.readthedocs.io/en/stable/serialcommunication.html#timing-of-the-serial-communications
One of my devices has following timing, there is only 560us between the messages so a passive listener cannot detect where those messages end - this gives crc error:

But another device I have has a generous delay (30ms) between command and response and is easily decoded:

I don't know how to handle the first situation. One way is maybe ignore the failed checksum (because when you merge two messages, the checksum at the end obviously doesn't match) and send it as one. Or maybe specify how many bytes to expect based on the header but that excludes custom message decoding and would be very complicated.

[danielkucera]

Hi @AndresL71 ,
I tried another approach with checking CRC after each received byte.
Can you try if that works for you?

[AndresL71]

similar results

03:54:41.696 MBS: Serial Received: 0B 03 00 06 00 02 06 1E 0E 0B 03 04 0D 05 11 0A 13 00 09 05 0B 02 00 00 00 1F 02 14 07 11 02 14 07 11 00 00 00 1D 0A 09 05 10 0A 0A 09 05 10 02 00 00 00 1F 0A 14 14 05 1F 0A 14
03:54:41.711 MBS: MBR Driver receive error 9
03:54:41.743 MBS: Serial Received: 14 05 00 00 00 00 1F 1A 11 19 0F 1A 11 19 0F 1A 11 19 0F 00 00 00 02 01 0A 01 1D 0A 06 1F
03:54:41.746 MBS: MBR Driver receive error 9
03:54:41.843 MBS: Serial Received: 0B 03 00 06 10 00 02 0F 06 1F
03:54:41.845 MBS: MBR Driver receive error 9
03:54:41.892 MBS: Serial Received: 0B 03 04 1F 02 14 16 1A 13 1F
03:54:41.895 MBS: MBR Driver receive error 9
03:54:42.143 MBS: Serial Received: 0B 03 00 06 10 00 02 0F 06 1F
03:54:42.145 MBS: MBR Driver receive error 9
03:54:42.192 MBS: Serial Received: 0B 03 04 1F 02 14 16 1A 13 1F
03:54:42.194 MBS: MBR Driver receive error 9
03:54:42.443 MBS: Serial Received: 0B 03 00 06 10 00 02 0F 06 1F

[danielkucera]

@AndresL71 , do you also see some frames correctly received?

To me it seems like some electrical issue because in the data I cannot see any message with a correct CRC.
Unlike in the one you sent earlier: #18618 (reply in thread)