Questions on required expressions, conditional triggers, etc (offshot of: Variable not triggering RM)

[a.mcdear]

@bertabcd1234

This would capture the specific transition from 1 (or 0 or whatever) to 2, rather than any value to 2 as it would without the expression. This is not that different from the modes example above and is another illustration of how this feature can be used to capture specific state transitions.

I think I get it. What you're saying is:

Required expression: variable <2
Trigger: variable = 2

Will fire anytime the variable was <2 and then becomes 2.

Ok, I think I finally get it. I am trying to use RE as a trigger condition, when the proper tool would be to use a conditional trigger.

[aaiyar]

@vitaliy_kh

I wonder how difficult it will be to do the same trick for the Required Expression?

Difficulty or ease aside, it will break a lot of existing rules designed on the basis of the current documentation (which you admit to not having read).

So I hope @bravenel will take that into consideration while implementing any possible changes.

[bertabcd1234]

@a.mcdear

I think I get it. What you're saying is:

Required expression: variable <2
Trigger: variable = 2

Will fire anytime the variable was <2 and then becomes 2.

Ok, I think I finally get it. I am trying to use RE as a trigger condition, when the proper tool would be to use a conditional trigger.

Yep, that's it!

(If there is no relationship between the trigger events and events that would affect the required expression, you can use it that way, too; or you can use conditions in your rule actions, conditional triggers, or a variety of other means that may meet your needs too. This particular example is just one that is a nice illustration of the feature since, unlike many of those cases, it's harder to do any other way.)

[hubitrep]

@a.mcdear

use RE as a trigger condition, when the proper tool would be to use a conditional trigger.

The difference is one unsubscribes the events used by the triggers (RE) and the other doesn't (CT).

The specific case under discussion falls somewhere in between because in that case both trigger and RE depend on the same event.

@vitaliy_kh

I wonder how difficult it will be to do the same trick for the Required Expression?

Not desirable. See above.

[bravenel]

@vitaliy_kh

I wonder how difficult it will be to do the same trick for the Required Expression?

I don't know what you mean, what trick??? Required Expressions are completely separate from triggers, except in one special case (device or variable in both Required Expression and trigger).

[mattias]

Ok, I just ran a couple of tests on this. The first test was the example from the docs:
Required expression = Mode is day
Trigger = Mode becomes Evening

When mode changes from Day to Evening it runs the rule actions, just like the docs say

However, I used the same rule for the second test, but changed it to be:
Required expression =(hub) variable < 2
Trigger = variable is 2

When the variable changes from 1 to 2, the rule actions do not run. So, to me it looks like required expression isn’t consistent in when it prevents the rule from running and when it doesn’t.

Edit: To be even more like the mode example I changed the variable example to instead have:
required expression = variable = 1
But the outcome was the same. Rule actions were not run when variable changed from 1 to 2

[vitaliy_kh]

@bravenel

I don't know what you mean, what trick???

The simplest answer is : improved and more predictable timing.
@aaiyar @hubitrep
I don't see what could be wrong if the Required Expression is evaluated the same way as the Conditional Trigger does:
On the Trigger event the Required Expression is evaluated and if true the Actions are running. This is a behavior of a Conditional Trigger and it works very reliably (so far did not seen any failure). The slider "Evaluate the Required Expression on startup" could be retired because each Trigger will evaluate it and present very fresh up to time state of the Required Expression. What is wrong with this picture? Do you really want a Required Expression to present an incorrect state?

[a.mcdear]

@bertabcd1234

Yep, that's it!

I'm sorry. This seems so obvious now. I'm not sure what kind of brain fart I am having today.

[bravenel]

@vitaliy_kh

The simplest answer is : improved and more predictable timing.

The improved timing for Run Actions has nothing to do with anything in this topic.

@vitaliy_kh

I don't see what could be wrong if the Required Expression is evaluated the same way as the Conditional Trigger does:
On the Trigger event the Required Expression is evaluated and if true the Actions are running.

The Required Expression can have its state change independently of any triggers, and if that happens it is evaluated then, and the result stored in atomic state.

The reason the approach is what it is stems from a desire NOT to evaluate the Required Expression when there is no reason to (i.e., upon events that will not change its value), and to not waste CPU for triggers when Required Expression is false (removed triggers). The Required Expression evaluation result is stored in atomic state in the app. This value can be looked at in lieu of re-evaluating the required expression. Are you hypothesizing that the independent evaluation results in timing problem, where result of evaluation happens after the trigger event? If that is the case, there is no fix possible. Or are you contemplating some other timing problem?

[bravenel]

@vitaliy_kh

This obviously requires more processing power leading to longer uncontrolled delays.

This is a non-sequitur. Complexity of the platform is not leading to "longer uncontrolled delays". You provide no evidence to support this claim.

@vitaliy_kh

once in while this gets out of control.

Say what? That's a pretty wild accusation. Come on, how about sticking to facts?

@vitaliy_kh

I am absolutely not surprise to see more/increased timing related failures for whatever was working before with each platform and/or app update

Yeah, there was a bug that resulted in slow performance of certain actions (now fixed), but there are not other "timing related failures" that have been reported.

@vitaliy_kh

But also now I am 100% convinced to design new and/or modify existing RM Rules using State Machine design technique

Go for it.

[vitaliy_kh]

@bravenel

The improved timing for Run Actions has nothing to do with anything in this topic.

This is 100%+ true. I am talking about timing between evaluation of the Required Expression and Trigger events. The very good example is using a PB for preventing unwanted re-triggering. I had many cases when PB was set to FALSE as a very first ACTION but the Required Expression became FALSE near the end or even after the rule was executed. Because of that I stopped to use a PB for preventing unwanted multiple triggers.
If the RE is/was evaluated similarly to the CT this should work as expected.
Is not it?

@bravenel

The Required Expression can have its state change independently of any triggers, and if that happens it is evaluated then, and the result stored in atomic state.

@bravenel

The reason the approach is what it is stems from a desire NOT to evaluate the Required Expression when there is no reason to (i.e., upon events that will not change its value), and to not waste CPU for triggers when Required Expression is false (removed triggers).

These two statements above is kind of contradictive (the way I am reading them and trying to understand correctly).

[mattias]

@bravenel I’m confused (happens easily mind you). How is it that required expression doesn’t seem to consistently prevent or allow a rule to run when comparing results from rules using different kinds of events that, to me, should result in similar behaviour? See my post above for two examples, Questions on required expressions, conditional triggers, etc (offshot of: Variable not triggering RM) - #26 by mattias

[bravenel]

@vitaliy_kh

These two statements above is kind of contradictive (the way I am reading them and trying to understand correctly).

Requied Expressions are going to be evaluated whenever an event occurs that might change the evaluation. When RE becomes false, all trigger subscriptions go away (except overlap triggers), so for the duration of falseness, no CPU is spent on triggers. Meanwhile, if a trigger is completely unrelated to RE, why evaluate the RE upon the trigger? RE has a known state that is not timing dependent in that case.

So that leaves the overlap case. Is that what you are concerned about? Case where trigger and Required Expression use same device or variable?

[bravenel]

@mattias

How is it that required expression doesn’t seem to consistently prevent or allow a rule to run when comparing results from rules using different kinds of events that, to me, should result in similar behaviour?

I'm not sure what specifically you are referring to, but there is a bug in the released platform with respect to variables used in both Required Expression and as trigger. Your link goes to a discussion about what happens in that case, but that discussion isn't informed by the existence of the bug.

[mattias]

@bravenel

but that discussion isn't informed by the existence of the bug.

Ok. So it’s confirmed that there is a bug with how variables are used in that scenario then? So once the bug is resolved, the variable scenario should behave as the mode scenario? If so, I’m no longer confused

[bravenel]

@mattias

If so, I’m no longer confused

I'm glad that's the case for one of us....

[vitaliy_kh]

@bravenel

This is a non-sequitur. Complexity of the platform is not leading to "longer uncontrolled delays". You provide no evidence to support this claim.

Every extra added commands requires extra CPU time. Is not this obvious?

@bravenel

Say what? That's a pretty wild accusation. Come on, how about sticking to facts?

This is based on my long time experience with designing HW with embedded CPUs. The SW team is/was always optimistic they can do everything in SW but eventually screaming about adding HW support for time critical functions. Thanks to the FPGA technology usually this could be done without costly modification the the existing boards.

@bravenel

Yeah, there was a bug that resulted in slow performance of certain actions (now fixed), but there are not other "timing related failures" that have been reported.

I am glad, the bug was found fixed.
Based on my primary job experience when SW complexity is increased sooner or later it will be an impact on a system performance. And as usually SW will ask for more memory, faster processors and moving some functionality to the HW domain. It is what it is.

@bravenel

Go for it.

I am still using only the RM as my main Automation tool. But all my new rules as well as many existing are rewritten as a SMs. I was an idiot not to use SMs right away.

[bravenel]

@vitaliy_kh

Every extra added commands requires extra CPU time. Is not this obvious?

Of course, but you make a sweeping comment not based on facts. A larger software base does not mean a slower one necessarily. In fact, the hub platform has grown with every release, and yet many releases make it faster. Hmmm...

@vitaliy_kh

This is based on my long time experience with designing HW with embedded CPUs.

So, not based on Hubitat Elevation, but other systems. Come on, that's ridiculous ...

@vitaliy_kh

Based on my primary job experience when SW complexity is increased sooner or later it will be an impact on a system performance. And as usually SW will ask for more memory, faster processors and moving some functionality to the HW domain. It is what it is.

This is not about Hubitat. so why post it? Being long time EE doesn't excuse you from need to make correct and relevant posts. I suggest that you stop making sweeping accusations about the hub that are not supported by facts, logs, etc. Of course there are bugs found from time to time, and we fix them as soon as we can. But the hub is not going down some timing hole as you suggest.

[bravenel]

Every question raised in this topic has been addressed. So, time to move on....