Easier way to update firmware?

ESPHome
31

Exactly! And you write like one of our small ones - but with a little more punctuation :joy:

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. :star2:

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 :timer_clock:

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 :trophy: Since then it is possible to have reproducible success and no problems with amnesia (lost settings etc.). :rocket: Also the native api with encryption is something I would never exchange against mqtt :round_pushpin: 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 :muscle:

Some people are happy running Tasmota 5 on a wall switch - why not? :rofl:

2 Likes
32

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

33

Have you been drinkin’ :rofl:

2 Likes
34

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.

35

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
36

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
37

@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

38

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.

39

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.

40

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?

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
50

Has anyone found a way to make a dynamic button that updates ALL the entities?

I’ve been trying but I can’t figure out how to put a template in the entity_id field such that it renders correctly.

Was hoping I could put this in a package YAML…

template:
  - button:
    - name: "ESPHome Update All Firmware"
      icon: "mdi:update"
      press:
      - service: update.install
        target:
          entity_id: |
            {% set myItems=
              expand(integration_entities('esphome') )
              | selectattr("entity_id", "search", "firmware")
              | map(attribute="object_id")
              | map('regex_replace', find='(.+)', replace='update.\\1', ignorecase=False)
              | list
            %}
            {% for x in expand(myItems)| map(attribute='entity_id')| list %}
            - {{x}}{% endfor %}

But errors:
Failed to perform the action button/press. Template rendered invalid entity IDs: - update.s31_upstairs_radio_firmware - update.s31_livingroom_light_firmware - update.s31_front_entry_light_firmware - update.s31_end_room_radio_firmware - update.s31_snake_light_firmware - update.s31_freshwater_light_firmware - update.s31_basement_filter_firmware - update.downstairs_hvac_flood_firmware - update.bt_proxy_laundry_room_firmware - update.s31_kitchen_radio_firmware - update.s31_matt_bedroom_air_freshener_firmware - update.s31_snake_light_2_firmware - update.s31_lizard_light_firmware - update.s31_snake_light_3_firmware - update.s31_rodi_filter_firmware - update.s31_matt_bedroom_filter_firmware - update.downstairs_hvac_humidifier_firmware - update.s31_saltwater_light_firmware - update.s31_dehumidifier_bsmt_rear_firmware - update.s31_livingroom_filter_firmware - update.bt_proxy_garage_firmware - update.bt_proxy_dining_room_firmware - update.s31_kitchen_light_firmware - update.s31_dehumidifier_bsmt_hall_firmware - update.s31_garage_door_opener_firmware

And log:

homeassistant.exceptions.HomeAssistantError: Template rendered invalid entity IDs: - update.s31_upstairs_radio_firmware
- update.s31_livingroom_light_firmware
- update.s31_front_entry_light_firmware
- update.s31_end_room_radio_firmware
- update.s31_snake_light_firmware 
- update.s31_freshwater_light_firmware
- update.s31_basement_filter_firmware
- update.downstairs_hvac_flood_firmware
- update.bt_proxy_laundry_room_firmware
- update.s31_kitchen_radio_firmware
- update.s31_matt_bedroom_air_freshener_firmware
- update.s31_snake_light_2_firmware
- update.s31_lizard_light_firmware
- update.s31_snake_light_3_firmware
- update.s31_rodi_filter_firmware
- update.s31_matt_bedroom_filter_firmware
- update.downstairs_hvac_humidifier_firmware
- update.s31_saltwater_light_firmware
- update.s31_dehumidifier_bsmt_rear_firmware 
- update.s31_livingroom_filter_firmware
- update.bt_proxy_garage_firmware
- update.bt_proxy_dining_room_firmware
- update.s31_kitchen_light_firmware
- update.s31_dehumidifier_bsmt_hall_firmware
- update.s31_garage_door_opener_firmware