Possible mismatch between binary_sensor in HA and MSR

[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

• 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

• 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

• 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

• 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