Updating HA..Good..Bad or Ugly

Last night I had a revelation…

ChangeMyMind

1 Like

The only good reason to update is if you need a new feature (or the very rare security fix).

The issue with not updating every release is if there is a new feature you need in, say, 6 months, then you can’t just install that new feature…you have to install every core update for the last 6 months to get it. And then you have to deal with all of the potential breaking changes in those last 6 months all at once.

I guess you need to decide if that strategy is good for you or not.

4 Likes

If you want a quiet life, I’d propose updating on the .3 / .4 release of alternate months.

Read release notes for both updates and check the forums. If there’s a nasty, wait until you have time to fix/replace.

But don’t ignore and leave for another release, or two, or three, or however, until you have time - it’ll be worse.

I’m not arguing for or against updating… it just a random thought experiment I was working last night!

That said…“a new feature you need” … then it makes sense… but if you’ve got what you need then why expose yourself to the hassle… and potential down time.
"you have to install every core update for the last 6 months "… if you watch updates then you could track the changes and wait until the change has matured before moving to use it.
The developers of HA are a prolific bunch (hats off) doing great work… but if you dont need ( or are comfortable with your current state) the enhancements are lost. I’m never gonna use half of the cool stuff in HA…

Just random thoughts…

There is no “set and forget” in any software. You always will run into stuff . Be it the main software security fixes or underlying requirement changes ( your 3rd integrated software, which is main thing for HA) The only case where you don’t update is unmaintained software ( in other words dead software)

1 Like

The only thing I have seen is that when you update after x months, a lot of things may no longer work (as you expect it) so that might bring a peak load to repair…but imo the effort to do in-between updates/fixes is higher

As long as you and no-one else changes anything around it you’re golden. Maybe keep it off the internet.
Just remember that change is harder the longer you leave it. In software and in life.

you have no control over the ‘no one’ unless you dont have any integrations or built the integrations yourself.

If you have been in any industry for any length of time you know change is inevitable and frequent maintenance is absolutely necessary. I assume all of us maintain our cars and houses at frequent intervals to keep them performing at their peak. With software, which is orders of magnitude more complicated and fragile than cars, frequent maintenance if very important for anyone wanting to keep up with the times and their system at peak performance. Heck, even nature performs maintenance continuously.

Think of industries like energy, construction, military; maintenance is frequent and where the bulk of the effort goes.

Therefore if you really want to have a top performing HA, monthly maintenance is a must, even if you think you do not need it. A minimum borderline interval should be a quarterly update.

The common saying: “if it ain’t broke don’t fix it”, has never worked for any industry at any time (ask the British car industry as they have experience on this matter); if this statement was true we would still be living in caves.

1 Like

The cave in wouldn’t mind, but getting up to fetch my breakfast outside any day, the horror…:yum:

Do- not always agree, the "industry’ pushes to maintenance frequencies just to create turnover. Not saying one should not do maintenance at all of course…just look at what you need, where your risks are and then act.
Till date… my “if it ain’t broke don’t fix it” saved a lot of shxt … everyone his opinion of course

But you’ll never know what you “need” in the future…until you need it (some updates to the things you have or some new thing that you never thought of before it came out). Then you’re stuck.

Apples and oranges. Unless we are talking about planned obsolescence (which I think we can agree is a bad thing), maintaining a car is unavoidable due to wear and tear naturally occurring with mechanical systems. Software breaking changes (not bugs) are intentional, they’re not unavoidable at all. Someone intentionally took that decision to generate that maintenance workload for others. Sometimes there are good reasons to do this, sometimes not. Most of the time there aren’t.

On the long term I do agree though, there’s no way to avoid updating. There’s things like support, long term security patches, hardware incompatibilities, etc. But we’re talking years here. Updating from a 2021 to a 2022 version on a yearly cycle should be entirely smooth. At work, for example, we have a 2 year update cycle for Visual Studio. We never encountered the slightest problem, ever. With HA, it can break if you simply wait 2 months.

1 Like

You make some good points, however, domotics platforms such as HA, has a plethora of moving parts and hence dependencies, which is why it is so difficult to always get everything right.

