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.
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.
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.
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.
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
Hi @mono, totally agree, I migrated to Mariadb some months ago, it improves the responsiveness of HA and my next project is to implement graphana.
I am going to say, no.
HOWEVER… HA has many classes of users, using many devices, some of which are an order of magnitude from eachother in performance, using a vast and varied combination of integrations, and their experiences are bound to differ. Should something be done to make this easier on less technical users, or those running HAOS on low end hardware, where updates are time consuming?
I am going to say, yes.
The rate of development is high, and I do not think that should change, but eventually it will slow down as platforms mature… maybe… there will always be new platforms, new integrations, new devices, companies change their API with no warning, and so on.
I am not sure if the HAOS users would agree or not, but my suggestion would be to stagger major new features so they only arrive every other month, as a “preview” release, then have the next month release be the “stable” release. This could potentially reduce the burden for system updates, though testers and more technical users would easily be able to install every update if they wished.
There are obvious drawbacks to that type of release cadence, the main one is that the stable release will have a BIG changelog, and more breaking changes than the previous. It also would not directly fix issues like the Honeywell one, and it may very well prevent certain rare issues from coming to light until there are a large quantity of people installing the latest version.
I am actually quite curious what the opinions of both the dev team and the user base would be regarding an every other month stable cadence.
I did not find it to be negative, the forum topics for new versions are full of posts about things going wrong, and in some cases it is due to a dependency change required to add a new feature, or the company updated the firmware on someones device the same day, or whatever, and of course HA will take the blame until it is otherwise placed. The smarthome ecosystem is full of products aimed at non technical users to simplify or improve their lives (or at least they purport to…), so many smarthome users will simply not grasp the scale of work that needs to be done in a project like HA to support the things it does for a global userbase, even highly technical ones, unless they start looking at the code and its rate of change.
In the last year I have never had a DB issue, and at 7GB I do not think mine is “out of control” but it is more than double what it used to be after adding just a few sensors with high frequency update intervals, though I am fully aware of many users that needed to delete the DB, so I agree that something should be done, such as splitting the long term data into its own file, though corruption issues at the filesystem level will still be an issue, especially for people running on low end storage or SD cards.
It might not be something that is easy to fix without fixes at the dependency level that are out of the HA dev’s hands.
I moved to MySQL in 2017 after experiencing extreme performance issues with the database on SQLite. Which I found odd at the time because SQLite is very capable and quite often for single connection access more efficient than MySQL. But then, I looked at the database structure and immediately found the issue. (below)
It’s not so much about having a DB issue, though the possibility of DB issues increase as the size does.
The issue is that a relational DB engine is treated as a flat file.
For every state change, the states table gets a row added with the state, the full varchar name of the entity, a timestamp, and a big varchar lump of JSON containing all entity attributes.
It’s an abuse of varchar and databases.
Entity names should be broken out to a table and linked to the state change record.
Attributes should be their own table, again linked.
It’s the basics of relational DB design.
It’s also the difference of using 8GB to store 80MB worth of data. 
I am sure the developers would welcome a PR that does things properly, preferably without breaking existing users. 
I’d be happy to design the database but I basically have no Python skills so the I don’t think I’d be much help there. At some point though, someone is going to have to fix it if Home Assistant is ever going to be “set it and forget it” reliable and performant.
This thread keeps pushing my HA hot buttons. I really am a big fan of HA, but…
Yeah, the DB implementation is a set-up for failure. The DB design sucks, and if SQLight is so awful, why is it the default? And since it is the default, why is EVERY SINGLE state change and event logged automatically? And if the user has to go in and exclude some of these, why isn’t there a way to do that from the GUI? And if every user has to learn SQL and learn how to analyze the database to find what to exclude, why isn’t that in the installation instructions?
Honestly, sometimes I think these decisions are a deliberate attempt to keep the uninitiated from using HA. You’d think developers would be proud of this fantastic project, and want mere mortals to enjoy it.
Based on some of the comments, it appears people forget that the software is built by volunteers. If no one is interested in fixing or enhancing something, it doesn’t get done. It’s as simple as that.
Like it or not, the same is true for the paid employees of Nabu Casa. What they fix or create next depends on what interests them.
Feel free to submit PRs or Feature Requests because complaining about what developers do or don’t do is not just unproductive, it can be counter-productive.