1. MyHome: Smart Home Control System
Akchay Srivastava, Christopher Liffner, Icaro Alzuru
University of Florida
{a.srivastava, cliffner, ialzuru}@ufl.edu
1. Introduction and Motivation
Smart Phones, Smart TVs, Smart Watches, and
other Smart gadgets seem to be creating a vogue
to add friendly internet and computational
capabilities to any device. Houses or homes (as
a whole unit) seem to have fallen behind of this
smart fever and there are different points of view
about what is considered a Smart Home.
Some authors [1] consider a Smart Home like a
self-maintained entity which tells you
automatically when to pay the bills or what food
to buy. Other authors [2], consider that it should
be a high tech, ecological and always-convenient
entertainment center, and that it should be able
to respond to environmental changes. We believe
in part of these interpretations but we think they
are separated applications and not a holistic point
of view of what a Smart Home should be.
Nowadays we see that there are smart
appliances in our homes, like smart refrigerators
or smart TVs, but the house is not conceived like
the entity that is going to be “Smartified”: The
Smart Home is today a group of expensive
gadgets that do not collaborate or work together
in behalf of specific and global goals.
We present a system: MyHome, a small and
simple Cloud based Android application, which
establish the starting point of what it can be a real
and complete Smart Home System. MyHome
permits to supervise and manage the state of
some simple elements of the house, but what is
most important, it permits to define smart actions
to events and allows the user to interact and react
in a more intelligent way to what is happening in
the house. The system comes with some
predefined common actions to certain events, but
allows users to set their own actions, like alarms
or changes in the status of other devices. This
freedom in the action's settings permits the user
utilize the system with multiple objectives in mind:
saving energy, helping somebody with
disabilities, saving time, easy your life,
remembering things, improving the security of the
home, controlling some appliances remotely, and
in general MyHome expands the possibilities of
what people can do with their homes.
The approach consists in creating a network of
sensors and actuators for some devices in a
home, all these devices are connected to a
central unit, implemented through a Raspberry Pi
(RPi) computer with a XBee Radio Frequency
module. The central unit uses the sensors to get
the changes in the state of the devices, this
activity is registered in a database in the Cloud,
implemented with Google App Engine. An
Android application shows the user the state of
the devices and allows him/her defining and
executing actions over them, these actions are
passed to the central unit through the cloud
database.
2. Related Work
In [5], the authors classified smart home network
technologies into two types: 1) Wiring systems,
and 2) Wireless systems. Nowadays, it could be
considered bothersome or inappropriate asking
the client to cable all his/her home in order to
control some devices. In MyHome we use XBee
wireless modules because of their range and
resilience to interferences. [13]
In [6], the authors have proposed a project known
as smart home energy management system
using IEEE802.15.4 and ZigBee developed smart
home control system. The project is based on two
main considerations 1) energy savings and 2)
user happiness. It minimizes the domestic energy
waste and can be adapted according to the user
habits. Wires from the lighting control were
removed which lead to significant savings in
installation. In our project too, we have not used
any wires for interconnection. We have used Wifi
card or Xbee for the same. In this project, when a
person entered a room in the daytime, the system
opened the drapes instead of turning ON the
lights, but in the night the lights were turned ON

