Home Automation Framework

Example Use Case

A user desires to turn off a lamp that is connected to a Home Automation Framework Power Module. The user navigates to the Home Automation Framework web application on his or her smartphone or desktop computer, and taps a button with a relevant icon in order to send a command to turn off that specific module. The lamp is then turned off by the module.

Overview of the Process

Protocol Selection

Client: Web App vs. Smartphone App

The client is the face of the whole project. It is what a user will see and interact with in order to use the product. Therefore, it needs to be simple to use and easily accessible. We chose to implement the client as a web application rather than as a operating system-specific smartphone application in order to address the latter issue. A web application can be loaded in almost any device that connects to the internet, and the HTTP protocol is a tried and true protocol that can be relied on to work.

Had we chosen to implement the client as a smartphone app, we would have to decide which platforms to develop it for, such as iOS, Android, or WP8. Each one of these platforms has its own advantages and disadvantages, but each requires development specific to its own operating system. To serve just these three platforms, three versions of the client would have had to have been developed. In addition, since we wanted to make it accessible in computers, we would have needed to develop Windows, OS X, and Linux applications as well.

The web application approach solves these issues of portability, as it is simple to develop a website that can be accessed via all platforms, since they can all browse the web. Another potential issue it addresses is updates. In a smartphone application, any update to the client would need to be implemented for all platforms; however, with a web application, only one update need be made, to the server.

The benefits gained from a smartphone app would have been very few in comparison to its drawbacks. The client is not complex enough that any kind of native implementation would significantly speed the process. Having icons stored locally also doesn’t significantly benefit the user, as the client would still need to communicate with the server both to load the client and send commands.

Module Communication: WiFi vs. IR vs. X10 vs. RF

Let us now examine the choice of protocol to communicate with the Home Automation Framework Modules from the Home Automation Framework Server.

WiFi:  The WiFi network provides some benefits. For example, if every device was connected to the network, then the server could be bypassed, and the client could communicate directly with the modules. There are some implementations of similar projects that use the network for this purpose, which is what drives the movement called The Internet Of Things. However, this approach increases the complexity of each module, as each then needs its own IP address, and a smarter application layer process that could handle IP packets. Given that we wanted to make the modules relatively simple and inexpensive, we chose not to use WiFi for the modules.

IR: Using Infrared beams was another protocol we discussed. As far as addressing is concerned, using infrared might simplify matters if we had a remote control that we could point to the module, but in the server/module paradigm, we would have had to still implement addressing, at the application layer. With just an IR receiver, a module could receive commands and execute them. In addition, we could program the module to respond to commands from any IR blaster, like a TV remote, thus making additional devices potentially compatible with the design. However, the disadvantages proved greater than the simplicity this protocol would bring. However, one sizable disadvantage to this approach is the limitation of line of sight effective range. If the server or remote doesn’t have a clear view of the module, then this implementation wouldn’t work. Since this would greatly reduce the range of the modules, we decided against it.

X10: The X10 technology has been available for a while now, and is a protocol for communicating within household power lines. It has been used widely in the past for home automation projects just like this one, so it’s an interesting protocol to look at. The X10 website offers similar products, which use the power lines within the home to communicate with each other, and modifying these products to fit our needs wouldn’t have been hard. However, we found that it wasn’t as simple or flexible as we desired for our project goals. The commands to turn lights on and off are already preset, but there are only 4 bits available for commands. While that would satisfy our immediate needs, further expansion ideas that we had would have been incompatible with the project. In addition, modules would be limited to devices connected to the same power network, excluding battery operated devices, and devices connected through a transformer or regulator.

RF: Finally, we arrive at the protocol we actually chose. Unlike WiFi, we didn’t need to give each module its own IP address or WiFi card, and the addressing could be handled directly by whichever microcontroller is powering the module. Unlike IR, it doesn’t suffer from line of sight issues. Unlike X10, RF can send more complex messages, and address any device in range, regardless of how they are gathering power to run themselves. RF was chosen for those reasons. Specifically, we chose the nRF24L01+ RF module to run the RF signals between the servers and modules. Its low cost and high bandwidth and range was ideal for our project.

Module Microcontroller: Arduino vs. ATtiny

An important decision was to decide which microcontroller to use for controlling the modules. The Arduino was readily compatible with the nRF24L01+, and there are multiple guides to make the Arduino interact with almost any device already, so it would have been an easy pick. The ATtinys are harder to program and have fewer pins. In addition, the nRF24L01+ wasn’t readily compatible with it, and we would lose some functionality using an ATtiny with it. However, we ultimately decided to use the ATtiny85 for its smaller size, reduced cost, and lower power consumption. With some extra effort, we were able to control the modules with the ATtiny just like we would have with the Arduino.

Server: Raspberry Pi Vs. Arduino

While the Arduino is a great platform for many great projects, it is not as good as a web server. It is possible to run commands over the internet to the Arduino, but it requires a lot more configuration and setup than we thought was necessary, given the existence of a great alternative, the Raspberry Pi. The Raspberry Pi already comes with a ready to use Ethernet port, and can easily be configured to run an Apache Server, Python scripts, and has easy-to-configure GPIO pins. While it is a bit more expensive than an Arduino, the increased capabilities and ease of use of the Raspberry Pi still made it an ideal overall low-cost server.

Unique Features

For this project, we wanted to make sure we could deliver on some specific features that would make it stand out. Here are some examples:

Simple Web Interface: We wanted to make the user interaction as easy and straightforward as possible. To do this, we designed the icons to represent which module they were controlling, and give feedback on which state they are in, so the user knows whether they’re on or off. This simple interface makes it easy to use for children, people with poor vision, or people with disabilities affecting speech or motor control.

Scalability: Our project makes it very simple to add new modules to your home. Simply plug in a new module, add its button on the interface, and it’s up and running. Future versions of the project could dynamically add new buttons as new modules are detected, but for this iteration, we kept it manual.

Open Source: For the project, we released all of our code as open source, and used components that anyone can buy readily online, or at their local electronics store. This way, anyone could replicate our project and add more features or fix bugs. We appreciate all the help!

Low Cost: Whenever possible, as in the Arduino vs. ATtiny choice, we picked components that are cheap and easy to get, so that our final product could be affordable but still very powerful.

VI. Assembly