It looks like you authored the original ISY binding as well? Both the Omnilink and ISY bindings seem to suffer the same reconnect problems - it looks like your were using an older version of google guava. I wonder if an updated version would solve this issue.
It is my understanding that the powers that be have suggested bindings should move away from utilizing the guava libs. The omnilink had a working reconnection strategy until I rebased this binding up to the 2.4 master and removed the guava dependencies. The ISY binding was further behind in development and I donāt believe had the reconnection coded.
I have asked a general question to see if others more up on current suggested best practices for openhab have an idea of how reconnection should work. I just have concerns about sync/async and using up threads, so I donāt want to hack something in.
Got it, both these bindings are essentially the core of my home automation both at my home and cabin. So the reconnect issues are causing a very wife approval factor
@craigh -
I am not using the rebased version and I (just yesterday) hit the issue where the binding stops being updated. So I donāt think it is related to your rebase.
Do you have a link on not using Guava in bindings in Openhab? That is a bit of a bummer as it makes working in Java a bit more enjoyable.
@mjcumming. I am with you. I have both these systems at my places and felt the need to do a fair bit of work on each of the bindings. Itās something I do want to solve, but without staying very involved in openhab development I find it challenging to keep a development environment that builds and is productive, etc.
The hang issue may be a deadlock in the core jominlink library. Could the next person who gets the hang and requires a restart run the dev:dump-create command from inside the openhab console? That will create a zip file in your userdata directory. Upload that file somewhere that I can download it and I will take a look at it.
Just a heads up. I got a dump, thanks @mjcumming. There is a deadlock in the core library. There are a lot of edge cases around I/O and threading in the current library. I have started rewriting the I/O portions of the library to use netty. I am about 70% done. It will however, have some impacts on the binding. Most of the synchronous methods will be replaced with Futures instead. The current library attempts to show the omni as a (request/response) system when it really isnāt - that causes some of the issues.
Looking at it more deeply there are a lot of things I want to fix in the core library and I think it will take a pretty long time to correct all of them. I think I may have fixed the deadlock we are facing now with a pretty simple change. @craigh, if you want you can grab a version that I think fixes the deadlock issue from here. That should be plug and play with the version you had before, the API didnāt change any. If that fixes the deadlock, I will make a PR.