Reactor build 26221

SECURITY! - BARE-METAL USERS: It is always recommended that you update package dependencies whenever installing Reactor updates. After unpacking the Reactor archive, go into the reactor directory (where app.js lives) and run npm run deps to update package dependencies. This is particularly important to address security updates for many packages.

• DynamicGroupController: Fix an issue where a filter_expression-controlled group would miss an attribute update.
• Engine/Reactions: The log level for the result of Group and While action predicates (i.e. the conditions) has been raised to INFO (4) from DEBUG0 (5). This may help users more easily identify logic bugs in their actions without the need to change the Engine log level (the Engine is dauntingly verbose even at DEBUG0 level).
• HassController: Bless HA to 2026.7.4

Yes, I found this as well. I have a fix that I've been running/testing, not yet into a build. I will get it done before the end of the weekend.

Yes!

Question on your feature request... generally, a capability has to be defined on an entity to assign an attribute within that capability. A Group is a subclass of Entity that normally has a limited set of capabilities and attributes that don't vary from group to group (i.e. the sys_group capability is pretty much it).

I can see adding attributes to a Group two ways:

1. Like with actions, the capabilities the Group allows follows the superset of capabilities of the Group's members, so the group would inherit those capabilities and you would be allowed to set attributes (via expressions in config) for them, or...
2. In config, you set what capability you want to assign and set attributes for, and then supply the logic (expression) to drive the attribute. In this scenario, the only additional capabilities that are assigned to the Group are those you explicitly name in config.

Thoughts?

@therealdb said in DynamicGroupController and attributes:

I think the correct code snippet is d = false,

The grammar allows semicolon (;) to end a subexpression, so in that context, the two should be interchangeable.

@therealdb said in DynamicGroupController and attributes:

But this is limited to the primary attribute, while I want to have any of the attributes in the group to be driven by a similar logic

I understand. Nice. I will look at this in greater depth over the weekend.

OK. EnvisalinkController won't be of much help there, since Honeywell is all I have to test with (and therefore all it currently supports). If at some point you think you may want to try it, let me know.

Gotta love AI... this thread sent me digging on the unsolved problem, and I just decided to ask Grok why I'm getting arming CIDs but not disarms... on my panel, opening reports are off by default. Thirty seconds in programming mode to enable opening reports and there they are! So now, I have parity... correct user IDs when arming and disarming (using EnvisalinkController).

Maybe check your panel configuration and ensure both arming (closing) and disarming (opening) reports are enabled?

I've written an EnvisalinkController for Reactor that I use, rather than HA's integration, but result is somewhat consistent in that it's unexpected/inconsistent (I'm on an Ademco/Honeywell panel). For me, arming produces the right user ID in a partition CID event and email from EyezOn. But alas, state isn't consistent with EVL3/4, and there does not seem to be a corresponding disarm CID event, and the overall keypad message/status event (which must be used to detect disarming) doesn't seem to report the user slot that disarmed the alarm (nor do I get an email from EyezOn that the alarm was disarmed, which given no CID event, makes sense). A bit different from your results, but frustrating nonetheless.

It's all good! Many, many, many has been the time where an extra pair of eyes helped me. That's why I'm thrilled to have my son working on this project with me now. I'm glad it was something easy (no patch and build needed). Onward!!!

@gwp1 OK, so just to be clear on what I think I see, when the lights are ON as the log shows (so that the rule Master Bath Lights is SET aka true in Rule State conditions), and based on the other rule states as shown in the groups you posted above...

This reaction group is true:

And this reaction group is also true at the same time:

That seems like your problem. Shouldn't that circled OR be an AND? Because in that interior group, any one of those conditions being true (the Primary Defer Controller condition specifically) will make the interior group true, and therefore the parent OR group true.

In Default/Open - No Deferral, did you mean to have an "OR" in the second interior group? That looks a bit suspicious.

