There are entire threads and posts on this topic where that can be discussed. It is specialised, but there are reasons a small amount of users (like myself) runs core. Personally I need certain OS access and don’t need the additional complication of mapped devices when I can access it directly (among other reasons). I also find it pretty easy to maintain, but I have a software background.
Personally I think the docs should by default assume HAOS.
My experience is different: I usually see people directed towards HAOS. Supervised is popular, but there was even a time they wanted to pull it (some years ago).
Interesting discussions, and many valid points.
My initial comment was if people doing How-To’s and Guides could acknowledge that there are those of us not running HA-OS or Supervised.
There are many reasons to do either. My reasons for running HA Core in a container, is for the most part historical. When I began with HA there was no such thing as “Supervised”. It was back in the days og HASS.io
With a containerized installation, I can move my whole installation from one machine to another in the matter of seconds. I can create failover and cluster systems. I can even run HA in Google Cloud.
home assistant.local is just an mDNS name, so you just need to configure the mDNS advertisement on your container or on the system hosting your container to map the correct AAAA (or if you’re still using older internet protocols, A) records in mDNS.
I was in the mindset of the OP that “Supervised” installs meant both HAOS and HA Supervised.
I will say again that as far as I know there is nothing that a non-supervised-type install can’t do or needs to do differently than a supervised-type install except where add-ons or backups are concerned.
If you did run into something and you have been running HA for a long time then it’s more likely that you ran up against the possibility that you don’t have “default_config:” in your configuration.
I run HA Container (since forever) and I know I don’t have it. So I know that I need to keep track of the new things that are added to HA that would normally be enabled by default if that entry is in the config and I know I need to add them manually. I’m pretty sure “my:” is one of those. You said it’s enabled by default but that’s only true if you have “default_config:” in your config.
But that’s also not something specific to a non-supervised-type install. Any install type could have that happen if they remove (or never added) “default_config:”.
I use container installation and I’m not sad that I missed out on getting my NodeRED nuked or breaking my setup with updating docker to v25.
When you chose which install method you want, it said add-ons are not supported. Your second image clearly says “add-on”.
You can probably just search “esphome docker” and easily find how to achieve the same as the add-on. But if you don’t like doing that, you should’ve chose a different install method.
I feel like a lot of folks in this thread are missing the forest for the trees.
I stopped running HA OS many years ago when I got tired of my RasPi 3 eating SD cards. I now run HA and ancillary services like MQTT, Postgres, Zigbee2MQTT and a dozen other services in a Nomad cluster with virtualized filesystems to a NAS for storage.
I went into this knowing I wouldn’t get the one-click-addon experience. I accepted that I have to figure out how to run things in my cluster myself.
The frustration I share with the OP is when no bone is tossed my way with any new things that come out. A good example is the Open Thread Border Router with the SkyConnect stick. The official docs say… install the addon. There are no further suggestions. I have not bought one partially because of this.
Now, from previous experience I happen to know that HA Add-Ons are in fact Docker containers, and I happen to know if I go looking I can find them and usually figure out how to get them talking to HA when running in my cluster. But I’m reading through a Dockerfile to figure this out instead of a bit at the end of the regular docs giving some hints.
Something like
“oh btw you need ports 1234 and 5678 open, and hand the dockerfile an API token. You might also want to give it a few env vars like this and that”.
That could save me (and others) a few hours of staring at log messages.
This isn’t a demand. As a fellow open source maintainer I know how time consuming it is to handle edge cases well. I don’t expect support and I don’t expect a slick interface that HA OS folks should expect.
A few lines of hints to save me needing to dig through yet another huge Dockerfile would be very much appreciated though
This has nothing to do with your installation method.
I can understand that. I avoid the Docker method for the reasons you mention too: There are a whole lot of additional (often unclear) steps and often the benefit is debatable.
Mind you, I’m not defending any of the other methods, since I run Core, but I think a fair argument would be that you should rather run Supervised. It gives you many of the benefits of HAOS, but without its restrictions and none of the Docker complications of the Docker method.
Just to understand your situation better: Was there a reason you didn’t opt for Supervised?
On my humble opinion, a major setback is that Supervised installation lacks important patches to kernel that are critical and optimized for better experience even functionality compared with HAOS.
Also, the guide as well as supervised installer is somehow outdated, requiring high level of Linux knowledge to get them work.
HA dev spend countless hours on these patches and they make a difference I think.
This is true, and these days I suspect the various cards I used at the time were substandard. I have also experienced zero filesystem corruption events since switching to my current setup nearly 5 years ago.
But that’s not really the point of my post, that’s another tree in the forest.
Just to understand your situation better: Was there a reason you didn’t opt for Supervised?
Running that on my cluster setup would be difficult. My cluster brings a variety of benefits to running the many services I run out of my home network. I quite like the ability of my services to automatically recover from hardware failures or network interruptions. I can plug my ZigBee stick into any usb port on any of my cluster devices, and within a minute my mesh is back online. I’m also not personally interested in the added complexity of directly managing a Linux system. After all, that’s why I run a cluster and use Docker for my services.
Indeed I would make the argument that it is not Docker that is the complexity issue here, it is what is in the container that matters. The HA Add-On architecture is brilliant for abstracting out the setup of additonal services in a way that makes it very easy for developers to contribute additional functionality. Unfortunately this doesn’t encourage documenting or exposing the information necessary to DIY the management of those containers.
I’ve rolled around the idea of an HA Add-On shim that translates the Add-On installation into k8s/Nomad cluster jobs to help bridge that gap, but I also have a project list a mile long already.
I agree that i would be nice if the add-on creator/maintainer would simply add a Docker run command to the docs somewhere so that non-add-on users could be able to get the equivalent Docker container up and running.
I doubt it would be much additional work since they’ve already done the work of figuring out what is needed and then even more work in adapting that Docker run command into an add-on.
it would be a lot of value added with a minimal amount of work on the devs part.
You cannot run add-on containers outside of Supervisor. So converting from an add-on to a standalone container will actually be significant work, depending on all that is involved.
Starting from an application that already has standalone container and working to an add-on is the usual route.
Also, in regards to ESPHome specifically, do these instructions for Docker not accomplish the same?
Yeah, I know that. I don’t think that anyone has suggested otherwise.
That’s my point.
the add-on dev has already likely created a standalone container (or at least someone has) and has already worked out the commands to use in the docker run command to create the container.
then they put in additional work after that to create an add-on.
they could fairly easily (I think) provide that original docker run command to users who don’t use the add-on to create their own standalone containers.
Working backwards from the add-on to the required docker run command to create a standalone container is exceedingly hard to figure out. I’ve tried a few times and usually end up just looking for other ways to get the same results.
And of course I’ll add the caveat (as I’ve already said above) that we made the choice to run the version of HA that we did so of course it’s on us to figure out how to run the containers we want. But it would just be a gesture of good will to think about non-add-on users when it would be almost zero additional work to provide that info.
What spurred me into writing the OP, was some frustrations today when I sat down to explore “Year of the voice”. Since I don’t have HA-OS (or Supervised), I couldn’t just follow along on the excellent video tutorials made by Smart Home Junkie or Everything Smart Home, or Dr. Zzs, because they all assume the use of Add-ons as default.
So I’ve now spent the better part of a whole day to figure out how to install Whisper and Piper in my Docker Container solution, and link those into Home Assistant.
And it actually works! (I may also write a tutorial on this)
Thank you for pointing that out… (but I think you got my point - even though I was slightly unprecise?)