Can't reconnect with TCP client

[David-]

Hello,

Our electrical service provider deployed home-made electrical consumption monitoring devices (I don't know the hardware used). We abandoned their supervision tool and used Zabbix to get the values via modbus, without problems. Zabbix use Go code in its agent2 (https://git.zabbix.com/projects/ZBX/repos/zabbix/browse/src/go/plugins/modbus).

We are testing Home Assistant to provide a more user-friendly interface to show the basic breakdown of power consumption. But Home Assistant only managed to get one value after each reboot.
I've tested with "KScada Modbus Doctor" and I get a similar behaviour: I only get values if I check "Reconnexion auto" to reconnect automatically before each reading.

I've seen the modbus "integration" of Home Assistant use the async clients of this pymodbus library (https://github.com/home-assistant/core/blob/dev/homeassistant/components/modbus/modbus.py).
So I've made a basic test:

import asyncio
from time import sleep

from pymodbus import pymodbus_apply_logging_config, ModbusException
from pymodbus.client import AsyncModbusTcpClient


async def main():
    pymodbus_apply_logging_config("DEBUG")
    print("get client")
    client = AsyncModbusTcpClient('192.168.120.11')

    print("connect to server")
    await client.connect()
    await read(client, 1703)
    await read(client, 1704)
    await read(client, 1705)
    sleep(0.5)
    await read(client, 1703)
    await read(client, 1704)
    await read(client, 1705)
    sleep(0.5)
    await client.connect()
    await read(client, 1703)
    await read(client, 1704)
    await read(client, 1705)


async def read(client: AsyncModbusTcpClient, address: int):
    print("get and verify data")
    try:
        rr = await client.read_holding_registers(address, count=1)
    except ModbusException as exc:
        print(f"Received ModbusException({exc}) from library")
        client.close()
        return
    if rr.isError():
        print(f"Received exception from device ({rr})")
        # THIS IS NOT A PYTHON EXCEPTION, but a valid modbus message
        client.close()
        return
    value_int16 = client.convert_from_registers(rr.registers, data_type=client.DATATYPE.INT16)
    print(f"Got int16: {value_int16}")

asyncio.run(
    main()
)

modbus.py.txt

And I get this on a Debian Linux (with Python 3.11 and pymodbus 3.8.6):

get client
connect to server
2025-03-31 08:53:25,877 DEBUG base:56 Connecting to 192.168.120.11:502.
2025-03-31 08:53:25,877 DEBUG transport:242 Connecting comm
2025-03-31 08:53:25,878 DEBUG transport:277 Connected to comm
get and verify data
2025-03-31 08:53:25,979 DEBUG transport:386 send: 0x0 0x1 0x0 0x0 0x0 0x6 0x1 0x3 0x6 0xa7 0x0 0x1
2025-03-31 08:53:25,981 DEBUG transport:329 recv: 0x0 0x1 0x0 0x0 0x0 0x5 0x1 0x3 0x2 0x0 0x1e old_data:  addr=None
2025-03-31 08:53:25,981 DEBUG base:91 Processing: 0x0 0x1 0x0 0x0 0x0 0x5 0x1 0x3 0x2 0x0 0x1e
2025-03-31 08:53:25,981 DEBUG decoders:113 decoded PDU function_code(3 sub -1) -> ReadHoldingRegistersResponse(dev_id=0, transaction_id=0, address=0, count=0, bits=[], registers=[30], status=1)
2025-03-31 08:53:25,981 DEBUG base:101 Frame advanced, resetting header!!
Got int16: 30
get and verify data
2025-03-31 08:53:25,981 DEBUG transport:386 send: 0x0 0x2 0x0 0x0 0x0 0x6 0x1 0x3 0x6 0xa8 0x0 0x1
2025-03-31 08:53:25,987 DEBUG transport:329 recv: 0x0 0x2 0x0 0x0 0x0 0x5 0x1 0x3 0x2 0x0 0x26 old_data:  addr=None
2025-03-31 08:53:25,987 DEBUG base:91 Processing: 0x0 0x2 0x0 0x0 0x0 0x5 0x1 0x3 0x2 0x0 0x26
2025-03-31 08:53:25,987 DEBUG decoders:113 decoded PDU function_code(3 sub -1) -> ReadHoldingRegistersResponse(dev_id=0, transaction_id=0, address=0, count=0, bits=[], registers=[38], status=1)
2025-03-31 08:53:25,987 DEBUG base:101 Frame advanced, resetting header!!
Got int16: 38
get and verify data
2025-03-31 08:53:25,987 DEBUG transport:386 send: 0x0 0x3 0x0 0x0 0x0 0x6 0x1 0x3 0x6 0xa9 0x0 0x1
2025-03-31 08:53:25,993 DEBUG transport:329 recv: 0x0 0x3 0x0 0x0 0x0 0x5 0x1 0x3 0x2 0x0 0x2b old_data:  addr=None
2025-03-31 08:53:25,993 DEBUG base:91 Processing: 0x0 0x3 0x0 0x0 0x0 0x5 0x1 0x3 0x2 0x0 0x2b
2025-03-31 08:53:25,993 DEBUG decoders:113 decoded PDU function_code(3 sub -1) -> ReadHoldingRegistersResponse(dev_id=0, transaction_id=0, address=0, count=0, bits=[], registers=[43], status=1)
2025-03-31 08:53:25,994 DEBUG base:101 Frame advanced, resetting header!!
Got int16: 43
get and verify data
2025-03-31 08:53:26,495 DEBUG transport:386 send: 0x0 0x4 0x0 0x0 0x0 0x6 0x1 0x3 0x6 0xa7 0x0 0x1
2025-03-31 08:53:26,496 DEBUG transport:289 Connection lost comm due to [Errno 104] Connection reset by peer
2025-03-31 08:53:26,496 DEBUG transport:480 Wait comm 100.0 ms before reconnecting.
2025-03-31 08:53:26,597 DEBUG transport:242 Connecting comm
2025-03-31 08:53:26,598 DEBUG transport:277 Connected to comm
2025-03-31 08:53:29,499 DEBUG transport:386 send: 0x0 0x4 0x0 0x0 0x0 0x6 0x1 0x3 0x6 0xa7 0x0 0x1
2025-03-31 08:53:29,500 DEBUG transport:289 Connection lost comm due to [Errno 104] Connection reset by peer
2025-03-31 08:53:29,500 DEBUG transport:480 Wait comm 100.0 ms before reconnecting.
2025-03-31 08:53:29,600 DEBUG transport:242 Connecting comm
2025-03-31 08:53:29,602 DEBUG transport:277 Connected to comm
2025-03-31 08:53:32,503 DEBUG transport:386 send: 0x0 0x4 0x0 0x0 0x0 0x6 0x1 0x3 0x6 0xa7 0x0 0x1
2025-03-31 08:53:32,504 DEBUG transport:289 Connection lost comm due to [Errno 104] Connection reset by peer
2025-03-31 08:53:32,504 DEBUG transport:480 Wait comm 100.0 ms before reconnecting.
2025-03-31 08:53:32,604 DEBUG transport:242 Connecting comm
2025-03-31 08:53:32,607 DEBUG transport:277 Connected to comm
2025-03-31 08:53:35,507 DEBUG transport:386 send: 0x0 0x4 0x0 0x0 0x0 0x6 0x1 0x3 0x6 0xa7 0x0 0x1
2025-03-31 08:53:35,509 DEBUG transport:289 Connection lost comm due to [Errno 104] Connection reset by peer
2025-03-31 08:53:35,509 DEBUG transport:480 Wait comm 100.0 ms before reconnecting.
2025-03-31 08:53:35,609 DEBUG transport:242 Connecting comm
2025-03-31 08:53:35,611 DEBUG transport:277 Connected to comm
2025-03-31 08:53:38,511 ERROR transaction:163 No response received after 3 retries, continue with next request
Received ModbusException(Modbus Error: [Input/Output] No response received after 3 retries, continue with next request) from library
get and verify data
Received ModbusException(Modbus Error: [Connection] Not connected[AsyncModbusTcpClient 192.168.120.11:502]) from library
get and verify data
Received ModbusException(Modbus Error: [Connection] Not connected[AsyncModbusTcpClient 192.168.120.11:502]) from library
2025-03-31 08:53:39,011 DEBUG base:56 Connecting to 192.168.120.11:502.
2025-03-31 08:53:39,011 DEBUG transport:242 Connecting comm
2025-03-31 08:53:39,013 DEBUG transport:277 Connected to comm
get and verify data
2025-03-31 08:53:39,113 DEBUG transport:386 send: 0x0 0x1 0x0 0x0 0x0 0x6 0x1 0x3 0x6 0xa7 0x0 0x1
2025-03-31 08:53:39,116 DEBUG transport:329 recv: 0x0 0x1 0x0 0x0 0x0 0x5 0x1 0x3 0x2 0x0 0x1e old_data:  addr=None
2025-03-31 08:53:39,116 DEBUG base:91 Processing: 0x0 0x1 0x0 0x0 0x0 0x5 0x1 0x3 0x2 0x0 0x1e
2025-03-31 08:53:39,116 DEBUG decoders:113 decoded PDU function_code(3 sub -1) -> ReadHoldingRegistersResponse(dev_id=0, transaction_id=0, address=0, count=0, bits=[], registers=[30], status=1)
2025-03-31 08:53:39,116 DEBUG base:101 Frame advanced, resetting header!!
Got int16: 30
get and verify data
2025-03-31 08:53:39,116 DEBUG transport:386 send: 0x0 0x2 0x0 0x0 0x0 0x6 0x1 0x3 0x6 0xa8 0x0 0x1
2025-03-31 08:53:39,122 DEBUG transport:329 recv: 0x0 0x2 0x0 0x0 0x0 0x5 0x1 0x3 0x2 0x0 0x26 old_data:  addr=None
2025-03-31 08:53:39,122 DEBUG base:91 Processing: 0x0 0x2 0x0 0x0 0x0 0x5 0x1 0x3 0x2 0x0 0x26
2025-03-31 08:53:39,122 DEBUG decoders:113 decoded PDU function_code(3 sub -1) -> ReadHoldingRegistersResponse(dev_id=0, transaction_id=0, address=0, count=0, bits=[], registers=[38], status=1)
2025-03-31 08:53:39,122 DEBUG base:101 Frame advanced, resetting header!!
Got int16: 38
get and verify data
2025-03-31 08:53:39,122 DEBUG transport:386 send: 0x0 0x3 0x0 0x0 0x0 0x6 0x1 0x3 0x6 0xa9 0x0 0x1
2025-03-31 08:53:39,128 DEBUG transport:329 recv: 0x0 0x3 0x0 0x0 0x0 0x5 0x1 0x3 0x2 0x0 0x2b old_data:  addr=None
2025-03-31 08:53:39,128 DEBUG base:91 Processing: 0x0 0x3 0x0 0x0 0x0 0x5 0x1 0x3 0x2 0x0 0x2b
2025-03-31 08:53:39,128 DEBUG decoders:113 decoded PDU function_code(3 sub -1) -> ReadHoldingRegistersResponse(dev_id=0, transaction_id=0, address=0, count=0, bits=[], registers=[43], status=1)
2025-03-31 08:53:39,128 DEBUG base:101 Frame advanced, resetting header!!
Got int16: 43

and on Windows (with Python 3.13 and pymodbus 3.8.6):

get client
connect to server
2025-03-31 08:45:21,168 DEBUG base:56 Connecting to 192.168.120.11:502.
2025-03-31 08:45:21,168 DEBUG transport:242 Connecting comm
2025-03-31 08:45:21,170 DEBUG transport:277 Connected to comm
2025-03-31 08:45:21,273 DEBUG transport:386 send: 0x0 0x1 0x0 0x0 0x0 0x6 0x1 0x3 0x6 0xa7 0x0 0x1
2025-03-31 08:45:21,278 DEBUG transport:329 recv: 0x0 0x1 0x0 0x0 0x0 0x5 0x1 0x3 0x2 0x0 0x1e old_data:  addr=None
2025-03-31 08:45:21,278 DEBUG base:91 Processing: 0x0 0x1 0x0 0x0 0x0 0x5 0x1 0x3 0x2 0x0 0x1e
2025-03-31 08:45:21,279 DEBUG decoders:113 decoded PDU function_code(3 sub -1) -> ReadHoldingRegistersResponse(dev_id=0, transaction_id=0, address=0, count=0, bits=[], registers=[30], status=1) 
2025-03-31 08:45:21,279 DEBUG base:101 Frame advanced, resetting header!!
2025-03-31 08:45:21,279 DEBUG transport:386 send: 0x0 0x2 0x0 0x0 0x0 0x6 0x1 0x3 0x6 0xa8 0x0 0x1
get and verify data
Got int16: 30
get and verify data
Got int16: 38
get and verify data
2025-03-31 08:45:21,284 DEBUG transport:329 recv: 0x0 0x2 0x0 0x0 0x0 0x5 0x1 0x3 0x2 0x0 0x26 old_data:  addr=None
2025-03-31 08:45:21,284 DEBUG base:91 Processing: 0x0 0x2 0x0 0x0 0x0 0x5 0x1 0x3 0x2 0x0 0x26
2025-03-31 08:45:21,284 DEBUG decoders:113 decoded PDU function_code(3 sub -1) -> ReadHoldingRegistersResponse(dev_id=0, transaction_id=0, address=0, count=0, bits=[], registers=[38], status=1) 
2025-03-31 08:45:21,284 DEBUG base:101 Frame advanced, resetting header!!
2025-03-31 08:45:21,284 DEBUG transport:386 send: 0x0 0x3 0x0 0x0 0x0 0x6 0x1 0x3 0x6 0xa9 0x0 0x1
2025-03-31 08:45:21,289 DEBUG transport:329 recv: 0x0 0x3 0x0 0x0 0x0 0x5 0x1 0x3 0x2 0x0 0x2b old_data:  addr=None
2025-03-31 08:45:21,290 DEBUG base:91 Processing: 0x0 0x3 0x0 0x0 0x0 0x5 0x1 0x3 0x2 0x0 0x2b
2025-03-31 08:45:21,290 DEBUG decoders:113 decoded PDU function_code(3 sub -1) -> ReadHoldingRegistersResponse(dev_id=0, transaction_id=0, address=0, count=0, bits=[], registers=[43], status=1) 
2025-03-31 08:45:21,290 DEBUG base:101 Frame advanced, resetting header!!
Got int16: 43
get and verify data
2025-03-31 08:45:21,791 DEBUG transport:386 send: 0x0 0x4 0x0 0x0 0x0 0x6 0x1 0x3 0x6 0xa7 0x0 0x1
2025-03-31 08:45:21,795 DEBUG transport:289 Connection lost comm due to [WinError 64] Le nom réseau spécifié n’est plus disponible
2025-03-31 08:45:21,795 DEBUG transport:480 Wait comm 100.0 ms before reconnecting.
2025-03-31 08:45:21,903 DEBUG transport:242 Connecting comm
2025-03-31 08:45:21,905 DEBUG transport:277 Connected to comm
2025-03-31 08:45:24,800 DEBUG transport:386 send: 0x0 0x4 0x0 0x0 0x0 0x6 0x1 0x3 0x6 0xa7 0x0 0x1
2025-03-31 08:45:24,802 DEBUG transport:289 Connection lost comm due to [WinError 64] Le nom réseau spécifié n’est plus disponible
2025-03-31 08:45:24,802 DEBUG transport:480 Wait comm 100.0 ms before reconnecting.
2025-03-31 08:45:24,909 DEBUG transport:242 Connecting comm
2025-03-31 08:45:24,911 DEBUG transport:277 Connected to comm
2025-03-31 08:45:27,809 DEBUG transport:386 send: 0x0 0x4 0x0 0x0 0x0 0x6 0x1 0x3 0x6 0xa7 0x0 0x1
2025-03-31 08:45:27,811 DEBUG transport:289 Connection lost comm due to [WinError 64] Le nom réseau spécifié n’est plus disponible
2025-03-31 08:45:27,812 DEBUG transport:480 Wait comm 100.0 ms before reconnecting.
2025-03-31 08:45:27,916 DEBUG transport:242 Connecting comm
2025-03-31 08:45:27,920 DEBUG transport:277 Connected to comm
2025-03-31 08:45:30,822 DEBUG transport:386 send: 0x0 0x4 0x0 0x0 0x0 0x6 0x1 0x3 0x6 0xa7 0x0 0x1
2025-03-31 08:45:30,824 DEBUG transport:289 Connection lost comm due to [WinError 64] Le nom réseau spécifié n’est plus disponible
2025-03-31 08:45:30,824 DEBUG transport:480 Wait comm 100.0 ms before reconnecting.
2025-03-31 08:45:30,930 DEBUG transport:242 Connecting comm
2025-03-31 08:45:30,933 DEBUG transport:277 Connected to comm
2025-03-31 08:45:33,833 ERROR transaction:163 No response received after 3 retries, continue with next request
Received ModbusException(Modbus Error: [Input/Output] No response received after 3 retries, continue with next request) from library
get and verify data
Received ModbusException(Modbus Error: [Connection] Not connected[AsyncModbusTcpClient 192.168.120.11:502]) from library
get and verify data
Received ModbusException(Modbus Error: [Connection] Not connected[AsyncModbusTcpClient 192.168.120.11:502]) from library
2025-03-31 08:45:34,334 DEBUG base:56 Connecting to 192.168.120.11:502.
2025-03-31 08:45:34,334 DEBUG transport:242 Connecting comm
2025-03-31 08:45:34,337 DEBUG transport:277 Connected to comm
2025-03-31 08:45:34,441 DEBUG transport:386 send: 0x0 0x1 0x0 0x0 0x0 0x6 0x1 0x3 0x6 0xa7 0x0 0x1
2025-03-31 08:45:34,448 DEBUG transport:329 recv: 0x0 0x1 0x0 0x0 0x0 0x5 0x1 0x3 0x2 0x0 0x1e old_data:  addr=None
2025-03-31 08:45:34,448 DEBUG base:91 Processing: 0x0 0x1 0x0 0x0 0x0 0x5 0x1 0x3 0x2 0x0 0x1e
2025-03-31 08:45:34,448 DEBUG decoders:113 decoded PDU function_code(3 sub -1) -> ReadHoldingRegistersResponse(dev_id=0, transaction_id=0, address=0, count=0, bits=[], registers=[30], status=1) 
2025-03-31 08:45:34,448 DEBUG base:101 Frame advanced, resetting header!!
2025-03-31 08:45:34,448 DEBUG transport:386 send: 0x0 0x2 0x0 0x0 0x0 0x6 0x1 0x3 0x6 0xa8 0x0 0x1
get and verify data
Got int16: 30
get and verify data
Got int16: 38
get and verify data
Got int16: 43
2025-03-31 08:45:34,453 DEBUG transport:329 recv: 0x0 0x2 0x0 0x0 0x0 0x5 0x1 0x3 0x2 0x0 0x26 old_data:  addr=None
2025-03-31 08:45:34,453 DEBUG base:91 Processing: 0x0 0x2 0x0 0x0 0x0 0x5 0x1 0x3 0x2 0x0 0x26
2025-03-31 08:45:34,453 DEBUG decoders:113 decoded PDU function_code(3 sub -1) -> ReadHoldingRegistersResponse(dev_id=0, transaction_id=0, address=0, count=0, bits=[], registers=[38], status=1) 
2025-03-31 08:45:34,453 DEBUG base:101 Frame advanced, resetting header!!
2025-03-31 08:45:34,453 DEBUG transport:386 send: 0x0 0x3 0x0 0x0 0x0 0x6 0x1 0x3 0x6 0xa9 0x0 0x1
2025-03-31 08:45:34,459 DEBUG transport:329 recv: 0x0 0x3 0x0 0x0 0x0 0x5 0x1 0x3 0x2 0x0 0x2b old_data:  addr=None
2025-03-31 08:45:34,459 DEBUG base:91 Processing: 0x0 0x3 0x0 0x0 0x0 0x5 0x1 0x3 0x2 0x0 0x2b
2025-03-31 08:45:34,459 DEBUG decoders:113 decoded PDU function_code(3 sub -1) -> ReadHoldingRegistersResponse(dev_id=0, transaction_id=0, address=0, count=0, bits=[], registers=[43], status=1) 
2025-03-31 08:45:34,459 DEBUG base:101 Frame advanced, resetting header!!

I'm able to believe the modbus support of this home-made device is faulty. But why pymodbus is able to connect but not to reconnect?
If this can be resolved in pymodbus, the Home Assistant integration will be functional as-is. Otherwise, I will have to try to make them add an option to explicitly connect (and not reconnect) before each read, like Modbus Doctor.

Thank you for reading this far. :)

