Home Automation System

Jacob Minyoung Huh, Jene Li, Michelle Nguyen

December 19, 2014

Introduction

In the past, predictions of technology included vi-sions of the future home as a fully-automated, inter-active ”smart home”. With the rising popularity ofthe Internet of Things phenomenon, many attemptshave been made in the field of home automation.From thermostats that can predict your desired tem-perature, to systems that can monitor and control thelights throughout your home, that vision of the futurehas been realized. However, despite such widespreadpursuits in home automation, the majority of today?smodern homes do not utilize these home automationsystems. Our goal is to create a home automationframework that remedies the problems of these cur-rent home automation systems. This includes creat-ing a framework that remains connected and inter-active despite losing internet connectivity. We alsofocus on the expandability and flexibility of our plat-form for easy use of both custom sensors and existingsensors already in the market. Furthermore, we de-sign our system so that it provides a simple, intuitiveinterface that is easy to build any application upon,allowing us to serve as a strong platform on which torun any household’s desired application.

Overview

For our system, we decided to focus on three corecomponents: the sensors, the server, and the integra-tion of the former. These are implemented over twophysical modules: the sensor module and the servermodule. The sensor module consists of libraries thathelp us make our platform flexible, expandable, andeasy to use. The server module employs two servers,one that is run locally, and one that is deployed onthe cloud. These two modules form a concurrent sys-tem that ensures that our sensor data is always be-ing recorded regardless of internet connectivity. Thesensor data can then be accessed either locally orthrough the cloud via simple APIs that help sim-plify the application development process. The gen-eral system model of our modules can be seen in the

following, where each module can further be repre-sented as a finite state machine:

Figure 1: General system model

Sensors

The lowest level of infrastructure in the projectcomprises of sensors, which provide the valuable real-time data used in home automation. Manipulationand use of the real-time data are used in applicationsthat are to be determined by the users and develop-ers. Instead, we focus on creating solid libraries as astate machine, which allows the developers and usersto employ the libraries in a reliable and effective way.By creating these libraries, we are abstracting awaythe details of the hardware and communication pro-tocol so that it does not have to be handled by thebackend users.

The sensors we have incorporated use two ways ofcommunication. One subset of sensors uses pure ana-log reads, where the microcontroller reads the out-put pin value. The other uses the I2C protocol, inwhich communication between the sensor and thecontrollers is made through acknowledgement. I2Cappealed to us because of the amount of freedom itgives to the users and the developers. Due to the factthat it does not depend on the number of pins, I2Chas no limitation in the amount of sensors we can useand users are guaranteed a full range of use with just

1

a single processor. By maximizing the capacity of asingle processor, we see great potential in using thesesensors for home automation.

Analog Read

So how are the libraries actually modeled? We canview I2C libraries as an improvement upon the ana-log read libraries, or the analog read libraries as asubspace of the I2C libraries. The analog librariesare composed of methods which can be easily seen asa rough state flow graph. Every time a reader request

Figure 2: State flow graph for analog read libraries

is made, the library calls read data and checks if it isvalid. If the data read is not valid (e.g saturated orunuseful) we will acknowledge that it is not useful andnotify the user that an error has occured. This stepcan be checked during the application. After it hasensured that it is valid, depending on the sensor, wewill compute gain depending on the noise and pushout the scaled, meaningful data.

I2C

Similarly to the pure analog libraries, the I2C pro-tocols have been defined. The I2C protocol consistsof acknowledgement between the master (processor)and the slave (sensors). We first check if the sensorconnection has been made and additionally check ifthe revision number of the sensor matches the one wehave seen in the data sheet. After all initialization hasbeen done, then we can start requesting data. Theunique slave address gives us the freedom to connectto multiple I2C devices.

We can see that this is very similar to the pureanalog read, except that we check if the initializa-tion and connection has gone through correctly, in

Figure 3: State flow graph for IC2 libraries

order to avoid reading corrupted data. Though ex-tracting data is much more complicated than pureanalog, it will not be discussed in this report. Fur-thermore, we can represent our I2C libraries as a statemachine, which also encompasses the state machinefor the analog read libraries.

Figure 4: State machine for IC2 and analog read li-braries

The state machine starts with initialization. Ittransitions to wait if and only if initialization has fin-ished correctly. The state machine will then stay atthe wait state until an input read request evaluatesto true. When this guard is evaluated to true, it willread data, check the validity of the read data, andtransition to read. If the value that has been read isnot valid for any reason, it will transition to the errorstate. Otherwise, it will transition according to thesensor type it is computing and push the scaled data.Finally, it will return to the wait state, where it willwait until the next request is present.

The types of sensors we have written libraries for inthe project have been chosen in respect to the impor-tance of how the real-time data impacts one’s daily

2

life. The following image includes the types of sensorsand the sensor libraries we have developed.

Figure 5: Sensors with written libraries

Integration

