[Reactor] Variables not updating correctly in latest-25201-2aa18550
-
Yep, I confirm I had to update a couple of rules where I had similar variables as @tunnus
I used script action because it’s multi line and definitely better in terms of readability.--
On a mission to automate everything. -
@tunnus said in [Reactor] Variables not updating correctly in latest-25201-2aa18550:
I was wondering if this could happen in cases where re-evaluation is queued but somehow gets stuck, and because new requests are ignored, updates won't occur?
Well, they won't get stuck, but there is no guaranteed order to the re-evaluation. Other things waiting to execute can run before the re-evaluation happens, including things that could change the global variables or entity attributes on which the first Rule depends.
Here's something to try (it's the @therealdb solution he mentioned):
- Make
msgan expressionless local variable. - Before your notification, use a Set Variable or Script Action to compute the value of
msgthat you want to send in the notification.
Would look something like this:
...or this, using a Script Action...
I personally prefer the Script Action because you can set several variables at once in the script, if that's what you need, and the syntax looks cleaner (you don't have to use the
${{ }}substitution.@toggledbits ok, I'll have to try script action. Still, as @therealdb stated, I'm also sure the "old style" used to work with pre-252xx builds.
Using MSR on Docker (Synology NAS), having InfluxDB, Grafana & Home Assistant, Hubitat C-8, Zigbee2MQTT
- Make
-
@toggledbits ok, I'll have to try script action. Still, as @therealdb stated, I'm also sure the "old style" used to work with pre-252xx builds.
Some strange results happened while I was experimenting with script action. I noticed that the order of local variables had an effect whether those variables did update or not.
If I had e.g. the following order:
"peak_power" did not update. But if I switched places of "ok_to_reset" and "peak_power", "peak_power" started to update in real-time:
-
Post your script. Based on the instructions given, your local variables should be expressionless, so that seems wrong and I want to see what your script is trying to do.
I can tell you right now, if
ok_to_resetis expressionless and you are resetting it in the Script Action script, and expectingpeak_powerto see the updated value, it won't work.Author of Multi-system Reactor and Reactor, DelayLight, Switchboard, and about a dozen other plugins that run on Vera and openLuup.
-
Post your script. Based on the instructions given, your local variables should be expressionless, so that seems wrong and I want to see what your script is trying to do.
I can tell you right now, if
ok_to_resetis expressionless and you are resetting it in the Script Action script, and expectingpeak_powerto see the updated value, it won't work.@toggledbits that wasn’t what I was trying to convey here. Let’s forget script action for a moment as it has no relevance for my finding.
What I’m trying to say here is that by merely changing the order of variables (and to be clear, that setup has worked before), my rules are working again. Somehow new builds do not like if expressionless variables are in the middle of regular ones. If they are last in line, all is well. Sounds crazy, but please test.
-
I'll say again, local variables are not processed/evaluated in the same way as global variables. Local variables are only evaluated when the Rule to which they belong is being evaluated (i.e. its triggers are being checked). They are not evaluated when a dependent local variable is changed. When the Rule is evaluated, its local variables, if any, are evaluated before the triggers, and yes, they are evaluated in the order in which they are defined. That is known.
Combine this with using a Set Variable action... if you don't check the "Force re-evaluation" checkbox, any other local variables that use the variable being set will not be updated until the Rule is next evaluated. If you check the box, it forces a Rule evaluation, and it is the second evaluation that will update the dependent variables.
The Script Action is absolutely relevant in your case, at least from what you've posted, because you apparently still had local variables that are dependent on the local variable that the script was changing, and that was not consistent with my recommendation. The script will not cause the dependent variables to be updated, because there is no "Force re-evaluation" option for the script, and local variables are not dependency-scanned/triggered, as I said above. That means your script action will change the local variable
ok_to_reset, but that won't makepeak_powerchange immediately after. That is why I recommended that you make all local variables expressionless when using the Script Action, and do all of the work in the script, none of the work in the local variables' expressions.None of this is new. And again, no changes have been made to how variables (global or local) in any of these recent builds. The earlier changes you mentioned to make
isRuleSet()andisRuleEnabled()trigger with the rules they reference (build 25082 -- a long time ago) was a change to the implementation of those functions themselves , but was not in any way a change to the mechanism that handles changes in global expressions.Author of Multi-system Reactor and Reactor, DelayLight, Switchboard, and about a dozen other plugins that run on Vera and openLuup.
-
I'll say again, local variables are not processed/evaluated in the same way as global variables. Local variables are only evaluated when the Rule to which they belong is being evaluated (i.e. its triggers are being checked). They are not evaluated when a dependent local variable is changed. When the Rule is evaluated, its local variables, if any, are evaluated before the triggers, and yes, they are evaluated in the order in which they are defined. That is known.
Combine this with using a Set Variable action... if you don't check the "Force re-evaluation" checkbox, any other local variables that use the variable being set will not be updated until the Rule is next evaluated. If you check the box, it forces a Rule evaluation, and it is the second evaluation that will update the dependent variables.
The Script Action is absolutely relevant in your case, at least from what you've posted, because you apparently still had local variables that are dependent on the local variable that the script was changing, and that was not consistent with my recommendation. The script will not cause the dependent variables to be updated, because there is no "Force re-evaluation" option for the script, and local variables are not dependency-scanned/triggered, as I said above. That means your script action will change the local variable
ok_to_reset, but that won't makepeak_powerchange immediately after. That is why I recommended that you make all local variables expressionless when using the Script Action, and do all of the work in the script, none of the work in the local variables' expressions.None of this is new. And again, no changes have been made to how variables (global or local) in any of these recent builds. The earlier changes you mentioned to make
isRuleSet()andisRuleEnabled()trigger with the rules they reference (build 25082 -- a long time ago) was a change to the implementation of those functions themselves , but was not in any way a change to the mechanism that handles changes in global expressions.@toggledbits I’m not using script action currently, and those screenshots were from a rule that uses set variable action.
But could you test my finding? Even rule triggers are not relevant when reproducing this finding. Just put a variable referencing an entity which frequently changes as a first one. Then make expressionless variable second, and as a third one make some kind of expression which uses first variable and does some calculation with it. Observe what happens and then swap second and third line and again watch what happens.
-
I'll say again, local variables are not processed/evaluated in the same way as global variables. Local variables are only evaluated when the Rule to which they belong is being evaluated (i.e. its triggers are being checked). They are not evaluated when a dependent local variable is changed. When the Rule is evaluated, its local variables, if any, are evaluated before the triggers, and yes, they are evaluated in the order in which they are defined. That is known.
Combine this with using a Set Variable action... if you don't check the "Force re-evaluation" checkbox, any other local variables that use the variable being set will not be updated until the Rule is next evaluated. If you check the box, it forces a Rule evaluation, and it is the second evaluation that will update the dependent variables.
The Script Action is absolutely relevant in your case, at least from what you've posted, because you apparently still had local variables that are dependent on the local variable that the script was changing, and that was not consistent with my recommendation. The script will not cause the dependent variables to be updated, because there is no "Force re-evaluation" option for the script, and local variables are not dependency-scanned/triggered, as I said above. That means your script action will change the local variable
ok_to_reset, but that won't makepeak_powerchange immediately after. That is why I recommended that you make all local variables expressionless when using the Script Action, and do all of the work in the script, none of the work in the local variables' expressions.None of this is new. And again, no changes have been made to how variables (global or local) in any of these recent builds. The earlier changes you mentioned to make
isRuleSet()andisRuleEnabled()trigger with the rules they reference (build 25082 -- a long time ago) was a change to the implementation of those functions themselves , but was not in any way a change to the mechanism that handles changes in global expressions.@toggledbits have you had time to look at this? I suspect there’s a bug in evaluating local variables when expressionless variables are not last items in the list
-
It works as I would predict.
-
Yep, I confirm I had to update a couple of rules where I had similar variables as @tunnus
I used script action because it’s multi line and definitely better in terms of readability.@therealdb could you test this if you could get your original rules (variables) to work just by rearranging local expressions? My hypothesis being that expressionless variables should be last in the list
