Auto-Update ESPHome Devices After Add-On Update

[ZenGuru84]

Blueprint: Auto-Update ESPHome Devices After Add-On Update

USE AT YOUR OWN RISK

Firmware updates — especially automated ones — can occasionally break ESPHome devices.
In rare cases, devices may become unavailable, fail to boot, or even become permanently unresponsive depending on hardware, flash health, or power stability during the update.

Make sure you have physical access to your ESPHome devices and that you can connect them via USB if recovery is needed.
This blueprint only automates the update trigger — it cannot prevent firmware-related issues caused by the update itself.

Description

This blueprint automatically updates all your ESPHome devices right after the ESPHome add-on itself gets updated.
It removes the need to manually check each device for firmware updates whenever the add-on updates.

Here’s what it does:

• Monitors the installed_version attribute of the update.esphome_update entity.
• When the add-on updates, it waits for a configurable delay.
• Scans all ESPHome update entities (update.*) and selects only those:
  that belong to ESPHome
  that report an update available
  that are not already in updating state
• Sends a persistent notification listing all ESPHome devices that will be updated.
• Updates the devices sequentially, with a configurable pacing delay between updates.
• Sends a final persistent notification listing all devices that were successfully updated.

Everything runs hands-free — once configured, it just works.

---

How it works

1. Import the blueprint using the button below.
2. Create an automation using this blueprint.
3. Configure two parameters:

• Delay after add-on update – waiting time before scanning ESPHome devices.
• Pacing between installs – seconds to wait between sequential firmware updates.

4. Whenever the ESPHome add-on updates, the automation triggers automatically.
5. It sends a notification, performs updates one by one, then sends a final summary.

---

Notifications

This blueprint uses persistent notifications inside Home Assistant:

• Before updates begin:
  Lists all devices that will be updated.
• After updates finish:
  Lists all devices that were actually updated.

This keeps you fully informed without manual checking.

---

Benefits

• Fully automated firmware updates for ESPHome devices after the add-on updates.
• Prevents forgetting to update individual devices.
• Safe sequential updating prevents congestion or connection issues.
• Clean notifications before and after the process.
• Zero maintenance once set up.

---

Notes & Recommendations

• Ensure your ESPHome devices expose an update.* entity (default behavior).
• The automation mode is single — repeated triggers won’t overlap.
• If you have many ESPHome devices, start with a longer pacing delay.
• Review firmware changes if you run critical devices.

---

Install the Blueprint

Click below to import directly into Home Assistant:

---

Support

If this blueprint helped you, a GitHub star would be greatly appreciated:
GitHub - zenguru84/my-ha-toolbox: Reusable things for Home Assistant

And if you want to buy me a beer, you can do it here
https://www.buymeacoffee.com/zenguru84

---

Enjoy your automated ESPHome updates!

[Protoncek (Pavel)]

While i appreciate your work i can’t help wondering (just a friendly reminder for all users, i mean nothing bad) …i hope that you are aware of danger part of such a blueprint? There are breaking things often in new esphome versions which MUST be read BEFORE you do any update since they can break your devices (render them useless or unavailable). Often some parts of code must be changed, removed, added… while some of these devices are easily accessible and flashable via USB some aren’t (like glued shelly’s etc…) so this can actually sends such device directly to special waste bin.

Not to mention that there’s also a couple of times mentioned golden rule: “don’t repair if it ain’t broken”. Don’t update if nothing has changed for your device program, since nothing WILL be changed apart version number.

[ZenGuru84]

You are right. Thanks!
I will include something about this in my post.

I have lots of ESPHhome devices and never had a situation like you described above. Not saying it’s not possible to happen, just never happen to me.

[sender]

I have this at almost every major update. Especially a lot after the recent idf change…

[ZenGuru84]

@sender you have what? “bricked” devices after updates?
I think regularly updates lower the chances of breaking things.

[eigger]

I also update my devices regularly, but it’s quite annoying to click each one individually. Thank you for creating the blueprint.

[ZenGuru84]

@eigger with pleasure!
use it wisely!

[sender]

Yes and yes

[Hellis81]

@ZenGuru84

I think regularly updates lower the chances of breaking things.

None of my devices has been bricked due to updates since I stopped updating them.
But when I did update them, they got bricked and had issues caused by the updates.

You are gambling with your setup, just because it hasn’t happened yet doesn’t mean it won’t happen.
And when it will happen then thanks to your blueprint, it will happen on all devices at the same time.

[ZenGuru84]

@Hellis81 you just proved my point.
if you skip tens of updates, and then you decide to update, chances to brick something are high. and hard to fix, because the cause can reside in any of the skipped updates.
QED

