You will have a lot of unresponsive devices and need some detective work on the why.
And does the eZLO Bridge continue trying to connect and bring the devices to life when itâs finally able to connect? This the behavior I would expect as a user.
When the websocket connection is lost the plugin will retry every 30 seconds for 30 minutes and once reestablished continue without a reload.
Updated to OpenLuup development, but the issue persists. I can see the plugin startup priority has now Ezlobridge at number 5, with the vera bridge.
Hi @ElCid, I tested that bridged devices work in Reactor now. Please make sure the variable is indeed updated on openLuup. You may need to delete and recreate the condition in the reactor sensor.
So hereâs the problem:
openLuup starts up and initializes plugins. Itâs initializes the eZLO Bridge, which attempts to contact the eZLO but cannot, so it times out and the devices are broken.
openLuup continues initializing plugins and brings up Reactor, which attempts to place watches on the eZLO Bridge devices, but these requests are ignored because the devices are not fully initialized.
Later, the eZLO bridge can finally contact the eZLO system and brings the devices to life. Reactor thinks it is watching these devices, but is unfortunately blissfully unaware that its watches were not placed (even though a log entry asserted they were).
Shortly after, the user discovers their automations arenât working, and that turns into a support problem for me.
This is a latent bug, an incompatibility between Vera Luup and openLuup, and I think it needs to be addressed at the source, not with a workaround.
The Status is definately getting updated.
I looked at startup log and Reactor is starting before Ezlobridge
Hi @rigpapa,
I understand but I think it is an inherent risk of using a setup build with multiple physical hubs. Any plugin that are bridges like this (like RFX, IOSensors, etc) will need to create child devices at start up and have this problem in them. Before AK put in the priority start option it was hit an miss with setting watches on bridged devices. For me it all work pretty reliable.
The only truly reliable change I can see is wait with watch creation until all plugins have started, but I think that will be a big change to openLuup.
But it must be understood this is for the tinkerers, openLuup second level tinkering, so not for the faint harted.
Cheers Rene
Not disagreeing with that. Just trying to understand your earlier description of the discrepancyâŠ
Please try to update to the development version of openLuup again and make sure the version AK mentioned.
version says 20.12.23, but will do it again to be sure.
The key difference, really, between openLuupâs watch implementation and Vera Luupâs, is that Vera luup doesnât care if the service is declared on the device, and also doesnât care if the variable exists.
If the variable is created later, watch callbacks start triggering for the device once the variable is created.
If the service is not declared on the device, but a variable exists in the undeclared service, watch callbacks will trigger when the variable changes.
Because openLuup specifically has to see the service declared and the variable exist at the time the watch is requested, it creates a pair of dependencies that do not exist on Vera Luup, and this probably more than anything creates the timing problems for both the Vera and eZLO Bridges, and would for any plugin that needs to watch another pluginâs device when the latter is initialized after the former.
I also consider it to be a bug that openLuup logs that it has placed a watch on a variable when, in fact, it has ignored the watch request.
It ignores the watch request because, in the current version of devices.lua, for the if srv then conditional starting at line 355, there is no else, it just drops out. Likewise, for the variable itself, line 358, there is no else, it just drops out. So there are two conditions under which a watch would not be placed, yet a message would be emitted to the log that it was placed, and yet no callbacks would ever fire because the hooks werenât added to the list.
Ok still no luck, Ezlo bridge has job number 10 and Reactor number 6 still.
So disabled the offending reactor sensor, then restarted luup. Waited 20 seconds the enabled the reactor again. The offending group instantly came to life, and the watches now show in the sheduler.
I think the Ezlobridge is slow connecting and reactor is starting first.
Edit/ Soon as luup reloads the group fails again, and watches disappear.
The logging, I can fix.
The fundamental behaviour cuts much more deeply.
The communication with the Ezlo is asynchronous so I think that is still causing the problem. I can have a look to change that for the startup so the devices will be created once the plugin startup completes.
I also noted that on Vera Reactor looks for a z-wave ready indication, but does not do that for openLuup. Maybe that is a point to look at too (especially if you use openLuup with a z-wave stick). Can there be some openLuup system ready check?
Cheers Rene
After some discussion with @akbooer on the openLuup issue, it looks like heâs leaning toward not bringing openLuupâs behavior in line with Vera Luup, so Iâve put a workaround in Reactor, at the expense of some performance, but it seems to work.
@ElCid, you have the litmus test. I canât reproduce the environment you are working in, so Iâll leave it to you to try it. Latest stable branch update.
If the eZLO (and Vera) Bridge had a state variable for communicating ready status, any user could check that in their logic. I think it would be useful to know anyway, as a user could send notifications or do other things if a ânot connectedâ state on a bridge persisted for too long.
No luck , update stable to Reactor ver 3.9develop-20358.1645
Same result, only if i disable Reactor sensor and reload luup, then enable , do the watches register
The message after device number is also missing.
1 2 housemode_watcher 0 2.openLuup.HouseMode
2 10 reactorWatch 7 2.*.*
3 10 reactorWatch 0 10040.*.*
4 10 reactorWatch 1 10041.*.*
5 10 reactorWatch 0 10106.*.*
6 10 reactorWatch 0 10008.*.*
7 10 reactorWatch 0 10038.*.*
8 10 reactorWatch 0 10165.*.*
9 10
from openLuup watches page.
Try it one more time â reload Luup, then pull the watch list. Donât disable the sensor or do anything else. I want to make sure that the updated Reactor was actually running on that test.
Here is list
1 2 housemode_watcher 0 2.openLuup.HouseMode
2 10 reactorWatch 0 2.*.*
3 10 reactorWatch 0 10041.*.*
4 10 reactorWatch 0 10106.*.*
5 10 reactorWatch 0 10166.*.*
6 10 reactorWatch 0 10040.*.*
7 10 reactorWatch 0 10165.*.*
8 10 reactorWatch 0 10008.*.*
9 10 reactorWatch 0 10038.*.*
10 10 reactorWatch 0 10164.*.*
11 10 reactorWatch 0 10019.*.*
12 10 reactorWatch 0 10082.*.*
13 10 reactorWatch 0 10103.*.*
14 10 reactorWatch 0 10085.*.*
15 10 reactorWatch 0 10178.*.*
16 10 reactorWatch 0 10043.*.*
17 10 reactorWatch 0 10044.*.*
18 10 reactorWatch 0 10192.*.*
19 10 reactorWatch 0 32.*.*
20 10 reactorWatch 12 14.*.*
21 10 reactorWatch 0 10089.*.*
22 10 reactorWatch 15 12.*.*
23 10 reactorWatch 2 10.*.*
24 10 reactorWatch 19 11.*.*
25 10 reactorWatch 0 10161.*.*
26 10 reactorWatch 0 10185.*.*
27 10 reactorWatch 0 10182.*.*
28 10 reactorWatch 0 10160.*.*
29 10 reactorWatch 0 10186.*.*
30 10 reactorWatch 0 10159.*.*
31 10 reactorWatch 0 10031.*.*
32 10 reactorWatch 0 10190.*.*
33 10 reactorWatch 0 10056.*.*
edit/ it seems shorter , i am sure it had 50+ before