2. when a person came in and they were turned off
when there was no one in the room. Thus energy
was saved. In our app, we have tried to integrate
the different components of the Smart Home but
we have not used the energy-saving aspect
extensively, instead kept the system simple and
financially reasonable. For example, in our
project if a person enters the room, then the light
will be switched ON and when a person leaves
the room, then the light will be switched OFF.
Thus we are also applying energy-saving but on
a smaller scale.
In [7], the authors have proposed a system known
as Framework for Cloud-based smart home. The
cloud provide web services. There were six main
applications which were environmental, security,
entertainment, domestic appliances, information
and communication and health. This project is
really good for future demands as all of today’s
data is gradually moving to the Cloud. The
system can quickly adapt to changing load
requirements. Our project is much simpler than
this project and serves useful for those people
who do not want/can’t afford all the extravagant
services, but instead just want to control the lights
or camera or movements. Our project also makes
use of Cloud-based services.
In [8] the authors have proposed a project known
as Computer-aided design software for smart
home device based on cloud computing service.
The project offered visual simulation by applying
the interface to construct a real smart home. In
our project, we are not using any visual simulation
because providing such a facility requires use of
newer, complex and expensive technology.
The major difference between other projects and
our project is based on the idea of “Integration
among different components of the Smart Home”.
In many projects based on Smart Home, the
Smart Home consists of really expensive smart
devices and smart appliances which are saving
energy or doing actions which are smart. But
these devices tend to work independently and
separately without cooperation. In this project, we
have tried to amalgamate and integrate all of the
components together. For example, if a person
enters the room (known by movement sensors)
then the lights will be switched ON (lights control)
and the camera of the room will be switched ON
too (camera control). What we are trying to do is
to let the devices talk among themselves and
cooperate with each other in activities. We have
tried to keep the cost of the system to be
extremely reasonable (so that everyone can buy
it) and at the same time tried to provide the most
important functions of controlling and monitoring
lights (for people having disability), cameras (for
security) and movements (for energy-saving).
Moving ahead, let us now talk about the different
Android Apps which have been launched in the
marketplace. The first one is Control4 MyHome
mobile app. Our app is very similar to this app,
except that Control4 Myhome app is more
extensive in the sense that the user can control
temperature, television, microwave and other
home appliances. Any interested user has to buy
the entire kit even if he just wants to control the
lighting of the home. This is a disadvantage in
terms of cost. The Control4 MyHome app makes
use of wireless Control4 switches, wireless
Control4 dimmers, Control4 fan speed controller
and all equipment’s of Control4. On the other
hand, our application is generic in the sense that
we make use of a standard bulb and a standard
manual switch. The only extra thing required is
some hardware like Xbee and Relay for wireless
communication. Keeping in mind the time
limitation, simplicity, and cost our app just
focuses on controlling the lights, cameras and
movements of the home.
Next comes, another app known as Belkin Wemo
app for Android Home Automation. All of the
equipment’s used by this app is of Wemo. It uses
Wemo light switch, Wemo switch and Wemo
Motion. This app focuses mainly on controlling
the lights of the home and some other electronic
appliances like fans and heaters. The app is
similar to our app, in terms of simplicity and
expected cost.
3. System Architecture
We provide a large-scale view of the system
design in Figure 1. To best demonstrate the flow
and function of the system, two examples will be
presented. The first example will show the
system flow of a user initiated command. The
second example will demonstrate the flow of an
automated feature of MyHome.
Let’s suppose the user is out of the house and
wishes to turn on an outside light as night
approaches. She accesses the MyHome app on
her smartphone and selects the appropriate
option. The smartphone sends the state change
command to the MyHome Cloud, where both user
settings and sensor information are stored.

3. Figure 1 – System flow.
The user’s light activation command is
transmitted to her modem at the house. The
Raspberry Pi is wirelessly connected to the
modem and receives the command. From this
point, the Raspberry Pi communicates with the
Coordinator XBee, to which it is directly
connected. The Coordinator XBee sends the
command to the appropriate Remote XBee. In
this case, the Remote XBee is wired to the outlet
which provides power to the outside light the user
wishes to turn on. The Remote XBee sends the
appropriate signal and activates the light.
The automated features of MyHome involve the
storing of sensor data in the cloud. Any
peripheral sensors integrated into the MyHome
system would essentially flow counter to the first
example. The sensor would be connected to a
Remote XBee and the information would be
stored to the cloud via the previously mentioned
path. However, the camera, being that it is
connected directly to the Raspberry Pi, is unique
and merits a brief example. By default, the
camera is set to record upon motion detection.
Let’s suppose the user is expecting a package,
but is away from the house. When the mail
person arrives to drop the package off, the motion
sensor will detect movement. This sensor is
connected directly to the Raspberry Pi. The
Raspberry Pi will send the command to start
recording to the camera. The data recorded by
the camera will be sent back to the Raspberry Pi.
This data will be uploaded to the cloud via the
modem. At this point the user will be able to view
the video and confirm delivery of the package.
3.1 Hardware
This section presents the hardware of the
MyHome system. While a modem and
smartphone are essential to the function of the
entire system, they are not designed or provided
by MyHome and are not considered MyHome
hardware. Similarly, a cloud server is required to
store data, but the hardware of the server will not
be discussed. The Central Unit is comprised of
the Raspberry Pi (RPi), camera, motion sensor,
and Coordinator XBee. There are primarily two
types of end devices – the outlet and the sensor.
Both types include a Remote XBee.
3.1.a. Raspberry Pi
From a hardware perspective, the Raspberry Pi
is the brains of the system. Commands are sent
from the Raspberry Pi and sensor data is
transmitted to it. It provides a GPU to better
handle the high-definition video from the camera.

