How does the "cancelable" functionality work?
For example, I have a rule to arm HSM with a 2-minute delay (I call it "turn on the alarm"). In the RM there is an option to make it "cancelable" But how does that work?
I'm assuming if I "turn on the alarm" during that 2-minute delay I can cancel the action... but how do I do that? I think this is an awesome functionality, I'm just not sure how to use it...
So setting it to be a cancelable task is what that toggle means. Once you have it set to cancelable then you need to have a rule that actually cancels it.
Here is an example:
Here's another example of how "cancelable" (and "stopable") can be used:
This rule is triggered if there is a status change in a number of contact sensors.
If the sensors are closed, then delayed actions are canceled and repeating actions are stopped.
On the other hand, if the sensors are open, after a delay of 5 minutes, there are two repeating actions that repeat every 5 minutes.
"Cancelable" marks something eligible to be cancelled by a "Cancel Delayed Actions" action. The rule in post 2 uses a similar-sounding "Cancel Timed Actions" action, but that actually does a lot more--and it will actually cancel a lot, including all delays or delayed actions, including those without "cancelable" set. (It also cancels repeats, waits, periodic triggers, and more, so I wouldn't get in the habit of using it to just cancel a delay; otherwise, some day you might accidentally cancel something you don't need to when you have more complicated rule actions.) So, technically, in the rule in post 2, you don't need "cancelable," but if it were me, I'd prefer to write it with "cancelable" and "Cancel Delayed Actions." Either is equivalent in that rule, however, since there are no other actions this would affect.
I probably just made things more confusing, but since you specifically asked about "cancelable," I wanted to make the scope of its impact clear. 
To simplify the examples a bit, here's a very simple rule using a common pattern you'll see:
Triggers: Contact Sensor changed
Actions:
IF (Contact sensor open) THEN
Delay 0:10:00 (cancelable)
Notify "Door open for 10 minutes"
ELSE
Cancel Delayed Actions
END-IF
This will notify you if the contact sensor remains in the "open" state for more than 10 minutes. If your rule actions didn't have "cancelable," then "Cancel Delayed Actions" wouldn't do anything (though you could use "Cancel Rule Timers" still as a blow-it-all-away solution as above--you don't see this in examples usually). If you didn't have "Cancel Delayed Actions," then your "cancelable" flag is harmless but also meaningless. Some people are tempted to write the rule like this:
Triggers: Contact sensor opened
Actions: (in case you're just skimming, please don't really write this rule)
Delay 0:10:00
Notify "Door open 10 minutes"
...but that will send you a notification 10 minutes after the door is opened every time the door is opened, regardless of whether it's been closed in the meantime (or how many times it's been opened--you'll get a notification for each). You can imagine the surprise some people feel when they write motion rules in a similar fashion. Cancellation is the key to making things like this work as expected. (You don't need to write rules like either of these, though: the Notifications app can handle this, and Motion Lighting and even Simple Lighting can handle most motion lighting cases.)
This is why I absolutely hate Rule machine. I feel like it's far too complicated. Much of that may be because the interface is terrible for multiple conditionals. I was using webCoRE for a while until I had hub issues, and that seemed much easier to follow. I actually ordered a second hub just to run echo speaks and webCoRE so I wouldn't impact my automation.
If you're used to webCoRE, then you can think of "cancelable" and "Cancel Delayed Actions" as the equivalent of webCoRE's Task Cancelation Policy--they have the same effect except it's enabled in webCoRE by default (also to the confusion of some but often helpful in situations like this).
The RM UI is indeed a bit constrained, but they've made strides in 3.0 and 4.0 working within the limits of the app UI model they mirrored from ST. I don't know if you ever used CoRE on ST, but I'd guess that's definitely the reason they moved to webCoRE. Same constraints and reminiscent, at best, of earlier Rule versions on Hubitat. I'm sure it will improve more over time, but I suspect significant change would require them to create a new app UI model--something they've indicated they aren't opposed to, though not specifically for RM.
I agree 100%. I often find it difficult to find the exact function I want to do in RM. I have seen the improvements they've made even from the app that was over on ST. Same for WebCore.
I was actually one of the early adopters of ST and moved to Hubitat shortly after launch (I think) . so I have seen it improve over time.
Anywho. I have officially hijacked this post. Sorry @charlesrblack
I understand the concept but am unsure of its scope. Does it work just for the current set of actions / rule / the whole of hubitats rule system?
Say I've got lights doing one thing and I want to cancel that from another rule. How is this best done? Setting a variable and reading that from the other rules?
"Cancel Delayed Actions" works only on the current rule (and only on delays marked as "cancelable"). If you do need to do something from another rule, "Cancel Rule Timers" is the only choice you have in terms of similar options, which lets you choose the current rule or any rule. However, besides all delays (cancelable or not), it also cancels periodic triggers, in-progress fades, and basically anything with a schedule as explained in the UI when you choose this option. However, you could definitely use a global variable (as you suggest) or private Boolean, both of which can also be modified by any rule, if checking the value after the delay and deciding what to do then works for your particular situation.
Excuse me, but I can't quite understand how it works. In the example below, does the 2 minute delay cover the OFF of SOTANO 1 and SOTANO 2? Or would I have to put the lines backwards?
Yes. For a "Delay" action, a "Cancel Delayed Actions" action will (if run) cancel all actions after the delay. In your example, this cancellation would include the "Off" command for both of your switches.
Putting these actions in the other order would not do anything--the actions would not be delayed, and they would not be cancelled (you can't cancel something that has already happened), so you might as well not have either the "Cancel..." or the "Delay" in that case.
Ok, thank you very much
Download the Hubitat app
