Scheduled bulk updates with a two-phase pipeline (compile at a preset time, then OTA upload), per-device exclusions, and outcome notifications

[ettiennecoetzee]

Describe the enhancement

Summary

I would like ESPHome Dashboard (Home Assistant add-on) to support an automated “bulk update orchestration” workflow that can (1) wait until ESPHome/ESPHome Builder has been updated, (2) compile selected nodes at a preset scheduled time window, (3) only if compiles succeed, proceed to OTA uploads, and (4) produce a clear notification/report of outcomes (compile + upload) with the ability to exclude “protected” devices from the bulk update process.

This is closely related to the existing desire for scheduled “Update All” behavior, but I am specifically requesting a safer, more controllable, two-step pipeline with opt-out protection and reporting. (#1677) :contentReference[oaicite:1]{index=1}

Problem / Motivation

• Updating a fleet of ESPHome devices is currently mostly manual, and it is easy to forget or postpone updates.
• Compiling many nodes can be slow on smaller Home Assistant hosts, and users often want this to run overnight.
• There is a real reliability risk if multiple compiles are triggered concurrently (for example from multiple browser sessions), which can overload the host. A built-in orchestrator could enforce queueing / concurrency limits. :contentReference[oaicite:2]{index=2}
• Some devices are “critical” (doors, heating, alarms, remote nodes) and should be protected from automatic bulk updates unless explicitly included.

Requested Feature: Two-phase Bulk Update Orchestrator

High-level behavior

1. Trigger condition

   • Option A: Automatically create a “pending bulk update” after ESPHome Builder / ESPHome Dashboard updates (or after a new ESPHome version is detected).
   • Option B: Manual “Queue bulk update” button, but execution occurs later at a scheduled time.

2. Phase 1: Compile window (scheduled)

   • At a user-defined time (for example 02:00), compile a selected set of nodes.
   • Enforce a safe queue with configurable concurrency (default 1 compile at a time).
   • Store build artifacts per node (so the upload phase does not need to recompile).

3. Gate

   • If any compile fails (or optionally if N compiles fail), do not proceed to OTA uploads automatically.
   • Present failures clearly with logs and “manual download” options.

4. Phase 2: OTA upload window

   • Only start OTA uploads once the compile phase has succeeded (or once the user explicitly approves).
   • Upload sequentially (or with a safe concurrency limit).
   • Optional: Upload only to nodes that are currently online (related to Change "Update All" to "Update Online Devices" #2441). :contentReference[oaicite:3]{index=3}

5. Outcome notification and report

   • Provide a summary report with:
     • Compiles: success/fail per node + links to logs
     • Uploads: success/fail per node + last error
     • Totals: X compiled, Y failed, Z uploaded, etc.
   • Notification endpoints could include Home Assistant persistent notifications, and optionally a webhook or HA notification service integration.

Device exclusions (safety feature)

Add a first-class way to exclude devices from bulk updates, for example:

• A per-node toggle in the Dashboard UI: “Exclude from bulk updates” (protected devices).
• Or tags/groups (example: “protected”, “remote”, “test”, “canary”).
• Bulk update UI should show excluded nodes and require an explicit override to include them.

Optional “staged rollout” enhancements

• Allow a “canary group” that updates first, then if successful proceed to the rest.
• Allow “compile-only” mode (generate artifacts now, upload later).
• Allow “upload-only using latest artifacts” mode.

Why this belongs in ESPHome Dashboard

ESPHome already has an “Update All” concept discussed in the community, and scheduling has been requested before (#1677). :contentReference[oaicite:4]{index=4}
This proposal focuses on making bulk updates safer and more automatable by:

• separating compile from upload,
• enforcing queueing / concurrency limits,
• providing a clean reporting/notification layer,
• and adding an explicit safety mechanism to protect critical devices.

Acceptance criteria (what “done” looks like)

• User can configure a scheduled time for bulk compile (and optionally upload).
• Bulk operation compiles nodes using a queue with safe concurrency.
• Upload phase can be gated on compile success.
• User can exclude specific devices from bulk updates via UI metadata (or tags).
• After completion, user gets a summary notification with per-node results.

Workarounds used today

Users can approximate this with external scripts/automations, but it is fragile and not integrated with Dashboard status, logs, device online state, or per-device protection. An integrated solution would reduce mistakes and make updates safer for larger fleets.

Environment (example, can be edited)

• Home Assistant OS + ESPHome Builder add-on
• Many nodes (ESP32/ESP8266), OTA updates
• Host resource constraints make overnight sequential compile desirable

Use cases

In my setup I manage a fleet of ESPHome devices (mix of ESP32/ESP8266) that are updated frequently as ESPHome and Home Assistant evolve. When ESPHome updates, I typically want all devices rebuilt, but I do not want to compile and OTA flash everything immediately during the day while the Home Assistant host is busy and while I am not available to babysit failures. The ideal workflow is to queue a bulk update, have the add-on automatically compile selected nodes overnight at a preset time with safe queueing, then only if the compiles succeed proceed to OTA uploads, finally generating a single summary notification showing which nodes compiled and uploaded successfully and which failed with links to logs. A small subset of devices are “critical” (for example door locks, climate control, alarms, remote nodes), so they must be excludable from bulk updates by default to avoid a breaking change taking them offline, with the option to include them explicitly when I am ready.

Visual examples

No response

Anything else?

No response