[Reactor] Variables not updating correctly in latest-25201-2aa18550

[therealdb]

Ok, I got a bunch of errors at restart because of failed references in almost all variables - now it seems to be OK and variables are updated. I'm observing a couple of rules I haven't migrate yet - and, at this point, I'll not migrate - where I used to old trick that @gwp1 surfaced (and that I used without making it a rule). always seems to be OK.

[therealdb]

yep, it seems to be related (in general) to variables not being evaluated at startup. Here's a screenshot from a daily rule that it's setting a couple of things, including a virtual binary sensor for Christmas from a local variable:

After re-setting the rule, the expression got re-evaluated and the error went away. @toggledbits

EDIT. a similar one + logs

This one, instead, every time is evaluated gives the error.

[latest-25248]2025-09-11T07:19:37.602Z <Rule:ERR> Lights-Christmas-Off (rule-kwv6wdpw in Lights-Outdoor): error evaluating expression specialdays: [Error] Object does not exist [-]
[latest-25248]2025-09-11T07:19:37.603Z <Rule:ERR> Full expression: t = time(), m = dateparts(t).month, d = dateparts(t).day,
(m == 12 && d == 24) ||
(m == 12 && d == 25) ||
(m == 12 && d == 31) ||
(m == 1 && d == 1) ||
(m == 1 && d == 5) ||
(m == 1 && d == 6)
[latest-25248]2025-09-11T07:19:37.604Z <Rule:CRIT> Error: Object does not exist [-]
Error: Object does not exist
    at GlobalExpression.getInstance (/opt/reactor/server/lib/GlobalExpression.js:160:27)
    at _0x1ec9e7._func.<computed> [as _ref] (/opt/reactor/server/lib/Rule.js:848:69)
    at _resolve (/opt/reactor/common/lexp.js:1385:27)
    at _run (/opt/reactor/common/lexp.js:1429:31)
    at /opt/reactor/common/lexp.js:1697:33
    at Array.forEach (<anonymous>)
    at _run (/opt/reactor/common/lexp.js:1696:28)
    at _run (/opt/reactor/common/lexp.js:1604:33)
    at _run (/opt/reactor/common/lexp.js:1438:34)
    at /opt/reactor/common/lexp.js:1425:29
[latest-25248]2025-09-11T07:19:37.627Z <Rule:INFO> Lights-Christmas-Off (rule-kwv6wdpw in Lights-Outdoor) evaluated; rule state transition from NULL to RESET!
[latest-25248]2025-09-11T07:19:37.638Z <Rule:INFO> Lights-Christmas-Off (rule-kwv6wdpw in Lights-Outdoor) started

[toggledbits]

New build latest-25254 posted. This should address the local variable in rule-based expressions at startup issue. Docker 64-bit platforms only.

[toggledbits]

@therealdb said in [Reactor] Variables not updating correctly in latest-25201-2aa18550:

[latest-25248]2025-09-11T07:19:37.603Z Rule:ERR Full expression: t = time(), m = dateparts(t).month, d = dateparts(t).day,
(m == 12 && d == 24) ||
(m == 12 && d == 25) ||
(m == 12 && d == 31) ||
(m == 1 && d == 1) ||
(m == 1 && d == 5) ||
(m == 1 && d == 6)

Just a tip, a more efficient way to write this:

parts = dateparts(), m=parts.month, d=parts.day,
    (m == 12 && d == 24) ||
    (m == 12 && d == 25) ||
    (m == 12 && d == 31) ||
    (m == 1 && d == 1) ||
    (m == 1 && d == 5) ||
    (m == 1 && d == 6)

The default time for dateparts() is the current time, so you don't need d, and by saving dateparts() to parts, the function is only invoked once. We old-timers love to save every cycle we squeeze out of the processor!

[therealdb]

@toggledbits said in [Reactor] Variables not updating correctly in latest-25201-2aa18550:

Just a tip, a more efficient way to write this:

OMG, very old rules, isn't it? Thanks, I fixed it.

[toggledbits]

@therealdb said in [Reactor] Variables not updating correctly in latest-25201-2aa18550:

OMG, very old rules, isn't it? Thanks, I fixed it.

This particular effort has made me look at rules that I haven't touched since the earliest days as well, many of them almost untouched copies from the Vera importer. It's a trip down memory lane, for sure, and a follow-on "wow, there's such a better way to do that now".

How's the latest working out so far? @tunnus have you had a chance to play with it as well?

[therealdb]

So far, so good. Everything seems to be OK atm. I'll report in case of problems.

[toggledbits]

OK. More testing done. I've hit a condition where the dependency scan in the last build still isn't hitting absolutely everything. Another build coming soon...

[toggledbits]

New build 25260. Also included fixes and enhancements for the expression editor.

Again, this build is intended only for the limited audience of this thread to test this specific issue. While the build at this point has had considerable testing, it's still not quite ready for consumption by all (but will be soon, if this goes well).

[3rdStng]

I don't know if my issue is related or not here. It seems like it should, but I also understand that local expression handling has changed within the last couple of builds. I don't know exactly when my issue started, nor what build I was on. My guess would be Sept 7th as my rule was last "SET" on that date.

I am running latest-25254-f6a45e41 in a docker on unRAID. The following rule has been in place for years and has been working pretty reliably, until recently.

The Set Reaction is just to turn on the shower exhaust fan. I collapsed it for screenshot space.
If I change the Local Expressions to: (and in this order)

MBath_HumityRise = "CurrentHumidity - MBath_prevHumidity"
MBath_prevHumidity = "CurrentHumidity"
CurrentHumidity = (some # value like 48)

And then manually change the CurrentHumidity value to 54 (something >=3), the rule triggers. The MBath_HumidityRise value changes to 6 too. Setting the CurrentHumidity to 50, changes the HumidityRise value to -4.

When I set these expressions back to pull from the device, I see the prevHumidity value change, but the HumidityRise value always stays 0. I set up global expression under different names and watched the values too. In the same order with the Rise expression above the Prev expression, I never see the Rise value change.

I will see if I have 25260 available for my docker update and test that, but for the life of me I cannot figure out why this rule stopped working.