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.
Exactly! And you write like one of our small ones - but with a little more punctuation 
Not at all!
You can just check the release notes yourself. To me it looks like the last vulnerability in esphome was CVE-2021-41104 fixed in the 2021.9.0 release. If you are feature complete on your node this probably should be the oldest version to run. 
I don’t use tasmota anymore since four or five (?) years - but it was a common problem back then. setOption xyz was supposed to fix it I think… but yea, just was never stable to do serious things with it back in the time 
Using espressif devices since long time and used a lot of projects along the road… espeasy, espurna, tasmota… all were nice but none of them was “production ready”. Everything changed with esphome Since then it is possible to have reproducible success and no problems with amnesia (lost settings etc.). Also the native api with encryption is something I would never exchange against mqtt 
Last but not least local automation that are actually easy to do and are not some cryptic assembler script style allows functions like over power shut off or timed shut off (pump runs for maximum x) to be implemented easily on a esphome node
Some people are happy running Tasmota 5 on a wall switch - why not? 
2 Likes
Oh man. I just read your latest and youre conparing Tasmota pre-pandemic to today’s ESPHome??? Lol lol lol.
And no, building an individual binary for every IoT device from a button that has to be manually pressed is light years away from Production quality. Haha.
You build mimthly binaries from source for your commercial IoT devices much??? Bwahahaha.
This is complete amateur hour.
Which is what counts for passable here in Home Assistant land. I get it.
But I’ve worked on actual embedded products. Tjis silliness wouldnt get past the first peer review. Let alone past a Change Control Board.
Compiling patches from source on the user’s hardware? You probably wouldn’t have a job for very long if you suggested that in the real world.
Recompiling at all when none of the code changes nor the config for the device needed it, to spit out the same binary as last time? Stuff you only might see in the QA lab as an internal only tool.
I’m glad youre happy wity it. It woildn’t make it out of the first team meeting without some seriously bad looks from peers in most pro environments.
That said, it’s about what I would expect out of HA pre-Nabu Casa. Nowadays I kinda wonder what they’re doing. Do they wamt their products to be taken seriously, or seen as hobbyist toys? Up to them, reallly.
The current “solution” cant even recover from a binary too large to OTA. And we’ve knkwn how to automatically handke that from Tas for years now.
Did ya notice it doesmt even gzip the binaries? Do they mot know the ota code can handle that? Haha.
Production quality. No way. Not even close.
Grab a Kauf PF12 switch — theyre cheap — and adopt it and let the curent intehration do as it pleases. Ptetend you havent done anything with ESP. Watxh it barf all over itself. Then come back and say ots teady for prine time for a complete noob to home automation and IoT devices.
It’s not even smart enough yet to count file size and know it built something that won’t fit into the ESP before it uploads it. Lol.
Not that hard to check the size of the resulting binary… this is like embedded systems 101 basics here…
Should the end user be looking up the Kauf code on GitHub … ever? No. But there it is. Dude wrote his code to use the entire ESP and add functionality not knowing some HA integration would come along and add API encryption that bloats the file too big for the device.
And then stupidly tries to upload it OTA like it’s going to fit… lol
Have you been drinkin’
2 Likes
No, bit your reply at least indicates you weren’t interested in an actual discussion about the topic as it relates to professional level coding.
Which is what I suspected from the start.
Cheers. Enjoy your hobbyist quality toy. I do.
But I mistakenly thought a forum for discussion would actually have folks actually capable of said discussion.
Saw a thread on the topic and tossed my two cents out there. Bern making embedded products for a loooong time.
This integration, isn’t production quality in that world. I have covered why.
Was worth a good belly laugh though!
They really have your expectations lowered by quite a bit, don’t they? That’s surprising.
I hope with all these acquisitions and hiring they don’t have hopes of attracting investor money. Imagine demoing something compiling source code on screen in front of the customer to an investor group. Haha.
No idea what their business plans are but this piece is not even half-baked yet.
Sorry. It just isn’t. Once you’ve actually built embedded systems for critical environments it’s pretty easy to see.
That said, for a couple of nerd hobbyists like us, it’s plenty. I just hope they aren’t thinking they’ll take this to mass market.
If it’s going to remain a system for hobbyists it’s fine. At least until the hobbyist outgrows it and has a life and no time to mess with it anymore.
I love what I can do with HA, but I wouldn’t recommend it to family members who don’t waste copious hours of their lives tech nerding for a living besides watching this thing compile code as nerd entertainment. Ha.
Cheers. If anyone else wants to discuss architecture that actually has an embedded systems background, I’m all ears. It’s not fun to discuss with disrespectful folk like yourself who’ll simply resort to making drinking jokes when you’re out of your league.
Shrug… not sure why you’d go there.
But other drugs? Be honest! At least it’s funny and you have the time for writing this amusing texts, please continue entertaining us. thx
Nabu Casa has no investors to satisfy, just its users.
https://www.nabucasa.com/
2 Likes
You could have said this:
As a seasoned developer with extensive experience in embedded systems, I joined a discussion forum hoping for meaningful discourse. However, I quickly realized that the level of discussion didn’t meet my expectations. The integration being discussed fell short of production quality, and I found myself disappointed by the lack of depth in the conversation. While I appreciate the forum’s appeal to hobbyists, I yearn for discussions with fellow professionals who share my background.
3 Likes
@denverpilot are you sure you are not in the wrong place? I expect a real discussion about esphome environment actually happening at the githubs were the dev’s are… But if you are just here to rant this here might be the better place as the devs can just continue doing important stuff
My two cents on the debate: if you don’t like ESPHome showing the update each time the add-on updates, turn it off for each device you have. You DON’T have to update each time.
I could have, but that would leave out significant context about what I’ve been thinking about things like the acquisition of ESPHome and wondering why and how it affects the project, as well as wondering aloud a bit about the project’s goals. As well as their goals for the forum.
The words listed were the words intended. But thanks for the judgmental proofreading, I guess? It wasn’t requested nor on-topic for the thread. Is that your “thing” online?
I see no reason you replied at all, really. Have an architectural comment or two to add to the thread content?
Not writing formal papers here nor critiquing them. It’s a discussion forum. Informal thoughts style is plenty fine.
Feel free to discuss the topic or spin that scroll wheel like the wheel of fortune… I’m good with exactly what I said. Cheers.
So, you expect no discussion of architecture choices at the forum. Ok. Got it.
Not sure why you’d think that. Some unwritten rule I missed somewhere?