desc.tex

\subsection{Motivation}
The goal of this project is to improve the quality of life for people in their
homes. Imagine sitting on the couch at home about to watch a movie, but all the
lights are on and it{}'s a little warm inside. It is irksome to have to get up
and turn off every individual light. With the technology existing today it is
perfectly feasible to be able to turn off the lights and turn on a fan with a
mobile phone. With the software available today it is even possible for this
process to be initiated by voice. The problem that exists is these solutions
lack mass implementation. By creating a wireless home control base station that
a mobile phone could connect to these visions can be realized. The need to get
up and physically interact with an appliance can be made a thing of the past.

We want to develop an easy to use system that allows people at their home to
interact with their appliances without having to be in front of them. Our aim
is for the solution to be reliable and low cost. The use case scenarios should
be intuitive so that even someone who was just visiting could utilize the
system. A person using WHCS should be able to turn on their lights or an outlet
with the press of a button or with a voice command from their mobile phone.
They should also be able to turn on their coffee pot from their phone when they
first wake up. If someone knocks on the door the person should be able to
unlock the door without having to get up. With the activation capabilities of
WHCS there is an opportunity to utilize a foundation that can be expanded upon.
We will have the infrastructure for integrating different types of sensors into
the home to provide users with information about things like temperature or air
quality.

\subsection{Overview}
The diagram pictured in \autoref{fig:whcs-overview} shows the highest level
overview of WHCS.  When the user wants to begin interacting with WHCS he has
the option of choosing to use a mobile phone or the included LCD screen. Both
option will provide full capabilities for interacting with the system. The
phone will be attached to the system through a BlueTooth connection that is
created by the user in the WHCS application. Using the phone will be a more
mobile and easy method for access because the LCD will be connected to the
central component of WHCS, the base station. The base station will be the
brains of WHCS. It will be the base station{}'s job to take commands from the
user and relay them to the endpoints, while also displaying the state of the
system. The base station will have a list of endpoints, also called control
modules, that can be targeted by the system. This list will be dynamic and
allow for endpoints to be added or removed from the system during operation.
Together the base station and the control modules will form a network through a
home and will communicate wirelessly to one another through radio transceivers.

The control modules designed for WHCS will allow for all the activation of
appliances around the house. These endpoints will be listening for commands
from the base station via a radio transceiver. Each control module will be
tailored for interacting with a certain device. There will be control modules
for toggling outlets, toggling lights, unlocking the front door, and also for
monitoring sensors. The control modules will be as similar as possible with a
designated area that allows for assigning specific roles to the control
modules.

\ucfgfx[scale=0.65]{fig:whcs-overview}{a21expected2pages-img001.png}{WHCS System Overview}

\subsection{Objectives}
In order to enable homeowners to have the best experience with their new WHCS,
we will explain our core project objectives. These describe what the end-users
are be able to do with the system at a high level.

\subsubsection{Voice Control}
Voice control from a supported, BlueTooth enabled, Android device will allow
the user to remotely activate any part of the home that is integrated with
WHCS. This would include activating lights, unlocking doors, turning off and on
appliances (by controlling their respective outlets), querying sensors, and any
other home specific applications.\footnotemark All of these \emph{actions} and
\emph{targets} will be able to be used just from the user's voice. Voice
actions will be specific to each target, but they will consist of verbs such as
\textbf{turn}, \textbf{query}, \textbf{check}, \textbf{open}, \textbf{close},
and so on. The list of targets will directly correspond to the number of
control modules listed in the home and their type.  This will be explained in
more detail in \autoref{sec:sys-design}.

\footnotetext{WHCS is an extensible system. Control modules are built with a
plugin-like interface, allowing for intrepid home owners to have a fully custom
home. This combined with the control module's free breadboard area, new
applications may be created.}

\subsubsection{Light Activation}
Through activating lights and querying their status remotely, a homeowner will
no longer have to be present in the same room as the switch.  By connecting
lights to WHCS, they will become integrated in to the home network and not be
isolated in each room of the home.  With just a spoken command or a tap on
their smartphone, lights will be controlled.  By automating the process of
toggling light switches, WHCS will have the ability to be smart about when they
are ON or OFF, freeing the user from having to think about their state at all.
In addition, lights, just like all of the other connected control modules in
the home, will be able to be actuated on a specific schedule. This schedule
can be designed by the homeowner
to meet their daily lives or in a special circumstance, such as travel.

\subsubsection{Outlet Activation}
Lights aren't the only actionable thing in the home. There are a multitude of
appliances throughout the home which could benefit from remote control. Some
of these include coffee makers, toasters, or computers.
If integrated with WHCS through outlet control, these appliances
would be able to be a part of the home network. Imagine being able to start the
morning coffee from the comfort of the bedroom. This would be possible with an
appropriate coffee maker and WHCS outlet control. An added benefit from having
outlets being automated is that there would be less draw from power leeching
devices' power subsystems, which may be always-on.

