As I must run the ekey1.x binding in openHAB2 I’m using remote openHAB to have them synchronous and put the ekey1.x items to my OH3 installation. As I’m struggling with the installation I reconfigured and rebooted the OH2 instance quite a lot and the remote openHAB binding does recognize the openHAB2 instance and gets updates, but if the remote OH reboots, it won’t reconnect, when it is up again.
Do I miss something?
You probably missed nothing, the reconnection is not 100% reliable and can fail sometimes.
It can fails if the restart of your remote server was fast and the remote openHAB binding did not see your remote server as OFF.
But you have two advanced settings in the binding you can play with to improve this detection.
Until now, I found no acceptable way to make it 100% reliable, I am sorry.
That’s unfortunate, because I am reliant on a working ekey-solution, otherwise it could happen, noone can enter our house anymore, because of the remote openHAB binding…
And yeah, you could play around with the intervals and stuff, but as you said, if my openHAB2 instance is fast enough, the socket (or whatever) connection is offline, but the binding is still online.
To moderate all that, in normal situation, your remote server will not be restarted and in this case the connection looks very solid. I never encountered problems even after many days.
I did see that, also. In my case, on my second openHAB instance, there’s those bindings running atm:
- ekey 1.x (not anymore, as this is crucial: see Ekey integration into openHAB3 (as ekey binding is deprecated and won't be available for OH3))
- smartmeter 3.x (which is OK, if it’s offline)
- comfoair 3.x (which is also OK, if it’s offline)
Fortunately all other bindings of my interest where moved to OH3.
I had a similar issue yesterday. I have a pi that has my zwave controller plugged into it for motion sensors (long story, I just haven’t merged it into my 3.0 system yet). I had to restart that pi yesterday and the remote binding didn’t catch it. I ended up restarting my OH3 anyway which fixed it but same problem.
You could just stop and start the thing, this is sufficient. But at first you’d have to find out the sync stopped… and the thing IS still online, you’d have to add a timestamp based “keep alive” item, which then must inform you of the error… that’s not what I’d like to have for my “smartdoor”.
Agreed. I was updating to a newer snapshot so it just worked out that way.
I will try to enhance that, I just thought about a possible solution that would make the reconnection fully reliable.
1 Like
The issue is now declared and the technical discussion will now continue in Github.
1 Like
Personally, I would wait for Lolodomo to implement this in the binding. But in the mean time, especially if you already have MQTT set up, you can use MQTT 2.5 Event Bus.
I don’t understand, you are restarting your servers all the time ?! Strange in a production environment… Mine is almost never restarted, especially the old OH2 server.
Ideally, there’s no need to restart servers, that’s right.
But I’m 100% reliant on that specific use case (fingerprint -> open door) and I can’t be sure, there’s not a situation like upgrades or other downtimes I don’t have control over and either forget to check or there’s an outage and they don’t synchronize…
MQTT was very stable in that and I played around a bit with Rich’s link and never got it right…