If I had to guess, your experience was probably the norm.
But if thereās a feature that can permanently bork a rule under the exact right conditions, and thereās also a viable alternative that canāt, you canāt blame them for yanking the one that causes problems no matter how rare.
I can understand that motivation.
But for me at least, a rule of that size is far more likely to have issues than like five or ten much, much smaller rules.
Note also that they didn't quite do this: existing rules using the feature will continue to work as-is. So, if it was really perfect for someone in a particular rule, that behavior won't change -- it was just removed as an option for new rules, effectively taking your options back to one of the alternatives that have long been available.
As mentioned above, if one of those alternatives isn't working, Logs are going to be the best clue for figuring things out. And they're the only clue if nothing stands out to you otherwise. That seems to be the case for this rule (though it's quite large and it's possible none of us are seeing something we should, another thing Logs can help pinpoint), aside from the smaller suggestions above. Enabling logs and checking the output would be the next thing I try.
Right, thatās consistent with how most features that were deemed to be in need of retirement have worked, IIRC. Thanks for clarifying.
If OP still has any rules with that switch, it wouldnāt be that hard to clone them and then reconfigure them to create new ones as needed.
Not the cleanest way to make new rules, but it would be the only way to still use the āignore trigger events while runningā flag with new ones (that I can think of).
Thanks all!
In regards to cloning an old rule...I'm assuming support for that switch will eventually be phased out?
@bertabcd1234 was pointing out that pre-existing rules that make use of the feature (and probably other rules that didnāt toggle the flag to active, but happened to be created during the time before it was deprecated?) will always be able to continue using it.
You canāt create a brand new rule and expect to be able to use it.
But you can still use old rules that have the toggle in them (if you have any). Always. Theyāre your rules that are already installed on your hub. Thereās nothing to āphase outā from Hubitatās perspective.
If you delete the rules, you wouldnāt be able to get them back (ignoring the possibility of restoring hub backups, for the moment).
But as long as you have even one rule that has the toggle switch youāre interested in, you can clone it and use it as a source of new rules, if you really prefer to design your rules in that manner.
Are you confident enough that the old switch will never go away that we can all feel safe duplicating an existing rule with the switch enabled to use as a template for a new rule?
thx
@bravenel has stated his intent to keep the feature for existing rules. That's his call, but removing it for rules that are already using it would break those rules, and that is generally avoided in updates, so I can't imagine it would happen. (When this kind of break would otherwise happen, that's how we got things like Rule 5.1 to replace Rule 5.0.)
But the other ways of doing this give you more control over how things work and the ability to "reset" the flag yourself if ever needed, so I would strongly encourage one of them instead -- and using Logs to troubleshoot the problem if it doesn't work as you expect for some reason.
thx!
Download the Hubitat app