VS has a narrow ecosystem and hence does not require as frequent updates. HA has a much wider ecosystem and a lot of fast moving parts and should be looked at more like an operating system like Windows, MacOS, Linux, etc.

HA, compared to other open source projects is, IMHO, doing a fantastic job. One thing most people forget HA is a technical project better suited to people with software engineering skills, but which is striving to make things easier for the technically minded consumer. However as with any technical project a certain level of technical skill and willingness to put effort to keep things updated is required.

“With great power comes great responsibility”

In the technology world things are moving fast and “if you blink you’ve missed it”. Therefore intentional changes are welcome because they move the ecosystem forward, keeping up with a fast paced world of technological change.

You are vastly exaggerating the complexity of this. Home automation platforms are actually pretty simple compared to some industrial process management systems. Home Assistant is pretty much a core with lots of ‘kinda but not really’ plugins (integrations) floating around it. If the project was designed that way, the core could be kept very stable and the plugins could adapt to changes and be updated separately as needed. This has been discussed ad nauseam. The core devs just don’t want to do it that way. But that’s a choice, not a technical necessity.

An OS is orders of magnitude more complex than HA. It’s not even in a different league, it’s an entirely different world.

Hell no. If I have a production system my home depends on, I want something super stable that doesn’t move one little bit unless I tell it to do so. Not something that changes every 5 seconds and I have to run after it.

2 Likes

Good discussion. Obviously HA has a lot of developers, all wanting to get their updates rolled into the next release. Hence lots of releases, with lots of changes. That’s one reason I went with HA; I knew there was an active development community.

That comes with some negatives, too. Not all of these changes have value to any given user. I’d go so far as to say most changes are of no value to most users, and somewhere between mildly irritating and downright damaging to some portion of the user base. Occasionally there are changes which break things or cause frustration for a large percentage of users.

What I don’t see is a lot of users thrilled with each release. I think a good metric to publish would be how many user-submitted feature requests or “WTH’s” are included in each release. Frankly I don’t know if any of those are ever included, or they’re just ignored by the dev team. It seems none I’ve submitted or voted on over the years have ever been included.

Maybe that’s just my perception. Maybe there really is an effort to work on what the users are clamoring for. If so then it would be a good idea to publicize that. I know I’d feel a lot better about each release if I felt that people who use HA had actually asked for some of the changes.

1 Like

the issue with the effort you need to spend for fixing HA after an Update is most probably due to ‘heavy’ customization - either in custom cards, custom components or themes.

I’m running HA a while now… but I haven’t had really bad issues with all the updates over the last years.

Most of the time, when things did go wrong after an update was, when one of my addons or a custom integration was affected - and it required a fix from their maintainers to get thing back to work.

And - I can’t blame the Dev team for this.
And usually, it only happened after an “OS” update.

Since these things happened, I’ve changed a lot on my setup.
I’ve replaced many of my Addons and run dedicated containers for them now.
So, an HA Core - or even OS update will not break these.

Custom componants can still crash after an update, but I will implement an evaluation system within the next weeks, where I will test any new release to see if it will break any of my custom components.

I think, what’s working in the industry should also work for a productive environment at home, which will slowly become a product that should work reliable…

Yeah many were included. Here’s the list for the 2020 WTH. I agree though, this could be communicated better in the release notes.

1 Like

There are breaking changes in literally every release of HA.

of course you are playing the odds on whether you will be affected by one depending on the CORE BUILT-IN integrations that you happen to use.

it doesn’t happen often for me but there have been a few months that I had to work to update for those changes.

Those odds only go up the longer you wait to update.

New potential user evaluating HA for a project.

Is there a core API that’s guaranteed to be stable across releases? It will take some work to integrate a bunch of my legacy systems into an automation framework, and I’d prefer not to be signing up to redo the integration work every quarter.

Based on this I’m now somewhat leaning toward an MQTT-based approach where each subsystem gets its own subcontroller with an API I control. But that’s also more work - and a lot of RPis that are out of stock everywhere!