I have created this TLDR with the hope it can assist newcomers, and not only, with decision making. This post uses a lot of acronyms and it is best viewed on my portal as I provide full real-time glossary. In any case, I hope it is useful to someone.
Background
There are several methods to install [[HA]], listed and compared here. I consider the [[HAOS]] method the most production worthy, for the simple reason it provides long-term reliability. A lot of people will try to convince you otherwise, but take it from someone who looks after more than 100 [[HAOS]] instances running for years with no issues. [[HA]] has a large technology ecosystem with a lot of moving pieces, which also happen to change frequently (the nature of the tech industry); the last thing you want is add unnecessary dependencies and complexity into a system that is already complex and updated at a fast pace.
As someone who has designed, engineered and programmed systems for AMX, Dynalite, ELAN, Control4, Crestron, HomeSeer, Loxone, Lutron, OpenHAB, RTI, Tuya, URC, and others, plus worked with almost any protocol in existence, like BACnet, CAN-bus, KNX, [[LoRa]], [[MQTT]], [[RF]], RS-485 Zigbee, Z-Wave, you name it I have most likely deployed it, I can confidently say, [[HA]] is the best overall [[domotics]] platform there is. In the hands of a competent technology designer/engineer, it will shine orders of magnitude brighter than any other galaxy in the [[domotics]] universe. Even for simple setups it is hands down the most flexible and in many ways the most enduring [[domotics]] platform out there.
With all this power and complexity the least you want to do is add even more dependencies and complexity, which is why I suggest the [[HAOS]] installation method is the most appropriate for anyone seeking long-term reliability from their [[domotics]] system. If you are just tinkering and your smart home does not depend on [[HA]] to function, any of the other methods of installation (container, core, supervised) are fine. For anyone looking for long-term, rock-solid deployments [[HAOS]] is the only reasonable choice.
[[HAOS]] Options
You can install [[HAOS]] in two ways:
- Bare-metal on a variety of compute platforms (64-bit is the preferred choice)
- [[arm-64]] (e.g. HA Blue, HA Yellow, RPi, Odroid, Khadas)
- [[x86-64]] (e.g. NUC and hundreds of other options) you will find a greater variety of hardware and configuration options and face less issues on this platform
- Virtualised in a [[VM]]
- Type-1 [[Hypervisor]]: this requires a [[BM]] installation on a dedicated computer - I strongly suggest [[PVE]], but other [[hypervisor]] options are also available
- Type-2 [[Hypervisor]]: it does not require a dedicated system and can be installed on most Linux/Mac/Windows PCs - examples are [[Hyper-V]], [[PVE]], [[VirtualBox]], [[VMware]]
- [[NAS]]: install [[HA]] as a [[VM]] in a [[NAS]] system, like [[QNAP]], [[Synology]], [[TrueNAS]], etc.
[[VM]] [[HAOS]] Benefits
[[PVE]] virtualisation has many benefits, some of the most important are:
- Ability to run production-grade, test and beta [[HA]] workloads side-by-side (tinker to your heart’s content on test instances/workloads, while running a robust production-grade [[HAOS]] instance in parallel)
- Ability to automate backup of the entire [[HAOS]] instance (the entire [[VM]]) in seconds with almost no downtime (includes all backups inside [[HAOS]])
- Ability to backup on-demand the entire [[HAOS]] instance prior to a version which might break things in seconds (includes all backups inside [[HAOS]])
- Restore a backup in seconds (includes all backups inside [[HAOS]])
- Create a robust infrastructure (compute, network, storage); e.g. running a [[PVEc]]
- Consolidate all server (even desktop) workloads on a single physical computer; you just need a lightweight client PC running a web-browser to access the [[PVE]] infrastructure
[[PVE]] has one consideration you should be aware of
- When [[HA]] is updated it needs to be restarted leading to downtime. In the same manner, when the [[PVE]]-kernel is updated, it requires full system restart for the new kernel to activate, which means all workloads will have to be rebooted including [[HA]]. In [[PVE]], a kernel update is available almost bimonthly. To reduce downtime you could update [[PVE]] as well as all workloads including [[HA]], all at the same time; then one reboot will update everything [[PVE]], [[HA]] and all other workloads
[[HAOS]] Recommendations
Some people suggest, install [[HA]] and then never update or update infrequently (say once a year). Although it is possible to freeze the installation if you will never have the need to change something, I believe it defeats one of the primary motivations of using [[HA]], which is to keep pace with technology advances. If you rarely update your system, chances are something will break next time you try to update. This is why Apple, Google, Microsoft and everyone else in the industry insist your system is updated at frequent intervals and also the reason why immutable [[OS]] deployments have started gaining traction.
I therefore suggest you update [[HA]] at least every 3 months (say 3rd week of the 1st month of every calendar quarter) and preferably once a month towards the end of the 2nd week. You might not want to update at the beginning of every month (say avoid the first 1 or 2 weeks of every month) as sometimes there might be issues introduced by updates, which although usually solved fast (within the 1st week) could lead to problems with your system, which although addressable, you might not have the time or the knowledge to solve.
Below find my suggestions in a nutshell (they apply to most people who are not experts):
- Install [[HAOS]] preferably in a [[KVM]] in [[PVE]] or alternatively [[BM]] install in a [[x86-64]] PC
- Preferably use [[NVMe]] [[SSD]] or alternatively [[AHCI]]/[[SATA]] [[SSD]] or [[eMMC]] for storage; DO NOT use [[SD]] cards as they have terrible performance and are not as reliable as any other option
- Rough sizing guidelines for most [[HAOS]] installations: note: how many CPUs are required depends on how performant the CPU cores are; if running in a VM start with 1 CPU and monitor):
-
baremin: 1 [[CPU]]
512MB [[RAM]] 32GB [[SSD]] -
minimum: 1 [[CPU]] 2GB [[RAM]] 32GB [[SSD]]
2 [[CPU]] -
optimum: 2 [[CPU]] 4GB [[RAM]] 64GB [[SSD]] 4 [[CPU]]
-
maximum: 4 [[CPU]] 8GB [[RAM]] 256GB [[SSD]]
-
baremin: 1 [[CPU]]
- [[HA]] requires a wired [[LAN]] connection to create a reliable network link
- [[HA]] does not require Internet access to communicate with the local [[domotics]] infrastructure; however, it requires Internet access when you try to update [[HA]]; at no time your local [[domotics]] infrastructure is exposed to the Internet, unless you use [[domotics]] hardware which has been designed for cloud operations, like for example [[Google]] and [[Tuya]]. However, even for these cloud services there is usually a local-only installation method
- You can securely access [[HA]] over the Internet, using the Nabu Casa subscription service and/or Cloudflare. These two methods are vastly superior to any other remote access method. The next two methods, Tailscale and ZeroTier, are also very good, but Cloudflare edges them out
- Automate [[HAOS]] backups (use [[PVE]] as it offers the most robust and fastest backup method)
- Set a static [[IPv4]] in [[HA]], using a [[DHCP]] [[MAC]] reservation, instead of setting a static [[IPv4]]; it is easier to setup and more flexible when changes are called upon
- Do not enable [[HTTPS]] in [[HA]]; it just complicates matters without real benefits in residential-[[LAN]]s (a better strategy is to ringfence and secure your [[LAN]])
- Take a full [[HA]] backup prior to updating; ensure the backup is saved outside the [[HA]] instance
- Randomly test backups can be restored; a backup is no good if we cannot restore from it
- Habitually update [[HA]] on the 3rd week of the 1st month of every calendar quarter (i.e. every 3 months) or something similar or more frequently; aim for a max update interval of no more than 4 months; ideally you want to update monthly, anytime the last 2 weeks of every month
- Only install well-maintained [[HAAC]] and/or [[HACS]] packages
- Primarily choose [[domotics]] hardware which natively supports [[IP]] protocol stacks (e.g. [[matter]]/[[thread]], [[WiFi]])
- With [[matter]]/[[thread]], protocols such as Zigbee, Z-Wave and possibly [[BLE]] will become obsolete, in the not too distant future; [[IMHO]]
- Advanced: consider [[LoRa]] hardware in favour of other wireless standards, except possibly [[matter]] and [[WiFi]]. [[LoRa]] has exceptional range (rated in km) with extremely low power consumption, designed for large industrial-scale [[IoT]] deployments, but also fantastic for residential/commercial use
- Advanced: consider learning [[MQTT]], which is the glue to connect dissimilar protocols together; although [[HA]] supports a plethora of protocols there are things that only [[MQTT]] can muster
- Advanced: consider learning [[Node-RED]], a flow-based [[domotics]]/[[IoT]] development platform
- Lastly apply for a subscription to Nabu Casa to keep this wonderful project alive and kicking butt, even if you decide to use Cloudflare, Netmaker, Tailscale, ZeroTier or anything else for [[HA]] [[WAN]] access
In case you are wondering what performance looks like on baremin ([[PVE]] [[KVM]] on i7-3517U CPU @ 1.90GHz, 12 integrations, no [[HAAO]], [[HAAC]], [[HACS]]):
