I have 2 motion sensors in my (large) kitchen. 1 Hue and 1 GE 26933 (Smart Motion Dimmer). I set up 2 rules: one to detect motion from either sensor and turn on a virtual switch and a second rule to turn on lights when the switch turns on. I found that occasionally the lights would turn off and never turn on again. I tracked it down to the sensor virtual switch not being reset. I added a trap to the light rule to determine why. The rules:
Is this a timing issue? Would inserting a delay after the "Wait for event: ...all inactive" and before "Off: Kitchen Motion Sensors Switch" solve the problem? If so, how long? Or replace the switch with a hub variable? I'm hoping this is a timing problem and not with an Action being missed.
Not sure why your switch doesn't turn off, but I wonder if using the Zone controller app would make it easier. You can combine the two sensors into one. Then you would not need to use the virtual switch.
The app has some customization on how the two sensors interact to set active and inactive. The app can be found under built in apps.
I think you may have a race condition that causes unpredictable actions in your Repeat block.
Here's what I understand may be happening (or at least a clue as to what may be happening). Admittedly, I'm not 100% sure of my analysis, but maybe it leads you to the solution, so here goes . . .
Are you familiar with how drivers generally work to update device attributes? If so, think about how a switch processes an "off": usually what that entails is that the driver gets the "off" command and then does some processing which eventually ends with the driver sending a "sendEvent (name:"switch", value:"off")" that goes through some further database checks and filters which eventually changes the device's switch attribute to "off". Thus, there is always a delay between the "Off" command being received by the driver and the sendEvent actually resulting in a change to the "switch" attribute.
Now look at your Repeat block.
The first thing you do is instruct the "Kitchen Motion Sensors Switch" to go to "off".
This starts a race condition. The unknown is how long will it take that switch's driver to process the "off" and send the necessary sendEvent to update the switch attribute, versus how long for the Rule to move to the next statement where it tests for the "off" condition of the switch. The switch driver runs independent of the rule, so it is quite possible that the Repeat loop runs through many reps before the switch driver does its processing. Thus, you have a race between two different sections of code.
Agre with @terminal3 that the stock zone motion controller app can help solve this. I have a GE motion switch in my master closet along with an Iris motion that covers a dead spot the GE cannot see. I set the motion timeout on the GE to be quite long and then have a rule that turns on the lights if motion is detected by the zone motion device and off if itās inactive.
The rule has two triggers (2 motion sensors). The first rule (setting the switch) prevents the second rule from being entered multiple times until the switch is turned off.
jvm33; That may be the case with my test code (Repeat loop), but the reason I put it in was because the rule was exiting with the virtual switch off so it does occasionally miss turning it off.
Note the block outlined in green in the rule. It was completely skipped in the rule execution. The log shows (and what actually happened) was that as soon as the motion sensors when inactive, the lights immediately went out. This rule has been edited many times. Corrupt? Try completely rewriting it from scratch? Reboot? Any ideas as to why it would completely skip the IF block would be appreciated. And no, it does not do this every time. It's currently executing properly.
Are you sure it was skipped? Housekeeper isnāt present so first If was skipped, based on logs time wasnāt between those hours so Else If skipped, thus final Else was evaluated and ceiling lights turned off. Assume you thought it was skipped since there is no logging? There might be a bug with the logging so I would suggest test housekeeper or hours just to be sure.
No, I can't be completely sure. But the lights did turn off as soon as the zone motion sensor went inactive (no 20 minute wait) and subsequent logs (when the wait is evaluated) do show the complete evaluation of the second IF block with the Wait.
I've since trashed the rule and rewritten it. Hoping that helps. (I couldn't delete the old virtual switch device since it was embedded in the apps Settings, but nowhere in the rule statements).
I don't think it skipped it, it just looks that way because you have two iterations of the rule running at the same time.
After the trigger the first IF shown in the log is not the first IF it should encounter. That is another run of the rule from a previous trigger.
Every time there is active motion the rule triggers. If it is in a wait it shouldn't start again. So probably most times it is waiting when a trigger occurs and it cancels and starts over, but two rapid triggers might start multiple versions running.
I guess that's the most reasonable explanation. I was under the impression that a trigger while the rule was running cancels everything except delays and repeats which aren't in this version of the rule. Guess not.
If the rule is in a wait the rule will be canceled. Otherwise the another trigger occurs and another instance of the rule begins. This can usually occur when you get two triggers close together.
The rule is triggered at 08:50:52.193, the first line of the rule after the trigger occurs at 08:50:52.315. The lines between those two times are another iteration running from a previous trigger.
At 8:50:52.284, just prior to the first line of the rule, there is the 20 sec wait prior to turning off the ceiling lights. So it started waiting for 20Sec, but the new instance started another wait for event motion inactive. When that wait completed it apparently halted the 20 sec wait as well, as the ceiling lights then went off. That was only slightly more than a second later. That part I am not clear on, but that is the problem when you get multiple triggers of a rule.
This shows, I think, the portion of the rule that occurred from the trigger listed in the log.
Thank you. Your analysis describes what happened. I'm not sure how to go about preventing a second instance of the rule. I'll have to wait an see if it occurs often enough to be a problem (WAF). The boolean trap doors I've tried before have the same problem (the trap gets closed, but not before the rule is already entered.) The rule was not a problem before I added the second motion sensor. But it did solve a coverage problem; unfortunately creating its own complications.
