Right before my nighly backup runs, I run a rule that refreshes a bunch of devices, ensures some key things are on/off as necessary, and resets all my PBs to True. It's my "make sure this imminent backup is tight and everything's ready to rock for the upcoming day" rule.
1 Like
Thatās a great option, Iāve asked a long time ago for Hubitat to do this, but was told no itās too hard. 
If this is considered as a warning it is indirect and very well hidden.
And what will happened to the rules which are currently using this feture?
My good guess, they will become retriggerable while running. Is this correct?
2 Likes
To be fair to Bruce, this would likely be called out in the release notes.
2 Likes
I hope, this will be a case.
And in addition it must be a very clear warning something like:
DO NOT UPDATE TO THIS LATEST PLATFORM UNTIL YOU MANUALLY FIX ALL YOUR RULES WHICH ARE USING THIS OPTION.
But now I will have a huge headache to go through all my rules, find out which one is using this option and find a new reliable solution for preventing unwanted multi-triggering other than using a PB.
1 Like
Yeah itās a pain for me too. I mainly use it for temp controlled rules with multiple sensors as triggers.
Your rules will continue just as they do now. The option to enable the feature will go away. Current rules will work as they do before the update.
Whoa, warning them to read the release notes from within the release notes IN BOLD CAPS TEXT will surely do the trick! Thanks for the help.
Better you do this than rely on an unreliable feature.
There is a lot of history to this, as you well know more than most. I resisted for years requests to put in a feature like this. While seemingly quite simple both conceptually and to implement, it turns out that in certain circumstances it will fail. I can't characterize those circumstances with any certainty. So, adding this feature, while well intentioned, was a mistake -- let's be clear about this: my mistake. I should have continued to resist requests for this, and will do so going forward.
The solution to this is actually quite simple: avoid complex rules with nested IF-THEN, IF-THEN with embedded delays, *changed* triggers followed by Conditional Actions based on the same event information, having just discarded said event information by using *changed*, etc. etc. The remedy is the same as it's always been: KISS.
You guys must have homes with vastly more complex things going on than my own. Even though I've got 275 devices and hundreds of apps, I have never once seen a need for anything that might cause these problems.
2 Likes
You are also a professional developer, so you can more easily see efficient programmatic logic to solve your automation problems than most of us non-devs can.
Ha, I haven't had a job as a developer since 1990; I'm just a retired old fart who learned Groovy so I could use SmartThings, and accidentally co-founded Hubitat.
But, your assertion is false, unless you accept that decades of experience repeatedly returns me to KISS. There's nothing sophisticated about KISS, and there isn't any "programmatic logic" needed. Most of my rules are very simple, with no logic at all. All of the complex stuff is done in Room Lights, or Thermostat Scheduler, etc, but there the apps do the heavy lifting, not me as rule author. I'd barf trying to do what Room Lights does with rules.
If you want to do complex things, learn Groovy.
1 Like
Just to hammer this home, how would it NOT help to make a clearer, more concise distinction between these two options that have the exact same description?
Seriously, how hard would it be to for this to read "Scheduled Delay" or something equally descriptive? How would this NOT be a clearer, more concise description of what this option does?
Ok fine, you win on a technicality, however your skills are a million miles beyond my own. I only barely passed programming at college, with a lot of help from my friends.
I am EE and my brain cannot readjust thinking for all these restrictions. My automation goal is near "hands/commands free" operation. Unfortunately this approach often requires relatively complex rules. As of today, believe it or not, this goal is achieved with very high WAF. I clearly understand differences between implementing logic in hardware and software. In old days the SW was much slower than HW but the SW behavior still was very well predictable.
Untill this multitasking and multithreadind was introduced ...
1 Like
Every time I am facing a problem which must not exist in a first place I am thinking about programming logic myself. But thinking about debugging things with only massive logging available as a debugging tool this immediately becomes a show stopper. Yes, I am spoiled by using very powerful real time debuggers (brake points, memory watch, etc.,etc.).
1 Like
Please confirm I got this message very clear.
This option will remain "as is" (i.e. still functional) for all current rules which have it enabled but will be unavailable for all new rures and existing rules which are not using it currently.
If I got it right and this is a case could you please add some sort of indicator that this now hidden option is active?
1 Like
While I don't have a stake in this discussion, I agree it is worth explaining the intended behavior re existing rules, in particular those that currently / previously use the feature. If they are updated, will they continue to include the option enabled or suddenly have it removed upon the next edit, or forever have the option enabled, needing to be re-created in order to have it removed.
2 Likes
That's how it will be after the update. If the selector is on, you will still see the selector (and could turn it off, but not back on again). If it's not selected, there won't be a selector. If selected, it will work as now.
3 Likes
PERFECT!
BIG THANK YOU for making this very clear.
So at the risk of being pedantic,
If we want to "use this for future rules (where there are clearly edge cases with "issues" today), then we should create a "stockpile" of empty/disabled rules, where this is enabled, so we can leverage this "cache" of these "grand-fathered" rules.
I'm not trying to be obtuse here, but I find this feature "easier" to deal with than PB's, and would like to continue to leverage this - Or thinking this thru a bit more - Could this setting be "preserved" when a rule is cloned/exported/imported?
What's a few dozen disabled & empty RM rules between friends...
@bravenel aside from calling me arrogant for daring to suggest clearer labelling for the two different implementations of ādelayā, you still havenāt answered my question!
How would it not be helpful to label these two functions for what they actually do? Eg
1/ scheduled delay
2/ inline delay (or something at least as descriptive like ārule delayā or "pause for hh:mm" etc)
Well, I guess here's a "case-in-point" about nomenclature similarity that I will embarrassingly present.
Function #1 I took to be facilitation of imposing a Delay without the extra line of code and without any consequences different than Function #2.
Function #2 I think I came into using as a clear & overt step to getting a resilient Delay after, cough, wondering if Function #1 wasn't subject to something I didn't quite understand.
So yeah, not going and reading the documentation on this (and just assuming similarity) is on me. Should have known from the past that...just because something "looks" the same doesn't mean it "is the same" or getting there by the same means.
2 Likes
