We are today officially deprecating two installation methods and three legacy CPU architectures. We always strive to have Home Assistant run on almost anything, but sometimes we must make difficult decisions to keep the project moving forward. Though these changes will only affect a small percentage of Home Assistant users, we want to do everything in our power to make this easy for those who may need to migrate.
↫ Franck Nijhof on the Home Assistant blog
Home Assistant is quite popular among the kind of people who read OSNews, and this news might actually hit our little demographic particularly hard. The legacy CPU architectures they’re removing support for won’t make much of a difference, as we’re talking 32bit x86 and 32bit ARM, although that last one does include version 1 and 2 of the Raspberry Pi, which were quite popular at the time. Do check to make sure you’re not running your Home Assistant installation on one of those.
The bigger hit is the deprecation of two installation methods: Home Assistant Core and Home Assistant’s Supervised installation method. In Core, you’re running it in a Python environment, and with Supervised, you’re installing the various components that make up Home Assistant manually. Supervised is used to install Home Assistant on unsupported operating systems, like the various flavours of BSD. What this means is that if you are running Home Assistant on, say, OpenBSD, you’re going to have to migrate soon.
Apparently, these installation methods are not used very often, and are difficult for Home Assistant to support. These changes do not mean you can no longer perform these installation methods; it just means they are not supported, will be removed from the documentation, and new issues with these methods will not be accepted. Of course, anyone is free to take over hosting any documentation and guides, as Home Assistant is open source.
Home Assistant generally wants you to use Home Assistant OS, which is basically a Linux distribution designed to run Home Assistant, either on real hardware (which is what I do, on an x86 thin client) or in a container.
Yes, just my luck. I recently switched to Home Assistant to get rid of cloud dependencies (I had Samsung SmartThings for Z-Wave and a bunch of Google and third party random vendors for WiFi devices, all needing cloud accounts).
Now… to be honest, HA setup is not as straightforward, and especially mixing Z-Wave in it is a hassle. But at the end of the day, it was working locally.
Now, I need to figure out how to redo everything. Especially migrating existing device associations will be a hassle. (As I remember installing the “supervised” version. Maybe I’m lucky and misremembering)
Maybe you can use their backup/restore method mentioned in the link?
Of course,
But the Z-Wave plugin is a bit brittle, and I’m not sure the backup will work without hitches.
(Btw, I confirmed, it is “Home Assistant Supervised”)
My setup is the “Home Assistant OS” running in a KVM/QEMU virtual machine on a Dell Micro with a 6th gen i7 running Fedora. Networking is bridged and the Zigbee stick’s serial port is passed through.
Cody Evans,
This might be a better alternative. Though… how did you manage to get the stick forwarded?
Looking at their stats, i am surprised that the vast majority run the HA OS version instead of the container version. I did notice that the OS route was the one they tried to push me towards, but that is not going to happen, not doing single tasking boxes, and don’t want to deal with full blown VM’s.
I run it as it’s own OS in my homelab as a VM, which sits comfortable with 2 cores and 2 GB of RAM. More than enough to run Cloudflared, and all my Tuya IoT devices locally on a different VLAN using the LocalTuya integration.