Global Moderators group | Smart Home

toggledbits

It looks like the entity ID changed on the HA side. That, or something else in your world is now named "Nordpool", and it's finding that one first. Go to the Entities list and (name) filter for /^nordpool$/i. If it finds more than one entity, you'll need to change the name of one of them.

CatmanV2

Perfect! Thanks (again)

C

toggledbits

On the system entity for each controller is sys_system.state. For HassController, that will be true when HA is connected and inventory has been completed. It will go false when HassController is stopped (i.e. during a Reactor restart), or if the connection to your HA instance is lost and not restored after 3 reconnection retries (about 15 seconds, which is less than HA requires for restart in most real-world systems), or if authentication fails.

CatmanV2

Thanks again for the recent release. One thing I wanted to ask about integrations and their 'loaded' condition:

Is there something similar that applies to the entire controller? So if I have (for example) a helper in HA that is used to trigger an automation in MSR, is it possible to effectively exclude it until MSR is 'happy' that HA is stable and its values can be trusted?

This, actually goes back to the issue I had. I've got a use case where a 30 second delay from triggering is a bit of a PITA (sustained for...) and was just wondering if there's a way of knowing that 'native' HA functions are working correctly.

Probably asking wrong, or it's hideously obvious, but...

TIA

C

CatmanV2

Thanks, installed and working.

Although after the first restart there were some virtual switches in HA that were not being accurately reflected in MSR, but I restarted MSR again, and everything looks fine.

Thanks again for your help. Next time I'll upload the logs to start with!

C

toggledbits

This is just a follow-up to link this conversation to the announcement for the build that addresses it, and expands generally on transient startup/outage states in HA integrations

CatmanV2

You are an absolute gent, sir

C

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:

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.

CatmanV2

Fabulous!

I've actually just put reset delays in the two rules that are triggered. The 'set' is heating on so it's the reset that's a PITA. That should cover it.

C

toggledbits

OK. I can't prevent HA from starting up in an undefined state, and the effect that can have on the rules, but @therealdb is spot-on with an approach to dealing with that, since the corrected state usually comes pretty quickly after. Sometimes, you just have to debounce those switches a little.

Beyond that, there is definitely an opportunity for a race condition and I think I have a good general fix for that. The logs support that cause as well. Testing my updates now. Will likely do a build with the update tomorrow.

Global Moderators

Posts

Reactor build 26140

General Advisory

Member List