No, no lines crossed.
Yes, would have saved a large number of users a lot of grief if it had been part of the release notes, completely agree.
Perhaps under the heading Farewell to the following…
1 Like
It’s in here. But the reality is if you run an unsupported system then you need to assume every release can contain undocumented breaking changes. Breaking an unsupported system isn’t considered a breaking change. There is no effort made to consider what unsupported systems may break and no testing done around that.
The only reason its noted as a breaking change in the release note is because of the now long-deprecated community add-on. Which may have duped people into thinking they were doing supported things.
I’m not sure who you’re referring to as management in this context. But the PR that made this change was put in by pvizelli (creator of HAOS and Supervisor) and approved by Frenck and me (I’m mdegat01 on GitHub). So that is 3 of the top 5 contributors to Supervisor and Frenck and pvizelli in particular show up at the top of every contributor list in the HA ecosystem. I can assure you ludeeus approves as well as its come up in chats, he just didn’t see the PR in time.
And this isn’t a major design change. You’ll notice for example that watchtower marks system as unhealthy as well:
That’s been in there for a while. The only reason portainer wasn’t was because there used to be an addon. But that addon has been deprecated for over a year now and a recent issue was a reminder that portainer should be in this list too.
I would prefer not to have this change at all to be honest. In my view this is a major change for the project and it has to do with the new path it has chosen to follow.
2 Likes
OK not going to lie. Much more passion going on here than I can read. So I updated Ubuntu to the latest, and updated portainer to the latest but same deal. Restarting supervisor as others have stated does not work anymore to update. Couple things:
- How do I do this on a Ubuntu docker instance:
ha jobs options --ignore-conditions healthy
- Are there clear steps how to drop our entire install into a supported implementation? For me needs to be in a virtual machine.
Thanks.
JR
I had this same problem and I was able to stop my portainer and updarte HA to 2022.10.3
I think exactly here hides the culprit of all this. Unfortunately it seems to be wishful thinking only. As you have been also active here and here you might have noticed that quite a few users are immoderately overestimating their own skills insisting on a HA Supervised installation and start to rant soon after if it doesn’t work out as expected. Some are not even willing to read the precautions and instructions (I mean thoroughly read, not just quickly skimming through the warnings and instructions).
I am disappointed too not being allowed to install some other docker containers like i.e. Portainer on the same host HA Supervised is running on if I want to keep that native “healthy and supported” HA installation. Besides it can not really being called sustainable to waste that much processing power (and electricity) especially if one runs HA Supervised on something more powerful than a RPI.
But taking the view of the devs and moderators of the forum I can understand their decision to simply limit the amount of docker containers allowed next to HA Supervised, although the consequenses are a bit harsh. As it was already pointed out further up this thread all too many users are simply blaming all others for their own incapabilities 
I really wish
since I am sure it would not have taken us into this patronised misery in the first place.
3 Likes
Evidently ha is going walled garden route, I would never expect such blatantly anti-consumer behavior from HA developers, but here we are.
5 Likes
I still don’t quite get it. How would the project be bothered if it flashed a BIG RED FLAG at every, say, reboot, or somehow, that the instance is unsupported and the project does not bear any responsibility for anything if something goes bad.
But NO, instead of that, the “unhealthy state” is tucked away 5456 clicks away, behind Settings-System-Repairs(what?)-3 dots(!!!)- System information. I’d been using HA for ages and I had a problem finding that back when the GUI changed. You may have 1435 containers alongside HA and never realise that its state is “unhealthy”.
In any case the project does not bear any responsibility for anything. It’s just free and open source automation software. Not a commercial, supported, paid and licensed software that runs an airport or a hospital. For God’s sake, this is just an excuse to further wall the garden.
Where are you seeing that? And even if it happened, what’s the big problem about that? Just another post in a thread. That’s why the community is there and will be there. Who cares if a guy just came straight from iOS and now wants to run a supervised install eg. within Proxmox withing a VM within a docker container? He’s just having fun. The project must not bother to answer it or/and fix any problem. And that’s what it did up until now: “-Do you have another container? -Yes. - Sorry, bye-bye”. I can’t see such a big deal here, which should result in such drastic decisions. That’s why we accepted the “unsupported” state. But the inability to update goes a LONG way.
Needless to say, that the proposed “solution” to completely deactivate the health check for the WHOLE setup is not a solution obviously, since we lose an important check for the whole instance for no important reason whatsoever.
Finally, if we go this way without a fight, what’s stopping the developers from blatantly saying in 2-3 months that if “we detect another dreaded, prohibited, abhorrent container alongside HA, HA WILL NOT START/WORK”? Will you also support this decision because “inexperienced users tend to break stuff”?
Sorry if I seem angry or anxious, but, yes, I’m worried when I see my favourite piece of free, open-source software changing paths (if you get what I mean)… And big changes often come gradually and slowly, not in a day or two (if you also get what I mean).
5 Likes
I also had to restart homeassistant, ie:
sudo docker stop portainer
sudo docker restart hassio_supervisor
sudo docker restart homeassistant
Then update could proceed.
4 Likes
The first two commands were enough for me.
You know what’s funny for me? I had three updates pending I couldn’t do. Following these commands now I get
Guess the problem is fixed for me. The updates went away so no errors trying to install.
1 Like
I am using the supervised method in Rpi4 and SSD. If I want to switch to HA OS, what will happen with the following items:
- My python script that is running from root access and will communicate with a CAN-bus controller.
- HACS and custom components
- SSD drive instead of SD card
Are they still be working in HA OS?
Baaad decisions are being made here. You will alienate tons of users like myself.
You guys are operating on a VERY slippery slope. Im not a super advanced user but I can find my way around eventually. Yeah, I found this thread, but others may not. And yes, I run a NUC with Debian and Portainer and run everything in my shop and solar system with home assistant. It’s not a hospital or airport. If some lights don’t turn on, no big deal.
Disabling health checks is a REALLY bad idea. I used that last week to finally fix MQTT changes you all depricated.
Home assistant used to be fun. Roadblocks like this turn it into a chore and a big PITA. Why do you want to make users like me curse your platform? Microsoft already has that in spades.
Rethink this guys. Seriously.
Jeff
Home assistant user from the very beginning
6 Likes
I don’t think there will be any turning back from this, just like when it happened with the “unsupported” state. But at least then we didn’t have to stop portainer, restart supervisor, update and then restart portainer, in order to do a simple update. It will only get harder from now on.
Just to clarify: By just having any container installed alongside HA makes the instance “unsupported”! As soon as portainer starts, the instance becomes “unhealthy” too!
Yes, going forward in this direction I think very soon the userbase number and rate of new users will start to decline.
-
Newcomers and people interested in trying it out will be deterred by the fact that they are more or less forced to get a dedicated machine for HA, unless they are willing to spend countless hours trying to get around the increasing number of “show stoppers”.
-
Existing users will grow increasingly frustrated and might consider looking elsewhere
The attitude in itself is detering, it’s a community driven project and still there are design decisions being made that will shut out more and more users, users who’s been giving and receiving support for years will find themselves in a whole new situation where they instead will be struggling just to keep their HA installations running.
Not to late to go back though, continue to warn people that they are running an unsupported instance but let the updates go through.
Make the Unhealthy information more visible, create pop-ups, have red flags everywhere, right now it’s really counterintuitive finding that info as @Tryfos pointed out.
6 Likes
Thank you everybody, solved stopping portainer, update home assistant and restarting portainer.
stop portainer, restart supervisor, update and then restart portainer
did that with the first update, but then I just removed portainer and… started it again, with different container name. problem solved, system healthy, next update worked normally with running portainer 
1 Like
Does this actually work consistently? How long did you wait after you restarted HA (with Portainer’s new name I mean)? In my experience it needs some time before the system is marked as ‘unhealthy’, so maybe you just updated within this time frame and it was then marked as unhealthy too.
To what other extremes are we going to go, in order to circumvent these unneeded and unjustified changes…I already feel awkward discussing this kind of solutions here, since the thread is being actively monitored by the developers, who I fear will immediately run to patch any loopholes… We’re slowly descending into ‘how to avoid an online Microsoft account for Win11 installation’ territory here and it kinda sucks to be honest.
when I was processing those changes - didn’t wait any special amount of time, but doing this while I was at work gave me some “natural breaks” between this or that command.
as for now - two machines working for almost a week without issues. “unsupported”? yes [ubuntu server + few own dockers], “unhealthy”? nope
I totally agree. first I was going to yell how I feel about this changes, but I realized that it won’t change a thing… I do plan going to VM tho, to secure myself from any “patches” and “it’s for our good” changes in the HA, that will prevent me from using my own hardware the way I like, but right now went to quick’n’dirty scenario 
Yeah, I’m afraid that supervised installs are not to last and/or to be supported for a long time and I’m starting to look elsewhere, especially after the last change, which has made obvious to me that the project is heading a direction I don’t like. But that’s my opinion, I know that developers are not particularly interested in our opinions.
Btw, why are you planning to go for a VM and not a docker install? That would be option no 2 for me after the supervised install.