[MSR] Copy&past of actions and/or drag&drop between set/reset

[toggledbits]

Reactor build 25310

IMPORTANT: This build was patched and re-released to address a compatibility issue for Home Assistant 2025.11. If you pulled this release before 1pm Eastern Standard Time (18:00 UTC) on Friday Nov 7, please re-pull/re-install this build to get those fixes.

• Expressions: restore ability (lost in 25304) to define a custom function in a global variable/expression and have it be available to other expressions.
• HassController: Bless HA to 2025.11.0

[toggledbits]

Reactor build 25315

NOTE FOR HOME ASSISTANT USERS: Versions of Home Assistant prior to 2025.01 are no longer supported as of this build. They may continue to work, but no effort will be expended to maintain compatibility going forward.

• Rules: New Script condition -- write an expression (simple or complex/compound) that returns a boolean (true/false) or null, just like any other condition. The alarm() function works in it, too! And it holds more secrets... see docs WARNING: This is a "bleeding edge" new feature; it may be subject to breaking changes as it evolves into final form.
• Expressions: Add new print() function to assist troubleshooting of complex expressions.
• HassController: Support for new HA selector/data type in input_datetime entities and other similar.
• HassController: Versions of Home Assistant older than 2025.01 are no longer supported, as support for a number of (their) deprecated features and functions is about to end.
• HassController: Bless HA to 2025.11.1

[CatmanV2]

@toggledbits that looks like a massive leap!

C

[toggledbits]

Reactor build 25321

• alarm() function: has been redefined to return a boolean; true will be returned when the configured interval has completed; false in all other cases. The function previously returned the number of milliseconds remaining in the interval (less useful).
• Fix an issue where modifying a global expression that contains an alarm() call may not reset the timer.
• HassController: Bless HA to 2025.11.2

[toggledbits]

Reactor build 25323

• Rule-based Variables: correct an error handling dependency evaluation of subscoped variables.
• SystemController: prevent spurious exception that could be thrown while shutting down Reactor. It had no effect, but it's preventable and I like my logs error-free.

[toggledbits]

Reactor build 25325

• Rules/Expressions: fix an additional evaluation case from @Crille
• UI: silence an error that could occur during restarts (the shutdown process could stimulate the Set Rules status widget to fire queries at the inoperative host that eventually time out).
• HassController: Bless HA to 2025.11.3

[toggledbits]

Reactor build 25238

• Rules/Date-Time: Fix a regression (in 25315) where a Date-Time between condition that crosses midnight may determine incorrect state if the Rule is reloaded (e.g. by editing it or a Reactor restart) in the period after midnight but before the end time.
• Restarts on Win32 systems can now (finally) do a gradual, organized reload or shutdown.
• HassController: Bless HA to 2025.11.3

This is a "silent" release (it is not advertised in the Status page of Reactor)

[toggledbits]

Reaction build 26011

USERS OF AARCH64-tagged DOCKER IMAGES: Per this earlier post, this build will likely be the last with the aarch64 tag. Please follow the post's guidance for changing to one of the newer tags appropriate for your hardware and OS (32-bit armv7l or 64-bit arm64).

• Reactions UI: Fix update of display after copy in-place.
• Don't store reaction history entries for sub-reactions
• VirtualEntityController: better consistency in time-series configuration; update documentation.
• Fix an error in date display of time range conditions within certain parameters.
• HassController: Bless HA to 2026.1.0

This is a "silent" release (it is not advertised in the Status page of Reactor).

[toggledbits]

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

[toggledbits]

Reactor build 26127

If you are upgrading to this build from 26011 or earlier, please read the cautions for build 26116!

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

[toggledbits]

Reactor build 26130

If you are upgrading to this build from 26011 or earlier, please read the cautions for build 26116!

• 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

[toggledbits]

Reactor buld 26137

If you are upgrading to this build from 26011 or earlier, please read the cautions for build 26116!

