RM Feature Request: Prevent rule from triggering if already running

[jwjr]

Just confirmed (by setting a known false as a required expression) that Run Rule Actions ignores the RE.

[PunchCardPgmr]

@dJOS

I know I'm being somewhat lazy, ....I'd really love this to be as easy as enabling a slider.

I think it's more than laziness...it's also a matter of someone coming to HE and wanting to jump into building rules but gets caught in little "gotchas".

They come in trying to do something pretty simple, maybe they have no clue about the nuances of a multi-threaded trigger based environment, yet have to learn/remember/maintain the extra overhead to prevent the situations which will trip them up and turn them into frustrated new users.

A toggle button sitting there begging the question of "do you only want serial, only-when-not-already-running, triggering of this rule" is just one of those "onboarding facilitators" that is helpful to their eventual growth & expanded use of the environment.

EDIT: Seeing Bruce is working on a reply. Can somebody else post real quick so I don't have to be the one right above his torch & burn.

[bravenel]

@terminal3

if the rule is triggered and executing do not trigger again

The problem you are wanting to address is caused by the fact that a rule does exit for delays, waits, etc. But, you don't want those to count and instead deem that the rule is "executing" in those cases.

@dJOS

I’d have thought that under the hood of RM there was an “exit rule” subroutine that is called whenever a rule completes or is canceled.

No, this isn't the case at all, there is no such 'exit rule' method. What you are missing is that the concept of "running" doesn't really exist. Or, rather, the concept of "done running" is not a single thing that can be used to address the multiple instances situation.

The solution to these problems is to stop creating complex rules with delays and waits embedded in iF-THEN-ELSE blocks. Every single one of these can be done more simply. There is a price to be paid for ignoring KISS, as if it doesn't apply to you. Oh well, I have tried to provide an education about this, but it's clearly just lost on some users.

[a.mcdear]

@bravenel

The solution to these problems is to stop creating complex rules with delays and waits embedded in iF-THEN-ELSE blocks. Every single one of these can be done more simply. There is a price to be paid for ignoring KISS, as if it doesn't apply to you. Oh well, I have tried to provide an education about this, but it's clearly just lost on some users.

Yep, that's me.

I mean, simplicity certainly is not lost on me, but at the same time I let things get quite complicated too.

I make some pretty complex rules doing many of those "expensive" RM options, but by and large I seem to have no real problems with my rules. I may have problems with them initially when I'm trying to achieve some complicated automation, but once I work out all the bugs it seems I can have very complicated rules that also execute properly, predictably, and very reliably.

[TArman]

So the concept of changing your private Boolean at top and bottom of a rule doesn’t “really” work if there are delayed actions that hang over the end of the rule.

I have to make sure everything is “waited for” if I really want all of the actions to be completed before I re-enable the triggers?

Is there a KISS tutorial for rule machine?

[dJOS]

@bravenel

The solution to these problems is to stop creating complex rules with delays and waits embedded in iF-THEN-ELSE blocks. Every single one of these can be done more simply. There is a price to be paid for ignoring KISS, as if it doesn't apply to you

I use delays in my rules simply because I need to verify via “repeat while loops” that some devices are doing as they are told. I wish I didn’t need them, but my two Zigbee thermostats are only about 90% reliable.

I also use them for my door locks, not because they aren’t reliable, but because failure is not an option.

[dJOS]

@TArman

So the concept of changing your private Boolean at top and bottom of a rule doesn’t “really” work if there are delayed actions that hang over the end of the rule.

I just tested this by intentionally adding a 30 second delay after setting the PB to false, and my rule definitely would not run again until the PB changed to true.

In my case I have a lot of rules, and some of them have multiple triggers. These rules benefited greatly from being serialised and noticeably reduced the load on my hub.

[a.mcdear]

@TArman

So the concept of changing your private Boolean at top and bottom of a rule doesn’t “really” work if there are delayed actions that hang over the end of the rule.

I don't believe that's what Bruce meant. I have rules with waits and delays and Private Booleans to limit concurrent instances of those rules and they all work fine. I think what he was saying is, in the context of creating a simple toggle for limiting to only one instance of a rule, there are way too many variables to consider that make the task not worth the effort.

[a.mcdear]

@dJOS

I also use them for my door locks, not because they aren’t reliable, but because failure is not an option.

Same.

[Horseflesh]

@PunchCardPgmr

They come in trying to do something pretty simple, maybe they have no clue about the nuances of a multi-threaded trigger based environment, yet have to learn/remember/maintain the extra overhead to prevent the situations which will trip them up and turn them into frustrated new users.

I just went through this a few days ago. I have been a user for a long time but only recently have I started working on more complex automations and understanding RM. I immediately realized that very simple automations were going to have problems with retriggering because of the nature of the real-world events being monitored. The scripting required to work around retriggering is not the fun part of home automation, at least for me.

[dJOS]

@Horseflesh

. I immediately realized that very simple automations were going to have problems with retriggering because of the nature of the real-world events being monitored.

This exactly! If only the real world was simpler.

[TArman]

I may be wrong, but as I see it, there are “fire and forget” commands like switch actions. The command is called and the rule goes on to the next command.

There are “stalling ones” like wait and wait for event.
RM stalls until the command completes or times out, then goes on to the next command.

Simple sequence to illustrate my statement above:
Requires Boolean true
Trigger once every second
Rules:
Boolean set false
Turn on light
Turn off light delay 10 seconds
Boolean set true

What would the log look like?
Would the light ever turn off?
If so, when?

(Silly rule, but it can be extrapolated to real world situations.)

[dJOS]

@TArman

What would the log look like?
Would the light ever turn off?

I’m pretty sure that rule would work just fine and the light would turn on and stay on for ten seconds. Then turn off and 1 second later turn on etc etc.

[bertabcd1234]

@TArman

Would the light ever turn off?

Yes, a delay is never canceled unless you do so specifically, and a delay on an action (as appears to be illustrated above, as opposed to a separate delay action) just schedules that particular action while immediately moving on to the next.

[TArman]

Try it, I goes crazy flipping the light.

[dJOS]

Hmm, can you post a screen shot of the rule?

[Alan_F]

The rule you posted is doing exactly what you set it to do.

It sets the PB false, turns on the light, schedules turning off the light in 10 seconds, then immediately sets the private Boolean true. When the "every second" triggers again, the private Boolean is already true.

It should turn the light on about 10 times in a row, then the first "off" event will occur, then it will rapidly alternate on/off as different instances turn the light on and off.

Try changing the "turn off light delayed 10 seconds" to two separate actions...

Delay 10 seconds,

then turn off the light

That way the private Boolean won't be set to true until after the light is turned off.

[TArman]

[TArman]

@Alan_F

That way the private Boolean won't be set to true until after the light is turned off

That’s exactly what I was trying to illustrate to say that the rule doesn’t “end/finish” just because the last command was run.

[dJOS]

Hmm, I wonder why there is a difference between adding the delay to the command, and adding a delay before the command?

I’ve noticed this myself in rules, and it makes zero sense to me.