Technical Report - WordPress.com

vermontdroningMobile - Wireless

Dec 10, 2013 (3 years and 6 months ago)

161 views

UNIVERSITY OF CALIFO
RNIA, IRVINE

miHome

Home Automation System


David Dinh, Michael Wayne Li, Sonny Wai
-
Git Lin, Stephen Yang

6/6/2012







i

Abstract

Home automation is the centralized control of lighting, heating, ventilation, and household devices
within the home. The miHome home automation system uses an Android phone application to control a
number of household devices, such as door locks, smoke ala
rms, and power outlets, remotely over the
Internet. These devices are integrated with miHome’s controllers that use UART and radio frequency
transceivers to communicate with an intermediate Internet connected server. The server then relays the
communicatio
n to and from the Android application using TCP/IP. This system required multi
-
disciplinary knowledge and skills to design, including circuitry, mechanical engineering, software
development, system architecture, and wireless communication. MiHome is cheape
r than most
commercial solutions and is one of the most expandable. The system increases safety of the household
occupants by alerting them via text when a smoke alarm is activated. The system is also sustainable and
energy efficient, due to extensive use
of embedded devices, with most
components
consuming

only

nanowatts
at idle.



ii

TABLE OF CONTENTS

1.

Terminology

................................
................................
................................
................................
..........

1

2.

Background

................................
................................
................................
................................
...........

2

2.1 Motivation

................................
................................
................................
................................
...........

2

2.2 Problem Statement

................................
................................
................................
.............................

2

2.3 Constraints

................................
................................
................................
................................
..........

2

3.

System Overview
................................
................................
................................
................................
...

3

3.1 Physical Description

................................
................................
................................
............................

3

3.2
Operational Description

................................
................................
................................
......................

4

4.

Hardware Architecture

................................
................................
................................
.........................

4

4.1 UART
................................
................................
................................
................................
....................

4

4.2 Transmitter/Receiver Pairs

................................
................................
................................
.................

5

4.3 Nodes

................................
................................
................................
................................
..................

7

4.3.1 Node Core

................................
................................
................................
................................
....

7

4.3.2 Door Lock Node

................................
................................
................................
............................

7

4.3.3 Smoke Alarm Node

................................
................................
................................
......................

7

4.3.4 Power Node

................................
................................
................................
................................
.

8

4.4 Base Sta
tion

................................
................................
................................
................................
........

8

4.4.1 Arudino Uno

................................
................................
................................
................................
.

8

4.4.2 Ethernet Shield

................................
................................
................................
.............................

9

4.4.3 LCD Display

................................
................................
................................
................................
...

9

4.5 Android
Hardware

................................
................................
................................
...............................

9

5.

Software Architecture

................................
................................
................................
.........................

10

5.1 Wireless Protocol

................................
................................
................................
..............................

10

5.1.1 Message Format

................................
................................
................................
.........................

10

5.1.2 RF Transmission

................................
................................
................................
.........................

11

iii

5.2 No
des

................................
................................
................................
................................
................

12

5.2.1 Node Core

................................
................................
................................
................................
..

12

5.2.2 Door Lock Node

................................
................................
................................
..........................

12

5.2.3 Smoke Alarm Node

................................
................................
................................
....................

12

5.2.4
Power Node

................................
................................
................................
...............................

13

5.3 Internet Protocol

................................
................................
................................
...............................

13

5.3.1 Packet Structure

................................
................................
................................
.........................

13

5.3.2 Communication Model

................................
................................
................................
..............

14

5.4 Base Station

................................
................................
................................
................................
......

15

5.4.1 Base S
tation State Machine

................................
................................
................................
.......

15

5.4.2 Database

................................
................................
................................
................................
....

17

5.5 Android Application

................................
................................
................................
..........................

17

5.5.1 GUI

................................
................................
................................
................................
.............

17

5.5.2 Command Flow

................................
................................
................................
..........................

18

5.5.3 Data
base

................................
................................
................................
................................
....

18

6.

Development Plan

................................
................................
................................
...............................

18

6.1 Software Tool Chain

................................
................................
................................
..........................

18

6.2 Division of Labor

................................
................................
................................
...............................

19

6.3 Progress Timeline

................................
................................
................................
..............................

19

7.

Pro
blems Encountered

................................
................................
................................
.......................

21

8.

Conclusions

................................
................................
................................
................................
.........

22

8.1 Social Impact

................................
................................
................................
................................
.....

22

8.2 Future

Expandability

................................
................................
................................
.........................

22

9.

Works Cited

................................
................................
................................
................................
.........

23

10.

Appendix

................................
................................
................................
................................
.............

25


iv

LIST OF FIGURES

Figure 1: The miHome System

................................
................................
................................
......................

4

Figure 2: UART Module

................................
................................
................................
................................
.

5

Figure 3: Transmitter Pin
-
Out [1]

................................
................................
................................
..................

6

Figure 4: Receiver Pin
-
Out [2]

................................
................................
................................
.......................

6

Figure 5: PWM Servo Control Timings [3]

................................
................................
................................
.....

7

Figure 6: Arduino Uno Revision 1 [4]

................................
................................
................................
............

8

Figure 7: Arduino Ethernet Shield [5]

................................
................................
................................
...........

9

Figure 8: Ethernet Shield Connected to Arduino [5]

................................
................................
.....................

9

Figure 9: Communication between Base Station and Android application

................................
................

15

Figure 10: Base Station State Machine

................................
................................
................................
.......

16

Figure 11: Android Application Views

