UNIVERSITY OF CALIFORNIA, IRVINE
miHome
Home Automation System
David Dinh, Michael Wayne Li, Sonny Wai-Git Lin, Stephen Yang
6/6/2012
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 alarms, 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
communication to and from the Android application using TCP/IP. This system required multidisciplinary knowledge and skills to design, including circuitry, mechanical engineering, software
development, system architecture, and wireless communication. MiHome is cheaper 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.
i
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 Station ........................................................................................................................................ 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
ii
5.2 Nodes ................................................................................................................................................ 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 Station 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 Database .................................................................................................................................... 18
6.
Development Plan............................................................................................................................... 18
6.1 Software Tool Chain .......................................................................................................................... 18
6.2 Division of Labor ............................................................................................................................... 19
6.3 Progress Timeline .............................................................................................................................. 19
7.
Problems Encountered ....................................................................................................................... 21
8.
Conclusions ......................................................................................................................................... 22
8.1 Social Impact ..................................................................................................................................... 22
8.2 Future Expandability ......................................................................................................................... 22
9.
Works Cited ......................................................................................................................................... 23
10. Appendix ............................................................................................................................................. 25
iii
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
iv
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
v
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: Communication 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.
●
Micro-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
Base 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 OFF.
●
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.
1
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
consumers. 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 to 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 system. 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 power 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 inherently
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.
2
●
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 interface 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 they 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 Microchip
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 receive 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 enduser with control over the nodes. The application runs on an Android mobile OS equipped device and
interfaces with the Base Station through the Internet.
3
3.2 OPERATIONAL DESCRIPTION
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 command. 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 send 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
message 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 ARCHITECTURE
The main components of the system are the wireless transmitter/receivers, the nodes, the Base Station,
and the Android Application. Although these components’ 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 functionality into a black box (as shown in Figure 2: UART Module).
4
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 source 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 layer 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 interrupts 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 connected 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 nodes only receive information and thus
only have a receiver attached to the RX pin. Although in the original specification, 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 their specifications are listed below in Table 1:
RF Transmitter/Receiver Specifications:
5
Table 1: RF Transmitter/Receiver Specifications
Name
433.92 Mhz
Transmitter
433.92 Mhz
Receiver
315 Mhz
Transmitter
315 Mhz
Receiver
Model
TWSBS-3
RWS371-6
TWSBS-6
RWS374-3
Maximum
Data Rate
(bps)
8,000
Operating
Voltage
(Volts)
1.5 – 12.0
Current
Consumption
(mA)
8.00
Power
Consumption
(mW)
12 - 96
Unit
Cost
$3.95
4,800
4.9 - 5.1
0.01 - 0.20
0.049 – 1.02
$4.95
8,000
1.5 - 12.0
8.00
12 - 9.6
$3.95
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 the 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
that the transmitters/receivers for both frequencies have the same pin-out so only one of each is
shown.
Figure 3: Transmitter Pin-Out [1]
Figure 4: Receiver Pin-Out [2]
6
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 depending 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 contains 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 the 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 when 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.
7
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 current 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 to 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 of 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 communication 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).
8
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. It
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 with 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 and 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
communication 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
9
●
Processor Speed: 400Mhz+
●
Main Memory: 256MB+
●
Main Storage: 256KB (application only), 512MB recommended (total)
●
Peripherals: Microphone and Speaker (for voice operation)
5. SOFTWARE ARCHITECTURE
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 Internet protocol.
5.1 WIRELESS PROTOCOL
The Base Station and nodes use a common wireless 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
Field 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.
10
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 has 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 TRANSMISSION
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
message.
11
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, which 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 the
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.
12
5.2.4 POWER NODE
The power node is a passive node. Because it is an unmodified pre-built device, the node does 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-coded 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 relies 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 three 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
13
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 NodeID 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 textual 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 assigned 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 closely 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 Internet protocol runs on top of the TCP/IP transport layer. However the details of TCP/IP
will not be discussed 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 expect 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.
14
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 the
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
commands to the nodes through its RF transmitter/receiver pair.
5.4.1 BASE STATION STATE MACHINE
The Base Station has nine states (a pictorial representation is shown in 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.
15
●
ETHERNET_POLLING: the Base Station polls the 16K Ethernet buffer for Internet 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-engineered 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 the 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
●
ETHERNET_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
16
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
Arduino’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 the 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
17
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 specific 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, whose
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 background.
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. With 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 incorporating all aspects of
Computer Science and Engineering. For this reason careful planning and division of labor is required to
ensure that all components can be completed on time.
6.1 SOFTWARE TOOL CHAIN
To program the Arduino Uno, the Arduino IDE v1.0 is used. 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 is 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.
Dropbox allowed the team to share the same files, documentation, and datasheets.
18
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 built 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 Integration.
Mike Li has worked extensively with embedded systems, ranging from the Tilera chip to the AVR microcontroller. He developed the software and built the nodes of our system. He wrote the code in the
nodes to integrate with our current household devices 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 application. 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
Fall 2011
1
Goals
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
19
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
1
Nodal System Programming
● Program node software to interact with device
● Program node software to receive commands
● Program 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
Winter Break
Winter 2012
20
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
1
Nodal Device Manufacturing
● Attach Nodes to more substantial devices
Spring Break
Spring 2012
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 unlike
Manchester encoding, and that we were incorrectly using the RF modules for half a quarter.
21
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, which 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 demonstrated that home automation does not have to come with a premium and
that the amount of integration scalable. The prototype system included nodes such as smoke alarm,
lock, and power node, which hint at the possibility that the home automation system could 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, and 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 efficient 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 people 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
downloading 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.
22
9.
WORKS CITED
[1]
Sparkfun Electronics, "RF Link Transmitter - 315MHz - SparkFun Electronics," SparkFun Electronics,
[Online]. Available: http://dlnmh9ip6v2uc.cloudfront.net/datasheets/Wireless/General/TWS-BS6_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-3743_315MHz_ASK_RF_Receiver_Module_Data_Sheet.pdf. [Accessed 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/garagedoor/dap-120000000180763. [Accessed 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 Express," 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-3716_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]. Available: http://dlnmh9ip6v2uc.cloudfront.net/datasheets/Wireless/General/TWS-BS3_433.92MHz_ASK_RF_Transmitter_Module_Data_Sheet.pdf. [Accessed 06 June 2012].
23
[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].
24
10. APPENDIX
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
25