In order to integrate our sensor modules with ourserver module, we decided to use a lightweight TCPprotocol over WiFi. This allows our server modules tobe connected across the home wherever WiFi reaches.With the addition of a uninterrupted power source onthe router, the TCP connection will always be run-ning regardless of power loss or internet connectivityproblems.

Figure 6: Demo board for integration module

For our demo, we created a small application todemonstrate our system. This application uses threesensors: a humidity, barometer, and temperaturesensor which constitutes as our sensor module. Usingan mbed RedBearLab nRF51822 paired with anAdafruit CC3000 WiFi breakout board, our boardacts as a TCP client and interfaces with the localserver by sending sensor readings.

WIFI TCP Read

wifi/ tcp/ read()

/read request!tcp/ socket.open()!wifi/ reconnect

!wifi/ !tcp/

!wifi/

data/send data

Our demo application can be modeled by the abovechart in addition to the sensor FSM running concur-rently. When in the READ state, the FSM outputsa read request signal that is fed into the applicationFSM. When data is received, it then sends it over tothe server over the TCP connection. If the serverconnection is disconnected, it will halt reading andattempt to reconnect. This leads to the followingfeedback model of our concurrent system.

Figure 7: Integration concurrent model

Backend

The backend consists of two servers–one that is runlocally on a mbed board, and another which is de-ployed to the cloud. Both servers aggregate and storethe collected sensor data, which the user can accessthrough simple, intuitive interfaces.

Local Server

Figure 8: mbed board for the local server

The local server is running on a mbed FRDM-KL25Z with an Adafruit CC3000 WiFi breakoutboard for internet connectivity. It is also connectedto a SparkFun MicroSD breakout board so that thesensor data can safely be stored, mitigating the lossof data during any possible power outages. The localserver acts as a TCP server, which polls and waitsfor requests from clients. These requests may addnew sensor data to the server, or may get existing

3

sensor data from the server. This is done using sim-ple payload formats that bear a slight resemblanceto those of a RESTful API, allowing it to be intu-itive to use. To send data to the server, the payloadformat is ”POST sensorname value”, which will savethe value for the sensor with that sensor name, andreturn the id of the entry that has just been stored.Similarly, if a user wants to access data on the localserver, the payload format is ”GET sensorname id”,where the id of the entry they want is the same asthe one given when the data is POSTed. The serveris flexible and allows for any sensor name, and thusany type or number of sensors, to be stored.

When connected to the internet, the local serveralso relays data to the cloud server as it receivesthe data. However, during periods of no internet ac-cess, the server notes which data entries have not yetbeen pushed to the cloud. A timed interrupt which isscheduled for every five minutes, checks whether thereis internet connectivity, and if so, will push these up-dates to the cloud. Similarly, another timed inter-rupt scheduled for every ten minutes will attempt toreconnect the server to the internet if there is cur-rently no internet access. We see that our home au-tomation system differs from several other platformswhich take a ”Cloud-First” approach, which rendersthe platform unusable during network outages.

Figure 9: State machine for the local server

The state chart for the local server is above. Wesee that after initializing, the server begins to waitfor clients. From here, it can either receive a client,or execute an attempt to reconnect to the internet orsend updates to the cloud server. After each action,it will return to its polling state.

Cloud Server

The cloud server is deployed via Heroku, atee149has.herokuapp.com, and uses a web.py frame-

work for the Python server. This server aggregates allof the data sent by the local server and safely storesthat information in the cloud. This allows users toaccess all of the available information and monitortheir home regardless of where they are. Accessing orsending data is done through a RESTful API. Thisfamiliar protocol style allows users to easily query forthe data they need, making it simple to build applica-tions upon our architecture. Users can either chooseto receive a single sensor value by providing an id, or,if no id is provided, they can receive all of the sensordata via a JSON format.

Conclusion

We have created an architecture that is easily us-able and extendable through the design of core sensorlibraries. By integrating our sensor module with ourlocal server module, we are able to provide a workingservice regardless of internet connectivity. We thenfurther improve the robustness of our system by uti-lizing a cloud server, also allowing users and theirapplications access to data beyond the home. Fur-thermore, we offer simple, intuitive APIs that userscan easily employ to build applications without anylimits.

Future Work

Now that we have an architecturally robust at-tempt at a home automation system, our next stepwould be to create a rugged enclosure for our mod-ules so that they will be physically robust and easieron the eyes. Since our boards also support BluetoothLow Energy, we would like to look into an identitydetection feature by scanning the Bluetooth IDs ofpassing phones. This will add another element to oursystem that goes beyond what sensors can capture.It will allow us to provide users with the ability tomonitor people in their home, such as who has en-tered a room at what time. We also want to improveour local backend server so that it attempts to re-connect to the internet in a smarter fashion. Insteadof using a timed interrupt, attempting to reconnectwhen first detecting the WiFi has disconnected, thenincreasing the time between each attempt with expo-nential backoff, would increase the time that the localserver is connected to the internet while also reducingthe number of wasteful attempts.

4