Easier way to update firmware?

ESPHome
41

Never said I couldn’t. Said the update process itself is silly and severely inefficient.

Your Linux distro doesn’t rebuild from source continually unless you’re really into watching it do that, like Arch or Gentoo.

Neither of which are embedded systems nor consumer friendly products.

They’re completely fine as hobbyist toys. I have been under the impression Nabu Casa is trying not to be a hobby toy product. Perhaps that’s mistaken. Perhaps it’s what they want to be.

I have no idea. Thus the initial post.

I had some time to discuss on a discussion forum, supposedly about the “product”.

42

Had to ignore last 15 posts…

Has anyone actually found a solution to this other than not updating? That doesn’t quite fit with the whole Continuous Delivery philosophy. I would love it if the “Update all” button in ESPHome dashboard worked as intended. However, as others pointed out, it starts by updating 2-3 nodes and then just hangs.

I have been updating them manually ad-hoc but that’s really annoying…

43

It seems to me this is why someone invented this program called “make”. It uses rules to only build the files that are needed. But it required someone to write a Makefile that includes the rules.

It seems what’s needed is an overhauil of the build system.

Compaining about that state of open source code is OK, but it seems implite to complain and not offer to help.

It is best to say “the current code sucks, I’ll fix it.” but not polite to say “it sucks, someone should fix it.”

44

Pfft. It’s only semi open source. People are paid to work on it. Plus it’s not my project. And the statement is still exactly true. Here’s detailed items.

  • NOBODY in the embedded systems pro world ever distributes source for embedded devices. (But ok fine. If you’re going to, make a proper build system, see below…)

  • NOBODY builds that source on the customer system. (The most ridiculous part, really. From a company selling underpowered hardware as the build platform??? Seriously??? No one measured how long a full update of 100-200 devices takes and went, oh… this sucks… or limited the release cycle because of it?)

  • NOBODY rebuilds modules unnecessarily for devices that don’t even need a rebuild just because the version number of the upstream project rolled. (Only one item in the latest release notes even affected half of my devices. The integration has NO CLUE and an update all rebuilds every device binary. For no reason whatsoever other than a version number change.)

  • NOBODY builds a build system that makes a new directory and builds the entire tree every week-ish. (Notice the release notes for the last dot version? Four completely optional items, not a single one regression tested, single dev approval? Yeah, let’s make every HA system running the integration earn users that they’re out of date for that silliness… repeat this as a mantra for embedded development: Users shouldn’t need to read release notes to know the update system is building things unnecessarily adding significant risk something will go wrong.)

  • NOBODY turns on features in the code that break updates because adding them runs the device out of flash space. (Forced addition of API encryption. No documentation on how to remove it.) None of my devices at adoption had API encryption. I don’t really mind until it fills available flash, but if it does that the build system needs to know how to upload minimal firmware and then recover by uploading the larger file. It also could gzip the file and compare to the available flash space — that information is available from the device. (If there’s a way to turn off forced API encryption and maintain connections to the device or force a gzip, feel free to point to the documentation showing it.)

  • NOBODY rebuilds the same tree over and over for the exact same devices. Build once, package in config changes. Individual binaries per device doesn’t scale. 20 devices of the same architecture and hardware is a rebuild of one, maximum… and and modules that change because of configuration items. Rebuilding the serial library — or network library — or whatever — every device, is pure silliness.

Except… HA and this Integration. Haha.

There’s no real fixing it without a complete refactor, frankly. I thought it was a joke, at first. The more I dig into it the more broken it is.

It’s fine to be lazy. It also means it’ll get called out. It doesn’t ever mean the “customer” or user is responsible to fix it.

Now brass tax. Do I care? No. Not further than discussing it. All these devices will happily run Tasmota which deals with all of this nicely. TasAdmin add-in and away you go…

Measured it. Test system to update the latest ESP release with four completely optional updates, none critical, one lowered flash size on a couple of devices by 180K is all… over an hour.

Same style devices on the other test system running Tasmota? Two minutes including reboot time. Three of the devices even needed to go up a major version.

