Hi!
Recently I’ve seen a lot of confusion here and on reddit and other places from people new to home assistant. Here I’ll try to answer some of the most common questions, mostly so I can just guide people here instead of copy pasting the same answer, and will also post some of my own opinions.
Please note, that I’m just a user and not affiliated with HomeAssistant, and so far did not even contribute much to it’s development. I’m also not a security or IT expert, though I’m a long time IT hobbyist, running a bunch of Linux servers local and remote and developing web-apps and stuff. My main job is 3D character animation, both art and tech sides of it, so… Just your regular geek. So, if you are an expert who sees something horribly wrong in this text, or even if you think some parts could be worded better - please do tell. I will fix it asap.
With that said, lets’ start.
What is Home Assistant?
Home assistant is Home Automation Hub. Or Home Automation Software to be more precise. It’s free and open source and fully local alternative to things like HomeBridge and SmartThings. It gives you the power of home automation without the cloud so you won’t depend on internet connection or remote servers. This results in faster operation and reliability. At least as long as you know how to properly set it all up, because in this you’re the only one to blame if something fails (well, you or devs for bugs, though I don’t think I’ve seen many bugs in release versions in 2+ years of using Hass).
You can read a bit more about Home Automation fundamental and why HomeAssistant is so great here: https://www.bruhautomation.io/fundamentals/
To be fair, there are other alernatives, of course, such as OpenHAB or Mozilla’s new WebThings. All of these are open source and locally hosted. HomeAssistant has most integrations at this moment, as far as I know. Also since it’s using Python, (one of) the most popular language in the world - it also contributes to the number of contributors (ha) contributing (uh) their work to this project!
There is also Hubitat, which is closed source but locally controlled and developed by ex-developers of SmartThings. It’s also a good option if you find hass to be too intimidating.
Why cloud based options are bad?
A lot of smart devices are built around web based infrastructure, which usually means easier setup for end users, as well as more control of the system from the manufacturer, like updating their backend systems without requiring ‘client’ updates, as well as they get all sorts of data and stats which they can use to adjust their sales or strategy or whatnot. Could be used for malicious intents as well, or be sold to someone, we live in the world where data and data analysis is quite important part of our lives
Some devices may keep working offline, like Hue bridge, some don’t. In most cases when it comes to automation those would be processed by outside servers.
Also any device on your network that has access to WiFi is basically a mini-computer. In most cases you can’t put an anti-virus on your IoT devices, and patching security holes in their firmware is usually in the hands of the manufacturer. These security holes can, at least in theory, be used to hack into your networks, to gain access to your data, steal it, or they can be used as a backdoor for other malicious intents. Or these devices can simply sniff data from your network and send it into the cloud.
How can I secure my WiFi devices?
VLANs and Firewall rules, but this is out the scope of this article.
But HomeAssistant is for tinkerers and is so hard!
Well, it was true once. But with each release, especially after 0.100 it’s getting a lot of love and attention in UI UX and user-friendliness areas. It still has a bit steeper learning curve than some other options, but it’s well worth it with how much power it provides, and how many devices it supports.
Installation is as simple as buying a Raspberry Pi with an SD card and card reader, inserting it, downloading balenaEtcher or Win32DiskImager, downloading HassOS image and clicking one button. Well, maybe two.
Configuration and integration of basic devices like ZWave light switches, ZigBee light bulbs, wifi plugs is as simple as getting a ZWave\ZigBee USB stick, plugging it in, enabling zwave and zigbee in Hass, and then just pairing them as you would with any other hub. WiFi even simpler - it can auto-discover, for example, any TP-Link Kasa device on your network by itself.
It has a UI Editor that provides all the basic features.
It has Automation UI, and since version 0.102 you can now even just type in something like “At 23:00 turn off outside lights” and it will try to convert that into an Automation for you.
So… It’s not that much harder than other automation hubs nowadays.
Sure there’s still editing of configs, but hass community is here to help should you have any questions. I think it’s quite possible to get up and running with Hass for a complete newbie over a weekend. For second-timer - less than an hour.
HomeAssistant, Hass.IO, HassOS, Hassbian, Hass, HomeAssistant Core, HomeAssistant Supervised - what are those and why so many names? Isn’t it all the same thing?
(Updated on 03.04.2020 to address naming refactoring that happened in versions somehwere between 105 and 107)
I’
-
Hass - just a short from HomeAssistant
-
HomeAssistant Core (Home Assistant before naming refactor) is that main Python program for HomeAutomation. It’s the main part of it, the UI, the Core, Components, Integrations, everything. You can just run it as a Python program installed from pip or in a virtual env. This is how it started and how we were all running it back 2-3 years ago. But now there’s no point in using this approach to run Hass. And if you don’t agree - then this article is just not for you, you know your thing and your reasons For most users it’s not worth it though.
-
HomeAssistant (Hass.IO before naming refactor) is basically just a Docker version of HomeAssistant with Portainer-like hypervisor tailored to work with Hass. It adds some new UI options in Home Assistant Core and allows you to: Install AddOns (More on them later), Update your Hass with one click and some other useful things like configuration folder backups.
-
HomeAssistant Supervised - and alias name of HomeAssistant when it’s necessary to make a clear distinction between HomeAssistant (ex Hass.io) and HomeAssistant Core.
-
HassOS is a minimal Linux appliance distribution that has ‘just enough’ to run HomeAssistant. User has very minimal control over the host system, and it does not have a lot of things you’d expect in a general purpose distro, for example it does not even have a package manager, afaik. So basically if you wanted to do anything ‘out of the box’ with Hass then you better use some other installation method that using HassOS. It is the easiest to start with, though!
-
Hassbian is a legacy was or running Hass, it is a Raspbian OS (native OS for Raspberry Pi) with HomeAssistant preinstalled in a Python VirtualEnv. It has scripts which allow you to update it, to install additional software like ZWave support, and things like that. At this point it’s no longer maintained or supported.
So I hope now you get a clearer image of what Home Assistant, Hass.IO and HassOS are, and how are they related to each other.
My Personal opinion on HassOS
While it’s a very nice concept I personally don’t recommend it YET especially if you’re using Raspberry Pi - it is important to move your database off the SD card and minimize logging. SD Cards don’t handle a lot of stress from constant read\writes to it, so RPi can become unstable and worst case - you’ll break your SD Card eventually, not matter how good it is. For small installs it may work, but as your Hass install gets bigger with more sensors and data it gets worse. And HassOS does not provide you with tools necessary to adjust all that.
If you ask me it’s better to go with Hassbian than HassOS, at least you can tweak it to reduce logging and move database file somewhere else.
But sure for larger installs you should probably just use another DB option like Postgres. Those even on RPI will work better than SQLite that’s used by default (though I personally love SQLite).
EDIT 08.01.2020:
HassOS is getting better with each release, and the good thing about it, is that it’s very minimal OS with small resource usage. So OS itself is actually great, it’s not so much that I don’t recommend using it, it’s more that I don’t recommend running Hass on a Raspberry Pi with SDCard. Use SSD or some other device for Hass. Even with their Home Assistant Blue, which they recently released, they went with Odroid N2+ which uses eMMC memory.
Why should I choose HomeAssistant over just running HomeAssistant Core container in Docker natively with Portainer\Cockpit UI?
Because it’s convenient. It gives you built in update notifications out of the box, update with one click and one-click addons. And you don’t HAVE to use any of those, you can still install Portainer and any other docker images you want. Hass supervisor should not interfere with any of that, I’ve been running it on Ubuntu in one Docker host with a lot of other services and it was running smoothly.
HomeAssistant Supervised also makes installing and integrating things like NodeRed a one-click task.
There are a few downsides, of course. Currently HomeAssistant hass container does not support TensorFlow because it does not come with a few libraries required for it. There may be a few other components that won’t work with HomeAssistant, but I don’t think there are many of them. Chances are by the time you are reading it it’s been addressed.
Note that I’m talking about production install of Hass here, not for development, of course.
How does Hass compare to NodeRed? Why can’t I just use NodeRed?
Well, first of all - yes you can use just NodeRed.
Here’s a little rundown of what they are and their pros:
Hass - it has a lot more integration than NodeRed, it can generate a good looking and usable UI for you quite easily, and it can create simple automations with yaml or the ever-evolving automation editor. I have high hopes that quite soon Hass’s own automation editor will require little to no yaml configuration, and everything will be available in dropdowns and menus. So basically you can easily define linear automation flows with some triggers and conditions and simple AND\OR logic functions. It has no support for IF\ELSE kind of flows, for that you’d need two separate automations. Basically, if you can do something with IFTTT then you can do it locally with Hass.
NodeRed - it has far less integrations than Hass, but it’s a very powerful node-based automation editor. It’s basically simplified visual programming at this point. You have all the logic operators like IF\ELSE, AND\OR and others. You lay out nodes on the canvas and connect them with lines, much like a block-scheme. It can create complex and really smart automations with a lot of conditions, forks and details. For example my ‘bed time lights’ automation is just one flow: it checks if it’s day or night time and adjusts lights accordingly: if it’s day time and I nap - it dims the lights, if I wake up it turns then on 100%. If it’s night time and I enable sleep mode then it gradually dims the lights during the next 10-15 minutes and turns them off completely, and if I turn it off during night it will just turn on dim lights so I can walk to bathroom or kitchen. (I’d love to automate it based on bed sensor but I dont have one yet).
So, in my opinion Hass and NodeRed are best used together. Hass as compatibility layer and state machine, NodeRed for automations. I personally also prefer to use Hass native automations for simple tasks (when everyone away - turn lights off, for example), but I understand that a lot of people insist that if you gone NodeRed do it in full
Running it on RaspberryPi
Is the method proposed by developers. But it’s not ideal, and here’s why:
- SD Cards are not designed to run under high concurrent IO load. Running ANY OS on SD Card is already pushing it’s limits, but Hass has some extended logging and database operations which often can corrupt even high quality SD Cards. They can also be corrupted because of power loss or spikes. This is the main Achilles heel of RPi
- RPi3(b+) has limited USB and Ethernet speeds, only 100mbps tops on ethernet, only USB2.0 and USB and Ethernet share the same lane, so basically they have shared bandwidth.
It is possible to mitigate or even completely avoid these issues by:
- Using external SSD to boot from instead of an SD card
- Using RPi4, which has more RAM, faster CPU, and most importantly 3.0 USB, Gigabit Ethernet and separate lanes for them
Personally I find it still better to run it on x86 devices like miniPCs, nettops, thin clients. Examples include Intel Nuc (expensive brand), Gigabyte Brix, Lenovo ThinkCenter Tiny, AtomicPi, Zotac MiniPC line. There are a lot more options from known brands like Dell OptiPlex, as well as less known Chinese brands, both with active and passive cooling and varying power draw and hardware specs, so everyone can find something that fits their needs. Some of these options can even be cheaper than full Pi build.
Closest to a Pi in formfactor, size and power draw, I think is Zotac P Series mini PCs, like this one, though it’s quite expensive at 230$. However if you factor in the price of Pi + all required things like SSD, power supply, case and such, then this price may not be that bad, since it includes all of the above, comes preinstalled with eMMC storage, power supply a sleek case and even a wall mount.
You can run HomeAssistant directly on those using, say, Debian OS as host and running Generic Linux server install script. Or, better yet, install virtualization host OS on it like Proxmox. Then you can really utilize your hardware to full potential. Even Zotac Pico PC can run A LOT more than just HomeAssistant.
So you talk so much, how do YOU run Hass?
I now ended up running HomeAssistant (ex Hass.IO) inside a Debian Virtual Machine on Proxmox. This way I can enjoy HomeAssistant, not worry about it (unlikely but still) making any changes to the host or other containers, and keep it separate from the rest of the stuff that runs on my server. This reduces the chance of me breaking home automation by accident while messing around with other things, and vice versa. I have a separate VM that’s another Docker host that runs other things. I know I may occasionally at some point break it. HomeAssistant I don’t touch really. So if one VM breaks - another one is still up and running.
Also - backups. I can’t express how much I love being able to have scheduled Snapshots of all my VMs and containers that are then uploaded to the cloud (Yandex.Disk because it’s cheap here and has a nice CLI client). I don’t care about breaking anything - I can roll back with one click. I don’t care about my server hardware just blowing up. Sure that’s worse than just breaking one VM and will probably take a day or two to build new PC and install Proxmox and after minimal initial setup load all VMs back from backups. Still it beats having to set every service back up from scratch.
Sure you could use Ansible or scripts or something like that to make restoring your system easier. But one click still beats it
Also ability to manage resources between VMs and CTs is quite useful. And VMs provide additional layer of security. All in all I love my current setup.
I also did not spend any money on it, I used an old gaming PC for this, the only thing I added was expanding ram from 16 to 32 gigs and an 8TB drive for Plex and all other data (linux ISOs of course ).
Regarding NodeRed and automations I split tasks between Hass automations and NodeRed. I prefer to use Hass native automations for simpler IFTTT style tasks, and NodeRed for more complex logic.
(WIP will expand this article and also open for critique and suggestions)
UPDATED 03.04.20
- Edited talk about what all the different names in HomeAssistant mean, to reflect recent naming refactoring
- Added thoughts on Pi installs
- Minor tweaks
UPDATED 27.04.2020
- Thanks for pointing out that I forgot to replace Hass.IO with HomeAssistant in the second half of the article. Now, hopefully, all fixed
UPDATED 06.09.2020
- If you’re looking for current supported way of installing Home Assistant on Generic Linux it’s now called “Supervised” install and here’s the link to how to install it: https://github.com/home-assistant/supervised-installer
It’s official, and a link to that github page is located at the bottom of the install guide page right here: https://www.home-assistant.io/docs/installation/#alternative-installs