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?