You haven't posted your whole rule so I don't know what your triggers are and you haven't posted the logs so I'm going to take a guess at what the issue is. I suspect all of your virtual switches are already off before your rule get to the Wait. If that's true then their won't be an event for the Wait to act upon. To check this, Run Actions for the rule. When you get to the Wait turn one of your virtual switches on then off. If the rule continue then that's the issue.
Ah ha! that's it! thanks!
for what it's worth, here's the triggers...
and the logs. I had just finished making them when you replied.
triggers
log fail
log success
1 Like
You probably want to change your Wait for Events to Wait for Expression. The Wait for Expression will look at the state of the switches and proceed if they're already off.
1 Like
The rule sort of run. You basically had a version of a race condition where things posted faster than the hub could cancel the actions. In looking at the time stamps, it was basically 5 ms between things posting and cancelling the actions. This is why it looks like your rule got stuck, but in reality it got cancelled. These actions also cause your Private Boolean to never get reset, which is why the rule cannot run again until you fix it.
What are you trying to accomplish with this rule? Do you want it to run only one time until it is finished, then reset itself? If so, just remove the cancel and leave the PB as true as required. The rest of your rule should work fine.
To give an example of how I use the cancel pending actions is with my lights at night. In the evening, I have a rule that gradually fades the lights over several hours until 11:15pm when the house transitions to Overnight mode. However, if I go to bed earlier, I just turn on my Goodnight virtual switch. My light fading rule has a required expression of the goodnight switch being off. Once it turns on, it cancels the light fade via cancel pending actions because the required expression is false.
There was no subscription to cancel at the moment the Boolean went false, it was a little over 800ms by my calculation from the time the private Boolean changed and the pending action occurred. Also in my screen shot above it still showed two pending subscriptions. One for power and one for the plug turning off. So that says it did not cancel them.
As to what I wanted to accomplish. As I stated in an earlier post, I just thought it would save adding a cancel pending actions to the rule. I wanted to stop the plug from being turned off if it was re-triggered while the turn off delay was still pending. Still seems like a bug to me, but I can make it work.
That's kind of the definition of a bug isn't it? 
Perhaps it is but using with the PB doesn't really seem like the intended case for this option. Perhaps Bruce @bravenel could take a look?
1 Like
I have the same problem (sometimes an rule stops after wait for event) since ages and today I found out when it's happening:
"Cancel timed actions" is ruining everything if the rule is currently waiting for an wait-event to happen and the rule is retriggered or restarted during this event-waiting and the "cancel timed actions" is activated. Next rule in line with waiting action will start the wait, but when the wait-event is over: nothing happens and Rule does not continue. Only removing the "cancel timed actions" OR retriggering/reactivating the rule outside an waiting-for-event will solve this issue.
If developers need information for this, just ask, I have made an small test rule with which I can 100% stop an rule after wait event when retriggered during the wait event. Removing the "cancel timed actions" will also solve it:
Additional info: it seems the rule only stops if the wait for event is immideatly after the cancel timed actions, If I retrigger my test rule during the second wait for event, the rule simply waits and then continues. So I added an delay after the cancel time action, and then it also works.
As I did not read all info about this matter and Cancel timed Actions, perhaps it is already solved elsewhere, but for me I also found an solution and it was an nice learning experience. This is the currect test rule which can be retriggered as much as you want, so I will use an delay after the cancel timed actions for my troublesome rules, but perhaps this could be baked in the cancel timed actions by the developers(?):
1 Like
