Sunday, October 5, 2014

Circles of the Home Automation hell

Introduction

Just a week ago I knew nothing about IoT. All the buzz was meant (I thought) for someone else, but that changed when I bought a house. Suddenly, a strange desire was born in my mind: to connect entities (doors, rooms, speakers, etc) inside my house, to monitor and control them as a system. Thus, I started looking into Home Automation, and with each new iteration I was diving deeper and deeper into the hell of technological diversity.

 

0. Complete Solutions

There is a lot of companies (like this one nearby) offering to install their proprietary home automation system for a big sum of money on the case by case basis. That wasn't acceptable for me, because I wanted to know what my options were, and expand gradually.

 

1. Isolated subsystems

Some companies specialize only in a specific domain. For example, Lutron is known for its lights and dimmers, which come with remotes. Phillips Hue makes the best LED lights, also remotely controlled. Nest is a decent (and awesome looking!) learning thermostat. Going wider, Vera allows you to buy components that you need and attach them to the system dynamically. Naturally, I started asking myself why these things can't be organized together, what language to they talk to each other?

 

2. Wireless Protocols

It turned out, there is a lot of diversity in wireless means of communications. You thought that WiFi and Bluetooth are enough for everyone? Welcome to the real hell:

ZigBee - perhaps, the oldest protocol (outside of X10, which we'll skip). It's looking decent on paper: support for mesh networking, low power consumption, huge group of supporters. It is ISO certified, and you can find numerous open source libraries and protocol implementations. However, the devil hid in the details, again. There are two incompatible kinds of hardware: Series 1 and Series 2. There are different profiles of communication, and you can't easily mix and match those. Finally, I tried to look for something specific, like a temperature/humidity sensor, and it came short of options for the real "Buy" button to appear. It appears that Zigbee has some fundamental issues (maybe those I mentioned) that pushed the alternative developments.

Z-wave - the most available (in terms of hardware) protocol, which also claims to be very smart in design (mesh networking and such). It is really straightforward to find actual devices, but unfortunately difficult to program them: the API is opened only after buying the SDK and signing an NDA. Open-source implementations exist but seem to be rough and incomplete.

EnOcean - the european-origin protocol with the main focus on self-powered devices. There is not much out there to read about it, but the limited range of compatible devices is available from a single manufacturer. The promise of battery-less components seemed very appealing, but it got compensated by the price of those.

Other things I didn't research include Insteon, Bluetooth Smart, WiFi (for IoT), ClearConnect (used by Lutron), and Thread (used by Nest). The last one seems exceptionally promising, but no public information is available yet about it.

At this point, I realized that if I'm gonna control my devices, they had to use the same protocol. Alternatively, I found a market of cross-protocol universal hubs, such as Wink, Revolv, Staples Connect, and SmartThings. While they do allow using devices from different networks, I found only Wink providing an actual API, which I doubt works flawlessly. If you don't intend to be in full control, this may be your last stop (for good).

Another problem, adherent to most solutions, is the requirement of Internet access. While I do appreciate a mobile app to access my home system, I believe it should not involve a cloud server. The cloud is a privacy hole and yet another point of potential failure. My system should be as much self-contained as possible.

Thus, I wanted to go deeper... The hub, I imagined, could be a headless Raspberry Pi with a RF module (like XBee) that I'd program myself in Rust. Fortunately, Pi supports modules for all major RF protocols. The hub would host a website for online access and schedule my house in a 24/7 mode. The only problem was locking into a single protocol (and its API), because I didn't want to hook up and dig into multiple protocols at once.

 

3. Micro-controllers

I noticed that sensors without RF modules are very abundant and cheap. What if I connect them to my own network physically, by having a micro-controller and a RF module attached by hands? That perspective made me look into simple computing cores:

Arduino - the most known family of boards, featuring dominantly the AVR family of controllers. Sadly, LLVM (and hence Rust) does not support this platform as a target, and the cheapest ARM core (Arduino Due) is more expensive than Pi. If not for these factors, I'd go with Arduino in a heart beat, for it's rich documentation and wide community support.

STM32 family - the most open-source friendly ARM chips out there. Rust has a Zinc project of running on bare metal, that was developed for this chip. Prices start as low as 8$, and there are extension boards available.

Tiva C launchpad kit from Texas Instruments - the most impressive ARMs in terms of website navigation and availability of standard extensions. Bare boards start at 13$ and seem very solid, thus being my current choice.

Freescale Freedom Boards - the most diverse family of ARM chips. I found it difficult to navigate their website and to figure out what exactly I need there. Can't see any extension boards in particular, but I'm sure there are some. Prices start at about 16$, though these boards include some LEDs and switches for demonstration purposes by default.

 

Conclusion

As a starting point, I decided to order one of the low-end ARM chips, and try to get anything programmed to it in Rust. That will take me a while... I may end up contributing some code into Zinc, or even shifting to robotics after-wise, because that's where MCUs really shine. At the same time, I'm going to buy a Nest thermostat with a couple of Nest CO detectors for my family to enjoy while I'm tinkering with low-level stuff. If I ever reach the point where I could control my HVAC and other things remotely by my own program, I'll be happy to replace Nest with something dummier, or just hack it to get the root access to HW.

If thought about home automation, have some solutions installed, or are building your own hub in the garage - please share, as I'll be happy to learn from your experience. If you didn't care about IoT and my article made you interested - you are welcome ;)