[maximeLeurent]

Hello,

I am recently facing issue with the reconnection, and i also receive "Connection reset by peer"

i am using pymodbus 3.7.4 with python in 3.11.11. Running in a docker Debian

[janiversen]

First of all this is not the HA project....and HA is really using an old release.

You do not write which version of pymodbus you use, but first part is to upgrade to the latest release.

As you can see in the log pymodbus tries to reconnect, but your device do not accept the connection. You probably need to play with the timeout/retry parameters. As the log shows this is not a pymodbus problem.

[janiversen]

@maximeLeurent please update to the newest release and if the problem persist add a debug log, so we can see what happens.

[maximeLeurent]

Yes i was making my research I saw this update #2501
(I was in progress, it is why I found this issue)
I think it will correct my problem

[David-]

First of all this is not the HA project....and HA is really using an old release.

I know this is not the HA project, but I'm trying to find where my problem is.
Home Assistant currently use pymodbus 3.8.3, indeed, but that's why I made a test with the latest version 3.8.6 before writing this ticket. I reproduce my problem with a basic example and the last version so I opened an issue here.

You do not write which version of pymodbus you use, but first part is to upgrade to the latest release.

I do write which version of pymodbus I use: it's the version 3.8.6 and it's the current latest release.

As you can see in the log pymodbus tries to reconnect, but your device do not accept the connection. You probably need to play with the timeout/retry parameters. As the log shows this is not a pymodbus problem.

