Since you’ve mentioned some devices allows only one connection, If OH2 is the only master polling that device, and that device is having the CLOSE_WAIT behavior; whether reconnectAfterMillis is set to 0 or 86400000 (a day), there will be a moment where max connections (in our case 1) is reach and comms will be lost, which is not ideal, since we don’t know when exactly the misbehaving slave device will eventually drop the CLOSE_WAIT session.
Yes indeed, if the slave has a problem then that one-connection limitation makes it a bigger problem. One way to mitigate that is to use the reconnectAfterMillis parameter.
There is no way to remotely fix that slaves problem from openHAB. It will experience the same problem in any other environment. Not sure where we’re going with this.
add an option to keep the connection open?
reconnectAfterMillis = -1 lol or add a new parameter for the tcp bridge in the binding.
I am personally using the binding with a plc slave that accepts only one connection. There are times when connection fails (I presume due to plc interrupt cycle, could be what you mentioned as well) but that no issue at all. You can retry the connection couple of times.
If you really like to have connection open for a long ime , you can set
2,147,483,647 milliseconds which is many weeks.
It’s currently not possible to have it open forever.
Good point. That can be made configurable if it is an issue. So far I have not heard problems on this
There is actually default of 3 seconds, which is plenty of time