Most of the things that I want to work around actually have to do with triggers. I do not need to bail out of actions, I just need to stop the rule from starting in the first place. A good analogy is how motion sensors may have a timer to ignore retriggers in their hardware settings. What is the proper way to do that in Rule Machine?
1 Like
That what the Required Expression is for.
1 Like
No, you have to set up:
Until that is ātrueā. All triggers will be ignored.
Define your own expression, thatās just how I did it for my rule.
Thank you!
Edit to add: to the OP's point, while this trigger-defeater Required Expression is very useful I can also see value in adding shortcuts to the most common retrigger issues like "ignore this trigger if it went off within the last X minutes." I am sure that is possible to build in the Required Expression though I don't see how yet.
3 Likes
But you'd still have to repeat that call at every exit point in your rule, so it would still be messy. Also you'd need a separate rule of which to run the actions for each rule you only wanted a singleton of, as each time it would be a different variable you'd want to set. This would therefore be worse than explicitly running the variable setting in the original rule.
@bobbyD Does the ārun actionsā command execute the āactionsā like a subroutine and return or does the command just ālaunchā the specified rule and continue on in parallel?
It runs in the actions from that rule in parallel to the rule that called those actions.
The starting rule keeps running, unless you introduce a wait after calling those actions with some sort of logic to resume after the called actions finish.
2 Likes
Thanks, as I suspected. So go practice for its use would be to make it the last command in a rule or be sure you donāt depend on its work without checking first.
It really depends on the situation. For example, I have several "arrival" and "departure" rules that will run rule actions from several different rules in parallel all at once while also continuing its own other tasks before quitting. Running things like enabling the auto-door lock rule, activating several security notification rules, turning off particular lights, etc all in parallel is fine as nothing is waiting for any sort of feedback in this case.
However, at the beginning of my departure or arrival rules, there IS one rule action that I run and then pause and wait for a result before continuing. And that is to determine if there are any other family members present at home and which ones, as that determines what the rule will do next when it resumes.
I guess when you think about it, every command, with the exception of the delay and wait variants, is asynchronous. Some are just so fast they seem synchronous.
In all fairness, it is not quite as simple as you would like it to be.
Nevertheless, given that this issue is one that comes up over and over, and despite the documented solutions and ignored advice concerning KISS, I am adding a feature to RM in the next release that can cause a rule to ignore trigger events if the rule is already running, like this:
There are three ways a rule can come to the end of "running": after the final action is run, the Exit Rule action is run, or Stop Rule Actions run against the rule (by some other rule).
Here are the logs of a rule with a delay that is triggered multiple times during the delay:
Notice that there were 4 instances of the rule running simultaneously, each throwing a delay, and that eventually those delays catch up.
Below are the logs of that same rule running with similar trigger events but with the option to ignore trigger events turned on:
Notice that it logs the fact that trigger events are ignored. The rule won't be triggered again until it has completed 'running', including all of its delays expired (or stopped).
This will be in the 2.3.9 release.
19 Likes
Thanks, I love it.
So Iām learning, Iām not having a go at you Bruce, itās just that Iāve never seen an any documentation that describes the multi threaded behaviours being pointed out.
The Multi threaded behaviour of RM has tripped me up countless times and Iāve had no idea why. That might be my fault, but from my simple non developer point of view, RM rules look like they are 100% serial, unless they are calling other rules during execution.
This is a huge trap for non devs and RM muppets like myself.
Awesome, thank you. 
1 Like
Actually it's only a problem for people who create pretty complex rules with IF-THEN blocks with embedded delays against frequent triggers. The same users hit this over and over. Hmmm.
Odds are good that using this feature will result in other surprises, like, "why didn't my rule trigger" when the triggers are being ignored.
8 Likes
I get what you are saying, but to the average user the following 2 blocks look functionality identically:
Delay 10 seconds
Turn off light
Vs
Turn off light - Delay 10 seconds
And yet the latter code block is adding multi threading to your rule.
3 Likes
A discussion on this particular issue is linked to in the Rule 5.1 docs (also accessible from the "?" icon in a rule as it is for most apps).
1 Like
Fair enough, maybe Iām just dense - until it was explained here, I didnāt appreciate this fully.
Both create new instances, not just the first one. Both exit the rule for the delay, and the rule 'comes back to life' after 10 seconds (a separate instance from the original). Either of those would be problematic with frequent triggers nested inside an IF-THEN block. Those differ only as to the continuation of actions after the second one, where succeeding actions would run before the end of the delay, and in the first case all actions are delayed.
3 Likes