I can connect() again immediately as after several seconds and in-between. But the automatic reconnect can't reconnect, even with testing several values for reconnect_delay, timeout or retries.
With this hardware, I never managed to made it reconnect and always succeeded in connect, and I find this... weird.

[janiversen]

If you can connect again after several seconds, then the reconnect will also work after several seconds....it is the same code being executed.

Your example code is ok, no need to reduce that further, it clearly shows your device not responding.

[janiversen]

Please be aware that #2501 was wrong and is corrected in a later commit, both are in v3.8.6

[David-]

If you can connect again after several seconds, then the reconnect will also work after several seconds....it is the same code being executed.

I don't understand you here. My example of code and the logs show that reading several values in line is working, but after waiting at least 0.5 second (the time to lose the connection, I suppose) the next reading and the reconnecting are not working, but connect()ing again is working.
What I see is that the reconnect don't work while explicitly connect again do. Every time.
Which is the precisely the problem I'm trying to bring with this issue.

Your example code is ok, no need to reduce that further, it clearly shows your device not responding.

This device might be badly engineered, but the proprietary software works with it, as is Zabbix modbus plugin. The only thing that is not working between this device and the pymodbus library seems to be the reconnection.

[David-]

I don't understand how the test if not self.transport: can check if the connection is operational. Or what you want pymodbus to manage at its level.
Maybe what I need is an option to connect (and disconnect) for each reading, as KScala Modbus Doctor, Zabbix or pyModbusTCP offer. But maybe you prefer the application to handle this?

