you have a choice. Install watchtower.
(short enough that time? 
)
1 Like
What if you aren’t using docker? I’m running HA Core ( the OS version ) inside of a virtual machine managed by my Proxmox hypervisor.
I also never read release notes., My HA VM is backed up nightly, the whole thing, so I can can undo an upgrade gone in a few minutes. Just click on the backup file and select “restore machine”
I’m not sure what you are asking?
It sounds like you have an update scheme already in place that you are happy with.
what am i missing?
1 Like
That only applies to docker.
Is there a solution for those who run HA inside of a VM ( without Docker )?
I would love to have the option enable auto-update with options to select day/time or when it is available, also with the option to select if it applies for all updates or minor updates (usually bug fixes) only, include/exclude add-ons/HACS, etc.
Many other consumer systems have this, as most consumers don’t wanna be a system admin all the time and still wanna be update with the latest fixes and security features.
3 Likes
by that I’m assuming you mean you are running a HA Core installation and are running in a Python Virtual Environment?
If so then I’m not aware of anything tht offers that ability. But I’m not a Linux guy so there may be.
you could also set up an automation to check that there is a new version available then based on that execute a bash script to run the required commands to perform the update.
Other “consumer” systems aren’t as complex as HA and come with so many potential breaking changes on every release.
The way I (and most, if not all, other advanced/senior/devs) see it is you should never update without first reading at least the breaking changes to see if you are affected by any and only update if you are prepared to deal with them. In that respect you are kind of forced to be a minimal admin.
So if you are already taking the time to read thru the release notes you are only a few seconds away from pushing the button (or buttons) to manually do the update.
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.
6 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”
1 Like
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?
1 Like
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.
5 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