Self-healing integration reload

Some integrations stay loaded and still go quiet: every entity they own flips to unavailable, and nothing in the logs says the config entry died. Restarting Home Assistant fixes it, which is a poor habit. This workflow watches one canary entity. If that entity sits in unavailable longer than a dwell you set, it calls homeassistant.reload_config_entry on the config entry that owns the canary, waits, and looks again. A phone notification goes out only if the reload did not bring the canary back. A retry counter and a cooldown stop the automation from reloading the same entry forever.

Entity ids are blueprint inputs. Do not publish a live integration dump.

This repairs. Offline devices report lists what is still down after an outage. Use the report for triage. Use this pack when one integration is known to wedge and a reload is the fix you already do by hand.

What problem it solves

You want a stuck integration to reload itself, you want silence when that reload works, and you want a single failure push — not a reload every minute — when it does not.

How it works

1. Canary — one entity whose availability tracks the integration. A forecast sensor for a weather integration, the main coordinator sensor, or any entity that goes unavailable together with the rest of that entry. Do not pick a battery device that sleeps; sleepy nodes look unavailable on purpose.
2. Dwell — the canary must stay unavailable for a duration (pack default two hours, shorter if the integration wedges in minutes). A brief Wi-Fi blip should not reload anything.
3. Guards before the reload — skip when the attempt counter is already at max_retries, or when now is still inside the cooldown that started at the last attempt. mode: single so a second trigger while a reload is in flight does nothing.
4. Reload — homeassistant.reload_config_entry targeted at the canary. Home Assistant reloads the config entry that provides that entity. Record the attempt time and increment the counter before the wait, so a restart mid-wait still counts.
5. Re-check — wait the re-check delay (pack default 60 seconds; some integrations need longer to republish). If the canary is no longer unavailable, reset the counter and do not notify.
6. Notify only on failure — if it is still unavailable, run the failure actions (one Companion push, optional persistent notification). The message says the reload ran and the canary is still down. It does not fire on the attempt itself.
7. Stop looping — at max_retries the automation refuses another reload until the canary leaves unavailable (a recovery trigger resets the counter). Cooldown (pack default 30 minutes) spaces the attempts that are still allowed. A reload that itself causes a short unavailable flicker cannot immediately schedule another reload.

The pack does not restart Home Assistant, and it does not reload every entry. One canary, one entry.

Hardware notes

• No new devices. This is a blueprint plus two helpers: a counter (attempts) and an input_datetime (last attempt).
• Notify. Companion, or any notify service, used only on the failure branch. Leave the failure actions empty if you want a silent reload and will read the counter on a dashboard instead.
• Canary choice. Prefer an entity that is unavailable exactly when the integration is wedged, and unknown or a real state when it is healthy. Template sensors that depend on that entity are a bad canary: they go unavailable for unrelated reasons.

Snippet

The pack ships a blueprint. Inputs replace real entity ids:

mode: single
max_exceeded: silent

trigger:
  - platform: state
    entity_id: !input canary_entity
    to: "unavailable"
    for: !input unavailable_for
    id: wedged
  - platform: state
    entity_id: !input canary_entity
    from: "unavailable"
    id: recovered

action:
  - choose:
      - conditions:
          - condition: trigger
            id: recovered
        sequence:
          - service: counter.reset
            target:
              entity_id: !input attempt_counter
      - conditions:
          - condition: trigger
            id: wedged
          - condition: numeric_state
            entity_id: !input attempt_counter
            below: !input max_retries
          - condition: template
            value_template: >
              {{ last_try is none or now() - last_try > cooldown }}
        sequence:
          - service: counter.increment
            target:
              entity_id: !input attempt_counter
          - service: input_datetime.set_datetime
            target:
              entity_id: !input last_attempt
            data:
              datetime: "{{ now() }}"
          - service: homeassistant.reload_config_entry
            target:
              entity_id: !input canary_entity
          - delay: !input recheck_delay
          - if:
              - condition: state
                entity_id: !input canary_entity
                state: "unavailable"
            then: !input failure_actions
            else:
              - service: counter.reset
                target:
                  entity_id: !input attempt_counter

last_try and cooldown are blueprint variables (the datetime helper, and a duration input). The full YAML is in the pack.

Setup outline

1. Create a counter helper (initial 0, step 1) and an input_datetime for the last attempt.
2. Import the blueprint. Fill the canary, dwell, re-check delay, max retries, cooldown, the two helpers, and the failure notify.
3. Test the happy path: Developer Tools → set the canary unavailable is not always possible for a real entity, so pick a template binary you can force, point a test automation at it, and confirm a reload call in the trace. Then point the real automation at the real canary.
4. Test the failure path: use a canary you know will stay unavailable (a disabled entity will not work — disabled entities are not unavailable). Confirm one notify after the re-check, a second attempt only after the cooldown, and silence once the counter hits the cap.
5. Restore the canary. Confirm the counter resets and the next real wedge is allowed again.

Troubleshooting

• Reload never runs. The dwell is longer than the outage, the counter is already at the cap from a test, or the cooldown datetime is still in the future. Reset the counter and clear the datetime.
• Notifies even though it came back. The re-check delay is shorter than the integration’s startup. Raise it. The notify must sit in the still unavailable branch, not before the reload.
• Reload storm. mode: single is missing, or the counter increments after a successful re-check instead of resetting. A successful re-check must zero the counter; a failure must start the cooldown before another trigger is eligible.
• Wrong integration reloaded. The canary belongs to a different config entry than the one you think (a template, a group, or a helper). The service reloads the entry that provides the entity. Check Settings → Devices & services → the entity.
• Sleepy sensor keeps reloading Zigbee. That device is supposed to be quiet. Exclude it here and use low battery alerts or the offline report’s exclude list instead.

Credits

Based on the reload-on-unavailable blueprint in ha-reliability-blueprints. This write-up is an original overview of that reload-and-recheck path with a retry cap and cooldown so a failed reload cannot loop.