I’m happy to say: We don’t have more telemetry on this. Privacy is a very high pillar of our project. 
…/Frenck
5 Likes
I understand deprecating self-installed Supervisor configurations — as a custom container designed for HAOS, I imagine it requires substantial effort to support elsewhere.
But deprecating “Core” installations sounds to me like a mistake. Ignoring the philosophical incongruity of a Python app that is unsupported running outside a container, consider that Core is the only way to run HA natively on macOS (and Windows, sigh) without a hypervisor (VM) layer since Docker Desktop uses underlying VMs. Not everyone can, or wants to, run VMs on their Mac — or figure out how to install semi-functional Asahi Linux — and it would be a shame to demote this alternative just because it is not popular. As M1 Mac minis continue dropping in price they could be ideal HA machines, but HAOS is not (and may never be) an option, and Docker Desktop on macOS continues to be kind of a mess (hence the existence of Colima), and neither are even mentioned anywhere in the official documentation.
Core install, in particular via Homebrew pipx, is really easy to maintain and doesn’t require a Unix degree. (Conversely, the official documentation for installing Core on macOS doesn’t even work on macOS, which perhaps speaks to the existing level of support).
2 Likes
My personal concern is that for a device like my Raspberry Pi, which only has 2 GB of RAM, I think that running HA in a container will cause more slowdown, and when HA is already running it is a bit expensive resource wise.
I want to clarify what unsupported means:
- Issues created on github related to your installation will not be addressed.
- Documentation for the installation method will be removed.
If you know what you’re doing, you can maintain both supervised and/or core with relative ease.
4 Likes
I ask again re the documentation. What documentation will still exist? At some point saying there’s zero/zilch/no docs means it won’t exist period. Memory-holed like “Dimension Out Of Range” by Jason Low & Brian Burgess [there’s only one reference in Google now, 20+ years later].
That you mention use by developers suggests the developer docs may continue to exist?
I suppose I don’t mind running HassOS in KVM if it can support multiple network interfaces in my router. I have advanced experience in Linux.
HAOS and HA container installation documentation will still exist.
The developer documentation will continue to exist, but understand that it’s documentation currently does not cover a ‘core’ installation. It references dev-container and running HA dev in a venv on different OS’s. All of that will likely remain.
1 Like
@petro You LOVE to live on the edge!!! 
1 Like
I’ve been using supervised since I started with HA, I’ve had a couple of times where I broke things, I just needed to refer back to my initial notes and I was back in business. Otherwise clean and very reliable.
Dropping it will require a fully rebuild and rethink of my setup.
A couple of things I feel are missing that I get from Debian is:
-
SMART data for the disks, emailed out after each test.
-
Being able to use SNMP to monitor the performance of the server (ideally sending traps as well) from an external network monitoring platform.
-
if things did go wrong and I already have the tools in place to access any file.
Now if those first two can be added into HAOS, and especially the first one, that would be a huge benefit to everyone using HAOS on bare metal installs.
I believe I can get the first two using proxmox but then have another layer to work with and keep up to date.
If some of the Devs are also using this to help with core developments, then isn’t this going to break all of those people??
So perhaps it should remain but with larger not recommended for beginners, support will be limited, etc.
(Reposted from my comment on GitHub)
1 Like
Home Assistant is first and foremost an open-source project to me, which I run on my own hardware.
I can and have continually modified Home Assistant to suit my needs. I have to fight it to get it to run Python code for scripts and automations (despite HASS being Python-based… 
) and continually write custom integrations when the core Home Assistant project purposely chooses to restrict what can be done (e.g. web scraping or a plethora of other decisions over the years).
I don’t like ANY arguments for limiting the level of control I have over my software on my hardware. I understand that Home Assistant is now catering towards people who do not have engineering backgrounds, but for the last 6-7 years that has come at the expense of those who DO have such backgrounds. Even YAML is a second-class citizen nowadays.
5 Likes
If you choose HA OS there’s an add-on for S.M.A.R.T. data. Home assistant addon : Scrutiny (SMART dashboard) You can automate the email notifications.
There are other options available. e.g. System Monitor (internal) or Glances (internal and external monitoring).
Then choose to either continue to run an unsupported system or move to a Container installation.
2 Likes
Why is Home Assistant moving away from the people who built this project to begin with and were its loudest advocates?
The Core install needs to exist for the Docker install to work; if it is already being maintained for that purposes than why is it so difficult to keep a single webpage up explaining how to use it? Even if that webpage is tucked away in the developers section or somewhere similar.
Forgive me for hearing “unsupported”, seeing that the only “supported” methods involve a black box, and wondering how long it will be until this project starts the process of locking out developers further until it’s no better than the proprietary systems it once replaced.
3 Likes
Core is required for all installation types.
Have a read of the links at the bottom of the first post for the reasoning behind this discussion.
There is no conspiracy. Firstly, the support required is disproportionate compared to the user base.
There are limited development and support resources and choosing to deploy them wisely is not a long term plan for any sort of “lock out”.
5 Likes
The proposal sounds reasonable to me.
@antbarney Why don’t you just run HAOS in a VM then, so you can then still reach the host OS directly?
I started HA in docker container when I was new to docker and HA. Never tried other methods. HA in container has been very stable for me. I do not plan to switch to HAOS.
I wish all important addons like voice-assistant related containers had compose.yml examples (with latest versions) to simplify their installation, because at the moment I have to build some containers manually.
1 Like
This change will not deprecate the install as such.
It will remove the official support and the official documentation for that install method, but the method will still be used and maintained, just as a HA developer method.
So if you are up to maintaining your system today, then you can keep doing it in the future too, but the help from the community will be in the developer forums and you are required to understand your own system.
This change will affect new users mostly in that the method will not be listed.
It is like removing the dish from the menu card in a restaurant, but you can still get it if you ask for it.
3 Likes
It is not with this proposal.
The installation type is not going away, since it is still used in the ha developer setups (by the people who builds this project).
It is only being removed as a “supported” method, which is more like a way of saying “for people that do not have the knowledge to truly run and maintain a Linux install”.
If you have that knowledge, then keep run it.
The kitchen will still make the dish if you order it, but it will not be on the official menu card.
5 Likes
But is that knowledge going to be kept somewhere?
The OP says “We just won’t officially document or provide support for them as recommended methods for production setups” - but nothing about what they consider a “production setup” vs. a development setup.
Does this mean that existing documentation will be moved to a dedicated subpage in an advanced/developer mode somewhere?
Does that mean that only some builds of HA will be considered “developer builds” and that the developer path may diverge from the production path? (e.g. in 5-10 years the developer mode will only work with toy data).
Clarification would be nice. I have nothing against removing Supervised builds, but as I stated elsewhere Core is necessary to set up both HAOS and the Docker builds. Maintaining “here’s how you run Core locally” would be helpful both for onboarding new HASS devs and for ensuring that at no point in the future can HASS be susceptible to a hostile takeover a la what has recently happened to Android AOSP.
2 Likes