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
The fact that it all works without any config is credit to all the work the devs have put in to make it work. That is the workload they are now trying to minimise!
Thanks. Since there is no hassos image that runs on low-end Intel hardware ( Zotac atom 2 GB ram) the announcement really meant : go back to the Rbpi with failing SDcards, or be stuck with half the HA experience. Now I can stop trying to install the NUC image on my PC (and failing )
[quote=“dkmcgowan, post:365, topic:194310”]
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.[/quote]
You’re one of the lucky ones if the current component works perfectly right now
The old component will stick around for a bit after the new component is released so you won’t have to immediately jump over. There will be some aspects that can’t be automatically migrated easily though
IMHO the docker containers would be easiest to maintain and only supported method. I don’t understand why anyone uses venv or direct install. That seems like a hard thing to support, with official docker images the easiest. If you want to leave the docker and host OS integration up to the user for networking and pass through hardware then fine, I get that. But if you’re supporting HA supervisor at all then that’s managing the docker environment anyway. So the need to “support it” isn’t really needed. If you want more control and a host OS for other things, then install the supported docker but understand that since it’s not HassOS you’ll have to do some docker environment setup. Am I not understanding? One things for sure, there’s way too many tutorials and ways to do this.
)
