I've been having issues with some of my HVAC rules misbehaving and I traced the issue to them being re-triggered while still executing and then producing undesirable results.
Anyway, after much searching of the forum, I finally found a solution - using Private Booleans:
While this works for me, it's imo a hack and comes with its own issues. eg a couple of times while testing my rules, the Private Boolean has become stuck in "False" preventing the rule from ever working again. I had to manually hack in a "set private boolean to true" before the "exit rule" and then very quickly pause the rules and edit out the "set private boolean to true" before then resuming the rule.
I think there is a very simple permanent fix to this, an Official Option to prevent Rules from re-running if they already executing (aka denounce). Thinking about this logically, having this as a Local option for Rule Machine has the potential to reduce Hub overheads at the same time as preventing unwanted results.
I have a rule where the PB would get in the wrong state when it should not have been possible. Others have seen it as well. In my case and at least one other that I know of we changed the PB to a local variable and have not had a lick of trouble since. And if you do it's easy on the rule to change it's value right there where you configured it to begin with and then run your test again.
There is no way to know that a rule is "running". They aren't actually running while waiting for a Delay or a Wait. Even if there was such a thing, it wouldn't make sense to do this. Essentially what you're suggesting is a conditional test to determine if a rule is running, and do nothing if that's the case. That's exactly what setting a variable or Private Boolean tested in the rule does.
You complain about PB getting "stuck". What would prevent some automatic mechanism from getting "stuck" the exact same way? Suppose a rule just never comes back, while the automatic mechanism is waiting for it to complete. This could happen, for example, by a Wait that never is satisfied, or a delay that has the wrong value in it. PB doesn't get "stuck", it is set by the actions of a rule. If the logic of those actions is wrong, there will be a wrong result.
So, there is no magic bullet to be had for this. Hubitat is a multi-threaded, event driven system. This has many implications for creating automations, including dealing affirmatively with the possibility of simultaneous execution of an automation. This has to be considered and dealt with when the automation is created. There is no avoiding this reality.
There is nothing special about Private Boolean. It behaves exactly the same way a local Boolean variable would work -- you can set it to true or false. How you do that has to be thought through carefully, working through the cases.
You didn't show your triggers so it's not possible to give a suggestion about how to do this. The way you have it setup is pretty much guaranteed to fail because of the delays. The rule will run through, with PB false, start a delay for 10 seconds, and then set PB true before those delays have completed. So it will then be vulnerable to being triggered again, and colliding with itself. That was the problem you were trying to solve, but you didn't solve it.
This has absolutely nothing to do with hub overheads, which for a rule like this are minimal.
The most surprising thing is that you have a rumpus room. I haven't heard of one of those since the 70s.
But seriously, what has worked better for me is to separate out the Private boolean part of the rule. In fact, I think you should use more PB here by you separating it out into smaller logic checks for each of these Else-If statements.
I know, you want it all in one rule to reduce clutter. But diagnosing this and making it run consistently is hard if not impossible. Maybe I need more caffeine, but it is making me dizzy even looking at that rule.
Ok good to know - I was born in the mid 70's and grew up with the mindset that using Computer resources efficiently was the ultimate goal. I guess that's why I've always hated Windows and preferred OS's like pure MS DOS, Amiga Workbench, and Unix/Linux variants.
I was tired when I wrote the above post and I meant to say a "Local Rule setting" (as in per rule option) as a global setting would break rules that have built-in Cancel functions etc. Well respectfully I'd suggest there is if enough thought is given to the problem as clearly we can do this ourselves programatically.
Yes, IMO this would be a per rule-setting (defaulting to "off") and perhaps part of the Triggers Config options - eg if the rule is already running, ignore additional triggers" or something like that.
I'm not complaining, I'm just pointing out I've had PB's break twice on 2 different rules in the space of 30 mins. Yes, I was working on the rules at the time which may be a contributing cause.
I didn't show my triggers because they aren't relevant - but for completeness, here they are:
The delays are a necessary evil with the Remotec ZXT-600, the way these things work is endlessly frustrating and Im not sure it's a driver issue (these suck on the Community driver too).
I've found that every time you change the SetPoint, the stupid thing sends an "Auto Fan" command at the same time and because they are so slow, I need to wait before sending the Fan speed command to override the Auto option.
It took me ages to realize that individual rules could spawn multiple threads in this way (I guess it should have been obvious seeing as I'm already using the cancel functions in quite a few rules). Anyway, I guess all I'm suggesting is a local option that lowers the barrier for entry for folk.
RM is amazing and powerful, but IMO it couldn't hurt to add some user-friendly touches.
As I said above, this is both impossible to do and not a viable fix for the problem you have.
This is undoubtedly a user error. Private Boolean doesn't just break.
The problem isn't with delays per se, it's the way you did them. Use Delay Actions instead of a delay on an Action. When you put a delay on an Action as you did, the rule continues to run through the remaining actions, thus getting to the spot where you set PB to true long before that delay has finished. You need everything to stop for the delay period, which Delay Actions does.
Oh, so we vote on facts? Others too can make user mistakes.
There are two types of delays, not just one. One is specific to a particular action, and causes that action to happen later but has no affect on other subsequent actions in the rule. The other delays all actions. Different use cases argue for one or the other to be used. You just picked the wrong one.
There are lots of people who make specious claims about things, reported as fact, when the reality is that they don't know what they are talking about. It's necessary to call a spade a spade and shoot down these mistaken claims of fact for what they are: misinformation. Not really trying to be snarky about it, just don't like to see misinformation spread in the community. Some people will not accept the truth and will argue from their 'experience' without understanding how wrong they are. These are subtle and complex subjects, and it is easy to get it wrong. It's not helpful to other users to spread misinformation such as "Private Boolean breaks".
If someone can come up with a conclusive and repeatable demonstration of a bug in Rule Machine with respect to Private Boolean, or any other aspect of the app, I'm all ears and would salute such a demonstration. There are always bugs in software, and we strive to identify them and correct them. There is also misinformation, in particular 'bugs' claimed that aren't bugs at all, but are instead user error. We have an obligation to correct that as well.
No. But you can Pause it if there is potential for it to get messed up. Due to the asynchronous nature of the hub, a Rule doesn't really "know" it's being edited. Suppose, for example, you open a rule to possibly make a change, and then switch to another tab and start doing other things. What state would you expect that rule to be in at that point?
Some changes to a rule, those involving event subscriptions (triggers) and scheduled events, are only changed with you hit Done or Update Rule. Other settings in a rule are changed when you make the changes, quite possible before you even hit Done on whatever page the setting is on.
May I ask, what is the difference between "Delay Actions" and "Wait for Elapsed Time"? They seem conceptually very similar. Would there be a use case where one would be better than the other?
Wait for elapsed time, like all Waits, will be automatically cancelled if the rule is triggered. A Delay Actions is not cancelled unless it is set to be cancelable, and there is an action that cancels it.
I think it's just become the default description in Australia for a second "lounge room".
