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
It was “how can I automatically update Home Assistant?”
Didn’t go through this entire thread, but you could run HA in a snap. That would auto update and probably wouldn’t break as much.
What is a “snap” ? I run HA on a raspberry pi currently.
Snap is an Ubuntu package manager.
Using it won’t reduce the number of breaking changes in HA, and it’ll stop you from downgrading if you need to.
If you really wanted to auto-update HA itself there’s less bad options.
Well, snap is distribution agnostic, you can run it in a pi.
Personally, I run docker on Ubuntu. Not a fan of snaps.
I have the same issue - I already have a widget on my loungeroom dashboard to show me when any of the os elements need to be updated, but I also find it frustrating as the version needing to be updated immediately disrupts the integrations into Phillips Hue and Grid Connect meaning I can no longer switch my devices on and off via the dashboard without updating.
I also think the ability to automatically update would be great, I seem to be updating one thing or another once a week - which is also very frustrating for my partner who doesn’t understand how to update meaning some of the lights can’t be used if I’m not available to update.
Sorry, I didn’t read the entire thread, but if people are still looking for a way to automatically update their Home Assistant installation, there’s a service for that:
You can combine that with updata availability entities (and maybe a 1 - 2 day delay to skip faulty updates) like already mentioned by others.
Also be aware that you could end up with a Home Assistant installation that won’t start anymore. But to be fair, the same could happen if you fail to find that vital hint in the change notes and update manually…
Not updating things results in the same problem. Since this is running on a server in my own network, exposed to the larger internet, I’d rather have occasional updates break it, than have it break from not being updated (and risk security breeches).
I believe someone gave a detailed guide somewhere on this thread on how to enable automatic updates. But I can’t find his now and am somewhat reluctant to read through the now many posts on this topic to try to find it? What would be truly helpful in this case would be a Wiki that everyone could refer to? Is anyone up for making such a Wiki?
I get there is a significant faction here that believe (with some zeal) that no one should be allowed to do automatic updates under any circumstances. But I really do feel this zeal is misplaced here. Sometimes things break anyway (although much more rarely than in the past), whether we read the notes or not (and many of us don’t). But usually it’s just a case of waiting for the next update to fix them. So as has been repeated ad-infinitum here, if you don’t like automatic updates you should simply not enable them. If you have taking a snapshot enabled before you update, then even if things do go wrong, then rolling back an update should be trivial. So again, any objections don’t seem to make a lot of sense.
1 Like
You can write automations using update entities
Ok, I’ll bite. Seems a lot of people are looking for a step-by-step on exactly how to enable automatic updates. I was one of them, so I spent some time today and figured it out. I’ll share the simple steps below. This is for HASS OS 10.5, not sure if it will work the same way on other setups.
Steps
- From the Dashboard, go to Settings → Automations
- On the lower-right, click the Create Automation button, then click Create new automation
- Click the 3 vertical dots at the top-right → Edit in YAML
- Paste in the YAML below and hit Save:
alias: Automatic Updates
description: Automatically keep HA components updated
trigger:
- alias: When any HA update is detected
platform: state
entity_id:
- update.home_assistant_core_update
- update.home_assistant_supervisor_update
- update.home_assistant_operating_system_update
to: "on"
action:
- service: update.install
target:
entity_id:
- "{{ trigger.to_state.entity_id }}"
data:
backup: "{{ trigger.to_state.entity_id != 'update.home_assistant_operating_system_update' }}"
mode: queued
That should be it! Next time there’s an update, it should automatically and silently install in the background. The HAOS update does not support backup: True so when that’s the trigger, the Jinja template sets that flag to false. Keep in mind all the caveats mentioned above: Always have good backups, snapshots, or other methods of recoving in case an update breaks your system.
One thing I am not sure of yet is how to add a safety delay so e.g. it waits 3 days after an update is released before installing. Not sure that’s possible with the built in automation framework. If anyone knows how to do it, please share.
1 Like