I'm using a set of rules for having both Motion Activated Lighting and also Manual Override for that lighting.
Essentially, there is a global LightStatus which starts at OFF.
The rules (stripped down for simplicity) are:-
When motion detected and the LightStatus is OFF
Change the LightStatus to AutoON
Turn the lights ON
Turn the lights OFF - delay 4 mins
Change the LightStatus to OFF - delay 4 mins
When the lights are turned on and the LightStatus is OFF
Change the LightStatus to ManualON
When the lights are turned off
Change the LightStatus to OFF.
Mostly this works fine. But there are occasions when the system seems confused. One particular example: no motion, manually switch on (so now in manual mode), motion occurs later, after a delay (might or might not be 4 mins) the lights go off - but they're supposed to be in manual mode.
I have lots of elements on my dashboard to show what's happening and I'm using the LOG to review what appears to be happening.
What I can't tell though is (for example) after motion, when the lights are on, and when waiting for the 4 minutes delay - what happens if more motion is detected?
Perhaps the rule doesn't run because it's in the midst of running altogether? (Not re-entrant)
Perhaps the rule does run in parallel with the already running instance of it? (Is re-entrant)
Can anyone offer some advice about motion triggered rules? What happens if there's more motion whilst it's already running? Do motion sensors have a quiet period to prevent a continuous flood of events (I think they do - mine is an Aotec Multi-Sensor 6).
Multiple instances of a rule can certainly run. However, they aren't "re-entrant", in that all instances share one state object. In general, multiple simultaneous instances of a rule will not work as expected.
Motion sensors usually have a count down reset. Once motion stops the countdown timer starts. That time may be fixed or settable depending on the device. If motion is detected again before the timer gets to zero, the timer is reset for the next motion stopped event.
Seems to me that you miss a scenario that it should cancel point 1 action off, if the variable is in ManualOn. Try adding cancel action and make the delay off (cancellable), if that did make any sence?
So a rule instance gets created in RM and events are hooked into it via conditions. Once saved the instance is called each time a related event fires. The instance itself "persists" which is why cancel delays, local vars etc work across different event triggers? Do I have that right?
I was confused thinking that new instances were created with each event trigger -which kinda doesn't make sense now that I think about it - overly complex, too many resources..
Thanks for that, and I can understand where you're going with it.
I'll explain why I don't have that kind of rule in there, but I need to go a little deeper into how the hardware is set up...
The Sensor is an Aeotec MultiSensor 6 using Z-Wave Plus to the Hubitat Elevation hub.
The Switch is a MOES 2 Way WiFi Smart Light Switch which is a Smart Life switch communicating with HE via IFTTT in two-way communications: ON/OFF events being sent to HE and received as Virtual Switch statuses, and ON/OFF requests being sent from HE via IFTTT to Smart Life to switch the lights.
The rule sets AutoON so that incoming ON events will be ignored whilst the automatic lighting process is running. The two-way wall switches, regardless of whether you switch them ON or OFF, simply signal the Smart Switch to invert the circuit.
I am expecting that when the Motion Rule turns the light ON then we will also receive a Light ON event from Smart Life via IFTTT and so do not want that one to overturn the AutoON status.
I am beginning to see the light - so to speak...
I don't think I need to do this 4 minute timing operation because, instead of catching Motion events, I should be catching OPEN and CLOSE events from the motion sensor. Research tells me that when the sensor first detects motion then it sends an OPEN event and starts a timeout timer (default 4 mins). If there is more motion before the timer expires then it simply resets the timer but doesn't send anything to HE. If and when the timer eventually expires without further motion then it sends a CLOSE event.
So I think I need rules for these OPEN and CLOSE events, and remove the rule for the MOTION event.
I would be interested in knowing if Local Variables persist across different events for the same rule. I.e. if you set a Local Variable in the Rule, and that Rule gets triggered whilst an earlier invocation was still running, then could you test that Local Variable within the Rule to discover that scenario? Or would you need to use Global Variables to do that? Would you effectively have two instances of the Local Variable - one for each active invocation that is still running?
I just tested by creating 2 virtual switches and change event triggers for both with an "add one to local variable" action logging the result. Yep works as expected!!
app:3532020-02-03 07:01:44.907 am infoTest Counter is 3.
app:3532020-02-03 07:01:44.839 am infoAction: Log: Test Counter is %TestCounter%.
app:3532020-02-03 07:01:44.693 am infoAction: Add 1 to TestCounter
app:3532020-02-03 07:01:44.620 am info__TestLV Triggered
app:3532020-02-03 07:01:44.567 am info__TestLV: __test1 switch off
dev:3212020-02-03 07:01:43.739 am info__test1 was turned off
app:3532020-02-03 07:01:39.535 am infoTest Counter is 2.
app:3532020-02-03 07:01:39.467 am infoAction: Log: Test Counter is %TestCounter%.
app:3532020-02-03 07:01:39.314 am infoAction: Add 1 to TestCounter
app:3532020-02-03 07:01:39.247 am info__TestLV Triggered
app:3532020-02-03 07:01:39.199 am info__TestLV: __test2 switch on
dev:3242020-02-03 07:01:38.349 am info__test2 was turned on
app:3532020-02-03 07:01:19.370 am infoTest Counter is 1.
app:3532020-02-03 07:01:19.291 am infoAction: Log: Test Counter is %TestCounter%.
app:3532020-02-03 07:01:19.117 am infoAction: Add 1 to TestCounter
app:3532020-02-03 07:01:19.048 am info__TestLV Triggered
app:3532020-02-03 07:01:19.002 am info__TestLV: __test1 switch on
dev:3212020-02-03 07:01:18.376 am info__test1 was turned on
Also I don't think "an earlier invocation" is the correct interpretation unless you mean trigger. I believe that generally speaking there is only one instance of the rule "running" (or persisting) at a given time. Of course I could be way off... would not be the first time..
Does that mean that the value of the local counter variable is retained at the end of the rule, so that upon the next triggering you can pick up from where it left off? That would be useful - I kind of assumed that it would go once the rule reached the end.
Yep! I think the mistake at least in my thinking was that rules start and end. Once created they are "alive" (instantiated) and waiting for triggered events... something like that.
