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.
2 Likes
Can you please include a line that creates a backup and that saves the last two known working backups also? I would also like all my apps to update too. Should there be an empty line at the end of the script? It also appears to have updated HA OS only and not HA core, after I ran the update. I think there needs to be a delay of several minutes between installing HA OS to give the update time to install, before updating the core.
I think you can either run it as a cron every Wednesday night and check if the update is n days old or run a save backup with that automation
service: update.install
data:
backup: true
So like this?
alias: Automatic Updates
description: Automatically keep HA components updated
trigger:
- 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
data:
backup: true
target:
entity_id:
- update.home_assistant_core_update
- update.home_assistant_supervisor_update
- update.home_assistant_operating_system_update
data: {}
mode: single
I just updated my simple solution a few posts up to simplify the trigger/action and account for the fact that HAOS upgrades don’t support backup: True.
Dear Fellow HA Worshippers/Regular Users/Other Users accidently reading this forum thread,
I work in IT operations for some years now with some experience in upgrading different systems - with both unattended (auto) and attended (manual) updates.
I have read through the thread and found multiple very good arguments. I also did see a very good/well written complain about the thread not going into the right direction.
I conclude the following:
In general I think We can all see the benefits and the downsides of the automatically installed upgrades. I am missing though the reason why people “religiously” opposing the idea of auto-update. Some posts have already hinted or mentioned the real issue. The issue is that they fear they will have more work supporting people (on this forum) with an enabled auto-update feature.
Why would they state this? Well if you think about it, the number of people regularly patching is most likely way lower then the number of people would use the auto-update. Based on this assumption the number of people creating posts would increase, because of the increased number issues presented as naturally people just leave the version as is.
To my knowledge it is not best practice to be always up-to-date, however it is also very bad practice to be far behind. In my opinion the .0-s should be skipped for most people (and should not even be available by default (only if beta is enabled)).
My recommendation is to be up-to-date starting .3 minor relases. Anything above that was safe so far (for myself at least). I would always skip .0, .1, .2.
As for the major releases there should be some alerts stating the conflict.
I manage several home assistants in different households and it takes way too much time (espcially if we include esphome upgrades as well), therefore I would very much welcome a feature like this. I would be happy, as these households are almost identical.
As previously mentioned I fully support this feature, but with some restrictions/considerations:
Upgrade order: I would create in the long run an order list. This list would determine the order of upgrades based on the actually available new packeges. Should Core be upgraded first or Zigbee2MQTT. This order list should be followed by all integrations. I am not sure if this can already be calculated by the dependencies specified in the integrations, but if not then this should be addressed.
Automatic backups: This is provided in the UI already (during manual upgrade), but with this new setting this should be continued to be provided
Update log: Update log should be clear. It should clearly state which integration is upgraded to which version and when
Linear upgrade: It must be ensured that only one integration is upgraded at a given time as based on mycurrent experience this is required
Notifications: The option for notification should be included as most of us hooked up some kind of messaging to the HA already.
In short the idea is great and I very much support it, but in order to make it available in the UI in a smart way, there might be some prerequisites.
Lastly looking at this thread I think it worth to mention that HA is really great software, but it lacks some features for real 24/7 operation.
I hope that in 2024 there will be some focus on unattended operation of HA (possibly even make it high available) as I think lot of people would benefit from this.
Merry Christmas
2 Likes
You can create an automation to update anything, in any order, with any output.
order doesn’t matter. You can build an automation to update in a specific order.
Integrations don’t have updates.
You can use log.log to in your automation, as well as persistent_notification.create.
Thank you! How would yo go about triggering the update only after midnight?
To be honest I am not sure how to combine the triggers. I know that a Time Trigger does exist, but I am going to have to defer to someone else on how to make an if (x && y) then z type automation…
I am not sure if its best practice, but worst case you could create a boolean representing the combined state.
Hello,
i do like the way of auto-updating. Like shown above. But is there a way to follow the idea of powerhosting to up-to-date starting with .3 minor relases?
Frank
1 Like
Really appreciate luckman212 sharing his example. Unfortunately, it does not work in HA OS 11.4. Maybe it does work if we modify this portion?
data:
backup: >
{{ trigger.to_state.entity_id != 'update.home_assistant_operating_system_update' }}
Either way, once I realized that the visual editor was powerful enough to keep me from digging too much into the syntax of writing the yaml from scratch, I created something similar from there with a few more conditions.
That doesn’t mean I wasn’t reading the documentation while I was creating it 
As petro shared here it’s all clearly documented if you want to write your own automation, script, whatever.
My outcome
Continuing with the example given I was able to create a single automation combining Core, Supervisor, and OS.
- It assigns a Trigger ID to each of the 3 triggers to differentiate them for certain conditional checks.
- It checks to see if the Core update is >= yyyy.mm.3 which I felt was safe enough to automate on considering I could not find a single month in several years where a .3 or > version was released.
- It attempts to create backups only in the cases of Core & Supervisor updates.
The full YAML
alias: Automatic Updates
description: Automatically keep HA components updated
trigger:
- platform: state
entity_id:
- update.home_assistant_core_update
to: "on"
id: "1"
- platform: state
entity_id:
- update.home_assistant_supervisor_update
to: "on"
id: "2"
- platform: state
entity_id:
- update.home_assistant_operating_system_update
to: "on"
id: "3"
condition:
- condition: trigger
id:
- "1"
- condition: template
value_template: >-
{{ state_attr('update.home_assistant_core_update',
'latest_version')|regex_match("^((2\d{3})\.([1-9]|1[012])\.([3-9]|[1-3]\d))$",
ignorecase=FALSE) }}
action:
- if:
- condition: trigger
id:
- "1"
- "2"
then:
- if:
- condition: trigger
id:
- "1"
then:
- service: update.install
target:
entity_id: update.home_assistant_core_update
data:
backup: true
else:
- service: update.install
target:
entity_id: update.home_assistant_supervisor_update
data:
backup: true
else:
- service: update.install
data: {}
target:
entity_id: update.home_assistant_operating_system_update
mode: queued
I personally felt it would be a bit simpler, safer, and easier to manage things by keeping a separate automation for each item; one for Core, one for OS, one for Supervisor, etc. I felt the combined automation I ended up with was pointlessly over-complicated. So I broke it out into 3 individual automations.
It’s not like these are taxing the system in any way. They are simple trigger based automations.
HA Core version check
I tested my Template based condition for the Core version checking in real time under Developer tools → Template. You can paste the following in there yourself to see:
Latest available version of HA Core:
{{ state_attr('update.home_assistant_core_update', 'latest_version') }}
The latest version of HA Core is >= yyyy.mm.3
{{ state_attr('update.home_assistant_core_update', 'latest_version')|regex_match("^((2\d{3})\.([1-9]|1[012])\.([3-9]|[1-3]\d))$", ignorecase=FALSE) }}
For anyone asking to add their own conditions to how they want their own home assistant instance to automatically update; I highly recommend you use the visual editor under Settings → Automations and make a new automation from scratch.
Make it do whatever you want it to.
1 Like