When the KidsInBedVariable changes to 2, the rule does not run. Nothing in the logs other than the required expression changing to false due to the variable value becoming 2
The required expression requires the variable to be less than 2 in order to run. I would have thought that when the variable becomes 2 the required expression will stop the rule from triggering and, hence, the trigger will not fire. But odd that it works in 2.3.9 then.
This is not how it's supposed to work; a required expression of < 2 and a trigger of = 2 should capture the exact transition from 1 (or really anything less) to 2. Without this, it would also capture any transition to 2, e.g., from 3 to 2.
This is a common misunderstanding but is an intended use of required expressions, and capturing specific state transitions in a way similar to this is one of the reasons the feature was introduced in the first place. This would be consistent with the documented behavior (see the example with modes): Rule 5.1 | Hubitat Documentation
I'd be curious if this behavior was different in 2.3.9 or even earlier builds of 2.4.0.
If there is any chance the variable value changes relatively rapidly (say, within a few milliseconds to a few hundred), I could see that causing problems (on any platform version).
So in this example when the variable goes from 1 to 2, the trigger condition would be evaluated first and kick off the rule before the required expression condition is evaluated and then prevents the rule from evaluating any further trigger conditions (until the required expression is true again)?
I havenāt had any experience with how it handles this scenario when the required expression is already true and an event happens that both triggers the rule and changes the required expression to false.
However, I do believe I have had to work around the opposite scenario, where the required expression is false and an event happens that both turns the required expression to true and is used to trigger the rule. In that case I have observed that the required expression will turn to true but the event will not trigger the rule. It needs the trigger condition to happen again for the rule to trigger. Is that correct?
Edit: the documentation says:
ā If the required expression evaluates to false at the moment when a trigger event happens, the rule will not actually trigger ā and, in turn, the specified actions will not run.ā
When it says āevaluates to false at the moment when a trigger event happensā, does that mean that it uses the state before the trigger event occurred (which the mode example seems to indicate) which basically indicates that it checks the trigger condition against the required expression before it re-evaluates the required expression, or does it use the new state that the trigger event creates?
I don't think so. A required expression on <2 will not allow the trigger at the value of 2. Change the <2 to <or=2 as <2 will prevent the trigger from rule from running if the value is less than 2.0
"Evaluates" not "changes". We're looking at a specific situation where required expression and trigger are both subscribed to the same event, which is not the general case.
Works for device attributes, as has been demonstrated elsewhere.
The mathematical symbol "Less Than" or "<" literally means "less than". Therefore <2, means "less than 2", or all values less than 2, which excludes the value of 2.
The mathematical symbol "Less than or Equal to" or "<=" literally means "less than or equal to". Therefore <=2 means all values of 2 or less.
The required expression "variable A <2" will prevent a trigger of "Variable A = 2" from triggering. (or, it should if the logic is processed properly)
A required expression of "variable A <=2" includes the value of 2, so it would work fine for a tigger of "Variable A = 2".
So here's what I'm really saying.. Maybe Hubitat DOES treat < and <= as the same, but it shouldn't as they are two distinctly different things. If Hubitat treats them identically, I have never noticed it before.
@g.shepperd
I suppose depending on how the variable works, you could also do something like get rid of the required expression and make the trigger "When variable A in 1-2" which means "in range" and then the trigger will always fire when the value changes to 1 or 2 but no other values.
It doesn't seem to work the way you describe. The required expression of "Variable A <2" gets processed before the trigger. If the trigger is variable A=2, it will be false already when the value changes and the RE flags it as false.
This situation would be avoided by using the proper operator, in this case <= instead of <
I'm positive I have rules that require this to work this way so I'll find one so I can post the log output.
but then again, I read this and am confused:
It kinda sounds to me like this is saying "if RE becomes false when evaluated, it prevents the trigger" which is what I am positing, but then it goes on saying some other stuff I don't quite understand..
No. If the operator is <=, the required expression remains true when the value is 2. When the operator is <, the required expression becomes false when the value is 2 after any triggers that depend on the same event subscription. I think itās the last part of that sentence that can seem confusing.
I didn't even need that required expression there in the first place. I have a newborn so I'm basically a zombie... creating rules is something best left to those who sleep
Either way, it definitely ran on the previous version and doesn't anymore so something changed in 2.4.0 in regard to the required expression being evaluated before/after the rule runs.
The thing is - timing relationship between evaluation of the Required Expression and Trigger is not guaranteed. I.e. in general whichever evaluation will happens first is not deterministic but usually a bit asymmetrical. Another words, using the same condition in the Required Expression and Trigger better to be avoided.