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

[gwp1]

@toggledbits whoops... guess this is one time having the system auto-update containers with new images is bad....

So I'm on the test version. Found this:

This is a Dynamic Group I'd created forever ago:

My ruleset:

I added the snippet as noted into my logging.yaml file:

When it didn't work I checked my yaml and found a spacing issue. That's been corrected, I now have a proper logger* log. Will upload to our pre-x Dropbox in folder 25248 logs along with the rule JSON file.

[toggledbits]

Is there a global variable called dead (it's not shown above)?

Or are you looking for the word dead in status_text? Because if it's that, your expression is incorrectly formed.

[gwp1]

@toggledbits kicker is: this has been working for a long while. Dead iblind nodes (far too common, btw) get caught and pinged and I get the alerts on my phone.

I don't see a Global Expression called dead and, yes, I believe when I wrote this I was looking for either a status of 3 or status_text of dead.

[toggledbits]

OK. Yes, the new build also has some new error reporting. That message was probably being logged, but since you weren't looking at the logs, you didn't see it.

You can also combine those into one status test, which will be a good bit more efficient:

- id: groups
  enabled: true
  implementation: DynamicGroupController
  name: Dynamic Group Controller
  config:
    groups:
      zwavejs_dead:
        select:
          - include_group: zwavejs
        filter_expression: <
          entity?.attributes?.zwave_device?.status === 3 ||
          entity?.attributes?.zwave_device?.status_text === "dead"

Also, please... Please... PLEASE do not screen shot pure text. Use the fenced code block formatting here for text like expressions, configs, logs, etc. It may be expeditious for you to just paste the screen shot, but when I try to give you suggestions or corrections like the above, I have to retype the entire block (I can't copy-paste the text and update it). That not only takes a bunch of time, but also introduces the possibility that I will make a typo in the part we don't care about and leave you with a non-working example we then need to fix in yet another series of post replies.

Don't forget to remove the Rule logging when it isn't needed.

[gwp1]

@toggledbits now I'm feeling hypocritical as I'm the guy at work chastising the Support folks for giving me screenshots for the exact reasons you noted.

Change deployed.

Got this upon restart of MSR:

    at _ClientAPI._commandTimeout (http://192.168.1.100:8111/client/ClientAPI.js:594:125)

Cleared it and refreshed the tab and all seems fine. Removing logging snippet.

Thank you, sir!

[therealdb]

@toggledbits I've updated my main system. I'll observe and report back. Thanks

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