[RESOLVED] Phantom device, “INFO” appears

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