A DIY cloud centered, iOS controlled, Arduino based Home Automation System – Part 1

There is a lot of buzz around things like “Internet of Things”, “Home Automation”, and “Smart Homes”. One reason for buying into commercial home automation systems is energy savings. At least that is often the main marketing message for commercial products. That is not true, as recent studies found out, and it is not my main motivation to build such a system.

A lot of commercial systems use Bluetooth (Low Energy) Systems zu drive their home automation solutions. You have a device, and an App that is connected to this device to control it. Sometimes, you have an array of devices, that are connected to a hub often with Zigbee based Mesh networks (so your Smartphones App only needs one connection). One example for that is Philips Hue Light System. Apple realized this is a problem as no one wants 10 Apps to control different aspects of their home and introduced HomeKit. While this really sounds interesting on iOS-Controller side, it remains to be seen how this works out on devices and compatibility (and price of course).

When I first got my Philips Hue System I have been impressed and loved it from day one and do so till today. But we have not installed it in every room. And controlling it with your phone is great, but it’s also tedious to pick up your phone to turn on light in a room you are just entering and turning it of when leaving the room. We often end up using the light switches on the wall, which kills that whole Home Automation thing as lights switched off on the wall cannot be turned on again wirelessly.

IFTTT  and Philips Hue: just magic

Things got really interesting when I tested IFTTT.com. What a great service. With “If This Then That” it’s possible to interconnect different web services and trigger actions based on data or triggers of other services. I created a very small receipt turning on my Philips Hue lights at sundown and turns them off at 1 o’clock in the night as a fallback if I just forget to turn lights off when I go to bed.

And it really works well most of the time. And that is really magic. If you have Philips Hue installed. Give it a try. It’s magic. Yesterday I have cooked and thought that it’s about time to turn the lights on, a few seconds later they turned on. Without pressing a key. Without picking my phone. On cloudy days, you sometimes have to turn lights on before sundown, because it’s just kind of dark. This is where large scaled systems like IFTTT have not enough details.

That’s been the moment where I decided to make my own DIY cloud centered, iOS controlled, Arduino based wireless Home Automation System.

Data and realtime is key to success

For me a smart system as a system that is able to make the right decisions at the right time. Right means that it should come up with the same or better decisions than me. To be able to do that, you need data. A lot of data. The more the better. And you have to build clever algorithms that analyze these data and decide what to do.

And of course these systems have to be realtime, or near realtime. It does not help if data occur that should trigger some action, but this action is only executed about every 15 minutes. Well, it must be realtime.

I thought about the features my home automation system should offer and came up with the following rules:

1. Wireless for more than 10-20 devices, but not more than 100
2. Battery powered nodes, I do not want to have all power slots blocked for small nodes lying around
3. Batteries should last 6 month, better 1 year or more
4. Mostly invisible (Woman Acceptance Factor is important here!)
5. It must be cheap – not more than 15-20 Euro per Device
6. iOS App controls everything
7. Cloud based data storage and push notifications (I did not want to build a web server on my own – that is my daily business, so no server programming in my spare time!)
8. Another possibility of controlling the most important parts of the system without an iOS Device (the good old button or a LCARS-System on the wall – how cool is that!)

I also had to decide what data I would like to gather to automate the most important things. I decided on these:

• Temperature
• Brightness
• Color or temperature of light (warm light or cold light)

I also thought about having some form of movement sensor to know if a room is empty or not. But as I have not found a sensor that will allow me to fulfill rule 3 (these sensor are quite current hungry as they have to run all the time to measure differences) I dropped the idea. I think there will be other possibilities to deliver this functionality, i.e. by adding a very cheap and small iBeacon device on every room using RFDuino.

Components

Finding the right components is the most time-consuming part. A great help are breakout boards from Adafruit and Sparkfun. Breakout boards offer an easy way to connect to very, very small components with wires on a bread board. I really love Adafruit and Sparkfun because their products always come with ready to go source code or libraries. This way you can test a component if it fits your needs without soldering or writing drivers based on data sheets to just test a component.

Wireless

In order to fulfill my ruleset I had to decide on the main components my system is built around. The first thing I did was to lay out and define the basic building structures. As I knew that WiFi would break my rules 3 (long battery life) and 5 ( cheap) I had to find something else. Zigbee protocol is great for this kind of application as it has been exactly developed for it. Building self organizing wireless networks. There are great products within the Arduino Eco System with Xbee. But the Zigbee protocol is quite complex and the main reason I dropped this option: not cheap.

Searching the web, I found nRF2401L+. That is a very small and very cheap RF transceiver using the 2,4 GHz Range, so being free of any regulations or other restrictions. Completely assembled modules can be bought for 2 Euro at eBay or Amazon.  Wireless will not get any cheaper. What nRF2401 lacks is a built in protocol as Zigbee devices have. But there is a very, very good Arduino library (more on that later) and these little devices are quite powerful and meet all my criteria. They are cheap, small and correctly implemented they run on small coin batteries for months.

