Addons for Docker installation

Feature Requests
,
7

Correction: The

If you have the requisite skills to install and maintain Home Assistant Container, the same skillset is needed to answer those questions.

If someone doesn’t know how to install a docker container, to provide an additional service (Mosquitto, Node-Red, Caldav server, etc), they probably shouldn’t lean towards using Home Assistant Container.

Honestly, everyone is free to make Feature Requests but the odds of anyone on the development team taking the time to implement this one are low. Their preference is to direct users towards Home Assistant OS. For example, the backup feature recently added to Home Assistant Container wasn’t to make it more feature-complete but to provide users with an easier upgrade path to the OS or Supervised editions.

2 Likes
8

I believe you have a very fundamental understanding of the differences between Supervised and Container and between add-ons and regular docker containers and how all of the pieces fit.

Add-ons are literally just Docker containers but with a whole lot of stuff added as noted above to make them to be installable and completely managed by the Supervisor. Those same docker containers are still available to you too without running them as an Add-on.

You can literally run pretty much every add-on as a docker container but the difference is that YOU need to configure and maintain it yourself.

Absolutely not at all.

I run zwavejs and mqtt and several other apps that exist as equivalent add-ons as docker containers right now on my HA Container install with no issues.

Most of the time if you are capable of installing HA in standard Docker then you can also figure out that you might need those other apps as the need arises.

It’s pretty much the same way that you know to install an add-on as well. If you realize that you need to run MQTT to get a device working you start investigating how to install it. It’s the same with Zwavejs, Deconz or any other third party app that interfaces with a HA integration.

The user chooses which install method to use to meet their own needs and skill level.

you chose Container (as did I for many of those same reasons that you) and that means no add-ons. BUT by no means does that mean I am in any way limited in any functionality where HA is concerned (especially not “demo mode” whatever that means). It just means I have to configure and run those other apps myself.

EDIT TO ADD:

And I personally find that HA Supervised is actually more limiting than HA Container because of the restriuctions the Supervisor puts on you.

And if there is no add-on for some app that you need (not every container has an equivalent add-on) then you are still going to have to fall back to installing the app into docker manually - which is way more complicated if you use a strictly Supervised install and pretty much impossible if you use HA OS.

3 Likes
9

Exactly, came here to say this.

The other big problem with this approach is (at least I would argue) HA container is installable in many more types of setups compared to HA OS which makes this feature request even more difficult to accomplish. Even more variables and even more edge cases.

Also, I’d argue the ease of getting started with “one command from command line” is irrelevant to the features that it should support.

1 Like
10

Once you know what you need, the big problem is the integration between third part software and HA. Say I figure out that I need Node-RED for that complex automation I want to do. Can I just install Node-RED? Sure, but Node-RED documentation has zero mention of HA. And the HA Node-RED documentation just tells me to click a button in the Addon Store, which I do not have. There is a gaping chasm of missing knowledge that users are faced with just at the point where they have least knowledge about what exactly is required of them.

I would at least have a hope of getting there if there was an Addon Store in my Container HA instance and if, when I pressed the install button, it would tell me “Ok, now you need to start this Docker container with these options along side the HA container, oh and use this kind of default database in your new containers, meanwhile I will add some lines to the HA config to autodiscover that new service that you are adding so it will show up when you are done”. Then I’d have a hope of discovering and figuring out what exactly is needed to get stuff working.

At this point I have two broken parts - a third party server that has no idea what HA is and HA that has no idea there is a third party server it could use somehow. And zero docs on how that is supposed to be connected because everyone that knows already knows and everyone that doesn’t uses the HA OS where that problem simply does not exist as the store/Supervisor autoconfigures it. Oh and also conflicting user stories - with some saying that it all is just trivial, just start containers like you already know how and others saying that it is impossible because the Supervisor API is essential. So who do I believe?

11 Likes
11

Do you really think that we all started with HA knowing all of this stuff?

Nope.

The only Linux experience I had when I started was from running Retropie on a Raspberry Pi.

I didn’t even know Docker existed until I saw it mentioned here on the forums as a way to install HA. Before that I ran HA Core in a venv on a RPi.

But I put in the time to actually learn things.

And it’s fine if you don’t want to put in that time. Just use HA OS or Supervised.

But if you want the freedom then that takes putting in the time to research and learn.

Well, apparently you know how at least a little bit since you managed to install HA Container in the first place. We have to assume at least a minimal amount of knowledge at that point. From there you can learn the rest.

