That's great to hear! Sorry for the disruption! Onward!

@therealdb Yes!

@therealdb said in Rulesets with multiple groups in Set Reaction not working post-26116:

PS: is it safe to delete the json files in the folder?

Which folder?

Reactor build 26130

• Reactions and Reactions UI: fix a long-standing issue where imported/cloned Group and While actions were not given unique IDs by the UI. Until 26116, this bug lurked in the shadows because IDs on actions in Reactions didn't matter at all, so the duplication went unnoticed and was actually harmless. But changes in 26116 to improve predicate response and display made these IDs important for Rule-based Reactions. IDs tend to change when Rule-based Reactions are edited, but long-standing objects that aren't often touched could be left with duplicate IDs embedded. In 26116, this duplication would cause inconsistent and incorrect evaluation of group/while predicates (because two different predicates sharing the same ID would share the same status/result). This build fixes the situation in two ways. First, existing Rules are fixed by deep-scanning when loaded (i.e. at startup), and any conditions or actions having duplicate IDs are given new, unique IDs. Second, fixes have been made to the Reaction Editor to prevent duplication of IDs when an action is cloned or a Reaction is imported. The former fix should ensure that your existing rules are corrected with no further intervention on your part. The latter fix addresses the original editing (copy and import) bugs that gave rise to the problem in the first place. Note that IDs are only required to be unique within the context of a Rule or Reaction; they do not need to be globally unique. If you are the type of person who likes to "deep dive" your storage data and you happen to find duplicate IDs in different Rules/Reactions, that's OK; it's only a problem if an ID is used in duplicate within a single Rule or Reaction. If you get an alert in the Status page that rules were modified by the new startup scan, please delete the alert and restart Reactor. The alert should not return (i.e. the rule is fixed). If the alert returns across more than two restarts, let me know in the Smarthome Community.
• HassController: Bless HA to 2026.5.1

I dropped you a DM. Whatever folder you are uploading to has expired and I no longer have access to it.

That may be moot at this point, since info from @therealdb is likely leading to the same conclusion. I have a fix build coming soon that I'm at least 50% sure will address your problem as well as his.

OK. Please turn on log level 5 for that rule only. Run the rule to show the issue, and upload the entire Rule log file as well as reactor.log, the rule storage files (dval and json). Link for upload in your DMs

Build 26127 just posted has a small change that hit the issue responsible for the misbehavior. If not, there's additional logging that may help point me in the right direction.

At this point I would need to see the entire config file. You could also run it through yamllint.com to make sure it's all OK (and remember, no tabs -- always spaces for indenting -- that's a common trap with some editors that "help" you during copy/paste).

Build 26127 has a change that may be responsible for the misbehavior, as well as additional logging in case that's not the problem. Please upgrade to that when able and see how it behaves.

Reactor build 26127

• This is an interim build that has one small possible fix for the group evaluation problem reported by @gwp1 and @therealdb , as well as additional diagnostic logging in case that change doesn't resolve the issue. Other users not using or experiencing problems with Reaction groups do not need to update to this build.

Looks OK. Check your IDs if you are not getting logs. The files will be named Logger#Rule#<ruleid>.log.

Enable logging at level 5 just for that rule. Anything else is going to generate too much information/distraction.

Edit: I'm not finding any issues yet in focused testing on this. I obvious don't know what the dependent rules do in your conditions (what conditions they have), but basic functional tests of groups with true and false constraints are working fine for me.

Since you have delays in your groups (or can easily add them), that's one way to slow things down so you can watch the "Running Reactions" status widget, which also may give us a clue why it's not working the way you expect.

Again, if you're not posting 20 or more lines of logs around what you think is interesting, it's not enough. You're also not showing the conditions for this Rule (a Ruleset is a collection of Rules).

It's suspicious to me that you have both Set and Reset reactions here... do you remember contra-reactions? If the rule is Set, the Set reaction starts running. While it's running, if the rule Resets and the Reset reaction is not empty, the Set reaction will be stopped (pre-empted) before the Reset reaction is started. The same is true the other way... the Reset reaction can be pre-empted by the rule Setting while the Reset reaction is running.

