At the moment calling SunSpecModbusClientDevice.scan with connect=True (the default) will cause any existing TCP connections to be closed (with a new connection being opened and then closed within the method call). Because this leaves the device in a disconnected state, each subsequent operation also reverts to the "open a temporary connection for the duration of this command" mode too.
It would be ideal if SunSpecModbusClientDevice.scan were to use (and not close) an existing connection when the connect=True argument is passed.
Aside: Why do I care so much?
Accidentally reverting to a connection-per-command mode has a number of disadvantages:
- It adds extra network-round-trips of latency to each operation
- It adds extra load on the remote device which may be relatively resource constrained (this is especially true when TLS is used)
- Using a long-running TCP connection allows you to detect remote device restarts during which the device map may have changed (e.g. after a firmware update). If a single TCP connection is used, the connection error after the connection is closed provides an indication that a new
scan is might be needed.
At the moment calling SunSpecModbusClientDevice.scan with
connect=True(the default) will cause any existing TCP connections to be closed (with a new connection being opened and then closed within the method call). Because this leaves the device in a disconnected state, each subsequent operation also reverts to the "open a temporary connection for the duration of this command" mode too.It would be ideal if SunSpecModbusClientDevice.scan were to use (and not close) an existing connection when the
connect=Trueargument is passed.Aside: Why do I care so much?
Accidentally reverting to a connection-per-command mode has a number of disadvantages:
scanis might be needed.