@bravenel I seem to recall someone asking for this function before, but I cannot find it in searching the forum. I think you had previously responded to it so I apologize if it’s been asked already.
I have rules that have required expressions at sunrise, and others with required expressions at sunset. It all works great, unless I have an incident that takes the hub off-line during that change-over period. As an example, we lost power at 1 AM and didn’t get it back until 11 AM. When this happens, I have to manually go into those rules and click the Update button to set their required expressions to the correct state.
What I would like, would be the ability to update those rules via Rule Machine actions from another rule. Just as we are able to Run Rule Actions from RM, it would be great if we could Update another rule from a RM action. This would allow me to build one rule I could trigger to repair the required expressions of multiple rules with just a single RM trigger.
Oops, confused restrictions with required expressions. Sorry about that. Kind of tired today after being woken by our ceiling fan light flashing on and off when the electricity cycled several times before finally staying off.
@bravenel Since evaluate required expression at systems start up is an option, is there a detrimental effect when enabling this for too many rules at once?
Maybe it’s my lack of sleep, but I can’t think of a scenario where I wouldn’t want to evaluate a required expression at system start up, unless it was detrimental to evaluate required expressions of every single rule that had them when the system starts up.
With that said, I’d personally would rather have it default to being evaluated on startup anytime I use a required expression, and then if I don’t want it to be evaluated, I turn that option off. Or, the option instead says “Do not evaluate required expression at start up” and it remains disabled by default until I enable it. To me, it seems this would be a lot more user friendly to those that didn’t notice or forgot about that option, like I did.
I am not sure. Any expression that depends on a device attribute, for example. Even if you re-evaluate it at startup, the current value of that attribute in the database will not necessarily have changed since the hub was last up, and may be different from the actual device state, until the next event. So reevaluating it does nothing helpful.
The option makes sense for a required expression that depends on a time event that, if missed, might not reoccur for a "long time" (e.g. I have a rule that has a required expression on a "heating season" variable that changes only twice a year).
It wasn't done this way so as to preserve backwards compatibility. It's actually a relatively small subset of Required Expressions that would require this option. So the question becomes, why do it if it isn't needed?
Because the "Required Expression" ALWAYS must be correct and must not rely on EVENTS. Because it does heavily depend on EVENTS it must be always re-evaluated at start-up in order not to miss an EVENT occurred while hub was down.
Yes, this aready was discussed.
I really can’t speak to how others are using required expression, but for me it’s always between two times and almost always beginning at sunrise or beginning at sunset. Therefore, I always will want to enable that option because it’s more common to have power outages in the middle of the night where I live now.
I feel it’s just good UX to have an option offered to a user, default to staying functional in situations that are common (i.e. power outage). Especially if there’s no hit to performance.
It’s somewhat on me because I was part of the beta and didn’t comment on that option. Not sure what was going on at the time in my life, maybe that was when we were moving. Not sure. Anyway, it’s something that I didn’t realize I would’ve preferred to always be enabled by default when it was still in beta, and so I didn’t offer the feedback I’m now offering.
A simple $25 battery backup is a better solution for power outages. The one I have will power a hub for 20+ hours. DB corruption is the risk that is mitigated.
Also, Conditional Triggers can replace many time based Required Expressions.
Choice is good. This topic has been beaten to death a number of times. Pointless …
I have invested in an 800w UPS, but it doesn’t last that long. I need it for other IoT equipment, not just my Hubitat hubs. Typically our power outages are short, but when they last more than a few hours, it’s not big enough.
I’ll just ensure that I turn that option ON going forward when I use required expressions.
Thanks Robert!
