Heads up for Esphome 2024.6

Because (color me completely suprised and affected by the Dallas part of this) with at least one month (preferably three, c’mon just a quarter, guys?) warning I could have prepared for the update. Now I’m on total full stop on 2024.5.x until I have time.to evaluate the change to the dallas/onewire platform which I see is now bugged for EXACTLY why I was concerned about it… So now I’m stuck without taking other 2024.6.x enhancements.

Yes I absolutely can elect to not take them but now I couldn’t if I wanted to (and I do for other reasons). This one rubbed me a lot the wrong way but it is what it is…

That’s not, what we’re/I’m talking about. :wink:

The dallas sensor is a whole other thing :rofl: :rofl:

1 Like

No both. Once it becomes breaking I have to review it… Even if it’s a one liner with global search and replace. In my casr that CAN’T happen until I return from a business trip late next week.

Either way same result still stuck.

It warrants at least a warning.

1 Like

Nathan I hear you, really! :slight_smile: And I agree with you, that sometimes more information beforehand would be great.

But c’mon, we both know, that you as an experienced user would never ever update your installation while away… :laughing:
And honestly, we both know as well, that this is ESPHome - if you don’t need new functions, you don’t need to do every update. At least not in the first days after the release.

What brings us back to reading the release notes before doing anything, especially the breaking changes section. Now, in your case even better than for others, you have until the end of next week, to look for a solution, and when you get home, you can easily upgrade. :wink: :laughing:

Really, I hear you, but I’m very sure, ESPHome will follow HA in regards to grace periods, log entries and such. You know how HA was with breaking changes years ago, and I think, the solutions that are now in place, are a good compromise. There’s no reason, why ESPHome shouldn’t follow this system as well.

1 Like

I have quite a few Dallas temp sensors, some critical (hot water heat pump), some not so much (pond temp).

I’ve updated all my device yaml files (ota and 1wire) ready for the breaking changes but am not actually pulling the pin until later this month when things have settled down with a few minor updates. And when I do update will be a test run on the non critical devices first.

Even if I forget all about this and do the update many months from now there should be no issues with my config as it has already been changed.

2 Likes

Sorry,
I’m not one to complain but this update has been totally idiotic and has messed up all my ESP home sensors - thanks for this!

And yet you do…

1 Like

You can blame whoever you want but we are all responsible for ensuring that we follow best practices to ensure a rapid recovery from an unplanned event or disaster. If I upgraded my environment without reading the release notes, testing or having a fallback plan and I am suffering from unexpected or degraded performance, I am to blame - not anyone else.

If I don’t have the time or resources to test or recover then I wait to upgrade and monitor forums like this, and GitHub, to see if there are any issues that may impact my environment.

Finally, thank you very much to everyone who did discover issues AND provided meaningful information for us to recover and to help the HA developers improve HA.

3 Likes

These changes weren’t made lightly. There was a lot of discussion about alternatives before coming to the conclusion that the changes would be required to allow a much better user experience with new features in future.

All this, especially “dallas disaster” again points to the fact that making esphome update sensor visible and enabled by default was, mildly said “not a good idea at all”…
Thankfully although i did click “compile” esphome file with dallas sensors i didn’t send fw to my dallas device…
I agree that breaking changes are necesarry, but whole thing shouldn’t be made so that it forces user to update.
However, these breaking changes could, i guess, be made with some kind of “grace period” where both versions would work while we would get a warning…

Hi, I’m glad you also feel like this because I also have found this a major step backwards!

This has caused major headaches for lots of people in going through every yaml file and correcting to the new standard…it’s a joke

You weren’t forced.

Do you not know about search and replace?

Nope ??..missed that

could you give me any information how to downgrade to a working version?

I have corrected this current version but i have devices that also show temperature values on a ssd1306 lcd…and sadly no longer showing this?? (more breaking changes)…and no the examples for the desplay in the ESPhome documentation is no longer working as well???

You kind of are, since if you don’t update you’re either stuck with all those annoying warnings (i have over 30 devices…) or you have to click “ignore” like crazy. That’s “forced” to me.

Disable the individual device update entities.

Sure you can, but that’s not the point…

2024.6 is working, but you can restore with your last backup.

Can someone confirm that the update 2024.6.2 released yesterday solves the problem ?