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.
What I would want to do, is not get update prompts for updates that will break my system. I would even suggest that this should be the default.
You could still have entities that show the newest version, but not prompt the user to update if the update is incompatible.
The problem is: HA doesn’t know it’s incompatible until you attempt to install it. It’s a chicken/egg scenario. If this functionality were added, HA would need to know this information before it’s installed (which it currently doesn’t have).
Hence: the Feature Request – construct the install/update env so that it is aware of what’s compatible and what’s not BEFORE attempting the installation.
That’s impossible if the update is for outside-of-HA devices, like zwave, zigbee, unifi, etc. Your “solution” would only work for custom integrations and possibly addons.
We only find our of incompatible things AFTER people submit issues Dave. Therefore you can’t block until issues get reported.
They already have a facility to block stuff like the bum Alexa Media Player update (last month?) (and the aftermath of confusion it caused when they used it) and can use that to keep people out of critical danger but the rest of it… Yeah?
(also I’ve been a software support pro for nearly 25 years responding to requests exactly like this in the big 4 shops - Trust me what you ask is something dev teams strive for… And you have no idea how hard it really is - even in a closed software ecosystem… It gets orders of magnitude harder in FOSS land)
