I do want to be reminded – as soon as there is an update → I want to see the update option.
If I disable the notification → then upgrade HA → will the Spook update appear again? I don’t think so (although I’m just guessing). I’d have to remember to look into disabled updates to install it, right? That’s error prone and unncesessary, from the user point of view.
As I said: technicallly HA knows I cannot update the integration right now → just show me the update when I can (don’t make me skip it entirely).
I don’t think there needs to be a compromise → I think both goals (having the latest available updates shown AND not showing updates that are not installable) can be achieved at the same time (with my FR).
In two years time the Spook update, targeted at an upcoming version, was the first time ever I experienced this, and I have not experienced it since. So i.m.h.o. this request is for such a limited use case, it barely warrant al this discussion.
Ignore the upgrade, unhide it once you are ready for it.
That’s honestly what I do, just ignore it and when the NEXT update comes out it will pop up again. I don’t do it often but I hate seeing that gold number next to settings so I’ve done it a few times.
As I stated, I took Spook just as an example to show the kind of problem with the Updates list. I don’t know how many of the thousands of integrations and versions have the same kind of issue.
I’m not saying it’s a big priority → I’ve noticed a thing that’s bugged me, I’m doing FR to propose an improvement for user experience. That’s what feature requests are for, I’d assume
I have close to a hundred integrations, so I dare say it isn’t common. Spook is uncommon as it ties very deep into HA, in ways that normal integrations shouldn’t. So I expect that to be way more version dependent than most. I must admit I keep up to date pretty quick though.
The idea behind these update entities is for you to build automations off them. Everything you’re requesting can be done with automations. The likelihood of a system being put into place to appease this is low when it can be done today with an automation.
The system shows update entities, there are people who want to know updates are available even though it’s not for them. That’s why they were built for automations. So what happens with that group of people if this is implemented? Do we now have to add buttons and options for the system? Where do those options go? Now there’s another system that needs to be managed in multiple places.
or…
use a blueprint / automation that does exactly what you want because you built it.
But this I think is not correct. If you ignore an update, future updates don’t come up again automatically, or do they? Or are you talking about HA core updates?
I’m quite sure, if you ignore an update for an integration installed via HACS, the future notifications won’t appear. But as others said, I’m updating quickly and I didn’t have that situation in over six years with HA, so can’t say for sure.
I ignored an update recently, because of breaking changes in the integration that I hadn’t had time to correct, and I’m quite sure the integration was updated inbetween. And I didn’t get an update notification.
Anyway, I’m happy as it is, but if enough votes come up, why not…
Sure, kinda odd to me (as I said: I’ve never noticed this kind of behavior in any other software), but that’s why I included the alternative proposition in this FR:
a.) make a separate “Upcoming updates” list (apart from the normal “Updates” list)
b.) [proposed within the discussion] make a Settings option to decide the desired behavior
b.) [also mention within the discussion]: at least show the missing requirements in the update info (instead of learning about the incompatibility from the error shown after clicking Install)
The last option would still bug me though, as I’d like to avoid the seeing the incompatible update –> but would be a small user experience enhancement of course, change in a good direction.
I get your reasoning, but you’re asking for all this additional management. When right this minute you can get what you want without any additional management. What you’re asking for would likely need to be done by the core team because it’s a core area. The likelihood of this ever happening is extremely low because you can use blueprints and automations to do this right now.
It falls into the same category as scan_interval. Half the people want 1 button clicks, the other half want crazy intervals. So it’s an automation to appease both groups.
Yes but you weren’t involved in HA when the update entities were introduced and you don’t know the history behind them which lead to the current implementation.
They are after 6 years of changes to get to the current implementation that works for everyone
I’ll leave you be. Just understand that the system wasn’t built overnight and there were many systems in the past that failed (and did what you wanted).
I was referring to past Home Assistant specific update systems. There were at least 3 other variations that I can remember using.
The current implementation was built to appease everyone and it leveraged automations so that anyone could do whatever they wanted. I’m not mincing my words here. You are encouraged to use automations and blueprints to hammer out these details you’re bringing up in this FR.