[janiversen]

You might not understand how "if not self.transport" can check if the connection is operational, the reason however is simple, that is NOT what that "if" does, the check is done at a lower level.

I have no idea what option you are looking for, if you want that you simply do a close/connect.

It seems your device disconnects very rapidly normally it is 30-60 seconds, NOT 0.5 second. But the question is not when it disconnects but when it accept connections again, and for that you need to play with timeout/retry.

Of course I assume we are only talking about v3.8.6 because in v3.8.3 there are known reconnect problems.

[David-]

It seems your device disconnects very rapidly normally it is 30-60 seconds, NOT 0.5 second. But the question is not when it disconnects but when it accept connections again, and for that you need to play with timeout/retry.

The device always accept my connections and any read following the last request in less than 0.5 second, from my tests. After that, a new connection is mandatory.

I have no idea what option you are looking for, if you want that you simply do a close/connect.

I want to get my data from my device from Home Assistant. Home Assistant use pymodbus. pymodbus can't reconnect itself to my device before read, and Home Assistant don't either. So Home Assistant can only read one value per boot.
pyModbusTCP has options to auto_open and/or auto_close TCP connection for each request.

Of course I assume we are only talking about v3.8.6 because in v3.8.3 there are known reconnect problems.

Yes, I'm talking about v3.8.6 and newer. And if my problem with Home Assistant was just an old version of a library, I would talk with them to update.

