Homeassistant.start and readiness of integrations

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:

alias: test_traccar
description: ""
trigger:
  - platform: homeassistant
    event: start
condition: []
action:
  - service: persistent_notification.create
    metadata: {}
    data:
      message: >-
        {{ states('device_tracker.iphone_5s_traccar') }}
mode: single

gives “unavailable” - although the entity seems to be OK when I check it right after HA startup.

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.

1 Like

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.

1 Like

Trigger based template sensors are restored at start up.

https://www.home-assistant.io/integrations/template/#trigger-based-template-binary-sensors-buttons-images-numbers-selects-and-sensors

1 Like

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.

1 Like