Let's say I had a system variable WXfreezing (boolean) or any number of such variables which need to offer daily state information to be checked by/in rules.
In this case WXfreezing would be set to TRUE on the trigger of any one of three temperature sensors going sub 32F (and maybe staying there some duration) at least once in the 24 hour day and FALSE if temps stayed above 32F. (I recognize the switching of this state needs some reasonable logic beyond what I've outlined but never mind that.)
The intent would be to note that freezing weather is persisting and that certain environment rules should or should not trigger throughout the day. So those rules would either have a condition to look at the state of WXfreezing or wouldn't even fire by virtue of a Required Expression keeping watch on WXfreezing.
I guess I'm wondering about best practices here.
Would you create multiple System Variable management rules one for each variable that fire up upon startup and stay running in a loop with WAITs for temp sensor changes to change the variable and then loops back or would you create a rule that is managed by a Required Expression that watches the state of multiple temp sensors, etc.
Or maybe make one rule that manages all the System Variables you might want to make current and available ? Haven't thought through how complex/confusing this might end up being but the idea of consolidating this for maintenance and reboot/startup execution seemed enticing.
Just throwing this out for some brainstorming among those that have worked through some of this already. Thanks in advance.
If you have very separate concepts being captured in different Hub Variables, or at least they are recorded in response to largely separate conditions or devices, then I would keep the management of the hub variables separate. This can help in reducing the complexity when maintaining any rules required to keep them up to date.
I think you would approach these in the same way you would any other rule, look to have them triggered by a state change event, or one of many possible events, and utilise the required expressions and other trigger features to keep the noise down. At a high level I don't think you need to introduce any loops within your actions, just the "waits" implied by the trigger definitions. Some situations may require waiting for addition events after one has occurred, or at least a period of time, and even though I believe these can be defined more elegantly in the triggers, I expect underneath the effect is likely the same, it just makes the rule writing easier.
I think you could have separate rules that include the logic for maintaining each variable throughout the day, but then include potentially a single rule to reset each of them on say a mode change or time-based schedule, whatever makes the most sense. The resets are relatively simple and easy to update, including adding or removing variables. Mixing together the updates to the variables can introduce a whole range of complexity, depending on what they are. If it is that some need to be kept in lock-step, then that would certainly be a case to maintain then within the same rule.
While not completely relatable, the best example from my setup would be Virtual Switches I have for each room to reflect whether motion lighting is in effect or not. I have various rules or button controller instances that change this throughout the day, but then when I transition to Night mode, I have these all reset in a single rule triggered by the change to Night mode.
I might have slightly misread your intention with the question(s) in your post... I see you are also asking about the choice of using Hub Variables versus including the logic in your rules to detect freezing weather conditions.
If the logic required for this is something you need in multiple rules, or it is or becomes quite complex, then in either of those cases I can see benefit in introducing a Hub Variable, if only to keep the definition of the rules that rely on it easier to follow. A single "is it freezing" check of a variable reads a lot better than a long list of logic at the top of what could be a relatively simple rule. I expect the re-use case is not something I need to explain...
Some things will lend themselves to be interrupt-driver, others will have to be polled.
Interrupt-driven example may be freezing temperature with a full degree change in temperature being the trigger to set the boolean variable true or false.
Polled example would be like my computing run time of the crawl space humidifier by checking once a minute to see if it is running or not. If running add one to count, which is reset at midnight after logging the day to a spreadsheet. [I have a group of scheduled tasks, such as every minute, every 10 minutes, every hour, and every night at 11:59 PM.]
Thanks for the things/approaches to think about guys.
The intent WAS to avoid repeating the logic down in every rule it could be used.... and thus allow for ONE place to orchestrate the decision logic, e.g. I might eventually try to look at this as a "multi-day hard freeze then it's TRUE thing" vs a "if it's still going below freezing even briefly at night then it's TRUE". Hate to have to change that in every rule needing it.
The polling vs interrupt and how to/if to bundle this stuff in one System Variables Management Rule was the root of my wondering. So appreciate it, will digest your insights before proceeding.
I'm curious why you would set a separate boolean variable for something like freezing temperature. What would be the benefit of having the temperature sensors change the variable and checking the variable over just checking the sensors, since you'd be looking for a static number (32°F) in every case anyway? "If sensors A, B or C < 32 and remain for X time period..." Unless there's some other need for the variable, wouldn't it just overcomplicate things?
OK, I'll state one case and then ponder your comment to see if I'm over complicating things.
Let's say I have a very simple "once daily" rule to "top something off with water"
....and that in all but for the most persistently cold days (meaning sub-freezing for some hours)
....this functions just fine happening at a fixed hour and fixed duration of time every afternoon
....and that common, but brief, dips to or below freezing don't necessitate interrupting this cycle
....but serious cold (usually pre-dawn) does impact the need and success of the daily water top up.
So my thought is - did it get below my set point, did it stay there long, and is it OK to keep this rule (and any other rules like it that are freeze dependent or sensitive) doing their designed actions.
EDIT: Clarifying - the temperature sensors MAY NOT be showing sub-freezing when it comes around to the respective rule's action time....but that overnight hard freeze IS STILL material to whether or not the rule should affect the action normally desired.
Mind you the approach would be totally different if we were talking about prolong-ly frozen Minnesota here.
The rule trigger is a set time shortly after the trigger ran previously. The first action is to wait 24 hours minus however long it takes to execute the entire rule. The second, third, etc actions run whatever you're actually trying to automate.
A different rule checks the temperature of your sensors. Any time one of them dips below 32 for X amount of time, then it cancels the first rule which would have already have started but still be in the wait period.
Then the first rule would start again at the appointed time the next day.
Again, I'm just thinking out loud here just to throw out other ideas. I'm not sure if that would necessarily work for you in this instance.
Funny how you can start out over thinking something.
This boiled down to a daily check of the pre-dawn temps of three sensors (when the temps are invariably the lowest) and just setting the state of the variable dependent on that polling.
