How Do I Completely Block All Home Assistant Updates Forever

I was still cleaning up the mess from the JS Z Wave “update” that broke hundreds of automations in my house, when the latest “update” broke all the Sonos Scripts I use to play music every day. What pushed me over the edge learning that the devs KNEW this was going to break existing functionality, didn’t care and pushed the code out anyway. You think I’m making that part up, I’m not, here’s a screenshot:

Here’s a link to an archived version of the original
https://archive.ph/16ZW1

I’m tired of other people taking things that are working perfectly fine, and “updating” them so they stop working. I am 3,427.9% OK with never getting another new feature, if it means I won’t wake up to discover someone else “helped” me with an “update” that breaks things I use on daily basis, and forcing me to waste hours of time fixing something that wasn’t broken and didn’t need to be fixed.

Is it possible to make it so home assistant never updates again. I want to block every hostname or subdomain on both my pihole and my firewall, so some devs programming doesn’t see my home assistant is multiple versions behind and decides to “help” me by deciding to “update” for me on it’s own.

Once I’ve blocked updates, I won’t come here in pissed off mood with a bad attitude because someone else broke my stuff.

2 Likes

You simply don’t install the updates. It’s not like “Windows Update” where it’ll automatically drop it on you late at night.

It’ll gripe, it’ll tell you the updates are available. Just don’t install them.

4 Likes

Yep, updates are entirely voluntary. Resist the urge to click.

2 Likes

As long as you are that fine with never installing a security update that prevents hackers taking over your home too, that’s up to you.

Monthly. Updates are released on a monthly schedule.

That tag is to make sure the change is documented in the release notes. Would you prefer these changes were a surprise?

I like surprises, but not that sort.

3 Likes

If you are pushing out a change you know is going to break existing functionality, why are you pushing it out? Twenty years ago when I first started developing eCommerce websites rule #1 was you don’t break existing legacy functionality, because it could literally have cost the company millions of dollars in lost revenue.

I am still trying to recover from the JS Z Wave update, it’s going to take me months to get everything working again.

Hackers are not the threat I’m worried about, developers “helping me” with “updates” that have wasted hundreds of hours of my time are the people I need protection from.

To improve functionality and/or stability. It’s not done to spite you.

Wait so are you honestly saying pushing out code that breaks existing functionality, is done to improve stability or functionality?

How exactly are you improving something by breaking it so it stops working completely?

That’s the exact opposite of improving something.

Feels like I shouldn’t have to explain that if I’m being honest…

Yes.

Zwave has improved to the point that I may now consider using it again. This has come with some upgrade pain for existing users but overall it is now a much more stable and well supported solution.

Can’t comment on Sonos as I’ve never used it but assume the reasoning was the same.

The JS Z Wave Migration broke hundreds, yes hundreds, of my motion based automations.

Additionally it is far less responsive, because I have to walk farther into the room for it to activate.

On top of that sometimes it doesn’t work at all, and the sensor gets “stuck” in the on/off state.

The hardware was exactly the same before and after, the update “broke” all my motion based automations so they have to be reconfigured. Once I do that that don’t work as quickly, and sometimes don’t work at all. Most people would not consider that an “improvement” at all.

I don’t know how you can honestly think "breaking’ things or making them slower and less reliable is an improvement in any way. If someone who worked for me pushed out code that was this “helpful”, they would be helping themselves to an unemployment check…

You are being completely unreasonable to the development teams.

I am a ‘generic user’ (granted a fairly technical one) and I have been using HA since September. I also happen to have a 20 year career in IT software support.

First - code must be updated. Period. Personally I won’t use code that’s not actively maintained. Guess what. Code updates break stuff. Security fixes break stuff more often than not. This is not unique to HA and in fact most release management activities tend to deal with how bad do we break stuff and how do we avoid such things. In some cases it’s just not possible to avoid.

I also tend to have some issues with how HA code is maintained and released too but there’s one significant point here.

