I’ve run Home Assistant in a venv, as a docker container, and most recently as Supervised on Ubuntu. The one thing I liked about Supervised’s add-ons is their integration with Home Assistant’s management UI. They are easier to configure, their logs are readily visible, and they can use Home Assistant’s user accounts.
It’s that last feature I appreciated the most. Setting up accounts for the mosquitto add-on was far more convenient that the traditional way (which I have done because I have a non-docker installation of mosquitto on another server).
I asked what the process would be to provide standard containers with access to Home Assistant’s user accounts. Paulus replied and directed me to a script but cautioned me that it relies on Supervisor’s API. Therefore re-inventing it to work without Supervisor is more work than I had anticipated.
The snapshot feature is also very handy.
If one is willing to forego those advantages, using docker-compose is the next best thing.
I agree accounts takes a little time for mosquito, but it’s not hard, easier than dealing with a VM, and with docker, backing up your config folder into a gzip file somewhere pretty much is a snapshot and it takes 5 min to script, mine backups up daily to Dropbox
Bad, bad, bad idea. One of the reasons that led me to choose the home assistant was the presence of hassio on the docker supervisor, i.e. the ability to run the app in a standard Linux environment, using all the features offered by this choice, with management of the addons offered by hassio and High availability and other features offered by the operating system (pacemaker, corosync etc etc). Now, in one night, I have to throw away all the hardware and project investments made in these months, one step away from production. How can I still trust you? What will jump into your head tomorrow? What protection do I have for my home automation investment? I am using Raspberry Pi, and if you change your mind overnight again, what should I do, throw everything away? I have been working in the field of IT for 35 years, I have seen it in all colors. But these are the things that kill a project. Surely hassos is not a valid alternative for those who make a choice of product as a homeassistant is.
I understand your needs, but I don’t think this will do any good for homeassistant.
Especially done in this way.
Too bad, because it was starting to take off.
yes. sure. i’ve got that … and that is and was my understanding. But still… it does not “explain” the difference between supervisor on hass.io compared to hass.os (with the exception the the supervisor on hass.os runs on a “managed” OS … whereas the other runs on “generic” linux) … however … both of them do the same…
why not develop and maintain a common and generic supervisor which can work (supports) on both … “hass.io” and hass.os ? and or even rpi installations ?
I just spent the last 2 hours reading and trying to understand all the questions and concerns.
I am now more than ever very confused.
After a few years of running my HA on an unraid server in a vm (2cowq method of install) which became unstable, I switched to a NUC.
I installed it using this method.
So if I understand the discussion the last line of the install is what the problem is (yes/no)?
If this is the problem I could wait as some have suggested to change, but wanting to still keep it on a NUC what do I change to.
Though I am slightly more than advanced then a noob, just as in my field of education, I need a cheat sheet to decipher all the acronyms.
Thank you forum members for the support and help.
carltonb
We’ve been overwhelmed with the many reactions. We realize our communication has been poor on this subject, for which I want to apologize. We do not collect data and so can’t always judge the impact of our decisions.
We’re going to put the deprecation plan on hold for now. Anyone running this installation method today can continue running this. We will offer more clear information in the future.
We’re going to investigate how we can maintain the supervised installation on generic Linux.
Furthermore, we are going to make sure that supported installation guides are properly documented.
The version that is no longer supported is the one in the middle. In a nutshell, if you are running Core+Supervisor on anything other than Home Assistant OS, it’s no longer supported. (and the timing of my post was priceless because Paulus just postponed the deprecation).
EDIT
On a positive note, I know more about Proxmox and ESXi today than I did yesterday.
So if Home Assistant Core is your primary application, what prevents you from leaving HassOS tomorrow (or tonight), and throwing away the work of those who migrated? How can I be sure that my investment in home assistant is protected? This is one of the main point, in my opinion.
I’m still confused after reading for a few hours now.
Currently I;m running HA in a VM on Proxmox. It has supervisor also.
So I just fired up a new VM using the whisker007 script. https://github.com/whiskerz007/proxmox_hassos_install It also has supervisor installed by default. Is this the one that will be supported? Or do I need to install a different way?
This is going to be a dumb question, but how do I tell what install I am running? I think I did the generic linux install on my PI4 a while back so I could run off my SSD, but don’t remember.
I’ve been using hass.io on generic linux (ubuntu LTS), running in a hyper-v VM, since late 2016 without any issues. Gradually, over time - I’ve installed the add-ins for unifi, pihole, motioneye, grafana, influxdb, vscode, etc… These were quick installs using the hass.io supervisor interface and I went that route because it was easy to keep things updated and I could throw way more resources at the underlying vm. The other benefit was this approach seemed to be the most popular install method.
But now, as someone who is not financially in a place to buy a nuc or odroid, I’m wondering what I should do? My setup has enough sensors and integrations that a raspberry pi simply won’t cut it (even if I had one). Additionally, the add-ins (unifi, pihole) are foundational pieces of my infrastructure that I don’t want to move away from. Maybe, I can download a VHDX and convert it? The instructions aren’t clear.
I think I could better understand if this was a data-informed decision. Like - “we have the data and it shows that this install method is 5% of the user base” or something like that. But, without that kind of data, the sudden announcement makes this decision feel shot from the hip. Does the home assistant team really know for sure if this will or won’t affect the project’s adoption? I expect it will, especially given the backlash we’re now seeing from the community. Honestly it just seems like a very poor business decision given that it was likely the most common way for new users to attach (maybe, maybe not - there’s no data shared about what is the most common install approach).
Beyond that, I feel frustrated by this decision. Am I just not valued as a customer and user due to the way I installed? I’ve been paying for Nabu casa ever since it was lit up, and it would have been great if the Home Assistant team would have stipulated what exactly they needed help with or what exactly wasn’t working - because as an open source project maybe folks would have been willing to help out? Should I start looking for alternatives now that there appears to be a messy path forward for hyper-v?
I’m so glad to read this response. I’ve been avoiding responding because I’ve been nurturing my anger/upset/disappointment, knowing I wouldn’t be able to write anything constructive. I was worried HA had become a project that behaved like Logitech, Sonos or Google with complete disregard for it’s users. My pride in HA for not behaving that way towards it’s users was taken away. Part of me wanted to walk away as I could no longer recommend HA with any enthusiasm or confidence.
This is a good decision.
I have actually tried to contribute to the generic-install branch but my comments and PR were previously ignored. I’m happy to extend that offer of support to @pvizeli again to help maintain this. I have limited knowledge of Linux or whatever voodoo magic Supervisor does but am willing to be used as a resource if supports HA.
Agreed. That would be a reasonable compromise. Running on all linux distro / flavours can be a nightmare to maintain. Choosing one rather mainstream (Debian, Ubuntu, Centos,…) would be the best of both worlds. IMHO.
The reactions are confusion are in great part also due to how many variants of home assistant installations have been introduced. I am a great advocate for simplicity and even the diagram reshared by @123 may not have helped everyone. I spent some time reading this thread and realized that a lot of opposition comes from people who will not even be affected. I understand the desire from the team and I also think that it makes sense in the long run to not have that many variants.
Would it have been clearer (If I understood things correctly which I may not have) to say that supervisor will be deprecated on installations outside prebuilt docker images, VM images and HassOS?
Therefore people who do not run supervisors or run it within a prebuilt environment are not affected?
Have to wonder if a mostly ‘here it is – deal with it’ team will listen to us old timers who’ve seen it all or if they’ll already make a choice to lead HA into disuse . So many expressing their objection in less than 24 hours – can’t be ignored but if they chose to go ahead as planned, HA is doomed in my opinion. Hass.io is what’s made this project a success…I’ve come to understand that that’s not what’s understood in the project team even if they themselves once reported that most used hass.io and it’s generic Linix intall. Pascal is truly to be commended for all his great work! Maybe someone will come forward to lend him a useful hand and find work/life balance.
