-
-
Notifications
You must be signed in to change notification settings - Fork 3.6k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[modbus] doesn't recover after network errors #18111
Comments
I switched on TRACE log level before restarting the "modbus binding" bundle. This produced of course a lot of log messages, multiple like this:
Look at total time if 17213184ms, which is nearly five hours and corresponds to the time the Modbus binding was not polling the data. It seems like restarting the bundle unstucks the blocked threads. |
I could replicate the situation by restarting my router and having trace logs enabled:
The logs start briefly before the outage. At the end, there is total silence from Modbus in the logs. You can see that after 6 minutes a rule was logging. The network and name resolution was then available already again for several minutes. openhab-modbus-issue.log It is also interesting to see that only some of the things go into an error state. Actually all of them should be in error since no Modbus communication is happening anymore. But since all the threads are stuck, also no exceptions are passed back. Please let me know if there are other loggers that I should enable to analyse the situation. |
Expected Behavior
When my network fails, e. g. because the router restarts after an update, modbus polling may fail to reach my device via network, but should recover automatically once the network is back.
Current Behavior
When the network fails sometimes the modbus binding is not recovering even after the network is up again. It doesn't poll the networked device anymore, but the device is reachable and functional over the local network with other Modbus clients.
The modbus bridge configuration:
Modbus related log entries (WARN level):
I had only set
org.openhab.core.io.transport.modbus.internal.pooling.ModbusSlaveConnectionFactoryImpl
to DEBUG level because I was expecting the error here.I took a thread dump when modbus was stuck and found five threads blocked on the same object:
It doesn't seem to be a deadlock, though, because the id in "parking to wait for" changes over time.
The situation seems to be similar to #10071.
It may make a difference that I also use a name (ew10) instead of a fixed IP address. Still, I'd expect the Modbus binding to recover from network failures instead of block indefinitely.
When I restart the "Modbus Binding", the system recovers and works normally.
Steps to Reproduce (for Bugs)
Your Environment
My OpenHAB installation details:
running on a Synology NAS, ARM 32bit.
The text was updated successfully, but these errors were encountered: