Will a rule run more than once at a time?

Working on automating my garage door. I want to trigger an auto-close after a certain time, so the trigger is TimeOfDay OR ContactSensorChange.

However I just opened my garage door , I dont want it to notify me immediately. Instead I wanted it to Delay15 minutes after the door opens and THEN check (if it's later than 9:30pm and the door is open).

Just curious, if I open and close the garage 3 times within those 15 minutes, will the rule be running 3 times?

If you put a wait of 15 minutes inside the rule. then every time the garage door would open or close it would reset that timer. So that timer's only counting down once

1 Like

Yes it would.

It would still happen 3 times I believe unless there is a cancel

1 Like

My past experience concurs with this.

1 Like

So....how could I make a rule cancel the previous instance up-front without actually canceling itself?

I don't use RM any more, so this is from recollection. Set the state of a PB (eg. true) when the timer starts running. When the rule runs, evaluate the state of the PB. If it is true then cancel timers.

Not a problem. Make the wait and close both cancelable, and first thing your rule does is cancel pending actions for itself. This instance of the rule keeps running and sets new wait and close events. Should work fine.

1 Like

Above is true but you could do
Turn off - delay 15 mins (cancelable)

Quite a few options.

I guess I should stop helping. Since there is no way to know this.

I would encourage you to not stop helping. Even if you were incorrect on this occasion, if you hadn't responded, it would not have promoted a discussion, from which we've all learned.

Edit: None of us knows everything (outside of Hubitat staff anyway). Discussion promotes learning - it isn't about being right or wrong :smiley:


I think you'll get better advice if you share a screenshot of your rule. It looks like part of the confusion above comes from waits vs. delays, which behave differently (delays must be canceled if that is your intention, as it would be here; waits are effectively canceled any time a trigger matches and your rule actions start over, so unlike as was suggested above, you probably wouldn't need to, but all depends on the rule).

Rather than Rule Machine, I suspect the Notifications app could more or less also handle this: notify if open for at least 15 minutes, restrictions so doesn't notify before 9:30 PM (but native-app restrictions tend to be naive, so you'll either want to really restrict this only until 9:15 PM or have a second way to check at 9:30 regardless of the open duration).

1 Like

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

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:

  1. Sync the position of the contact sensor to the virtual switch
  2. If I toggle the virtual switch on
  3. If I toggle the virtual switch off

You could then use these rules for your specific purpose (e.g. If TimeOfDay AND Virtual Switch is ON THEN turn Virtual Switch OFF)

are you do your own groovy apps
or webcore?


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.

  1. 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)

  2. 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.