@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.
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.
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.
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:
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.
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.
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 
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.
that sounds like home assistant regularly breaks with upgrades o.o
Thats not a good system 
Not if you bother to read the release notes…
to be honest i don’t.
it is not 1999 anymore … i expect my it systems to auto update and be on the newest version without the need of spending 15 minutes to log in to everything each day just to click the upgrade button -…-
And you figure that works with 1990 supported integrations (and a lot more if you include HACS).
There is no developer who has al those devices to test…
I myself wrote one integration on HACS, and as long as I have the device, I will support it…
But if it breaks down (or stop using it for whatever reason)…it’ll be the end of it, unless someone else pick it up…
I’m afraid that is the reality of an open source project that supports so many devices…
yeah i try to kiss - and therefor i am update stable.
and even if in 10 years there would be a break i can disaster recover in minutes by going back to the last snapshot of the vm.
i get your point and it would be ok to have the auto update off by default. But at least offer this option for advanced users.
But advanced users won’t be the ones to typically use any auto-update feature since they know what the pitfalls are to such a system for at least HA.
the ones more likely to use it are the ones most likely to not know how to recover from a broken system.