Thanks for this, saved me a whole bunch of time. Easy enough to update, but it’s a pain that you have to edit each device file and then upload. It’s why I keep ESPHome to a minimum and use Tasmota in preference, click a button and it’s upgraded.
If you take a smarter approach to managing your devices, this wouldn’t be an issue at all. Use GitHub for generic parts of your config…only have to update one config file.
I use a HA Automation to update all my ESPHome devices at 3 am if an update is available.
Yeah this is one of the reasons I hate YAML. Both of these work:
ota:
- platform: esphome
password: "something"
ota:
platform: esphome
password: "something"
As everyone else, I came here after a google search. Just updated from 2023.12 to 2024.06 or something like that. As it has been said, there is usually no rush to updating. Things work.
For me it was a home assistant update that broke my esphome with epaper-display, but I assume I should be able to fix this with not too much work. Something with the weather forecast entities I assume.
2 Likes
Only second solution work for me. First solutions give error
mapping values are not allowed here
in "/config/esphome/esp13-102.yaml", line 20, column 13
“This change was made to facilitate the use of multiple update mechanisms, enabling greater flexibility.” Yeah right at the cost of a working integration. Documentation is terrible which isnt helpful.
Thanks this was very helpful. I just added the platform line without the “-” above my password like your example and it worked.
Great post, lifesaver. Shame there is not a version upgrade script/process working to migrate configs as you go. ie you have ota: but no platform configured, inserting default platform esphome
1 Like
From my view I don’t get the issues. HA is free and open source and I don’t contribute. How can I complain? When an update comes I scan the changelog. For 2024.6.0 there were 2 breaking changes, both of which impacted me. I chose one yaml to test and it took a few minutes, along with some googling, to sort things out. I then did a mass update on all my devices.
2 Likes
I think this error is different. I ran into the same with either way of writing the ‘ota:’ part.
When using the ‘- plateform’ way, you have to make sure you use the same ‘style’ for the rest(your sensors et.). Which means:
[space]-platform; myplatformname
[space][space]firstline
example:
sensor:
- platform: pulse_counter
pin: GPIO12
If you mess up wich the spaces in front. Like 1 or 3 or more for the line that starts with ‘pin:’, I get the error you mentioned.
Use the </> button or backticks like this:
```
CODE GOES HERE
```
Thanks!
I did try both before. But not hard enough 
.
Now it worked.
1 Like
How did you get the backticks shown and not converted to a code block in your post?! 
Magic 
Use backslashes to escape the backticks. What I actually typed was:
\`\`\`
CODE GOES HERE
\`\`\`
but oooh, how did I type that?
2 Likes
Ran into this issue today after upgrading last night. Thanks for the quick fix!
Dear HA Devs,
Could you please consider adding more details/links to such error messages as mentioned here? Especially if it is already foreseeable that hundreds (or more?) of average HA users will fall into such or similar breaking changes pitfalls.
Alternatively, you could try emphasizing on a prominent place, where all users can see it, that it is very recommendable to first read and understand the change log before updating.
I really want to thank you Devs and other HA contributors for this really great tool! 
And for the friendly and helpful community, too. 
1 Like
What would you propose where this should be made more clear?
I mean, this is the page, where updates are explained, it literally states (#2):
Check the release notes for backward-incompatible changes on Home Assistant release notes. Be sure to check all release notes between the version you are running and the one you are upgrading to. Use the search function in your browser (
CTRL + f/CMD + f) and search for Backward-incompatible changes.
Here it is shown in the release notes, which always are a blog post, so reachable and seeable for all users.
And these are only the notes outside your installation. If you hit the update button, it shows a link to the release notes, that opens in a new tab/window.
Not to mention all the people, that tell you to read the release notes before updating in the forum or on all other support sites. 
Don’t take this the wrong way, you seem to be one of the people, who doesn’t notice all these markers, where should it be shown and how? Really, this is a genuine question. 
I for one am a little annoyed by all the notes and messages I get for updates… 
So really, tell us/me, where would you place the warning signs?
I do read the release notes, but this slipped - not only for me, as it seems.
When I wrote here before, I should have referred to this observation:
It seemed that this breaking change was not so obvious in the notes, but maybe it was just me and some others, who asked about it in this thread. There might be a majority of users who knew what to do (and therefore would not ask here).
Honestly, I don’t know where (else) to mention such changes, and I agree that reading the release notes before updating is highly recommended.
To sum it up from my perspective: You cannot make it “fool-proof”.
And please kindly accept my apologies on case my post was somehow not adequate or helpful.
PS:
BTW, placing “safe_mode: no” as suggested in the example of the corresponding PR does not work, because it will throw another error message that “safe_mode” is now also handled differently. 
Thank you so much for the resume, that what we all needed!
Well… it would be a step forward if breaking changes are handled consistently in Home Assistant. There are some breaking changes in the following pattern, that already occured (and where that was handled so that functionality wasn’t impaired immediately):
- Breaking change is planned and announced for Version X (PRs, Release Notes, etc.)
- Release of Version X-n → Information is shown in the HA Notifications, that configuration XY needs to be adapted until Version X release date (if they actually use configuration data that is known to be altered in the future)
- Release of Version X (with the actual breaking change)
This flow is sometimes already used within Home Assistant and ensures that users only need to act upon actual problematic configuration they use - and don’t need to always read multiple display pages of change notes.
And to be clear, in a Software Developer point of view with consumer in focus: Should people read release notes? No - sorry, but people don’t have the time to always read release notes of software they use. It is a good source of information IF they are interested in. But the reality is that most people just lack time and the muse for it and just want software to work (especially since 99% of the time the release notes are not relevant for them). If software does not work or breaks regularily then people will fallback to privacy-invading offerings, like Amazon, Google, etc. - because it “just works”.
I disagree. They should still read the release notes before blindly hitting the update button. Your 99% relevancy figure is also a bit suspect and sounds made up. I had a look at the last 3 releases and in each one there were two integrations which I use which had breaking changes (the most notable being the removal of activity switches from Logitech Harmony and the renaming of the forecasts service).
Hell, even if there were indeed 0 breaking changes, reading the release notes will tell you what new features are being released, because otherwise, why bother to upgrade at all?
Amazon and Google are multi-billion companies which do not rely on volunteers and a handful of staff for testing, and despite that they still release updates which break stuff. Earlier this year, Amazon broke third party apps on the Fire TV stick. Last month, Google released an update which broke its own password manager.
Just be grateful you actually have actual release notes you can read, so you can be prepared before updating. I’d rather have that than something like the Alexa release notes which consist of “various bug fixes and improvements”.
1 Like