................................
................................
................................
.........

17




v

LIST OF TABLES

Table 1: RF Transmitter/Receiver Specifications

................................
................................
..........................

6

Table 2: Wireless Protocol
Message Format

................................
................................
..............................

10

Table 3: Manchester Bit Conversion

................................
................................
................................
...........

11

Table 4: Internet Packet Format

................................
................................
................................
.................

13

Table 5: Project Timeline

................................
................................
................................
............................

19

1

1.

TERMINOLOGY



Active Node: A node that can send and receive messages to the Base station.



Actuator:
A component of the node core that contains the PIC and any physical connections that
affect the functionality of the node.



Android Application: A
front
-
end GUI that allows the user to organize and control
individual nodes and manage system settings.



Base
Station: The central component of the miHome system. It relays Internet packets from the
Android application to the nodes using a wireless protocol over radio frequency.



Door Lock Node: A node that can lock or unlock a deadbolt on a door.



Internet: Communi
cation between the Android application and the Base Station are passed
through this medium.



IP Address: A number assigned to the Base Station by the Internet. The user would read this
number from the LCD Screen and enter it into the Android application.



Mi
cro
-
controller PIC16F628A (PIC): A low power processor attached to the core of most nodes.
It contains software to process messages and to actuate household devices.



miHome: A custom
-
built home automation system that consists of an Android application, a
B
ase Station, and several nodes.



Plant: A software behavioral model of the physical node that determines actuation



Passive Node: A node that can only receive messages from the Base Station.



Power Node: A node that can turn the current from an outlet ON or O
FF.



Radio Frequency (RF): The wireless medium used to send messages between the Base Station
and the node.



Smoke Alarm Node: A node that activates when smoke is detected and is otherwise asleep.


2

2.

BACKGROUND

Home automation is the centralized control of
lighting, heating, ventilation, and household devices
within the home. It allows a user to control remotely or automatically household devices.

2
.1
MOTIVATION

In the market, several
home automation

aim to provide convenience, efficiency, and security to
co
nsumers. Two examples are Craftsman’s Mobile Garage Door Opener [10] and GE’s Z
-
Wave system
[11]. The problems with these solutions are non
-
standardization and high cost. If a user wanted to
automate the light switches and door locks, the user would need t
o need to buy two separate systems
and
carry
two separate remotes [10]. For standardized solutions offered by one

vendor, the costs are
high,
the
number of devices is

limited
, and

the devices are only interoperable with each other

[11].

The miHome system,
however, uses low
-
cost embedded systems that embed into current household
devices, unlike

the complex commercial systems

which require users to replace their current devices
with the commercial ones. The miHome system aims to create a similarly functional
system, allowing
the user to remotely control and automate household devices through the use of a mobile device at a
lower cost than current offerings.

2
.2
PROBLEM STATEMENT

The goal of the project is to create a low cost, sustainable home automation syst
em. Because different
users may have different economic backgrounds or different levels of interest, the best design would
scale with the desires of the user
-

to automate only one room, or an entire household.

In order to achieve maximum control over powe
r consumption and cost, the development of the system
would have to be holistic. Team members must be familiar with low level details such as which bits to
send over a wireless link and high level abstractions such as GUI construction. This project is inhe
rently
multidisciplinary as it requires knowledge of circuitry, mechanical hardware, software development,
system architecture, and wireless communication.

2
.3
CONSTRAINTS

The system is required to be low cost, sustainable, and easy to develop and deploy.




The system should be low cost relative to similar products and must be easy to develop. This
constraint implies that the project shall be built with off
-
the
-
shelf components to save on
development time and cost.



The system should enhance sustainability;
system components must be built with low
-
power
embedded processors and discrete components.

3



The system must be easy to deploy and accessible to the end
-
user. This constraint implies that
user setup of the system must be minimal and that an intuitive user i
nterface must be
developed to support the use of the system.
The system must ensure that

minimal
wiring and
data entry is performed by the end
-
user.



The system must be easy to develop
and upgrade.
This calls for modularizing
components and
code so that th
ey can be easily integrated
into
future system designs.



3.

SYSTEM OVERVIEW

The system is holistic and requires both low
-
level hardware implementation and high
-
level software
development.

3
.1
PHYSICAL DESCRIPTION

At the lowest level of abstraction are the
nodes. Each node is an independent control circuit, modeling
the physical device actuation with a plant. It is physically connected to an actuator, and receives wireless
radio frequency, or RF, control signals from the Base Station. Each node contains a Mi
crochip
PIC16F628A micro
-
controller used to decode radio frequency messages from a 315MHz receiver and
control the connected plant. The circuitry differs with plants, but in general, however, here are two
categories of nodes: Active and Passive. Passive re
ceive control messages only and are described above.
Active nodes can additionally initiate communication with the Base Station and therefore contain a RF
transmitter as well.

The Base Station is an Arduino
-
based control circuit that is directly connected
to the Internet through an
Arduino Ethernet Shield and has radio frequency transmitters to send control signals to nodes. Its role is
to relay commands from the Android application to the nodes.

At the highest level of abstraction is an Android application
. This application provides the human end
-
user with control over the nodes. The application runs on an Android mobile OS equipped device and
interfaces with the Base Station through the Internet.



4

3
.2
OPERATIONAL DESCRIPT
ION


Figure
1
: The miHome System

