[C8] Variable not triggering rule machine

After upgrading to 2.4.0.148, a variable equalling a certain value is no longer triggering my rule. If I downgrade to 2.3.9.199 it works as expected.

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

1 Like

Is this a hub variable or a local variable? Have you hit "Done" (or "Update Rule") since creating this trigger?

It's a hub variable. Yes I've hit update and done. Still doesn't trigger when the variable becomes 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. :person_shrugging: But odd that it works in 2.3.9 then.

You're right, I removed that required expression and now it works. Definitely strange that it worked in the previous version totally fine.

1 Like

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).

1 Like

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?

1 Like

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

There might be a regression. I still have a hub on 2.3.9:

While on 2.4.0.147:

Not sure why there are two events for the variable changing to 2.

The rule is the same in both cases:

"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.

1 Like

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 does not. The trigger will happen exactly once and then not again, because the required expression will be false thereafter.

4 Likes

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.

Ok, well sorry it doesn't seem to work that way.

Proof:

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.

2 Likes

This is what I demonstrated myself aboveā€¦

  • It works for device attributes
  • It was working for hub variables in 2.3.9
  • It seems to be broken in 2.4.0

Actually, I'd argue, if anything it seems to be fixed in 2.4.0.

A mathematical operator being improperly interpreted by RE is a problem. This is the proper behavior exhibited in 2.4.0

Nothing is being misinterpreted

You are confusing truth with order of operations. Youā€™ve decided the required expression should be reevaluated first when the event occurs.

1 Like

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.

Interpreting a trigger of 2 as valid when the requirement for the trigger is to be less than 2 IS a misinterpretation. End of story.

The current implementation is proper.
<2 EXCLUDES the number 2

Having a requirement that specifically excludes the value being watched will prevent the actions from happening.

This makes perfect sense. To do anything otherwise breaks logic.