You do NOT have to install any updates. Period. Ever. If you don’t install it - it doesn’t install itself.

Also the loss of OZW/ZWave has been Known for - at least - since I started using HA in September. In fact, it was one of the first things I noted. You’ve had that long (and more) to figure out how to perform the migration from one of the other implementations to JS.

When 2022.4.x pushed without OZW/ZWave because of depricacation you still did NOT have to install anything. You could sit and wait on a 2022.3.x version.

One thing HA does better than most is notification of ‘breaking changes.’ In fact, the notice you take issue with here is there specifically as a warning to folks in your situation to pay attention and consider if that breaking change affects you.

So I applaud dev for the breaking notice and the community for continuing to try to help people migrate. But I do not condem them in this case. It was completely avoidable. Either by working through the issue last year when it was first announced or holding off of updating. Either way no issue.

4 Likes

Please open an issue for this so it gets rectified.

Except for the Supervisor on a HAOS install.

2 Likes

Asking people not to break something that’s already working is considered being unreasonable to you? While I’m not a programmer I do write code, and I know if I break something it’s definitely not a good thing.

People use a smart home to save them time, energy and make their lives easier. If a smart home system is wasting your time, it’s not really smart, and it’s definitely not helping you.

You pointed to the solution for sonos yourself

Instead of storing the favorites in the state machine, they’re now available using the media browser via websocket API

Also, if you’re determined to use the rotting mess that the original zwave dev left behind you’re welcome to do so by staying with 2022.3.

I have about 30 scripts I use to play a specific playlists, I have them setup on a dashboard, and with one click a 6-8 hour playlist would play for the whole day while I’m working. Whatever change they made “broke” all the scripts, forcing me to take out my phone, defeating the entire reason I integrated it with my smart home in the first place. How anyone thought pushing out an “update” that broke things was acceptable is something I can’t wrap my brain around at all.

If I could go back in time and stay with the old Z Wave I would do it, unfortunately I “excluded” almost 60 entities, and “re-included” them thinking the “upgrade” would be an improvement, I have since learned that was an incorrect assumption, and I regret that choice.

Why people are defending the new Z Wave when it’s slower, and less reliable is mind boggling to me, I’m guessing there was some personal drama people found unpleasant that I’m not aware of.

zwave’s history has been well documented in the forum and I am not going to repeat what has already been said. You can search for it. But the code had no history for a very long time, and you have had plenty of time to switch, and to post issues if any arose.

zwave js, didn’t break anything, the old integration was removed and you moved to a DIFFERENT integration that is not compatible with your OLD integration settings. it’s called a breaking change, because things will not work the way they did previously or at all. you are notified in the release notes that things were done to add to, enhance, change or yes cause something to not work. I’ve been using HA for many years for the last few, it has been this way every single release. if you can’t deal with this, then revert to your backup and don’t update. alternatively feel free to move away from HA to something that suits you better.

@marketingdude In fact looking at your posting history, the zwave stuff has been posted about you before, and explained to you, in another thread where you were equally rude and called the devs incompetent and lazy. Has it reached time for your monthly rant?

1 Like

I put off switching because I knew it was going to break things, so I waited and gave it time for all the bugs to get worked out. I incorrectly assumed an “upgrade” was going to make things better, I am learning that was an incorrect assumption on my part.

This entire thread is filled with people telling me they it’s perfectly acceptable for an “update” to break existing functionality, over in the real world if you do that you get fired, or told your contributions are no longer wanted on the project.

However in Home Assistant land, people are applauded for breaking things, and recognized for their bravery in documenting the complete loss of functionality.

Feels like I’m in some bizzaro world nightmare where complete incompetence is recognized as attaining the highest level of enlightenment.

OK so fire the devs, uninstall HA and go and find a better solution. Go on, vote with your feet, no one will care.

1 Like

The nerve of me expecting developers not to keep breaking things that had been working perfectly fine for over a year…