Hello all,
I (almost) successfully migrated from docker based install to pythonic way (being a python person, that was the most natural for me). Instead of doing from scratch new install, I simply started
hass -c /path/to/config which worked great. Got all my ZHA etc working, all good 
However, where I did the migration to enable supervisor and addons, neither are showing up.
Is there something maybe in the DB that needs to be changed or something like that to enable these ?
Thanks all!
I’m not sure that HA core install has Supervisor.
As far as I know the python installation has no supervisor and therefore also no add ons.
Okay. I mean, I can understand the docker installs do not have that because of the immutability of the container (at least not beyond the volumes).
If then all the pythonic way does is install core, then I am not too sure what the OS version has that installing it “bare-metal” does not and disables that.
If it is how it is, I am fine with that and will dedicate a Pi for it, but very curious as to why the most low-level way does not allow for all the features 
in essence, there are 3 ways;
First option wants to own the hardware fully, no extra software is allowed.
Second option, hardware can be shared for some other extra software.
Last option, similar to second.
Indeed, that makes sense considering what I am seeing now that I created a VM with HaOS on it. Which works great and some of these addons are great.
Typically what lead me to re-do this install is only because every googling I do about HA + Mosquitto leads to the addon. Where I already have Mosquitto deployed, but without much going for the configuration and can’t quite figure out the authentication from / to HA / Mosquitto.
I only want to use Mosquitto as a broker bridge relaying to another MQTT backend which will persist the messages.
Anyways, back down the rabbit hole of securely configuring HA + Mosquitto I guess 
So you already have Mosquitto installed on the hardware itself (no add-on and outside of HA)?
Mosquitto has the ability to create security options and then you just give HA those credentials to log in to Mosquitto.
I’m confused about what the goal is and what you can’t do, I guess.
I suppose on this topic strictly then, good to “close” as the new install on VM with HaOS does have the addons etc. available. Definitely considering keeping that instance, but will work on using the non-addon install of Mosquitto.
Hey @finity
Mosquitto has the ability to create security options and then you just give HA those credentials to log in to Mosquitto.
Do you have documentation on that to point to ?
I did see the addon did configure HA and Mosquitto to talk to each other, which is what I wanted to get to but doing it “myself”.
I kind of depends on how you installed it but the mosquitto config file is located at “/etc/mosquitto/mosquitto.conf” if you installed it directly on the OS.
and example configs can be found at “/usr/share/doc/mosquitto/examples/mosquitto.conf.example”
the HA MQTT installation UI should tell you what you need for that including the ability to add a username and password (the same as the one you created when you installed mosquitto).
and if you need SSL (I don’t so I don’t really have any insight into that) here is the HA docs for that:
You’re aware that the core/venv/python install is the only one of the 4 which does not use docker right?
Supervisor is designed to be a docker container which manages the system it resides in, particularly rhe docker deployment. It is written in python but it does not function outside of a container in any meaningful way. And addons basically consist of two things:
So it’s impossible for a core/venv install to have supervisor or addons.
The most low level way would be HAOS which does.
Hello.
I was not aware that the HAoS install would come with docker in it, I did not go as far as poking with lower level OS settings, I just wanted to see if the mosquitto mqtt config addon was to make it easier to configure MQTT, not do it for me and run your own broker
Not surprised that the OS version runs containers though, I suppose that makes sense.
And it would be possible I guess to have the core/venv install do control containers, with the docker lib… if it weren’t a few CVEs behind 
@DavidFW1960 I disagree, that’s the highest level, where user has little to no access to anything else but the software. That’s apple level of settings, vs Linux level of settings.
That’s fine but you’re wrong. The devs are steering everyone to what is essentially a one click simple install. If you think managing a linux system is lower level than pressing one button to update and having everything completely managed for you you’re wrong big time.
Lower level doesn’t mean least path of resistance or level of experience / knowledge of the system.
I don’t disagree with a one-click getting started approach, that’s totally fine, but lower level in CS, that’s not what that means.
i.e. for those using the UI drag-and-drop tool (which I am forgetting the name of) to create workflows, that’s high level. Implementing the templates in Jinja is lower than that, lower again would be writing the python code.
You mean lower level as least path of resistance / wizard and wrapped up solutions. Which is totally fine, different meanings in different “worlds”.
check out this table here
Also here Linux - Home Assistant. Supervised is considered an advanced installation
Yes, that what you call low-level in CS.
I have looked at that table, I have not tried all 3 of installs, jury under deliberation over which one to go with.
To @CentralCommand 's point, in the end, all of this could be a giant docker-compose file really, you just need to learn the docs of each integration.
It’s kind of not too cool to start a new thread talking about the same subject while not acknowledging the help someone has already tried to give you.
Yes and no. Like I said addons come with two things:
In addition supervisor sets up a number of options by default including args during the build process, environmental variables at runtime, standard mounts, DNS access, etc. Basically if you tried to build and run an addon image without supervisor it would fail. You would need to dig deep into it to figure out how it works and most likely modify it to remove the supervisor dependency. It is likely easier to instead find a different image for the service (like say mosquitto) that is designed to be standalone deployable and start from there, copying over whatever config files from within the addon image make sense.
However part of why people like HAOS is that’s really only a small part of what supervisor gives you. Supervisor also does discovery. For instance when you install the Mosquitto addon then the Mqtt integration in HA is discovered. You can install it with one click, no configuration required. And if later you install another addon that uses Mqtt (like say zigbee2mqtt) that just works as well. It will discover your Mqtt configuration from supervisor.
Supervisor also informs you of updates to addons and allows installation with one click without disrupting anything else. And provides backup and restore functionality for addons and core. It listens for new USB devices being plugged in and informs core and addons about them, giving them immediate access to them for services that need it. Addons can also come with a custom apparmor profile that supervisor can then load and enable on the fly when the addon is installed or updated.
There’s a quite extensive list of things supervisor simply handles behind the scenes that addons bank on. Many of which go far beyond the capabilities of docker compose. You can do all this without supervisor but you would need to put in a lot of work to get parity with what addons have ootb.
started a new thread because the issue at hand of not seeing addons/supervisor was “solved” due to the nature of the installation options at hand and did not want to dwell on the MQTT stuff in here.
And the other thread specifically is to address the “lack of visibility” over the MQTT configuration options.
Nevertheless, sorry if that offended you.