I think what will help is for there to be more transparency as to what the moving parts are, and how doing things to the underlying OS might impact those. I see French mentions dbus - I am not going to pretend I understand that and what it does, but documenting features that may well be interfered with by changes at the OS level may well help.
There are typically only a few topics that this kind of a response. And almost every one of those topics are based on a fundamental change to the way HA operates, yaml config is the most recent example before this one and, TBH, being right on the heels of that one this was truly poor marketing/optics What did they expect so soon after that?
Ironically most of the complaints I see on the forums is from too much development work being done too quickly and causing lots of breaking changes. People are saying “please slow down with the development it’s hard to keep up”. The response from the devs has typically been “breaking changes are part of this. We are still in beta. If you don’t like it that’s tough.”
Now we hear that the pace of development/maintenance of existing features is taking it’s toll on the devs. Hmm…
But instead of just cutting back on the pace of development they decide to start scrapping a ton of the functionality that the user base actually use because it’s “too hard to maintain”. Talk about “can’t see the forest for the trees”.
A good solution for me would be a minimal supervisor. Something that only deploys HA Core and offers the option to backup/restore and upgrade. I could see this been paramount in the future when automatic upgrades are possible.
I feel that add-ons require a far more standardised underlying configuration which Hass OS does nicely. If you’re managing the Docker environment there are many options for deploying addons such as Mosquitto.
With the decision being on hold, you are safe !
Otherwise, you would have had to do something. Not urgently… But at some moment. Now, you just wait for further details. And enjoy what you have
It means you are running Home Assistant Supervised on Raspbian (not HassOS) so, yes, you are affected. However, Paulus has suspended the deprecation until further notice so you don’t need to change anything at the moment.
As soon as they slow down then people will be mad about that. The next big one coming is moving z-wave out of core and into mqtt and using openzwave daemon. That one I know will affect me huge, could make me spend multiple nights and weekends fixing what works perfectly right now. Only benefit is faster restarts and updated device XML files, which I can override anyway.
But, as frustrated as I’ll be, I’ll come here to ask for help, not complain once, and I 100% agree architecture wise with decoupling these things…
I’m sure that will turn into one of these too…
Just part of using a beta free product. I knew what I was trading for when I left SmartThings, constant change for functionality over any form of stability.
I see. I’m going to have to dig into the install scripts then to see what’s going on.
It may be time to simplify the supervisor, I’m not sure why it needs to control anything outside of the Docker Daemon, So that people don’t need to know the device name of their USB devices? I donno.
Please help me understand of this is going to affect me. I have stock Raspbian, with HA Core & supervisor all in docker containers, installed with the one-liner. I don’t use docker-compose or run anything at all manually. The supervisor controls all of it and the add-ons flawlessly, for a year now. I update everything and nothing has ever broken because it’s all in the docker containers maintained by HA. Am I going to be affected? I hope they are talking about supervised HA not running in docker?
Ive never had a single hardware issue or add-on issue. I use both zwave and zigbee USB sticks. I use cli commands, etc.
It is not the installation script itself. I had a look. It is fairly simple. It is the “supervisor” program/container itself. Frenk explained that it uses dbus… and that is tricky part.
I don’t know the distribution of the install population, but I have been running on a Pi since ~0.28 and it still serves my needs very well. It has been stable and responsive and for the most part, I have been spared problems with SD cards. Hass OS makes it so much more relaxing.
I believe the move to a very minimal OS is consistent with what is happening in the commercial Container world. Remember JeOS from Suse? My understanding is that RedHat OpenShift is moving in this direction as well the use of CoreOS to run their container platform on.
I’m a new user of a few weeks, installed on Raspbian and considered the installation options carefully. I have always understood that it is impractical to expect HA to be supported every which way up.
I hope that some sort of standardised linux install can always be a practical option. Others have been more eloquent than I would be about why having this option is a strong argument for Home Assistant over other home automation systems.
I’m currently maintaining it from Portainer, which I think I set up outside of / before HA.
Could I still use Portainer for that, but managing Portainer as a HA add-on instead?
This is the stupidest thing I’ve heard in a long time.
hass.io is not being deprecated, only support for running it on the OS of your choice. All features you’re used to are still in play, you only have to move to one of the supported methods of installation!
That said, the way this has been communicated was a bad idea!
I don’t understand that anyone could run into the issues that the developer is saying is hard to support.
I have supervised HA running all in docker on generic Linux (Raspbian). I have never needed to configure anything, no port forwarding, no docker-compose, no USB device forwarding, anything. It just works. For a year. All hardware. All add-ons. Updates never break. But because it’s on Raspbian I can still do stuff like use a cron job to sync the snapshots folder to my next loud instance, etc