5 comments:

  1. I'm kinda in the same boat :)
    Completely agree with you about this craziness of the protocols, vendors and interoperability. Personally I did not make my decision just yet about a communication backbone in my smart home. Most likely it will be WiFi network on ESP8266-based nodes with custom binary application protocol. Or a mesh network on nRF24L01-based nodes.
    Either way, I'm going to use Arduino or bare AVR micro-controller (C/C++) on nodes and some ARM-based board for "ground control" (Scala + Akka :).

    ReplyDelete
  2. Awesome! I like the way you are thinking :) Confirms that I'm not entirely crazy with this. I haven't seen these ESP8266 and nRF24L01 things. The former seems to have a neat cost of 7$, even though I'm curious if wifi energy consumption will bring you any trouble. The latter - what protocol does it use for the mesh networking?

    Computation-aside, I'm a bit puzzled by the task to connect the MCU with an energy source, RF transmitter, and a sensor into a meaningful box. I assume I'd need to either use the bulky (and expensive!) devkits, or design a board myself from scratch, which seems to be a huge task on its own, especially for an unexperienced noob like me. How are you gonna wrap these nodes into boxes?

    ReplyDelete
  3. I did not spend much time researching mesh networks on nRF24L01, just know there are many implementations.

    For a wireless sensor node i found a neat solution here: http://www.seeedstudio.com/depot/DevDuino-Sensor-Node-V2-ATmega-328-AAA-battery-holder-p-1850
    It gives you AVR + nRF24L01 in compact form factor, powered from 2 AAA batteries. Power consumption solely depends on efficiency of your firmware. The idea is that most of the time system is in deep sleep, awaking periodically by hw interrupt to perform a job and to send / receive data.

    ReplyDelete
    Replies
    1. That's cool! The link is missing ".html" on the end :) So for 17$ you get a nice base, and you only need to connect it to something and enclose in a box. Are you planning to 3d print some boxes? I also see your transmitter there for a mere 3$: http://www.seeedstudio.com/depot/nRF24L01Module-p-1394.html

      These AVR chips, despite being old, seem to be a decent choice for the home nodes. I'd probably go with them as well if LLVM/Rust supported it. Meanwhile, I've ordered STM Nucleo L1 board (ARM) + Bluetooth LE extension to play with. Will keep looking for integrated variants with batteries, like the one you have ;)

      Delete
  4. This comment has been removed by a blog administrator.

    ReplyDelete