I have a rule that fires the first time I walk into my kitchen each morning. This rule will fire only once and then reset once I have switched on my Good Night routine (i.e. wait for event/ switch). When this rule's action runs after the first time, it should be dormant based on how the private bool is setup. The problem is the wait for event subscription for Good Night is lost after the 2nd action execution. Why is the 2nd action execution unsubscribing the good night switch on event when showing skipped in the logs? Screen shots below.
Wait for Event is cancelled each time the rule runs. Presumably the rule is running again because it was triggered, right? You will need a different approach.
Let's think about this a little further. If you look at my action list, you will find that subsequent action executions will not meet the initial IF condition until the private bool is set to True. Logically speaking all actions should be skipped on subsequent executions, but not cancel subscriptions (wait for event) from the 1st action execution. Isn't this a bit counter intuitive? I guess I could place the wait for event action in a way that executes each run, but that seems a bit obsessive. Feedback?
I'm not sure what you mean by "cancel subscriptions". Waits are cancelled each time the rule runs whether any of its actions are skipped or not. Before running the action script, waits are cancelled.
All I'm saying is that if you are waiting for Good Night to turn on, and either trigger events happen first, that wait is cancelled and Private Boolean will not be set to true.
My view is that secondary executions do not honor IF THEN blocks when bypassing commands. If a condition is not met, why cancel the previous wait for event from the first execution?
Why don't you set the private boolean for this rule in another rule using "Good night turns on" as the trigger? That way, you don't have to worry about the existing triggers for this rule firing and causing potentially undesired behavior. (If your other conditions are important with respect to this switch changing state, you can include them in that rule's actions section, too.)
The issue as-is is that your actions are pausing at the "Wait for events" action, but if one of your triggers happens again before the event that "wait" is waiting for fires, it will go back to the beginning. It's not ignoring the conditions on your IF (I'm not sure if that's what you're saying); it's obeying them because the private boolean never got the chance to be set to True. Per the Rule Machine docs, "both pending Wait for Events and Wait for Condition are cancelled each time a rule is triggered, and [can] be cancelled by another rule with Stop Rule Actions, or by Cancel Wait action." This certainly isn't the way it has to work (it could pile a bunch of subscriptions on top of each other but I suspect the end result would be bad if the rule triggers multiple times and later a sudden firing of this event causes a bunch of duplicate actions to run at the same time). However, it's the way it does work, so you'll need something else to make it work the way you want.
I know, I know, it's a second rule. But as people used to say in earlier versions of RM when the Actions sections weren't quite as powerful as they are now, rules are free. Luckily, that's still true. 
I'm not sure what you mean by "secondary executions". Rules are a script that runs when the rule is triggered, every time it is triggered. Delays and Waits suspend the script for some interval, and under some circumstances the script will restart. Waits are a special case because they entail temporary device event subscriptions. As a general rule, multiple simultaneous execution of the same rule's script is a recipe for failure, and is to be avoided in the way the rule is written. Such simultaneous executions are explicitly NOT SUPPORTED. IF-THEN blocks and Waits in particular cannot survive simultaneous execution as the rule only possesses a single state in which to track the nesting of IF-THEN blocks and the meanings of Wait subscriptions. An inbound event from a device carries no information about the context of the subscription that caused it to be received -- such context has to be remembered in the rule's state.
In accordance with the foregoing, all outstanding waits are cancelled at the beginning of each execution, motivated by the fact that a rule only possesses a single state. The idea to keep track of prior execution states for a rule is inherently not possible.
I appreciate the follow up gentlemen and I understand your view. I'm accepting the design as is and again appreciate all the help.
