Running the latest on a C8 Pro
I no longer see this option when creating new rules in Rule Machine.
I went back into an old rule to make sure of what I was thinking...and when I clicked on it (from on to off)...it disappeared.
This is a really important feature! Please Help
This was removed some time ago. It was deemed to not be as reliable as required expressions or conditional triggers. If you had rules that we're using this it stayed present but it isn't available on new rules.
My suggestion would be on new rules to us private booleans in required expressions or conditional triggers. They aren't perfect either but will work.
Here's is Bruce's reccomendation
Thanks. Seems like if it so easy to do this with the private booleans works...it would work in the code,
I really miss the switch.
BTW...I really strive to keep my rules a simple as possible (KISS).
For some reason I though that the private meant "known by the current rule running only" and that try to run the rule the next time would be a "new" iteration unaware of the local viable in the iteration that already started. Interesting.
So this works as well if you launch a rule...call another rule that is running it's own stuff in sequence...and while that other rule is running...it would still deny the originally called rule from running again if retriggered?
Hope that make sense.
Sorry, I've tried to read your post a few times, but I still can't make sense of what you're asking.
If that last part is referring to the "Run Actions" command used to call another rule, that literally just runs the Actions of the called rule - it has nothing to do with that rule's trigger(s) or required expression (exception).
Think of a private boolean as a toggle switch inside the rule. If your required expressions or conditional triggers says that the private boolean must be "true" for the rule to trigger them the private boolean must be in the true state. The first step in the actions of the rule would be to make the private boolean "false", then step through the remaining sequences of your rule. This prevents the triggering of the rule again while it is running because the required expressions/conditional triggers is not met. Then the last step before completely ending the sequence of actions is to set the private boolean back to true. This will allow the conditions of the required expressions/conditional triggers to be met and ready to trigger the next time the rule is supposed to run. It is basically a toggle switch inside the rule that says this can't run again until we are finished.
This does not stop you from calling actions of another rule inside a rule as long as the initial triggers are met.
I believe the issue with the "Ignore Trigger Events while Running" switch, is that it could occaisionaly (not often, and only in some edge cases) fail. Aka, then a rule would be effectively disabled (as the system thought it was running), and since you have no visibility to the internals or means to correct this - the rule was effectively disabled (and that wasn't obvious), until you turned off this switch.
PB's can also fail (and occaisionaly do), if you happen to be unlucky and reboot while in the critical section while the PB is set to false (perhaps with a delay in the rule), and you happen to reboot, and now the rule is also effectively disabled, by the PB
Bottom line, both mechanisms to protect critical sections of code (trying to avoid race conditions) can fail
The only advantage of PB's is that they are much easier to see, and you can either do a "force to known state" at boot, manually reset it, or fix during some late night "clean-up" rule. It's just the "Ignore Trigger Events" approach, while saving some code and allowing you to avoid dealing with PB's (which is a commonly repeated pattern in alot of my rules) - But it also had cases where it failed, and when it did, it was much less obvious, and much harder for a user to fix.
So the intent was nice (Thanks Bruce!), but we're back to where we started with PBs... (don't get me started on a desire for semaphore's or mutexes, but that's a post for another day) IMHO, given the multi-threaded nature of the system (RM included) - having some concurrency control primatives would be nice. - But we have PBs...
That makes sense. Thanks for all the detail. It would still be nice to have that toggle...but once you know something is now different it's easy enough to work around. I need to figure out how to not miss change update notices like this. I always read release notes and must have missed this one.
Yeah, it was pretty well buried in the 2.4.0.142 release notes - Under Bug Fixes - There was alot to that release, so easy to miss. The specific quote was:
Well that's pretty obvious. Thanks.
I assume the recommendation is to rewrite any rule with that enabled? By default I turn that on.
In fact denying a rule rerunning should simply be the default it seems to me.
I'm sure there are use cases...but even though I don't have but about 75 rules...I NEVER once want something to rerun while already running.
Per the release notes linked above, existing rules should remain unaffected.
Thanks. I would think eventually...if not already...support would be dropped for the feature. I guess the real point is that the private boolean method is more stable.
In my experience using a PB in the Required Expression has a timing problem. I.e it will not prevent a retriggering if trigger events are coming fast (faster than once 0.5 - 1 sec). I am using a "Virtual Switch goes On" as trigger event and a triggered rule resets this VS at the end. This approach requires an middle man Virtual Switch and the Required Expression cannot be used. But it 100% guarantees from unwanted rule retriggering.
Why would the PB not work if the trigger events come quickly? If the first step in the rule is to change the state of the PB after triggering the rule then it should make the rule not able to run again until the last line where the PB state is returned to the state of the required expression. I know there is a slight delay after triggering to change the PB state but it isn't long. Maybe I am not understanding how it works.
I'm pretty sure that's one of the reasons why Bruce generally recommends using PB as a Conditional Trigger (see post #3 above) vs Reqd Expression. But I of course don't claim to speak for Bruce, so take that with a grain of salt.
Yes, using PB in Conditional Triggers works much better. But the problem is - Conditional Triggers can't have a Logical Expressions.
TIMING!
The Required Expression is running as a separate thread (or so, I am not a SW engineer).
Usually it takes 0.5 - 1 sec for the Required Expression to become FALSE. As a result multiple retriggering could happen in this time frame. Unfortunately stepped into this problem.
Ok that makes sense. I have a few rules with required expressions but don't have triggering events near that quick of repeat so it hasn't been an issue.
One more comment related to the Timing.
If the rule can 100% complete all Actions before next Trigger Event there is no need to protect it against multi-triggeriing.
Download the Hubitat app
