HA Installation Methods - Not to Beat a Dead Horse

1

Greetings all,

I’ve been running HA for a short while, admittedly not fully understanding the various nuances of the different installation methods, benefits, etc at first or completely even now. In the bigger picture, I’ve moved away from my VMs and big power hungry, heat generating and loud Dell R710 and R410 servers to smaller more efficient and smaller servers and converted all of my services to run containerized via Docker (Gitlab, GestioIP, Nagios, Smokeping, PowerDNS for Authoritative, PiHole, Prometheus, Rails Apps, and other sundry services, NodeJs, Postgres and my coding toolboxes). It’s saved me a ton of required resources needed to power a multitude of VMs and allows me to quickly spin up dev environments.

So I’ve got Hassio installed as a Supervisord install via Docker. The Supervisor->System tab reports that “You are running an unsupported installation.” The Learn more link provides two additional links to learn about how to resolve two issues (Operating System and Network Manager). In searching the home-assistant forum to learn more about the current installation methods, it’s clear that there’s been much confusion about how, what, and why. I’ve spent the better part of an afternoon reading reams of posts discussing the topic. I ran across the two links below, the first from @jal5376 asking for some clarification and the second a suggested read from @tom_l which provides a table and description of the different methods and pros/cons.

I now want to make something more permanent as well as reliable/redundant. That is, I want to set up a High Availability deployment. I have ZFS and GlusterFS on my storage devices to give me the benefit of ZFS and GlusterFS’s distributed data benefits. I understand there are some gotchas when it comes to physical attached adapters (ZWave, Zigbee, Wyze adapters, etc). I’m not yet educated on if or how one can have multiple Z-Wave access point adapters, for example. I’m ok with having to physically move my adapters to other physical servers in the event one goes down. But having another system ready and waiting a the drop of a hat is big. And let’s face it, if my single Home Assistant installation dies and I loose control of opening the motorized front gate to my property, or other various imperative automations, that’s unacceptable. And I’m not ok with having to reinstall a complete OS, dependencies, etc to get up and running again. With Docker done manually, or with Kubernetes, redundancy should be able to be accomplished with haste. Even if deployment is a little clunky at first.

I realize there are varying opinions all based on levels of experience with Home Assistant, as well as experience in their IT careers with servers, OS’s, containerization, SysOps and services in general, etc.

I’m interested in some feedback and your thoughts to help me ferret out what might be the best and wise course taking from the experience of others who have walked a few miles down this road.

Thanks all!

TD

2

I have no experience with setting up redundant systems (by that I assume you mean a system in which a failure of one server causes an auto switch over to a backup server?) but here are my thoughts:

  1. always have a way to operate things in your house outside of HA. Everything should have a manual override/operation method.

  2. as a back up to your HA install I would get a cheap RPi4 and have HA pre-installed on it and then take periodic backups of your production system and restore them to the RPi. Then if your main server dies then to gat HA back then the only thing you should need to do is move your zwave/zigbee hubs to the RPi and power it up. Make sure you test it to make sure it works as you want before you really need it. At least it’s a cheap way to have functionality for at least HA and it will give you time to make the repairs more permanent. Of course, there are ways to make a clone of your entire system if that’s what you want but that all depends on your budget.

  3. There is no way to have a “hot backup” of a zwave or zigbee controller for automatic fail-over. The devices are paired to the controller so that is the nature of the platform. But if you run an Aeotec zwave dongle you should be able to use the Aeotec backup software and create a standby dongle that you can just plug in and make it work. I think I’ve seen somewhere that zigbee has the ability to make a backup of the stick too but I don’t remember where I saw it.

  4. Don’t let the “unsupported installation” warning scare you. there are a lot of us not running a supported system just fine. the only thing a supported system gets you is “official support” via a github issue or a discord request (for whatever that’s worth - I’ve used HA for over 3 years and I don’t remember ever having had a github bug report or discord chat resolve an issue for me personally). However, the forum is here for everyone (supported or not) and there are lots of people willing to help.

3

That’s a convoluted way of saying you installed Home Assistant Supervised.

FWIW, the name hassio was discontinued 6 months ago in favor of Home Assistant OS. Both Home Assistant OS and Home Assistant Supervised are implemented as a collection of Docker containers. It isn’t necessary to indicate “install via Docker” because it’s not like there’s any choice in the matter (it’s baked into the product).

4

@finity… Thank you for your prompt reply and valuable insights!

On points:
1: You’re not wrong and I do agree with you in theory. Having said that, the more integrations and automations you have, the more you relay on them. That goes without saying. So downtime is that much more painful if/when that event occurs. As an example case for me… My driveway front entrance has a motorized swing gate. It is too far (200ft) from the house to run a cable, or at least too much work. So I put up a Point to Point Ubiquiti link to the front gate. There I installed a box with a Raspberry Pi Zero as a Lan2Wifi Bridge and connected an ESP32 to it. The ESP32 is then set up in my Home Assistant (ESPHome) to control the gate motor via a simple relay switch along with a couple of PhotoElectric Beam Sensors. Unfortunately, all the new RF I introduced interferes with the original remote control RF. I’ve moved the remote control antenna around but it’s still flaky. Ideally, as you suggested, I left the original remote control for just the point you made. If my Home Assistant goes down, I wouldn’t be able to easily open the gate from the outside. Yes, I do have a way to get in, but that would require getting out of the car, and manually going through the steps to open the gate, possibly in the rain or snow. It’s perhaps a remote case, but a real one for me. I’ve got Solar and battery backup, I just need/want some HA redundancy, hence my original post.

2: For my HA setup I’m using a few HP Elite 8300 w/ 16GB Ram. I use Docker extensively and grew frustrated with building images to support ARM. They are small, quiet, x86_64 and have a lot more horsepower. And as cheap as a Raspberry pi. I also have not been able to get my Aeotec Zwave Stick to be recognized on my Rasp Pi 4. I agree, a backup and successfully tested recovery procedure to ensure it works is a must

3: That’s what I suspected although I had read somewhere that you could use a “ZWave Controller” to distribute your access points and devices. But I haven’t dug into that. I also was not aware of a Aeotec backup software.

4: I’m on the same page. Being a Network Engineer and Sys Admin by trade having worked in and managed an ISP datacenter for 12 years, I’m a hands on person. So that didn’t concern me at all. I mentioned it as it related to the topic of various installation methods. And it also relates to how I feel about the Supervisord aspect of Home Assistant. I’m not a huge fan of an “app” having control over my bare metal to reboot thereby affecting other services I may have running on the same hardware.

5

@123, Thank you… Please forgive the HA noob terminology. You are correct on the new name. But when I originally installed it it was Hassio. It’s not my intention to perpetuate the incredible confusion as it relates to the installation methods and descriptive names.

6

It’s my understanding that the RPi4 needs a powered USB hub to work with the Aeotec Stick.

As far as the “zwave controller” i’m not sure what you are referring to. The “controller” is the stick itself.

However, you are able to expand and enhance your network by installing mains powered devices. They act as repeaters to the main controller and strengthen your mesh.

And you might be able to add a secondary zwave controller (dongle) to your system that is separate from your HA machine to improve reliability but that stick will only be able to control devices that are paired to it. it won’t be able to control all of your devices if they aren’t paired to that stick.

I would look into zwave2mqtt or maybe the new zwave beta that can run the zwave network on a remote machine and communicates to HA via mqtt. At least if you have a disaster that takes down your server it won’t also affect your stick and hence your zwave network. it can stay running until you get your HA backup system spun up and operating.