Generally.
Reading the release notes is far quicker than updating and having issues.
Ok..
Do you know for sure your backup works?
Does it backup everything? Do you have the encryption key?
There is a lot of people that has done just like you and ended up right at this spot here.
With incomplete backups or no encryption key.
Those who has seen it before do our best to make sure itās avoided again.
Sadly people come here with the attitude they know it all and call us negative.
Not in all cases, notably if thereās been automatically migrated configs or some DB schema changes. Youād need to restore the DB then as well, and that would depend on the DB setup used. It will only work for backups including the default SQLite DB.
Pretty sure these nearly 4GB backups are the full backup right? Seems to be working the way I expected .
Iām in the same boat. I have no time to look at release notes. Itās not a bad idea to do that though. I agree with everyone that these auto-updates are scary, but Iāve literally been doing it manually anyway. All this does is remove āmeā out of the equation.
And if something is suspect, then I can disable the auto-update automation. I personally follow every upcoming Home Assistant release. I bet itās because of AI, but holy crap does every update seem MASSIVE this year. And I can always tell AI ālook at the release notes for 2027.1.0 and fix all the things that are going to break when I upgradeā.
Apparently You canāt Distinguish between Negative āVibesā and Warnings/Advices
Well Who would know , good that you were Home and had time to research and post here to get help ! ( Please donāt tell me you havenāt had time to look in the āTracesā of your Blueprint/Automation, and havenāt bothered to Look the RAW-Logs of HA-Logs )
Could be that the Devās are aware of the consequences , and that it would be an enormous task and burden to implement in a secure way
When you learn to read, you will know howto āskim throughā ( Read whatās important to You and Your install
1.Right, and turn on the the Alarm to wake you up in the middle of the night ⦠to hopefully fix it with a rollback ?
2.What if Your not at home, and donāt have any other options to actually Be home And have time to Fix it ?,
3. In the middle of your kids big birthday party, When ever !
Sure You and a few others do consider Warnings and Advises as
PS: You might have noticed that noone have even tried to Answer your Question in regards to
One of the first (pinned) Post in this Forum , describes the often needed requirements , for people to even understand what you are talking about ( Yes it requires you to have time to read ! )
I am reminded. The stove is on, the small hand of a child is reaching up. āDonāt touch, itās hot.ā Touch. Tears. And from that day on, that child knows what āhotā means, forever.
Nobody in this thread saying ādonātā is being negative. We are all kids who have had their fingers burned.
For the record, āhotā means:
Breaking changes ship monthly, on purpose, announced in advance. An auto-updaterās core feature is not reading them for you. It is not reading them at all.
A backup is not a rollback. It is a rollback you have not done yet. Someone awake, at home, with a working login still has to restore it.
Updates do not break at 2pm on a free Saturday. They break at 2am, while you are at work, or on vacation. An auto-updater schedules failures against you.
x.y.0 is the community beta. Automating day-one updates does not make you hands-off; it makes you a volunteer.
The updater runs on the thing it is rebooting. Which is why it needs helpers, resume stages, and restart-survival logic just to exist, and why this thread already contains āupdates partially completed, nothing happened, please help.ā The escape from reading release notes has become reading logs.
Automate the lights, the locks, the laundry. The update button changes the machine that runs all three; that is the one moment the human is supposed to be in the room. The boring version that works: skim the breaking changes for your integrations, update when you are home and awake, never on release day, with a backup you have restored at least once.
Or touch the stove. No disrespect, it is a rite of passage, and the burn heals. But afterward, when someone says āitās hot,ā you will know exactly what they mean.
Iām actually a Home Assistant power user, but yeah, I donāt have custom cards other than some from HACS. I didnāt write any myself because itās a maintenance headache.
The default dashboards are awful at scale. I literally have hundreds of devices, and those dashboards really donāt work for me. I donāt even recommend them for family members.
Maybe I should rephrase and say very few people read or care about release notes, myself included. Itās unreasonable to expect people to read them.
Home Assistant updates with huge changes monthly especially in 2026. I do follow those on YouTube because I wanna know about new features, but especially for add-ons and other things, Iāll just dumb-update to be up-to-date. To me, itās more important to have the latest possible security patches without caring to look at what those may be.
While Home Assistant obviously attracts power users like me, I donāt care about anything past ādoes it do what I want it do to?ā
Sorry to drag the conversation back to whether or not to auto update but I think there are a few things to keep in mind.
Current behavior: I donāt think there is a way to measure this but I suspect quite a few users update āsemi-automaticallyā clicking all the buttons without reading the release notes. Whether that is because of a complex build with random update schedules, many release notes, or a person with a busy day job that is not in IT or just plain convenience (have you ever appended a 1 or ! to the end of a password or capitalized the first letter to meet a password policy?). Since it is already happening āsemi-automaticallyā and could be opt-in, I think the only reasonable argument against implementing is that you are encouraging bad habits (even if they are already happening whether you like it or not).
breaking changesThe argument about breaking changes and inability to road back is a half-truth. Even if one is diligent about reading notes about breaking changes, there are times where updates still break things unexpectedly. Look at OPNSenseās latest major release for instance.
security In the age of AI, I dont think itās prudent to say āif it works, donāt updateā. Security updates are pushed out at a much higher rate for software now with ai being used to identify vulnerabilities to patch, and ai being used to attack. Keeping a system up to date is the most secure posture for most systems. So the headache of an unanticipated break-fix should be weighed against the headache of a hack.
Is there a way to utilize semantic versioning? Or a system-check prior to update to pre-emptively identify if a user has a edge case that will break with an update (if you have a Kasa breakfix and Kasa is installed, you donāt get the auto-update but instead get a notification). Seems like there is a better way than to say to keep it manual, keeping in mind security and not breaking things.
I have been using this blueprint for addons and HACS for a few weeks and am very happy with it. I am not too concerned about the autoupdate question because Iāve simply not often had problems with it, and I certainly didnāt read the whole release notes every time before beginning to use this.
So far, I have not enabled updating for HA Supervisor/OS/Core because in that area I have noticed compatibility problems in the past. My personal policy is that I donāt use xxxx.y.0 versions, but wait instead for the first xxxx.y.1 release to update (or x.0/x.1 for HAOS). It would be great if a similar policy could be implemented in the blueprint.
On a more general topic, with AI bug discovery and AI bug exploitation and all that going around, a lot of package managers have implemented a ādependency cooldownā concept where versions arenāt offered until they are a certain amount of time old (to allow for 3rd party security scanners to likely find problems first). Iām not sure how possible that would be here, but it would also be a nice feature to wait to do the autoupdate until the version is available for a certain number of days. (I understand that that could be problematic if another version comes out before that cooldown is completed and I have no idea if HA lets you explicitly install, for example, 1.0.1 when you are running 1.0.0 but 1.0.2 has just been released.)
Hello,
I have some problems with getting the the messages after run:
Logger: homeassistant.components.automation.auto_system_updates
Quelle: helpers/script.py:2291
Integration: Automation (Dokumentation, Probleme)
Erstmals aufgetreten: 04:08:16 (3 Vorkommnisse)
Zuletzt protokolliert: 08:16:39
Auto System-Updates: If at step 18: If at step 2: Repeat at step 1: Error executing script. Error for call_service at pos 1: Error sending notification to iPhone
Auto System-Updates: If at step 18: If at step 2: Repeat at step 1: Error executing script. Error for call_service at pos 1: Error sending notification to iPad