New update entities not triggering automations when state changes during core startup

Hi all,

I have a few automations with triggers based on the new Update Entities, one of them being this popular blueprint (link) and the rest manually created. They work well most of the times but I have noticed a couple of times that I have pending updates yet those automation were not triggered and after a little bit of troubleshooting I realized that this is happening when there is a new update available but before the automated update check happens I restart Core for some other unrelated reason (HACS integration update, etc.).

I suspect the issue is likely with the startup order where the check for updates happens (and the new update entities state changed) before the automations are loaded or something like that?

I though about opening an issue but before that wanted to confirm here if this is maybe a configuration issue on my side or anyone else has noticed it? I am on 2022.5.5.

Yes this is true. It’s not really an issue, its by design. See here:
https://github.com/home-assistant/core/blob/ffbec553d194f13bec8310e0ff47036d49688c00/homeassistant/components/automation/\_\_init\_\_.py#L564-L566

Automations enable themselves after HA says it is started. Which occurs after all integrations have been loaded. Everything that listens for state change event does this, you can find essentially identical code in the template integration for example.

So I wouldn’t submit an issue for this, it will be rejected. Nothing is supposed to listen for state change events during start up because then you get really strange events. Plus everything is asynchronous so it would be totally random which integrations loaded before you and which loaded after and you’d miss all the ones that happened to load before.

As the author of this blueprint though, I can do something about this if it is important to you. First of all I should point out, are you listing all your update entities in the update_entities input of that blueprint? As the description of that input says:

List of update entities to watch for updates on and be notified as soon as one is available.

The blueprint is only actually listening for state change events for update entities specifically listed in this input. For all others it only checks them for updates every few hours (whatever you set reminder_hours to). There’s whole back and forth in that thread where I tried to actually listen for state change events on all update entities without the user having to list them out and gave up because its impossible. And also because users of the blueprint haven’t seemed to mind that it basically just checks on a schedule.

I could add a trigger for “HA startup” if this really bugs you. But just wanted to make sure you’re aware even after startup that blueprint is generally not watching for state changes in your update entities. It’s only watching for state changes in the update entities you manually list out in the update_entities input.

1 Like

Hi Mike!

First of all, thanks for the Blueprint! very useful. and thanks for confirming the issue.

Yes, I have my desired update entities listed as per the blueprint instructions, I don’t think this is something you should fix though and this is why:

I understand automations only loading after core has started, by design. And I agree submitting an issue about that will get rejected (I would if I was a core developer) BUT, I would think triggering notifications and automations was one of the main drivers on developing these new update entities and this not working on such a common use case kind of makes them unreliable and in my opinion a bit useless… I would think the issue is with the fact that the first update check happens before automations are loaded, a simple delay on this process would fix that and I think this would be something developers would me more open to accept as an issue, like, do not check for updates until automations are loaded… do you agree?

Ok I see what you mean. Sure you could try that. Although just an FYI you’d need to submit several issues. Core doesn’t control what integrations do while loading, it just tells them to load. Integrations create entities and take any actions they feel they need to take while loading, including (it would seem) checking for updates before adding their update entities to the state machine.

So you’d actually be creating an issue for the supervisor integration. And (if you use it) the hacs integration. Also you might have to keep submitting issues as other integrations you use add support for update entities in case they check for updates during load and don’t add a delayed trigger to do it after start up.

1 Like

Thanks, I opened an issue with supervisor (link), lets see how that goes and go from there…