Reactor tries to be conservative about state when you edit a rule. That's to avoid whipping devices around every time you hit "Save". If you've been editing a rule and it stops behaving consistent with its intent, try the Reset Rule button first... it will wipe the entire state of the rule and force a full re-evaluation. Faster and less dramatic than restarting Reactor entirely.

The first thing to do here is to look for a conflict, and when I look at your log entries, what stands out is 00:06:15 where something before the start of the snippet is causing the lights to be turned on. As you've shown the state of the reaction groups, that would make the Privacy Close and Privacy tilt groups both true at the same time.

Reactions are run asynchronously from the rule evaluation. The rule evaluation does not capture and "lock in" all of the states of things involved in the reactions. The reactions can change the state of things as they run, and those changes may affect how later conditional reaction groups are interpreted — the evaluation of reaction group conditions happens at the moment they are encountered in execution. If it's your view that everything is frozen in time at the moment the Rule evaluation starts, that's incorrect.

in matches the listed (comma-separated) words exactly. partlycloudy should not match cloudy by itself. My testing bears this out. You are not showing the actual condition state, which would be preferable here (i.e. open the Rule's detail view in the Rules list). If you've been editing the rule, you may need to reset it to flush old state.

Reactor build 26214

ALL USERS: This build is strictly to address a problem for bare-metal installs only running on nodejs v22.0 through v22.11. Use node -v to show your version, or look at the startup messages in reactor.log. If your nodejs is v22.12.0 or higher, or you are running a docker image, you do not need to update to this build.

• Workaround for module load problem in nodejs versions from 22.0 through 22.11.

Only a bare-metal package is distributed for this build. The latest docker images are still build 26193.

I was able to find a workaround, so build 26214, which will be posted shortly for bare-metal only, should address the issue without any changes to your system (other than the Reactor package).

Did you update packages?

Edit: nodejs 22.2.0 is the problem. You should update nodejs to the latest LTS, or at least to nodejs v22.12.0. There is also a quicker workaround that may work: add --experimental-require-module to the nodejs command line that starts Reactor.

OK. I think I found it. Patched and respun the 26193 build, so pull that again and let's see if it behaves better.

Did you check the log files? Whenever something isn't working right, that should be the first place you look.

Thanks for the inspiration!

Reactor build 26193

BARE-METAL USERS: nodejs v24.17 had a regression/injection that breaks HTTP connections, which has broad negative effect in Reactor. This version specifically is excluded from support, and users on that version are advised to upgrade to v24.18 (or higher).

BREAKING CHANGE: I'm guessing this will affect very few people, maybe none: the include_attributes selector for DynamicGroupController now requires that all listed attributes match when tested against an entity. Previously, if any listed attribute matched, the entity would be added to group eligibility. This forced users to use a filter expression if all attributes had to be matched together, which carries a greater performance impact and has other side-effects. The old behavior can be obtained by separating each attribute under its own include_attributes selector individually.

• DynamicGroupController: the include_attributes selector now requires all listed attributes to match, rather than any of the listed attributes, for the entity to be selected. See note above.
• A new lexp-cli.js utility in the tools subdirectory allows users to experiment with lexp expressions outside of Reactor. This tool doesn't have Reactor context, so functions like getEntity() and isRuleSet() are not available; nor are Reactor's global variables. It is strictly an environment to help with familiarization.
• Reaction Editor: when editing the Set or Reset reaction of a Rule, the Copy From... button will now list the contra-reaction at the top of the list, making it easier to find and copy the reaction within the current Rule.
• UI: The condition and action editors now support a right-click context menu on conditions and actions. The menu provides copy-paste of individual conditions and actions. Other menu actions are added where they make sense. Thank @therealdb for this power-user feature!
• UI: On dialogs, the Enter key will not perform any action if a modal dialog contains two or more buttons (i.e. where the meaning of Enter is ambiguous).
• nodejs version 26 is now explicitly supported, with v26.4.0 being the current version used for development (testing still occurs on v22 and v24).
• HassController: Bless HA to 2026.7.2