4. It also has WiFi capability (with the addition of a
WiFi dongle) allowing for a more flexible system.
The Raspberry Pi model B was selected over the
model A for its additional memory (512 MB vs 256
MB), which may be helpful in handling the video
data.
3.1.b. Camera and Motion Sensor
A camera and motion sensor are connected
directly to the Raspberry Pi. The primary
objective of the motion sensor is to activate the
camera. However, it could potentially be used for
other functions, such as turning on a light.
Because the camera is wired to the Raspberry Pi,
a fast and reliable transfer of data is achieved
without any additional WiFi requirement.
3.1.c. XBee RF Modules
We use 1 mW series 1 XBee RF Modules in our
system. These units have a range of 100m and
use a 2.4GHz frequency. MyHome does not
require complicated mesh networks and
therefore does not require the series 2 models.
The Coordinator XBee is connected directly to the
Raspberry Pi via the GPIO pins. This XBee is
responsible for taking the commands of the
Raspberry Pi and transmitting them to the
appropriate Remote XBees. Additionally, the
Coordinator XBee also receives sensor data from
the Remote XBees and sends this to the
Raspberry Pi.
In the outlet style end device, the unit consists of
a Remote XBee, 120V AC to 3.3V DC
transformer, as well as a 120V wall outlet and a
relay. The relay allows the Remote XBee to
activate or deactivate the outlet. The XBee is
powered by the AC to DC converter. The sensor
style end device contains a Remote XBee, AC to
DC converter and a sensor. The nature of the
sensor is up to the user, but one such application
is the detection of an open door or window.
The roles of the cloud and Android application
have been described in the beginning of the
section. The details of these components will be
discussed in the subsequent section.
4. System Design and Implementation
During the technologies exploration or evaluation
process, after considering the System
Architecture, we realized that the system involves
the integration of three different pieces of
software: The service that is going to run in the
Central Unit, the Database in the Cloud, and the
Android (client) application. The decision we
made was trying to work with technologies where
the possibility of integration was demonstrated
and a reduced amount of different tools to
accelerate the learning and adoption process.
Because of these considerations, we decided to
implement the service in the Central Unit as a
Java Service running on Debian Linux, to
configure the the Database in the Cloud through
the Google App Engine service, and to use
Android as the smartphone operating system.
4.1 Hardware sensors and actuators
Thinking of clients and of the cost of the whole
MyHome solution, it seems to be clear that users
should spend the less amount of money possible
and the sensors and system should be easy to
configure. For this reason it was decided not
requiring the user to change their home devices
by new ones, but inserting sensors that could act
and sense the existent devices. Following the
same principle, it was preferred connecting the
sensors and the Central Unit through a wireless
network and not through a wired one, and
basically because of the required amount of job
for cabling a house only to put some sensors in it.
Because of their power to communicate through
objects like walls, the chosen device to create the
wireless network was the XBee [3]. Through the
XBee, the commands from the Central Unit (CU)
will be sent to the actuators and from the
actuators to the CU. In the case of lights, the
actuator is a Beefcake Relay Control Kit, which
controls when to turn on/off the light. The
combination of voltages provided by the XBee to
the relay kit will indicate to it the action to take.
For the detection of the state (open or close) of
the doors and windows, an Infrared Proximity
Sensor is used whose variations in voltages will
indicate the state of doors and windows to the
CU.
4.2 Central Unit (CU)
The Central Unit is the computer with the
responsibility of:
a) Getting the data from all the sensors, and in
case if there is a change in the state of the

