You pick out a single sentence? Guessed wrong, I always was aware, but the frequency and notifications have gone up very high last weeks.
- Release 2023.2.1 - February 16
- Release 2023.2.2 - February 17
- Release 2023.2.3 - February 20
- Release 2023.2.4 - February 23
How is that different from January (actually in total more updates than in February 
):
- Release 2022.12.4 - January 20
- Release 2022.12.5 - January 23
- Release 2022.12.6 - January 24
- Release 2022.12.7 - January 26
- Release 2022.12.8 - January 27
or December with even two releases on the same day?
It’s very normal that after the monthly release bug fix releases coming in 
Keep on rolling 
You’re picking your response again on a part of the sentence 
.
I never had any issues with updates, just managed them alone in the esphome addon. Now they’re also popping in HA it’s more “present”.
When I quote your whole post the @system will just auto magically remove the quote completely
I posted already how to “opt-out” on update notifications for particular esphome nodes or how to do it for all - the rest is up to you
PS.: I now circumvented actions from @system by quoting your whole post in two parts 
I suspect a lot of folks that don’t like the recent changes to ESPHome devices would have less of a problem if there were accompanying changes that made it easier to opt out of the bulk update process.
That’s very obvious with the amount of users “complaining” on various channels - including this forum 
I actually expect that based on the user echo we will sooner or later find a option to fine grain update notifications for esphome in HA (like for all update, for security updates only or even disable it completely). In the past @frenck or @jesserockz always took valid feedback into account and everything turned out to be even better in the end 
Agreed. Those guys rock. 
Or if there was an easy way TO bulk update? I’ve had very poor results trying to update my 20 or so esphome nodes often requiring me to make 5-10 attempts to get thru the update-all, and one of them can only be updated when it “phones home” due to solar/battery deep sleep. Seems like it times out and then doesn’t finish the job in bulk.
But yeah regardless it’d be nice if it was less nagging. I don’t care that its got a big number but when it hides any OTHER relevant updates due to the number of ESPHome updates that’s an issue. I want to know about them but probably only care about certain ones.
I have 20+ ESPHome devices in my house and I’ve spent quite a bit of time thinking about this too trying to decide how to handle it. I think @sender said it well with this line:
For now, I’ve been turning off “Enable” for the Firmware value on almost all my ESPHome devices so I can reduce the number of notifications. I don’t really want a notification for every device to show up on HA because most of them aren’t going to be impacted by a FW flash from the new ESPHome release. I do want a single notification that ESPHome devices are out of date. I would like it if any ESPHome devices were out of date, it would bundle them up into a single notification on HA saying “An ESPHome device is on old FW”.
The best long-term approach I can think of is to figure out dependencies from the ESPHome YAML file on each ESPHome update and decide then the criticality of each update to an ESPHome device deployment. I envision any update that has a change which is touched by the implementation should be flagged as a node needing the firmware flashed. You could even go so far as to decide on the importance of the FW update based on the changelog if the developers published a grading scale of some kind.
Anyway, that’s my pie-in-the-sky wish list that probably is unattainable. 
I think the solution is even simpler.
If you device is working then don’t update.
Then you have dozens of “update” notifications that you have to individually hit install or skip on, which may all come back tomorrow if there’s another update.
I’m very grateful for all the work the esphome developers do, but I would also welcome a less frequent update schedule. If there was an option to only update 4x per year instead of monthly, I would enable it.
Just set yourself a reminder (automation) to update your nodes every 3 month 
I would definitely agree with that! I’ve now switched almost all my devices at home to ESP: that makes over 80 of them. When I finish there will be even mora than 100!!
With every little update, it takes almost the whole day for all ESP devices to be reflashed OTA…
As I can see on the screenshot below, I can no longer turn off the notification at all!
:o
You see that this update only includes/lists 5 changes/fixes? I very much doubt that all of your 83 devices need that update… The ones which feature a cse7766 power sensor or a tmp102 temp sensor should improve. In case you use esphome nodes with wake word they also should benefit - for the rest the update is of no importance (in other words: useless) as it doesn’t include any general or security fixes 
Or in other words
With great power comes great responsibility
Any of the various ways described should do it - for me it was only one click to get permanently rid of all esphome update notifications.
1 Like
Another thing that would help, is quit compiling the source for the same devices over and over… these are shared libraries, not individual device libraries.
If I have ten of X architecture somethings, it should compile the library once for that architecture, in cases where the config file doesn’t change the binary .o file. Then link individual device .o files against the shared .o files.
And at the next source update, only build things that changed, not the entire esphome core tree again.
Did ESPHome hire someone from Gentoo? LOL… joke… but not really… wow…
Even Tasmota who releases complete binaries, manages to do everything with ten binaries for every device they support… AND they can auto upload minimal to devices limited on space AND auto update to the correct full version immediately afterward. No source building required… at all.
This architecture for updates happening weekly, is well beyond silly.
Probably worth warning users about – if you’re happy with Tas, stay there. This is completely bonkers and even the long-understood unix compile process isn’t utilized correctly.
Feels very slapped together. I’ve got 8266 devices with plenty of room to run that need a minimal OTA firmware then upgrade cycle. With TAS, all I have to do to automate that is toss their binary minimal at the device and it’ll finish the upgrade on its own.
I don’t even think the ESPHome add-on is attempting to .gz these firmware images… but maybe that’s fixed now.
(Just an interested party who wanted to try ESPHome thinking if Nabu Casa bought them and integrated them, it must at least be as smart as Tas… whoa boy was I wrong! LOL… yuck… messy… very messy. Feels like beta. I’ve only got seven devices converted over, and I completely halted this little ESPHome “experiment”… it isn’t ready for prime-time. Love that there’s new life in it, but yikes… it un-automated a small portion of my home instead of automating it.)
Feel free to send a PR so your function(s) can be included 
https://github.com/esphome/esphome/pulls
Is it? Last time I counted tasmota offered already over 100 different binaries in the web installer… 
While in the past it could often happen that you have a sensor supported in one binary it lacked display support because that are in a different binary (a manual compilation of things is then necessary).
It’s actually monthly for feature release plus bug fixes.
The way esphome (and ha is shipped) is close to a rolling release or continuous delivery approach, you can read more about that on wikipedia if you like to know more
Not sure what you did wrong? Are you still wasting time with mqtt and not using the native api?
For my 80+ esphome nodes all that it takes is one click on “update-all” to update all devices - that could obviously be automated but I rather do this myself every 2 or 3 months
Answering your questions:
Yeaaaahhhh, a PR from a volunteer to a paid team to completely refactor their misuse of a compiler such that it needs to build the same object file over and over for every device? Yeah, thanks, no.
I know what a rolling release is. We call that “hoping to patch your way to success”… LOL. Also known as, “Always broken”. Meh. It’s not a positive anymore once you hit about 80% just passing down upstream patches without any real regression testing. Seen the release notes lately? Upgraded library blah… repeated about 50 times… that stuff isn’t getting tested… and it’ll roll again the next month…
No idea what the “web installer” is, but there’s only ten binaries to cover installation of ALL hardware they support. Did I stutter?
Did you have a point besides playing the clip individual sentences game to add snark? I made mine. There’s nothing particularly compelling or “better” about this, having tried it. It’s a pretty big mess. Especially at IoT numbers of devices scale. Recompiling for 50-100 devices isn’t going to scale.
Just here to discuss. It is a discussion board after all. Not sure you actually addressed anything I mentioned as architechtural issues (that still need a LOT of work), though.
Did you have an architectural point as to why waiting for binaries to compile for 50-100 go-arounds for the same object files, is a good thing? How about when someone has 200?
Iterating over a directory tree rebuilding 50-100 binaries at every release, is just brute force… it’s not much of an update system… it has absolutely nothing to do with the API. API works fine. Re-read.
I’ll stick with Tas on the majority of the devices until this is a LOT faster…
Updating those is a shell script that grabs the latest minimal, hits all of them via http to tell them to grab that from the internal webserver, and they do the minimal to full transition on their own, and are back online… ALL of them, in roughly 120 seconds.
(One laggard that’s way at the very edge of wifi coverage takes 180.)
Nothing needs compiled, nothing gets repetitively compiled over and over, same code… the CPU and other resources on the HA box don’t even notice it.
Re-compiling 50, 100, 200… new binaries at every monthly update, is completely bonkers… it’s a nice “first effort” I guess…
No skin off my nose, just chatting. Tas works well. ESP integration will have to do something a lot more compelling than kick off a copy of a compiler for every device before it’ll scale, is all I’m sayin’…
Like you, I could automate it and not click… watching it just made me realize it’s a resource suck for no particularly good reason… doesn’t seem to add any more functionality to the devices, or anything like that either, of course…
Fun convo.
It’s always great when people complain and do exactly 
(zero) to change the status quo. Not even a feature request? Just ranting… the internet in the year 2024 
So you are aware HA does the same?
Install Tasmota (powered by ESP Web Tools)
No idea, I don’t want. Just click “update-all” (takes around 1 second) and go on with my live 
And that’s one of the biggest advantages over Tasmota. I used to have quite a lot tasmota devices before I switched completly over to ESPHome. Getting a device up & running was way fast for me with esphome and it is not necessery to do as many steps as tasmota needs (connecting to tasmota AP, enter wifi details, enter mqtt details and other configs in various places like web ui, console, etc…)
Depending on your needs it’s up to you when rolling updates, I do it around every 2 to 3 months when nothing critical hits (that’s almost never)… The release notes got you covered if your particular device(s) even benefit from an update 
I actually don’t have it automated but just click that button like explained in my last and this post
Any way from my mileage esphome is much easier to scale, faster to onboard/enroll and the biggest advantage for me (over tasmota) is the stability. It’s rock solid with local automation, everything burned into the binary and no loss of (volatile) settings like it (used to?) happen with tasmota much to often. 
Oh good lord, you’re one of those who quotes line by line and can’t maintain na conversation related to my original post. Yuck. Just write your answers in conversational format. I’m not posting code here… sheesh. Plus you use it to REMOVE my points so you don’t have to address them. Example: Rolling releases are just continuous patching taken to the extreme without proper testing timeframes. Quote that. Of course I know HA is doing the same thing, it’s all the rage these days… it’s not particularly compelling other than as a way to look busy. It provides no particular significant quality improvement over a slower and more careful release cycle. Never has.
(It hasn’t changed anything in the overall industry much and definitely didn’t reverse anything in well researched works like The Mythical Man Month, etc.)
As far as the whine that I haven’t done anything to “amke it better”, pffft… been doing open source since before linux was even a thing – and if you stick to my original post you’ll notice I’ve made no claim it must be fixed, I’ve said it’s weak architecture for embedded devices and Tas does it better… and we all have either one to choose from.
(If you want the hard truth, both need better tagging of security vs feature updates, and long term support type branches, but that wasn’t part of my analysis of how Tas handles updates vs the ESPHome integration compiling and compiling and compiling, to build the same binaries over and over… on the user’s box…)
As far as the web installer thing you mentioned, ahh I see – you use some newfangled web thing… most of us old Tas folk just grab one of these and go… takes about thirty seconds and can be hosted locally…as mentioned in my already working upgrade script.
https://ota.tasmota.com/tasmota/release/
However, I do know you aren’t “going on with your life” since that upgrade webpage isn’t closeable and doesn’t go into the background… hahaha… unless you’re triggering the upgrade event from developer tools… (Grin)…
If you were connecting to the Tasmota AP more than once in the lifespan of thje device, you didn’t understand how to send it commands via a simple URL request with curl. Sorry you missed out on that, it’s essentially an “API”. All of the config can be done without logging into them… shrug… not sure what all you missed…
Already covered the problem with deciding when to patch via release notes above, needs “security” tags. Couldn’t care less on embedded devices that there’s some new feature I’m not using in one of the two hundred resulting object files in ESPHome for some device I don’t have, but it’s a recompile anyway… it’s currently not even smart enough to not rebuild the binary if nothing changed… even though there’s oddly a “clean source tree” button kinda acting like that’s planned someday… if it wasn’t cleaned, it shouldn’t be rebuilding…
make && make install … vs … make clean && make && make install – you follow?
But no, projects shouldn’t ALL be doing this “read our breaking changes!” crap… it’s getting old. How about you stop breaking things and take the time to migrate things correctly vs break? End-users should not be reading release notes to trust automating security patching…
I’m glad you like wasting time clicking buttons… but I automate away security patching both at home and for a living… enjoying clicking to patch is a very hobbyist-centric point of view and something hobbyists like. I was “over it” being interesting to wacth something like twenty plus years ago… ha… it’s the wrong path. You don’t even want to bother the user with it in a properly “product-ized” system. That said I know HA is really mostly run by hobbyists who love watching it do things when they click… when they could be outside enjoying some sunshine or spending time with a loved one… the older you get the less interested you are in watching something compile… that’s stuff the CI/CD pipeline is supposed to do before it even gets sent out to the end user… grin!.. not even the devs should be watching that silliness… the pipeline will alert if errors…
I can’t think of a single pro dev dept that sat and watched things compile in the last decade-plus… making the end user watch it? Or using their machine’s resources to do it? Pfffft… no. We wouldn’t let that past the change control committee… no way… not even twenty years ago…
Anywhooo… it’s too bad you never realized Tas had all the scale tools built in. TasAdmin I believe it was called, wrapped all that stuff with buttons to push if you liked buttons… and watching it…
I just wrote a very very short shell script.
It’s been years, like six (?) since I’ve seen Tas lose setting data… and it hasn’t even stored that in the same flash area as the code for so long, I wonder what was really happening on yours… it didn’t really have access to it unless you somehow told it to wipe the entire flash… shrug… but I mention it because it’s another side topic that has little to do withj all of this compiling the integration is doing unnecessarily – back to the original post we are supposedly discussing – recompiling constantly when it’s not needed for a particular architecture or any actual code change, actually raises the chance something will get changed and error out, that was running fine… significantly if automated…
And this IS after all Home AUTOMATION, not Home “let’s sit and watch a compiler build things”, right? I’m not running home automation to be wowde by someone’s ability to dump a compiler log to my web browser, after all! Hahaha…
Cheers.