Actually, 90% of the addons is picking some standard Dockerfile for a product and adding the HA “sauce” on top 
1 Like
Right, the addons I’ve developed haven’t needed any HA sauce so they’re just pointing right to the source docker image. Usually starts with a normal docker container then goes to addon 
1 Like
If that were so, then writing out a docker-compose.yml file for the admin directly from the Addon Store would be trivial, no? /devilsadvocate 
Maybe the right documentation would be the easiest way forward. Or at least the easiest first step. I could even volunteer to write that. But I would need someone who could help walk me trough the steps first and fill the missing knowledge. Then I could condense it down to end-user instructions.
2 Likes
Like I said earlier, addons are other software republished in nearly all cases. This guide already exists for all of them published by the people that maintain that software wherever they do their documentation. Why would HA team republish that when they don’t maintain the software? They clearly have enough PRs they don’t need to sign up to try and replicate others doc and keep it up to date.
Have you checked out linuxserver.io by any chance? They publish and maintain standalone images for basically every piece of self-hosted software you can think of.
Course as has been mentioned repeatedly the docker compose file is only part of the story. Addons often preconfigure various settings and things in the other software that make the most sense for HA users. This other software wasn’t actually developed with HA users in mind though so when installing the non-addon version you’ll have to replicate that. Supervisor also does discovery which can preconfigure an integration in HA if is used in conjunction with the addon. No supervisor means you’ll have to configure the integration manually. If USB devices or advanced network config is involved supervisor cant help with that but hopefully the software maintainers have a guide. Or if you want healthchecks and auto-restarts of unhealthy services, update notifications when a new version comes out, sensors for cpu/memory used by services or backup and restore then you’ll have to set all that stuff up yourself since there’s no supervisor to provide that.
I agree with your suggestion of a community guide for setting up common software in a docker install though. That would be helpful if you or someone else wants to write that up.
1 Like
Reading through the thread, @aigarius , I believe you have to pick:
- If you value easy maintenance more, then go with HAOS install.
- If you think the flexibility that comes with a Docker environment is more important, then you can do Docker container install, and roll/manage whatever add-on software services you like, as containers, yourselves.
Can’t have both. At least not today, and not for the foreseeable future.
The devs don’t see the need; (most of) the users here in this forum / this thread don’t see the need either.
So, you could still make the feature request no problem. I just would not hold my breath waiting for any of it to be fruitful, if I were you.
1 Like
There is an alternative, though:
If you know your way around docker containers, maybe you could help put together something to bridge the gap, and contribute to the community?
I can see a couple of things being helpful, outside of feature request:
- An explainer article that can go wide altitude and latitude, to convey the idea that “add-ons are essentially docker containers”.
- A how-to guide, with examples (maybe MQTT? Node-Red? MariaDB? Portainer? z2m?), to show other users how easy it is to roll your HA as a container, and how easy it is to roll your own HA-related containers, and how easy it is to tie them together.
- A repository of a bunch docker-compose.yaml’s for various HA-related (or smart home related) services / software
Just a couple of things one can do, to contribute, to make the situation easier, and to make gaps smaller.
Does not have to be anything from scratch. Building blocks of those are likely available already somewhere. We might just need a 2022 index page with a bunch of links.
My 2 cents, anyways…
2 Likes
But HA already does that. It’s what Addon Store is, essentially. It just does not exist for people running HA in Docker. If all addons were just third party software, like SSH server or Nginx server, then there would be no question that this is not in generally useful to be republished.
However, those are not the addons that I am talking about. I am talking about addons that add (sometimes essential) functionality to HA. Like Zwave JS. They are not just standalone third-party Docker containers. The addon part configures the third party container in a specific way and it also configures the HA in a way that enables the HA to use that new container. Be it config files, network ports, user credentials, … That is the part that is non-trivial even for very experiences Linux system admins, because it is all HA-specific knowledge that is not documented (for most addons) and is instead hidden deep inside Addon Store or Supervisor configs and scripts.
I am open to contributing the knowledge gap to the documentation, if a programmatic solution is too hard to implement. How the system is working does quite heavily influence what could be the best way to document this. Also it would be best if the documentation could be made in a generic way so that it can be easily transferred to all new addons as well by saying things like “then you look at the X field in the addon definition and that will be the name of the Docker container to run”. And at that point any sane (read - lazy) developer and sysadmin will be asking “why isn’t there a simple Python script that can do this for me?”. 
2 Likes
This is an interesting debate, but ultimately this is missing the point. I’ll rephrase in my own words what I think many have already said or implied.
It’s not about easy vs hard, but rather about a specific goal. This makes it fundamentally a design choice. The docker method works the way it does, because it is intended to work that way, and that was a human choice and not a technical reason. While there is parity by all installation methods running HA core, the divergence beyond that is there for a reason. Trying to align more of these would lead to duplication in effort and larger overlaps, which in my view doesn’t seem to be the intention (or valueable use of time of the core devs). With the installation methods that exist, all the bases are covered when it comes to skill levels.
Disclaimer: Note that I run HA core on bare metal in a pyenv. I have never tried or needed the other methods so far, but I’ve been hanging out for a number of years in the forum now and have followed a number of these conversations.
1 Like
That’s just plain not true, I’m no Linux expert and all of the configuration files, ports mapping, and credentials are all documented.
You mentioned earlier that you haven’t used any addons / set these up yet, but you speak of it like you know how it works which is contradictory.
I’ve never once had to read source code to get things setup and I currently run 20 docker contains half of which connect directly to HA. This thread seems to be going in circles, and it seems to be the general consensus that no source code needs to be read to set these things up.
There is. Its name is supervisor. It’s even written in python. That is the tool the HA team publishes which allows a developer to attach a config file to a stock 3rd party image to add all of this functionality to it
Along with all the other infrastructure things the HA team has identified as needs for HA users (backup, restore, watchdog, update monitoring, log access, network config changes, etc)
If you do a docker installation you are making the explicit choice to run without this tool. Which means any of the things the tool does that you like you have to do yourself.
I feel like we’re going in circles so I guess I’ll stop here. As Taras said much earlier your welcome to make any FR you want but this one seems quite unlikely. At least by the HA team, Community Guides are always welcome.
2 Likes
Going through this thread I really feel maintainers are missing the point. So I created an account just to explain the use-case step-by-step and why it is a real issue.
- I built a custom REST API that tracks internal information on my server.
- I am running my HA server in a docker container.
- I google “Use REST API as sensor in Home-Assistant”
- All the results are RESTful Sensor - Home Assistant which looks like exactly what I want, it’s even part of core!
- I can’t install it because it’s an addon and I am running HA in a container. There is no docker image for it, I just get the code.
This is not an “expert” feature, this is just an installation with reduced features where I can’t do simple things like pulling data from a REST API.
The installation page (Installation - Home Assistant) should make it clear that HAOS is the right way with stronger wording than:
Home Assistant offers four different installation methods. We recommend using one of the following two methods:
- Home Assistant Operating System: Minimal Operating System optimized to power Home Assistant. It comes with Supervisor to manage Home Assistant Core and Add-ons. Recommended installation method.
- Home Assistant Container: Standalone container-based installation of Home Assistant Core (e.g. Docker).
Where the tradeoffs are missing entirely. It even lists both approaches as “recommended” with HAOS having a second “Recommended” in it’s description.
2 Likes
Hi 
!
They RESTful sensor (the thing you linked to) is not an Addon, it’s an integration. Furthermore it’s a core integration shipped directly with every HA installation per default. To use it you really only have to follow the very documentation you linked to. You don’t have to install anything additionally.
3 Likes
It’s not an add-on, it’s an integration (look at the URL). All (official) versions of HA runs the core, which includes all the built-in integrations, such as this one.
Just to be clear, integrations and addons are different things. Whatever you found under the integrations Integrations - Home Assistant (home-assistant.io) page, are all part of the core - you’d get all of those regardless how you install your HA.
Add-ons, on the other hand, are services that are “related” to your home setup, and only applicable to HAOS install method. If you want a different database? That’s available as an add-on. Plex? That’s available as an add-on. You want Node-Red for automation instead of the built-in automation editor/engine? That’s available as an add-on. You want to do Cloudflared so that to connect to your HA services from outside? That’s available as an add-on.
So these are official addons: home-assistant/addons: Docker add-ons for Home Assistant (github.com)
And these are community addons: Home Assistant Community Add-ons (addons.community)
And then there are other add-ons that were developed independently, for example Google Drive Backup, or Zigbee2MQTT.
In the background, addons are containers also. They are just packaged specifically for HAOS, so that to smooth out the learning curve for users who choose HAOS.
== An example ==
One might ask: wait a minute, what if I go container-based installation, and want to do Plex? Couldn’t I just install Plex server somewhere else myself?
The answer is sure, of course you could, and that’s the point: you very likely could find equivalents of those HAOS add-ons available somewhere else in a different format, and you could totally do that yourselves if you want to.
Now, what if I want to integrate my HA to my Plex server (that is in another metal box)?
Sure you could do that also. Search “plex” under the aforementioned integrations page, and you will find how you could connect HA and Plex together, and build your own interesting automations.
2 Likes
While that is all entirely true and correct, I think that, based on the context of this thread, that an even finer point needs to be put on it…
Yes, those things are all add-ons and are related to HA OS (and HA Supervised as well) BUT All of those things are also available and can be installed as their own Docker containers even without the use of HA OS or HA Supervised.
Add-ons only provide a way to install and configure those Docker containers from within HA itself.
They are fully available and functional with HA without the Supervisor. You just need to install & configure them yourself.
1 Like
Apart from the “Supervisor’s” automation for setup, there is another point to consider when choosing HAOS/HA Supervised versus HA Container:
In case of HA Container, the HA ingress functionality does not exist. So, if the addon provides GUI front-end, it can be included in HA, but only as an external web-site via i-frame (I think).
Say, I would have five extra addons.
If I want to be able to use their GUI from public internet (like I do access my HA core), then the requirement for authentication (part of addon? Nginx proxy simple authentication? …), firewall, and port-forwarding significantly increases the complexity of the setup.
I am running HA as a container and I would like to understand how to configure Warema WMS Integration as an addon. HA OS or supervised installations are absolutely not an option for me, so here I am trying to figure it out and learn how to configure and run these containers separately through docker.
Can someone please help me figuring out the steps? I guess most of the needed metadata is in the addon-warema-bridge/config.json at 715f0f32c4b4e806ead86ba4c311a42a26097280 · giannello/addon-warema-bridge · GitHub file?
There are people like me which are not confident with docker and Linux using it.
I reuse my jeedom atlas box to run HA. But I didn’t know I ll not be able to use adding.
I ve installed hacs but it cannot provide me everything.
And now I want to install a theme but I need to update a yaml configuration file using vscode and I don’t find a solution anywhere.