i’ll use it at my own risk. i can physically connect to any of my devices in no time.

[Edwin_D]

Use wisely is an impossible suggestion. You use it and pray it does not break things, or you do not use it and be safe about it.

I agree with Herllis81 auto updates on all devices at once is a big risk. Look at yesterdays release notes and see how much changed. It may all work, it may not.

What I do is check release notes first. If I feel there’s not much in it for me I skip all update using a script (see below). If they are nice, I try one or two that are lower risk and can alert me to possible problems. If some are still scary, I skip those ESP’s. for the ones I do want to update, I run another script to update the esps that were not marked as skipped:

Skip all ESP updates:

alias: Skip all ESP updates
sequence:
  - action: update.skip
    metadata: {}
    data: {}
    target:
      entity_id: >-
        {{ states.update | selectattr('attributes.title','eq','ESPHome') |
        selectattr('state','eq','on') | map(attribute='entity_id') |
        reject('eq','update.esphome_update') | list }}
description: ""
icon: mdi:memory

No longer skip the ESP updates that I previously skipped:

alias: Unskip all ESP updates
sequence:
  - action: update.clear_skipped
    metadata: {}
    data: {}
    target:
      entity_id: >-
        {{ states.update | selectattr('attributes.title','eq','ESPHome') |
        map(attribute='entity_id') | reject('eq','update.esphome_update') | list
        }}
description: ""
icon: mdi:memory

Install all ESP updates that are not skipped:

alias: Install all non-skipped ESP updates
sequence:
  - action: update.install
    metadata: {}
    data: {}
    target:
      entity_id: >-
        {{ states.update | selectattr('attributes.title','eq','ESPHome') |
        selectattr('state','eq','on') | map(attribute='entity_id') |
        reject('eq','update.esphome_update') | list }}
description: ""
icon: mdi:memory

These scripts require the firmware update entities to be enabled, they are not by default.

[Hellis81]

@ZenGuru84

@Hellis81 you just proved my point.

I believe you did not understand my post then…

[Protoncek (Pavel)]

@ZenGuru84

I think regularly updates lower the chances of breaking things.

Sadly it’s rather other way around… Each programming of esp can go wrong at any time, even if program is ok… Devs, and also many others often point out that it’s IMPERATIVE to read changelog in detail BEFORE doing ANY update (valid for HA and addons also!!!).

But, as said many times already, many (if not majority) never does that, but rather ask for their problems here afterwards… And this blueprint quite nicely bypasses exactly this most important part: reading the changelog. Then number of questions like “my esp doesn’t work after update” then rises above acceptable, consequently same and same answers are given hundreds of times… (as those people many times also don’t use search much to find already answered problems).

Think this way: say that you have version, say, “a” and in your esp you have one i2c sensor for temperature/humidity. Now, version “b” is different from version “a” in, say, modified switch configuration, but it doesn’t touch sensor or i2c part nor wifi, ap… When/if you update code for i2c and sensor is exactly the same - down to the last bit. So, apart from time wasted you only needelssly wear out flash and risk of something going wrong, nothing else. Oh, yeah, there IS one “plus”: shiny new and latest esphome version number…

Some of my esp’s still run 2023 code… and they work flawlessly.

As “sender” said: latest idf changes “bricked” quite some esp’s… there were quite some questions here about that (because people didn’t read changelog before doing update). Then there were changes in type naming, like in template: bme280 → bme280_i2c and similar.

[Protoncek (Pavel)]

@ZenGuru84

if you skip tens of updates, and then you decide to update, chances to brick something are high.

You completely turned around hellis’s point… .again, it’s quite contrary: when - after long time - you decide to update certain esp you do that not because “you feel like it” but because you add or modify something. In this case compiler will warn you that things aren’t ok (anymore) and you’ll be forced to correct them BEFORE esp will be updated. So, no bricked devices.
After all-… do you take your car to a service when service buys some new shiny tool or when your car needs it?

[Hellis81]

@Protoncek

after long time - you decide to update certain esp you do that not because “you feel like it” but because you add or modify something

Even if I want to change something after a long time, then I use legacy ESP Home to make sure I do not get in to issues.
Only on devices that it doesn’t really matter do I update.
Like bluetooth proxys, they only do that and if they break then I just recreate it with the new code.

But updating my old devices from several years ago, no way!
They work fine the way they do. There is no reason for me to update them.

[ZenGuru84]

guys, you are totally right, and i’m sure you had those bad experiences.
i’ll continue to use this blueprint, and if i’ll run into issues, i’ll fix them.
if there is anyone thinking like me on the subject, they’ll use it too.