I have attached two images. It seems that none of these wait events are working, and the front door wait events are recognized (dashboard shows door is locked and no motion. I figure this must mean I have a systematic error.
Also, for the Alexa garage lights. Is there any way to turn the virtual switch back to 'off' after the supposed 2 hour timeout without re triggering the same rule?
All lights appear to stay on indefinitely in both rules. What am I missing?
The biggest problem I see with both rules is that you have a conflict between your "Wait" events and your "Trigger" events. If you weren't aware, waits are cancelled any time the rule re-triggers, so you've got two event subscriptions here (assuming your rule got to the "Wait"), and it's likely a toss as to which will execute first, which could give unpredictable results (likely undesirable in either case).
For your second rule, the solution looks easy: just trigger with "on" instead of changed," then eliminate the IF that checks the switch state--you'll already know it's on, otherwise it wouldn't have triggered. The "Wait" should still work as you expect here: the subsequent actions will run either when the switch turns off or after 2 hours, and there is no longer any conflict (but the whole thing will start over if the switch is turned on in the meantime).
I didn't look at your first rule as closely, but you'll have to rethink it to avoid this conflict. If you aren't sure, it may help to describe your goals, and someone could suggest a rule that might work. Good luck!
I also think your two waits may have the following issue. If the motion sensor goes inactive before the door is locked you would then have it waiting till the door is locked and then waiting on the motion sensor to go inactive but it already is so it will wait there until there is motion and then no motion again before it will continue.
I hear what you're saying but I don't think this is the issue. The rule kind of acts as a reminder to lock the door (when you see the light on you know to check that it is locked). Since we most often physically lock the door, there will always be motion after the door locks. I guess I could wait for door to lock, then put in a loop that keeps checking for no motion every minute. Once the sensor says inactive it could exit the loop and move on. This is just a little more resource intensive I think. Hmm
Thanks. I guess I'll have to try to wrap my head around that.
The first rule turns on the front porch light and matches it to four of my other pot lights if they are on (time based) and also turns on our front foyer light depending on who is home at the time. Then it is supposed to wait until someone locks the door, finishes putting away coats etc, and walks away.
I did not realize that waits are cancelled when the rule is re-triggered. Perhaps I will have to review my triggers, or break these rules up into two smaller rules?
That is never a bad idea. 
I think I would still prefer to have the front door rule running as intended. To me that should not be an issue, but I obviously am no expert.
So the front door rule was hanging up because the motion detector needed to be rediscovered from when I upgraded my hub. I still can't figure out the other but I will keep at it.
Can you explain how wait events get cancelled? Is it something that I have to manually select for each action or is it a native function in Rule Machine 4.1. I have previously found that some rules with wait events get retriggered but the time outs on waits still run. Ie I had rules that would randomly turn lights off because a previous run of the rule timed out, even through the rule had been retriggered.
Thank you! Is this a recent change?
No, waits have always been canceled when a rule re-triggered, or at least since Rule 4.0 when all rules became just triggers and actions (can't say I remember how this worked in Rule 3.0 and earlier, but I'm not sure I ever used this feature then). One recent change is removing the "Cancelable Wait" action (still in the docs, it appears), as staff no longer believe it is necessary in light of the built-in cancelation behavior.
This is different from delays, by the way, which must be canceled in some way if that is the behavior you need for that rule.
Download the Hubitat app
