It could be the TimeoutException isn’t handled in a way to recover from it. So the bridge stays in a zombie state. In such case only a restart will fix it. What you can do is to set log level for the binding to debug to to see if you get any additional info when it happens. (Looking in the code it should try to restart in such case, which would be shown in debug log, but somehow this isn’t recovering the connection).
Thanks for your hints. Found the following sequence within the openhab.log. It seems that not only the innogy binding is affected. Also the http binding. See messages arround web socket and SSL exceptions. These are the first log lines after a new IP was assigned to the Fritzbox (once per night). Hopefully this provides additional information to you?
2020-12-24 03:01:49.572 [INFO ] [io.openhabcloud.internal.CloudClient] - Disconnected from the openHAB Cloud service (UUID = xxxxxx, base URL = http://localhost:8080)
2020-12-24 03:01:54.243 [INFO ] [io.openhabcloud.internal.CloudClient] - Connected to the openHAB Cloud service (UUID = xxxxxx, base URL = http://localhost:8080)
2020-12-24 03:02:59.890 [ERROR] [org.openhab.io.net.http.HttpUtil ] - Fatal transport error: java.net.ConnectException: Connection timed out: connect
2020-12-24 03:02:59.890 [ERROR] [ab.binding.http.internal.HttpBinding] - No response received from ‘https://xxxxxx.myfritz.net:46662/nas/filelink.lua?id=xxxxxx’
2020-12-24 03:04:30.384 [INFO ] [b.binding.neato.handler.NeatoHandler] - Will get STATE for Robot Kobold VR200
2020-12-24 03:04:30.686 [INFO ] [b.binding.neato.handler.NeatoHandler] - Successfully got and parsed new state for Kobold VR200
2020-12-24 03:16:20.250 [INFO ] [gysmarthome.internal.InnogyWebSocket] - Connection to innogy Webservice was closed abnormally (code: 1001). Reason: java.util.concurrent.TimeoutException: Idle timeout expired: 900006/900000 ms
2020-12-24 03:30:00.045 [INFO ] [lipse.smarthome.io.net.exec.ExecUtil] - executed commandLine ‘C:\openHAB2\restart_modbus.bat’
2020-12-24 03:30:02.788 [WARN ] [shd.server.session.ServerSessionImpl] - exceptionCaught(ServerSessionImpl[openhab@/127.0.0.1:51554])[state=Opened] IOException: Eine vorhandene Verbindung wurde vom Remotehost geschlossen
2020-12-24 03:59:29.182 [ERROR] [io.openhabcloud.internal.CloudClient] - Error connecting to the openHAB Cloud instance: {}
io.socket.engineio.client.EngineIOException: websocket error
at io.socket.engineio.client.Transport.onError(Transport.java:63) [bundleFile:?]
at io.socket.engineio.client.transports.WebSocket.access$400(WebSocket.java:24) [bundleFile:?]
at io.socket.engineio.client.transports.WebSocket$1$5.run(WebSocket.java:107) [bundleFile:?]
at io.socket.thread.EventThread$2.run(EventThread.java:80) [bundleFile:?]
at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source) [?:1.8.0_271]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source) [?:1.8.0_271]
at java.lang.Thread.run(Unknown Source) [?:1.8.0_271]
Caused by: javax.net.ssl.SSLException: java.net.SocketException: Connection reset
at sun.security.ssl.Alert.createSSLException(Unknown Source) ~[?:1.8.0_271]
at sun.security.ssl.TransportContext.fatal(Unknown Source) ~[?:1.8.0_271]
at sun.security.ssl.TransportContext.fatal(Unknown Source) ~[?:1.8.0_271]
at sun.security.ssl.TransportContext.fatal(Unknown Source) ~[?:1.8.0_271]
at sun.security.ssl.SSLSocketImpl.handleException(Unknown Source) ~[?:1.8.0_271]
at sun.security.ssl.SSLSocketImpl.access$400(Unknown Source) ~[?:1.8.0_271]
at sun.security.ssl.SSLSocketImpl$AppInputStream.read(Unknown Source) ~[?:1.8.0_271]
Solved my issue going through my changes which i carried out within the last couple of months since the issue ocurred.
@Hilbrand and @cweitkamp
It is primarily neither the innogy binding nor the http binding which caused the problem. Disabled a rule based on a FritzBox thing (DECT 400 switch of the AVM Fritz! Binding) and increased the poll time in the AVM Fritz! Binding from 5 to 15 secs (= default) again.
Now openHAB (2.5.12 snapshot #263 on Windows 10) is stable again and keeps alive after assignment of a new IP every night.
I have trouble with the innogy binding sometimes, too. Restart helped but since I have no rules in openhab (3), Willibald’s explanation doesn’t fit here, so there seem to be other/additional problems…