I have literally never heard anyone ever say that on the forums. Not that I’ve read everything here but I’ve spent an awful lot of time here over the last 5 years so I could have missed it but if anyone did say that it was likely a newer user who had no idea what they were talking about.

Or maybe it’s a bit of hyperbole/projection on your part. :man_shrugging:

me. :wink:

or any other user who has been here for a bit.

where did you find this documentation? I’ve never seen it.

But it’s not even necessary to use Node-red in HA, either.

I’ve never used it and again I’ve never been limited in my ability to write an automation without it.

1 Like
12

Read reply 3 in this thread that tells us that it would be impossible for the HA Addon Store to just generate a Docker Compose entry and HA configs for addons because they are “not just docker containers”.

Starting HA in Docker is trivial and also well documented. As long as you have a working Docker installation it is literally one line and that line is provided in the HA documentation. It does not require any knowledge of HA or Docker to do so. It surely does not imply the sudden acquiring of arcane knowledge of how to start Node-RED or deConz in HA-compatible manner and how exactly to tell HA that you have started these things and how HA could then connect to them. A new user would not even know how to see if these thing and the connection is working or not. I have no idea what to expect from HA when Node-RED is fully integrated and working. Why should I, I just found about about its existence days ago?

  • the instructions on the HA side are just to click the button in the Addon Store.

Even a simple hint that for most (?) addons you’d also need to add an integration or a config snipplet to your HA to have HA actually be able use them would go a long way. It is really, really hard as a user in the know to understand what new users have no clue of even not knowing.

I mean, I am a Linux and Python developer with over 20 years of experience. I can (technically) just read the HA, Supervisor and HA OS source code and figure out what it does. But I do not believe that is a great way of approaching new user experience.

5 Likes
13

Again you are confused and mixing concepts.

I never said (and neither did @CentralCommand) that it is impossible to obtain the same functionality for the base app without using the Supervisor API.

He said that it is impossible for the Supervisor to write a docker-compose file to get you the SAME functionality as an add-on because there is A LOT of overhead in an add-on to make the Supervisor functionality available.

BUT at it’s base the add-on is just simply another docker container (with all the overhead added).

You absolutely CAN obtain the same functionality as the add-on base app (but without the supervisor stuff) by installing the base docker image.

And so are most docker containers documented to the same (or similar) level.

most of the images on docker hub have the image documented on how to run it in the same manner as the HA docs do for HA. Or the docs can also be found on the associated github repo for it.

You’re right. HA Container is in no way meant to be for a “new user experience”.

That is what HA OS or Supervisor is for.

You have the option to install those as well.

But you want more freedom. So you chose HA Container.

YOU made the choice. So YOU have to accept the trade-offs that come with that choice.

1 Like
14

Whole heartedly agree. Hence why there are warnings ensuring new users know that they will have to be Linux experts to use the container install method. Really any method besides HAOS.

Also I’m confused at why you seem to be calling out node red in particular for a couple reasons:

  1. node red is an alternate automation platform. HA comes with its own automation platform. Out of all the addons that one seems like the absolute least likely to get a guide (well I guess AppDaemon is equally unlikely for the same reason). Any time invested in that could be time invested in improving the native automation editor. Makes no sense
  2. it’s honestly one of the easiest ones. NR has extensive documentation. And if you’ve used it at all you know that everything it can do is in it’s pallette. Its not even really a docker compose problem, all you do is install this via pallette manager and follow it’s excellent doc and you’re all set. The addon installs other packages for convenience but they aren’t about HA integration and you can find them all in manage pallette. NR basically is a whole separate thing.
1 Like
15

At the end of the day, most of the HA addons are just mimicking what someone that is at ease with docker containers and linux would discard as trivial (“SSH & terminal addon” is a fair example). or just already has in place (nginx, letencrypt, …).

I think there is a fundamental contradiction between finding docker trivial and wanting addons :wink:

1 Like
16

See, the thing is - as a new HA user I have zero clue what Node-RED is, what it is used for and how it is supposed to be used and how it is not supposed to be used. Or deCONZ or Ada or ZwaveJS. All I know is that functionality is added to HA by “integrations”, so when I get said in a user forum that “that thing you want to do is much easier with Node-RED” or “your device will only work via deCONZ”, then first thing that I will go to is to install an integration with the same name. I do not even know what addons do … because it is impossible for me to just install and try them on my HA installation. A user does not want addons a user wants more HA functionality and some of it is locked behind addons.

In some cases this actually works just fine - (I had no need for deCONZ or Zwave, so I just tried that now) the integrations for deCONZ and Zwave JS have a Help button and then in the integration docs there are actual instructions on how to start the required external servers with Docker and how to pair them with HA. That is awesome.