Under normal operation of a passive node, a user would initiate a command to the node through an
Android device. The Android device would use the Internet to connect to the Base Station and send the
user’s comm
and. The Base Station would act as a relay and repeat the command through its RF
transmitters. Upon receipt of the message, the passive node will carry out the command (such as
turning a light on). After relaying
the command
, the Base Station would then se
nd an acknowledgement
back to the Android Device.

Under normal operation of an active node, an external trigger, such as an alarm, would wake the node
from sleep and cause it to send a message to the Base Station. The Base Station will interpret the
messag
e and relay it through SMTP e
-
mail servers to alert the Android user through e
-
mail/text
message. Upon receipt of the message, the user can launch the Android application and silence the
alarm by sending a “turn
-
off” command to the node. The data path that

the command takes is the same
as the one described in the previous paragraph.


4.

HARDWARE ARCHITECTUR
E

The main components of the system are the wireless transmitter/receivers, the nodes, the Base Station,
and the Android Application.
Although these

compone
nts’ behaviors are
mostly
driven by software
,
hardware is needed to support the higher functions of the system.


4
.1
UART

UART is the underlying protocol used for byte
-
level communication between the base station and
nodes. The higher level protocol that
dictates which bytes to send is described in the Software Protocol
section of the paper. Both the base station and nodes have hardware support for UART, which allows for
the abstraction of the UART functionalit
y into a black box (as shown in
Figure
2
: UART Module
).

5


Figure
2
: UART Module

For inputs, the system has an 8
-
bit TX register to store the byte to be transmitted and a run bit. The run
bit triggers transmission when set and is cleared by hardware upon completion. Busy wait while loops
exploit this to check for transmission competition before allowing the software to overwrite the TX
register with another byte. The node and Base Station s
ource code abstract this detail in sendByte(byte)
and Serial.write(byte) respectively.

For outputs, the system has an 8
-
bit RX register to store a received byte and two error bits, FERR and
OERR. FERR signals frame errors when the bits on the physical lay
er are misaligned. OERR signals
overrun errors when more than 8
-
bits are detected within one frame. An interrupt signal is sent when a
byte is received. The use of this mechanism is evident in the source code where serialEvent() captures
Base Station inter
rupts and RX_ISR() captures Node interrupts.

For both the Base Station and Node, the hardware module described above has direct control over TX
and RX pins for UART transmission and reception respectively. For the Base Station, the RX and TX pins
are conn
ected to a radio frequency transmitter/receiver pair. Nodes are split into two categories: active
and passive. Active nodes can initiate communication with the Base Station and thus have a
transmitter/receiver attached to the TX/RX pins as well. Passive no
des only receive information and thus
only have a receiver attached to the RX pin. Although in the original specificatio
n, all nodes had a
transmitter
(see
Problems Encountered
).

4
.2
TRANSMITTER/RECEIVER

PAIRS

Wireless transmitter/receiver pairs provide a communication link between nodes and the Base Station.
Wireless modules enhance the ease of setup for end users

by eliminating the need to route
communication lines from each node to the central Base Station.

The miHome system uses RF transmitter/receiver pairs that operate in the unlicensed 433.92 MHz and
315 MHz radio frequency spectrums intended for general use. To avoid cross talk, 315MHz is used to
transmit packets sent from the Base Station and 433.92MHz
is used to transmit packets from nodes.
Wenshing manufactures the transmitters/receivers and th
eir s
pecifications are listed below in
Table

1
:
RF Transmitter/Receiver Specifications
:



6

Table

1
: RF Transmitter/Receiver Specifications

Name

Model

Maximum
Data Rate
(bps)

Operating
Voltage

(Volts)

Current
Consumption
(mA)

Power
Consumption
(mW)

Unit
Cost

433.92 Mhz
Transmitter

TWS
-
BS
-
3

8,000

1.5


12.0

8.00

12
-

96

$3.95

433.92 Mhz
Receiver

RWS
-
371
-
6

4,800

4.9
-

5.1

0.01
-

0.20

0.049


1.02

$4.95

315 Mhz

Transmitter

TWS
-
BS
-
6

8,000

1.5
-

12.0

8.00

12
-

9.6

$3.95

315 Mhz

Receiver

RWS
-
374
-
3

4,800

4.9
-

5.1

0.01
-

0.20

0.049


1.02

$4.95

These devices are raw input/out devices; a HIGH on the transmitter’s Data In pin corresponds to a HIGH
on receiver’s Data Out pin. They lack processors to provide an underlying transmission protocol and
collision detection. This reduces both th
e cost and power consumption of the transmitter/receiver,
helping satisfy the project’s constraints on cost and sustainability.

The pin
-
out diagrams are
shown in
Figure
3
: Transmitter Pin
-
Out


and
Figure
4
: Receiver Pin
-
Out
.

Note

t
hat the transmitters/r
eceivers for
both

fre
quencies have the same pin
-
out

so only one of each is
shown.


Figure
3
: Transmitter Pin
-
Out

[1]



Figure
4
: Receiver Pin
-
Out

[2]

7

The Data In pin of the transmitter is connected to the TX pin of the UART module and the Digital Out pin
of the receiver is connected to the RX pin of the UART module. A baud
-
rate of 2400 was chosen for
UART module since
it was below the maximum data rate of the receivers.

4
.3
NODES

Nodes connect to physical actuators and carry out commands received through the RF receivers.

4
.3.1
NODE CORE

Although the node
circuitry

will differ depen
ding on the actuator attached,
all
nodes (except the power
node) have a similar “node code
.” The node core consists of a
Microchip PIC16F628A micro
-
controller
and a radio frequency receiver. These common components allow the nodes to receive
messages from
the Base Station
and process them.

