Is there any guarantee that all integrations are loaded at the time when “homeassistant.start” event is sent?
I started observing that in automations triggered by “homeassistant.start” some integrations may not be ready.
For instance:
Perhaps there’s a difference between an integration being set up and all its entities being available.
For example, the ping integration is probably quick to set up, but ping entities (if automatic polling is disabled) will only be available upon the next update (this is hypothetical, because the last value probably gets restored). Same for REST and MQTT sensors, probably.
Assume polling is not switched off by a user.
An entity will be updated when it will be updated from a phys. device or a server.
So, some entity may not be updated right after HA start.
Shouldn’t this entity have a prev value?
Many entities are restored at startup, but there are exceptions, one being trigger-based sensors. I cannot speak for this specific integration though.
Even with automatic polling on, the updating of sensors can still be async (in fact, I think the dev docs actually state that it must be the case in order not to block HA’s startup) or background tasks that complete after the integration has been set up.
Means:
In automations with “homeassistant.start” I have to check an entity for it’s existence; if some entity does not exist - wait for it’s update (with some timeout interval)…
Thanks for explanations, Pieter.
Although, smth definitely was changed in Traccar in this part.
Ah, thanks for the correction. Which one is the exception then? Or was it the case and then it got changed/fixed not too long ago? Maybe that’s what I’m thinking of.
It did get added later, but only a version or so after triggered template sensors were introduced. Template buttons, images, numbers and selects are not restored.