• Rules: fix an error where a Variable Value condition in a constraint may not be reevaluated correctly when the variable changes.
• Rules UI: if a Rule State condition uses the changes operator with terminal values, make sure those are shown on the detail card.
• Rule Editor: when a new local variable/expression is added to the rule currently being edited, make sure all expression selectors in any Variable Value conditions shown are updated so that the new variable can be selected immediately (a bug was causing some to be missed).
• HassController: Bless HA to 2026.5.2

[toggledbits]

Reactor build 26140

If you are upgrading to this build from 26011 or earlier, please read the cautions for build 26116!

• HassController: Address a race condition that can occur when a large number of devices is initialized at the same time that HA is starting up (i.e. during the connect/reconnect and entity inventory phase while HA is still starting integrations). The race condition could cause a state change for an integration's entity to be missed during inventory. This is particular to integrations that set their device/entity states to null or "unavailable* during startup rather than preserving the last known state and only changing it after initialization succeeds or fails.
• HubitatController: Add since property to x_hubitat_pushable and family for improved button press detection.
• HassController: Bless HA to 2026.5.3

General Advisory

Users of HassController (and some other controllers as well, like OWMController for weather) often rely on cloud-based/Internet-dependent integrations to drive entities. There is no documented standard for how an HA integration should behave at startup, before it connects and authenticates with its mother ship; nor is there a standard for when it loses its connection to the mother ship and has to reconnect. Some integrations will preserve the last-known state of their entities for a while during these (re)connections, and some don't. It's kind of up to us as consumers of these integrations to figure this out and adjust our Rules accordingly.

While the fix in this build can address the issue of missing a state change during a lengthy initialization, it doesn't address how rules might behave in the face of these state transitions when they occur. If, for example, you write a condition "John is home" that tests the John presence entity attribute for the value "home", the transition to "unavailable" during integration startup could easily cause your logic to perform its "not home" behaviors. There are a couple of ways you can hedge against these spurious/transient states:

1. If the attribute value exposes "unavailable" as a state, test for it. I do this a lot. For example, a not-home test may be written as an AND group with value <> "home" AND value <> "unavailable" or perhaps more simply value NOT IN home,unavailable, rather than testing for equality to the sole value not_home. Again, whether or not "unavailable" is produced as a state and at what time/under what conditions is integration-dependent, so you will need to experiment. See further comments about integration states below.
2. Use the delay reset or sustained for condition option delays to dampen response to state changes. In this case, your rule would delay for some acceptable period before running its reaction... value == "not_home" sustained for 60 seconds is likely in most cases to be sufficient to allow the integration to get up and running and provide a "real" state rather than locking your wife in a dark house with no heat running and an armed alarm system (low WAF). Be careful, however; this doesn't address how the integration behaves during sustained outages of your Internet connection or their cloud services. Sometimes adding additional checks that the integration is healthy is necessary.

Recent versions of Reactor have introduced entities for integrations. For example:

The top highlighted line shows the state of a particular integration. You can use these entities/attributes as another test of the validity of other attributes you need to test (e.g. when the integration state is other than "loaded", the values are not to be trusted/acted upon). The lower highlighted line is provided by the integration itself and provides another data point on overall health of the reported attributes.

And just so I've said it... you have to test your entire automation under some terrible conditions. Some day when everyone is out of the house, unplug your Internet router and watch how your automations behave. Chances are you'll find some interesting and not-so-obvious behaviors.

[CatmanV2]

You are an absolute gent, sir

C

[toggledbits]

Reactor build 26143

If you are upgrading to this build from 26011 or earlier, please read the cautions for build 26116!

• Reaction Editor: fix an issue where non-group actions could not be cloned.
• Docker images: add ping command to underlying minimal OS packages.
• HTTP Request Action: a bug in an underlying package dependency caused digest authentication to ignore a server's suggested/supported digest algorithm. A workaround has been put in place and tested successfully against servers requiring SHA-256 and SHA-512-256, in addition to the now disfavored MD5.
• HassController: Bless HA to 2026.5.4

[toggledbits]

Reactor build 26150