In addition, we can share code between different nodes due to
these common components.

4
.3.2
DOOR LOCK NODE

The door lock node contain
s a PIC micro
-
controller, a 315 MHz

radio frequency receiver, an analog servo
motor to turn a door lock, and two buttons
to control the door lock without use of the Android
application. The servo motor has 3 pins: power, ground, and control. The control pin is modulated with
pulse width modulation (PWM) by the micro
-
controller chip (see
Figure
5

for the exact timings).


Figure
5
: PWM Servo Control Timings

[3]

The door lock node has two mini push button switches, which are rated to support 50 mA current and
have high quality Omicron type B3F momentary on switches and mounts normally on breadboards and
PCB
. These button switches are used for unlocking/locking th
e door lock, since we cannot physically put
our fingers on the door lock handle to turn it with our particular design.

4
.3.3
SMOKE ALARM NODE

A smoke alarm is purchased off the shelf, and the team designed the software and components to run
off the battery

power for the alarm. The smoke alarm node contains a PIC micro
-
controller, a 434 Mhz
radio frequency transmitter, a 315
MHz

radio frequency receiver, and a off the shelf smoke alarm. One
of the pins on the smoke detector switches from 0 volts to 9 volts w
hen the alarm is activated. This pin is
connected to a micro
-
controller, which is connected to the rest of the node core components. The
micro
-
controller is normally sleeping to save battery power, but turns on and sends messages through
the 434
MHz

radio

frequency transmitter every 5 seconds when the alarm is activated.

8

4.3.4
POWER NODE

The wireless power node was purchased off the shelf and its protocol was reverse
-
engineered to work
with the miHome system. Its purpose is to allow remote control of curre
nt through an outlet. The power
node contains a 315
-
Mhz receiver, which allows the Base Station to communicate with it.

4.4
BASE STATION

The core of the project is the Base Station. It maintains a database of all registered nodes, facilitates the
Android t
o Node communication, and contacts e
-
mail servers in case of emergencies.

4.4.1
ARUDINO UNO

The Base Station was built on
-
top of the Arduino Uno R1 board, an embedded system. It features an
Atmel Atmega328P
-
PU microcontroller running at 16 MHz with 2KB o
f SRAM, 32KB of program memory,
14 I/O pins, and a UART module. Along with the microcontroller, the board has a voltage regulator (up
to 20V), an Atmega8U2 co
-
processor for USB connectivity, and a DC
-
in power jack.


Figure
6
:
Arduino Uno Revision 1

[4]

The built
-
in UART module handles the Node communication; an RF transmitter and receiver, described
in Transmitter/Receiver Pairs, are connected to Digital Pin 1 and 0 which are the UART TX and RX pins
respectively. The Atmega8U2 co
-
processor handles commun
ication with the PC and facilitates both
programming the main Atmega328P
-
PU microprocessor and debug message passing. The I/O pins
control periphery devices connected to the
Arduino

(described below).


9

4.4.2
ETHERNET SHIELD

The native
Arduino

Uno hardware
does not support Internet connectivity, yet it is required for Android
communication and e
-
mail services. For this reason, an Ethernet Shield was added on.

The Ethernet Shield R1 was specifically developed for the Arduino Uno by the creators of
Arduino
. I
t
connects with the Arduino by directly seating itself on top of the Arduino Uno’s I/O pin connectors

(see
Figure

8
).
It features a WizNet W5100 Ethernet Controller wi
th an internal 16K buffer for network
packets, an RJ45 Ethernet jack, and a microSD slot (unused). The Ethernet Shield communicates with the
Arduino

through a Serial Peripheral Interface Bus, SPI, utilizing digital pins 11
-
13 for SPI and digital pins
10 an
d 4 for mode selection between the W5100 and SD card respectively.


Figure
7
: Arduino Ethernet Shield

[5]


Figure

8
: Ethernet Shield Connected to Arduino

[5]

The addition of the Arduino Ethernet Shield enabled Internet connectivity and facilitated
communication with Android devices and e
-
mail servers.

4.4.3
LCD DISPLAY

With the addition of the Ethernet Shield came an additional detail; the user needed to know the IP
address of the Base Station in order to send commands to it. For this reason, the designs incorporated a
DMC
-
16202 LCD screen which features a 16x2 character

LCD display and a Hitachi HD44780 chipset. The
Arduino API supports native communication with the Hitachi controller which helped lower
development time.

The LCD uses pins A2
-
A5 on the Arduino for 4
-
bit bidirectional data transfer, A1 for signaling
commu
nication start, and digital pin 7 for selecting between a read or write operation. The contrast and
power lines are connected directly to the power rails of the Arduino.

4.5
ANDROID HARDWARE

Although Google built the Android platform to be open
-
source for

all devices, there are a few general
hardware features this project requires for interoperability:



Internet Connection: Wifi or Cellular



Touch Screen: Single or Multi
-
touch supported

10



Processor Speed: 400Mhz+



Main Memory: 256MB+



Main Storage: 256KB (appli
cation only), 512MB recommended (total)



Peripherals: Microphone and Speaker (for voice operation)


5.

SOFTWARE ARCHITECTUR
E

The software contained in each component of the miHome system is concerned with communication or
internal bookkeeping. Communication exists on a wireless protocol and an
I
nternet protocol.

5.1
WIRELESS PROTOCOL

The Base Station and nodes use a common wirel
ess protocol to pass messages. Nodes will decode
messages that contain its ID and ignore all others.

