@paolo_denti Darn, you are correct! Obviously that was a mistake - sorry for that!
I think I have deleted those with the following logic
- there is reconnecting parameter already in jamod serving that purpose (but when looking at it, openhab binding has hardcoded default of reconnecting=false
) - various other fixes were done to close connections, for example ModbusTCPSlave did not close the socket on resetConnection, or ModbusXTransport did not close the underlying socket/serial port etc., connections were not closed on update – I concluded that these bugs might have been the reason for the original statement
- connections were not closed with other connections (serial ports for example)
- Honeywell Modbus TCP implementation guide explicitly recommends not to open & close tcp connection on every modbus transaction (see p. 15 of the linked guide)
- Perhaps most importantly, the binding still establishes as many connections as there are slaves defined in openhab.cfg (in the beginning when binding is being configured)
It’s a shame that I commented some of these points to the PR when it had several commits but apparently those are now lost after the commits were squashed into single commit.
Obviously the new behaviour is not good for every use case.
- @walter can you paste your modbus configuration (in openhab.cfg)?
- if I understood correctly, you are reading the modbus also with the external script? If this is the case, I believe the amount of connections is limited in the Modbus TCP server you use?
- Please note the connection pooling I’m working on: if you have many modbus slave definitions in openhab pointing to the same binding, the amount of connections required will much less with connection pooling.
- we might need to re-introduce the old behaviour where connections are closed after every transaction – if we do, I propose we make it configurable