MODBUS - TCP - Close Connection After Polling

I have a working MODBUS TCP connection to an ESP-32 “slave” which is running the Arduino version of MODBUS-slave.

Home Assistant (as well as the open-source Rapid Scada software) is working to poll various “sensors” from the ESP-32 device.

However, it appears that he Home Assistant implementation of MODBUS (tcp) keeps the TCP connection to the device “open” after initial connection and polling. This causes issues with the ESP-32 MODBUS library which, by default, uses this condition to stay in the loop listening for requests in the tcp buffer:

while (client.connected())

Can a boolean flag/feature similar to Rapid Scada “Stay Connected” [true/false] be added to the MODBUS code?

If [false] this additional connection flag/property would have the tcp session CLOSE after receiving/sending the MODBUS payload to the MODBUS slave.

Thanks for the consideration.

Yes.

Thank you.

I read that documentation very thoroughly.

…could find no “disconnect after polling” property.

Did I miss it?

Only this close_comm_on_error

It may help or not

That is non standard modbus behavior. While I’m sure the integration could be enhanced to fix this, a better fix would be on the ESP side to make the implementation more standard.

Yeah, I would have to agree with you, but figured it worth asking.

Thanks for the reply.

It also seems to me that this could be the explanation for the error I have. A device is given, the communication of which periodically throws an error during the query. The problem is that if you use this device, e.g. I configure it as a climate device, the value -1 appears on the dashboard when the device to be queried breaks the communication. In my case, the device is not open source, and I don’t have a way to set up modbus, so it would be good if the tcp connection was not reserved from the HA’s side, but closed properly after a query and reopened to another query.

This is what the log looks like during a normal query and sometimes “Connection unexpectedly closed” appears:


2023-12-21 10:19:04.989 DEBUG (SyncWorker_7) [pymodbus.logging] Connection to Modbus server established. Socket ('192.168.8.y', 56938)

2023-12-21 10:19:04.989 INFO (SyncWorker_7) [homeassistant.components.modbus.modbus] modbus modbus_hub communication open

...

2023-12-21 10:21:16.001 DEBUG (SyncWorker_11) [pymodbus.logging] Current transaction state - TRANSACTION_COMPLETE

2023-12-21 10:21:16.001 DEBUG (SyncWorker_11) [pymodbus.logging] Running transaction 2

2023-12-21 10:21:16.001 DEBUG (SyncWorker_11) [pymodbus.logging] SEND: 0x0 0x2 0x0 0x0 0x0 0x6 0x0 0x3 0x1 0x1a 0x0 0x1

2023-12-21 10:21:16.001 DEBUG (SyncWorker_11) [pymodbus.logging] New Transaction state "SENDING"

2023-12-21 10:21:16.001 DEBUG (SyncWorker_11) [pymodbus.logging] Changing transaction state from "SENDING" to "WAITING FOR REPLY"

2023-12-21 10:21:16.002 ERROR (SyncWorker_11) [homeassistant.components.modbus.modbus] Pymodbus: modbus_hub: Error: device: 0 address: 282 -> Modbus Error: [Connection] ModbusTcpClient(192.168.8.x:502): Connection unexpectedly closed 0.0006918907165527344 seconds into read of 8 bytes without response from slave before it closed connection

2023-12-21 10:21:17.036 DEBUG (SyncWorker_8) [pymodbus.logging] Connection to Modbus server established. Socket ('192.168.8.y', 34948)

2023-12-21 10:21:17.036 DEBUG (SyncWorker_8) [pymodbus.logging] Current transaction state - WAITING_FOR_REPLY

2023-12-21 10:21:17.036 DEBUG (SyncWorker_8) [pymodbus.logging] Running transaction 3

2023-12-21 10:21:17.036 DEBUG (SyncWorker_8) [pymodbus.logging] SEND: 0x0 0x3 0x0 0x0 0x0 0x6 0x0 0x3 0x1 0x1a 0x0 0x1

2023-12-21 10:21:17.036 DEBUG (SyncWorker_8) [pymodbus.logging] New Transaction state "SENDING"

2023-12-21 10:21:17.036 DEBUG (SyncWorker_8) [pymodbus.logging] Changing transaction state from "SENDING" to "WAITING FOR REPLY"

2023-12-21 10:21:17.039 DEBUG (SyncWorker_8) [pymodbus.logging] Changing transaction state from "WAITING FOR REPLY" to "PROCESSING REPLY"

2023-12-21 10:21:17.039 DEBUG (SyncWorker_8) [pymodbus.logging] RECV: 0x0 0x3 0x0 0x0 0x0 0x5 0x0 0x3 0x2 0x0 0xd2

2023-12-21 10:21:17.039 DEBUG (SyncWorker_8) [pymodbus.logging] Processing: 0x0 0x3 0x0 0x0 0x0 0x5 0x0 0x3 0x2 0x0 0xd2

2023-12-21 10:21:17.039 DEBUG (SyncWorker_8) [pymodbus.logging] Factory Response[ReadHoldingRegistersResponse': 3]

2023-12-21 10:21:17.039 DEBUG (SyncWorker_8) [pymodbus.logging] Adding transaction 3

2023-12-21 10:21:17.039 DEBUG (SyncWorker_8) [pymodbus.logging] Getting transaction 3

2023-12-21 10:21:17.039 DEBUG (SyncWorker_8) [pymodbus.logging] Changing transaction state from "PROCESSING REPLY" to "TRANSACTION_COMPLETE"

Moreover, here is a more detailed error description, so that someone else has the same problem (I’m also looking for a solution to this):

Does anyone have any suggestions as to how this problem could be remedied by e.g. not cause a change in the state of the sensor?

Dear all,

I use the Modbus with a SolvisMax SC2 heating system. Coming from FHEM, closing the connection solved all issues; I am looking for the same on Homeassistant.

Is there a way to tell the modbus integration to close the connection after polling one or more values?

It seems that the Solvis Control system has been implemented with limited „love“.

Best

That would require a code update. I’d submit an issue on GitHub and provide the diagnostic and logs described in the docs Modbus - Home Assistant