So my question for you is: do you want pymodbus to handle the case where a device need a reconnection if no request had been made for 0.5 second?
By adding an option allowing the app to ask a reconnection before each request, or by detecting the lost of the connection with this type of device, or by adding an option to specify the time limit between request before reconnecting, or something else I don't know.

If you don't want it inside pymodbus, I will see with the Modbus integration of Home Assistant if they want to handle this at their level, and if not to write our integration with pyModbusTCP but this would be silly.

[janiversen]

As far as I know "do you want pymodbus to handle the case where a device need a reconnection if no request had been made for 0.5 second" is already handled....because if the device needs a reconnect it have closed the connection, which start the reconnect task. If your device do not close the connection, but silently demands a new connection, then it is something you should do in the app.

"By adding an option allowing the app to ask a reconnection before each request" such an option do not make sense, the app should simply do a close/connect....in other words this is not an option that belongs in pymodbus.

"option to specify the time limit between request before reconnecting", this is also something the app can handle a lot better than pymodbus.

Good luck with the modbus integration, I am not sure there are any active maintainers. I maintained the integration during years, but decided to leave due to the demands from the core developers. Today I run a custom version, because 3.8.6 contains a number of important fixes.

Finally pymodbusTCP is not this project, so I have no idea if that helps or not.

[janiversen]

just for the record, even if pymodbus got these options implemented, you would still need the modbus integration updated to the new version and have the options implemented in the yaml configuration.

[janiversen]

As I suspected, there are currently 40 open issues in HA mentioning modes....so at the very least it is not very actively maintained.

A number of the issues seems to be because the integration was upgraded from pymodbus v3.7.4 to v3.8.3 without updating the code to use the features of the v3.8 line (at least as I remember the code).

[janiversen]

Closing, as this is an issue to be handled in the app.