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

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

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

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.

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

I don't know if I'm the only one, but managing more than one Reactor installs, the need to have some sort of copy&paste for rules has grown on me.

While I understand the technical challenges, I'm wondering if a "god mode" where I could copy the raw JSON rule and paste it into another rule could be an advanced, flag only feature that could benefit power users.

I know I can copy the JSON file and proceed, but I must stop Reactor and when doing maintenance, it's more clicks to do.

Just an idea

Version 25244: https://github.com/dbochicchio/reactor-mqtt-contrib/releases/tag/25244

Add new Shelly Gen3 templates for dimmer and energy meter, modify version in manifest.yaml to 25244, enhance sensor expressions for accuracy, and improve event handling and actions. General refactoring and cleanup across YAML files for consistency and quality.

So, my solution, based on the logic, is this the following.

Cycle Logic (pseudo-blocks)

Trigger: Button press (scene controller state changes)

Variables:

• fan1 = getEntity("zwavejs>13-1").attributes.power_switch.state
• fan2 = getEntity("zwavejs>13-2").attributes.power_switch.state
• skip (default = false)
• lastTurnedOff (text)

Group 1 – Both OFF → Fan1 ON
Condition: skip == false AND fan1 == OFF AND fan2 == OFF AND lastTurnedOff <> "fan1"
Action:

• Turn Fan1 ON
• Set skip = true

Group 2 – Fan1 ON → Fan1 OFF
Condition: skip == false AND fan1 == ON
Action:

• Turn Fan1 OFF
• Set lastTurnedOff = "fan1"
• Set skip = true

Group 3 – Fan1 just OFF → Fan2 ON
Condition: skip == false AND fan2 == OFF AND lastTurnedOff == "fan1"
Action:

• Turn Fan2 ON
• Set skip = true

Group 4 – Fan2 ON → Fan2 OFF
Condition: skip == false AND fan2 == ON
Action:

• Turn Fan2 OFF
• Set lastTurnedOff = "fan2"
• Set skip = true

Notes

• The skip variable ensures only one group runs per button press.
• lastTurnedOff lets Reactor know which fan was just turned off by this rule (so it can toggle the other fan on next).

I'll make some other tests and see if it's working as expected. I used Chat GPT 5 giving the Reactor Docs as context and deep reasoning and it helped me a lot. I just had to explain my logic, provide a couple of screenshots and ask for logic blocks instead of script action. YMMV.

I’ve added a couple of Shelly Wave i4 as scene controllers and I’m planning to add more, since I can just use standard buttons instead of battery-powered scene controllers, which also looks better aesthetically.

That said, I’m struggling to figure out how to write a simple rule that cycles between states every time I press a button.
Example: Light 1 ON → OFF, then Light 2 ON → OFF.

The part I can’t get right is handling the case where Light 1 or Light 2 might already be ON independently of the rule.

Maybe it’s just too much sun and relaxation clouding my brain, but any hint would be appreciated.

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.

Ok, I was probably lucky in the past, I don't know. I could send you the rule's JSON if you want to take a look. Anyway, I'll try to move some logic into set variables for the time being. Thanks.

I'm 100% sure it used to work before. I did a restart and nothing changed.
I have "Force re-evaluation of expressions and conditions" in the rule and I was under the impression that was forcing updates. Now back to change a couple of rules that have the same problem. I'll move them to Script Action to set the values, but as I said I'm 100% sure it used to work OK before.
Thanks.

After updating to latest-25201-2aa18550, I found that an old rule (probably 2-3 years old) has started experiencing a weird behavior.
As you can see from this screenshot:

It seems that while rain variable is false and wind is true, debugmessage (and other similar variables) are not updated correctly. If I press on the Play Icon on the variable inside the rule, it is then updated. It was working OK previously, so maybe it's the new version.

As you can see from this screenshot, the first one is updated manually, but the second one is still showing the old value:

The rule has just some action in the SET part doing notifications and calling MQTT endpoints for logging.

Anyone with the same problem? /cc @toggledbits

Also, for me a virtual device instead of checking for rule states seems to be less prone to errors. So I have one for home status, guests, party etc and the rules are much easier to write.

I use script action a lot with arrays of devices defined in a variable. Very handy for when you want to do it without messing with config files.

Version 25154 on GitHub:

GitHub - dbochicchio/reactor-opensprinkler: OpenSprinkler controller for Reactor - Multi-Hub Automation

OpenSprinkler controller for Reactor - Multi-Hub Automation - dbochicchio/reactor-opensprinkler

No release, just download the code.

Fix for station status and support for MQTT capabilities in OS 2.2.1. Still based on both HTTP/MQTT because the underline fw is still not 100% MQTT-ready.

Just copy storage and config from your bare metal install, point the container paths to the disk and you're good to go. Very easy*.

• this excludes external controllers, but the relative installation is well documented.

I still run my primary network on UZB, but I've just bought an Aeotec ZStick 7 for a new house. I'll switch to that for my primary house before end of the year, mainly because I want to use ZWave LR for a couple of devices and I need a 700/800 series router.

All that said, I'm running inside ZWaveJS and it's working as expected. My system with Reactor is pretty solid. I think ZWave is still the tech to go. My experience with ZigBee is quite similar (I run everything: Zwave, Zigbee, MQTT, Matter).

I prefer a structure where I organize them by features. The name reflects the rule set they're in (ie Lights-Outdoor-Gate is in Lights-Outdoor) to simplify discoverability, until a global search is added

the clock problem is a know bug. update to latest.

Please be 100% extra sure to copy everything under storage. this includes any file/directory under the path. do it while bot reactors are stopped for better accuracy.