OK, quick grab the log file and send it to me. I want to see what it logged. Make sure the startup is in the log you send.
sent 2 email has startup
edit/ did not have debug on, can do again if you want
Startup was in there, no worries.
openLuupâs own log messages show Reactor applying its watches:
2020-12-24 14:48:39.328 luup.variable_watch:: callback=reactorWatch, watching=20021.*.*
2020-12-24 14:48:39.331 luup.variable_watch:: callback=reactorWatch, watching=20023.*.*
2020-12-24 14:48:39.333 luup.variable_watch:: callback=reactorWatch, watching=20009.*.*
If I had to guess, just a hunch, when the device is initialized later, openLuup is discarding the current device object and creating an entirely new one, thus losing any modifications and watches on the existing device.
Back to @akbooer.
I am seeing text before activities page loads in other reactor sensors and some activities not executing.(house mode change but works if i then go to activity and hit running man)
What do i need to type in plugin page to revert to previous?
Try hard refreshing your browser. And then try a supported browser. Android Firefox is not supported.
I alway hard refresh, seems to have stopped now, will keep an eye on it.
Blockquote
Hi,
I have been experimenting a bit and how openLuup works now is that a (child) device must exists before you can set a watch on it. The only workaround I can offer is to make the communication blocking at startup so the startup routing creates all child/bridged devices at startup. I have made some other changes now, and will look at this the next days.
Cheers Rene
1 Like
At first sight, this seems entirely reasonable. Are you saying that Vera does it differently?
Yeah, Iâm not sure what @reneboer means by that, either, because that seems obvious. If the device doesnât exist, no device number. No device number, no watch.
The issue as I see it is that there is a known device number (the device was created previously and thus visible to Reactor so it could be chosen by the user to put into a condition), but the device isnât completely initialized somehow at startup. So even though the device is known to exist, by evidence of it having a device number, placing a watch on it is ignored. I suspect thatâs because somehow the device is being (re?)initialized (perhaps by chdev.append? with no changes) and watches that were placed before that event are then lost. But I havenât dug into the openLuup code to know.
What I do know is, yes, watches in openLuup work differently from watches in Vera Luup, and to such a degree currently that there is no workaround I can reliably place in Reactor.
So let me be clear about my suspected progression of events:
- eZLO bridge starts up, doesnât matter when in relation to Reactor, because it has to initiate communication with the eZLO device and thatâs async, so the âsuccessâ is going to come later.
- Reactor starts. It sees it has a condition for an eZLO bridge child that was previously known and placed, so it places a watch on that device.
- eZLO bridge establishes connection, enumerates devices from the eZLO device and calls chdev.append() for every device, existing and new, as it should.
- Watches previously placed on eZLO child devices are now lost (somehow chdev.append() erased them).
Again, I havenât looked at the code, but thatâs what I suspect is happening.
Yes, thatâs almost definitely whatâs happening. I need to revisit some design choices made early on for chdev.append().
This was not an easy task the first time around, and involved much experimentation. We know more now, and anyway, I would do things a bit differently. openLuup has grown more than I could have initially imagined. It was, to begin with, just a couple of Luup emulation routines to allow me to run DataYours, and then Netatmo, outside of the Vera environment. I have refactored significant parts of it, sometimes more than once, but some core bits remain quite unaltered. I guess thatâs true of many maturing systems.
Iâll take a look, but itâs likely a significant job. The fear, of course, is that Iâll break something, despite unit testing.
Tony
PS: Virus rampant again, most of country now basically locked down. Likely to remain so for at least a month. Deaths have hit the highest rate since April. New school term delayed for at least several weeks. All non-essential shops closed. On the plus side, a second vaccine has been approved. Happy New Year!
2 Likes
The EzloBridge is a clone of the VeraBridge. Looking at the way child devices are created it is not using the standard chdev.start, append, sync. It is using an openLuup specific chdev.create could this be why?
PS: we are in the same boat as you, but awaiting the second vaccine approval. Heck our government will only start vaccination Jan 8th with the first. Next year will be happier.
PS2: It is my English I suppose. Yes a child device must exists before you can put a watch on it. I meant that it should have passed the start up routine it seemed. But now looking at the way the devices get (re)created to assure the right bridged device number, the cause is probably else where.
The problem stems from line #398 in the VeraBridge code (v20.12.11)
create_new (cloneId, dev, room) -- recreate the device anyway to set current attributes and variables
The comment âanywayâ shows clearly that I understood that this was over-writing an existing device (and therefore its variables) and the history trail in the comment header corroborates this:
-- 2016.04.17 chdev.create devices each time to ensure cloning of all attributes and variables
so itâs had this behaviour for a while.
1 Like
Looking at this more again, it is definitely not an issue with the basic openLuup engine, but simply with the bridge code (both VeraBridge and EzloBridge, not with ZWay.)
It turns out that simply moving the create_new() function into the branch of the if statement where the device is missing is sufficient to fix the variable watch issue. I had been concerned that the variables wouldnât be initialised with their values correctly, but this is, in fact, fine since the first polling update reads all variables and checks for changes anyway.
The only remaining thing required to change is an intialisation of the device attributes which may have been updated since the last restart. So this should be an easy fix.
This issue is now fixed (for VeraBridge) in openLuup development version v21.1.3.
I have tested it by setting a device watch on a bridged child device in the openLuup Startup Lua and checking that it works as device variables are changed on the remote Vera (in fact, a Zwave device.)
The same fix should work for the Ezlo bridge.
Thanks AK, Iâll have a look (and undo my blocking coms bit 
)
Cheers Rene
very informative.
Hi Rene, do you plan to release a fix for this?
Hi EICid,
I am testing a new version right now, looks promising. I expect no later than this weekend.
Cheers Rene
1 Like
FYI all, Reactor stable branch on Github is 21007 and reverses out the attempted workaround. All Vera and eZLO Bridge users should use this version of Reactor (or higher) on openLuup 21.1.3 or higher. Iâm not going to enforce that version, since this has not been an issue for other users.
1 Like