Automating Update Manager

Every entity Update Manager creates lives under its own "Update Manager" device.

Status sensors

• One per status the Updates tab groups by: sensor.update_manager_ready, _waiting, _blocked, _skipped, _not_installable. Each sensor's state is that status's own count, with affected entities listed in its attributes; point a numeric_state trigger at one directly, e.g. to notify when anything becomes Discouraged.
• sensor.update_manager_needs_manual_action separately counts "Ready to update" entities that won't auto-install on their own, i.e. what's left for you to do yourself.
• sensor.update_manager_pending_installs/sensor.update_manager_failed_installs expose the exact same live lists the built-in "Scheduled updates"/"Failed updates" persistent notifications are built from (entity_id/to_version/execute_at, and entity_id/to_version/reason respectively), so an automation can read the same information those notifications show.

Events

Fired on hass.bus for the three discrete moments an automation might want to react to:

Event	Fired when	Data
update_manager_announced	An auto-install countdown starts	entity_id, from_version, to_version, release_url, execute_at
update_manager_installed	An install completes, auto or manual alike	entity_id, from_version, to_version, auto_installed, install_method, auto_install_reason, trusted_voter_usernames
update_manager_install_failed	An auto-install's update.install call raised	entity_id, to_version

Ongoing status is already covered by the sensors above; these events are only for the moments in between. install_method is auto, manual, or external (updated itself outside Home Assistant, e.g. a device with its own separate auto-update setting).

Native automation triggers (beta)

The same three moments above also show up directly in the automation editor's own trigger picker (search for "Update Manager"), each with a native entity-target field to narrow it to specific update entities, instead of a plain Event trigger with the raw event type and manual entity matching:

• Scheduled auto-install: same moment as update_manager_announced.
• Installed: same moment as update_manager_installed.
• Install failed: same moment as update_manager_install_failed.

Marked beta: built on a Home Assistant trigger API that's still young and can still change, so these might need adjusting on a future Home Assistant release. Existing automations using them aren't expected to break, but it's worth knowing before building something critical on top of them.

Actions

Available under Settings > Tools > Actions, so an automation can act on update_manager_announced without the panel involved, e.g. analyzing release notes before letting a scheduled auto-install proceed:

Action	Does
update_manager.get_release_notes	Returns the same compiled release notes the update-detail dialog itself shows, from the currently installed version up to to_version (defaults to the entity's own current latest version if omitted).
update_manager.cancel_scheduled_install	Cancels a scheduled auto-install for to_version (same default as above).

Example: notify yourself for every scheduled auto-install

The same message the built-in persistent notification already shows, just on your phone instead. The exact time comes first for a quick glance, the precise date/time after it as a fallback: a relative time like "in 6 hours" goes stale once you actually read the notification later, the same reason the panel's own status text sticks to absolute times instead of a countdown.

automation:
  - alias: "Update Manager: notify on scheduled auto-install"
    trigger:
      - trigger: event
        event_type: update_manager_announced
    variables:
      device_name: >-
        {{ state_attr(trigger.event.data.entity_id, 'friendly_name') | regex_replace("\\s*Update$", "") }}
    action:
      - action: notify.notify  # replace with your own target, e.g. notify.mobile_app_your_phone
        data:
          title: "Scheduled update"
          message: >-
            Update Manager wants to update {{ device_name }} to version {{ trigger.event.data.to_version }}
            in {{ as_datetime(trigger.event.data.execute_at) | time_until }}
            (on {{ as_timestamp(trigger.event.data.execute_at) | timestamp_custom('%d-%m-%Y %H:%M') }}).
          data:
            url: /update-manager/updates
            clickAction: /update-manager/updates

Example: notify yourself when something gets installed

Reuses the same install_method/auto_install_reason wording the History tab itself shows, so this reads consistently with the panel:

automation:
  - alias: "Update Manager: notify when something gets installed"
    trigger:
      - trigger: event
        event_type: update_manager_installed
    variables:
      device_name: >-
        {{ state_attr(trigger.event.data.entity_id, 'friendly_name') | regex_replace("\\s*Update$", "") }}
      reason: >-
        {{ {"trusted_voter": "a trusted vote", "rules": "your own rules", "whitelist": "the always-auto-install list"}.get(trigger.event.data.auto_install_reason) }}
    action:
      - action: notify.notify  # replace with your own target, e.g. notify.mobile_app_your_phone
        data:
          title: "Update installed"
          message: >-
            {{ device_name }} updated from {{ trigger.event.data.from_version }} to
            {{ trigger.event.data.to_version }}
            {% if trigger.event.data.auto_installed -%}
            (auto-installed, {{ reason }}).
            {%- elif trigger.event.data.install_method == "manual" -%}
            (installed manually).
            {%- else -%}
            (installed outside Home Assistant).
            {%- endif %}
          data:
            url: /update-manager/history
            clickAction: /update-manager/history

Example: notify yourself when an install fails

Mirrors the built-in "Failed updates" persistent notification's own content:

automation:
  - alias: "Update Manager: notify when an install fails"
    trigger:
      - trigger: event
        event_type: update_manager_install_failed
    variables:
      device_name: >-
        {{ state_attr(trigger.event.data.entity_id, 'friendly_name') | regex_replace("\\s*Update$", "") }}
    action:
      - action: notify.notify  # replace with your own target, e.g. notify.mobile_app_your_phone
        data:
          title: "Update failed"
          message: >-
            {{ device_name }} couldn't be updated to version {{ trigger.event.data.to_version }}. Check the
            Home Assistant logs, or install it manually.
          data:
            url: /update-manager/updates
            clickAction: /update-manager/updates

Example: notify yourself when something needs a manual install

sensor.update_manager_needs_manual_action lists the affected entities in its own entities attribute (entity_id, installed_version, latest_version each), so a notification can name them instead of just giving a bare count:

automation:
  - alias: "Update Manager: notify when something needs a manual install"
    trigger:
      - trigger: numeric_state
        entity_id: sensor.update_manager_needs_manual_action
        above: 0
    action:
      - action: notify.notify  # replace with your own target, e.g. notify.mobile_app_your_phone
        data:
          title: "Updates waiting on you"
          message: |-
            Ready, but won't auto-install on their own:
            {% for u in state_attr('sensor.update_manager_needs_manual_action', 'entities') -%}
            - {{ state_attr(u.entity_id, 'friendly_name') | regex_replace("\\s*Update$", "") }}: {{ u.installed_version }} → {{ u.latest_version }}
            {% endfor -%}
          data:
            url: /update-manager/updates
            clickAction: /update-manager/updates

Want one combined notification setup for all four, matching the built-in persistent notifications so nothing is missed either way, with a notification that replaces itself instead of stacking, clears itself once resolved, and an Install button right on the manual-install one?

These four examples stay deliberately simple.

Want to run an update's release notes through your own AI setup before letting it proceed? The same update_manager_announced event plus update_manager.get_release_notes and update_manager.cancel_scheduled_install give you everything needed to do that from an automation, with Update Manager staying deterministic and provider-independent. See issue #9 for the discussion that led to these actions, and Discussions > Show and tell for a working example someone already built this way.