This very much comes into play when the rule's conditions look at an entity that is also controlled by either reaction (i.e. condition to see if the light is off with a reaction that turns it on), and any condition that produces pulse output (i.e. by using pulse output in condition options, or using the changes operator in a condition). The former instantly changes the rule conditions and possibly the rule state. The latter (pulse) happens very fast when no reset delay is configured, and can easily pre-empt the Set reaction before it even has a chance to start.

OK. 26120 rebuilt with a UI fix and pushed. Update your container and let me know how it goes.

Ugh. So sorry. Working on it now.

@gwp1 Logs probably long gone if you've already modified the reaction. It would help to see the group in its original form, though.

@gwp1 unrelated.

OK. Here's the release note I'm making on this for the next build:

• The behavior of empty "group" conditions was changed in error. As of the next build, the behavior is as follows: group actions may have empty constraints (no conditions), and since this is not explicitly false, the group will be allowed to run; while actions may not have empty constraints (and this will be enforced by the UI/editor going forward), and if a legacy while action is encountered with no conditions, it will not execute (safe behavior). A disabled group or while action will not run.

Reactor build 26116

PLEASE READ ALL CAUTIONS AND INSTRUCTIONS BELOW!

IMPORTANT: PERSISTENT FORMAT STORAGE CHANGE! I STRONGLY RECOMMEND MAKING AN INTENTIONAL, SEPARATE BACKUP OF YOUR REACTOR STORAGE/DATA BEFORE UPGRADING TO THIS BUILD, AND SAVING IT SAFELY SOMEWHERE FOR A WHILE. The file format and name used to store Reactor system objects and data has changed as of this build. Data files under the storage directory now have a .dval suffix rather than .json. See this post for background. Conversion of your existing files to the new format is automatic and transparent on the first run of this and future builds, so your existing backups will be restorable into the foreseeable future. If you need to see the contents of a file in its native form, a new utility under tools has been provided: dval2json.js. You can run this utility (e.g. node tools/dval2json.js storage/expressions.dval) and it will read the .dval file and output its JSON representation, if possible. However, due to the limitations of standard JSON, some .dval files may not be convertible to JSON by this tool; if that happens, the tool will switch to an alternate output format that is JSON-like enough to be human-readable (but is not parseable as JSON).

BARE-METAL UPGRADE MUST UPDATE DEPENDENCIES! Those of you on bare-metal installs will need to run npm run deps in your Reactor install directory after unpacking the distribution archive. There are new and updated packages required to run this build of Reactor, and it will not start without these updates. Docker users don't need to do anything, as the image is built with all dependencies preloaded.

ERRORS WILL BE LOGGED ON THE FIRST RESTART AFTER UPGRADING TO THIS BUILD. ALLOW THE SYSTEM TO SETTLE A MINUTE, AND THEN RESTART AGAIN. THEN AND ONLY THEN SHOULD YOU BEGIN CHASING/REPORTING ANY ISSUES THAT REMAIN.