Using this type of radio would need a hub or proxy that indirectly connects these devices to the internet. This hub must be able to talk to the other nRF2401+ devices and must have WiFi on board. There are a few options here. As I only will have one hub per home and it will be placed near the router I had no problem with the hub breaking rule 2,3 and 4 (battery powered and nice looking). The best solution would probably be a Raspberry Pi as the nRF2401 library I told you before also has Raspi drivers. But I opted for an Arduino Yun. It has everything embedded what I needed and I would not have another layer of complexity as the Raspberry Pi would introduce. Running more or less the same nRF2401 Code on the devices and the hub makes things easier. The Yun is an amazing small little device, as it combines the best of both worlds: An Arduino micro controller and Linux for networking.

Recently I found an interesting Kickstarter project: Aurbee. In their introduction video they talk about a very small and cheap Zigbee Chip. I think I found one that matches their description, but it’s in a very small QFN Package and you will have to implement it all by yourself. Perhaps Aurbee, or implementing your own, cheap Zigbee QFN is an option, but I will stick with my decision to run my network with nRF2401L+.

Capacitive Touch

As said before I don’t like to pick my iPhone all the time whenever I want to control any part of the system. If I am standing in a room and want to turn on lights – there will be cases where the automated light system will fail – I would like to just press a button or switch to turn lights on or off. Buttons are not nice. It’s a quite complex task to get buttons right, especially in custom designed enclosures. I decided on using touch. There are amazing capacitive touch controllers out there providing another layer of fun with proximity detection. I did some tests with Sparkfuns Touch Breakout (Freescales MPR121) and it worked beautifully in my tests.

But I do not have space to embed a breakout board in my final design. And I did not want to mess around with QFN as I wanted to hand solder my final boards without investing into a Reflow-System. I have searched for other capacitive touch ICs that are available in solder friendlier packages. I finally found the Atmel QTouch 2120. As I just need a button that is either pressed or not, I can use the provided Standalone mode. This mode provides a predefined setting and touch values can be read without using I2C. For the sake of completeness: The other mode is called Comms Mode. Using I2C you can configure every aspect of this little IC and program complex touch interfaces. For my project I stick with Standalone mode. But it’s great to know that there are endless possibilities waiting for me by just changing a pin.

Temperature

I did some tests with very simple temperature devices like TMP36 and results were ok. But I just wanted that little bit more precision. Therefore I decided to integrate a TMP275AID into my system. This IC can be easily read with I2C and is very precise (0,5°C) and can easily be soldered.

Light

Measuring available light is a very important component of my system. A simple photo resistor is not good enough, as its sensibility in darker rooms is very limited. I found this breakout board at Adafruit. That sounded great and so I went with this little IC. As Adafruit provides source-code I could easily integrate this product into my firmware. But, there is a bummer: It’s some kind of a QFN-Design. I have been optimistic that I would be able to solder that 6 pin bastard with an iron, as the pins are vertically exposed and come on: 6 pins: That should be possible. I ordered a few more ICs from Mouser – just in case…

MCU

As I wanted an Arduino compatible sensor node this has been a no-brainer: Atmel 328p. I wanted the 328p variant as I wanted as much SRAM as possible, as I had a few libraries to implement – and a bit of storage if the hub or wireless network is down is not bad at all. I decided on the TQFP32-Package as this is easily solderable with an iron but small enough to leave enough room for the other components.

Cloud Data

Building cloud based apps and applications is a mess. You have to work with Databases, Webservices, Scripts, etc. You have to setup a lot of boilerplate code, even if you just want to drive a RESTFul-API with Zend Framework 2 (my personal favorite combined with Twitter Bootstrap and Doctrine) for example. As this is bread and butter in my daily work I did not want to have this in my spare time again. As I am constantly searching for services that make my life easier and that allow me to work on what really counts for my application I found Parse.com. What an amazing service! Fees are really fair and my sensor network will never send so many data that I will have to pay for it. And even if I ever have to pay for it: It’s worth it. Parse.com provides everything that is necessary to build great, cloud based applications. And it has SDKs for all major parts of my system. That best part about Parse.com is Cloud Code. You just write Backbone-based JavaScript-Code that is run for example if new data is saved. That allows for easy triggering and maintenance work. Of course sending push notifications to iOS and Android-Devices is available, too.

Just give it a try the next time you have a cloud based approach or if you just need to save some highscores on a server. It’s setup in minutes and you never have to care again.

Putting it altogether

In the next part we will dig into my project. I will start with the design constraints I had in this project to fulfill rule 4 (most important, remember that WAF!) and will provide my final Schematic and Board-Design.