5.1.1
MESSAGE FORMAT

The messages are 15 bytes long and have the following structure:

Table
2
: Wireless

Protocol Message Format

Fie
ld Name

Size (bytes)

Purpose

Direction

1

Indicates packet direction.

Node ID

2

Addresses the node responsible for the contents.

Base Station ID

1

Addresses the Base Station responsible for the contents.

Command

1

The functionality to be performed.

Data 1

4

Data related to the command, if any.

Data 2

4

Additional data related to the command, if any.

Error Checking
(CRC)

2

Used to detect errors in wireless transmission; calculated by adding
the bytes in the message

The Direction Byte is included to

allow nodes to quickly ignore messages. Some fields have different
purposes depending on which direction the message is sent.

The differences are explained below.


11

Messages from Base Station to node:



Direction: has a value of 0xBA



Node ID: recipient of
the message



Command: functionality the node needs to perform



Data: arguments needed by the node to complete the command

Messages from node to Base Station:



Direction: has a value of 0xDC



Node ID: author of the message



Command: functionality that the node h
as performed



Data: results from the completed command (i.e. status, temperature reading, etc.)

The wireless protocol is written in C for both the Base Station and the nodes. A call to
sendMessage(Message * msg) will transmit the message in RF.

5.1.2
RF TRA
NSMISSION

To send and receive a message over the air, the spectrum noise must be taken into consideration.
Before a message can be transmitted, a synchronization byte is sent to prime the channel in order to
synchronize the sampling clock.

When the actual

message is ready to be sent, the wireless protocol converts each byte to 2 Manchester
bytes. The bit mapping is described in the table below.

Table
3
: Manchester Bit Conversion

Message Bit

→ is replaced with →

Manchester Bits

1


is replaced with →

10

0

→ is replaced with →

01

After the conversion, the Manchester bytes are loaded into the UART TXREG, one at a time. At the
receiving end, the Manchester bytes are collected two at a time, and translated back into the original
messag
e.



12

5.2
NODES

Nodes contain a state machine that facilitates event
-
based transitions. All passive nodes will only
receive messages, while active nodes will be able to both send and receive messages.

5.2.1
NODE CORE

All passive nodes
have three

common states, regardless of their function:



IDLE: process incoming bytes for a message and filter out noise



ACTUATE: interpret the message and act accordingly



ACK: send an acknowledgment back to the base station, but due to time constraints and
hardware
complications, this state remains unused.

All active nodes have three common states, regardless of their function:



IDLE: sleep micro
-
controller to conserve power



EMERGENCY: the node sends an emergency message to the base station, which will get relayed
to
a phone.



ACK: the base station sends an acknowledgment back to the node, which makes the node return
to the IDLE state.

5.2.2
DOOR LOCK NODE

The door lock node is a passive node, which means that it only receives commands from the Base
Station. Because it
has a servo, the node stores the current rotation angle as a variable. A call to
door_lock() will set the proper timer interrupts to produce the current pulse width modulation (PWM)
to lock the door and door_unlock() will unlock the door. The IDLE state is

extended to include a PWM
control signal for the current rotation angle. The door lock node also goes into a ROTATE state to change
the current rotation angle when receiving DOOR_CMD_LOCK.

5.2.3
SMOKE ALARM NODE

The smoke alarm node is an active node, whi
ch means that it can send and receive a command to the
Base Station. In the IDLE state, an LED blinks to signify that the alarm is active, but the micro
-
controller
sleeps to save battery power. When the alarm is triggered, the smoke alarm node goes into t
he
ALARM_MODE state and sends a message to the Base Station. The node returns to the IDLE state when
it receives a SMOKE_DETECTOR_CMD_ALARM_OFF.



13

5.2.4
POWER NODE

The power node is a passive node. Because it is an unmodified pre
-
built device, the node doe
s not
contain software by the miHome team. Although it can receive messages, the internal software
communicates on a different protocol. The RF signals emitted from the power node’s pre
-
built remote
ON and OFF commands were reverse
-
engineered and hard
-
code
d into the Base Station, allowing the
Base Station to control the power node.

5.3
INTERNET PROTOCOL

A protocol was developed to facilitate communication between the Base Station and an Android device
over the Internet. It sends fixed
-
sized messages and rel
ies on the underling TCP/IP transport layer to
handle error
-
less delivery of packets. The Base Station implementation was written in C and the Android
device implementation is written in Java.

5.3.1
PACKET STRUCTURE

The packets were designed to support thr
ee types of control messages: node management, group/room
management, and command relay. For this reason, there exists three flavors of packets, but they are all
54
-
bytes long and contain a common 6
-
byte header. The packet structure is described below in C

constructs.

Table
4
: Internet Packet Format



The 6
-
byte header contains a direction indicator, a Base Station command field, and sequence numbers.
The valid values for the direction and command field are
explained in the Android GIT repository
linked
14

to

in the appendix
, but the important detail is that the command field dictates which payload would
come after the header. Note that the payloads have different lengths, but they are zero
-
padded to
achieve the

static 54
-
byte packet length.

If the command fell under the category of node management, such as adding and deleting nodes, then
the Node Payload would be used. It contains all the necessary fields to fully replace a Base Station
database entry; the Node
ID uniquely identifies a node and groupID identifies its group affiliation. Last
modified indicates the last time the node entry was modified and data1/data2 store the last known
status of the node. The 32
-
byte char array, name, stores a user specified tex
tual string to identify a
node.