5. house appliances, updating the database in
the cloud.
b) Reading the updates made by the Android
application in the database, and applying
those commands: changes of state or
actions, to the actuators and devices.
The chosen computer was a Raspberry Pi
because of its price ($ 39.95) and the possibility
of running Linux and the Java Virtual Machine.
The CU runs a Java Service, configured to read
and update every 10 seconds, in a round robin
fashion, the state of each home device.
4.3 "Database" in the Google's Cloud
Datastore
In Google App Engine does not exist the
possibility of creating a common relational
database. The system is designed to work with
big data and the Relational Model does not
perform well at that scale [4]. Following the model
proposed by Google, we create 6 types of
Entities, the equivalent concept to a Table in the
Relational Model. The Types of Entities (and
Fields) were the following:
• ACTION (HomeID, ID, ActionType, SensorID,
SensorType, State)
• CAMERA (HomeID, ID, Location, State,
UpdateTime)
• LIGHT (HomeID, ID, Location, State,
UpdateTime)
• MOVEMENT (HomeID, ID, Location, State,
UpdateTime)
• OPENCLOSE (HomeID, ID, Location, State,
UpdateTime)
• USER (HomeID, ID, FirstName, LastName,
Address, Cellphone, Email, Login, Password)
The fields HomeID and ID are used to identify
uniquely the sensor in the supervised houses.
ACTION is used to store the smart behavior of the
system, reacting in programmed ways to the
changes of the state of the home. Because this is
a prototype, we included only these types of
actuators and sensors, but it can include many
other types.
4.4 Android Application
In our project we have created an Android App
which has the capability of connecting with
Google App Engine. The app provides basic
functionalities like logging in, performing actions
(ON/OFF) on lights and camera and detecting
movements. Initially the schema of the database
was made in the Google App Engine, which has
been described above.
The tables or entities were populated with proper
data by running the Java code on the client
phone. As far as the Android App interface is
concerned, we have created a handful number of
screens. When the app is opened by the user, the
Login Screen opens up. This screen accepts the
login information of the user such as user name
and user password. If the user provides correct
information, the user is logged in and is taken to
the next screen. This next screen contains the
option to Supervise Lights and Supervise
Cameras.
When the Supervise Lights button is clicked, the
control goes to the Lights Screen. In this screen,
there are options for performing actions on
different kinds of lights for example the Bedroom
light or the Kitchen light. Any particular light can
be made ON or OFF by pressing the suitable
radio buttons. When the ON/OFF radio button is
touched/clicked in the Android App, the state of
that particular light is changed in the database
existing in the cloud. To get this change reflected
in Google App Engine, a time of about less than
1 second was required. The Raspberry Pi is
periodically reading the data from the cloud and
as soon as it detects a change in the state of the
light, it passes a suitable signal to the XBee. After
some relaying action, the light is turned ON or
OFF. Similarly when the Supervise Cameras
button is clicked, the control goes to the Cameras
Screen and rest of the functionality remains the
same.
As soon as a movement is detected in the home
through movement sensors, the light of that
particular room can be made to switch ON/OFF
depending upon the corresponding action. If the
user wants to record the live happenings upon
movement detection, then he can switch ON the
camera of the room. This action relates to our
novel concept of “Integrating different
components of the Smart Home”.
As far as the Interface is concerned, the interface
is a simple one with required functionality. Other
cosmetic features and convenient settings can be
further incorporated to make the App elegant in
the market. The screenshots of the Android App
are shown below:

6. Figure 2 – Login screen. Figure 3 – Devices screen.
5. Performance Evaluation
A very accurate performance evaluation was not
performed, considering the activities that can be
initiated from the cell phone are not affected by a
couple of seconds of delay. Obviously, depending
on the use a potential client gives to the system,
in the future, response time could be a concern
for a specific application.
Approximate response times for the differents
steps of the flows of information are:
a) From the sensor to the Android app:
- Sensor response: 1 s.
- Data transfer from the Sensor (via XBee) to
the RPi (via XBee): 1 s.
- Data transfer from the RPi to the Cloud: 3 s.
- Refresh rate of the data in the Android app: 10
s.
- Data transfer of the data from the Cloud to the
Android app, and visualization of it: 1 s.
These times were timed manually and are good
only as a rough estimation. Considering these
times, the total response time for the
communication from the sensor to the Android
app can be estimated in 16 seconds
approximately.
b) From the Android app to the actuator.
- Data transfer from the Android app to the
Cloud: 1 s.
- Refresh rate of the RPi: 10 s.
- Data transfer from the Cloud to the RPi: 3 s.
- Data transfer from the RPi (via XBee) to the
actuator (via XBee): 1 s.
- Actuator and device activation: 1 s.
In the same way, these times were timed
manually and are good only as a rough
estimation. Considering these times, the total
response time for the communication from the
Android app to the actuators or devices can be
estimated in 16 seconds approximately.
It is obvious that the system is sensitive to a fail
in the Internet connection and there is some
uncertainty in the response time when the media
is the Internet. Moreover, there is a tradeoff or
conflict between the response time and the
overload produced by a sort refresh rate, which in
the case of the Android app, could affect the
energy consumption of the cell phone.
In general, we consider a response time of 16
seconds is acceptable, considering the nature of
the application.
5.1 Experimental Setting
After merging the different components of the
project, we began the experimentation. The
setting mirrored a household environment.
Internet access was required for the Central Unit

