I did not change a Thing file - Instead it was a Rule file that was modified.
But I am now seeing continuesly messages in the log like these:
2021-04-02 08:57:48.550 [WARN ] [.core.thing.binding.BaseThingHandler] - Handler VeluxBridgeHandler of thing velux:actuator:home:ThKLF200Gardin tried checking if channel limitMaximum is linked although the handler was already disposed.
2021-04-02 08:57:48.550 [WARN ] [.core.thing.binding.BaseThingHandler] - Handler VeluxBridgeHandler of thing velux:actuator:home:ThKLF200Vindue tried checking if channel position is linked although the handler was already disposed.
I suspect this is related to my restart of the binding mentioned above. I have now restarted OH and everything works great again including Velux.
Hmm. That is odd. Normally on my system, changing a rule file does NOT cause the things files to be reloaded. I wonder what could be different between your system and mine? (It will be harder for me to test, if I cannot simulate your situation).
Just to be sure: in this case, did you need to power cycle the KLF? Or was a restart of OH sufficient to resolve the issue alone?
Ah-Ha! I see what is the problem: it is a synchronization issue…
As you can see in your log (above) OH calls the ‘Shutting down Velux Bridge’ method, and then, only 1 milli- second later, it calls the ‘Initializing Velux Bridge’ method; so the new initialization is overlapping the prior shut down.
In my last bug fix of the ‘zombie state’ problem, I purposefully made the shutdown process veeery slooow, to make sure that the binding completely flushes any data in the KLF send buffer, and then does a full and formal TCP ‘FIN-ACK-FIN-ACK’ socket shutdown handshake; which can take up to 2…3 seconds.
In a manual shutdown, the user is not likely to restart again within 3 seconds, so there is no process overlap. But when OH does shutdown/restart automatically, it is simply “too fast” – so the new initialization starts before the prior shutdown has completed.
It is easy enough for me to fix this; I can simply hold off any (re-) initialization process until any prior shutdown process has fully completed. I will make this fix in the next couple of days, and create yet another PR with that fix.
I have suddenly a problem with my openhab3 installation and the Velux Binding telling me:
[x.internal.bridge.slip.io.Connection] - io() on 192.168.xx.yyy: Exception occurred during I/O: raised a non-recoverable error during connection setup: Connection refused (Connection refused).
Any idea from what this comes? I already restarted the KLF, openhab, the Raspberry, Cleared the cache > nothing helps. Always the same error. Any help really appreciated.
And I didn’t change anything except for some rules or items which I regulary configure and enhance.
What version of OH are you running? It is quite a complex problem to solve, and I have made several changes in the last months to fix it, so the closer your version is to OH3.1.0-M3, the better.
A few comments…
Clearing the cache won’t make any difference at all.
Any “hard restart” of the OH service, or reboot of, or, power-cycling the Raspberry, will most likely NOT solve the problem; indeed it is probably CAUSING the problem (read the post in the link above).
To (try to) prevent the problem occurring, you should always “soft stop” the OH service before you doing anything “hard”.
Once the problem has occurred, then the only way to fix it is to power-cycle the KLF.
So the sequence to resolve the problem is…
Stop the OH service “softly”: sudo systemctl stop openhab.service
Power cycle the KLF
Re-start the OH service “softly”, or you can do a reboot of the Pi: sudo systemctl start openhab.service, or sudo reboot
I have this issue as well running OH 2.5.12.
My experiences is, the above procedure doesnt always work. Atm I´m actually tried two times, and I still end up with the same issue when OH restarts.
Unfortunatly I´m not prepared to move to OH3 dues to other bindings having issues. So I´m stuck at 2.5.
Hi @Kim_Andersen thank you for the feedback. This is really not a problem with the binding: it is a fundamental problem in the KLF firmware. Nevertheless I have spent several months trying very hard to develop some work arounds to ameliorate that problem. But unfortunately those efforts have not been back ported to v2.5.x…
I have tried to look in Karaf to see if I can check for something but unsuccessfully. I have tried to install manually but cannot find the location of the package online (as it is now in the official depot and not on github).
in the addon.config, I can see a reference to velux in the bindings line.