\subsubsection{Door Access}
In addition to controlling home lights and various appliances, giving users
remote control of their doors is  a goal of WHCS. Through the use of an
\emph{electronic door strike}, we would provide a specific control module the
capability of locking and unlocking a door. This functionality would be
demonstrated in Demo \ref{sec:demo-door}. WHCS sees door access as important
for a home automation system to support because remote access, like a garage
door, is simple and easy. We want to make opening \emph{any} door simple and
easy.

Unlike controlling appliances and reading sensors, correctly managing the
operation of a safety-critical door must be handled with great care. Any flaw
in the implementation of the WHCS network would leave a user's home vulnerable
to outside attack. This is why any control module whose purpose is to control
doors will support additional security features. These additional features will
include mechanisms to prevent replay attacks (which garage doors are vulnerable
to) and also prevent outside attackers from engaging the door opening mechanism
just by sniffing traffic. For additional details on the security considerations
of WHCS, please refer to \autoref{sec:safety-sec}.

\subsubsection{Data Collection}
In order to give users a broad overview of their home's state, WHCS supports
the collection of data from \emph{arbitrary} sensors. Data collected can
include temperature, humidity, light level, sound levels, and so on. Each home
may have sensors throughout collecting various data that the homeowner deems
useful. The sensor integration with WHCS would be transparent to the user. All
they would see would be the list of sensors and the corresponding values.
WHCS's pluggable control module's would be tailored to each sensor or set of
sensors, which would relay their data back to the base station. This is
illustrated in \autoref{fig:many-to-one}. The base station would support
queries from the LCD interface and simultaneously from a connected phone.

