HA Supervised has no real drawbacks if you can manage a Linux install and a lot of advantages nevertheless comments about supervisor seem to abound.
1 Like
Alright, I think I need to explain the Supervisor point a bit more it seems 
First thing, if we’re talking about getting your system long term stable, we can assume that you are not a complete newbie at HA anymore, that you know what you want and need from HA and that you know at least the basics of host OS administration. I’m not talking about needing the reprogram anything here, just Linux OS system upkeep.
Two important cornerstones of long term stable systems (and that is also valid outside of HA) is very tight update management (if you update and when you update which component) and full control over all individual subsystems that work together: the host OS, separate subsystems like deamons and servers that provide services but aren’t directly tied together (zwavejs server, Mosquitto, etc) and finally the HA core.
The Supervisor defeats all of that. That’s not only because of technical reasons, but mainly due to the way it is managed by the developers. It is the only component in HA that updates itself without asking for your consent and you can’t (easily) keep it from updating. This destroys one of the stability corner points of tightly managing update schedules. I mean, just search around the forums or Reddit about people who complain that their systems broke after the Supervisor updated itself out of the blue.
The supervisor is a black box. You have zero control over what it does. And that is by design. It does a lot of things behind your back and without your consent, like the time where they started sending your hashed passwords to a third party website without telling you and without letting you opt out (an opt out was eventually added after long and tiring discussions). All that might be acceptable for new users to keep them from breaking things - and even that is up to debate. But it’s absolutely impossible to manage when your priority is long term stability.
And finally, the Supervisor isn’t really needed anyway unless you really value the click’n’play experience over everything else. If you just need something to manage your containers, there are industry proven solutions to that you can use, especially from the Kubernetes world. That is, if you want a containerized system at all. For very simple local systems that won’t change much after initial setup, containerization might not be the right choice. But this ultimately depends on your setup and experience.
TLDR: For best long term stability you want control. Supervisor is a black box that takes away your control, by design, to make things easy.
3 Likes
These problems exist in all automation and to some extent all software. It is simply due to a large number of dependencies and inability to test. The problem domain is too large to expect everything to work all the time.
My only advice is to upgrade on your own terms. If things are working for you you don’t have to upgrade. Only upgrade when you need something and have time to deal with any issues. Have a rollback plan that you have practiced. But keep in mind that the longer you wait the harder it will be to upgrade eventually. And only integrate things you need, to try to limit the problem domain of what can break. If you wait too long it may be easier to start over from scratch.
I use HA core on docker. I stop the container and backup the entire config volume routinely and before any upgrade. To restore I just roll back the image and restore the config volume.
2 Likes
I appreciate the convenience of Supervisor’s management features but I’m less enamored with its ever-growing policing functions.
-
It rates your instance using two ‘red flags’: Unsupported and Unhealthy.
-
“Unsupported” is relatively benign and means your instance deviates from ADR-0014. For example, you’re using something other than Debian as the underlying linux distro. It typically doesn’t impact the system’s operation but, from the development team’s standpoint, your instance is no longer eligible for official support.
-
“Unhealthy” indicates something in your instance may affect Home Assistant’s operation. If your instance is determined to be Unhealthy, there are consequences. Supervisor will prevent you from upgrading Home Assistant and installing/upgrading Add-Ons. Your system is now knee-capped until you fix/undo whatever is the source of the Unhealthy status.
-
Supervisor automatically submits a hash of your passwords to haveibeenpwned. When this feature was discovered, many users balked at having their passwords (hashed or not) submitted anywhere without their consent. In addition, the submission process was not performed just once but repeatedly. After receiving many complaints, the team provided a means of disabling the feature via the CLI (Command Line Interface). Disabling the feature carries no penalty (i.e. your system is not marked as Unsupported).
-
Supervisor automatically checks for the latest software version and confirms Internet connectivity (by connecting to version.home-assistant.io). It performs this function every 10 minutes with at least two DNS lookups each time. If you want to change this frequency (lower or higher), you can’t because there’s no control provided. If you use Home Assistant OS, it performs a separate internet connectivity every 5 minutes in addition to the 10-minute interval performed by Supervisor.
-
Supervisor checks itself for source-code modifications and, if it detects it has been altered, marks your instance as Unhealthy. Effectively, Supervisor protects itself from being modified. The value of this feature is debatable because a bad actor wishing to add malicious code can strip out the entire self-checking feature. However, what it does do is prevent casual, non-malicious users from modifying Supervisor (because removing the self-checking feature is non-trivial).
-
The self-checking feature, known as “content-trust”, can be disabled via a CLI command. However, there is a penalty and your instance will be marked as Unsupported. Unfortunately, there’s a bug in Supervisor 2021.5.4 because it will also mark your instance as Unhealthy. In other words, regardless of whether “content-trust” is enabled or disabled, your instance will be Unsupported and Unhealthy (with all the constraints imposed by the Unhealthy status).
-
Supervisor automatically inspects any docker containers you have installed. If the container is a member of an “unsafe” list, your instance is flagged as Unsupported and Unhealthy. Even if you know the container’s function is benign, you can’t instruct Supervisor to exclude it from its “unsafe” list (and you can’t modify Supervisor’s source code).
-
Supervisor automatically upgrades itself and there’s no control over that function.
NOTE
If you would like more control over Supervisor’s configuration, such as adjust the polling frequency of version/connectivity checks or determine when Supervisor is upgraded, please consider voting for the following Feature Request:
7 Likes
That was developed ad a compromise to reclaim work from an overworked developer. The initial announcement was to remove the official Supervised option from HA. The compromise is support ONLY for vanilla, unmodified Debian.
The supervisor checks make a LOT of sense to people customizing things and expecting support here & especially official support. As previously stated the supervisor experience is not set up for the advanced user who wants total control. Unfortunately, the devs killed the lightweight Hassbian scripts that were a compromise between the 2 extremes.
Yes, I recall supporting that.
Arguably, providing control over Supervisor’s activities is not limited to just advanced users. for example, it’s been a long-standing request to control Supervisor’s upgrade process. It upgrades without one’s consent and there have been incidents where the new version introduced serious bugs.
1 Like
I run my HA in ESXi and I’m a bit paranoid, so I have rolling backup every saturday morning automatically by my Synology NAS and keep the latest 4 backup.
If something happen, I can rollback to my latest backup.
Also, when doing upgrade on major version, I always backup first.
Last year when I upgrade HASS OS, it corrupt my VM and have to restore from backup in 5 minutes up and running again.
1 Like
Guys, very big thanks for participating in the discussion, but we are drifting away from the topic a little.
This is not about backups. I do make them too and use them too.
This is more about the situations, where you are standing in front of the choices: When i don’t upgrade now, Integration 1 stop’s working, because there are changes on the side of the API.
So you choose to upgrade, but Integration 2 stops working, because there are changes in the new HA version, that makes it fall.
Then you are on a point, where it’s a choice between a smash in your face or a kick in your butt. But there is no more choice of cuddling.
What i do not understand: Like the media player for Pioneer AVR. My physical Pioneer AVR is a bit old. It does never get updated anymore from the factory.
So that has to be as easy, as maintaining the code, that works now. But somehow someone somewhere has the urge to change the code, maybe to support never players too, but does not leave the working code intact, so that once supported hardware maintains working.
Like the old saying: If it works, don’t fix it.
I can’t weaponize my self against such changes, backups or not, this breaks stuff and there is nothing, a user like me can do about it.
Also that Z-wave story did costs me a lot of irritation. When the Z-wave JS was anounced, there is said, i can remember that exactly, on the HA site, that there WILL come some kind of conversion tool to make the change easy. Months later, when we asked, where that tool is, the answer was - do not count on it. WTF. So I spend DAYS figuring out, how the heck I will migrate all my Z-wave stuff without bothering my family with broken stuff. I did it, they did not notice, but the effort needed was way too much, it took unplanned, unwanted freaking lot of my free time. For what? To make work something, that did worked before too…
Guy’s, not everyone here is a coder. Not everyone is an Linux-server-park maintainer. Not everyone here does understand Python.
There are a lot of people, like me. I’m a technician, working with big water pumps, gigantic airco’s, cables thick as your leg. But I’m not a software engineer.
My only advance is, that I’m really very capable of copy/pasting stuff in an editor. Sometimes i even understand, what the code is about. But I’m not far enough to debug or write code myself.
I still love to find out, how stuff works and I’m happy, when I get it working. And yes, I was ranting out of frustration, but even on my level of experience, I’ve build-ed a nice, stable system, I can be proud of. And I now do know a lot more, than 2 years before.
I’m just stating here, that some changes could be lot less painful, if there will be some guidelines, how to keep things working, which do work already.
I can’t influence that with making backups…
Thank’s for listening, thank’s for thinking about it, thank’s for every piece of code running on my machine. I really appreciate all yours effort. The devs, I’ve communicated with, do know, how much.
I still love HA and will learn more and more every day.
And now, I’m going to try to find out, why the Garmin integration still does not work even after the second official fix… 
1 Like
this is the closest I have seen.
https://zwave-js.github.io/zwavejs2mqtt/#/guide/migrating
Just coming from openHAB I can say categorically changes could be a lot MORE painful too. the main reason I stuck it out over there as long as I did was due to a possible fork and not wanting to abandon a friend who was extra busy IRL with an International move.
Actually there is, file an issue @ GitHub.
Issues that are not filed on GitHub have little to non chance of being fixed.
Even if the integration does not have an active codeowner, other people are actively looking at issues, both long time contributors and people that want to do more (like contributing their first bugfix)
1 Like
I know, and I’m very active on Git even helping out testing some fixes 
1 Like
I’m curious to learn why you chose Home Assistant?
It’s not a commercial product for use by the general public, it’s a software project created by hobbyists for hobbyists. It constantly evolves and often requires a fair bit of research and technical knowledge to maintain and/or fix it.
Making Home Assistant usable by the general public is an aspirational goal but, as you have witnessed yourself, it isn’t close to attaining it yet. Just keeping current with Home Assistant’s monthly updates is more time and effort than the average consumer is willing to invest in home automation.
1 Like
No offense, @123, but please, read all my contribution in this topic again, and search for my posts on the forums to make a picture of me, before you start calling me something, I’m definitely not.
I’m more familiar with this stuff, than average consumer, and actually this comment hurts. I’m just not a coder.
But I’m a lot, as i did manage to build the server, docker, portainer, plex, HA, and build it up to a working project. I’m a hobbyist, definitely.
1 Like
I called you nothing; I simply asked a question which you didn’t answer but chose to play the victim.
Then your first post sounds like it was written not by a hobbyist but an anxious newbie. Even the title is overwrought: “getting scared of my future with HA”.
True; it was clear from the first post. Misery loves company.
2 Likes
Ok, the tone you are setting is all, but not constructive. I’m not going to argue, all I’m trying here to discuss with the goal of improving for all of us. Until now, the discussion was very nice and a lot of good contributions have been placed.
But if it has to go this way, I’m finished. I don’t need this, and no one here does too.
2 Likes
You did not communicate that ton well from the start then., especially with comments like this.
Getting only the critics out of the context, where I at the same time price HA to heaven is very easy way to turn this in to a attack against me. I did nuance my “rant” in the closing of my first post very clearly.
But really, if this has to be turned now into well/not child like war, just close this topic, I’m out.
I was trying to discuss very globally, said my cons a pros, and there still were more pros.
It was not me, who is now making it personal and no, i won’t continue this way.
2 Likes
Well you’re not the only one. But the case of zwave in HA is special and you have to be fair to the developers on that one. I have lots of zwave devices myself, so I have been impacted by this too. I still think the core devs handled this rather well, given the circumstances. They had to adapt to a completely new technology, zwavejs, in a very short time span. I think that mistakes have been made during the transition (for example, reinventing the wheel for a zwave management UI when zwavejs2mqtt already had a fully functional and awesome UI done), but all in all it was well performed.
At this point, if your devices still work with the old zwave integration, there’s nothing wrong in keeping it. There is no immediate need to jump to zwavejs. The devs marking the old integration as deprecated didn’t really help though.
1 Like
This was exactly, what made me push the migration on a urgent list, being afraid, that it stop’s at the least wanted moment, when I can’t find the time for it and it will break my installation.
And sure, I can understand the amount of work behind it. And I’m very happy, someone did it, and quiet fast too.
If I would know, what I do know now, I will handle it differently. Less stress around it. And that’s exactly, what I’m trying to say here.
First, there is said, a migration tool comes. Later there is said, no migration tool comes. And then suddenly the Integration is marked deprecated. Yes, that puts some stress in the game. Because at that moment, I don’t know, what to expect and try to avoid some real troubles coming.
Well, I’ve learned from that too, fixing stuff in a rush 
I have been thinking about this issue with broken integrations.
Each time a new HA is released we have a storm of people reporting that xxxx.xx.x has made their integration stop working.
I know Paulus once talked about (in some Youtube interview or Podcast - cannot remember) changing the way Home Assistant is distributed making all integrations pluggable (don’t shoot me if I express it wrong).
I think a lot of stability could be obtained for the individual user if an update of Home Assistant means that you updated a core and the front end and a number of generic integrations. But any integration that relates to interfacing 3rd party products would be something you pick as required and load.
The advantage of this is that you can upgrade each individual integration when there is a reason to.
With individually released integrations you can
- Update each integration when you want a new feature or there is a bug to fix
- Downgrade an integration to previous version when the new breaks something without being forced to revert the entire HA to previous version
- Developers of an integration can fix and release a new version without having to wait for next HA release
There is way too much bundled into a HA release today. It would also relief the core team as they can focus on the core HA and the front end.
In Foswiki where I have been release manager years ago we shipped with around 15 plugins that we declared core plugins and the core team had the ownership of those. And then there were hundreds of contributed plugins you could download and install with a UI not very different from HACS.
We maintained an API and if the plugins only used the API calls to the core Perl code then the plugins would run no matter what. The users quickly learned that some plugins were well maintained by active community member and others were cruft that never got finished. I really think plugins should have release cycles independent of the core.
My daily experience with the few HACS things I use is that they are usually fixed much faster then the core integrations and I can up or downgrade as I see fit.
6 Likes