7. (it can be wired or wireless) and for the cell
phone.
The elements used were:
- Outlet Device: As described in section 3.1.c.
- Central Unit: The Raspberry Pi (RPi) computer
is running the RaspBian operating system.
Python scripts (version 2.7) were developed to
get the values from the sensors and to send
commands to the actuators. These scripts are run
periodically by a service which reads the data
from the cloud too. In order to use the RPi, was
required a USB keyboard, a USB mouse, and a
USB Wireless Adapter, because RPi has only 2
USB ports, it was necessary a USB Hub to
connect all the devices.
- Cloud System: It was set up a Google App
Engine project. It was defined the 6 entity types
defined in point 4.3 and it was load the Java
Backend with the Endpoint definition (classes) for
these six entities.
- Android App: A simple Android application was
developed to validate the credential of the user
and reading and modifying the entities of the
cloud database. The Android App was tested in a
Samsung Galaxy S3.
5.2 Performance Metrics
There are 3 main performance metrics: cost,
speed, and reliability. MyHome should be priced
at or below similar systems which incorporate
video access over the internet. The system must
respond with reasonable speed. No specific
value is provided, as the response rate is only
important for the convenience of the customer,
not for the function of the system. Reliability is
the final and most important measure. The
system may take time to respond, but eventually
the command must be received.
5.2.a Cost Comparison
One important criterion of the project was cost.
The total cost of the central unit is itemized below:
Raspberry Pi model B – $49.95
Raspberry Pi Camera Module – $29.95
Xbee 1mW series 1 – $22.95
Motion Sensor – $9.95
Raspberry Pi Case – $5.95
Total: $118.75
The central unit can be used by itself.
Again the central unit is comprised of a motion
detector, video camera, and Raspberry Pi. These
components are sufficient to act as a video
surveillance unit. Similar devices that can capture
1280 resolution high definition video are sold for
around $180 dollars[14].If our unit was sold at the
same price a $60 profit margin would remain.
However this value is highly conservative as we
have price the components based on single unit
purchases. Obviously, in higher volume the cost
would be greatly reduced leaving an even greater
gap in price.
The full benefit of the MyHome system is not
realized without its complementary end devices.
These are what make MyHome unique and not
directly comparable to other products. The sensor
end devices are difficult to place a price on as this
will vary with the particular sensor used. However
the outlet devices are uniform in design. The
pricing of the outlet devices is itemized below:
Xbee 1mW series 1 – $22.95
2 x Solid State Relay – $9.90
AC to DC converter – $5.95
Total: $38.80
The cost of the outlet devices can be further offset
if the user is able to make better use of the
Remote XBee within. The XBees have 8 I/O lines
which can be utilized, but the outlet only requires
2. If the user is able to use these lines for his
sensors or to wire additional outlets to the same
XBee, additional value can be obtained. The AC
to DC converter is only required for the Remote
XBee therefore optimizing the Remote XBee is
optimizing the AC to DC converter, as well. A
single relay is only able to control one outlet, but
this is the least expensive component.
The aspects of MyHome which can be compared
to other products have been shown to be priced
at a comparable rate. Because MyHome adds
even more functionality we have evaluated the
cost comparison as a success. We have
designed an affordable system, providing the
customer with the ability to scale as simply or as
intricately as he desires.
5.3 Experimental Results
Due to the nature of the project and how it was
implemented, failures are extremely rare. In the
majority of cases success is achieved on the first
try. If for some reason it is not, the user would
never know as the system would continue the
attempt until it was achieved. For example, the 1