If the command fell under the group/room management, the payload of char[32] name is used. This is
the only modifiable group field since groups are internally represented as a tuple of a name and an id
and ids are assigne
d by the Base Station. Nodes can be affiliated with a group by having a group’s id.

If the command fell under the category of command relay, the Net_CMD data structure is used. The
data structure closel
y resembles a wireless message (
see
Table
2
: Wireless

Protocol Message Format
)
. It
encapsulates the essence of a node command sent through the wireless protocol; it specifies which
node to contact, with
what commands, and with which arguments. Those fields are intended to be
copied verbatim into a wireless message.

5.3.2
COMMUNICATION MODEL

The miHome
I
nternet protocol runs on top of the TCP/IP transport layer. However the details of TCP/IP
will not be di
scussed in this document, because the documentation is publicly available (Citation) and
the details are not important to the core operation of the system.

In our communication model, only the Android device can initiate a connection with the Base Station;

the Base Station cannot initiate connections. This design decision is based on the observation that an
Android device roaming on a cellular network will not have a static IP and a Base Station residing in a
static location will most likely retain its IP.

When an Android device wants to initiate communication with a Base Station, it shall open a TCP socket
with the Base Station’s IP address on port 1200. It shall probe the connection by sending a HELLO (0x03)
command
packet to the Base Station and shall exp
ect an ACK_HELLO (0x13) command packet. At this
point, other Base Station commands can be sent down the pipe. Connections are closed via the standard
TCP/IP close.
Figure
9

describes the process pictorially.


15



Figure
9
: Communication between Base Station and Android application

After the initial connection, any of the packets mentioned in the previous section can be sent to t
he
Base Station and a singular ACK packet is expected in all cases except packets containing the opcodes
GET_NODES and GET_GROUPS. In these cases, a series of N packets shall be sent by the Base Station
where each packet specifies a Node or Group stored in

the database. The sequence number fields in the
header shall be used to index the nodes and when seq_id == seq_total, all nodes/groups have been sent.

This behavior is modeled in
Figure
9
.

5.4
BASE STATION

The Base Station is
an

intermediary
relay that connects

the Android application to the miHome nodes.

It
is an always
-
on device
that listens for
TCP/IP
connections from the Android
application and

relays the
comman
ds

to the nodes through its RF transmitter/receiver pair.

5.4.1
BASE STATION STATE M
ACHINE

The Base Station has nine states (a pictorial representation is shown i
n
Figure
10
):



IDLE: this is the default initial state. Since the system is idling and not checking for messages,
email via SMTP are sent in this state.

16



ETHERNET_POLLING: the Base Station polls the 16K E
thernet buf
fer for I
nternet packets from
the Android application.



RF_TX_SETUP: the Base Station has received the command from the Android application and
primes the RF circuity to transmit.



CONTROL_POWER_NODE: the Base Station Station sends a reverse
-
engi
neered command to the
power node via its 315MHz radio frequency transmitter



RF_TX_SEND: the Base Station sends the command to a node via its 315MHz radio frequency
transmitter using our native protocol.



RF_WAIT_FOR_ACK: wait for an acknowledgement from th
e node that the command was sent
successfully.



RF_DECODE_PACKET: decode the acknowledgement packet from the node



ETHERNET_SEND_ACK: send a “acknowledgement” packet back to the Android application, so
the user knows that the transmission was successful



ETH
ERNET_SEND_NACK send a “no acknowledgement” packet back to the Android application,
so the user knows that the transmission was unsuccessful


Figure
10
: Base Station State Machine



17

5.4.2
DATABASE

The nodes can be grouped into rooms for easy access on the Android application. Information about the
nodes and rooms are kept in a database on both the Base Station and the Android application. The
organization of nodes and rooms synchronizes between the

Android application and the Base Station.
The database is implemented as a linked list with an O(n) query time. In practice, this translates to a
small penalty since practical lists have less than 100 items. The space
-
efficient linked lists optimize the
A
rduino’s memory usage.

5.5
ANDROID APPLICATION

The Android application is the front
-
end GUI that facilitates user interaction with the system. In its
current form, the application allows the user to add/delete/group nodes, send commands to individual
nodes
, and manage system settings such as where to send emergency e
-
mails.


Figure
11
: Android Application Views

5.5.1
GUI


The user starts from the Grids Menu to navigate to three different sub
-
menus, as seen from the
Figure
11
.
From the Grid Menu, users are also able to access the Settings Menu. In the Settings Menu, users are
able to remove all local data in the system or change t
he IP address to the Base Station. This allows
users to connect to different miHome systems with the same Android device. In the Grid Menu, users
also have to option to add rooms or nodes locally or to synchronize with the Base Station. The user can
either

view all the available nodes on the miHome system or view specific rooms. The Rooms Menu
18

allow users to view specific nodes are added by the user from the Grid Menu. When users select the
nodes, they are able to enter the node’s unique menu and send speci
fic commands to the Base Station
to actuate the specific node. This UI allows users to view the status of the system and control nodes.

5.5.2
COMMAND FLOW

Once the Android application obtains the Base Station’s IP address, it can send Internet packets, wh
ose
format is shown in
Table
4
: Internet Packet Format
, to the Base Station. When the user selects a node
command on the GUI, the corresponding node ID and command are passed to the Base Station. The
protocol also contains additional arguments, but due to time
-
constraints, the extra parameters remain
unused.

A new process is spawned to handle network communications for each user
-
initiated event
because there can be significant network delays. The result is a more responsive interface as the
application sends the command for a node to the Base Station in the b
ackground.

5.5.3
DATABASE

