There’s a disconnect here (and a pretty even split), between what people who view themselves as ‘devs’ want - and what should probably be classified as what ordinary consumers want. Despite ardent efforts to the contrary, I still couldn’t care less about manual updates. If something breaks then fine. I have two options. Roll back to an earlier instance of HA, or scratch my butt, shrug my shoulders and wait until it gets reported by someone else and is almost inevitably fixed in the next update anyway. I don’t get this almost religious aversion to automatic updates and no amount of berating will ever teach me to love them.
7 Likes
You can make your own automation. I have one where I have a button I press, and then the automation runs at 05.00 in the night (after my backup). All credits go to someone else, I found this on our forum a while back. Can not remember where
Include this in your configuration.yaml
shell_command:
update_core: 'curl -X POST -ssl -H "Authorization: Bearer $SUPERVISOR_TOKEN" http://supervisor/core/update'
Call the upgrade through the GIU part of automation, “call service” and then “shell_comand: update_core”
2 Likes
Ok, I’ve created some automation and as soon I can verify I will try to create a Blueprint and share here.
It might take some time to test as I’m not able to setup a testing environment those days then will have to wait for future updates in production.
1 Like
I will start with this, but as soon I can confirm this works I will add some scheduling capabilities:
alias: Home Assistant Auto-update (Blueprint draft)
description: ''
trigger:
- platform: template
value_template: (states.update | selectattr('state','eq','on') | list | count | int(0))
id: Update available
condition: []
action:
- service: update.install
data: {}
target:
entity_id: >
{{ states.update | selectattr('state','eq','on') |
map(attribute='entity_id') | list }}
mode: single
Any thoughts or ideas?
2 Likes
If you really insist on trying automatic updates, that’s cool - you do you. But please don’t make this into a Blueprint and encourage others to do this. I’m assuming blueprints are mainly used by inexperienced or newer users who will have no idea what they will be getting into with automatic updates. As noted by multiple people, it is just a bad idea for a multitude of reasons. The inevitable flood of Help Me! threads will be unbearable.
That being said, your automation here as is is going to try and install every available update at once. I don’t think I need to explain why this is a bad idea. Honestly it’s such a bad idea I’m a little surprised update.install actually supports multiple entity id’s at all. (According to the docs, it does.) If there are issues, how will you even know what got updated and what is causing the problem?
At the very least send yourself an email or something with a list of the updates that are going to run so you have a fighting chance to figure out what the hell happened and where to look when something inevitably goes horribly wrong.
How are you going to deal with restarts on Core and OS updates? Especially if HA restarts while something else is in the middle of updating? I can’t see that going wrong. How are you going to deal with HACS updates and reloading resources or restarting HA when custom integrations update? What’s your game plan if an update pukes and HA won’t restart?
Maybe someday HA will mature to the point where there is a boring stable release and automatic maintenance updates will make sense. But there are just too many changes and awesome new things happening every release for it to be viable for most people right now.
1 Like
@EdwardTFN For the reasons stated above updating everything automatically isn’t a great idea - especially without even creating a backup.
I do think there is a time and a place for unattended updates though (especially on my underpowered RPi4) - with OS and Supervisor updates it can take 10 minutes to update and reboot. Not having access to turn on/off smart lights during this period can be a pain.
I use the following setup to run updates overnight (but with the knowledge that I might wake up the next day and have a headache to deal with): Unattended Update/ Update Button/ Scheduled Restart
If you are going to do what you propose to do at least take a backup first (see my example).
2 Likes
@illuzn and @jazzyisj, thank you very much for your considerations.
I’ve already included optional scheduling (I wanna it running when I’m sleeping), optional backup and optional notification on my Blueprint, but have excluded from my initial testing code (the one I shared) to be able to test one thing at time.
I was thinking about
I understand your concerns about making this public, so perhaps we should keep this discussion here… I’m not gonna share this until I’m convinced it would help more than hurting.
But then, going to this, I see the last releases of HA all focusing on moving things from coding to user friendly interfaces. This is probably in line with the system getting more and more popular (for mortals who cannot play with complex settings or coding). But then I hear from a lot of people here that the system is not stable enough to be considered a popular system. If this is the case, shouldn’t we be trying to convince less experience people to just stay away from HA entirely? And do you understand this will just drive the system to its end of life (as some other system will just take over this users and everyone will start developing solutions for those systems)?
I totally agree with the comment above (sorry, couldn’t find the autor right now) that non experienced people will just update anyways, without reading the release notes, without the need for updating… So, why don’t just help this people to do this boring task if the risks are just the same? Or are them in some way reducing risks by doing this manually without any special preparation?
It’s a good topic. It became more about making HA a consumer system or keeping it as a engineer only system. And this deserve a lot of attention.
Thanks @jebus2504 for raising this.
1 Like
You are never going to convince the (almost religiously) opposed to automatic updates to change their minds here. Even if your code automatically creates 1 or two scheduled backups (which would be a good thing) before running updates. (Which would make restoring from a last known good install a trivial matter.) They don’t get us and we don’t get them. They enjoy the complexity and constant need for tinkering. I on the other hand just want my home automations to run and to never have to think about the damn system again. (Unless something does break, in which case I’m happy to go to whatever ‘trouble’ there may be to fix it.) This isn’t some mission critical corporate mainframe or whatever. It’s just a cool little gizmo that makes me lazy and fat and that helps me turn my lights on and off, lol.
6 Likes
There’s an add-on that checks the config against the next version of HA, called Breaking changes or similar. One way of making this less fragile would be to make use of that to refuse to update HA if there were any issues with the config.
Obviously you can’t do anything about HAOS or the Supervisor that way, or any other add-on really, but it’s better than nothing, and covers the most likely reason people would wake up to a dark and cold (or hot) house.
2 Likes
This is the link for the add-on mentioned by @Tinkerer: GitHub - custom-components/breaking_changes: Component to show potential breaking_changes in the current published version based on your loaded components
There is also this one:
1 Like
FYI - Here is a thread that has a solution for this:
So, there is my Auto-update Blueprint: Auto-update Home Assistant - Blueprints Exchange - Home Assistant Community (home-assistant.io)
Please give your feedback.
2 Likes
I can’t speak for others on here but I would never do auto updates because I enjoy the ability to continue tinkering at all. If everything broke regularly due auto updates with breaking changes I would’ve exhausted my supply of PAF a long time ago and my system would’ve mysteriously found itself in the garbage.
I do auto update other things that only affect me even if they sometimes break. But not something like ha which I want others in my house to adopt and enjoy.
Kind of weird logic here? Seems like the best way to achieve this is to never update. Not that I’m encouraging that but auto updates is a surefire way to ensure you have to think about your home automations regularly.
1 Like
Not updating a static system that works is by far the best solution….
But for tinkerer’s like myself that is not really an option 
But i did notice that there are nowadays a lot less breaking changes then 2 years ago, however there was one now with node-red 
No. I’m running HA on the Home Assistant Operating System. It’s a specialized operating system that runs HA and nothing else.
For example, if you go to the Raspberry Pi installation instructions here https://www.home-assistant.io/installation/raspberrypi/- you can see how to download and install the OS.
Then you are in fact running HA in a Docker environment.
Every version of HA that includes a Supervisor runs in Docker. Unless you know how to look for it you won’t see it but it’s definitely there.
In fact, the Supervisor itself, every add-on you install and all of the other various assorted HA support functions (hass audio, cli, dns, etc) are all running in their own associated docker containers.
so yes, you have the ability to run Watchtower (as an add-on I think) and that will keep you up to date automatically.
Which is likely to be an even more terrible idea than normal and should result in a broken install in record time 
1 Like
Yup.
I never said I recommended it. I just said it was possible for those die-hard ‘I want to auto update everything’ folks. 
I personally wouldn’t touch it with a 10 foot pole.
1 Like