I started this project because I wanted to automate my home. But unlike many others, I am deeply concerned about privacy. And besides, I am a software engineer and an electronics enthusiast, and I always enjoy tinkering. So, I decided to take the matter into my own hands.

First and foremost, this is a hobby project. It does not aim to be perfect, easy to deploy and use or fit for every home. But it aims to be fun and respect privacy. And I decided to share it with the world. In fact, all source code and hardware designs are publicly available on GitHub (see below).

The project is in a state of flux. At the time of writing this blog post, I have been working on the project for more than 3 years, and it's nowhere near complete. It probably never will be because I have more ideas than time to implement them. I have a day job and a family, so I work on the project when I can. It is therefore work in progress, and will likely be for a long time.

Design goals

Use only free open-source software (FOSS)

Twenty or even ten years ago, it may have made sense to explain the power and benefits of FOSS. But today, I think it's very clear, and the internet is a living proof. Whoever doesn't get it is probably still stuck in the 20th century.

Send absolutely nothing to the cloud (privacy first)

In other words, what happens in my home stays in my home. This is extremely important in a digital era when everybody is after your data. Unfortunately, most people don't get it, and neither do they care to read the privacy policies for the services they use. Speaking of which, in most cases users waive pretty much all their rights and agree to have their privacy violated for free.

You may wonder why it matters if a random service provider knows when lights turn on and off in your home or what temperature your thermostat is set to, and furthermore if that data is disclosed to other third parties, intentionally or not. That data alone says something about your schedule and habits. But when it is correlated with other personal data, things get much worse.

And last but not least, voice command systems are likely the most dangerous. They must record permanently to be able to respond, because they can't know in advance when you talk to them. And, since most of the processing is done off premises, the recordings are in the hands of your provider, and you have no control over that. It is impossible to tell if they respect the privacy policy (which is way too permissive anyway), let alone fight them in court if there's any suspicion.

And I could go on for pages about why all of this is important, but I will leave that for a separate post.

Use DIY hardware as much as possible and to a reasonable extent

Proprietary hardware can be as bad as proprietary software, and pretty much for the same reasons.

Luckily, hardware is easier to confine than software. For example, a Zigbee device cannot leak any data to a third party simply because there is no communication channel to the outside. And that makes it acceptable to use a Zigbee device even if the hardware and firmware are not open.

Along the same lines, most WiFi based home automation devices and smart appliances inherently violate the privacy. Not because of how WiFi works (you can always block the communication in your router), but because they allow no local/direct control and depend on a cloud service and your internet connection to be controlled.

Most manufacturers don't get it, or at least they pretend they don't. We don't need their sketchy mobile app (which often is a privacy hazard just by itself) or their cloud service. The ease of use they offer comes with a very high toll on privacy. Remote control can be done safely and privately with FOSS, but requires extra work, which I am happy to do.

Architecture

As mentioned before, the project is in a state of flux. The diagram below shows the current architecture, in terms of both hardware and software.

Home Automation Architecture

Legend:

  • Yellow boxes represent standalone off-the-shelf hardware.
  • Gray boxes represent support hardware, either off-the-shelf or DYI.
  • Blue boxes represent third party FOSS.
  • Orange boxes represent personal FOSS.

The "?" (question mark) box is essentially a home automation controller but it is not yet deployed, and I am still exploring multiple options. I am considering the following FOSS projects, likely in that order:

Even though it is not included in the architecture diagram, I am also considering voice control but this is particularly sensitive from a privacy perspective, since most solutions send the audio stream to the cloud for voice recognition and semantic interpretation.

Rhasspy Voice Assistant looks extremely promising. However, the project relies on other external projects for each of the main features (wake word, speech to text, intent recognition, text to speech), and with the multitude of choices for each feature, it is harder to make a decision. It will likely also influence the choice of home automation controller, even though all three projects listed above are readily supported.

The table below summarizes the software components and DIY projects that are currently part of the architecture.

Project Description
Zigbee2MQTT Zigbee to MQTT bridge
Eclipse Mosquitto Message broker that implements the MQTT protocol
Memcached A distributed memory object caching system
Graphite An enterprise-scale monitoring tool
yawd Collect and display local weather data
hvac-app HVAC controller - application software
hvac-eda HVAC controller - hardware design
aqmon-app DIY indoor air quality monitor - application software
aqmon-eda DIY indoor air quality monitor - hardware design