My rule with multiple Cancel Delayed Actions?

My rule is not firing automations particularly in the first few lines namely the Blind Closing and turning on a socket. They are delayed and cancelable actions and I am wondering if the additional rules below with the Cancel Delayed Actions are effecting the above rule? Any help would be appreciated.
(The mode stays in Day to clarify it does not trigger the Cancel actions)

Oh good, more evidence there is an issue!

I'm not sure if this is material but I think you've missed out an End-If, after If (Mode is Away...

No, that’s a simple conditional action.

It doesn't, only those active "delayed action", to impact the entire rule you need to use the "Exit rule" function. eg

Sorry, I should have used the word "those" in reference to active cancellable timers. It won't impact any non-active cancellable timers.

The way I have found it works, (using the below rule snippet), all of those actions will run if the preceding conditions are met. The 2 cancellable timers will both trigger active scheduled jobs, however, if there is a cancel clause added to the rule (it needs to be at the start of the rule or it won't work), and the cancel clause fires, both scheduled jobs will be killed off.

Screen Shot 2021-04-10 at 8.40.07 pm

eg, this is one of mine:

1 Like

I dont believe so, I'm fairly sure additional scheduled jobs will be created if the rule runs again and the conditions are still true, this I why I use the Private Booleans in many of my more complex rules so the rule cant trip over itself. eg

Good points, on further reflection, I think you are correct.

All good, sometimes we make our lives difficult by being too clever. :grin: However, that doesn't explain the scheduled action execution failures that he (+ myself and 1 other are seeing) when the rules appear logically correct.

1 Like

While not related to your problem, this is technically correct. However, in your screenshot, you are using "Cancel Timed Actions," which will cancel all delays (and anything else that is scheduled). You don't need to mark those delays as "cancelable" because it doesn't matter--it gets them all. More commonly, you'll see delays marked as "cancelable" and then a "Cancel Delayed Actions" action (rather than "Cancel Rule Timers"), and in that case the "cancelable" does matter--ones without this flag are unaffected. In both cases, it should cover all affected entities, not just the most recent (but again, the actual scope is different).

But I don't think that's related to anyone's problems here. Seems like there is something inconsistent going on. :thinking:

I appreciate everyone's time in replying. I will have a tinker around with it starting with the cancel delayed sections being at the beginning of the rule?

Would this be an example of my rule written properly? The exceptions at the beginning?


1 Like

That’s certainly how I was advised to use the cancel functions.

1 Like

I have done a little re-jigging. Will see if these fire now :man_shrugging: (Below)

Just checking, as long as I have End-Ifs between rules the triggers in each won’t cancel their delayed timers in the different sections? See below image.

No the cancellation is the whole rule. I don't understand your rule because you test the same modes with the same conditions multiple times? They are going to always run together so why make it complex?

Have you come from ST and webcore ?

BTW that's your issue you set up a delay then immediately cancel it on the next IF THEN block.


Originally came from ST but been here for a little while now, I have some relatively complex rules set up but sometimes come across learning points like this one. Now I know that the cancelled actions effect the whole rule I can work from there. I think I understand it better now, thanks for the assist.


Thanks all, between everyone's posts I have managed to work this out :+1:
You're all great, thanks again.


Best way is to think of it like a script that every time it triggers it starts from the top and works it's way down.

That's why you can put the lines in any order because you may want something to happen which you can test later down in the rule.