\ucfgfx[scale=0.5]{fig:many-to-one}{many-to-one}{A illustration showing the translation of many different sensor nodes to WHCS' protocol}

Beyond home sensors, all of the other controllable objects in the WHCS
would have metadata being collected about them at all times. This extra metadata
would include \textbf{connection status} and \textbf{power status}. See
\autoref{sec:network-library} for a more detailed description of the supported
network packets and the type of fields they support.

All of this raw data being collected could be displayed to the user in the form
of graphs and tables. It would also serve as the basis for a set of descriptive
statistics for display to the user.

\subsection{Requirements and Specifications}
For WHCS to become the product that we want it to be it must adhere to a strict
set of requirements and specifications.  We have identified certain
requirements for subsystems involved in our system that we must fulfill in the
development process. The following section is devoted to identifying
requirements that we must meet to completely reach our goals for WHCS.

\subsubsection{Mobile Application}

The mobile application must communicate to other components of WHCS through
BlueTooth. The process of connecting to the base station within the application
must take no more than eight seconds from when the application is opened.
Toggling the state of a control module within the system such as a light or
outlet must also take no more than eight seconds from anywhere within the
application. The user must be able to create sets of control modules to
interact with simultaneously. The Android mobile application must follow
Google{}'s material design guidelines for Android development. The application
must not request any privileges other than Bluetooth services. The application
must support full duplex communication with the base station. The application
should be able to react to disconnections to the base station by polling the
connection every thirty seconds and dropping the BlueTooth connection if no
response is received.

\subsubsection{Radio Module}

The radio module must communicate in ISM allocated radio bands in order not to
interfere with bands requiring radio licenses. The radio module used to
communicate between subsystems must be able to communicate at ranges up to at
least 50 meters. The radio chip must be able to act as a transmitter and a
receiver and must be able to switch roles quickly.  The radio module must be
interoperable with common microcontrollers, so it should have a feasible method
for interfacing with a microcontroller{}'s pins. The radio chip must be capable
of addressing, and further must be able to listen for messages from multiple
addresses when in receiving mode.

\subsubsection{Microcontroller}

The microcontroller for the base station must have enough GPIO pins for an LCD,
radio transceiver, and a BlueTooth module. The microcontroller must have an
on{}-chip UART and SPI solution. All microcontrollers in the system must have
on board flash memory to promote design simplicity. The microcontrollers must
operate in logic level voltages ranging from 3.3V{}-5V. The microcontrollers
must be capable of operating with a supply current of 50mA or less. The
microcontrollers must have an option for setting the frequency to at least 8
MHz to boost throughput of the system. SMD footprints should be available for
whichever microcontroller is chosen. The microcontrollers must be programmable
while in circuit. The base station and control module microcontrollers must
both have on{}-chip analog to digital conversion hardware. All microcontrollers
must support interrupts to properly implement the network that is planned for
WHCS.

\subsubsection{BlueTooth Module}

The BlueTooth must communicate with some form of RS232 to be interoperable with
a microcontroller{}'s UART. The BlueTooth chip must be able to exchange data
with a baud rate of 9600, with higher baud rate options being a plus. The
password and name of the BlueTooth module must be programmable for security
measures. The BlueTooth module should operate at logic level voltages of
3.3V{}-5V. The BlueTooth module should be capable of communicating at ranges up
to at least 50 meters.

\subsubsection{Printed Circuit Board}

The printed circuit board layout{}'s outer dimensions should have a width of
.008''. The size of vias on the PCB should be set to .02''. Isolation of ground
pour polygons on the PCB layout should be set to .012''. Logic level trace
sizes should be .01'', and any high level voltage traces should be set by
referencing a trace width calculator. The preferred of resistor package for the
PCB is 0805. SMD components should be used whenever possible in the PCB design.
The control module PCB should be no more than 4''x4''. The base station PCB
should be no more than 5''x6''. High level voltages from the power supply
should be isolated from the logic level voltages with an isolation area of at
least .75''. A two layer board design should be used for all of the PCBs in
WHCS.

\subsubsection{Power Specifications}

The power supply developed for WHCS must rectify and downstep 120V AC provided
by household mains. A transformer must be chosen that downsteps 120V AC to a
level that is suitable for a switching buck regulator to regulate with high
efficiency. A 5V and 3.3V line should be provided for each board in WHCS to
meet the needs of individual logic chips.  The 5V line must be obtained through
a regulator with at least 80\% efficiency. The step down to 3.3V from 5V does
not need to be highly efficient. A relay must be chosen for switching high
voltage to control high voltage components. The relay should have a load
voltage capable of tolerating 120V AC. The input voltage required for
activating the relay should be no more than 5V so it can be switched by a
microcontroller. The relays forward current for activation must be no more than
40mA so that it can be supplied by the GPIO pin of a common microcontroller. At
least 500mA should be suppliable to every board in WHCS. The electronic strike
that is used in WHCS must consume no more than 700 mA while activated. The
electronic strike must operate at 12V or less.

\subsubsection{LCD}

The LCD must have a touch screen interface to allow direct interaction with the
system. Any interaction that can be performed on the system that is available
from the mobile application must be performable from the LCD. The LCD must be
operable with a supply voltage of 3.3V{}-5V. The LCD must be interoperable with
a microcontroller with speeds of approximately 8 MHz. The LCD must be able to
interface with a microcontroller through SPI or parallel data in. The LCD must
be no more than 6''x6'' and must be mountable directly to a PCB through the use
of standoffs.

\subsection{Research of Related Products}
In order to have a successful product, the WHCS has done background research on
products tha thave similar goals to WHCS. There is a lot to be learned from the
``big players'' in the industry. Through a survey of the below companies, we
have a better idea of some of the features WHCS could offer and what the other
companies aren't. This allows us to make new innovations and avoid mistakes
that others have already made. Beyond that, we will know where WHCS falls in
the spectrum of home automation by gathering as much data about other companies
as possible.

\subsubsection{Z-Wave}
Z{}-Wave is a wireless technology that serves as a building foundation for home
automation technologies. It is a certain type of home technology networking
standard. The idea is that any component for the home that carries the Z{}-Wave
logo is interoperable with any other Z{}-Wave product. Certain vendors
implement Z{}-Wave into their technology to give their products a wide appeal.
Z{}-Wave is not a full home automation solution, it is merely the basis for
wireless home automation products. Vendors like Schlage create components for
the home that are compatible with Z{}-Wave networks.  For example Schlage
offers a door lock that can be controlled from a mobile phone due to its
implementation of Z{}-Wave technology.

In relation to our product Z{}-Wave is similar to our
implementation of a wireless network. Our Wireless Home Control System will
feature radio transceivers that use a proprietary protocol to exchange
information. Only components within our system will be able to communicate
within the network. The network will also allow user{}'s mobile phones to join
in. So WHCS implements a tiny version of Z{}-Wave within the whole product.
Z{}-Wave takes the networking to an extreme and offers it as a platform for
vendors to create home automation equipment. For WHCS the network is a means to
get our home automation equipment to communicate with each other instead of
providing a foundation for others to build into.

{\color{black}
Z{}-Wave has a great feature called {}``scenes.'' Scenes allow users to create groups of devices around the house and
specify certain states for those devices that can be activated at the touch of a button. WHCS will also implement a
feature similar to this. With the ability to control multiple devices around the home it will be a common use case for
the user to change the state of the system to certain common configurations. For example, a user might want to turn off
all the lights in the house with a {}``sleep mode{}'' every night. This will be achievable through the hardware that
WHCS will create for the house.}

\subsubsection{Belkin}
Belkin has a brand of home automation products called WeMo. The WeMo brand
consists of products that broadcast themselves via wifi and are controllable
through mobile phone applications. There are multiple offerings such as
heaters, outlet plug ins, light switches, and cameras. Overall their product
line is quite similar to what we are aiming for. They have things that assist
in home automation and are controllable by a mobile application. This is what
want to accomplish with WHCS. They are different from the previously mentioned
company Z{}-Wave because they actually provide smart appliances that go inside
your home rather than just providing the foundation for a home automation
system.

One notable difference between Belkin{}'s line of WeMo products
and our solution is how outlets are handled. WeMo offers outlet plugins that
are put directly into the outlet and then expose an outlet facade for a user to
insert into. Rather than completely turning off the outlet that is connected to
the household main like WHCS will be doing, WeMo shuts off the insert that has
been put into the outlet as a middleman. This type of design is great for ease
of installation but also clutters the outlet. When a WHCS outlet is installed
it will not be noticeable from the outside and it will be a permanent addition
to the household. Belkin also has a solution for toggling the state of lights
with their WeMo light switches. These light switches are different from the
outlets because they actually require the stock light switch in the home to be
replaced with the WeMo product. Our version of light control will leave the
stock light switch of the home intact.

\subsubsection{Apple HomeKit}

Apple HomeKit is an application programming interface that Apple develops for
programmers to interact with any appliance that implements the Apple HomeKit
Accessory Protocol. This is an approach to home automation that is not very
popular.  Apple seeks to make the mobile applications that access home
automation systems not proprietary. With Apple HomeKit any Apple developer is
capable of developing applications that interact with a multitude of
appliances. HomeKit does not seek to develop one home automation solution, it
wants to decouple the application development from the hardware. The company
that we mentioned before called Belkin creates a mobile application to go along
with the smart appliances that they sell. With Apple HomeKit the philosophy
shifts away from development like this where the application comes along with
the hardware.

With HomeKit multiple developers could develop independent applications all
targeting the same hardware and users could choose which application they like
best. Our WHCS solution for home automation will feature things that Apple
HomeKit does except they will all be internal to us who are developing the
system. There will need to be libraries that interact with the hardware but
they will be proprietary and we will not expose them to developers. Together
Z{}-Wave, Belkin, and Apple HomeKit complete the spectrum of home automation
solutions. Z{}-Wave provides a network foundation for people to create
appliances for, Belkin creates hardware and a mobile application to control it,
and then Apple HomeKit creates tools to develop applications for controlling
hardware.


\subsubsection{Nest Labs}
Unlike the previous companies, Nest Labs\cite{link19} is quite new,
but has certainly claimed its space in the smart home market with its smart
Nest Thermostat. Their other product, the Nest Protect, a smart smoke and
CO$_2$ detector, integrates smoothly with the thermostat allowing for remote
monitoring and control of the home. For their thermostat, the primary goal is
to have a smart learning thermostat that aims to save energy in the home. By
keeping temperatures at energy-saving levels when no one through the use of a
motion sensor and learning algorithms, one of the most expensive home energy
costs can be reduced.

In terms of administration, Nest has a online web interface and a mobile app
that will display all of the networked devices, allowing for a highly connected
experience. This would allow you to change your temperature from your warm bed
or before you even get home.

Nest Labs was recently purchased by Google for \$3.2 billion dollars\cite{link20},
which certainly gives the company a powerful position in the market. One of
Nest's goals is to have a \emph{platform} for other companies and developers to
create new products that \emph{Work with Nest \texttrademark}\cite{link21}. This strategy is
clever as now the success of the company will grow with every new
developer who chooses to integrate their products with the Nest suite.
Customers will see the multitude of devices that work with Nest and realize
that they can ``harness the future today.'' Quite a solid business model.
Coming in at \$249, the thermostat might be a tough sell for typical home owners who
already have a working, yet ``dumb'', thermostat.

\subsubsection{X10}
Founded in 1970s, X10 is one of the oldest home automation companies still on
the market.  Home security and automation are the key goals of X10. To meet
these goals, X10 offers a wide selection of products to link every aspect of
the home or business. When these products arrived in the early days, they set
the standard for home automation. The architecture is centered around wireless
remotes, transcievers, and appliance modules.  The transciever is a fixed
plug-in that is listening for commands from the wireless remote. If it receives
a command, it can send signals through the house power grid to an appliance
module.

The applications for X10 products are limitless. One issue with X10 and its
goals are that the entire system is proprietary and encourages lock-in. The
frameworks for making new X10 devices are not open, which could limit any
support. WHCS aims to do the opposite by providing a well documented home automation solution.
This became an issue with the original company of X10, X10 WTI, went
bankrupt in 2013. This caused a disruption in the X10 ecosystem, including
dedicated services run by X10 WTI. Luckily another company, Authinx, picked up
the domain\cite{link1} and is continuing to offer support and sales for
X10 products. Give this recent change of hands, choosing X10 today may not be a
sure choice for the future.