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