This still stands, pretty much as said. My goal is to have as little as possible Docker containers related to HA. So my (unknowing) ideal would be to have 1 container for HA, in which (for example) HA, an MQTT broker and something else related to HA run. So everything related to HA is inside 1 container.
This one was more of a general remark, probably related to something like installing HA Supervised inside a docker container, but that idea has already been removed from my head.
As for who’d want to run it this way; I much prefer core over supervised because I don’t need (nor want) auto updating as I can manage everything on my own and there are update checks available for core (using binary_sensor.updater) and watchtower for docker containers.
Since add-ons are pretty much nothing more than docker containers (with customizations to be able to interact with HassOS/Supervised), they can be replicated with a proper docker-compose.yaml file and some integrations with Lovelace.
This is known as the “appliance” approach. There are pros and cons to this. Pros are that you have a single place to manage your home automation “system” and a super simple topology. Cons are that you have a single point of failure when something breaks or goes wonky (Yes, I said “when”, because with home automation, it is never an “IF”) and a simple topology will fail when your system grows beyond it.
In my house, I have over 1000 entities (150+ devices) operating on Zigbee (67 devices), Z-Wave (14 devices), and WiFi (97 devices) and I also capture energy and atmospheric data (temperature, humidity, lux, etc). All of this traffic (and trust me when I say, there’s a LOT of traffic) gets captured in various data stores (InfluxDB, MariaDB, Percona and Cassandra). Not to mention my MQTT traffic (of which I actually run a cluster of MQTT servers to reduce and spread the load around). I often tell people that if there is something in my house that can be automated or made “smart”, it probably is. The funny part is that compared to some of the users here, my environment is still considered to be small.
I’m sorry, but you should really work on your wording. You can’t go around saying it can’t be done if it can be done. It may not be the optimal way (or even anywhere close to a good idea), but it can be done, like aibish and code-in-progress mention. Saying it can’t be done only confuses those who have little to no knowledge on the subject, since they see others doing it, but then you say it simply can’t be done, as if that’s a fact.
I get that you want to prevent people from doing something dumb, but saying it can’t be done when it can is not the right way. People need to understand why something is a bad idea to really accept and comprehend it, if the only reason they know is “because some guy online said so”, that’s not gonna stick.
I appreciate the effort, I really do, but just repeating “it can’t be done”, despite others saying and showing it can be done, doesn’t help, it only confuses.
I guess you are right but I guess I was using “can’t” more in the colloquial sense of “you can but why would you?”.
I mean technically you can have a windows pc with vmware on it running Debian in a vm running docker in that with a raspbian os inside running home assistant supervised along with mqtt, nginx, node-red, zwavejs, pihole, adguard, etc, etc all in the same container.
If your skills were up to the task you can technically do anything you want.
But why would you?
If you really understood docker well enough to completely build the image containing all of those things in it you likely would understand docker well enough to know that you wouldn’t want to do that.
