I created a check in another rule I'm using to check if the rule is already running.
Create a local boolean variable, call it whatever you want. I called mine "RUNNING".
In the actions, run the following:
IF (Running = TRUE) THEN
Exit rule
END-IF
Before the start of the rest of your code, put
Set Variable Running to TRUE
At the end of your code, put
Set Variable Running to False
Just to confirm, you have a trigger for the garage door and a tilt/contact sensor to track the actual position of the door, correct?
I did my own garage door opener and this is how I did it.
I have a virtual switch that I link to my tilt sensor. If the tilt sensor is open, then the virtual switch is on. Vice versa for closed/off.
I then created a rule that if the switch is turned on, check to see if the tilt sensor is closed. If it's closed, trigger the garage door (me activating the door via voice control). [If the sensor was to open as the door is opening and trigger the initial rule, then it won't do anything]
I repeated the above rule for if the switch is turned off, but check if the tile sensor is open.
In total I have 3 rules:
You could then use these rules for your specific purpose (e.g. If TimeOfDay AND Virtual Switch is ON THEN turn Virtual Switch OFF)
how?
are you do your own groovy apps
or webcore?
Node-RED.
So this is my rule:
The goal here is that inside of the 10 minute delay I can cancel this rule by some means. So that if I'm out in the garage it doesnt close on me.
What I'm imagining is that if I accidentally close the door and re-open within those 10 minutes it will now have 2 delays running. Since i'm using a relay momentary-switch for my garage door opener, there's no real "on/off" it's really more like a button...and therefore would then re-open the garage door after the second delay.
I'm not even sure, in the end, if it will have any bearing on this particular rule, I'm just trying to understand how it works.
(and oops, I changed the trigger time to 9:15 but not the time-check statement. Will fix that)
To be picky, the issue here isn't really two instances of the rule "running" at the same time, but there would indeed likely be a problem with your rule as written above. (Hubitat apps, including rules, aren't always "running," just waiting for a scheduled event, subscription, or something else to wake them up if they aren't actually doing something at that moment. In the case of a delay, a rule makes a scheduled event for that far into the future that wakes it up and resumes operation. In the meantime, it isn't really "running." There are rare issues with two instances of a rule truly running at the same time, which can cause problems in that they share a single state and one could overwrite the "other's" [but again, actually the same] with unexpected data--consider issues people had a while back with "contact changed"-type triggers and contact sensors that sent duplicate "open" events within milliseconds of each other. But I digress.)
The issue here is that the "cancelable" flag that you (I'd say correctly) set on the "Delay" action won't do anything on its own. This just marks it as being eligible for cancellation. A "Cancel Delayed Actions" action in this rule would actually stop it (while ignoring delays without this set). If you're familiar with webCoRE on ST (or Hubitat, I guess), this is similar in concept to its Task Cancellation Policy (TCP) feature, except that TCP is on by default, while RM makes you create the same effect manually with the interaction of these two things. (Of note, a "Cancel Rule Timers" action can be applied to one rule from another, and this will stop any delay, with or without "cancel?" selected, but it also does a bit more and might be overkill for most situations.)
If this still isn't clear, the Rule 4.0 docs have a bunch of examples with cancellation, many in the context of motion lighting where the desirable and undesirable outcomes are easy to understand (e.g., you want the delay to get cancelled if motion becomes active again). I'm not exactly sure how you'd factor something like that into your garage door rule (what do you want to "cancel" this with? would a virtual [or even real] switch you could turn on when you want to override the rule be a better choice?), but I'm sure you have some ideas.
Let me give you a few user stories.
It's 9:45 and I got out to do some stuff in the garage. The rule triggers cause it's after 9:30, so I don't want it to close the door in 10 minutes. I just want to be able to cancel the rule completely. ( I have a few ideas in mind of how to do this, probably a local endpoint as someone suggested that I can easily trigger a rule to cancel this one)
It's 10:00pm. I open the garage to bring the garbage out. Rule starts counting and will trigger the momentary switgch to close door at 10:10pm. PERFECT! But...
2a. At 10:05pm I go back inside and close the door, then open it again cause I forgot to bring something else outside. Rule starts counting 10 minutes and will trigger momentary switch at 10:15
10:10pm = momentary switch is triggered closing the garage door
10:15pm = momentary switch is triggered opening the garage door
I can fix this scenario with an additional check to see if the door is still open. But I just want to understand if I need to do that in the first place. Will the rule actually maintain 2 countdowns?
set it up and test it. i think it will work fine.
Confirmed that this maintains 2 separate timers, and 2 instances of the rule.
Something like this perhaps?
Of course my devices don't match yours but it should get the idea across.
So cancel delayed actions:
Cancels delayed actions ONLY from THIS rule, but all instances of this rule?
Yes
Multiple simultaneous instances all share the same state, subscriptions and scheduled events. As a general comment, avoid creating this circumstance.
Watch out for multiple triggers of rules with delays.
Coming late to this party. Please describe what you are trying to accomplish, minus how you put it in a rule. A rule triggered by both a time and by a sensor event is a formula for problems.
Multiple triggers with an IF to sort out which one fired is not good either.
My only real question was...if I open my garage door twice in 10 minutes...but my rule has a delay of 20 minutes in the rule..."what's going on in Rule Manager".
I just wanted to understand how it works, so that as I add more Actions/Delays/Exception-Criteria, that I don't screw up the logic of what's actually happening.
I think I understand now:
As long as I start with "Cancel Delayed Actions", all previous instances that were being delayed are effectively destroyed. (I have to assume that means all actions after that delay)
Good point. I originally was going to post the rule without the time trigger. I was just trying to match his original request. The above sample will work just fine without the time trigger. The extra trigger is just an edge case that really isn't needed to be covered.
How do I do it without the time trigger.
What if I opened my garage door at 8:30, and now it's 9:30? There was no event to trigger the rule.
How do you do what? You haven't explained your use case, what you want to happen.
Don't leave your garage door open. 
I think it breaks down to this:
During the day if the door is left open don't do anything.
Between 9:30 and sunrise automatically close the door if it has been open for more than ten minutes.
Download the Hubitat app