If you are upgrading to this build from 26011 or earlier, please read the cautions for build 26116!

• A new Router notification method is now available. This method allows a single notification action to send a message to multiple notification targets. Configurable routes allow the selection and filtering of messages for different destinations. See docs
• In support of the new Router notification method, configured Notifier profiles other than default are considered children of default. If a configuration value is not specified in such a profile, the value will be inherited from the default profile. This allows, for example, the default profile for SMTP to contain the host and authentication information, while additional profiles may contain only different recipient addresses — the additional profiles will use the default profile's host/auth info to connect to the same mail server, without the need to repeat that information in each profile. If an additional profile needs to connect to a different mail server, it may specify its own host and authentication parameters as before.
• DynamicGroupController: improve response to changes in groups using filter_expression in configuration;
• Expressions: fix an error in the runReaction() function that may cause it to crash on an attempted dereference through undefined.
• Make the system more resilient to startup failures caused by hard errors in configuration files. When a (syntactically) valid configuration file is successfully loaded, it is copied to a last-known-good shadow file in the config directory. If the YAML configuration is later edited and contains errors that would prevent it being loaded, Reactor will load the last-known-good configuration, log the error, and display an alert in the Current Alerts widget on the Status page. The alert will clear itself when the file is fixed and later successfully loaded. To be clear, "valid" in this context means parseable (syntactically correct YAML). It does not mean that the keys and values given in the configuration will do what you expect/want or contain values or structures that Reactor can't recognize.
• Fix a compatibility issue with node version 18. This version of node is only supported in the armv7l docker image (for 32-bit Raspberry Pis).
• A new backup script backup_reactor_gfs.sh has been added to the tools directory; this script uses the grandfather-father-son backup strategy. If run daily, it will keep 30 daily backups, monthly backups (i.e. the first daily backup of each month), and quarterly backups (i.e. the first monthly backup of each quarter). Command line options suppress the backups of the logs directory and/or the transient/temporary state data for smaller backup size.

[toggledbits]

Reactor build 26174

IF YOU ARE UPGRADING FROM A REACTOR BUILD EARLIER THAN 26116, PLEASE READ THE RELEASE NOTES FOR THAT BUILD. THERE WERE IMPORTANT CHANGES MADE ON THAT BUILD THAT MAY AFFECT HOW YOU BACK UP AND RESTORE REACTOR DATA.

NOTE TO DEVELOPERS: An upcoming build of Reactor will be published after code base conversion to ES modules. Current Reactor core modules are CommonJS (CJS). Many dependent packages are only getting new features in their ESM versions (i.e. the world is moving to ESMs), so Reactor must follow. Instructions for converting your Reactor Controller and Plugin subclasses are published in the Building Controllers page of the Reactor documentation (under Developer Info). If you send me a DM in this community, I can send you an early release of ESM Reactor for your development and testing. This 26174 build is still CJS-based, so your conversion applies only to that future Reactor release and beyond.

• Entities list: fix a bug in entity filtering where a group filter would be ignored when an entity's name matched the name filter (both should be enforced).
• Hubitat: Fixed a problem where a scene controller button would report tapped at every Reactor startup.
• HTTP API: A new endpoint /api/v1/notify has been added so that external applications can use Reactor's configured notifiers to send messages. docs
• VirtualEntityController: New ping-driven binary sensor reflects the (ICMP) reachability of a target network host. see docs
• VirtualEntityController: Virtual entities may now be added to system room/location groups by including room: <string> in the virtual entity configuration.
• HassController: Bless HA to 2026.6.4

[toggledbits]

Reactor build 26177

• Notify via Telegram: fix application of default chat_id when not specified on individual notification action.
• Hubitat: fix an error in handling data POST from MakerAPI (affects house modes, HSM)

[toggledbits]

Nodejs v24.17 Not Compatible

Users on bare-metal installs... a security fix in nodejs v24.17 inadvertently broke a dependency of Reactor. This version of nodejs is therefore not compatible with Reactor. If you are using it, please upgrade to v24.18.

[toggledbits]

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