I may be missing the point of this and can't really find much info on it since it was added. Wouldn't the system automatically do this? WHen the hub starts up it would look at day, time, booleans, etc to see what was available to run? Is there another purpose to this? I haven't been checking it but I'm wondering if I'm missing out on something I should be using.
No it wouldn't - I thought the same and mentioned it another post (that post led to Bruce adding it to RM). A Required Expression becomes True or goes False as the result of an Event. So if the Event that causes the Required Expression to change occurs while the hub is down, it would appear to be evaluated incorrectly when the hub is back up. An example of this might be if you had a rule that used Sunset and you happened to reboot the hub just before that Sunset time and the Sunset time occurred while it was down. This switch checks the required expression when the hub comes up (in the same way it does when you create or initialise the rule)
3 Likes
As @johnwill1 said, there is a thread where this came to be that might be worth reading.
Obviously, the hub is not going to react to triggers that occur while the hub is down. But a required expression is not a trigger, it is a condition. And conditions should be correctly evaluated in real time. The problem is that under the covers, required expression becomes true as a result of a trigger. That's an implementation detail, though, and shouldn't change the behavior that a condition is real time.
The solution is to evaluate the required expression at system startup, and that's what Bruce gave us. I appreciate that. But having a toggle there for it makes no sense to me. Under what scenario would you NOT want a required expression to work correctly?
1 Like
IIRC, Bruce said having it enabled on a lot of rules may potentially be a drag on system resources upon system startup, but I may be totally misremembering that..
I used to use a lot of required expressions, but I moved back to plain conditionals in many of my rules -- I only have ~12 rules with Reqd Expressions now, so I did enable that toggle for those... Hopefully, that amount doesn't cause undue startup stress (I haven't noticed any ill effects so far).
That makes sense @johnwill1 . Thanks for the example. I was having trouble visualizing it but that makes sense. It wouldn't evaluate until the next event when the hub was up and running, so next sunset.
@HAL9000 I tried to search, but missed the thread leading up to implementing the new option. I'll look for it based on user posts. That would probably be good to see the development of it. I completely agree on appreciating the addition...the more options the better! I was kind of wondering the same thing though...why would you not want it to to evaluate it on startup. Maybe it's what @hydro311 mentioned about system lag on startup. If there are a few that aren't that important or seasonal, it will be evaluated at some point before the next trigger so it doesn't need to check on every reboot/startup. But yeah, I was wondering if I was missing something on why you wouldn't want it do work as programmed.
Thanks for the input! I appreciate everyone pitching in to help us learn!!
I'm where you used to be I guess. 
I use a lot of required expressions and have actually been wondering if I should go a different route. In theory, I would prefer the rules not even trigger if they don't need to rather than trigger and stop with a conditional. But I also don't want system lag. I looked at my list and was thinking I had too many a few days ago.
The other thread is Required Expression false .. but it isn't
No, I opined in that thread that this could potentially be the case, but Bruce replied that almost nothing happens at startup .. a big yawn. He didn't exactly say evaluating required expression conditions would or wouldn't be a performance concern. Maybe it is. But since it is just iterating through rules that have required expressions and looking at device and variable states (i.e., not having to poll devices or anything like that), it wouldn't seem like it would be a significant hit. I stipulate that I'm speculating. I don't know.
2 Likes
I hear ya... But in the grand scheme of things, I suspect it's all pretty darn close to a wash either way.
More than anything, I think I just got tired of seeing so much "Reqd Expression False" things in my RM listing lol... I'd rather reserve that easy-at-a-glance red print for rules I have stopped or paused.
2 Likes
Under the scenario that none of the Required Expressions need to be evaluated at System Start, and there being no point in doing that at start up. None of mine require this. Why would I want to run a bunch of pointless condition evaluations at startup?
I just happen to believe that doing something pointless is worth not doing. It has nothing to do with "excessive load" or anything like that. I do believe that most Required Expressions don't need this to happen. Restarting a hub is an isolated event, and only a Required Expression that might have changed during the reboot cycle is implicated by this.
Now, if you think every Required Expression should be evaluated on every hub startup, go for it.
1 Like
Same issue during upgrades which is a restart but only longer.
First let me say that the solution you provided is sufficient for my needs. I didn't raise the issue again but did speak my point of view of it was to aid in understanding, which was the question that started this thread.
Required expressions are conditions and conditions ought to be correctly evaluated. The power outage scenario and to a lesser extent, the reboot scenario, are edge cases, yes, but they are not rare, and ones that are trivially accounted for. Would none of your required expressions be affected if there was an extended power outage (4-6 hours) during which time the sun set, people arrived at home, doors changed states, etc.?
Nothing is pointless if it removes a reasonable, albeit infrequent, point of failure. Yes, you've given us a switch to toggle to cover for this scenario, but in my mind, the toggle switch is pointless.
1 Like
So what would you suggest... there is no solution.
The switch only address one issue but is a step in the right direction.in my opinion.
What about all devices after an outage? Especially an extended outage? They all can and would be out of sync with reality and not all even report correct state with a refresh and for a large network doing refresh of everything is untenable.
Its the nature of the beast! My recommendation get your hub on an ups at least
My expectations as to the state of things after a long outage certainly would not be that everything would work right away just perfectly. Even without Required Expressions, a reboot during the timeout period for a motion lighting instance will leave the lights on after the reboot, with nothing that will turn them off magically. Many timers could be disrupted. These sorts of things are to be expected. This is why we put the timing of updates (and reboots) in your hands.
I don't have an expectation that the hub could ever respond perfectly to every situation where its communications are disrupted, or its power is disrupted, or it is restarted (or even that it will work perfectly at all, given that a hub is a computer running software with sophisticated dynamic networks of devices). Adding that toggle to Required Expression, is relatively speaking, a drop in the bucket. I see only incremental value to it, and negative value if you think it means everything is hunky dory after a power outage. I tend to shy away from features that would create a false sense of security about the state of the hub. This is why, for example, we won't touch "device health" with a ten foot pole.
4 Likes
I came across this thread while trying to figure out why some of my paused apps containing required expressions weren't evaluating properly once resumed (when the required condition had changed during the paused state). It turns out that if the required condition for an app is changed during the time the app is paused, and the app is then resumed by the user opening the app and clicking on "Resume," the required condition will be evaluated properly at that time and the resumed app will operate as expected. If the app is resumed instead by an action in another rule (using "Pause/Resume Rules" in Rule Machine), then the required condition will not be evaluated properly, and the app will then operate based on the status of the required condition at the time the app was paused. I consider this to be a flaw.
The only methods I can determine to get these rule-resumed apps to properly evaluate their required expressions for the current conditions are to either manually open the app and click "Update Rule" or "Done," or to "toggle" at least one of the test parameters of the required expression off of its current state and then back.
@bravenel, if there are instances where a user would require that an active app specifically not have its required expression stay correctly evaluated, I can't think of any. If there were such a situation, it seems that the app could simply be paused. I myself would prefer the certainty that these required expressions stay correctly evaluated at all times rather than continue to find situations by surprise where they aren't.
1 Like
I will look into this.
This will be fixed in the next release. BTW, the failure here cut both ways. The Required Expression becoming false while paused wasn't caught either when resumed. Both are actually the same problem, fixed by a single line of code.
2 Likes