8. mW XBees we are using have a range of 100m.
Obviously, this is not an immediate drop of the
signal. As the distance approaches and goes
beyond 100m, more packets are lost. However,
our system only sends 1 bit of data to the XBees
-- 1 or 0. Moreover, this state is held. So, if the
signal does not get through the first time, it is
mere milliseconds until another attempt is made.
Because our system is not time sensitive this has
no effect on the overall success.
Even the motion detector proved 100%
successful in our trials. At a distance of 10’ from
the motion detector, a brief hand-waving gesture
was performed 50 times. The motion was
detected every time. After the motion ceased, the
sensor would indicate no motion, but quickly
indicate a false positive. This happened on nearly
every occasion and was determined to be a
resetting period. The need for the reset was
compensated for in the coding by using a delay
after motion was detected.
These type of approaches were implemented
throughout the project. Because of this failures
were virtually eliminated. The occasional failure
has occurred due to a broken wire.
6. Current Progress and Project
Management
6.1 Current Status
Sensors and actuators tested during the project:
(100%)
- Motion sensor: It can be detected when there is
movement in a specific area.
- Camera: The camera can be turned on and off.
- Light Relay: The relay, hence the light can be
turned on and off.
Why 100%: We wanted to test more kinds of
sensors. But we think with these we can
demonstrate the viability of the idea.
Central Unit: (85%) The Central Unit and the
devices are communicating using XBees in a
reliable way. The Central Unit was implemented
through a Raspberry Pi card which runs a service
and is in charge of reading the state of the
sensors and reading the action from the cloud.
Why 85%: The service can be improved. After the
testing process and implementation, we realized
it is a better idea to store a copy of the actions for
the events in the Central Unit, this was not
implemented. For example, if it is detected some
movement in a room, it should not be read from
the cloud what to do, this could take about 6
seconds, what it could be too much to capture a
good image of what is happening. It could be
tested also other devices similar to the Raspberry
Pi and alternative communication options to the
XBees, in order to reduce the price of the system.
Cloud Database and Backend: (90%) The cloud
system is working using Google app engine. The
“database” or entities were created with the Data
Store application and allows to store the last
values of the variables. The backend was written
in Java and gives response to the requests.
Why 90%: The model of the events and the
actions need some improvement. It is
recommended to use a more complex logic
model for taking decisions.
Android App: (85%) Validates the credentials of
the user, allows to execute actions over the
devices and to read the status of them from the
cloud.
Why 85%: The events and actions model can be
improved. The interface does not adapt
automatically to new devices added to the home.
6.2 Team Coordination
In this project the responsibilities were divided as
follows:
Akchay Srivastava: Android Application, Cloud
Backend.
Chris Liffner: Hardware installation and related
code.
Icaro Alzuru: Cloud Backend, Cloud Database,
Central Unit service.
Because of this division of the responsibilities, it
was possible working independently. Only two
activities: Cloud Backend and Central Unit
Service needed some moment of integration. For
this reason, the GitHub projects, mentioned in the
next section, were not created till the final
integration phase of the project.