The Android application stores two types of information for correct functionality: Base Station IP
Address and node data. In order to communicate to the Base Station, the application needs to store the
Base Station’s IP address.
The user enters the IP address in the Android’s secure preference data
manager, where sensitive data is stored and encrypted. The Android application also uses a built
-
in
SQLite database to store the organization of nodes and rooms generated by the user. W
ith a local
database, the application is able to synchronize the information of the nodes with the Base Station and
communicate effectively with the system.


6.

DEVELOPMENT PLAN

The miHome
system is
inherently a
massive and
multidisciplinary
project incorpor
ating all aspects of
Computer Science and Engineering
.
For

this reason careful planning and division of labor is required
to
ensure that all com
ponents can be completed on time.

6.1
SOFTWARE TOOL CHAIN

To program the Arduino Uno, the Arduino IDE v1.0 is u
sed. It contains a built
-
in code editor, compiler,
and programmer software. For the PICs, Microchip’s MPLAB IDE release 8.76 was used. This compiler
contains Hi
-
Tech’s free
-
version C
-
compiler for the microchips. A PICPro K150 programmer is used
program the

PICs with a .hex file generated from Hi
-
Tech’s cross compiler. The PIC programmer relies on
MicroBurn v150807 to interface with the PIC. For mobile development, the Android platform is used.
Because Android development extends from Java, the IDE Eclipse i
s used, since it has built
-
in support for
Java.

In order to keep the source code organized and collaborative, a combination of GIT version control and
Dropbox was used. GIT allowed complete and correct source code to be saved reliably as milestones.
Dropbo
x allowed the team to share the same files, documentation, and datasheets.

19

6.2
DIVISION OF LABOR

The miHome project can be separated into four problem domains: node development, wireless RF
communication, Base Station integration, and Android application.

Each team member was assigned a
domain based on their past experience and current interests.

David Dinh held an internship position at Broadcom, under the wireless connectivity group. With his
experience of communication protocols, David developed the RF
message packet structure and
implemented the RF protocol between the nodes and the Base Station.

Stephen Yang held an internship position at STEC where he built an SSD
-
based Memcached server in C.
With his knowledge of databases and network protocols, he b
uilt the TCP/IP network layer for the
Android and Base Station communication link, built the core and database section of the Base Station,
and advised the development of the RF protocol for the Nodes and Base Station. He was in charge of
Base Station Inte
gration.

Mike Li has worked extensively with embedded systems, ranging from the Tilera chip to the AVR micro
-
controller. He developed the software and built the nodes of our system. He wrote the code in the
nodes to integrate with our current household de
vices and tested them. He also debugged the wireless
protocol and the integration of the protocol with the nodes and base station.

Sonny Lin worked as a freelance Flash developer. With the experience in UI design he developed the
Android mobile applicatio
n. He designed the application’s user interface and local database systems.
Under the miHome team, he helped developed the communication protocol and determined how the
users can dynamically organize and add the nodes in the system.

6.3
PROGRESS TIMELINE

Table
5
: Project Timeline

Quarter

Week

Goal
s

Fall 2011

1

Administrative Objectives



Team Formation



Find Faculty Advisor



Define Project Thesis


2



3

Design Objectives



Create System Layout and System Protocol



Discuss
Responsibilities



Create Prototypes



Purchase Parts


4


20


5



6

Core System Programming



Program Base
-
Node Communication Protocol



Program Base Station



Program Base
-
Mobile Communication protocol


7



8



9



10

Fall Quarter Wrap
-
up



Submit Design Document

to CSE 181A



Research into Android Development

Winter Break





Winter 2012

1

Nodal System Programming



Program node software to interact with device



Program node software to receive commands



Pro
gram node software to send data

Android



Program Mobile App
GUI


2

Top
-
Level Integration



Connect Core System to the Mobile App via Internet



Program Mobile App to send commands to Core System



Program Mobile App to receive data from Core


3

Develop Android SQLite database


4

Android



Program Mobile
-
Base
Communication Protocol


5

Nodal Device Manufacturing



Attach Nodes to makeshift devices

Quality Assurance and Testing



Regression Tests



Sanity Tests


6

Test Android Communication to Base Station

21


7

Developed Android Room category for Nodes


8



9

Winter

Quarter Wrap
-
up



Package and submit project to CSE 181B



Finalize presentation for Senior Design Expo


10

Developed Android Voice Commands

Spring Break





Spring 2012

1

Nodal Device Manufacturing



Attach Nodes to more substantial devices


2



3



4

Spring Quarter Wrap
-
up



Finalize project


5



6

Prepare for UROP Presentation (Saturday, May 19, 2012)



Print necessary materials


7



8

Prepare for Individual Senior Design Report for CSE 181CW



Write
-
up for the entire process



Presentation to Faculty


9



10



Developed Senior Design Paper


7.

PROBLEMS ENCOUNTERED

The miHome system primarily encountered problems when developing node hardware.

The way the
wireless protocol was implemented changed many times
as we started to learn of the limitations of
wireless.
We found that we had to deal with noise, that UART bits are not self synchronizing
un
like
Manchester

encoding,
and

that we
were incorrectly using the RF modules for half a quarter.


22

The implementation of the wireless protocol contributed to the greatest amount of time spent.
Firmware for both the transmitter and receiver was written in parallel. Whenever the transmission
format is changed, the firmware for both sides would
need to be
changed
. The complications occur
because a small design change results in large code rewrites and crosscutting concerns.

