Here is a guide for how to run Home Assistant and addons(equivalent containers) in a container environment without hassio.
From a user perspective I am not sure I see the distinction.
I guess the very least allowing the community to help itself could be of benefit.
What about having a compose.yaml for every add-on for example?
I tried to read through all. Maybe I got sloppy with the reading in the end - but I am not sure I have seen explanations for
- why the add-ons are not listed on the website (but only inside HA)
- why not have the add-ons store in the container version and just point to the specific install instructions (instead of the install button)?
- why there is no desire to make the re-packing details of the add-ons more accessible. It’s there: GitHub - home-assistant/addons: ➕ Docker add-ons for Home Assistant
- why talking to container runtimes isn’t an option (to unify Container and HA OS)
Sorry, if I missed them.
AFAIK the store is not available to those that run the Container version. So there is a discovery problem unless there is at least an equivalent on the website.
That was my point.
If the store (I have never seen it) just list exactly what is here
GitHub - home-assistant/addons: ➕ Docker add-ons for Home Assistant
Why not at least link to the repo from Home Assistant Add-ons - Home Assistant ?
Even little things like that would be of benefit IMO.
I would offer to make PR for the docs.
I am just not sure I have the full picture.
Nice. To summarize:
77% OS
15% Container
4% Supervised
3% Core
Sure they are. But maybe a README in the repo would be enough rather than having Supervised and Core listed as supported install paths?
TBH I am running the container version and I have no bigger problems adding what I need once I need it. But that’s my field. Yet I see the discovery and integration as what could be improved.
It just feels like this gets largely dismissed in this thread.
15% of users isn’t exactly just a few geeks.
I just wanted to offer a (hopefully) constructive voice/view.
4 Likes
Because nobody’s put the time and effort into doing that?
There’s absolutely nothing stopping the community doing that. Building a repo of compose entries and related docs.
Of course somebody has to manage and maintain that, and history says that it’ll be more work than people expected and get abandoned.
No, but it mostly consists of people who’ve used some GUI to install HA in Docker and will do the same for other software, or those who’re already using the command line for installing software.
Most of those are people who can track down official install steps for other software themselves. Not all, by any stretch, but most.
Ultimately the project has only so much time and effort to put into things. They don’t prioritise third party software install docs, since the third party should provide those.
Maybe we could have a category on the forum for the various Docker command equivalents for add-ons?
Or we could have another pinned thread in the community guides category for that?
or we could have a new sub-category in the HA Cookbook forum thread? That would be the easiest to get started on but it would be harder to find for users tho as it would be buried in the long list of other links.
Anything that could make it easier for users to find the info and forum members to contribute. Just throwing out ideas…
3 Likes
That works, with each post having the compose entry (embedded) and links to the relevant external docs?
Alternatively, separate topics so that people can engage in discussions about each one?
Hoo boy. Quite the thread. Lots of good points from all sides regarding Add-On (AO henceforth) support. I’ve been using HA in Docker for about 5 years, have been a professional software engineer/architect for over a decade, and have been a system admin/home labber for much longer. I’m hoping to summarize what I’ve read, clear up some miscommunication I believe I saw between the sides, and add my take.
I ran into this because, like OP and many others (15% of HASS users, as cited above), I chose containerization over dedicated VMs for my lab when I set it up 5 years ago. My options for HASS were to set up a supervised installation or use the official container. At the time, the OS was not available (IIRC), and the limitations of the container approach vs. the Supervisor weren’t as clearly defined. Both approaches were once “recommended” as recently as Aug '22. The argument that HAOS is now strongly pushed to users who want AO support may be true today, but it doesn’t seem to have always been the case. The issue I see is that there’s an ever-growing gap between the ease of installing AOs via the OS/Supervisor approach, and the ease of installing AOs via the container approach, which has been made increasingly obtuse. (As mentioned above, some core functionality was only added to the container to draw users toward supervised installation methods.)
First, I’d like to address a concern I have with the stats being used to justify some of the larger architectural decisions at play. Let’s assume for a moment that some amount of the 82% of users who chose the HAOS (77.93%) or Supervisor (3.93%) installation did so because they wanted easier access to AOs but still would prefer a container installation—a reasonable assumption considering some participants in this very thread. I think it’s reasonable to conclude that if it were easier to integrate 3rd-party AOs, the adoption of the container approach would be vastly higher than 15%. I’d bet the share of container installations has been steadily decreasing from a much higher share since I adopted it 5 years ago, despite the popularity of containerization consistently rising. The inclusion of dedicated HA hardware in the HAOS/Supervisor statistics is also worth considering, as it might inflate the 82%. If someone buys a dedicated HA Green/Yellow device with HAOS/Supervisor installed, it seems unlikely they’d wipe it and install HA in a container on some other host. While possible, it strikes me as an edge case. A better comparison might be between users who already had access to bare metal or a VM environment and what they chose, though I see those data being difficult to isolate. So, I’d take the 15% statistic with a grain of salt and assume it underrepresents users who might prefer a container installation.
HA adoption has grown significantly, and I applaud the team for focusing on accessibility and keeping it open-source while supporting themselves with official hardware, rather than stricter licensing. However, it’s understandable that some users, like OP and others, are concerned that this focus on accessibility seems to cater to an audience HA may not have been built for originally. There are already plenty of easy-to-use home automation systems (SmartThings, Aqara Hub, Amazon Alexa, Google Home, etc.). Personally, I chose HA because it was the advanced option. I don’t mind spinning up new Docker containers to expand functionality; the missing piece was always the integration with HA, which has become more difficult even for experienced users.
I understand and appreciate the devs’ perspective that documenting every AO might not be feasible since they’re 3rd-party applications. However, I don’t think users were necessarily asking for exhaustive documentation. From what I can tell, the official ways to find AOs are through a supervised HA installation (OS or Supervisor), the hassio-repository category, or the GitHub organization. But I couldn’t find a URL with a clean list of supported AOs like the AO Store, only a screenshot on this page. That’s a big leap from a call-to-action button in the integrated store to digging through GitHub for configuration details. Users like me are looking for easier integration without having to dedicate an entire machine to HA (which, with its minimum requirements, feels excessive even today).
I’d like to propose a possible solution: a dedicated Add-On configuration page in Core. Imagine a page in the HA UI prompting users for the local address, port, etc., of “known” AOs (from the AO Store, maybe custom ones too), expecting the user to manage the container on the host OS. HA would just need to recognize it’s running in a container rather than supervised, which doesn’t seem like a stretch. This could bridge the gap and make integration easier. For example: “Want to connect deCONZ to HA? Here’s what we need… [with Docker Compose snippets and documentation links].” I’m not suggesting the Core team do all of this, but laying out the architecture to allow it could encourage contributions from the developer community.
I hope this adds something constructive to the conversation, and I apologize if I’ve misrepresented any comments. I love HA and look forward to many more years of using and supporting it!
7 Likes