9. 6.3 Milestones, Weekly Plans, and Deliverables
02/03 - 02/07 Hit Design and create a database in Google App Engine
Learn how to create a service in Linux
02/10 - 02/14 Hit Hello World Android app that connects to Parse
Design the interfaces in Android
Assemble a Wireless Light
02/17 - 02/21 Hit Develop a program that connects the Raspberry Pi with the XBee
Develop a program that connects to Google App Engine
02/24 - 02/28 85% Development of the engine to define a Home and its sensors
Complete the programs that connect the Raspberry Pi to the devices and App Engine.
03/03 - 03/07 Hit Integrate Android app, Google App Engine, Services, and Devices
Development of a first version of the supervision module in Android
03/10 - 03/14 Hit Test the product and fix bugs
Prepare the Project Midterm Presentation
03/17 - 03/21 Hit Add alarms and actions to the setup module
Assemble another kind of sensor
03/24 - 03/28 Hit Complete the development of the Central Unit module
03/31 - 04/04 Hit Integration of the whole product. Testing alarms and actions.
04/07 - 04/11 Hit Interface improvement, Fixing bugs, Completing development
04/14 - 04/18
04/18 - 04/20 95%
Testing the product and fixing bugs.
Presentation, final report, and final coding.
Updated Midterm Weekly Plan/Milestones:
The following milestones were set and
accomplished during the project:
Hit- 17th - 23rd March: Android App: Finalizing of
Interface (incorporating some new
states/activities found out later in the stage).
Enhancing the Interface with new features like
flash, animation or external effects. Hardware:
Access RPi GPIO pins and interface Coordinator
XBee.
Hit- 24th - 30th March: Android App: Connecting
the Android Application with the Google App
Engine. The Android App should be able to read
the data from the Google App Engine. Proper
exchange of data between App and App Engine
should take place. Hardware: Develop camera
activation (due to motion detection) software.
Hit- 31st March - 6th April: Connecting the
Hardware components with the Cloud System.
95%- 7th April-13th April: Bringing the entire
system work together i.e. Amalgamation of
Hardware components, Cloud System and
Android Application. Fix connectivity bugs if any.
90%- 14th
April-29th
April: Catch up on any
overdue deadlines. System testing and reporting.
Deliverables:
In order to share the code, were created the
following GitHub projects:
- https://github.com/ialzuru/MyHome: Android
App with the interface and the logic of the
program.
- https://github.com/ialzuru/MyHome-AppEngine:
Cloud Backend.
- https://github.com/ialzuru/MyHome-CentralUnit:
Hardware code and Central Unit service.

10. REFERENCES
[1] W. Plasencia. Home smart home. Hispanic
pp. 66. 2004. Available:
http://search.proquest.com/docview/237028600?
accountid=10920.
[2] Wu, Z.L.; Saito, N., "The Smart Home
[Scanning the Issue]," Proceedings of the IEEE,
vol.101, no.11, pp.2319, 2321, Nov. 2013
[3] Ayars, E.; Lai, E., "Using XBee transducers
for wireless data collection," American Journal of
Physics, vol.78, pp.778, 781, 2010
[4] Chang, F.; Dean, J.; Ghemawat, S.; Hsieh,
W.; Wallach, D.; Burrows, M.; Chandra, T.;
Fikes, A.; Gruber, R., "Bigtable: A Distributed
Storage System for Structured Data," ACM
Trans. Comput. Syst. 26, 2, Article 4, June 2008
[5] Manfred Huber, 2006, “Smart Home
Technologies” [Online], Available
http://ranger.uta.edu/~huber/cse4392_SmartHo
me [2012, October 18].
[6] Inji Ibrahim Attia and Hamdy Ashour, “Energy
saving through smart home” The online journal
on power and energy engineering [Electronic],
Vol.2, No.3, pp. 223-227.
[7] Xiaojing Ye and Junwei Huang, 2011, “A
Framework for Cloud-based Smart Home”,
International Conference on Computer Science
and Network Technology, December 24-26,
Chongqing, China, pp. 894-897.
[8] Molly Edmonds, “How Smart Homes Work”
[Online], Available:
http://home.howstuffworks.com/smart-
home4.htm [2012, October 19].
[9] Jackie Craven, “What Is a Smart House?”
[Online], Available:
http://architecture.about.com/od/buildyourhous1/
g/smarthouse.htm [2012, October 18].
[10] iT24Hrs, 2012, “Smart room, smart home”
[Online], Available:
http://www.it24hrs.com/2012/smart-room-smart-
roomautomation [2012, October 18].
[11] Paul Lin, “Disadvantages of a Smart Home”
[Online], Available:
http://www.ehow.co.uk/list_7631272_disadvanta
ges-smarthome.html [2012, October 19].
[12] Barthold, Jim, 2005, “Changing the Way
Houses Operate” [Online], Available:
http://articles.castelarhost.com/smart_home_tec
hnology.htm [2012, October 18].
[13] Digi International Inc., “XBee - Connect
Devices to the Cloud” [Online], Available:
http://www.digi.com/xbee/ [2014, April 20].
[14] Best Buy, Home Security Camera
Search [Online], Available:
http://www.bestbuy.com/site/home-security-
safety/home-surveillance-
cameras/pcmcat254000050005.c?id=pcmcat254
000050005 [2014, May 18].