In Part 1 I outlined thoughts on assembling my ideal smart home and its operation. And at the heart of any smart home is the hub, connecting the communication between devices. But when looking at existing consumer products I’m still not yet convinced they are able to handle more complex interactions. So I went searching for alternatives.

One option I had been aware of for some time now is the open source project openHAB. But although I’m sure it’s a fine product, on the surface it looked a little too complicated for the time I’m willing to invest. Granted I didn’t give it a chance with a test setup, but in any case I decided to look elsewhere.

Then I stumbled across Home Assistant, a another open source project.

Home Assistant

With an easy to navigate website, finding relevant information was a painless process. The online demo shows a modern user interface, which it too is a breeze to navigate. This is despite my wanting to interface with my home using voice via my Google Home virtual assistant.

Home Assistant ticks a number of boxes:

  • Open communication with devices (a lot of devices!).
  • Cheap to install, but still powerful in features and performance.
  • Quite easy to configure and use.
  • Runs locally, so no reliance on the internet.

Without a doubt one of the strongest draw cards is the exhaustive list of connectable devices and services. Currently over 600, and counting. Each device/service web page comes complete with simple documentation for configuration.

And this was the light bulb moment I needed.

If choosing to go down the Home Assistant path I no longer have to wait on proprietary consumer devices to catch up. Consumer devices which are slow to adopt integration of other platforms and devices.

The strength of a good ‘open source’ project like this is in its flexibility and robustness, while still remaining agile to changes in an infant market.

How does it work?

I can’t yet provide an in-depth explanation as my setup is only young, but here’s what I understand so far.

Raspberry PiIt runs on a Raspberry Pi, a very small single-board computer, and the setup could not have been easier. Once installed, it crawled the network doing an impressive job of detecting devices. But despite not having any sensors on the network (yet), it managed to find all the mobile devices, computers, and media devices.

A simple YAML text file maintains the system configuration. It’s not the most elegant or user friendly method, but it gets the job done. The config defines the user interface, as well as the Actions between devices.

Occupant mobile devices like phones generate historical data, and is used as a means to detect their presence. This lets Home Assistant know if an occupant is home or away. The media devices also generate data such as if they are in use, and in most cases show what’s playing.

I also added user interface features for weather data. Not that I need to read this data, but it could be useful data for actions between devices. An example could be a reminder from the virtual assistant to close all the identifiably open windows if a storm is approaching.

Home Assistant states

I especially like the simple History view showing the different device States. It’s a basic log of the devices. This historical data could provide context to the devices when performing actions.

As a test, I created an action for when I returned home. After it detects my mobile phone on the home network, one minute later the Google Home says “Welcome home”. It was simple, but confirmed that I could get the devices to interact with each other.

Home Assistant History

This historical data will continue to grow as more devices such as sensors are added to the network. And so too the value of that data increases. I also believe this data is accessible through Home Assistant’s API for other outside uses, possibly with a building information model (BIM).

I’m feeling quite comfortable that my new Home Assistant hub is going to be a great option in the long term. Given the reliability so far and general user friendliness, at this stage it is here to stay. This has provided enough confidence to move onto the next phase of purchasing a few sensors.

And speaking of sensor data there’s one specific type which has recently captured my attention, energy monitoring. I’ll share my initial thoughts on this in Part 3.

Chad is a consultant to the AEC industry, a design technologist, VDC advocate, BIM Manager, early Revit adopter, and public speaker.