I just started using using Reactor and am very impressed with the capability and ease of use, so much so I made a little donation which I rarely do (sadly). This is a question or maybe an enhancement request …
On the GitHub Reactor wiki, under “house mode conditions”, the limitation mentions: “… Reactor does not “anticipate” a house mode change (i.e. you don’t know when the delay period starts).” Is it possible to enhance reactor with the capability to detect the beginning of the delay period of a transition between modes? I have looked around and can’t find any way to do this. I also posted a question on the scene scripting forum asking this but got no responses.
The short answer is yes but no. It’s something I know how to do but can’t do well enough to be happy with it as a feature. When I get my laptop up and running later today, I’ll give the more comprehensive answer this question deserves.
OK. Sorry, I totally lost track of this during my trip, but I’m catching up…
There is data on an impending house mode change in the system state, but like the current house mode itself, it is not stored in a location or manner where events are generated when that storage changes. So the only direct way to detect that these values change is to poll them–request them repeatedly at some interval, until a change is seen between requests. This is the approach that the House Modes Plugin uses (and likely most other plugins that check house mode), for example. The problem with this approach is that the response to a change in mode can be as long as the polling interval in the worst case–if you poll every 60 seconds, it may be 59.999 seconds before it notices a mode change. The “solution” is often to reduce the polling interval, but this comes at the expense of more CPU cycles wasted.
Reactor as of 2.3 uses a different approach to detect house mode changes that is much better and more responsive than polling: it uses hints from other things in the system that change when the house mode changes. So Reactor is able to respond consistently much more quickly to house mode changes–instantly, basically.
But Luup doesn’t (at least not that I’ve yet found) have any such hints for the pre-change, the start of the delay period before the house mode change occurs. I would only be able to tell by polling. The problem with doing that, is that the polling frequency would likely need to be very high. If your house mode change delay period was 15 seconds, for example, and polling was at 60 seconds by default, then it’s possible that the polling would not even see the change before the delay expired and house mode change completed, making the value of the test zero–it misses the event entirely. In order to ensure that the pre-change event is caught, it would have to poll at a much higher rate, and this has a cost. If we read the delay period (which we can) and polled at an interval that is half that, it would be polling every 7-8 seconds all the time, 24x7x365, and this would just be a gigantic waste of resources. So, unless and until I can figure out some hint somewhere, similar to how the end of the delay period is handled, or Vera makes these system events available as actual subscribable events, I won’t go down this road.
Thanks for the replies rigpapa. Maybe we will be able to get Vera to support what is needed in firmware someday.
They’ve been really open to suggestions lately, judging by the interactions I’ve had after making them. I am more optimistic than I’ve been in some time.