Obviously my testing is complete. Heh. There’s no reason to stay on ESP with this integration being this wasteful of time and resources on what’s an automation platform for embedded tiny devices.

Just figured smart folk here would appreciate the technical analysis. But it’s bad. Really bad. Like ten orders of magnitude bad, objectively measured with real numbers and times.

Not emotional about it. I’ve seen far worse sold to paying customers and sat on change control boards that stopped some of them. Haha. Not exactly new at this, as mentioned before.

Some things are just architected poorly and yet wildly popular. See Microsoft. Ha. Shrug…

Life is just a bowl of cherries… cheers. Good discussion. Brings up that broken attitude that users are supposed to fix things. Nope. By definition they aren’t qualified to do so. Open source continues to pretend everyone is a dev… which I’ve realized over nearly thirty years is pure silliness wank.

You don’t WANT neophytes coding for embedded devices that might be hard to access and are critical for home automation. Not without strong peer review, regression tests, and proper controls on what becomes a user “warning”… big orange ball that says “you need to upgrade!!’” — what do you think the average user is likely to do?

UI/UX. It’s important. Two minutes vs an hour of compiling in a non-dismissible window… come on. Clearly that’s not bright. Put it in the background… at least… haha… wow… bad. Makes no sense at all.

Was fun to test ESP. I hope it catches up. Probably turn the test system down now and flip those devices back to Tas… May keep it… not lots of personal time avail for that level of testing and it’s so far behind it becomes a “I’ll check back in a year or more” thing for me, really. Especially with as mature as Tas has gotten.

Have fun y’all.

45

Still the off topic continues. Maybe a @mod can split the topic apart so Nate’s posts don’t spam this topic?

I make use of the esphome cli and “update-all” works as intended for me

Their are people improving things for everyone and their are people just complaining without any intentions to make things better…

46

Now that sounds more promising. Would you care to elaborate? I use an ESPHome addon directly from HA. How can I access the cli for it? I suspect SSH?

Moreover, is there away to bring it out to the frontend using a script or something?

Thanks.

47

Too late.

I didn’t read all of the posts because most are repeats. tl;dr.
My suspicion is that the OP is expecting a polished, finished product with occasional upgrades. What he doesn’t grok is that Home Assistant is a DIY, community supported constant work-in-progress. The day it becomes an off-the-shelf, grandma can install it product is the day I look for another IOT ecosystem.

I never use “Update All”. I have almost 100 ESPHome devices and invariably there is always one or two that won’t come online after the reboot (at the end of the upgrade). And in all respect to Mr. Murphy, it will be the least accessible device in the house.

I have the firmware update disabled for most of my ESPHome devices, and I never see an update prompt for them. I do have a few where updates are enabled and if the release notes for an update look like they should apply to other devices, I can update them from the ESPHome sidebar panel.

firmwareupdates
firmwareupdates596×724 50.1 KB

1 Like
48

The decision to update or not totally depends on the release notes…

If it has a security fix…install it…as it might make your installation safer (depends a bit on what the fix is, and how your network is setup)

But, if it just supports one (or more) new feature(s), which doesn’t apply to your device anyway, it really doesn’t matter if you update it or not, the re-compiled firmware will be identical to the old one, except it has a new version number :thinking:

1 Like
49

I don’t think that the frequency of the updates is the problem here. It seems to me that reduced frequency was being discussed as one of the ways to make them more manageable.

In the very first post the OP is actually asking whether there’s a way to automate these updates or make them less hands on. That’s also how I ended up here. It seems that the answer to the original question is no, there is no way to update all nodes easily or automatically.

We’ve already established that there is a way to NOT update and forget about it. That’s not what the question was asking though. That “Update all” button is there for a reason after all and it’s broken. Everyone’s situation is different. I don’t have 100 ESPHome devices, the 10 that I have always update without any issues and I’m also happy to accept the risk that one day one of them will not. I will gladly take that risk over screening ESPHome changelogs every week. This is my preference; yours might be different.

However, now that we’ve established that there is no way to update all nodes easily we can accept that NOT updating them may be the next best thing here :slight_smile:

1 Like