Yes at sunrise the next day it will be set again.
I have repro'ed this with logging on the rule enabled and nothing is logged when the required expression thinks it isn't met. Consider the following test rule.
I gracefully shut down the hub at 9:05 AM and restarted it at 9:15 AM. At several times from 9:20 - 9:25 AM the trigger motion became active but the action didn't fire. The name banner at the top of the rule says that Required Expression false, even though in the Define dialog it is currently evaluating as true.
So there's something we need to understand about when required expressions are evaluated. I would have assumed that all required expressions would be evaluated upon system start, but that seems not to be the case. To get the rule working again before 9:10 AM tomorrow, it was necessary to go into the rule and hit Done.
Side note: Obviously this could be avoided by moving the required expression into actions as a conditional, so that the conditional was be evaluated each time motion occurred. I'm just wanting to learn more about what one must be aware of when using Required Expression.
1 Like
A required expression like this schedules two events. Restarting the hub has nothing to do with these scheduled events, neither removing them or changing them.
It would be most helpful if you could show two things: The Scheduled Jobs from the bottom of the rule's App Status page (gear icon), and the logs for this app between 9:00 and 9:30. Be sure the Event and Trigger logging are on in the app.
1 Like
Here is the Scheduled Jobs and it shows as expected that a job will run at the start and end of the time window. As I indicated, there is nothing in the logs (even with all logging turned on in the rule) regarding this rule at the time it failed to trigger during that time window.
Again, I'm just trying to understand the limitations of the required expression. It appears to be the case that if the hub is down when the required expression becomes true, the rule won't trigger until the required expression becomes true while the hub is up.
That leads to the scenario where the rule thinks required expression is false, yet if evaluated at that time, it is true.
Of course! A rule can't run when the hub is down. So if during that period of time the Required Expression was to have changed state, it won't. And no, before you ask, there is no way the hub is going to look for things like this at startup to find 'missed' events that you wished had run.
Consider a similar case: The hub is down, a door opens. The hub comes back up. Is a rule with a contact opens trigger supposed to run then? The answer is, of course not! Events happen when they happen. The hub is event driven, not state driven. It is never examining its state to see what it might have missed.
A Condition involves the examination of state. States change due to events occurring. Every time a rule encounters a Condition it evaluates it by examining the state of its elements. A Required Expression is evaluated only when the state of one of its elements changes. When the Required Expression becomes false, the Event Subscriptions for the triggers are removed -- the rule won't trigger from any of these events. When the Required Expression becomes true, those Event Subscriptions are created, allowing the rule to be triggered again. The Required Expression is not evaluated when the rule is triggered.
This might be helpful: Introduction to Automation
1 Like
OK, I think it is obvious that triggers are event-driven, and rules won't run if their trigger happens when the hub is down.
Required Expression on the other hand is something I think many may (erroneously) consider as a matter of state. Now that you've explained that the required expression is dependent on events to turn them on and off, yeah .. understood. And I kinda realized that in comment #3 above. I was just looking for confirmation.
I don't think I'm alone in this impression because there are quite a few threads on this. In fact in one of them, you stated
... which is exactly the astonishment that prompted me to ask. Can it be that the top of the page shows Required Express false and the rule not eligible to run even if the required expression currently is true? Yes, that can happen and there's an explanation for it. So we're good with that, although I think I'll tend towards conditionals rather than required expressions for rules whose trigger doesn't fire frequently.
I accept that. But whatever happens when one opens a rule and hits Done essentially resets the evaluation of the required expression to its state without an event, does it not? For example, If "door is open" is the required expression and the door is open when you hit Done, then the rule meets the required expression, correct?
If that is correct, then if system start triggered "Done" for each rule that had a required expression, then the scenario would no longer exist. I am not asking that this be done .. I'm just trying to understand. I had previously assumed that lots of similar stuff (like subscribing to events for all triggers) does happen upon reboot.
3 Likes
Ya that's why i avoid the required expression and just put extra ifs in the rule (the old way). Seems more bullet proof to me albeit with more cpu cycles.
1 Like
Very little happens on reboot. With respect to apps in general, reboot is a big yawn.
In fact, the only thing you can rely on happening is a rule that has a trigger for system start:
Up to you. But there are many circumstances in which a Required Expression is the right way to do something, and there are automations that can't be done without it. For example, try to figure out how to trigger a rule when mode becomes Day after it was Away without using Required Expression.
2 Likes
agreed easier with reqired espression but can be done with std rule machine and a variable.
1 Like
Show the rule. Doesn't it take two rules?
yes thats not what i meant.. i just meant it could be done without required expression.
It's just discouraging to read a suggestion that an advanced feature should be avoided rather than understood and used as intended.
2 Likes
i do use it.. but mostly for things like time restrictions etc.. but as i have lots of rules written and not making lots of changes i leave those in place that work instead of rewritting and debugging using a new approach.. i still have more rule machine 4.x than 5.1. Just regarding the case where a required expression is not reevaluated at boot time was stating that if the expression was an if in the rule it bypeass that issue thats all.
any issue at boot is thorny at best.. i've had the same issue with std rules ie if a door opens or something comes on (and they stay that way) during the boot then some rules are and have bound to fail as the state change on given devices will be missed.. not really a way to avoid it becuase you cannot possibly go back through all devices.. at least critical devices like garage doors etc seem to internally poll periodically to avoid this issue.
1 Like
Hmmm .. I believe I was using the feature as intended and I had the moment of astonishment when it didn't work as expected. Knowing now more about under the covers, I plan to favor conditionals over required expression if the rule isn't that much more complicated, unless the frequency of state change of some condition was very infrequent.
For example, if I wanted a creaky sound made whenever motion was detected on the front porch but only on Halloween, I'd make Halloween a required expression so that the motion trigger wouldn't needlessly run a rule with a conditional "Is it Halloween?" when 364 days of the year that trigger isn't useful.
Back to furthering our understanding of behind the scenes, is it correct to say that upon creating a new rule with a required expression, or even hitting Done on such a rule, that the required expression state is evaluated at that time, and no event needs to occur to set it to true if the condition was true when the rule was created/hit Done. But state is otherwise not evaluated unless an event occurs.
3 Likes
Just thinking aloud….You could easily test that yourself by creating a rule without a required expression, running it, then edit and add a required expression for between two times that doesn’t include the current time. When you hit ‘done’, if it has evaluated the required expression, the rule would stop triggering.
If it did work that way, you could create a rule with actions to initialise your rules (where a required expression may be out of whack), triggered by system start.
Edit: Required Expression is evaluated at rule creation/initialisation, I just tried the above. On reflection, it's kind of obvious that it does I suppose, as otherwise when we created rules after sunset that have a 'between sunset and sunrise' required expression, we'd have to wait until the following day to see them start working 
1 Like
Yes, I have also tested in order to reach an understanding of how it works, I believe I do understand now (again, please correct me if I'm wrong), and if I were asked to explain to others I would say ..
The Required Expression (like a condition) is a state. The state is set in one of two ways:
-
An event occurs that potentially changes the state (e.g., a door opens would change the state of a door is open).
-
When you hit Done to initially install a rule or after editing the rule. No event is necessary in this case.
But the state is not evaluated upon system restart, so if an event occurs while the system is down, the state won't change until the next event occurs that could change the state.
3 Likes
You could make this happen with a single rule and a Hub Variable. Create a number Hub Variable, set to any positive value. Add a Condition to your Required Expression with AND for that variable > 0. Add that Condition to the Required Expression for any rule that you want to update the Required Expression state upon system startup.
Create a new rule whose Trigger is Location event: systemStart. Its actions should be to add 1 to the number variable.
What will happen is that upon system start, that variable will change, and the Required Expression will be evaluated. The new part of the Required Expression will always be true, but the value changing will cause an evaluation. So in case something was missed while the system was not running, it will be caught up.
5 Likes
That's quite a clever workaround.
When you have a minute Bruce, you could add that lot to your RM code, with an additional checkbox in the Required Expression area titled "Re-evaluate expression at system start" 
...Just kidding
2 Likes
That is a brilliant solution! I scratched my head for a minute trying to figure out why you wouldn't need to set the variable back to 0. Now I realize that the actual value of the variable is moot; it is the change of value that would cause the evaluation of the restriction.
OK, I think we've covered this topic sufficiently. Thanks for that. I would be remiss to not suggest that perhaps one day restrictions be evaluated when a rule is instantiated after system start (whatever the proper term for that would be). You've already seen that such is useful when a rule is created/edited, and making the required expression even more foolproof would be desirable. We've apparently both had moments when seeing "Required expression false" and its evaluation as TRUE was odd.
2 Likes