A similar problem occurred when the functionality of the nodes changed. Several layers divide the nodes
and the Android application, wh
ich makes it difficult to synchronize the changes. The agreement on
command arguments, results, and data makes this most apparent. Due to time constraints, a few
functionalities of the Android application remain unused.


8.

CONCLUSIONS

The miHome system demon
strated that home automation does not have to come
with
a premium and
that
the amount of integration
scalable.
The prototype
system
included

nodes
such a
s
smoke alarm,
lock, and power

node, which
hint at the possibility that the home automation system coul
d be used to
enhance
safety, security and sustainability.
The system is also
upgradable to include
extra nodes

at
amortized development costs.

8.1
SOCIAL IMPACT

The miHome system was motivated by a variety of societal reasons, including safety, energy, an
d cost. A
major social concern is energy efficiency and power consumption, and the miHome system allows the
user to turn off power remotely over the Internet. In addition, the system uses energy
-
efficient
embedded systems which are much more energy effic
ient than conventional PC servers. The system also
increases safety of household occupants due to integration with door locks and smoke alarms.

Traditional home automation systems do not provide safety features and are not budget friendly; they
require peo
ple to buy entirely new household devices. In contrast, our research and implementation of
the system has shown that our home automation system can be built with relatively low cost and
integrate with current and future household devices.

8.2
FUTURE
EXPANDABILITY

Much of the node software can be reused for similar household devices. The door lock node has servo
libraries that can be expanded for use with controlling window blinds. The smoke alarm node can be
reused to create a node for a water leak
detector. Hardware modifications, rather than software, would
be the most time
-
consuming change needed to make similar nodes. Even after the initial miHome
system deployment, newly developed or updated nodes can be incorporated into the system by
downloadi
ng the latest miHome Android application and Base Station software.

The miHome system design showed that it is possible to create a low cost home automation system that
is able to adapt to current household goods.



23

9.

WORKS CITED


[1]

Sparkfun Electronics, "RF Link Transmitter
-

315MHz
-

SparkFun Electronics," SparkFun Electronics,
[Online]. Available: http://dlnmh9ip6v2uc.cloudfront.net/datasheets/Wireless/General/TWS
-
BS
-
6_315MHz_ASK_RF_Transmitter_Module_Data_Sheet.pdf. [Accessed Dec
2011].

[2]

SparkFun Electronics, "RF Link Receiver
-

4800bps (315MHz)
-

SparkFun Electronics," WENSHING,
2012. [Online]. Available:
http://dlnmh9ip6v2uc.cloudfront.net/datasheets/Wireless/General/RWS
-
374
-
3_315MHz_ASK_RF_Receiver_Module_Data_Sheet.pdf. [A
ccessed 06 June 2012].

[3]

Hforesti, "Sinais controle servomotor.JPG," Wikipedia, 2006.

[4]

Arduino, "Arudino Uno," 16 April 2012. [Online]. Available:
http://arduino.cc/en/Main/ArduinoBoardUno. [Accessed 1 June 2012].

[5]

Arudino, "Arudino Ethernet
Shield," Arudino, 2 June 2012. [Online]. Available:
http://arduino.cc/en/Main/ArduinoEthernetShield. [Accessed 1 June 2012].

[6]

Craftsman, "Craftsman," Craftsman, 2011. [Online]. Available: http://www.craftsman.com/garage
-
door/dap
-
120000000180763. [Acce
ssed 06 June 2012].

[7]

Microchip Technology Inc., "PIC12F1840," Microchip, 2009. [Online]. Available:
http://ww1.microchip.com/downloads/en/DeviceDoc/41441B.pdf. [Accessed 06 June 2012].

[8]

AVNet Electronics Marketing, "PIC16F628A Parts
-

Avnet Expre
ss," Microchip, 2008. [Online].
Available: http://ww1.microchip.com/downloads/en/DeviceDoc/40044F.pdf. [Accessed 05 June
2012].

[9]

SparkFun Electronics, "RF Link Receiver
-

4800bps (434MHz)
-

SparkFun Electronics," WENSHING,
[Online]. Available: http://
dlnmh9ip6v2uc.cloudfront.net/datasheets/Wireless/General/RWS
-
371
-
6_433.92MHz_ASK_RF_Receiver_Module_Data_Sheet.pdf. [Accessed 06 June 2012].

[10]

SparkFun Electronics, "RF Link Transmitter
-

434MHz
-

SparkFun Electronics," WENSHING, 2012.
[Online]. Avail
able: http://dlnmh9ip6v2uc.cloudfront.net/datasheets/Wireless/General/TWS
-
BS
-
3_433.92MHz_ASK_RF_Transmitter_Module_Data_Sheet.pdf. [Accessed 06 June 2012].

24

[11]

Home Depot, "Z
-
Wave Basic Handheld Remote
-
45600 at The Home Depot," McNair Technology
Co,
Ltd, 30 March 2007. [Online]. Available:
http://www.homedepot.com/webapp/wcs/stores/servlet/ProductDisplay?productId=202453937
&storeId=10051&langId=
-
1&catalogId=10053&MERCH=REC
-
_
-
product
-
1
-
_
-
202453948
-
_
-
202453937
-
_
-
N. [Accessed 06 June 2012].





25

10.

APP
ENDIX

Android Git Repository
:

https
://
linsw
@
bitbucket
.
org
/
linsw
/
mihomeandroid
.
git


Base Station and Node Git Repository
:

https
://
linsw
@
bitbucket
.
org
/
mikeli
/
mihome
-
base
-
station
.
git