Same applies to this suggestion:
I’ve been a home assistant core install since releases in the 0.70’s or 0.80’s,
I’ve been working over the last few weeks to bring custom integrations to up date, and get myself in position to try the “Backup, restore, done ”.
Some challenges so far:
- History is mysql database, sensible for the time, but the backup doesn’t include that. I don’t particularly care about dumping the history, but it creates a bit of “darn, where’s the config editor in this darn thing”
- Official integrations such as APCUPSD don’t seem to have a practical option for local install under HAOS
- Command_Line sensors which work well under HA Core do not work under HAOS, some of which may prove a challenge to implement. Currently looking at porting appdaemon, although I’ve moved a few things to other servers using MQTT
It’s absolutely my technical debt to pay down. But there are some significant changes beyond backup-restore-done.
FWIW, you may be able to replace APCUPSD with the NUT add-on and integration. The add-on would talk to your attached UPS, and the integration then talks to the add-on to provide UPS entities in HA.
not going back to re-read “the posts above”, my impression is that you have assumed under-reporting is uniform or uniform enough. I was trying to imply otherwise, especially in light of @redhatme’s comments.
Not only voluntary under-reporting but also internet availability/restrictions.
Then one might argue social demographic differences, specifically relevant privacy/paranoia. Each of which may contribute to significant skews.
You do repeatedly say we aren’t going to actively stop you. I think perhaps what might provide comfort to many is a public [if informal] process by which a handoff occurs. Of course, this doesn’t guarantee any level of long-term support, but I keep hearing “how will we prevent this being memory-holed” and your [not necessarily a specific moderator/maintainer, but my summary of your combined position] continued position that the community will magically step-up remains less than comforting.
being told that “it will all be deleted” is a long way from “it will be moved to an [as-yet unnamed] unofficial github repo”.
Well if you are not going to research properly then there is no point engaging with your incorrect assumptions.
I have read the comments over the last ~10 days, I haven’t kept notes. ~300 messages is a lot to read through a second or 3rd time. I did try searching the thread for the keyword “statistics” but did not find the specific posts I was looking for.
istr frenck saying “we assume only 25% of users opt-in” && the general statement “the statistics are not our only or primary motivator”.
The problem is that your other motivations listed are subjective/relative and thus inarguable. So most of us know better than to make them the focus of our arguments.
You ask for feedback, but you only appear interested in tweaks to the intended future announcement, not in arguments that might change the final outcome. Other than the change to discontinue armv7 too.
They are not inarguable, but they are hard to argue against.
The problem here is that those are the heavy motivators, so those are the ones that needs to be argued against to really sway the decision.
The problem is that the support on these platforms have long be an issue in the active community, because many of the users that run these setups are passive community members.
The lack of effort from these users to help is partly what have spurt this proposal.
I am one that has opted in to Analytics.
Is someone able to elaborate how the below percentage is derived?
Analytics used by 2.3% of active installations?
I know Privacy is one of Home Assistant’s priorities, in my mind this probably should have been an Opt-Out option rather than Opt-In. Especially when it comes down to having some quantifiable and transparent data to base system changes on.
I can see there will be other changes like this into the distant future as technology moves on. The proposed change in this thread “I personally do not disagree with and won’t be affected by”. @frenck and the Home Assistant Team, I commend on the open way this change is being approached.
I agree with this, basing “because nobody uses supervised, it should be deprecated.” on data only 5% of people give you seems wrong. “only 5% of installations use it” isn’t as valid if it’s also a subset of 5% of all users.
Yeah, and I could migrate mysql externally, and I can move some services to another server over MQTT, and I can move some services to AppDaemon, and I can retire some other things.
But the key point is that just restoring the backup isn’t the end of the story. It’s probably a weekend of light tinkering, I’m not mad, it’ll probably be lower maintenance for me in the medium term too. I’m just highlighting that there is work to be done to migrate beyond just spinning up a new VM.
Users of the other installations opt-out of the analytic too, so it probably even itself out somewhat.
I’d bet the type of users to use Core and Supervised are more likely to opt out of statistics and are probably under-reported in the stats. Enough to matter? I don’t know.
I’d bet HA OS users are more unaware of the feature and don’t enable it so are under represented. Enough to matter? I don’t know.
So maybe it does even out.
Completely understood! I was ‘stuck’* on an ‘ancient’ install of HA Core running on Debian Buster for the longest time until I decided to rip that bandaid off. I think another argument in favor of HAOS is there’ll be a smoother path forward once one does the work to move from Core or Supervised. Now that I’ve moved to HAOS could take the 2025.4.4 backup I have from last night, made on a VM, and drop it onto another VM, RPI or other supported hardware and be quickly back in business.
*by stuck, I mean the same as you - technical debt due to decisions I had actively made around my install - mysql db and command line sensors included among a number of other choices that made moving on less appealing
Moving from Core to Container was the best move I ever made. HA is just way too fast moving of a project to keep up with otherwise.
Well after i read the comments i can only say “yes dev good call”
My 1st home assistant was hypervisor a debian vm on a pi. Because the pi did stuff already and did not had a spare system. It was a pain in the ass. (Not blaming ha)
@frenck cant you guys add libvirt with a PI to the documentation. For that migration scenario.
Its stange you guys have a perfectly fine haos img for libvirt on a pi but no documentation.
Armbian will continue to maintain the supervised installation method for as long as it remains feasible. This commitment is partly driven by a personal interest in running Home Assistant Supervised on a single-board computer of choice. It is expected that HAOS is not intended to accommodate the wide range of custom hardware configurations that Armbian supports.
Armbian focuses on kernel-level support for diverse and non-standard hardware, and even within that scope, meaningful support is realistically limited only to a curated selection of boards (supported), everything else that work or might not work is “community supported”. Most of those have level of support just enough to run server case / headless scenarios just fine.
As noted by several people here, maintaining low-level kernel support for random or low-cost custom hardware exceeds the mission and capacity of the Home Assistant project. Expecting a small development team to provide stable support across such a broad and fragmented hardware landscape is not realistic. Even the broader Linux kernel community faces ongoing challenges in addressing the explosion of custom hardware over the past decade.
tl;dr;
If not for anyone else, I will keep Supervised install maintained on our fork until it will be possible. But I won’t be answering on any support requests - we have automated test installation in place and in case / when Debian base packages broke it, it will be known that very moment and fixing will be done when (if) possible, regardless of anyone’s request. This is open source world - anyone can help help open source maintainers fixing a common problem.
After going through all the feedback here (thanks!) and thoroughly weighing the long-term maintenance benefits against the impact on affected users, the core team has approved the proposals.
The aim is that starting with Home Assistant 2025.6, we will begin a six-month deprecation period.
We understand this change may be disruptive for some, and it was not taken lightly. However, this step is necessary to ensure Home Assistant can continue to evolve and remain maintainable for the future.
Thank you to everyone who participated in the discussion. Your input was essential in guiding this decision.
I’d say that @igorp’s post is the most encouraging, and in-line with my earlier comment of needing a hand-off or a known point-of-reference.
Not sure why this keeps being recommended, instead.
Managing Docker infrastructure is significantly different than HA add-ons. Managing Docker infra is my daily driver job. This is like recommending someone go use more computers. Can it be done? Sure. Does it make sense as a comparative replacement? No.
For example, several add-ons rely on HA ingress. If you terminate your server with TLS, the ingress is secured with a session. So you get a convenient frontend for (mostly secure) managing of multiple insecure backend interfaces through the ingress endpoint.
Home Assistant supervised is acting like an orchestrator similar to Kubernetes; except a normal person can interface with it because of how Add-ons are integrated with home assistant.