• DynamicGroupController now manages rooms across all standard controllers where room information is available from the source hub. Previously, each Controller had to manage rooms on its own (if that data was available from the hub/source), and the room groups were local to that controller. Now, the room information on Vera, Ezlo, Home Assistant (area), Hubitat, and Z-Wave JS (location) will be used to automatically generate shared groups owned by DynamicGroupController. Rooms are associated by name (case insensitive); for example, a "Living Room" room on a Vera and a "Living Room" area in Home Assistant will both use the "Living Room" group automatically created and managed by DynamaicGroupController. This behavior can be turned off on a per-controller basis by setting rooms_as_sys_groups: false in a controller's configuration. By default, this setting is true (on, system-level groups will be created) for all controllers. All standard controllers (Home Assistant, Hubitat, Vera, Ezlo, and Z-Wave JS) have been updated to use the new room group strategy. Refer to the documentation for each Controller for additional details.
• VeraController: Add configuration flag rooms_as_local_groups to enable VeraController's legacy behavior of creating local groups for Vera rooms. In support of the shared groups described above, this setting defaults to false as of this build. Existing local groups will be marked dead for eventual purging unless this setting is changed.
• Expressions: new runReaction() function can be used to launch a Reaction (see docs);
• Reactions UI: Additional fixes to coordination and placement for copy/move;
• Reactions: While actions now have an optional iteration limit — a maximum number of times the loop will run. If the loop hits this limit before its conditions stop it, the loop will stop without error;
• Reactions: While actions now have an enforced once-per-second minimum iteration delay (that is, if you omit a Delay action in the While group, Reactor will provide a one second delay);
• Reactions UI: The display of the While condition on the detail card has been improved;
• DynamicGroupController: new include_attribute selector (see docs);
• Rules: The rule detail display now updates the main constraints' evaluation values continuously. This restores UI functionality lost when fixing an earlier bug that caused unexpected/undesirable re-evaluation of a Rule's triggers when dependent entities or variables in constraints were modified;
• Controller Config: The type config key, previously deprecated, is no longer supported. Use implementation instead. Unless you've ignored prior deprecation warnings, this should not be an issue.
• Rules: The startup scan of rule conditions has been improved to correctly update old conditions using the changes operator with blank operands;
• HubitatController: The room of a device is now stored on the entity attributes.
• HassController: The area and floor properties of a device/entity are now stored on the Reactor entity's attributes.
• HassController: Better support for new "state" selector in service data as of 2026.4.0. The most notable effect is that, where HA offers us data, we will present a list of expected values for a field down to the device/entity level (because not every device may support every possible value for a field). This is not universal yet, but seems to be HA's direction, so as they publish the data on more entities, it should just start working in Reactor Editor fields.
• Entities List: Fix page overflow when attribute has a long value with no natural word breaks (i.e. force wrap).
• Entity: extended attribute values on standard capabilities will now survive refresh of the capability.
• Reaction Editor: Fix presentation issue with gutter in section header.
• Rule Editor: Fix presentation issues with gutters in section headers.
• Reaction Editor: After a data entry validation error, an error was not being cleared after the user fixed the entry.
• Dashboard: the sys_group.visible attribute has been added to control the selection of groups for automatic display on the Dashboard's default group list display (default: true);
• Many documentation tweaks and updates; supply some new/improved images.
• Docker images: Detection of improperly mounted data volume. This will help alert new users in particular to missing/misconfigured data volume binding.
• HassController: Bless HA to 2026.4.3

OK, everyone, it's almost time. Sorry for the long pause. Life takes over sometimes.

The aforementioned updates will be in the next build, and I am working on wrapping everything up to get that build out later this week.

Please make backups of your Reactor data as advised in the head post here. As I said then/there, I've been working with this for months now, with no issues, but my world is not your world or everyone else's world, so there's always the possibility I don't see or have an issue that you do.

Prior to releasing this new build in the latest channel, the 26011 build will become the stable channel head. In addition to your backups, that gives you a relatively quick path (especially docker users) to get back onto 26011 if there's a showstopper.

This build will also include unified room groups: DynamicGroupController will manage "rooms" (or areas or locations or whatever your hub calls them). If you have two different hubs with devices in the "Living Room," there will be one "Living Room" group with the combined set of devices. The per-controller room groups generated by VeraController and EzloController will be disabled by default, and existing room groups created by these controllers will be marked as dead entities (and eventually purged). If you already use DynamicGroupController to manually create your own room groups via configuration, you can either keep that (and disable DGC's new behavior, if you wish) or switch to DGC's version. An updated version of ZWaveJSController that supports this functionality will be released simultaneously with the core build.

OK. If it helps, I haven't had to make any compatiblity changes to HassController since HA 2026.1.0 up to 2026.4.0. They did change some service data information, but not in a way that's incompatible, rather, they improved the content of the data in a way that I have now modified both HassController and the UI to offer more guidance (suggested values) for parameters in some services. They are taking a new direction that I imagine provides better and more consistent support for themselves in Lovelace, and I'm following that path with them. So you can probably go to at least 2026.4 and, if you can tolerate Reactor warning you about it, may not have any issues, but again, I don't have every device/integration, so there's always something you may have that I don't and therefore don't see (but that's a risk whether I "bless" the HA release or not, and as you know, I try to react as quickly as possible when those things come up).

TL;DR You can probably upgrade HA to 2026.4 safely, just ignore Reactor's warnings. If there's any issue, let me know and I'll address it.