Yes, in the June release, which contains the code for it.
Thanks. But do you actually remember what the text says? I donât remember it.
Thank you.
That would be enough to alert any user and have them running to the blog.
If this type of notification wasnât even possible in May, then I get it. Either way, whatâs done is done. This is just something for the next time a major deprecation happens.
That system would need to be built⌠It doesnât exist.
Iâm talking about the notifications that already exist.
The one that Francis just posted.
All Iâm saying is, that this notification just needs to happen earlier, before the feedback period has ended.
my guy, i understand what youâre saying. You arenât understanding what it took to get that very pointed notification in the system.
There is no delivery mechanism for future deprecations.
No matter what way you look at this, a feature request is required before the feature is used for a future deprecation.
Okay, I think I understand you.
It seems that during the feedback period, since the decision has not been solidified, they were not going to push that text yet.
It sounds like this deprecation notice is a one-time, tailor made for this particular deprecation.
In that case, I think a feature request is certainly warranted for a general alert/notification delivery system.
My original post, with the hitchhikerâs meme⌠Only illustrates that a real notification system is needed, rather than people stumbling upon this blog.
Itâs funny, because the deprecation notice that people are getting now, is kind of like Arthur running into the bar.
Youâre thinking of this in terms of just âtextâ showing up on your dashboard. There were many code changes put in place to target the correct systems. They arenât going to put out a deprecation notice to non-effected users. As it stands, thereâs already people seeing the blog post thinking it affects HAOS. A blanket notification to all users would just create a ton more unnecessary conversations.
A good feature request would potentially be some sort of mechanism that could target systems with specific attributes like installation type, integrations, etc. However that would require people to Opt In. Hopefully you can see the irony in thisâŚ
Agreed. I donât think I came across as suggesting a blanket, blunt force notification. Certainly not on the dashboards.
With the great work done on the current repair notifications, thereâs obviously a set of checks and criteria for integrations that are installed as well as the versions and installation method. Thereâs a lot of good data available before a repair notification pops up. Otherwise every user would get every repair possible notification. Thatâll be an ugly bug.
Yes but those repairs are built directly into the code as the result of code changes or a past decision/deprecation.
Youâre essentially asking for the chicken before the egg. You want code changes about future things before the code changes happen.
I understand that. It would require new code built-in directly to check a new system built into the version checker.
So in addition to what it does currently, it would have to fetch for critical alerts and notifications.
I get that. It would be new and would need to be developed. And will require a feature request.
With so many operating systems and other major software projects having a system of general alerts about future code changes, like major revisions or deprecations⌠And home assistant pretty much being its own OS (HAOS)⌠I kind of see this as a WTH opportunity.
Itâs not. This notification is purpose built on architecture and installation method. The only way to build something (sensible) this generic for a random future criteria, would be to act on your system information being pushed to the cloud. Which is an opt-in feature, so it wouldnât have helped anybody in this thread, since everyone is claiming to have analytics turned off.
OK. Another pissed off user here.
I found this was going to happen because of the message in the repair sections of the settings, once the decision was already taken.
I understand the âcommunity drivenâ approach of requesting feedback in the forums, but as I suppose many of us have a life and checking the forums on something that is just working doesn´t make sense to me.
Beside this, the âif you want you can continue using it but we will not support itâ doesnât sound âthatâ community driven to me.
I know any one can fork the code and start maintaining it, but - come on - really? This is another answer you can find in this topic.
As others have stated, first thing I do with whatever I install is to disable telemetry, so Iâm not sure you are accounting for my installation.
After a thorough revision of different installation methods, I decided to use supervised because it can manage the add-ons and can be installed in a generic semi-old notebook as long as it support Debian 12. It is definitely the most flexible installation in terms of easy to install, managing of add-ons and supported hardware (HAOS is not quite there yet). Not to mention low power usage running with lid close.
Only thing I can say now. Please reconsider. HA is a GREAT product and you have done a GREAT job so far. I have recommended HA to anyone asking me about home automation.
You likely wonât need to fork anything to keep it running. Youâll just need to learn a bit more about how to manage linux and itâs dependencies without official documentation from HA. Someone will need to read the code to figure out dependency changes for supervisor if you choose to update the supervisor.
Another pissing of answer. I know linux. I know and work with containers. But to me the promise of HA has been I don´t need to learn how to âupdate the supervisorâ
Someone need to read the full posts. If you want to reply the please address it in complete form.
My man, your tone is not appreciated. If you want to reply, you need to taper down your aggressiveness. This is not a suggestion, this is a requirement.
I think you misunderstand.
Nothing needs to be sent to the cloud other than the standard version check ping. Even without telemetry, HA still fetches information about what update versions there are available.
The current repair notifications happen without sending the opt-in telemetrics. It does all of its checking locally.
Iâm saying that a feature request would just extend this capability to also check for and fetch all critical notices, then filter locally based on whatâs installed and relevant.
Iâll assume youâre joking. Or trolling.
If neither, then review the Blog post. Itâs a longer version of the repair message.
First of all. My apologies. Maybe translation error (my first language is spanish).
That said, suggesting âsomeoneâ go and read the documentation doesn´t feel friendly to me either. I was paraphrasing your response.
My point is, my post (the first one) reflect my frustration about some responses.
As I said, GREAT work, GREAT product. Not sarcasm. I really mean it.