In other cases, like Node-RED, well there is no integration there and the user is lost. The interest is not to “use Node-RED” or learn the Node-RED infrastructure, it is to get more functionality in my HA installation. As you said - there are far better and easier ways to, for example, get SSH/Šamba access or install MariaDB or NGinx server on your computer. People with containers do not need support for that. But for external things that do actually integrate into HA and add to its functionality, there more straightforward documentation or scripted assistance would be welcome.

And to be clear, I do not want to run Supervisor for this to happen. It is not even possible to do so in most setups where HA is run in container. If HA is running in a container, then whatever solution is there for addons must also be run inside a container. Either the same as HA Core or a separate one.

If you are saying that a user can easily get the same functionality on their own, then it must also be possible to generate some combination of docker-compose config, derived Docker containers and HA configs that would also enable the functionality. And then expose them via the same Addon Store interface. Without any Supervisor at all being in the picture.

Or at least a documentation section describing step-by-step how to get a few common addons running and integrated manually. deCONZ and ZWave JS integrations are really close to providing that documentation, so they can just be linked from the main documentation pages. That would be a really easy win. Having a couple more examples for how to install and enable an addon that does not have an integration of the same name readily available would help a lot, including an addon from community, explaining exactly where to find the information about: what extra container needs to be started, with what Docker settings, with what configuration of the server inside and where to find out what settings need to be set in HA. If that is generic enough so that the user can then look at Awesome Home Assistant and apply the same procedure to get (most) other addons working on their own would be a major win for usability and user education.

P.S. That “excellent doc” link opens to an empty page for me, just the headings, no content :smiley:

4 Likes
17

There’s a node red integration in HACS GitHub - zachowj/hass-node-red: Companion Component for node-red-contrib-home-assistant-websocket to help integrate Node-RED with Home Assistant Core but overall nodered is a separate automation platform.

I think in general installing things without researching what they are first is ill-advised. For example, some prefer node red but I’ve personally preferred HA automations and never had anything I couldn’t do in those.

At the end of the same seems this is more about better documentation than running addons for a container install which I think is very unlikely to be done by the developers.

18

To prefer something over something else you first need to try both and thus be able to install both. Addons bring amazing additional functionality to HA. Like Zwave support and voice interaction support and who knows what else. AFAIK the Matter support is also now coming via Addons. That would be pretty important, don’t you think?

It is more about having a viable way to have the Addon Store be there in the container install, including the ability to add community addon sources. Even if all that the “Install” button was doing is pop up manual instructions on what to do for each addon. If addon installation is as easy as some people here are claiming, then there should be no problem pre-generating a viable docker-compose entry for an addon container (possibly using a HA-specific container) that would just work most of the time.

2 Likes
19

Having read bits of the replies here and coming in as someone who’s first interaction with docker was setting up HA container:

Everything in the docs suggest HA container is an advanced method to choose, and you know from the start add-ons are not an option (well HACS is but that’s different).

Whilst setting up HA in docker is simple for someone who understands docker, docker itself has quite the learning curve so is not the best choice for someone who isn’t prepared to learn the ins and outs of how it works. And that also includes how to use it and extend the functionality of HA.

This is why HAOS and HA supervised exist. I do understand where you’re coming from wanting add-ons but the fact is if you choose HA container you’re expected to take on the role of the supervisor in the other distributions. Expecting to spin it up easily and then hand over control defeats the point of why people that choose docker make that decision.

Plus you can always just use proxmox and have HAOS installed along side debian or Ubuntu running the rest of your docker apps.

I think rather than asking for add-ons/integrations in docker container the preferred option is to get involved in updating the docs or making a guide on the forum that can guide people through setting up docker/docker-compose AND extending functionality. So far in my experience finding those guides and examples as been the difficult part.

3 Likes
20

Matter has already been confirmed to be shipped as a standard docker container for docker users as well. Again, nothing in an addon that CANT be run in docker as well.

This is still functionally the same as doing it right through docker, after it’s installed you’d still be asking yourself “how do I integrate it with HA?” so I don’t think it solves any issues. The main problem it seems is how to find the answer to that question.

2 Likes
21

Actually, 90% of the addons is picking some standard Dockerfile for a product and adding the HA “sauce” on top :wink:

1 Like
22

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 :grinning:

1 Like
23

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 :slight_smile:

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
24

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
25

Reading through the thread, @aigarius , I believe you have to pick:

  1. If you value easy maintenance more, then go with HAOS install.
  2. 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
26

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