A broken core integration can still be fixed and used as a custom component (it will override the core integration) while you are waiting for the official fix.
2 Likes
If you able to track branches/MR and find the ones you are after, if you want to extract code to create custom integration, if you agree with tracking changelog later to remove the custom integration when merged with core etc (incl possible data transitions etc)
I think we can agree it’s still workaround. I suppose you are getting fun with doing workarounds over workarounds. I’m not. To me it sounds the same as “write a fix yourself”.
IN general it’s not bad idea, seems an infrastructure is prepared for it. But its execution shouldn’t require skill and additional effort from an user. At the end in this thread we are discussing making the user’s life easier.
So we may back to this idea once the system will be able to cover it automatically.
Anyway mentioned modularity requires to be supported natively in order to improve quality of the HA (less bugs, quicker fixes delivery)
One way to slow the pace of updates/releases is be careful to not install “dot zero” major/minor releases. Wait for a few patch cycles until “dot three” or “dot four” release comes out, to avoid too many issues.
That being said, the single most important thing to do is READ THE RELEASE NOTES for breaking changes. Often, existing integrations will be significantly updated or even re-written, requiring configuration changes or manual update processes. It’s sometimes unavoidable.
1 Like
in fact it doesn’t slow anything. It just shift update in time a few weeks forward. But still it ends up with monthly updates one way or another. Yeah I know I’m nitpicking.
What is more important, there is no policy that all bugs introduced in a major version are fixed untill its the last patch.
I’ll play Devil’s Advocate for a moment, although I don’t want to come across as a whiner. I’m just a dumb user, not part of the development team, and I greatly appreciate all the work that’s gone into HA. Having said that, here goes:
I’ll use my current situation as an example. I have three Honeywell thermostats. Without heat, my pipes will burst and everything else in the house is ruined. This is not just a hobby; I need to know their status when I’m away.
8.0 broke the Honeywell integration. Not sure why it was re-written; it was working fine before. Due to inadequate testing (the developer only had one thermostat) it didn’t work at all for any more than one thermostat in the home.
The developer jumped right in, and with help from other users managed to produce and test a fix. That fix found it’s way into one of the point releases. But after a while, another bug was found. If HA ran for 48+ hours without a reboot, the Honeywell server gave a rate-limiting error and stopped communicating with HA. Somewhere in the process of fixing that bug, users started reporting an inability to adjust the thermostat set temperature.
We’re at 9.6 now, and no end in sight. I can’t upgrade and take advantage of all the new features because this core component is still broken. The developer is doing their best and I appreciate all the effort.
To me, it’s a systematic failure. Why was a poorly-tested core component updated and rolled into the production release? Why is there STILL no reference to these THREE problems with a core component in the “breaking changes” list? Why is there no way for the average user to back out the change for this one failing component?
Again, nothing against any individual developer. Bugs will occur and fixes will be frustrating for users. But there are ways to mitigate the pain.
There is. You load the last known working version into the config/custom_components folder. Despite maxym’s bemoaning it’s not actually that difficult. I ran the depreciated BoM weather forecast scraper for far longer than I should have (a better version was released, though it is not yet in core) this way.
Because breaking changes are not a list of issues. They are a list of changes you must make to your config.
2 Likes
I had a somewhat less troublesome experience with a few different devices over the last two years:
a) Ecobee thermostats - I could never really determine what was happening. But upon installing an update release, I had to delete and re-create my integration on the Ecobee website. This happened two or three times. It was annoying, but easy enough to correct. It’s been quite stable since then.
b) Alarm Decoder security system interface - Completely MY FAULT for not reading the BREAKING CHANGES section of the release notes. Once I did that, I was off and running. In this case, the integration had been re-written and greatly improved, and required configuration steps to re-define the monitoring zones.
c) LG WebOS televisions - originally required completely manual configuration, and the breaking changes were definitely improvements. It required some minor changes to the wake_on_lan value and formatting.
Nothing entirely difficult, just ordinary changes, updates, and “growing pains”. It all comes with the product, free of charge. 
Thank you. Is there a write-up somewhere explaining how to find and load the last known working version?
As for breaking changes, I guess I misunderstood. I kept seeing people say you should read them before updating, to see if there’s anything in your system which might be be affected.
So, where should I go to find out if anything I’m using is broken in the new release, before updating?
Thanks to everyone who has commented, my original comment may have come across as completely negative. It was not meant to. HA is a wonderful collection of software components that I have gotten a lot of value out of and it has made my house a safer and smarter place to live. One of the concerns I have is that I only have one instance of HA running (production) and so all changes are applied to this and has resulted in various problems in the past. I am investigating how to build a test system without interfering with the integration to my zigbee network and still have a representative HA instance for testing. This will mitigate some of my concerns.
I will always applaud the developers for the continuous amazing work they do on Home Assistant. They really are building a world class system.
That said, I wish there was a moratorium on new features until the database is fixed. With more and more new integrations (like the energy dashboard) relying on the database, it is no longer acceptable for the database size to grow out of control due to inefficient data storage. And with valuable data now being saved their (energy monitor, long term histories), just dropping the database is not going to be a great option when it grows out of control again or gets corrupted again.
4 Likes
I run a production and a test instance, which both have access to the ZigBee network. For this you need ZigBee2MQTT or DeCONZ (there are some workarounds for ZHA as well as far as I know), because then HA is ibdependent from ZigBee and multiple machines can access the ZigBee network at the same time.
1 Like
No, there’s also nothing special/complicated about it. Set up HA on a different machine or spin up a separate VM, setup all the integrations you have on the first machine, copy your config and that’s it. What would you like to know or where are you unsure?
And, if you skip major releases, read the Release Notes of all missed major versions too.
I would add : point all your HA instances to the same mqtt server. At least, that is how I do it.
1 Like
Couldn’t agree more. Also transitioning from HomeSeer. HA is a significant step up from HomeSeer to be completely frank
Thanks @Burningstone I have Hassio installed on an intel nuc and love the supervisor function, so would like two instances of Hassio but unsure how to keep them separate. I did install HA as a docker container but its not the same.
In the apocryphal story Bill Gates reportedly compared the computer industry with the auto industry and stated: “If GM had kept up with the technology like the computer industry has, would all be driving $25.00 cars that got 1,000 miles to the gallon.”
In response to Bill’s comments, General Motors said If we developed cars like computers,
-
Your car would crash twice a day.
-
Every time they repainted the lines on the road, you would have to buy a new car.
-
Every so often a left-turn would cause your car to shut down and refuse to restart, and you would have to reinstall the engine.
-
Apple would make a car powered by the sun, reliable, five times as fast, and twice as easy to drive, but would run on only five per cent of the roads.
-
New seats would force every-one to have the same size butt.
-
Occasionally, for no reason, your car would lock you out and refuse to let you in until you simultaneously lifted the door handle, turned the key, and grabbed the radio antenna.
-
Every time GM introduced a new model, car buyers would have to learn how to drive all over again because none of the controls would operate in the same manner as the old car.
Jump to aerospace technology:
None of us would let our family get on a plane run by Home Assistant, but we all as individuals generally get on that test flight once a month. We learn from that breaking changes. This is bleeding edge stuff, or as close as many of us get.
To borrow @CaptTom roller coster analagy. Scream “Are there too many new features being introduce, too quickly?” if you want to go faster.
4 Likes
Running Home Assistant OS (the term hassio had been deprecated more than a year ago) directly on the NUC takes away the possibility to have multiple HA instances on the same machine. You would need to install a hypervisor like proxmox and run separate VMs for each instance. That’s how I run it on my NUC, it’s way too overpowered for HA only.
If you’re still using the default SQLite database, it’s time for you to switch your recorder over to something more capable. HA ships with SQLite as the default out of necessity so that the various install types can run on all machines - there’s nothing stopping you picking a ‘better’ database if your setup is pushing the capabilities of SQLite.
MariaDB is popular and easy to set up, and you can find instructions for pointing your recorder at a new DB here: Recorder - Home Assistant