Thats… actually not a bad idea. A minor/major release attribute would make that easy enough.
In the meantime, you could probably figure this out yourself on a per entity basis with a template. Since every component has it’s own versioning scheme you’d have to figure out the template for each update individually.
{{ states('update.home_assistant_core_update','on')
and state_attr('update.home_assistant_core_update','installed_version')[:6]
== state_attr('update.home_assistant_core_update','latest_version')[:6] }}
{{ states('update.home_assistant_operating_system_update','on')
and state_attr('update.home_assistant_operating_system_update','installed_version').split('.')[0]
== state_attr('update.home_assistant_operating_system_update','latest_version').split('.')[0] }}
Both of these should evaluate to true if there is a minor update version available.
The update.install service is still not working for the Home Assistant Operating system. This is how I have it configured. Is there something I’m missing, or have I ran into a bug?
I ended up figuring this out. Having the “Backup” option enabled causes it to fail. After disabling the option to take a backup before the update fixed the issue and caused it to run. This obviously isn’t a good idea so a work around is to use the Google Drive addon and use that to schedule a backup before the update service is called. In my case I have a backup set to run every morning at 3 AM and then an automation to run the update service every day at 4 AM. If I wake up and find my system hosed, I can download the backup from Google Drive, format my Pi, and restore from the backup taken right before the upgrade. It would be nice if the built in backup option was supported but at least for now I found a workaround.
Would it be possible to match this with the breaking changes list, to validate the breaking change and if what we use is in the breaking change then don’t update and send a notification or a mail
Is there a way to auto update to latest dot version of a previous release? IE - I want to avoid going through the dot versions that get released so instead update to the latest version of the last release. So when 22.8.0 comes out it would automatically update to 22.7.7
That is… Not how that works. Updating the state of entities in dev tools is just for testing, it doesn’t change anything except the state of that entity. At least until the integration updates it state again with what the value is supposed to be. I would guess if you looked again you’ll see that attribute is true again.
However you are correct that you can disable automatic updates for supervisor now. To actually do that you need to enter this in the cli:
ha supervisor options --auto-update=false
Note that while supervisor is out of date nothing else can be updated. It also won’t even check for updates to addons as just reading in their config can break things if they are expecting the latest supervisor features. You also cannot install new addons or add new addon repositories.
In addition your system will be considered unsupported while supervisor is out of date as only the latest version is supported. Wanted to make sure you weren’t surprised by any of these restrictions before you changed it.
So that’s the reason for the auto update,
still I can imagine some smart mechanism not breaking stuff while the supervisor is out of date,
for me there seems to be some kind of contradiction,
for haos and ha core, please read through all changes before installing because you might break something and then the supervisor is just pushed whether the time suits me or not.
On the other hand, this update has never broken anything for me, still a little more consideration would be nice.
If you’re referring to the command in my post it came out in 2022.08.4 of supervisor. And you definitely have it because supervisor auto-updated for everyone with no ability to turn that off prior to that release.
What version of core you are on (I assume that’s what you’re referring to) does not affect what commands are available in the CLI.
Is there any way to stop all update checks/notifications entirely? They’re not an issue for my own personal systems/spaces, but deploying this for a customer, neither of us can afford the annoyance of the update checks and notifications. In such a situation I’d manually handle updating once or twice per calendar year or at any other scheduled maintenance such as when adding new hardware.
That might be too much maintenance (moving targets, things missed) and instead it’s looking like locking them out of the HA web UI and app is the better move, relying strictly on Apple Home for their interaction.
Or set them up with a user account rather then an admin one. User accounts don’t see update notifications or the entire settings panel when they log in.
