I’m aware of what Supervisor brings to the table when installing HA. What I’m curious about is what do I give up if I use supervisor? I’m comfortable with Docker so I’m not afraid to set it up on my own. Do I lose configurability when using the dockerized supervisor? Are there any downsides at all?
Put another way, are there any benefits to running HA Core in Docker that you don’t get with Supervisor?
I was going to respond on this but found a recent response to another similar post that articulates the differences very well: Here you go: New Here - HassIO vs HassOS vs Home Assistant?
The only real “downside” (if you want to call it that) is that the supervisor auto-updates without you having any control at all as to when or if it does it.
It might not sound too bad until you realize that more than once a supervisor update crashed peoples HA installs in the middle of the night (or some other inopportune time).
Granted it’s not very frequent (some would say rare but it has happened) but it is the one thing that has stopped me from switching from HA Container to HA Supervised.
Other than that I can’t think of any negatives that affect Supervised that don’t also affect Container.
Interesting, in my opinion, the easy “auto-backup” option mitigates this to some extent. I guess my next question is: is there a way to move from Core in Docker to Supervised without redoing all my Device names, Automations, Scenes and Node-red flows?
Just to expand/clarify for people who may be unfamiliar with the differences between the two installation methods that employ Supervisor:
Using Home Assistant OS, the Supervisor auto-updates the underlying operating system (Home Assistant Operating System) automatically and one has no control over it. As for the Home Assistant software itself, Supervisor notifies you when an update is available (but it will not auto-update it).
Using Home Assistant Supervised, the Supervisor does not auto-update the underlying operating system (Debian Linux or whatever other distro you may have installed) because that’s beyond its control. As in Home Assistant OS, the Supervisor will notify you when an update to the Home Assistant software is available (but not auto-update it).
For future reference “Core in Docker” is officially called “Container”.
The configuration of your system is separate from the selected installation method.
Since when?
As far as I know the supervisor has always auto-updated itself and still does.
Edit: unless you are referring to the HA container itself (i.e. v112.5) and not the supervisor container? If that’s the case then you’re right. But that’s not what I was referring to about auto-updates being an issue. I was talking about supervisor auto-updates happening and crashing people’s HA in the middle of the night.
Quoted: But Edited Too
Yep This is my goto install for my Production Machine.
I generally skip the " .0 " releases on this to avoid any major breaking changes or “issues”. I update when I want but generally from home (I’m not as brave as Tom (who ‘shits bricks’) but still upgrades when about 5,000 miles from home 
).
I’ve never had a problem with over 1000 entities, including : - 34 Z-Wave nodes, 225 Automations, 340 sensors. But I do run ‘as vanilla’ as possible with yaml front end and automations/scripts
Nope, I’ve never seen that, always manual (This is using the supervised install over own OS (though I don’t actually use debian))
You’re right, we were referring to different things. I was talking about auto-updates to the operating system, you were talking about auto-updates to the Supervisor itself.
I believe you are right about the Supervisor’s ability to update itself. To be honest, I have never looked closely at its docker container to determine its version. My production system has been running Home Assistant Supervised since March and I have not yet experienced a problem with a defective Supervisor upgrade but the potential is definitely there.
What I have experienced is a glitch with a test system that runs Home Assistant OS and it was with its operating system upgrade. Several weeks ago there was a buggy version that was released then promptly retracted. I never received the buggy operating system upgrade (others did and it crashed their systems) but it kept erroneously reporting a newer version was available (which was untrue because it had been retracted). I simply ignored the message and eventually it went away because the underlying versioning information was corrected.
Understood, but is there any documentation I can use to see exactly which files need to be transferred to make the transition between the 2 seamless?
What hardware do you have ?
In my case, move the z-stick, copy the yaml files and directory structure, paste into new enviroment, reboot, good to go
Edit 1 : This assumes you have not created any ‘helpers’ through the GUI, if you have, you ‘may’ have to copy .storage and not quite sure of the consequences from that. But from there on out take snapshots to restore on any supervised system. Though as they are basically zip files you can probably do a lot more.
Edit2 : If you did create ‘say’ input booleans through the front end you can use : -
{% for state in states.input_boolean -%}
{{ ' state.entity_id }}
{{ '' }}
{%- endfor %}
Will give you a list of them and you can modify this to create then in yaml or just as a reminder list to redo them
It’s a Pi 4 with an Aeotec Z-Wave stick and ConbeeII Zigbee (running ZHA). Throughout my journey in HA, I’ve seen references to sqlite databases, .storage directories, zwcfg xml files and pyozw databases. I suppose I can copy everything over but I don’t want to break the new setup with a potentially invalid (for supervised HA) config.
What OS would you go for ?
I use rasbian on a Pi4
Pi4’s don’t play nice with SSD’s properly yet
I followed tha James Chambers advice to get it to play (awaiting final eft (eprom upgrade) to do this properly)
Do you plan on SSD or just SD ?
The HA OS (edit: on a Pi 4) does REALLY not like running from SSD - but again, some people have suceeded
Copy everything in the configuration folder, including the hidden .storage directory.
Yes, Thats a good point as though (say) your z-stick will know all the devices it connects to, it won’t know what they are called in your installation and thus can’t map them to the device names you have given them and use in your automations etc., good correction/catch !
as long as you only copy the “/config” directory - the entire directory where your configuration.yaml lives including subfolders - and you are running the same HA version - v112.4 for example - then you can’t have an invalid config based on the new install being supervised or any other install method. All install methods of HA use exactly the same configuration data.
There might be some strangeness with the db tho so you might need to delete that and let the new version re-create it.
But again, really, if you are pretty comfortable with Docker then I’m not sure that I would go thru the trouble of converting for the minor benefits you get - which are only add-ons (if you are fluent in Docker those aren’t really an issue since you can manually run a container for pretty much anything that is an add-on except for possibly some very rare cases) and snapshots. those are the only ones I can think of.
Yep, one click backups is one of the things I’m after. Easy config of add-ons is another. Adding them manually to my docker-compose file has been working but has been a hassle. Of course once I’m there, I might find that what I had before was better but that’s part of the learning process!
Good attitude!
Two years ago, I started with Home Assistant Core for my production system. Months later I created a test system with Home Assistant Container. In March, I changed my production system to Home Assistant Supervised (on Ubuntu) and created a second test system using Home Assistant OS (on a spare RPI3).
It’s been a great learning process and now I’m comfortable with all four installation methods. For my purposes, I like the management convenience provided by the Supervised and OS editions. It’s good to have choices.
