Just wanted to share my solution for using the Aeotec Wallmote Quad with Reactor handling all the logic (almost…) on openluup with a bridged Vera Plus as z-wave controller. The problem I faced was the same as had been discussed here:
In short; if your scene controller supports LastSceneTime you are A-ok! But if it doesn’t and you only have sl_centralScene openluup can’t check correctly if the Wallmote’s sl_centralScene has changed (i.e. a button has been pressed, even if that button is the same as the last button pressed) you’re in trouble. Aeotec Wallmote Quad apparently doesn’t have the LastSceneTime and thus my Wallmote did not work as intended with openluup.
As the thread concludes there isn’t any good solution and the suggested workaround would not work for me. The workaround suggested is using Reactor on the Vera itself for checking if sl_centralScene changes or updates, which probably works great thus having access to the Veras own internal timestamps, but for me my Vera constantly reloads luup IF I run ANY Reactor sensor on it… So that I can’t do, and moving all the Reactor sensors OFF the Vera was the reason I moved to openluup.
So, what I did was create a virtual Wallmote Pulse switch using the Switchboard plugin, on the Vera. I have den created a normal Vera scene (because they don’t cause luup reloads) that checks if any button has been tapped/held (I just added all the button taps/holds as triggers for the scene). If any button is pressed then the scene will switch the virtual Wallmote Helper switch ON for 15 seconds, basically a pulse.
On openluup in my Reactor Sensor I create a group for each button tap/hold that contains two things which both need to be true to trigger the group condition, i.e. a group with AND:
What button has been pressed? E.g. Device Wallmote Quad sl_centralScene equals 3
Has any button recently been pressed? I.e. Device Wallmote Helper Status equals 1
Since my Vera scene will turn the Wallmote Helper OFF after 15 seconds, I basically get a pulse where one of the button groups will be true for 15 seconds. If I press the same button again, the same group will be true again, because the Wallmote Helper was false before the button press, so it’s state will change to true again for 15 seconds.
This way I can use the Wallmote Quad as it intuitively should work. Without this type of model (i.e. if you leave out the Wallmote Helper device) you can’t press the same button in a row and get activities triggered both times. And that is problematic in many instances. For instance; if I use the Wallmote to trigger Away mode when I leave for work, but have Geofence to trigger Home; the next morning I want to press the Away-button again. If I havn’t pressed any other button in between nothing would happen the second morning.
Hopefully this will help anyone else with the same challenge!
Cheers!
Actually, all of this should not be necessary as of openLuup 19.12.11 (all current versions of Reactor require openLuup 2020.04.14b or higher anyway). The expected conditions for openLuup should be the same as they are on real Vera Luup:
AND Group:
Device state, scene controller device, sl_CentralScene (or sl_SceneActivated, depending on device) equals button number
Device state, scene controller device, sl_CentralScene (or sl_SceneActivated), updates
Another simple approach is to have a single condition that checks sl_CentralScene (or sl_SceneActivated), and then in the activity that reacts, set it to blank or zero in a Run Lua action.
Thanks for the input @rigpapa! I can see how your second suggestion would work. An elegant solution!
However, at least for me, the first variant doesn’t work. It was exactly what I had on my Vera and it worked there (disregarding the luup reloads…) but it doesn’t work on openluup. The problem is that the timestamp updates every 2 minutes or so for some reason. This is what it looks like:
Device State: WallMote Quad (#10459) sl_CentralScene updates; pulse for 3 secs 1597430498 (false) as of 21:41:38
And then about 2 min later without any interaction from my part:
Device State: WallMote Quad (#10459) sl_CentralScene updates; pulse for 3 secs 1597430604 (false) as of 21:43:24
This is with the VeraBridge variable CheckAllEveryNth set to 20. I’ve also tried setting it to 0, with unreliable behavior as a consequence.
I’m using vwouts latest docker image with openluup version 2020.05.22.
If I had to guess, I think the Bridge is not looking at Vera’s timestamps to see if there’s a similar change coming from the Vera end. That is, the Bridge is getting each value from each Vera device, and writing the value it gets to the local openLuup device, rather than writing only if it has changed or has a different timestamp than the previous value. Hmmm… @akbooer, can you weigh in on this?
I’ve read this thread twice, and still don’t quite understand it… but it is now late at night. However, I’d point out a fundamental problem with Vera status reports: although they report variable value changes, they don’t report the variable update time.
I don’t have a device of the type in question, so this will always be difficult to trouble shoot. Random changes in VeraBridge parameters are unlikely to bring any sort of closure to the issue.
There are several approaches available at this point without any changes to openLuup or Bridge. We are likely near a practical limit of the level of compatibility between Vera Luup and openLuup, and this is just an exception we’re all going to have to work with. I think it’s fine. There are so many other issues with Vera timestamps that also provide plenty of incentive to stay with the status quo (sync/dataversion problems since 7.30 in particular seem to be much worse, although I think I’m beginning to see a pattern pointing to a cause).
Yes, this is ok I think. This thread now includes a couple of workarounds to choose from for those having this issue with their scene controller. Thanks as always @rigpapa and @akbooer for providing knowledge and context in the matter!
Huh, interesting. I tried changing over to your second suggested solution and it doesn’t work for me either due to the same reasons the updates solution doesn’t work.
The sl_CentralScene variable can be set as per your example, but every 2 minutes or so it “bounces back” to the last variable. E.g:
Device State: WallMote Quad (#10459) sl_CentralScene equals “6” 0 (false) as of 19:12:26
Device State: WallMote Quad (#10459) sl_CentralScene equals “6” 6 (true) as of 19:14:04
Device State: WallMote Quad (#10459) sl_CentralScene equals “6” 0 (false) as of 19:14:09
The 5 second delay from true to false is due to a 5 second delay set in the activities before running the lua script setting the variable to 0.
So, I need to change back to my virtual pulse button it seems, if you don’t have any other ideas?
Yeah, probably would work. But the virtual button trick works as well so I’ll leave it like that for now.
The interesting part in this is that the variable reset happens with the same intervall as the updates version triggers. So I think they are caused by the same root cause, which is somehow connected to the CheckAllEveryNth variable. Compare:
Device State: WallMote Quad (#10459) sl_CentralScene updates; pulse for 3 secs 1597430498 (false) as of 21:41:38
Device State: WallMote Quad (#10459) sl_CentralScene updates; pulse for 3 secs 1597430604 (false) as of 21:43:24
with
Device State: WallMote Quad (#10459) sl_CentralScene equals “6” 0 (false) as of 19:12:26
Device State: WallMote Quad (#10459) sl_CentralScene equals “6” 0 (false) as of 19:14:09
Just as a curiosity.
I’m ok as long as it is just working, so as I said the virtual button workaround is fine.
Apparently it should work…