Having backups makes such issues very easy to handle.
But yes it was/is an issue with wrong dependencies in the installation routine of HA. Shouldn’t happen, but is hopefully fixed soon.
I remember that core developers of HA such as @frenck and some others have had valid arguments that auto update also means auto breaking. However, I would like to report here that not-updating the core or HA version (not confirmed - it’s probable) during my month long holidays highly probably stopped controlling HACS integration of my B-Hyve valves and my garden is almost dead. I was once again reminded that cross checking of irrigation (including whether physical water is detected in soil) is crucial.
I don’t understand this debate. Or at the very least, I don’t understand people’s insistence in trying to convince others to follow their practice. The original question was “is this possible” not “should I do this”. Basically what I’ve seen in this thread is:
OP: How do I get pie shipped to my house?
Others: You shouldn’t even be eating pie, not unless you understand that it can make you fat.
OP: Okay…but I’m gonna eat pie anyway. I just don’t want to drive to the store to get it. Can I get it delievered?
Others: Getting pie delivered to you is a bad idea. It’s going to enable you to continue in your ways, which are bad.
OP: That’s fine. I’m going to get pie no matter what, even if I have to drive to the store. I just don’t want to waste my time doing that. I want it delivered so that it’s available to me if I want it.
Others: …getting pie delivered is a bad idea.
What the heck?? Just let the user have their pie delivered!! As was mentioned over and over, OP is going to install the updates regardless of what the breaking changes are without reading the notes. I have worked in professional IT fields for nearly 20 years, working on Support teams, Help Desk teams, dev teams, and more and personally I never read release notes. If something breaks, I just roll back. It’s not that hard.
There’s several schools of thought, many of which have been represented here, including (but not limited to) “never update automatically or manually”, “update manually, but never auto-update and always read all notes”, “update manually but never read the notes”, and “auto-update, because I like to live dangerously”. No one opinion is “right” and everyone is welcome to run their system the way they wan’t. Stop trying to convince OP that your way is the better way. If they want to run auto-updates, and there is a way to do it, why not help them accomplish it? The worst thing that’s gonna happen is they’re going to brick their current build and will have to roll back. Which, if I understand correctly, is going to happen ANYWAY because they’re going to manually install updates without reading notes whenever they become available. You’re not stopping the outcome from happening by refusing to help or by trying to force them to live your ideal. All you’re doing is frustrating the user who just wants to automate their life a little bit. Which, by the way, is the entire purpose of HA. Just because there are parts of your routine that you don’t want to automate, doesn’t mean you should try and force others to live the same standard.
Also, whenever someone responsd with “no one is forcing you to do anything” I want just want to scream. If I’m going to run the updates no matter what, and you are refusing to help automate it even though you know it’s possible and you know how to do it, then you essentially are forcing me to do it manually. Because it’s going to happen no matter what. Doing it manually is just tedious and time consuming. If you want to read the release notes in their entirety every time an update comes out, then maybe you don’t care about tedium. Maybe you like spending the majority of your day on such dry material. But for me personally, I have better things to do with my time. I can run an auto backup every night, then run an auto update every night, and if I wake to something being broken then I can roll back to the previous day’s build. That is far less time consuming and headache enducing to me than reading every single note of every single release that ever happens.
In short, why not just let the man (or woman?) have pie delivered? It’s not harming you, they have a contingency plan in place for if things go wrong, and they’re going to be eating it anyway. Where is the harm, really? They understand the risk, and they’re gonna do it anyway.
(It should be noted, I’m not a dev and I don’t know how to auto-update. In fact, I only found this thread because I also was looking for a way to run automatic updates. Because, like I mentioned, I don’t ever read release notes and I have the means of restoring my previous builds. I also find manually updating tedious and time consuming, and want to find a way to keep my system up-to-date without the hassle of having to always come in and click the button.)
1 Like
Relax. People are gonna be people. No reason to get bent out of shape. This wasn’t possible to automate until recently.
Make an automation that uses the update.install service when an update is found from the update entity.
basic version
just updates home assistant
alias: Auto Update HA
trigger:
- platform: state
entity_id: update.home_assistant_core_update
to: 'on'
action:
- service: update.install
target:
entity_id: update.home_assistant_core_update
advanced version
Allows for any update entity trigger.
alias: Auto Update HA
trigger:
- platform: state
entity_id: update.home_assistant_core_update
to: 'on'
action:
- service: update.install
target:
entity_id: "{{ trigger.to_state.entity_id }}"
3 Likes
I like it. The only suggestion I’d make would be to send a notification before the install, to say what’s about to be updated. Then if something breaks after an upgrade you know that the upgrade may have caused it (and if something breaks and there wasn’t an upgrade, you know that too).
I’m using Scheduled auto-update for Home Assistant and have it set to only operate during a few hours each day (early morning). I also have a shutdown and startup automation that I use that sends a notice before shutdown and one after startup.
So, when I get up in the morning if I see a pair of those I know that either an update happened for my instance rebooted for some other reason.
1 Like
In that case, I would suggest you to create a toggle helper and use that in the pre-update actions to set the helper as true, and then in the post-updates actions to set it back to off.
Then you add to your startup automation t9 check for this helper and if it is on you can send a different message saying something like “the system restarted during the update process”. Also use your startup automation t9 set the helper off after sending the message.
Then you will know if it was the automation or something else.
Too complex?
Sure, I could do that, but I actually have a good idea of when my systems are going to auto-update since I see the update in the UI waiting during the day 
1 Like
I am new to the HA project (been just over a month) and have tried to keep current with core updates. It seems to be about every 3 days I see the (1) icon by settings suggesting to me that I should update. I have added the automation recommended just up thread (thanks for that!).
I can’t help but chime in to the debate: If the UI is presenting to the user that an update is available and highlighting it via a notification, I would assume as a new user that it’s recommended to take the update. After manually taking so many of these updates (and all without issue - thanks for the stable project and solid release process!), I can only wonder why there isn’t a simple way to auto update (which ultimately brought me to this thread).
I did notice an attribute on update.home_assistant_core_update: { auto_update: false, ...}. Does this mean an auto update feature is in progress (or already exists, just not in the UI)?
Thanks, Jeff
You don’t want this.
If there is a breaking change, you don’t want to spend hours trying to figure out why something in your system stopped working. It happened to me once. Since then I am reading the Breaking Changes in every update notes. Then I update.
2 Likes
It can break on a manual update as easily as it can an automated one. Personally, I don’t have time to read update notes. I’d be fine with one of
- Reducing the frequency of or disabling automatic checks for updates.
- Disable update notifications without updating. If you should be cautious before updating, then the application should not visually nag you to update.
- Making automatic updated and rollbacks a smooth process. Users have different setups, so develop and test recovery procedures to make sure they are simple, reliable, and well documented.
I’ll take any of these. Anyway, I see there is an Core OS 9.3 update pending. I’d read the release notes, but I have got to get ready for work. Since I don’t have time to read them, I’m pressing the update button.
Turn off the update entities.
Turn off the update entities
1 Like
Quite a long topic! My 2 cents.
I administer several HA instances for family and friends. I suppose us HA knowledgeable will say that HA is not for end users and thus they can’t benefit from all the cool things HA can do. If we say that’s the case then automatic updating is moot. We know what has be been done (although at least some built in push notifications of available upgrades would be nice)
I can say that with several instances to check in on I don’t always update them regularly. I came to this thread just because I was at a friends HA instance and I had not updated in about a year so I’m looking at going from Hassos 8.2 to 9.3 with corresponding changes in core and supervisor.
I will take and transfer full backups before doing core/supervisor upgrades. I mount the entire machine via sshfs and then do a (backintime) backup before hassos upgrades. That pre upgrade procedure could be automated.
IMO updating regularly is a good idea because frequent updates don’t involve lots of changes so less chance of FUBAR and any rollback is smaller. That said the “new” core versioning is kinda nice but is not semantic versioning. There is now no way to tell if a release has breaking changes unless breaking changes are always made at the new year?
Consider how npm (i.e. node) decides what to update. Patch and minor changes are not supposed to be breaking and npm will upgrade these packages. For major changes the developer must manually change the major version number in order to upgrade (and can expect breaking changes.
So currently there is no “minor-patch” auto updates for core/supervisor/Hassos. Maybe the devs aren’t interested in coding in any auto updates but no reason we power users can’t develop something. But I just wonder how “semantic” the versioning is and how we can identify releases without breaking changes solely by the version number?
1 Like
The version scheme is this:
<Year>.<month of release>.<patch number>
Patch releases never have breaking changes. If you find one it’s a bug and will be fixed in a new patch when reported. I can’t think of any exceptions to this. I guess maybe a significant security issue could put a breaking change in a patch but to my knowledge that’s never happened.
Every month there’s a new .0 release. These are major releases and always have breaking changes. It’s not a requirement that they have breaking changes but I cannot think of a single major release in the past 3ish years I’ve been using HA which has did not have a breaking changes section in the release notes.
So essentially auto updating patch releases - probably safe. Definitely safe if you use the “take a backup first” feature since in rare cases you hit a bug you can rollback.
Auto updating to the .0 release of the new month - never safe. I mean if you use the take a backup feature it isn’t too bad since it’s easy to rollback. But there are always breaking changes so things may break every month if you do that.
Also all this only applies to HA versions. Every addon has its own versioning scheme determined by the author. Every version may have breaking changes. Often they aren’t even in the release notes because the underlying software the addon is wrapping is what changed.
2 Likes
I think for HA every update is potentially a breaking one. That is because there is HACS and there are custom integrations, custom UI components, … It has been said before, but the HA team can’t test it all. Also most custom components are not checked against new releases until those come out. Nor are custom components tested in combination with all others. At least when users press the update button and see things fail, they are there to operate the system. And they had there fingers inches away from the link to the release notes.
I make it a habit to make automations in a way the house is still operable without HA. But there are some who are happy to for instance control chlorine injection into the pool with HA. should HA update while it is injecting chlorine and miss the call stop it, then bad things will happen. Simply a reboot caused by an update can break things by aborting automations, or by HA not being active while a critical trigger occurs.
Putting auto updates as an option in HA will make it a no brainer for most people to put it on. But later, when they build automations such as the one I described, they will not think about auto update dangers. So I’m happy people warm here about possible consequences. especially when the solution to auto update is there.
Just one silly example: how would you feel if you want to leave the house in a hurry and the lights and heating won’t turn off because some one just posted an update?
Yes but if you do the update manually you likely know that an update was the cause of a brokewn system instead of waking up to leave for work one cold morning and your HA is broken with no time to fix it.
those two by definition are mutually exclusive.
the auto update happens…automatically.
the roll back would need to be done once you figure out that the system is broken.
there’s no way for the system to know it’s broken if the system is broken and can’t run so it can’t automatically roll back because it’s not running…because it’s broken. 
That’s not really true anymore, that’s why safe mode was created. Even if the config is completely unreadable nonsense HA will still start in safe mode. Safe mode is obviously extremely limited in what it can do but rollback works.
1 Like
I’ve actually had safe mode fail once or twice too. But that was a long time back and things may have gotten better since then.
Well fwiw if HA didn’t start at all and safe mode failed too that would be a bug. Obviously that would be cold comfort to someone in that situation but HA should always start in at least safe mode.
I really don’t understand this topic, the question was: how to automate the update process or why I should or shouldn’t automate the process?
1 Like