Final Design Report
HomeAlive
Team 9
2014 – 2015
Andrew Jo
Okkar Moe Myint
Hezkiel Nanda
Jeremy Ward
Engineering 340: Senior Design Project
Calvin College
May 13, 2015
© Andrew Jo, Okkar Myint, Hezkiel Nanda, Jeremy Ward, and Calvin College
Abstract
The HomeAlive project was to design a home automation system that allows the monitoring and
control of any household device from any remote location using a mobile phone, tablet, or computer.
Most homes do not utilize the technology available in the modern age, and the electrical devices
within them are unnecessarily inaccessible. This project shows that the addition of a cost-effective,
aftermarket home automation system to a house would result in productivity, security, and environmental
conservation gains. The project’s system prototype allows the reliable control and monitoring of
household devices via remote user interfaces.
The design of a home automation system that satisfies this need could take many various forms;
the implementation that has been chosen includes sample devices, gateways, a server, and user interfaces.
These components form a network that allows information and commands to be sent from the user
interfaces to a specific device, and from each device to the user interfaces. The server, gateway, and user
interface required software design, and each sample device required both hardware and software design.
Additionally, the electrical and wireless communication between these components required significant
hardware and software design with a focus on protocol selection and utilization.
The final prototype that was designed and implemented throughout this project was completed by
May 9, 2015. In addition to the development of a functional prototype, this project included giving
presentations, recording documentation, writing reports, and maintaining a web presence. A project
budget was established and followed, consisting of approximately $600 as allocated to the project by the
Calvin College Engineering Department. This funding was spent wisely in order to obtain the
development tools and physical parts necessary to implement the design. The team responsible for this
project consists of four electrical and computer engineering students: Andrew Jo, Hezkiel Nanda, Jeremy
Ward, and Okkar Moe Myint. Calvin College engineering Professor Mark Michmerhuizen, Gentex
employee Eric Walstra, and SpinDance Inc. employee David van Geest all generously agreed to support
the team for the duration of the project.
The progression of the HomeAlive project from September, 2014 to May, 2015 is one of
decreasing and increasing scopes. First, the team considered designing an entire home automation system
with four sample devices. Eventually, they realized that this was a very large scope, and narrowed the
project down to a home automation system prototype with a single sample device. In March, the team
reevaluated their schedule and budget, then decided to revisit some of their original goals; they reincreased their scope to include two sample devices and some additional features. The prototype was
completed by May 9 with some minor bugs remaining as explained below. However, there are some
areas that would require improvement if this project were extended, including performance testing.
The HomeAlive prototype home automation system allows the monitoring and control of two
households, and each household includes a thermostat and an outlet adapter as sample devices. Users
interact with the prototype via an intuitive website user interface, and system communication is managed
using the server and one gateway per household.
1
1
Contents
Contents ............................................................................................................................................. i
2
Table of Figures ............................................................................................................................... vi
3
Table of Tables .............................................................................................................................. viii
4
Abbreviations ................................................................................................................................... ix
5
Introduction ....................................................................................................................................... 1
5.1
Report & Project Context.............................................................................................................. 1
5.2
Problem Statements ...................................................................................................................... 1
5.3
Project Definition & Objectives .................................................................................................... 1
5.4
Scope & Constraints ..................................................................................................................... 2
6
Acknowledgments............................................................................................................................. 3
7
Project Management ......................................................................................................................... 4
7.1
Team Organization........................................................................................................................ 4
7.1.1
Team Advisor........................................................................................................................ 4
7.1.2
Course Instructors at Calvin College .................................................................................... 4
7.1.3
Industrial Consultants ........................................................................................................... 4
7.1.4
Team Members ..................................................................................................................... 4
7.2
Team Meetings.............................................................................................................................. 4
7.3
Team Documentation & Task Organization ................................................................................. 4
7.4
Schedule ........................................................................................................................................ 5
7.4.1
Milestones ............................................................................................................................. 5
7.4.2
Schedule Management .......................................................................................................... 5
7.5
Budget Management ..................................................................................................................... 6
7.5.1
Sources of Funding ............................................................................................................... 6
7.5.2
Budget Details ....................................................................................................................... 6
8
System Requirements........................................................................................................................ 8
8.1
Requirements Categories .............................................................................................................. 8
8.1.1
Functional ............................................................................................................................. 8
8.1.2
Performance .......................................................................................................................... 9
9
System Architecture ........................................................................................................................ 10
9.1
Conceptual Diagram ................................................................................................................... 10
9.2
Component Summaries ............................................................................................................... 11
9.2.1
User Interfaces Summary .................................................................................................... 11
9.2.2
Server Summary.................................................................................................................. 11
9.2.3
Gateways Summary ............................................................................................................ 11
i
9.2.4
Devices Summary ............................................................................................................... 11
9.2.5
Component Interactions Summary...................................................................................... 12
10
Component Requirements ........................................................................................................... 14
10.1
User Interface Requirements ....................................................................................................... 14
10.1.1
Functional ........................................................................................................................... 14
10.1.2
Performance ........................................................................................................................ 14
10.2
Server Requirements ................................................................................................................... 15
10.2.1
Functional ........................................................................................................................... 15
10.2.2
Performance ........................................................................................................................ 15
10.3
Gateway Requirements ............................................................................................................... 16
10.3.1
Functional ........................................................................................................................... 16
10.3.2
Performance ........................................................................................................................ 16
10.4
Device Requirements .................................................................................................................. 17
10.4.1
Outlet Adapter ..................................................................................................................... 17
10.4.2
Thermostat .......................................................................................................................... 19
11
Task Specifications and Schedule ............................................................................................... 21
11.1
Work Breakdown Summary........................................................................................................ 21
11.2
Time Tracking Report ................................................................................................................. 22
11.3
Scheduling Conclusion ............................................................................................................... 25
12
Design Norms ............................................................................................................................. 26
12.1
Stewardship ................................................................................................................................. 26
12.2
Justice.......................................................................................................................................... 26
12.3
Trust ............................................................................................................................................ 26
13
Design Criteria, Alternatives, Research, & Decisions ................................................................ 27
13.1
Gateway OS ................................................................................................................................ 27
13.1.1
Criteria ................................................................................................................................ 27
13.1.2
Options ................................................................................................................................ 27
13.1.3
Decision Matrix................................................................................................................... 27
13.1.4
Design Decision .................................................................................................................. 27
13.2
Terminal Device to Gateway Communication Protocol ............................................................. 28
13.2.1
Criteria ................................................................................................................................ 28
13.2.2
Options ................................................................................................................................ 28
13.2.3
Decision Matrix................................................................................................................... 28
13.2.4
Design Decision .................................................................................................................. 28
13.3
Gateway Processing Hardware ................................................................................................... 29
ii
13.3.1
Criteria ................................................................................................................................ 29
13.3.2
Options ................................................................................................................................ 29
13.3.3
Decision Matrix................................................................................................................... 29
13.3.4
Design Decision .................................................................................................................. 30
13.4
Gateway Power Supply ............................................................................................................... 30
13.4.1
Criteria ................................................................................................................................ 30
13.4.2
Options ................................................................................................................................ 30
13.4.3
Decision Matrix................................................................................................................... 30
13.4.4
Design Decision .................................................................................................................. 30
13.5
Server & Gateway Integration .................................................................................................... 31
13.5.1
Criteria ................................................................................................................................ 31
13.5.2
Options ................................................................................................................................ 31
13.5.3
Decision Matrix................................................................................................................... 32
13.5.4
Design Decision .................................................................................................................. 32
13.6
Server Hosting ............................................................................................................................ 32
13.6.2
Database Structure .............................................................................................................. 33
13.6.3
Web Application Framework .............................................................................................. 34
13.6.4
Gateway to Server Messaging Protocol .............................................................................. 36
13.6.5
Web Portal Programming Language ................................................................................... 37
13.6.6
User Interface ...................................................................................................................... 38
13.7
Design Decision Summary.......................................................................................................... 39
14
System Implementation............................................................................................................... 40
14.1
Technical Diagram & Component Explanations ........................................................................ 40
14.1.1
User Interfaces Explanation ................................................................................................ 41
14.1.2
Server Explanation .............................................................................................................. 41
14.1.3
Gateway Explanation .......................................................................................................... 41
14.1.4
Devices Explanation ........................................................................................................... 41
14.2
User Interfaces ............................................................................................................................ 42
14.3
Server .......................................................................................................................................... 47
14.3.1
Hardware ............................................................................................................................. 47
14.3.2
Software .............................................................................................................................. 47
14.4
Gateway ...................................................................................................................................... 50
Hardware ............................................................................................................................................. 50
Software .............................................................................................................................................. 50
14.5
Devices........................................................................................................................................ 52
iii
14.5.1
Thermostat .......................................................................................................................... 52
14.5.2
Outlet Adapter ..................................................................................................................... 58
15
Integration, Testing, and Debugging........................................................................................... 70
15.1
Testing Summary ........................................................................................................................ 70
15.2
Informal System Testing ............................................................................................................. 71
15.3
Informal User Interface Testing .................................................................................................. 71
15.4
Informal Server Testing .............................................................................................................. 72
15.5
Informal Gateway Testing .......................................................................................................... 73
15.6
Informal Devices Testing ............................................................................................................ 73
15.7
Informal Component Interaction Testing .................................................................................... 73
15.8
Formal Testing ............................................................................................................................ 74
16
Business Plan .............................................................................................................................. 75
16.1
Mission & Vision ........................................................................................................................ 75
16.1.1
Mission for the Company .................................................................................................... 75
16.1.2
Vision for the Company ...................................................................................................... 75
16.2
Market Survey ............................................................................................................................. 75
16.3
Market Sizes & Trends ............................................................................................................... 75
16.4
Potential Customers & Target Market ........................................................................................ 76
16.5
Competitive Strategy .................................................................................................................. 76
16.5.1
Differentiation ..................................................................................................................... 76
16.5.2
Response ............................................................................................................................. 76
16.6
SWOT Analysis .......................................................................................................................... 76
16.6.1
Strengths ............................................................................................................................. 76
16.6.2
Weaknesses ......................................................................................................................... 76
16.6.3
External Opportunities ........................................................................................................ 76
16.6.4
External Threats .................................................................................................................. 77
16.7
Cost Estimate .............................................................................................................................. 77
16.7.1
Development ....................................................................................................................... 77
16.7.2
Production ........................................................................................................................... 77
16.7.3
Break-even analysis ............................................................................................................ 79
16.7.4
Ratio Analysis ..................................................................................................................... 79
17
Conclusion .................................................................................................................................. 81
17.1
Future Tasks ................................................................................................................................ 81
17.1.1
User Interface ...................................................................................................................... 81
17.1.2
Server .................................................................................................................................. 82
iv
17.1.3
Gateway .............................................................................................................................. 83
17.1.4
Devices ................................................................................................................................ 84
17.1.5
System Level ....................................................................................................................... 85
17.1.6
System Testing .................................................................................................................... 86
17.2
Summary ..................................................................................................................................... 86
17.2.1
Lessons Learned.................................................................................................................. 86
17.2.2
Project Status ...................................................................................................................... 87
18
Appendices.................................................................................................................................. 88
19
References & Bibliography....................................................................................................... 110
v
2
Table of Figures
Figure 1. Conceptual System Diagram .............................................................................................. 10
Figure 2. Component Interaction Diagram ........................................................................................ 13
Figure 3. Team Hours by Category .................................................................................................... 23
Figure 4. Team Hours by Person........................................................................................................ 23
Figure 5. Team Hours by Category and Person ................................................................................. 24
Figure 6. Team Hours by Person and Category ................................................................................. 24
Figure 7. Team Hours by Category per Month .................................................................................. 25
Figure 8. Team Hours by Person per Month ...................................................................................... 25
Figure 9. Technical System Diagram ................................................................................................. 40
Figure 10. Welcome Page .................................................................................................................. 43
Figure 11. User Login Page ............................................................................................................... 43
Figure 12. Home Manager Page......................................................................................................... 44
Figure 13. Home Manager Page continued ........................................................................................ 44
Figure 14. Outlet Adapter Advanced Settings ................................................................................... 45
Figure 15. Outlet Adapter Monitoring Display .................................................................................. 45
Figure 16. Thermostat Advanced Settings ......................................................................................... 46
Figure 17. Thermostat Scheduling Display ........................................................................................ 46
Figure 18. HomeAlive’s Database Structure...................................................................................... 47
Figure 19. Server’s program flow from UI end to Gateway End ....................................................... 49
Figure 20. Server’s program flow from Gateway end to UI End ....................................................... 49
Figure 21. Rabbit MQ Broker and Client System Diagram ............................................................... 50
Figure 22. HomeAlive Messaging Format (bytes) ............................................................................. 51
Figure 23. Gateway Software Diagram .............................................................................................. 52
Figure 24. Thermostat Device Conceptual Diagram .......................................................................... 53
Figure 25. Thermostat Device Schematic .......................................................................................... 54
Figure 26. Thermostat Software Diagram .......................................................................................... 55
Figure 27. Thermostat Feedback Codes Snippet ................................................................................ 56
Figure 28. Thermostat Command Codes Snippet .............................................................................. 57
Figure 29. Thermostat Abbreviated State Machine ........................................................................... 57
Figure 30. Outlet Adapter Device Conceptual Diagram .................................................................... 59
Figure 31. Outlet Adapter Device Schematic..................................................................................... 62
Figure 32. Outlet Adapter Device Filter............................................................................................. 62
Figure 33. Outlet Adapter RMS to DC Calibration ........................................................................... 62
Figure 34. Outlet Adapter Device Voltage Calibration Curve ........................................................... 63
Figure 35. Outlet Adapter Device Current Calibration Curve ........................................................... 64
Figure 36. Outlet Adapter Device Photo ............................................................................................ 65
Figure 37. Outlet Adapter Software Diagram .................................................................................... 66
Figure 38. Outlet Adapter Feedback Codes Snippet .......................................................................... 67
Figure 39. Outlet Adapter Command Codes Snippet ......................................................................... 67
Figure 40. Outlet Adapter State Machine........................................................................................... 69
Figure 41. Statement of Income. ........................................................................................................ 78
Figure 42. Statement of Cash Flows .................................................................................................. 78
Figure 43. Ratio Analysis. .................................................................................................................. 79
Figure 44. Revenue Sheet – If Everything Produced In a Year Is Sold In That Year ........................ 80
Figure 45. Thermostat Device PCB Layout ....................................................................................... 88
Figure 46. Outlet Adapter PCB Layout .............................................................................................. 88
Figure 47. Break-Even Analysis ........................................................................................................ 98
Figure 48. Material Costs Sheet ......................................................................................................... 99
Figure 49. Material Costs Sheet (cont.)............................................................................................ 100
vi
Figure 50. Fixed & Variable Costs Sheet Break-Downs with Totals .............................................. 100
Figure 51. Fixed Cost of Goods Sold ............................................................................................... 101
Figure 52. Variable Cost of Goods Sold .......................................................................................... 102
Figure 53. Variable Cost of Operation ............................................................................................. 102
Figure 54. Variable Cost of Operation (cont.) ................................................................................. 103
Figure 55. Fixed Cost of Operation.................................................................................................. 104
Figure 56. Cash Flow Statement (Quarterly) Year 1 ....................................................................... 105
Figure 57. Cash Flow Statement (Quarterly) Year 2. ...................................................................... 105
Figure 58. Cash Flow Statement (Quarterly) Year 3 ....................................................................... 106
Figure 59. Cash Flow Statement (Quarterly) Revenue Explanation. ............................................... 106
Figure 60. Ratio Analysis Calculation Year 1 & 2 .......................................................................... 107
Figure 61. Ratio Analysis Calculation Year 3.................................................................................. 108
Figure 62. HomeAlive Prototype Devices ........................................................................................ 109
Figure 63. HomeAlive Prototype Thermostat ................................................................................... 109
Figure 64. HomeAlive Prototype Outlet Adapter ............................................................................. 109
vii
3
Table of Tables
Table 1. Course Instructors for Engineering 339/340 (2014-25) ......................................................... 4
Table 2. Project Milestones .................................................................................................................. 5
Table 3. Project Budget ........................................................................................................................ 6
Table 4. Honors Project Budget* ......................................................................................................... 7
Table 5. Senior Design Grand Total .................................................................................................... 7
Table 6. Functional System-Wide Requirements ................................................................................. 8
Table 7. Performance System-Wide Requirements ............................................................................. 9
Table 8. Functional User Interface Requirements .............................................................................. 14
Table 9. Performance User Interface Requirements .......................................................................... 14
Table 10. Functional Server Requirements ........................................................................................ 15
Table 11. Performance Server Requirements ..................................................................................... 15
Table 12. Functional Gateway Requirements .................................................................................... 16
Table 13. Performance Gateway Requirements ................................................................................. 16
Table 14. Functional Outlet Adapter Device Requirements .............................................................. 17
Table 15. Performance Outlet Adapter Device Requirements ........................................................... 18
Table 16. Functional Thermostat Device Requirements .................................................................... 19
Table 17. Performance Thermostat Device Requirements ................................................................. 20
Table 18. Work Breakdown Schedule Summary ............................................................................... 21
Table 19. Decision Matrix for Gateway OS ....................................................................................... 27
Table 20. Decision Matrix for Terminal Device to Gateway Communication Protocol.................... 28
Table 21. Decision Matrix for Hardware System for Gateway .......................................................... 29
Table 22. Decision Matrix for Gateway Power Supply ..................................................................... 30
Table 23. Decision Matrix for Server & Gateway Integration ........................................................... 32
Table 24. Decision Matrix for Server Hosting ................................................................................... 33
Table 25. Decision Matrix for Database Structure ............................................................................. 34
Table 26. Decision Matrix for Web Application Framework ............................................................ 36
Table 27. Decision Matrix for Web Portal Programming Language ................................................. 38
Table 28. Decision Matrix for User Interface .................................................................................... 39
Table 29. Design Alternative Selection Summary ............................................................................. 39
Table 30. HomeAlive’s Gateway and Database API Summary ......................................................... 48
Table 31. HomeAlive’s User Interface and Database API Summary ................................................ 48
Table 32. Testing Table Parameter & Their Descriptions.................................................................. 71
Table 33. Existing Competitors in the Market with Devices ............................................................. 75
Table 34. Features Comparison among Commercially Available Home Automation Systems ........ 75
Table 35. User Interface Tasks........................................................................................................... 82
Table 36. Server Tasks ....................................................................................................................... 83
Table 37. Gateway Tasks ................................................................................................................... 84
Table 38. Devices Tasks .................................................................................................................... 84
Table 39. Thermostat Tasks ............................................................................................................... 85
Table 40. Outlet Adapter Tasks ......................................................................................................... 85
Table 41. System Level Tasks ........................................................................................................... 86
Table 42. System Testing Tasks......................................................................................................... 86
Table 43. Lessons Learned Summary ................................................................................................ 87
Table 44. Whole System Testing ....................................................................................................... 89
Table 45. User Interface Testing ........................................................................................................ 90
Table 46. Server Testing .................................................................................................................... 91
Table 47. Gateway Testing ................................................................................................................ 92
Table 48. Devices Testing .................................................................................................................. 94
Table 49. Interface Testing ................................................................................................................ 97
viii
4 Abbreviations
ACL
AMQP
CSS
DIY
FTP
GUI
HTML
HTTP
JS
JSP
LED
M2M
MOM
MQTT
MVC
ORM
PAN
PCB
PHP
PPFS
RDBMS
RF
RoR
RTOS
SMTP
WAF
WBS
UI
Access Control List
Advanced Message Queuing Protocol
Cascading Style Sheets
Do It Yourself
File Transfer Protocol
Graphical User Interface
Hypertext Markup Language
Hypertext Transfer Protocol
JavaScript
JavaServer Pages
Light Emitting Diode
Machine-to-machine
Message Oriented Middleware
MQ Telemetry Transport
Model-View-Controller
Object-Relational Mapping
Personal Area Network
Printed Circuit Board
Hypertext Preprocessor
Project Proposal Feasibility Study
Relational Database Management System
Radio Frequency
Ruby on Rails
Real Time Operating System
Simple Mail Transfer Protocol
Web Application Framework
Work Breakdown Schedule
User Interface
ix
5 Introduction
5.1 Report & Project Context
The HomeAlive home automation project is being worked on for Calvin College’s engineering
senior design course. The senior design course is intended to both give its students experience working
on a yearlong project and allow them to showcase what they have learned at Calvin. The capstone project
will last from September 2014 to May 2015, and it includes everything from brainstorming project ideas
through demonstrating the functionality of a prototype system. The project’s team members consist of
four electrical and computer engineering students: Andrew Jo, Okkar Moe Myint, Hezkiel Nanda, and
Jeremy Ward.
This final design report is intended to explain the home automation project’s purpose, scope, and
design implementations. It includes topics focused on scheduling, budgeting, technical decisions and
implementation details.
5.2
Problem Statements
There are four problems and opportunities that are related to this project: house modernization
rates, device inaccessibility, productivity improvements, and home monitoring.
House modernization rates refers to the problem that homes in the modern world are not taking
advantage of new technologies. This is caused by house longevity and high renovation costs; the home
automation system prototype should show that its mass production and installation would be possible at
an affordable price.
Device inaccessibility refers to the problem that many household devices are unnecessarily
difficult to interact with; it should be possible to control any electrical device one owns from anywhere in
the world. The home automation system prototype should show that secure access to home devices is
possible from remote locations.
Productivity improvements refers to an opportunity to introduce time-saving into the daily lives
of those who would use the home automation system. Integrating household devices and allowing them
to be automatically and remotely managed can increase ease-of-life and decrease wasted time.
Home monitoring refers to the opportunity to observe and control household devices more
effectively. The home automation system should allow for greater security and reduced energy
consumption by providing homeowners with a single interface for interacting with several devices. The
system should also address this opportunity by providing automatic device control scheduling and homemode settings.
5.3
Project Definition & Objectives
The HomeAlive project is to design a home automation system that allows homeowners to
control any electrical device in their house remotely, and to build a prototype model of that system. For
example, a system user could turn off her lights from work, let a friend into his apartment while on
vacation, setup a thermostat heating schedule using her phone, or perform countless other interactions
with any household device.
This home automation system should address the following three key opportunities and
consistently emphasize the design norms of justice, stewardship, and trust. The first opportunity is that
many modern household devices are unnecessarily inaccessible; it should be possible to securely interact
with these devices from afar. This relates directly to the design norm of justice by facilitating greater
independence for those with limited mobility. The second opportunity is that an intuitive interface could
save system users significant amounts of time and increase their daily productivity. The final key
1
opportunity relates to the design norm of stewardship and the enhancing of user’s control over the
resources used by their homes. By allowing actions such as thermostat scheduling and power
consumption monitoring, especially with the inclusion of automatic limits and real-time notifications, this
home automation system could help to reduce household energy costs. Furthermore, the design norm of
trust is critically involved in home automation systems because homeowners must be able to rely on the
system to behave both robustly and securely.
In order to address these opportunities, the HomeAlive team has designed a home automation
system that includes four components: devices, gateways, a server, and user interfaces. Devices are the
many electric household objects that can be monitored and controlled. There is a single gateway per
household; it is a small unit responsible for converting messages between radio signals and internet data
packets. The server, which is shared amongst all households, stores all of the HomeAlive data and
performs most of the system’s computational processing. Finally, the user interfaces include a website
and mobile phone applications. It is their responsibility to offer an intuitive and seamless portal for
interaction with the other parts of the system. Additional details on the four components and their
interaction can be found below.
5.4
Scope & Constraints
This home automation prototype is meant to demonstrate the proper functionality and scalability
of the system, not to include every desired system feature. There are countless features and devices that
the system could eventually incorporate, but in order to maintain proper project scope, only a single user
interface and two sample devices for two households have been designed. Determining an appropriate
scope for this project is perhaps the biggest challenge that was faced; however, the prototype includes:
four sample devices, two gateways, the server, a web portal user interface, and the communication
structures between them.
These components were selected to demonstrate appropriate system functionality because they
make up the communication network between users and the devices that are being controlled. Once this
structure is in place, additional devices, features, and user interface options can be added to the prototype
in order to continue development of the home automation system. Features considered out of scope for
this prototype due to a lack of financial and temporal resources include: registration of new households,
initialization of newly-purchased devices, mobile phone application user interfaces, and high-level
security.
2
6
Acknowledgments
There are several organizations and individuals that influenced this project and deserve both
credit and thanks. First, the Calvin College engineering department for its administrative and financial
contributions to the project. The department provided primary funding, quality workspaces, and
necessary equipment for the project; it also organized project showcase and set the final prototype due
date. Second, SpinDance Inc. for generously providing David van Geest as an industrial mentor. Also,
David himself for offering guidance on several technical issues and helping to clarify appropriate project
scope. Next, Eric Walstra for serving as an industrial consultant and providing assistance with technical
issues and project risk assessment. Additionally, Professor Mark Michmerhuizen for his consistent
feedback on schedule management and project deliverables. Also, Professors Brouwer, Kim,
VanAntwerp, Wunder, and Nielsen for their varied guidance. Finally, Chuck Holwerda and Bob
DeKraker for their help in securing supplies. Without these organizations and individuals, this project
would not have been possible.
3
7 Project Management
7.1 Team Organization
7.1.1 Team Advisor
Professor Mark Michmerhuizen is an electrical and computer engineering professor at Calvin
College and served as the project’s faculty advisor. His role was to provide guidance and evaluate project
deliverables. His signature was also required on all project purchases.
7.1.2
Course Instructors at Calvin College
The followings served as course instructors for ENGR-339 and ENGR-340 during this project.
Table 1. Course Instructors for Engineering 339/340 (2014-25)
Name
Mark Michmerhuizen
Ned Nielsen
Jeremy VanAntwerp
David Wunder
Title
Electrical Engineering Professor
Mechanical Engineering Professor
Chemical Engineering Professor
Civil and Environmental Engineering Professor
7.1.3
Industrial Consultants
David van Geest is a Calvin College graduate from 2009. He works at SpinDance Inc, a
company that specializes in the development of technologies in the “internet of things” field and is based
in Holland, Michigan. David graciously offered his time and expertise while providing feedback on
system architecture details.
Eric Walstra works in Zeeland, Michigan at Gentex Corporation, a company that mainly
specializes in developing electronic products in the automotive and aerospace industries. Eric met with
the HomeAlive team twice and gave provided insights regarding project scope, task scheduling, risk
assessment, design testing, and project presentations.
7.1.4
Team Members
The HomeAlive team consisted of four members: Andrew Jo, Okkar Moe Myint, Hezkiel Nanda,
and Jeremy Ward. All four team members are electrical and computer engineering students at Calvin
College and expecting to graduate in May 2015.
7.2
Team Meetings
There were scheduled team meetings every Friday from 1:00 PM to 1:30 PM. These weekly
meetings gave the team a chance to go over the progress of the last week and to schedule new
assignments as needed. This meeting helped to hold the team members accountable and ensured the
project’s continued progress. In addition to these regular meetings, numerous other meetings were
scheduled at varying times as determined by availability and requirement.
7.3
Team Documentation & Task Organization
All of the team documents, including research notes, reports, diagrams, presentations, schedules,
budgets, and test results, are kept on a shared Microsoft OneDrive account. These documents are
accessible by all team members, allowing collaborative work to take place unhindered.
At first, the team assigned tasks using an online scheduling tool called Asana. Asana allows
reminders to be sent at preset times, and it allows team members to view each other’s progress on tasks.
This tool has proven itself very effective and useful in task organization, time management, and
4
adherence to schedule. Later, meeting frequencies increased to at least one per day and progress was
evident without using the Asana tool.
7.4
Schedule
In order to achieve its goals and make progress towards its milestones, HomeAlive broke down
their workload into manageable pieces and assigned weekly tasks to every team member. Progress on
tasks was reviewed every Friday, and the schedule was updated at this time. Large project milestones
were tracked using Microsoft Project and include items such as writing the PPFS and completing the
website. Weekly tasks were tracked using Asana and include shorter items that made progress towards
project milestones, for example adding photographs to the website. During the second semester,
HomeAlive decided not to use Asana because simple Word documents proved faster and more efficient
for dividing tasks. The primary reason that this become more effective than Asana was the dramatic rise
in meeting frequency; daily discussions about tasks reduced the need for group progress reports. This
approach to scheduling was implemented as described in the task specifications section below.
7.4.1
Milestones
This project had several notable milestones in its schedule as shown in Table 2. These were both
design process milestones, with estimated completion dates, and deliverable content milestones, with
assigned due dates.
Table 2. Project Milestones
Milestone
Oral Presentation 1
PPFS Rough Draft
Oral Presentation 2
PPFS Final Draft
Oral Presentation 3
Prototype
CEAC Review
2nd Prototype
Faculty Review
Oral Presentation 4
Testing
Project Demonstration
Final Website Update
Final Draft Senior Design Report
Date
10/17/2014
11/10/2014
12/3/2014
12/8/2014
3/2/2015
4/01/2015
4/24/2015
4/30/2015
4/30/2015
5/5/2015
5/8/2015
5/9/2015
5/11/2015
5/13/2015
7.4.2
Schedule Management
The scheduling approach for this project involved a master WBS, task lists, estimations, and
reevaluations. Originally, a master WBS was generated which included large scale tasks. It incorporated
approximate time estimates and due dates. Since then, the process of listing tasks, estimating task
lengths, and then reevaluating previous estimations has been repeated each week. First, task lists were
generated, which included all relevant small and large scale tasks. Second, each of these tasks was given
an updated time-required estimation and goal due date. Third, estimations from the past scheduling
iteration were examined for accuracy in order to improve the scheduling estimation process.
Reevaluation also helped identify tasks that were behind schedule.
5
A HomeAlive member took on the role of schedule maintenance and also reminded other team
members to log their time in the team’s time tracking document. This time tracking tool was created by
the HomeAlive team in order to provide efficient and easy access for time logging throughout the year.
7.5
Budget Management
HomeAlive originally assigned Hezkiel Nanda to maintain its project budget. Later this role was
reassigned to Jeremy Ward because his tasks developing devices required frequent parts purchasing.
Jeremy then oversaw that each purchase was documented in the team’s budgeting information.
7.5.1
Sources of Funding
HomeAlive had one primary source of funding, the Calvin College engineering department’s
senior design fund. Calvin generously provided $531.12 to fund the HomeAlive project as seen in Table
3. Furthermore, they provided electrical equipment and components such as resistors, LEDs, transistors,
cables, and connectors. There was one secondary source of funding, the Calvin College engineering
department honors program. This budget was used in order to purchase hardware components amounting
to $207.35 as seen in Table 4. Two HomeAlive team members did their honors projects in order to
support the HomeAlive prototype. With these sources of funding, HomeAlive had sufficient financial
support for the prototype design and implementation.
7.5.2
Budget Details
The HomeAlive project cost totaled $738.47, including both funding sources, and the purchasing
breakdown can be seen in Table 3 - 5 below. It is important to note that the largest costs were purchasing
the commercial thermostats, XBee Pro modules, and AD736 ICs.
Table 3. Project Budget
Component
Xbee Modules S1-1mW [1]
Xbee Modules S1-60mW [2]
Xbee USB Dongle [16]
Xbee USB Dongle [16]
Xbee Uno Shield [17]
Xbee Uno Shield [17]
Arduino Uno [18]
Xbee Nano Shield [19]
Arduino Nano [20]
Arduino Nano [20]
Arduino Stackable Header 8pin [21]
9V Battery Connector [22]
Thermostat [23]
AD736 RMS to DC [24]
DC Power Inverter [25]
Relay [26]
Current Transducer [27]
AD628ARZ-R7CT [28]
AD8436ARQZ [29]
Unit Price
Quantity
$24.22
2
$37.95
3
$29.95
1
$24.95
1
$18.94
1
$14.98
1
$28.90
1
$9.90
2
$14.99
1
$14.80
1
$0.45
10
$1.88
1
$50.77
1
$10.31
9
$3.03
4
$4.48
2
$4.82
3
$5.23
1
$10.81
1
Total
Line Total
$48.44
$113.85
$29.95
$24.95
$18.94
$14.98
$28.90
$19.80
$14.99
$14.80
$4.50
$1.88
$50.77
$92.79
$12.12
$8.96
$14.46
$5.23
$10.81
$531.12
6
Table 4. Honors Project Budget*
Component
Kill-a-Watt
Adafruit Tweet-a-Watt
Thermostat
Arduino Uno
Total
Line Total
$28.22
$87.25
$52.98
$38.90
$207.35
*Each Component Quantity Equals One.
Table 5. Senior Design Grand Total
Project Budget
Honors Project Budget
Grand Total
$ 531.12
$ 207.35
$ 738.47
7
8 System Requirements
8.1 Requirements Categories
Requirements for the HomeAlive system can be classified as either functional or performance
requirements; they may also apply to either a specific component or the entire system. Functional
requirements refer to the capability to accomplish a certain task, for example the system must be able to
allow remote control of household devices. Performance requirements refer to the quality with which a
task is accomplished, for example the system must exhibit less than a two second delay between sending
commands and seeing their results. System-wide requirements are discussed in this section, and
component-specific requirements are discussed in greater detail below.
8.1.1
Functional
The functional requirements of the system as a whole are laid out in Table 6. They focus on the
system’s ability to accomplish the task of remotely monitoring and controlling household devices.
Table 6. Functional System-Wide Requirements
Requirement
Allows remote control of prototype devices
Allows multiple distinct devices
Allows multiple distinct households
Scalable to multiple distinct user interfaces
Scalable to 256 devices per household
Scalable to numerous households
Description
The main task of the system, to allow remote
control of household devices using a computer,
phone, or tablet
The system must support multiple devices per
household without any interference between them,
otherwise it is not useful
The system must support multiple different
households without any interference between
them, otherwise it is only useful for one home
The system must be set up in such a way that
adding additional user interfaces is possible
The system must be set up in such a way that
adding up to 256 devices per household is
possible
The system must be set up in such a way that
adding very large numbers of additional
households is possible
8
8.1.2
Performance
The performance requirements of the system as a whole are laid out in Table 7. They focus on
the system’s ability to accomplish the task of remotely monitoring and controlling household devices in a
way that is efficient and high-quality.
Table 7. Performance System-Wide Requirements
Requirement
End-to-end Delay Up (single)
End-to-end Delay Up (flood)
End-to-end Delay Down (single)
End-to-end Delay Down (flood)
Unexpected Component Shutdown: Gateway
Unexpected Component Shutdown: Devices
Unexpected Component Shutdown: Server
Description
The system must exhibit a device to interface
delay of less than 2 seconds for a single message
The system must exhibit a device to interface
delay of less than 3 seconds for a flood of
messages (greater than 2 messages per second for
10 seconds)
The system must exhibit an interface to device
delay of less than 2 seconds for a single message
The system must exhibit an interface to device
delay of less than 3 seconds for a flood of
messages (greater than 2 messages per second for
10 seconds)
The system must able to recover from an
unexpected shutdown of the gateway with
minimal lost messages and no extra user
interaction (besides restoring power to the
gateway)
The system must be able to recover from an
unexpected shutdown of any device with minimal
lost messages and no extra user interaction
(besides restoring power to the device)
The system must be able to recover from an
unexpected shutdown of the server with minimal
lost messages and no extra user interaction
(besides restoring power to server)
9
9 System Architecture
9.1 Conceptual Diagram
This home automation system has been designed modularly as several components according to
both concrete and abstract distinctions between different parts of the system. At its broadest level, system
inputs are the user inputs: device control and system control. Broad system outputs include device
information and system information, which are displayed to users in order to allow them to make
informed control decisions. This can be seen in Figure 1, which also highlights the modular distinctions
described below.
(A)
(B)
Gateways
Server
User Interfaces
Devices
Figure 1. Conceptual System Diagram
The system shown conceptually in Figure 1 is divided into components according to the tasks that
each is required to perform. Components include: devices, gateways, a server, and user interfaces.
Devices are the many electric household objects that can be monitored and controlled. There is a single
gateway per household; it is a small unit responsible for converting messages between radio signals and
internet data packets. The server, which is shared amongst all households, stores all of the HomeAlive
data and performs most of the system’s computational processing. Finally, the user interfaces include a
website and mobile phone applications. It is their responsibility to offer an intuitive and seamless portal
10
for interaction with the other parts of the system. Additional details on the four components and their
interactions can be found below.
9.2 Component Summaries
9.2.1 User Interfaces Summary
HomeAlive user interfaces are responsible for providing homeowners with seamless and intuitive
methods to control and monitor their household devices. In order to do this, they must present available
information as it updates in the server’s database, and they must submit action requests to the server.
Additional information on inter-component communication can be seen below.
The system prototype demonstrates a website user interface, hosted by the same machine as the
server component. This website makes use of HTML, PHP scripts, and JS scripts in order to interact with
the database and provide a quality user experience. Additionally, it incorporates a login system in order
to match homeowners with their own devices.
9.2.2
Server Summary
The HomeAlive server performs the bulk of the system’s computational processing as it
maintains and manages a database. This database includes information on each device in every
household, and it offers user interfaces a channel to submit action requests. Management of the database
includes handling these action requests, and also device status updates, by appropriately adjusting
database values and generating new system messages.
The prototype server exists on a dedicated desktop computer; it uses a MySQL database for
information storage and PHP scripts for database management. These PHP scripts use multi-processing
techniques to ensure minimal delays in both server-gateway and server-user interface communication.
Server communication with gateway units is done using the internet-based Advanced Message Queueing
Protocol (AMQP); more information on inter-component communication can be found below.
9.2.3
Gateways Summary
HomeAlive gateways connect a household’s devices to the server by converting messages
between internet packets and XBee radio signals. There should be just one gateway per household, and it
should require little to no user interaction or maintenance. Without a gateway component in the
HomeAlive system, each controllable device would require an internet connection. Using gateways is
preferable for simplifying devices and isolating the HomeAlive system capability from home internet
network strengths. A gateway communicates wirelessly with all of its household’s devices and with the
server using an internet connection. Additional information on inter-component communication can be
found below.
The prototype gateway consists of a single-board Raspberry Pi computer and XBee radio chip,
which uses a serial USB dongle. The gateway runs using a multithreaded Java program that both converts
AMQP messages it receives from the server to XBee radio signals and converts XBee radio signals it
receives from its household’s devices to AMQP messages.
9.2.4
Devices Summary
HomeAlive devices are the electrical objects being monitored and controlled by home automation
system. There is no limit to the number of different possible devices; anything electric and in range of the
system XBee network could become a device. Each device can be broken up into two smaller conceptual
parts, the object portion and the control portion. The object portion is the actual thermostat, coffee maker,
door lock, or other electric machine. The control portion consists of the XBee radio and a
microcontroller.
11
The prototype system showcases two device types, a programmable thermostat and an outlet
adapter. The object portion of the first device is a purchased Honeywell programmable thermostat. Its
control portion consists of an Arduino microcontroller, XBee radio, and control circuit. The Arduino uses
the XBee radio to communicate with the rest of the HomeAlive system, and it is programmed to press
buttons on the thermostat object. The thermostat control circuit allows the Arduino to press the
thermostat buttons electronically and to read physical button presses as electronic signals. The object
portion of the outlet adapter is a circuit that is meant to be inserted between any standard American outlet
and the item plugged into it. This circuit is capable of toggling power to the plugged-in item, and it is
capable of measuring the power being used by that item. The control portion of the outlet adapter also
includes an Arduino microcontroller and XBee radio. These are used to communicate with the rest of the
HomeAlive system and to report the power measurement results.
9.2.5
Component Interactions Summary
The HomeAlive system’s devices, gateways, server, and user interfaces interact as a bidirectional
message-passing chain. In order to present homeowners with an interface that allows the monitoring and
control of their devices via an internet connection, it is first necessary to establish a communication link
between the user interfaces and devices.
This is done by granting the user interfaces web-access to the database storage on the server. The
server manages its database and sends appropriate messages to and from the gateways using AMQP. The
gateways are responsible for converting the messages that they receive between AMQP and XBee, and
then resending them in the new format. The XBee radio transceiver chips utilize the DigiMesh® protocol
and operate at 2.4GHz. Finally, each device uses an Arduino single-board computer for device control
and monitoring; the Arduino uses an XBee radio chip to communicate with its gateway. The chain of
communication can be seen in Figure 2 below.
12
Figure 2. Component Interaction Diagram
This diagram shows the HomeAlive system component interaction chain in a single direction; the
opposing direction is identical with reversed communication channels. The diagram displays two user
interfaces, the single server, and two households (each consisting of a gateway and set of devices).
13
10 Component Requirements
10.1 User Interface Requirements
10.1.1 Functional
Table 8 shows the functional requirements for the user interface. Most of the functional
requirements emphasize user-oriented viewpoints instead of a programmer’s perspective. The user
interface requirements focus on its ability to operate intuitively and be easy-to-use for the typical user.
Table 8. Functional User Interface Requirements
Requirement
Sends input forms
Hides unselected features
Receives database data
Follows the original theme view
Alerts user for changes
Accessible worldwide
Description
The user interface must have a form to send
commands. It has to be accessible across multiple
operating systems
The user interface must hide unselected input
forms when they cannot be accessed correctly
The user interface must connect to the API server
to receive database information. Furthermore, it
must update every 2 seconds without interfering
with user inputs
The user interface must follow the general shapes,
placements, and colors of the original theme to
make it easier to control by users
The user interface must alert users after
commands are sent and updated data is received
The user interface must be accessible by
computers, tablets, and mobile phones from
anywhere in the world with an internet connection
10.1.2 Performance
Table 9 explains the performance requirements of the user interface. These requirements
emphasize the efficiency of the user experience and its ability run continuously for long periods of time.
Table 9. Performance User Interface Requirements
Requirement
User Interface Message Flood
User Interface Continuous Running
User Interface Basic Security
Knowledgeable User Testing (UI)
Unknowledgeable User Testing (UI)
Description
The user interface must be able receive message
from the server’s database at a rate of 500 ms per
message
The user interface must not decrease in
performance after long period of time
The user interface must have basic security
features in place, for example logins
The user interface must exhibit no unexpected
behavior (bugs) while being used by individuals
familiar with the HomeAlive system
The user interface must exhibit no unexpected
behavior (bugs) while being used by individuals
unfamiliar with the HomeAlive system
14
10.2 Server Requirements
10.2.1 Functional
The functional requirements of the server component are laid out in Table 10. They focus on the
server’s ability to communicate with the user interface and gateway, and also on its ability to provide the
necessary communication and data storage.
Table 10. Functional Server Requirements
Requirement
Handle status request from User Interface
Handle status request from the Gateway
Handle request to register commands in the
database
Handle request to register status of the devices in
the database
Host an AMQP server
Host a database
Database structure
Message Integrity Maintained
Send message to the gateway
Receive message from the gateway
Description
The server must have a way to provide many
status data required for display in user interface
end.
The server must have a way to provide many
status data such as time and date required for
changing the device settings.
The server must be able to store the commands
sent from user interface in the database.
The server must be able to store the status of the
devices relayed from the gateway in the database.
The server must be able to host an AMQP broker
and listen on its port.
The server must be able to host a MySQL
database and listen on its port.
The MySQL database setup in server must have a
logical relational database structure.
The server must not modify any messages in any
manner and keep multiple messages distinct from
one another.
The server must send users’ commands to the
gateway after receiving them.
The server must be able to receive message
including status request and request to register
commands in a real time manner.
10.2.2 Performance
The performance requirements of the server component are laid out in Table 11. They focus on
the server’s ability to handle requests and communicate with both the user interface and gateway in a
timely manner and to store data in accurately.
Table 11. Performance Server Requirements
Requirement
Server Processing Speed
Server Operation Environment
Server Operation Time
Server Bad Message Handling
Description
The server must be able to handle multiple
messages per second without slowing down.
The server must be able operate stably in a
relatively temperature regulated room. The server
must be able to withstand dust accumulated in the
room as well.
The server must be able to operate constantly with
minimal downtime for maintenance.
The server must be able to discard bad messages
and continue operation without any downtime.
15
10.3 Gateway Requirements
10.3.1 Functional
The functional requirements of the gateway component are laid out in Table 12. They focus on
the gateway’s ability to accomplish the task of converting messages between the AMQP and DigiMesh
protocols.
Table 12. Functional Gateway Requirements
Requirement
Converts messages from AMQP to DigiMesh
Converts messages from DigiMesh to AMQP
Receives and sends DigiMesh messages
Receives and sends AMQP messages
Message Integrity Maintained
Description
The gateway must be able to convert a message
from the internet-based AMQP protocol to the RF
DigiMesh protocol.
The gateway must be able to convert a message
from the RF DigiMesh protocol to the internetbased AMQP protocol.
The gateway must be able to both send and
receive DigiMesh messages using an RF chip and
serial connection.
The gateway must be able to both send and
receive AMQP messages using a preconfigured
RabbitMQ broker.
The gateway must not change any messages in
any way and it should be able to keep multiple
messages distinct from one another.
10.3.2 Performance
The performance requirements of the gateway component are laid out in Table 13. They focus on
the gateway’s ability to accomplish the task of converting messages between the AMQP and DigiMesh
protocols in an efficient and high-quality way.
Table 13. Performance Gateway Requirements
Requirement
Gateway Processing Speed Up
Gateway Processing Speed Down
Gateway Temperature of Operation
Gateway Heat Dissipation
Gateway Message Flooding Up
Gateway Message Flooding Down
Gateway Bad Message handling
Description
The gateway must send a converted AMQP message within
500 ms of receiving the original DigiMesh message
The gateway must send a converted DigiMesh message
within 500 ms of receiving the original AMQP message
The gateway must operate stably at typical room
temperatures
The gateway must be able to dissipate heat fast enough to
continue running indefinitely at room temperatures
The gateway must be able to continue performing its role
when subjected to message flooding (greater than 2
messages per second for 10 seconds) coming from devices
The gateway must be able to continue performing its role
when subjected to message flooding (greater than 2
messages per second for 10 seconds) coming from the
server
The gateway must be able to recognize and discard or
repair bad messages without ceasing to function as it is
intended
16
10.4 Device Requirements
10.4.1 Outlet Adapter
10.4.1.1 Functional
The functional requirements of the outlet adapter are laid out in Table 14. They focus on the
outlet adapter’s ability to be controlled and send information wirelessly.
Table 14. Functional Outlet Adapter Device Requirements
Requirement
Description
Measure Power (VA)
The outlet adapter must compute the power being
used by a plugged in appliance.
Turn On & Off
The outlet adapter must be able to toggle its
output socket between the on and off states.
The outlet adapter must store the on/off status in
Remember previous settings & calibration non-volatile memory to remember the setting and
calibrations upon power loss.
Bidirectional Communication
The outlet adapter must receive commands from
the user and also be able to send back status
information.
Wireless Communication
The outlet adapter must use wireless
communication to accomplish the message
sending and receiving.
Safe to use
The outlet adapter must be safe to use and comply
with electrical safety standards.
Dimensions
The dimensions of the outlet adapter must be
reasonable for everyday use, smaller is better.
The adapter must dimensions resulting in a lesser
volume than 5x2x2 cubic inches.
17
10.4.1.2 Performance
The functional requirements of the outlet adapter are laid out in Table 15. They focus on the
outlet adapter’s ability to be controlled and send information wirelessly, while maintaining adequate
precision, accuracy, safety, and response times.
Table 15. Performance Outlet Adapter Device Requirements
Requirement
Description
Outlet Adapter Power Rating
The outlet adapter must operate in the range of
0 A – 15 A and 0 – 130 V. Thus the power
range is roughly 0W – 2000 W.
Outlet Adapter Power Precision
The outlet adapter should measure to the nearest
1 W.
Outlet Adapter Power Accuracy
The error on measuring the power should be
W.
Outlet Adapter Response Time
Once the command to toggle the on/off state is
received, the appropriate action should be taken
within 250 ms.
Outlet Adapter Operation Environment
The outlet adapter must be able to operate
stably at typical room temperatures for long
periods of time.
Outlet Adapter Heat Dissipation
The outlet adapter must be able to dissipate heat
fast enough to allow 15 A of current at 120
Vrms to be sustained indefinitely. The Arduino
must also dissipate heat fast enough to continue
operation at room temperature indefinitely.
18
10.4.2 Thermostat
10.4.2.1 Functional
The functional requirements of the thermostat are laid out in Table 16. They focus on the
thermostat’s ability to be controlled and send information wirelessly.
Table 16. Functional Thermostat Device Requirements
Requirement
Physical Button Pressing
Description
Pressing the buttons on the thermostat must
have the same effect as using the user interface.
The Arduino must read manual presses and
synchronize this change on its state machine.
Electrical Button Pressing
The Arduino must be capable of simulating a
manual button press by electrically pressing the
buttons.
Remember previous settings &
calibration
The thermostat must store all of its state
information in non-volatile memory to
remember its settings upon power loss.
Bidirectional Communication
The thermostat must receive commands from
the user interface and also be able to send back
status information.
Wireless Communication
The thermostat must use wireless
communication to accomplish message sending
and receiving.
Safe to use
The thermostat must be safe to use and comply
with electrical safety standards.
19
10.4.2.2 Performance
The functional requirements of the thermostat are laid out in Table 17. They focus on the
thermostat’s ability to be controlled and send information wirelessly, while maintaining adequate
response times.
Table 17. Performance Thermostat Device Requirements
Requirement
Description
Thermostat Operation Environment
The thermostat must be able to operate stably at
typical room temperatures.
Thermostat Heat Dissipation
The Arduino must dissipate heat fast enough to
continue operating at room temperature
indefinitely.
Thermostat Processing Speed
The thermostat must process the incoming
messages and take appropriate action within
500 ms of receiving it.
Thermostat Action Speed
The thermostat should minimize the amount of
buttons being pressed to accomplish every
available action.
20
11 Task Specifications and Schedule
11.1 Work Breakdown Summary
The HomeAlive project was divided into several broad tasks, each with many subtasks, and
intentionally scheduled. These tasks included: determining scope, reports and communication,
developing each component, and system testing. The schedule was determined largely by project due
dates, but it all also accounted for peripheral conditions such as weeks with heavy workloads and team
member vacations. A general schedule and tasks list can be seen in Table 18.
Table 18. Work Breakdown Schedule Summary
Tasks & Milestones
Due Date
Due Date Type
Date Completed
Project Choice
9/10/14
Assigned
9/8/14
Team Name & Facilities
Needs
9/15/14
Assigned
9/13/14
Presentation 1
10/17/14
Assigned
10/17/14
Several
Adjustments
Repeating
9/15/14, 11/10/14,
4/11/15
Presentation 2
12/3/14
Assigned
12/3/14
PPFS
12/8/14
Assigned
12/8/14
Outlet Adapter
(early design)
12/8/14
Milestone
12/5/14
Thermostat Device
(early design)
12/8/14
Milestone
12/5/14
Gateway
12/5/14
Milestone
12/2/14
User Interface
(early design)
2/15/15
Milestone
2/15/15
Server & Database
(early design)
2/15/15
Milestone
2/15/15
Presentation 3
3/2/15
Assigned
3/2/15
Gateway Complete
3/5/15
Milestone
3/5/15
Thermostat Design
(except debug)
3/29/15
Milestone
3/29/15
User Interface
(except debug)
3/29/15
Milestone
3/29/15
Scope Definition
21
Server
(except debug)
3/29/15
Milestone
3/29/15
Initial Prototype Testing
4/1/15
Milestone
4/11/15 (late)
Outlet Adapter Design
(except debug)
4/21/15
Milestone
4/21/15
CEAC Review
4/24/15
Assigned
4/24/15
PCB Fabrication
4/27/15
Milestone
5/7/15 (late)
Prototype Functional
Testing
4/29/15
Milestone
5/7/15 (late)
Faculty Review
4/30/15
Assigned
4/30/15
Prototype Completion
5/1/15
Milestone
5/8/15 (late)
Presentation 4
5/4/15
Assigned
5/4/15
Prototype Performance
Testing
5/6/15
Milestone
incomplete
Prototype Demonstration
5/9/15
Assigned
5/9/15
Final Report
5/13/15
Assigned
5/13/15
* Many milestone due dates and completion dates are estimated
11.2 Time Tracking Report
It is also useful to view the HomeAlive project tasks and schedule from the perspective of hours
spent. The amount of time that the team spent was logged over the course of the project, and this data can
be viewed on a per-task, per-person, and per-month basis in the figures below. The timing information in
this section reflects project hours from 8/18/2014 to 5/13/2015. The total number of hours logged by the
team was 1875 hours. As seen in Figures 3 to 8, the majority of the team’s time was spent designing and
implementing the four major components: devices, server, gateways, and user interface. It is important to
note that the devices section required by far the greatest amount of time, partly because there were two
devices included in this category. Another section requiring a large portion of the hours spent is reports
and communication, which encompasses all speeches, reviews, and senior design night preparations.
Additionally, the hours spent each month on the project have been increasing steadily since August. The
hours logged by each time member have also been separated, and the graphs below show how each team
member had varying contributions for each month of the project. The final division of hours per team
member was approximately evenly distributed. More detailed hour tracking graphics are available on the
project website.
22
Figure 3. Team Hours by Category
Figure 4. Team Hours by Person
23
Figure 5. Team Hours by Category and Person
Figure 6. Team Hours by Person and Category
24
Figure 7. Team Hours by Category per Month
Figure 8. Team Hours by Person per Month
11.3 Scheduling Conclusion
The HomeAlive project took 1875 person-hours for four team members over the course of two
semesters. This time was allotted as roughly 101 person-hours for project scope discussions, 462 for
presentations and reports, 1077 for design and prototype development, 88 for prototype testing, and 147
for miscellaneous other tasks. A reactive scheduling approach was used to ensure the project was
completed before 5/14/15. However, it would have been better to spend greater amounts of time doing
preliminary system design early in first semester.
25
12 Design Norms
Design norms are topics that are meant to facilitate the application of core Christian beliefs into
the engineering design process. They provide guidelines for thinking about engineering in the holistic
context of life, as opposed to just the product being designed. The design norms that are most important
to this project were stewardship, justice, and trust. Together, they influenced the development of the
home automation system prototype by encouraging the careful consideration of how the system interacts
with people during each stage of its product life-cycle.
12.1 Stewardship
Stewardship is defined as conserving finite economic, human, and environmental resources while
preserving character and minimizing environmental degradation [6]. This home automation system
adhered to the design norm of stewardship in three ways. First, economic resources will not be
squandered in either the design or production of the system; care will be taken to use the available project
budget as effectively as possible. Second, the system was intended to conserve human resources by
increasing its consumers’ ease-of-life and improving the security of their homes. Finally, the system
included features that allow the monitoring and reduction of power consumption in consumers’ homes. In
this way, the system contributed to the conversation of environmental resources and helped to minimize
degradation.
12.2 Justice
Justice is defined as respecting the rights of all persons and considering all stake-holders, not just
users [6]. This home automation system adhered to the design norm of justice in two ways. First, the
system was designed to allow increased access to devices for people with limited mobility. By making
the control of home devices possible through a smartphone application, it was possible for many users to
achieve things alone that they previously needed help with. For example, a person who is paralyzed from
the waist down and living in a multilevel, non-handicap-accessible home, may now easily control devices
from any floor.
12.3 Trust
Trust is defined as ensuring that the design is trustworthy, dependable, reliable, and avoids
conflicts of interests [6]. This home automation system adhered to the design norm of trust in three ways.
First, the system functions entirely as intended and was not susceptible to inconsistent performance. This
is especially important for a home automation system because users quickly come to rely on it and a lot of
time is wasted doing things the old way if the system fails. Second, the issue of security was considered
throughout the design of the system. Security was important because unintended access to the system
could result in theft or other undesirable circumstances for the system’s owner. Finally, all conflicts of
interest by the people involved in the design of this system were avoided. No one participating in the
project has stake in any competing organizations or relationships with anyone in a contradictory
circumstance.
26
13 Design Criteria, Alternatives, Research, & Decisions
13.1 Gateway OS
13.1.1 Criteria
The operating system for the gateway should support real time operations in order to provide
seamless experiences to users. The operating system should also perform well under low hardware
configurations (e.g., 512 MB of RAM). In addition, it should support multiple messaging protocols. This
encourages compatibility and reliability within the design, which relates to the design norm of trust. For
the gateway OS, three different operating system were reviewed and evaluated as follows.
13.1.2 Options
13.1.2.1 UNIX variants – Raspbian
Raspbian is a Debian Wheezy based operating system with a Unix-like interface. It is developed
by the makers of Raspberry Pis. This alternative provides a familiar developing environment. In
addition, it is optimized to run smoothly under low hardware configurations. Raspbian has a large
number of active developers and is proven to run reliably on Raspberry Pi.
13.1.2.2 Windows - Windows Embedded
Windows Embedded is an embedded operating system developed for terminal devices with low
system configurations, such as small amount of memory. It allows real time operation and device
connectivity support is also provided. Developers in the home automation industry typically avoid the
windows platform because of its proprietary licenses status and other administrative difficulties.
13.1.2.3 Real Time Operating Systems – TinyOS
TinyOS is an RTOS written in nesC. It is developed jointly by the University of California, Intel
Corporation, and Crossbow Technology. TinyOS provides fairly simple interface for developers, and has
a rich support for many devices. This alternative is also well documented and well known in the RTOS
field.
13.1.3 Decision Matrix
Table 19. Decision Matrix for Gateway OS
Weight
Unix Variants
Window
Embedded
TinyOS
Reliability (RTOS)
30%
10
8
10
System Resource Requirements
25%
10
8
10
Reliability (Device Connectivity)
25%
10
5
10
Price
5%
10
10
10
Raspberry Pi Compatibility
15%
10
3
7
Totals:
100%
10
6.6
9.6
Criteria
13.1.4 Design Decision
As depicted in Table 19, Raspbian appeared to best satisfy the weighted criteria for a gateway
OS. However, real-time operating systems were evaluated as similarly suitable and the chosen operating
system must also be compatible with the gateway processor, alternatives for which are examined below.
The Raspberry Pi processor choice influenced the usage of Raspbian, a Unix variant, for the gateway OS.
27
13.2 Terminal Device to Gateway Communication Protocol
13.2.1 Criteria
The communication protocol should have low latency times and low power consumption, in
accordance with the design norm of stewardship. In addition, the protocol should include security
measures in order to prevent any intrusion of the system. The communication protocol should also be
widely used in order to ensure reliability and continuous support in the future.
13.2.2 Options
13.2.2.1 ZigBee
ZigBee is a commonly used communication protocol in the home automation industry. It
provides low latency times and has low power consumption. The protocol itself has a security
architecture built in to it. However, increasing numbers of developers in home automation industry are
abandoning ZigBee due to its non-free, non-open source licensing status. ZigBee is available on XBee
Series 2 chips.
13.2.2.2 DigiMesh
DigiMesh is essentially identical to the ZigBee protocol; however it is available on XBee Series 1
chips as well.
13.2.2.3 Z-Wave
Z-Wave is a widely used communication protocol in home automation industry. It has low
latency times, low power consumption, and a decent security architecture. However, Z-wave chips are
manufactured only by the company Sigma Designs. Some developers avoid supporting the Z-Wave chip
protocol because of the company’s monopolistic nature.
13.2.2.4 Bluetooth
Bluetooth is a widely used communication protocol in home automation industry. It is secure
with low latency times and average power consumption. Bluetooth is widely used and supported by
numerous developers and products.
13.2.3 Decision Matrix
Table 20. Decision Matrix for Terminal Device to Gateway Communication Protocol
Criteria
Weight
ZigBee &
DigiMesh
Z-Wave
Bluetooth
Reliability (Low Latency Time)
Stewardship (Low Power Consumption)
Trust (security)
Trust (Devoted Developers)
Range
Totals:
25%
5%
19%
11%
40%
100%
10
10
10
5
8
13.15
10
10
8
7
8
8.49
10
5
8
7
6
9.69
13.2.4 Design Decision
As depicted in Table 20, ZigBee and DigiMesh appeared to best satisfy the weighted criteria for a
device to gateway communication protocol. The team decided to use DigiMesh, a ZigBee-based
proprietary protocol developed by the company Digi. Both ZigBee and DigiMesh operate on the
purchased XBee RF chips and use the same frequency, 2.4 GHz.
28
13.3 Gateway Processing Hardware
13.3.1 Criteria
The gateway processor should support the OS alternative chosen above, this will dictate its
platform architecture and other features. The hardware system should provide the ability to flash the
board itself and have strong development tools. The processor should also align with the design norm of
stewardship by having a low power consumption. Additionally, the hardware should be compact, and be
readily available at a reasonable price.
13.3.2 Options
13.3.2.1 Arduino Uno
Arduino boards allow direct programming, but not the ability to flash the board. The Arduino
developer GUI is well-developed. The operational voltage for Arduino Uno is 5 Volts[16]. The current
draw varies based on the load attached to the board. The size of Arduino Uno is 75 mm x 53 mm, and
can be purchased easily at common electronic devices distributor with a price of $28.20[32].
13.3.2.2 Raspberry Pi – Model B
Raspberry Pi boards can be flashed; however, they only support operating systems that have been
optimized for use with their hardware. They have strong support and a widely used development
environment. The Raspberry Pi is powered by 5V micro USB, and the current usage also varies based on
the application. The Raspberry Pi measures 85.60mm x 56mm, and is also readily available at Calvin’s
engineering labs with no charge. It can also be purchased with $35[30].
13.3.2.3 BeagleBone Black
Beagle boards can be flashed; however, they only support operating systems that have been
optimized for use with their hardware. They have a fairly widely used development environment. The
operational voltage is 5V, and the current drawn varies based on the load attached to the board. The
BeagleBone Black board measures 86.36 mm x 53.34 mm, and is available at a price of $55[31].
13.3.3 Decision Matrix
Table 21. Decision Matrix for Hardware System for Gateway
Weight
Arduino Uno
Raspberry Pi
Model B
BeagleBone
Black
Availability
13%
10
10
10
Reprogrammable
12%
8
10
10
Cost
13%
10
8
5
Development Environment Popularity
12%
10
8
8
Appropriate OS Support
22%
5
10
10
Power Consumption
15%
10
10
10
Size
13%
10
8
5
Totals:
100%
8.66
9.24
8.46
Criteria
29
13.3.4 Design Decision
As depicted in Table 21 the Raspberry Pi satisfied the weighted criteria for gateway processor type.
Given this and their availability at no additional cost, a Raspberry Pi gateway processor was used.
13.4 Gateway Power Supply
13.4.1 Criteria
The Gateway should be portable, although it is designed for stationary use, in order to ensure that
it can be placed in various areas. It should also be reliable in the event of a power outage, as suggested by
the design norm of trust, and allow any battery operated device to continue communicating with the
system. Additionally, and in accordance with the design norm of reliability, the gateway should not
require any maintenance once installed.
13.4.2 Options
13.4.2.1 Battery Powered Only
A battery powered gateway will allow for portability if it becomes necessary to move the
gateway. Batteries would also give the gateway a limited increase in reliability in the event of a power
outage (i.e., the gateway would continue to function as long as the batteries last). However, using solely
batteries also significantly decreases reliability and increases maintenance needs because they must be
checked frequently.
13.4.2.2 Outlet Powered Only
A gateway powered only through an outlet would have low maintenance requirements. By
allowing the gateway to be plugged into the wall, this alternative provides power in the absence of a
power outage. This is highly reliable, but not portable. Each time the gateway would be moved, it would
power down and cause system communication loss. This alternative also is not reliable in the event of a
power outage.
13.4.2.3 Battery & Outlet Powered
A gateway that is both battery and outlet powered embodies the portability, and reliability of both
alternatives described above. This alternative allows the gateway to be easily relocated, and also makes
the already highly reliable gateway more trustworthy by reducing chances of communication loss in the
event of a power outage. However, the appropriate interaction between two unique power systems
involves increased design resource usage and monetary cost for the final prototype.
13.4.3 Decision Matrix
Table 22. Decision Matrix for Gateway Power Supply
Criteria
Weight
Battery
Powered Only
Outlet Powered
Only
Battery &
Outlet Powered
Portability
Reliability (Power Outage)
Reliability (Maintenance)
Complexity
Totals:
10%
35%
35%
20%
100%
10
10
2
10
7.2
0
0
10
10
5.5
10
10
10
7
9.4
13.4.4 Design Decision
As depicted in Table 22, using both a battery and outlet power supply in the gateway best
satisfied the weighted criteria.
30
13.5 Server & Gateway Integration
13.5.1 Criteria
Including the server as integrated into the gateway or as hosted off site, separate from the
gateway, will not change the user interface of the system. Nonetheless, these design alternatives greatly
affect the quality of the whole system and, indirectly, the user’s experience. These alternatives should be
evaluated according to the criteria: reliability, latency, user support, stewardship of resources, and design
simplicity.
The design solution should build trust by minimizing the probability of system failure, and by
reducing both user involvement and the need for expert help in the event of a failure. The system should
be highly reliable.
The system should also minimize the latency time between a user interface command and the
target device’s response. This will improve user experience significantly.
Customer support should be considered during system design because it impacts the user’s
experience and perception of product quality. The alternative selected should maximize the ability for
customer support to handle incidents, such as a user needing help setting the system preferences or a third
party device not interfacing well with commands.
The design shall embody stewardship through efficient hardware usage. This will result in
relative cost savings, which can be passed on directly to customers. It will also result in decreased energy
consumption, an environmentally friendly aspect.
Finally, the design’s complexity shall be minimized, especially if doing so impacts the
stewardship of the design by reducing required human, material, and manufacturing resources.
13.5.2 Options
13.5.2.1 Unique Server & Gateway
In this alternative the gateway would still mediate bidirectional communication between the
devices and server through translating the information passed using different communication protocols.
But different from the alternative below, this one separates the database structure housing, database
operation performance and the processing of commands from the gateway to a server. This alternative
assumes that the server is not at the user’s house, but instead offsite where it is managed and maintained
by the system designers.
This alternative has a high reliability in the event of a system failure. The system designers
would be in charge of maintaining the server and would be more capable of doing so.
It is possible that this might have a high the latency for the response of commands sent by the
user. This would be due to the location of the server being offsite from the user’s house. There would
likely be a farther distance for commands to travel.
This design alternative gives the system designers great ability to support the users. If a user
needs help with system preferences or third party device support the system designers would be in a great
position to help because they are in control of the server.
Separating the server allows the system designers to effectively and efficiently manage the
database structure’s size. This also impacts the user because they would not have a limit in devices or
system preferences they may have.
31
Implementing a database structure with a server offsite will give greater flexibility in software
choices and low complexity in hardware implementation.
13.5.2.1.1 Server Integrated Into Gateway
This alternative integrates the server and its functions into the combined gateway. This would be
accomplished by embedding a database structure in the gateway and giving the gateway the capability of
processing commands and performing database operations.
Integrating the server into the gateway gives low reliability to the system if the server were to
crash due from high activity. The user would be required to reset anything needing resetting. This calls
for work or expertise out of the user and negatively affects the user’s experience.
With the server on gateway the latency of response time for the system would most likely be low,
but a user in need of help might have difficulties in receiving user support.
For this alternative, the size of the database cannot be changed. If a user has a large variety of
devices or system preferences, they will need a larger database structure to accommodate this. Thus, the
design would need to plan for the worst case and give a large allocation of memory. This alternative
would not allow for minimizing the server’s size and potentially wastes hardware. This would lead to an
increase in the products price.
This alternative has a high complexity in the system design. Creating a database structure on the
gateway might prove difficult and performing operations on an in house database structure might be
challenging.
13.5.3 Decision Matrix
Table 23. Decision Matrix for Server & Gateway Integration
Reliability
10%
Unique Server &
Gateway
10
Latency
10%
5
10
User Support
40%
10
3
Hardware Usage
20%
10
4
Complexity
20%
10
3
Totals:
100%
9.5
3.6
Criteria
Weight
Server Integrated Into
Gateway
0
13.5.4 Design Decision
Table 23 clarifies the decision. Under the criteria listed, with the weights and scores given to
each alternative, the design should implement a server separate from the gateway.
13.6 Server Hosting
This design alternative assumes that the server is chosen to be separate from the gateway as
explained above.
13.6.1.1 Criteria
The server should not require high levels of maintenance, be capable of supporting required
program sizes, and be financially feasible given the project’s budget. It is directly connected to the design
norm of trust as server hosting has to provide reliable and transparent data.
32
13.6.1.2 Options
13.6.1.2.1 Server Rented Online
A rented server from an online provider would probably not take much time to implement (there
would be no need to set up the database structure) and would not be limited in size. But renting is
typically expensive and most likely not possible given the operating budget of the project.
13.6.1.2.2 Calvin College Server
Using one of Calvin College’s servers would not take much time to implement, but there may be
limitations on program size. This alternative would most likely be free; it would not require additional
financial investment to use one of the college’s already existing servers.
13.6.1.3 Decision Matrix
Table 24. Decision Matrix for Server Hosting
Criteria
Weight
Server Rented Online
Calvin College Server
Time to Maintain
10%
10
10
Size
10%
10
7
Cost
80%
0
10
Totals:
100%
2
9.7
13.6.1.4 Design Decision
As depicted in Table 24 using a Calvin College server to host the home automation system’s
server met the weighted criteria.
13.6.1.5 Design Decision Amendments
The team first decided to user Calvin College’s server to host the HomeAlive server programs.
However, the server was later moved to a team member’s personal Linux computer off-campus. This
option allowed for the configuration of the system as required and eliminated the need to be compliant
with Calvin’s eduroam policies and restrictions.
13.6.2 Database Structure
13.6.2.1 Criteria
The database structure must perform its duty well in order to maintain consumer trust. The three
basic criteria for the database structure are reliability, database management efficiency, and database
development efficiency. Reliability is an important consideration when the system will require multiple
data access attempts simultaneously. Management efficiency directly affects how fast the HomeAlive
system handles data storing and loading. However, comparing database structure performance times is
complex. The final criterion involves project scope and consists of designer familiarity with the
database’s programming language. All of the three of these criteria are associated with the design norm
of trust.
13.6.2.2 Options
13.6.2.2.1.1 SQL Server
Microsoft SQL server was first launched for commercial use and could only be used by machines
running a Windows operating system. SQL Server is the first database structure that became widely
known and has a long history of use beginning when it was released in 1989. This server-based database
33
structure uses Microsoft relational database management system (RDBMS). Although implemented in
C++, SQL supports the .Net, Java, PHP, Python, Ruby, C++, and Visual Basic programming languages
[7].
13.6.2.2.1.2 MySQL
MySQL was developed by Oracle in 1995. It is a server-based, open-source database structure,
and it is compatible with Linux, Windows, OS X, Solaris, and FreeBSD operating systems. MySQL uses
client server and an open source RDBMS. Although implemented in C and C++, MySQL supports C, C#,
C++, Java, PHP, Python, and other programming languages [8,14].
13.6.2.2.1.3 Oracle DB
The Oracle database structure was first published in the year 1980 for commercial use. Oracle
uses RDBMS to manage its data storage, and it is compatible with Linux, Windows, OS X, Solaris, HPUX, AIX, and z/OS operating systems. Although implemented in C and C++, it supports C, C#, C++,
Python, PHP, Ruby, Visual Basic, and other programming languages [9].
13.6.2.3 Discussion
Microsoft’s SQL Server has a significant downside if HomeAlive uses an operating system
besides Linux, OS X, or Solaris for its server. In terms of reliability, all of the database structures
discussed are widely used and famous for their accuracy; however, the Oracle database has the longest
tradition of reliable widespread use (30 or more years). When considering development efficiency,
Oracle and MySQL support the languages C and C++ which are familiar to system designers [1]. (need to
fixed)
13.6.2.4 Decision Matrix
Table 25. Decision Matrix for Database Structure
Criteria
Reliability
Easy to Manage
Totals:
Weight
SQL
MySQL
Oracle
70%
30%
100%
9
7
8.4
8
8
8.4
10
8
9.8
13.6.2.5 Design Decision
As depicted in Table 25, the Oracle database structure seems to best meet the weighted criteria.
Selecting it as the database structure is advised. However, SQL and MySQL were evaluated to be
suitable options if any problems arise with Oracle.
13.6.2.6 Design Decision Amendment
MySQL was proven to be more reliable and readily available. Thus, a MySQL database was used
instead of an Oracle database.
13.6.3 Web Application Framework
13.6.3.1 Criteria
The Web Application Framework (WAF) is the software that will be used to design the web
portal and other web services associated with this system. The WAF has to follow the design norm of
trust as they will integrate two systems with a reliable and transparent connection. When choosing a
WAF, there are three key criteria: protocol compatibility, development efficiency, and unique feature sets.
Protocol compatibility is important because the web framework should be able to effectively
34
communicate with the remainder of the HomeAlive system. Developer efficiency is important due to
project scope considerations and is usually based on designer familiarity with the supported programming
language. Routing and templates are also issues common to web framework evaluation [10].
13.6.3.2 Options
13.6.3.2.1 Ruby
Ruby on Rails (RoR) an open source WAF built in the widely used programming language Ruby,
uses an ActiveRecord model-view-controller (MVC), which allows it to represent its data in various
ways. RoR manages MVC using push techniques, and its object-relational mapping (ORM) data
conversion tool is also ActiveRecord. RoR adds inheritance and associations features; it also incorporates
testing, database migration, security assurances, template generation, caching, and form validation
frameworks. This alternatives security framework is plug-in [11, 12].
13.6.3.2.2 Python
Django is a commonly used, open-source WAF built in the programming language Python.
Django uses a full stack type MVC and has its own integrated ORM. Like most WAF models, Django
supports testing, database migration, security assurances, template generation, caching, and form
validation. Django’s security framework uses access control list (ACL), and its template and form
validation frameworks use Python. The caching framework that Django uses is a dynamic one [10].
13.6.3.2.3 Java
There are several WAF models built in the Java programming language, but the most widely used
one is Spring. The Spring WAF is one of the most commonly used open source frameworks. Its MVC is
a push-typed one, but it is not highly unique. The ORM that Spring uses is called Hibernate; it solves
ORM impedance mismatch problems. Like most Java-based WAF models, Spring does not include a
database migration framework. Spring’s security framework is unique, like its unit-testing test
framework. JavaServer Pages (JSP), software that dynamically generates web pages, is used as its
template framework. Spring’s caching framework employs the Echache technique, and this validation
framework utilizes Bean Validation strategies [13,14].
13.6.3.2.4 PHP
The acronym PHP originally stood for Personal Home Page, but it became Hypertext
Preprocessor since it is highly related to HyperText Markup Language (HTML). PHP is usually located
on the server-side of web processing. The MVC that PHP uses is similar to the one used by Ruby. There
are many ORM libraries available for PHP, most notably are the data mappers ORM, PDO/ADO, and
Doctrine. Most PHP libraries are fully documented and have complete tutorials available for free. The
framework that PHP offers is adaptable and well-developed. [17]
13.6.3.3 Discussion
The WAF model associated with the Java programming language is the most familiar to system
designers, giving it the highest expected development efficiency. On the other hand, PHP is highly
compatible with HTML files that are used for HomeAlive marketing websites, and they are also similar to
the familiar C++ programming language. Compatibility considerations must be examined in tandem with
server choices. The Spring and Django WAF models include several unique features which adds to both
their flexibility and complexity.
35
13.6.3.4 Decision Matrix
Table 26. Decision Matrix for Web Application Framework
Criteria
Weight
Ruby
Python
Java
Familiarity
60%
7
8
9
PHP
9
Compatibility
30%
8
8
8
10
Uniqueness
10%
8
9
10
9
Totals:
100%
7.4
8.1
8.8
9.3
13.6.3.5 Design Decision
As depicted in Table 26, the WAF model that seems to best meet the weighted criteria is PHP
WAF. However, each alternative evaluated as similarly suitable and decision matrix estimates require
refinement before a WAF is chosen.
13.6.4 Gateway to Server Messaging Protocol
In order for the gateway to properly function it must consolidate wireless communication from
many devices into a single internet-based communication path. It includes two critical components: a
wireless communication module and an internet-enabled processor. The communication protocol for
messages passed between the gateway and the server will be chosen from several alternatives as discussed
below. The messaging protocol from gateway to the server has to utilize the design norm of trust.
13.6.4.1 Criteria
Each messaging protocol should be evaluated according to its reliability, computational
requirements, compatibility, and complexity. Reliability refers to the protocol’s assurances that its
messages are transmitted successfully, decoded accurately, and received from a trusted source. The
reliability of the system connects to the design norm of trust. Computational requirements refers to the
idea that minimal hardware and software resources should be needed in order to utilize this protocol; its
primary purpose is to transmit information, not process it. Compatibility refers to the fact that the
protocol must be capable of interacting with both the wireless communication module and the gateway’s
main processor. Finally, complexity refers to choosing the simplest available alternative that satisfies the
preceding criteria satisfactorily.
13.6.4.2 Options
13.6.4.2.1 MQTT
One protocol option for internet-based messaging is MQ Telemetry Transport (MQTT). It was
designed for machine-to-machine (M2M) integration and mobile applications by focusing on the
minimization of required computational resources and reliable assurances of message delivery [15]. It
utilizes established connections between publishers and subscribers in order to perform message passing.
13.6.4.2.2 AMQP
Advanced Message Queuing Protocol (AMQP) allows messaging providers to send information
to a message-oriented middleware (MOM) broker by implementing an open standard application layer.
MOM supports messaging distribution over similar platforms. AMQP is utilized for M2M
communication, and it is similar to the familiar Hypertext Transfer Protocol (HTTP), File Transfer
Protocol (FTP), and Simple Mail Transfer Protocol (SMTP). It utilizes established connections between
clients and brokers in order to perform message passing.
36
13.6.4.3 Design Alternative Selection
AMQP was first chosen for HomeAlive’s internet-based messaging protocol based on industrial
consultant’s recommendation. In addition, AMQP was proven to be more feature-rich than MQTT. This
was also based on the fact that the Raspberry Pi processor has the required complexity to support an
AMQP application, which offers greater capabilities than the MQTT protocol.
13.6.5 Web Portal Programming Language
In order to provide a web portal user interface that is most ideal, it has to satisfy the criteria
below. In addition, a programming language for designing the software interface must be chosen.
Several alternative languages are identified and evaluated in this section.
13.6.5.1 Criteria
Each web portal programming language should be evaluated according to its compatibility,
graphical capability, runtime performance, and developer familiarity. Compatibility refers the fact that
the web portal must be able to interact with the database system and interface protocols that are chosen
when designing the server. Graphical capability refers to ease with which the programming language can
be used to develop intuitive and aesthetically appealing user interfaces. Runtime performance refers to
the efficiency and speed with which programs written in the language typically run. Finally, developer
familiarity refers to selecting the language that is best known by the web portal developer and also
satisfies the preceding criteria.
13.6.5.2 Options
13.6.5.2.1 Ruby on Rails
One programming language option for the web portal user interface is Ruby on Rails. Its chief
advantage seems to be an integrated web framework that facilitates the development of website user
interfaces. The connectivity with the database is easy to use. Ruby serves as the server-side, while all the
client-side is handled by JavaScript (JS). The graphical capability mostly depend on the JS handling.
PHP
Another programming language option is the language PHP, which is often used in back-end or
server-side web portal contexts. PHP has a noteworthy integration with the MySQL database language
and is easily linked to HTML and CSS files. It is also important to recognize that PHP is easy to connect
with JS in order to provide high-quality graphics.
13.6.5.2.2
Java
A third option is the Java programming language. It is commonly used as a server-side
development language for web development. Java’s connectivity with the database systems is easy to
learn and Java frameworks allow HTML integration for graphical web interfaces. Finally, the inherent
connection to JS will help the user interface display the necessary visuals for system data.
13.6.5.2.3
13.6.5.3 Discussion
PHP is a free software released under PHP license. The syntax is very similar to the C based
languages. Since HomeAlive members have previous experiences in coding with C++, PHP provides the
highest familiarity. Java is also a familiar language as it is the basic object oriented programming. In
terms of compatibility, PHP is compatible with many architectures and operating systems. It runs
smoothly on Windows, Linux, and Macintosh systems.
37
13.6.5.4 Decision Matrix
Table 27. Decision Matrix for Web Portal Programming Language
Criteria
Weight
Ruby
Java
Familiarity
60%
7
9
PHP
9
Compatibility
30%
8
8
10
Performance
10%
7
8
9
Totals:
100%
7.3
8.6
9.3
13.6.5.5 Design Decision
PHP was selected according to the matrix shown in Table 27. However, it is important to note
that this web portal programming language will be paired with JS, HTML, and CSS on the client-side.
13.6.6 User Interface
13.6.6.1 Criteria
The user interface is the point where product and consumer interact, so it plays a large role in the
user’s experience and HomeAlive seeks to maximize the quality of that experience. This project is being
conducted with limited resources including time and cost. In light of this, the user interface alternative
that is selected should maximize quality of experience while remaining within project budget and scope.
The criteria of the user interface is highly connected with the design norm of trust, users should
experience transparency and consistency when using the user interface.
13.6.6.2 Options
13.6.6.2.1 Web Portal Only
The web portal would use project resources efficiently by building upon an already required web
framework. Developing a web portal interface that is intuitive for users may present a challenge, and the
user experience for a web portal is not seamlessly available in daily life.
13.6.6.2.2 Mobile Application Only
A mobile phone application user interface would require development of an Android or an iOS
application using Java or objective C. Developing a mobile application may cost money to gain a license
to use an environment provided by the related OS. Designing a GUI of this nature would be time
consuming, due to team inexperience with mobile development. A mobile application would be a great
asset for maximizing the user’s experience; it would serve as an important part of the system’s overall
accessibility.
13.6.6.2.3 Web Portal & Mobile Application
Developing both the web portal and mobile application interfaces, in comparison to only doing
one, would increase the time required and possibly the cost of this project, but would significantly
increase the user’s quality of experience.
38
13.6.6.3 Decision Matrix
Table 28. Decision Matrix for User Interface
Weight
Web Portal Only
Mobile
Application Only
Web Portal &
Mobile App.
20%
2
8
9
5%
10
2
2
Time Required
75%
9
5
1
Totals:
100%
7.65
5.45
2.65
Criteria
Quality of User’s
Experience
Cost
13.6.6.4 Design Decision
As depicted in Table 28, developing only a web portal user interface for the system best met the
weighted criteria. However, it is important to note the criteria weights favor scope considerations far
more than the quality of user’s experience and cost criterion.
13.7 Design Decision Summary
Table 29 summarizes all of the design alternative selections discussed above.
Table 29. Design Alternative Selection Summary
Design Alternative
Gateway OS and Networking
Terminal Device to Gateway Communication Protocol
Gateway Processing Hardware
Gateway Power Supply
Server & Gateway Integration
Server Hosting
Database Structure
Web Application Framework
Internet-based Messaging Protocol
User Interface
Selection
Raspbian
DigiMesh
Raspberry Pi
Battery & Outlet Powered
Unique Server & Gateway
An independent Server
MySQL
PHP
AMQP
Web Portal Only
39
14 System Implementation
14.1 Technical Diagram & Component Explanations
The conceptual system diagram explained above can be expanded into a technical system
diagram as seen in Figure 9. The technical diagram shows greater detail within each system component
from the conceptual diagram, by separating them into even smaller modules. These modules are
categorized as either hardware or software, and the interface protocols between them have been explicitly
declared.
Figure 9. Technical System Diagram
This diagram shows system component separation into hardware and software modules. It also
clarifies that interface protocols will be needed for communication between components.
40
14.1.1 User Interfaces Explanation
The user interfaces component, seen in Figure 9 is separated into two distinct software modules: a
web portal client and a smart phone application. The web portal client describes any internet browser that
is accessing the server’s web portal module. The phone application functions similarly but interacts
directly with the server’s database manager API protocol; it uses a GUI that has been optimized for
smartphone screens. Both of these modules allow for users to interact with the home automation system.
The UI Webserver module of the server is the code for the website UI, hosted by the server machine, and
is referred to as part of the user interface throughout this report.
14.1.2 Server Explanation
The server component, seen in Figure 9, is separated into five software modules. The basis of the
server is the database storage module which is responsible for containing device and system information.
This software element is important because the storage of device information enables actions to be taken
based on the past, instead of just the present. Additionally, the storage of system information is crucial to
maintaining device pairings and security logins. Next, there is a database manager software module
which is responsible for controlling reads, writes, and searches of the database as it communicates with
the gateway via an AMQP broker. The manager controls the HomeAlive system and the broker simply
coordinates messages between its gateway and server clients. Finally, there is a user interface to database
API module which adds a layer of abstraction between the webserver and the database. This is important
to facilitate the adding of more user interface options in the future.
14.1.3 Gateway Explanation
The gateway component, seen in Figure 9, is separated into two hardware modules, their
associated software modules, and two interface protocols. The first main hardware module is the RF
communication chip. It is responsible for relaying information from all of the devices to the gateway’s
processor, and for relaying information from the gateway’s processor to the correct individual device.
The second main hardware module is the processor which is primarily responsible for translating
messages received from the RF communication chip into internet-based messages, these are destined for
the server’s database manager module. The software module running on the RF communication chip
includes basic configurations for the chip. The software module running on the processor includes both a
small operating system and a networking structure that allows it to access the internet and pass messages
to the server.
The two interface protocols include server communication and wireless RF communication. The
server communication protocol allows the processor to make and receive understandable requests from
the server. Next, the wireless communication interface protocol module is meant to show that the
information being relayed by the RF communication module has a logical structure imposed on it.
14.1.4 Devices Explanation
The devices component, seen in Figure 9 is separated according to each device; each device is
then separated further into hardware and software modules. Hardware modules for each device include
the essential device hardware, control circuitry, a microprocessor, and an RF communication chip. The
essential device hardware is comprised of the actual lighting system, thermostat, coffee machine, or other
household object. The control circuitry is attached to the essential device hardware in such a way that it
can execute the desired monitoring and controlling of the household object. The microprocessor is the
master of the device and interprets RF messages before taking the appropriate action using control
circuitry. It has the device’s main software module which is integrally connected to the microprocessor’s
ability to read and drive electrical signals on IO pins. Finally, the RF communication chip is responsible
for relaying information wirelessly from the control circuitry to the gateway, and from the gateway to the
41
control circuitry. It also hosts the device component’s other software module, which includes basic
configurations for the wireless communication chip.
14.2 User Interfaces
The system implementation of the user interface relies on HTML, CSS, PHP, and JS scripts.
First, the HTML structure provides the display of the website and its user input forms. These forms use
the POST method because it is more reliable and secure than the only alternative, the GET method.
Second, the combination of HTML and CSS makes the user interface display more colorful and
aesthetically pleasing. The placement and shapes of all objects are defined inside the CSS file; all of the
minimalist HTML and CSS files are originally designed by HTML5 Alpha Themes (although they have
been significantly altered). The HTML and CSS combination works well with Windows, Android, and
Blackberry operating systems, but iOS has notable incompatibilities.
Third, the PHP language is used because it provides familiar programming styles and higher
security than simple HTML files. The HTML files used for the user login pages and home manager
pages are embedded inside PHP scripts using the echo function. In this way, users can only look at the
printed result of the PHP script. This is a standard security protocol used to prevent unwanted user
permissions for viewing configuration files and database values that the PHP files utilize. The opensource module that was used for developing the login page is called userCake, and it provides a simple
and manageable login system that connects directly to the server’s MySQL database. This module also
includes logout, sign up, forgot password, and email activation features. Fourth, the JS script files are
used as an additional programming tool that works flawlessly with HTML. Multiple JS script files are
integrated in order to provide rules for checking time, hiding unselected features, getting live data, and
other required functions. The only two libraries involved in the JS scripts are the default JS library and
the popular jQuery library. These are relevant to achievement of the user interface’s component
requirements. Finally, the JSON add-on is used in these JS scripts to attain undisturbed send and receive
capabilities. The following figures (Figures 10 to 17) show screenshots of the user interface’s final
appearance.
42
Figure 10. Welcome Page
Figure 11. User Login Page
43
Figure 12. Home Manager Page
Figure 13. Home Manager Page continued
44
Figure 14. Outlet Adapter Advanced Settings
Figure 15. Outlet Adapter Monitoring Display
45
Figure 16. Thermostat Advanced Settings
Figure 17. Thermostat Scheduling Display
46
14.3 Server
The server component was integral to HomeAlive system, and implemented using many sub
system components.
14.3.1 Hardware
A desktop computer with an Intel Core i5 processor and a 4GB of RAM was used to install all
required software. The server was physically located at engineering building while in development stage,
and later moved to Okkar’s house for universal access. The desktop computer with mentioned
configuration provided more than adequate system for HomeAlive. The processing speed was 2.7 GHz
and data storage capacity was 500 GB. It also had an Ethernet cable interface with a maximum transfer
speed of 1Gb/s to handle incoming internet traffic.
14.3.2 Software
HomeAlive used an Ubuntu server as a base system for HomeAlive’s server. The software
implementation of server involved four main area: a database server, a device and database API, a User
Interface and database API, a gateway and database manager and an AMQP server.
14.3.2.1 Database Server
A database server for storing system related data was set up using a MySQL database over an
existing Ubuntu server. MySQL server listens incoming internet traffic on port 3306. The relationship
between tables were shown in Figure 18.
Figure 18. HomeAlive’s Database Structure
14.3.2.2 API for communication between a Gateway and a database (Gateway – API)
Server was required to provide a way to communicate between a Gateway and a database. In
order to do so, functions written in PHP were used as API. API eliminates the need for the Gateway to
know the structure of the database or the need for database to know which gateway to communicate to.
47
For example, a gateway sends a status update from a thermostat. By using the API provided, the gateway
does not need to know the details of table and rows that need to be updated. The API handles those
details. This approach allowed HomeAlive team to design modular system easily with minimal
dependent on other components of the system. The followings were the main API functions used.
Table 30. HomeAlive’s Gateway and Database API Summary
Name
sendCmdToHub()
Purpose
It periodically checks new user commands stored in the database
and send the commands to the gateway using the appropriate
AMQP queue for the specified household.
registerStatus($mysqli,$raw_data) The function insert or update the rows in table using the device
and house identification number included in raw data.
14.3.2.3 API for communication between a User Interface and a database (UI-API)
Server was also required to provide a way to communicate between HomeAlive’s user interface
and tis database. API approach was again used. The UI would call the functions to store the user
commands in the database. Similarly, the UI would call the function to get the status of devices. All API
function were written in PHP. The followings were the main API functions used.
Table 31. HomeAlive’s User Interface and Database API Summary
Name
Purpose
registerUserInput ($Device_ID, The function inserts or updates commands in the appropriate table
$House_ID, $Cmd)
given the device and house identification numbers.
getCurrentStatus
The function returns the current status of the specific device from
($Device_ID,$House_ID,$Cmd) the specified household stored in the database.
14.3.2.4 A Manager for communication between a gateway and a database (Gatway-Manager)
A manager simply referred to a standalone function that is constantly monitoring the changes in
the system and taking action as necessary. For HomeAlive system, a function with infinite loop that was
calling the API for communication between a gateway and a database was used. The function was also
written in PHP.
14.3.2.5 RabbitMQ Server and Broker
A RabbitMQ server is an AMQP server and listens incoming traffic on port 5672. It was readily
available through Ubuntu software repository. The configuration of the server was modified to meet the
requirements of the HomeAlive system. The Exchange and Queue were set up according to the Figure
21.
The RabbitMQ client communicates with the RabbitMQ server residing on the server machine as
described above. When receiving AMQP messages, the client is pushed by the broker and its received
message handler is called. This handler then calls registerStatus API function to update the contents of
the device table. When sending AMQP messages, the client simply publishes the message content to the
appropriate queue (see above); from there the broker distributes it to the server manager. This structure is
diagramed below in Figure 21.
14.3.2.6 Flow diagram of the software implementation
The following figure illustrates the simplified flow of server software implementation. Figure 19
represents the flow of server programs starting from UI-API to RabbitMQ broker. Figure 20 shows the
reverse flow of server programs from RabbitMQ Broker to UI-API.
48
UI- API
Database
Gateway Manger
•registerUserInput() :
register the incoming user
input in the database
•stores data in the
appropriate table
•notice the change and call
API
Gateway - API
RabbitMQ Broker
•sendCmdToHub() : send
the command to the
appropriate gateway
•relays the command using
AMQP
Figure 19. Server’s program flow from UI end to Gateway End
RabbitMQ Borker
Gateway Manager
Gateway - API
• receives AMQP
message from the
gateway
• Manager notice the
message and call API
• registerStatus() : put
the message in the
database
Database
UI-API
• store the incoming
message
• getCurrentStatus() : get
the current status of
the device
Figure 20. Server’s program flow from Gateway end to UI End
49
Figure 21. Rabbit MQ Broker and Client System Diagram
14.4 Gateway
Gateway hardware was purchased and then carefully configured. Gateway software was written
nearly from scratch, utilizing just the Java Simple Serial Connection (jssc) and RabbitMQ libraries.
Hardware
The gateway hardware was implemented using a purchased single-board computer called a
Raspberry Pi. This computer has the required processing power to be capable of converting messages
between AMQP and DigiMesh at the required speeds. Furthermore, it has USB serial ports which allow
it to easily communicate with a wireless RF communication XBee chip. The XBee chip is another
hardware element of the gateway, and it uses a USB serial dongle adapter. Optionally, the gateway can
be outfitted with a USB WiFi dongle to provide an internet connection. If not, a standard Ethernet
internet connection functions equivalently.
Software
The gateway software was written in a one multithreaded Java program. This program is
basically divided into two sections, a RabbitMQ client and an XBee serial communication module. These
sections are closely linked because an incoming message in either one results in an outgoing message on
the other. Furthermore, multithreading concerns are handled by congregating all functionality that needs
50
to be thread-safe into a few synchronized functions. These functions are then used instead of directly
accessing shared resources in order to guarantee that there will be no race-conditions, deadlocks, etc.
14.4.1.1 Messaging Format
Throughout all of the gateway software, messages are treated as sequences of bytes in the
HomeAlive message format. This format can be seen in Figure 22 and includes: 4 bytes of house
identification, 1 byte of device identification, 1 byte of message payload length, and up to 256 bytes of
payload data. House ID numbers are unique per household and device ID numbers are unique within
each household. Also note that start sequences are prepended to messages travelling from devices to the
gateway, but the start sequence is cut off before messages are delivered to the server.
Figure 22. HomeAlive Messaging Format (bytes)
14.4.1.2 RabbitMQ Client
The RabbitMQ client communicates with the RabbitMQ broker residing on the server machine as
described above. When receiving AMQP messages, the client is pushed by the broker and its received
message handler is called. This handler then makes use of the XBee Serial Communication module’s
send functionality in order to pass the message on as a DigiMesh message. When sending AMQP
messages, the client simply publishes the message content to the appropriate queue (see above); from
there the broker distributes it to the server manager. This structure is diagramed below in Figure 23.
14.4.1.3 XBee Serial Communication
As seen in Figure 23, the XBee Serial Communication module uses the jssc library to interact
with the XBee chip and dongle adapter, and it also does a significant amount of processing to confirm
message accuracy. When sending messages using the XBee chip, this module simply writes the byte
content to the DigiMesh protocol. However, when receiving DigiMesh messages two additional
algorithms are used to confirm message accuracy. First, devices sending message to the gateway must
start their messages with a specified 5 byte sequence, the start sequence. If the gateway receives a
message that does not begin with this sequence, it purges the serial buffer until it is either empty or
locates the correct start sequence. This helps the gateway be resilient against bad messages which
originate in the interleaving of DigiMesh messages from multiple sources. A higher quality solution
would be to access the XBee firmware and stop message interleaving from occurring in the first place;
however, this was considered out of project scope. Second, the gateway checks each message’s header
information for that message’s payload length. It will then continue reading bytes into that particular
message until the payload length is realized or a timeout event occurs. This helps protect the system
against the tendency of XBee chips to divide DigiMesh messages into segments and send each segment
separately. If the timeout event occurs, the serial buffer is purged in the same way as previously
described.
14.4.1.4 Multithreading
The multithreading capabilities of the Java programming language are used in order to more
efficiently handle gateway message conversions. As seen in Figure 23, there is a single main loop for the
program. The main loop listens for new XBee messages, reads them, and then spawns threads to handle
51
their conversion and resending. In addition, new threads are spawned when the program is pushed by the
RabbitMQ broker to receive a new AMQP message. These threads pass their message content on using
the XBee radio chip. In order to implement multithreading without running into deadlock, race condition,
or other problems, the Java ‘synchronized’ keyword is used. The ‘synchronized’ keyword allows
programs to mark functions that have critical sections and cannot be used by multiple threads at once. All
shared resources, especially the XBee radio chip, are wrapped in synchronized functions in order to make
them thread-safe.
Figure 23. Gateway Software Diagram
14.5 Devices
14.5.1 Thermostat
The HomeAlive team decided to develop a smart thermostat to show the system’s capabilities.
This was accomplished by converting a normal thermostat, which has a programmable schedule for the
week and weekend, and other features similar that may be set, into a smart thermostat by adding wireless
and scheduling capabilities. To do this a programmable thermostat was purchased and modified to be able
to be controlled wirelessly.
14.5.1.1 Hardware
This section will describe the hardware required to modify the thermostat and make it smart.
14.5.1.1.1 Thermostat
The Honeywell RTH6350 was selected to be the modified thermostat. This thermostat has 4
programmable periods - wake, leave, return, sleep - for both heat and cool, and the week and weekend.
This totals to 4 different schedules: a week heat and cool and a weekend heat and cool. The modified
design added the ability to electronically press the buttons, and wirelessly send and receive data.
52
14.5.1.1.2 Arduino
An Arduino Uno is used to electronically press the buttons, read if buttons are pressed manually,
process communications, and maintain a synchronized state with the state machine on the Honeywell.
14.5.1.1.3 XBee Chip
An XBee chip is used to wirelessly communicate with the gateway.
14.5.1.1.4 Control Circuitry
The control circuit of thermostat can be viewed in Figure 24. This section will walk through each
area of the circuit at a high level. For a further explanation of the button pressing see the honors report
posted on the team website.
When a button is pressed manually on the thermostat a terminal on the thermostat’s circuit is
shorted. This is accomplished electronically using a transistor (2N3904). The base of the transistor is
connected to the digital output of the Arduino. When the digital pin is asserted high the transistor is
forward biased and the emitter and collector are essentially connected. By connecting each end of the
button’s terminals to either the emitter or collector the transistor is capable of electrically pressing the
button.
This technique gave control to all six of the buttons, but pressing a button, manually or
electronically, can have different effects based on whether or not the thermostat is currently awake or
asleep. Thus a way needed to be devised to tell if the backlight is on or not. This is accomplished by
reading the voltage across the backlight’s LED on an analog pin.
The manual reads are accomplished by reading the voltage across the terminals of the buttons into
analog pins.
An LED is asserted digitally by the Arduino to show when the Arduino is busy.
Lastly, the thermostat has connections for a heater, air conditioner, and fan. To display when the
thermostat is turning on the heater, air conditioner, or fan LEDs are digitally asserted by the thermostat.
Figure 24. Thermostat Device Conceptual Diagram
53
Figure 25. Thermostat Device Schematic
14.5.1.1.5 PCB Fabrication
The initial circuit designs were built on a bread board, but once the circuit proved working they
were moved to printed circuit boards. The PCBs were fabricated at Calvin College.
14.5.1.2 Software
The thermostat device’s Arduino software consists of several thousand lines of Arduino code
(similar to C code), and it is organized according to the structure shown in Figure 26. This diagram
shows how Arduinos are divided into two sections, setup and loop. The setup code executes each time
the Arduino boots; the loop code executes repeatedly and endlessly until the Arduino shuts down. Each
segment of the Arduino code is explained in greater detail below.
54
Figure 26. Thermostat Software Diagram
A: Define Global Variables & Constants
This section of the software explicitly declares all the global scope variables and constants for the
program. Most of this section is filled with declarations of numerical constants for: recognizing
commands from the rest of the system, sending status updates to the rest of the system, and using
EEPROM addressing techniques. The constants for communication with the rest of the system must
match those used by the other system components exactly.
B: Send Status
This section of the software causes the Arduino to write bytes of information to the XBee RF
chip, where it will be sent to the gateway. These informative bytes are the message payload and are
wrapped in appropriate header information and prepended with the correct start sequence according to
Figure 26 above. In addition, the status reports follow a specific payload format of alternating feedback
codes and byte sub-payloads. A portion of the table detailing these can be seen in Figure 27.
55
Figure 27. Thermostat Feedback Codes Snippet
C: Initialize Variables
This minor but important section of the code prepares the thermostat to run by setting up its initial
state and resetting its internal timers.
D: Send Status
This section of the software is identical to the similarly named section in the Arduino setup code;
however, it is only executed if the custom Arduino chirping timer has expired. The chirping timer length
can be set by the HomeAlive system using thermostat commands; it is essentially how often the
thermostat should report its state.
E: Read Message
This section of the code relies heavily on the Arduino’s serial interface with the XBee RF chip. It
carefully examines incoming bytes of data in order to recognize only HomeAlive messages that are
intended for its specific device ID, discarding the other messages. If it does receive a message that is
intended for the thermostat, then it invokes the appropriate message handlers (see below).
F: Handle Message
This section of the code is the most important part of the thermostat Arduino program. It causes
the thermostat to take some action based on the command code and parameter values of the message
payload, a snippet of this structure can be seen in Figure 28. These actions involve the Arduino state
machine, EEPROM values, and pressing the thermostat buttons using the control circuitry described
above.
56
Figure 28. Thermostat Command Codes Snippet
G: Manual Button Press Checking
This section of code is responsible for recognizing when a user has physically pressed a
thermostat button with their fingers. It does this by quickly counting the number of times (corresponds to
length of time) that the Arduino analog read pins cross a certain voltage threshold. When that number
exceeds another threshold value, a button press has occurred and the appropriate state machine link is
forced in order to keep the Arduino and thermostat synchronized. One other important feature of this
code is its ability to recognize which of the 6 buttons is being pressed based on the 5 Arduino analog read
pin values, these are organized as explained in the hardware paragraphs above.
State Machine
One of the main functions of the Arduino code on the thermostat device is to maintain a state
machine that is always synchronized with the physical thermostat machine. This is necessary in order to
know what conditions exist on the thermostat without needing to access its firmware. As explained
above, the physical thermostat interfaces with the Arduino only via an analog reading of 6 of its electrical
nodes. This complex state machine has 22 states and 132 links where states represent thermostat
conditions and links are button presses, an abbreviated version is shown in Figure 29.
Figure 29. Thermostat Abbreviated State Machine
57
14.5.2 Outlet Adapter
The outlet adapter was created from scratch as a device to mimic a commercial Kill-a-Watt with
the added ability of bidirectional communication, other commands, and toggling on/off feature.
14.5.2.1 Hardware
14.5.2.1.1 Arduino
The outlet adapter uses an Arduino Nano to process all of the wireless communications, perform
analog reads for current and voltage, and digitally control the a relay.
14.5.2.1.2 XBee Chip
An XBee chip was used to wirelessly communicate with the gateway.
14.5.2.1.3 Power Monitoring Circuitry
The power monitoring circuit is split into two different sections: the measuring of current and
voltage. The power factor was not determined, thus multiplying the measured current by the measured
voltage produced the apparent power (VA) and not the real power (W). The descriptions below explain
the schematic in Figure 32.
The basic approach to measuring the voltage is to step down the voltage by a factor of 1000.
Next the smaller voltage is used as an input to an rms to DC converter (AD736). The rms to DC converter
produces a steady DC value between 0 VDC and the positive voltage supply (5 VDC) proportional to the
input’s position in the input range. The input range is from 0 V to 200 mVrms thus 100 mVrms would
produce an output of 2.5 VDC. The output is sent to an analog pin on the Arduino. The Arduino was then
calibrated to produce valid measurements.
The current is measured using a current transducer (ACS712). The output of the ACS712 is a DC
value offset halfway (2.5 VDC) from 0 VDC to the positive voltage supply (5 VDC). The voltage output
is linearly proportional to the current, but scaled based on the power supply. The maximum input allowed
is 15 Arms, as specified by the datasheet. Thus, using a ± 5 VDC supply, the scaling factor is 0.333 and a
+ 100 mArms current would produce a + 33.3 mVDC from the DC offset and a - 100 mArms current
would produce a – 33.3 mVDC from the DC offset. The output would be 2.533 VDC and 2.467 VDC
respectively.
The next step was to filter the output of the current transducer. A 60 Hz bandwidth filter cancels
out the DC and passes only the 60 Hz signal, as would be expected of U.S. outlets. The filter also has the
negative effect of attenuating the signal by 70%.
After the signal is filtered it is input into an rms to DC converter (AD736), the same part but
another one. The AD736 does the same operation and functions the same way as above.
The output of the AD736 could be sent straight into the Arduino to be read, but to increase the
precision the output of the AD736 if first amplified by a non-inverting operational amplifier with a gain
of 5 V/V.
Lastly, the output of the operational amplifier is sent to a voltage divider that allows the output to
be read at smaller and larger values. The Arduino analog pins have a range of 0 VDC to 5 VDC. To gain
precision the analog reference (AREF) can be set as low as 1 VDC. The Arduino then converts the ratio
of the input compared to the reference (default 5 VDC) to a number between 0 and 1023. To illustrate, if
AREF is set to 3 VDC and the input is 1.5 VDC the number for an analog read will be 512. The output of
the AD736 is from 0 VDC to 1 VDC and corresponds to a value of 0 Arms to 15 Arms. By amplifying
this output by 5 times the full range of the analog read can be utilized. Next by setting AREF to 1 VDC
58
more precision can be acquired. To make sure that the maximum output of the operational amplifier (5
VDC) is in the range of AREF a voltage divider is used. The voltage divider splits the operational
amplifiers output into five equal chunks. To illustrate, 1 VDC is split into 0.2 VDC, 0.4 VDC, 0.6 VDC,
0.8 VDC and 1.0 VDC. Thus, 5 VDC will have at least one reading that is in range.
An analog pin reads the voltage divider at each one of these chunks. The chunk with the lowest
value is checked first. If it is out of range (it equals 1023) the next lowest chunk is checked. This
continues until the highest chunk (the original value) is checked. If that value is out of range the current is
determined to be above 15 Arms. The Arduino was then calibrated to produce valid measurements.
Figure 30. Outlet Adapter Device Conceptual Diagram
59
D
A
E
B
C
A
B
60
C
D
E
61
Figure 31. Outlet Adapter Device Schematic
Figure 32. Outlet Adapter Device Filter
Figure 33. Outlet Adapter RMS to DC Calibration
62
Figure 34. Outlet Adapter Device Voltage Calibration Curve
63
Figure 35. Outlet Adapter Device Current Calibration Curve
64
Figure 36. Outlet Adapter Device Photo
14.5.2.1.4 Control Circuitry
The control circuit for the outlet adapter’s toggling utilizes a relay, controlled by the digital
output of the Arduino. The relay (G5CA-1A) needs 5 VDC and 40 mA to be able to control up to 15
Arms through it. To control the switching on and off of the relay a transistor (2N3904) is connected to it.
The transistor is forward biased by the digital output of the Arduino.
14.5.2.1.5 PCB Fabrication
The initial circuit designs were built on a bread board, but once the circuit proved working they
were moved to printed circuit boards. The PCBs were fabricated at Calvin College.
14.5.2.2 Software
The outlet adapter device’s Arduino software consists of a several hundred lines of Arduino code
(similar to C code), and it is organized according to the structure shown in Figure 37. This diagram
shows how Arduinos are divided into two sections, setup and loop. The setup code executes each time
the Arduino boots; the loop code executes repeatedly and endlessly until the Arduino shuts down. Each
segment of the Arduino code is explained in greater detail below.
65
Figure 37. Outlet Adapter Software Diagram
A: Define Global Variables & Constants
This section of the software explicitly declares all the global scope variables and constants for the
program. Most of this section is filled with declarations of numerical constants for: recognizing
commands from the rest of the system, sending status updates to the rest of the system, and using
EEPROM addressing techniques. The constants for communication with the rest of the system must
match those used by the other system components exactly.
B: Send Status
This section of the software causes the Arduino to write bytes of information to the XBee RF
chip, where it will be sent to the gateway. These informative bytes are the message payload and are
wrapped in appropriate header information and prepended with the correct start sequence according to
Figure 19 above. In addition, the status reports follow a specific payload format of alternating feedback
codes and byte sub-payloads. A portion of the table detailing these can be seen in Figure 38. For the
outlet adapter, status reports are either comprehensive or limited. Comprehensive reports share all status
information while limited ones share only frequently changing information.
66
Figure 38. Outlet Adapter Feedback Codes Snippet
C: Load EEPROM
This minor but important section of the code prepares the outlet adapter to run by setting up its
initial state and loading its EEPROM values into its global variables.
D: Send Measurements
This section of the software is identical to the Send Status section in the Arduino setup code;
however, it is only executed if the custom Arduino chirping timer has expired and it only shares a limited
status report. The chirping timer length can be set by the HomeAlive system using outlet adapter
commands; it is essentially how often the adapter reports the power monitoring values that it is reading.
E: Read Message
This section of the code relies heavily on the Arduino’s serial interface with the XBee RF chip. It
carefully examines incoming bytes of data in order to recognize only HomeAlive messages that are
intended for its specific device ID, discarding the other messages. If it does receive a message that is
intended for the thermostat, then it invokes the appropriate message handlers (see below).
F: Handle Message
This section of the code causes the outlet adapter to take some action based on the command code
and parameter values of the message payload, a snippet of this structure can be seen in Figure 39. These
actions typically set whether or not the adapter has toggled on its relay and whether or not the adapter is
chirping its measurement values.
Figure 39. Outlet Adapter Command Codes Snippet
G: Measure & Sample
67
This section of code is responsible for using the Arduino’s analog read pins in order to determine
the voltage and current being used by the adapter hardware. As explained above, voltages are read by a
single Arduino pin and the current is read by several Arduino read pins. The values of these pins are
sampled over either a certain number of repetitions or a certain amount of time and then averaged.
Finally, the averaged values are subjected to a linear calibration curve in order to determine current,
voltage, and power values. The calibration curves can be seen in the figures below and were generated by
submitting the adapter to several different loads and comparing values to a DMM readout.
Custom Floating Point Format
Due to the non-integer nature of voltage readings, current readings, and calibration curve values,
it became necessary for the HomeAlive system to pass floating point values between its components.
This presented something of a challenge because the system deals exclusively with byte data. Two
solutions were used, one for power readings and one for calibration values.
The solution for power readings (voltage and current) was to pass three bytes of data and interpret them
using a one-deci-milli format. For example, the number 214.692 V would be separated into 214 V for the
first byte, 6 dV for the second byte, and 92 mV for the third byte. Adding these together results in the
original value of 214.692 V.
The solution for the calibration values allows four distinct bytes to be used to communicate all
positive or negative values of 6 or less significant figures with magnitudes between 1*10^-63 and
999999*10^63. This is done using another custom format wherein the second, third, and fourth bytes are
simply the BCD value of each segment of the 6-digit number. For example, 123.456 would have the
second byte 12, the third byte 34, and the fourth byte 56. The first byte is handled more complicatedly;
its range (0-255) is divided into four equal sections: (0-63), (64-127), (128-191), and (192-255). These
sections clarify both the exponential power of 10 to shift the magnitude by, and also the sign of the
overall number. The four sections above correspond to (positive value, positive exponent), (positive
value, negative exponent), (negative value, positive exponent), and (negative value, negative exponent)
respectively. Furthermore, the magnitude of the exponent is given by the first byte’s value minus its
sections first value. For example the first byte 67 would show a positive overall value, a negative
exponent value, and an exponential magnitude of 3 = 67 - 64. Therefore the bytes 67, 12, 34, and 56
would signify the equation +123456 * 10^-3 and result in the value of 123.456.
State Machine
One of the main functions of the Arduino code on the outlet adapter device is to maintain a state
machine that is always synchronized with the physical outlet adapter. As seen in Figure 40, the adapter’s
state machine is a simple one with just 4 states and 8 links. Navigating between these states can be done
only by sending the adapter RF commands of the proper format as explained above. Reporting refers to
whether or not the adapter is sending its measured power values to the rest of the system. Relay on refers
to whether or not the adapter is allowing power to pass through it and turn on whatever is plugged into it.
68
Figure 40. Outlet Adapter State Machine
69
15 Integration, Testing, and Debugging
15.1 Testing Summary
Tests for this system will be used in order to ensure proper functionality of the system and its
components throughout the development process and in order to evaluate the final prototype. These tests
can be categorized as hardware tests, software tests, interface tests, user tests, or some combination, and
each category can be further divided into multiple types. Two specific tests that have been established are
the end-to-end communication test and the weekend-loop test. Additionally, a ‘fail fast’ methodology
will be used whenever possible.
A ‘fail fast’ methodology is based on the notion that the earlier in the design process a failure is,
the more capable designers are of remedying the issue. This is because less resources have been invested,
more time remains before deadlines, and less consecutive design decisions have been made that depend
on the failing component. The methodology is acted upon by scheduling frequent, small-scale tests as
early as possible during the design of the system. Even a basic proof of concept test can be invaluable
when evaluating feasibility and making design decisions.
The user interface will be tested in two distinct ways, firstly for functionality and secondly for the
quality of user experience. Functionality tests include evaluating the speed at which it communicates
with the database, confirming the accuracy of its values, and other tests. Quality tests will be done by
exposing unfamiliar individuals to each webpage and asking them to rate it using categories and one-toten scales.
The two primary ways in which the server will be tested are by measuring its speed and
robustness. Speed tests evaluate the delays between the reception of a message and the handling of that
message. They can be performed in both single message situations and message flood situations.
Robustness tests help to ensure the server can handle high volumes of information and atypical command
sequences.
Gateway testing will focus mainly on processing speed and robustness. The gateway will be
evaluated to ensure that the duration of time between its reception of a message and its sending of the
converted message is acceptably short. The gateway will also be evaluated to ensure that it can run for
long periods of time and in high-traffic situations without ceasing to function properly.
Device testing for the thermostat and outlet adapter can be categorized as object-related or
control-related. Object-related testing for the purchased thermostat will be limited; however, objectrelated testing for the outlet adapter will thorough. It will include evaluations of maximum loads,
measurement accuracy, parasitic power draw, and more. Control-related testing for both devices will be
used to ensure that system messages invoke appropriate responses in the object and to confirm that the
generation of status update messages is handled as intended.
Successful component interaction will be tested in several different ways, but the most important
of these is the end-to-end delay test. The end-to-end delay test measures the length of time between the
generation of a message on either a user interface and the reception of that message on a device; this is
also done in the opposite direction. The test also establishes a maximum passable delay duration.
Table 32 shows the description of the table title used to describe the testing. Since the testing is
not conducted fully, the testing results are not shown in the testing table.
70
Table 32. Testing Table Parameter & Their Descriptions
Name of
Parameter
Test Name
Component
Under Test
Prototype
Should Pass
Prototype Has
Already
Passed
Informally
Description
Test name
identification
Name of the
tested
component
The necessity
of passing the
test?
Informal test
has been
done?
Name of
Parameter
Test Type I
Test Type II
Test
Description
Description
The first
criteria being
tested
The second
criteria being
tested
Simple
description of
the testing
Test
Conditions
Initial
condition of
the testing
Test Measured
Value
The variable
being
measured in
the test
Name of
Parameter
Test Pass Min*
Test Pass
Max*
Description
The minimal
result of the
testing
The maximal
result of the
testing
Test Results*
The result of
the testing
Test Passed?*
The result of
the testing
15.2 Informal System Testing
One specific, holistic test that will be used to evaluate this system is the end-to-endcommunication test. This test consists of simply sending a recognizable signal, such as “hello world” or a
pattern of bit voltage levels, from device hardware through the communication modules, gateway, and
server to the phone application. This test should also be performed in the reverse direction. If successful,
the end-to-end-communication test indicates that all relevant parts of the system can feasibly be used as
intended in the system. This test should be done as early as possible in keeping with the ‘fail fast’
methodology described above.
Another specific tests that will be used to evaluate components in this system is the weekend-loop
test. It is primarily an interface test, and consists of monitoring the communication between two modules
over a period of time. For example, the gateway should be able to send an integer value to a device and
the device should be capable of responding with that same value. Upon receiving the matched
acknowledgement, the gateway will increment the integer and send it again. If this continues successfully
over the course of a weekend, it is likely capable of running stably for much longer. Table 44 in the
Appendices displays the testing that will be conducted.
15.3 Informal User Interface Testing
User testing has two main aspects, unexpected use-cases and the user experience. User tests
typically involved taking a third-party individual or random of individuals with limited knowledge of the
product, and allowing them to interact freely with the system or component under test. This was typically
most helpful when the sample users are taken from the target demographic population. User tests could
reveal unexpected use-cases for the system. New, unknowledgeable individuals were likely to attempt to
interact with the system in ways that system designers did not foresee. Additionally, the user experience
can be evaluated using user tests. By watching random users interact with the system, and by surveying
71
or interviewing them afterwards, HomeAlive gained valuable insights into the development of the
product.
The specific tests performed on the user interface includes continuous running, message flooding,
security, and consumer/user testing. These tests prove the robustness, continuous-running performance,
and security aspect of the system. Table 45 in the appendices shows the complete testing table. The user
tests was done 4 days before the project showcase. Knowledgeable users are the primary candidate
because they brought harder issues to fix such as alerts timing, delays in function, and function
breakpoints. Within a day, the HomeAlive member fixed the issue and conduct another user tests. This
time both knowledgeable and unknowledgeable users took part of the test. Minor and major changes
were needed such as cropped logo, unrelated icon, and page links. Finally, the last informal user tests was
conducted a day before the showcase.
The next test conducted was the message flooding and continuous running. The user interface
was saved on the phone browser for 1-2 days. Then the user periodically checked whether the alert
system still notify of the send command and database update. The live checking worked continuously for
6 hours as it track changes every 2 seconds. To combine the two tests, the HomeAlive member decided
to update the database once every second to check if the user interface still response correctly. In the span
of 3-6 hours, the user interface functioned well. Minor fixes needed were alert bubble blocking the
display and skipped alert. The skipped alert was fixed a day before the demonstration, but the alert
bubble required more time to fix.
The security protocol used in the user interface was a standard PHP security. HomeAlive used
the security provided by PHP as well as the POST method of the form. These protocols were deemed
sufficient for stopping minimal hacker. Brute force and sophisticated hacking system were not tested,
therefore HomeAlive could not determine the result of user interface hacker resiliency.
15.4 Informal Server Testing
Server tests focus on the server’s availability, processing speed, messaging flood response, error
message handling, and security. The processing speed tests involved the server’s timing and consistency
when the server is continuously running. The server’s internet connection strength is also an important
measure of the robustness of the server. Finally, the security testing includes checking the resilience to
inappropriate access by an unqualified party. Table 46 in the appendices shows the complete testing
table.
Each function in the server’s programs was tested using a unit test during development. After
each function was written, the function was called using various input parameters and the results were
verified. Such unit testing ensured that individual functions were correct. According to the operating
system log, the server was also proven to run around 75 days without any downtime, at which point it was
shutdown (it did not crash). The server machine worked better than originally expected considering the
dusty and unregulated temperature environment. The ambient environment seemed not to have effect on
functionality and performance of the server.
In order to test the processing speed and messaging flood response, a HomeAlive system with
two households was set up. The server received more than 240 requests per minute from multiple
gateways. The AMQP broker received those messages in real time; however, the database management
program was found to have a two minute lag due to multiple IO reads and writes. The API functions
were then revised and retested. After this, the whole server performed in real time with no significant
delays.
72
The security of the server was not explicitly tested. However, a number of additional securities
were implemented in the server. The MySQL server used user and password security system. It would
not allow logging in from unrecognized computers effectively preventing hackers. Hackers won’t be able
to hack unless they obtained HomeAlive’s computers physically. In addition, only the required ports
were open on the server. This prevents Hackers from getting access to server using unused ports. The
server also used a SSH key based connection. Each team member was provided with a 512 bit AES key
file to access the server. AES is a military standard encryption method and hacking such kind of keys
required multiple days and proven unsuccessful most of the time. In addition, RabbitMQ broker also
used its own independent user and password based security system. Thus, the server was considered to be
resilient from most hackers although no explicit tests were performed.
15.5 Informal Gateway Testing
Gateway testing is done to ensure the processing speed, hardware, software, and security of the
component are high-quality. Processing speed testing involves timing the delay between a message
reception and the sending of its converted form in both directions. Hardware testing is related to
confirming continued functionality under extreme heats, extreme colds, and also room temperature
conditions. Heat dissipation and water resistance were also be part of the hardware testing. For the
software testing, unit and module level tests were conducted to ensure that the software is reliable and
consistent. Security testing refers to checking whether a hacker could easily corrupt the operations of the
gateway. Table 47 in the appendices shows the complete gateway testing table. These tests, with the
exception of extreme temperatures, have all been passed informally by the HomeAlive prototype.
Informal passing means that the metrics by which these tests were evaluated were consistently noted in
the passing range during other, system-level testing. However, informal tests were not explicitly
performed with known control groups and careful procedures.
15.6 Informal Devices Testing
The devices’ hardware were tested throughout the design via informal unit tests, PSpice
simulations, and whole system integration tests. The software testing involved message flooding,
intentionally erroneous messages being sent, continuous running, testing the accuracy in the
measurement, rapid toggling, and unit and module tests. The design process was iterative and each time
the system grew in size informal tests were conducted. First the devices were tested in isolation from the
system, no communication with the gateway, server, or user interface. Data was sent via USB and java
test programs. Once the devices were sending and receiving data properly and the appropriate actions
were being performed in hardware, the devices were connected to the gateway and informal tests were
conducted at that level of integration. Next the devices were tested at a fully integrated level via the user
interface sending commands and viewing the results. These tests ensured the robustness, power usage,
accuracy, and software reliability of devices. Table 48 in the appendices shows the complete list of tests.
15.7 Informal Component Interaction Testing
Interface tests focus on confirming the appropriate functionality of the system’s inter-component
communications. These tests are crucial because points of component interaction tend to be both the
hardest to develop correctly and the most likely to fail over time. Interface tests include both hardware
and software tests, as described above. Hardware interface tests are performed on circuitry that connects
multiple components by transmitting signals between them. One key aspect they check is the matching
between the maximum output signal amplitude and the maximum input rating of the targeted component.
Software interface tests are performed to ensure that different programs and platforms are communicating
73
digitally as intended. This is often done by sending a target component a known signal and expecting a
certain forthcoming response.
The tests conducted for the component interaction specifically involve the XBee and AMQP
linkage. The server and the gateway will be tested on their messaging protocol security. The devices and
the gateway will be tested on their XBee resiliency. Table 49 in the appendices shows the complete
testing table.
15.8 Formal Testing
The HomeAlive project was unable to comprehensively and thoroughly complete all of their final
testing; however, a significant portion of it was still done. As described above, integrated, functional,
system testing was performed over the course of several weeks. During this testing, many of the same
conditions that would be formally present in the incomplete tests were realized. This allows the team to
declare that many of their performance tests were informally passed. Unfortunately, these performance
tests were not explicitly tested in otherwise isolated conditions due to a lack of remaining time in the
project. This lack of time ultimately stems from the team’s decision in March to pursue additional
features on both devices. The team favored the trade-off of additional functionality over more thorough
testing. Finally, the HomeAlive team was able to determine around 80 tests that should be done on the
prototype if there was enough time. These can be seen in Figures 44 to 49.
74
16 Business Plan
16.1 Mission & Vision
16.1.1 Mission for the Company
HomeAlive’s mission is to provide to homeowners accessible control of any electronic device,
smart or non-smart, through a convenient, elegant, and intuitive remote-interface.
16.1.2 Vision for the Company
HomeAlive’s vision is to make its way into the home automation market and claim a significant
portion of market share. Upon meeting this goal, HomeAlive will seek to expand its product base, which
will further HomeAlive’s presence in the market. HomeAlive seeks to become one of the top competitors
in the home automation market within ten years.
16.2 Market Survey
The home automation market has multiple established, large-company competitors; each of
whom offer similar device support and features. To complete in this market, HomeAlive will need to
differentiate its features from those competitors. Table 33 and Table 34 show existing competitors their
product features.
Table 33. Existing Competitors in the Market with Devices
Devices
Gateways
Lights Control
Contact Sensors
Motion Sensors
Water Sensor
Door Open/Close Sensor
Keypad
Outlet Adapter
Power Strip
Thermostat
Range Extender
Locks
Smoke Detector
Camera
3rd Party Support
Iris
Y
Y
Y
Y
N
N
Y
Y
N
Y
Y
N
N
Y
N
Connect
Y
Y
N
Y
Y
N
Y
Y
Y
Y
Y
Y
Y
Y
Y
Wink
N
Y
N
N
N
N
N
N
N
N
N
N
N
N
Y
Peq
Y
Y
Y
Y
Y
N
N
Y
N
Y
N
Y
N
N
N
Smart things
Y
Y
Y
Y
Y
Y
Y
Y
Y
Y
Y
Y
Y
Y
Y
Table 34. Features Comparison among Commercially Available Home Automation Systems
Features
Iris
Connect
Wink
Peq
Smart things
Basic Control
Y
Y
Y
Y
Y
Notification
Y
N
N
N
Y
Video Camera
Y
N
N
N
Y
Customizing Rule Set
Y
N
N
N
Y
Voice Control
Y
N
N
N
Y
16.3 Market Sizes & Trends
HomeAlive is targeted towards both new and previous homeowners. Several smart home
products already exist, such as Google’s Nest, Philip’s Hue light bulbs, Apple’s HomeKit, and others.
75
However, there is a lack of seamless system integration that would allow the connection of all devices.
The home automation market has been changing in order to address that gap. Lowe’s Iris is an example
of such an attempt; HomeAlive’s product will be another.
The smart home market was valued at $33 billion in 2013, and is expected to boom to $71 billion
by 2018 according to Juniper Research. The recent market entrants such as Apple (HomeKit), Google
(Nest), and BestBuy (Peq) have strengthened the market; it is clear that the smart home market is
increasingly valuable.
16.4 Potential Customers & Target Market
HomeAlive targets both new and existing homeowners as potential customers. The specific
target market focuses on homeowners who have disposable income, familiarity with electronic devices, or
margin to gain from increased accessibility to devices.
16.5 Competitive Strategy
HomeAlive seeks to compete based on differentiation. Competing based on cost would not be
feasible due to the presence of large-company competitors already in the market. Competing based on
response would not be as applicable to this product as differentiation for the reasons explained below.
16.5.1 Differentiation
Customers will want to buy home automation product based on up-to-date technology, ease of
access, and reliability. HomeAlive provides ease of access by creating intuitive and elegant interfaces.
Other key differentiation that HomeAlive focuses especially on customer experience and environmental
sustainability of HomeAlive products.
16.5.2 Response
HomeAlive’s system design has similar scale compared to other home automation products. This
fact leads to a need for better control and focus. HomeAlive brings more flexibility to customers who
have prior home technology devices than other products do. HomeAlive offers embedded technology that
connects all home devices with the gateway, which helps with increasing ease of access and the apparent
quickness of HomeAlive’s products.
16.6 SWOT Analysis
16.6.1 Strengths
HomeAlive is built by a passionate and motivated team, which is reflected in the product. The
home automation market has a large potential for new product growth and HomeAlive will use this to
gain market traction throughout development and support of new devices. Large company bureaucracy
will not slow the team down; instead, necessary design modifications will be made quickly and
effectively.
16.6.2 Weaknesses
HomeAlive is not a recognized name and its executives are not experienced in the market. In the
early stages of production, due to lack of name recognition and a small customer base, the cost for
HomeAlive will be more expensive. This will be true until demand reaches high enough levels to use
economies of scale to lower production costs.
16.6.3 External Opportunities
The market that HomeAlive focuses on is relatively new and broad. Rapid technology
improvements help the current generation to become familiar when handling technology. This trend is an
excellent opportunity for HomeAlive to emerge into the market. New homeowners with higher
76
disposable incomes and who have gadgets are the main target. The uniqueness of HomeAlive’s products
will attract additional customers.
16.6.4 External Threats
The competition with the established brand products offered by competitors is a strong threat to
HomeAlive. They are well funded and have more resources in their research and development branches.
Another threat is the lack of differentiation between the home automation products currently on the
market. Customers who have home automation devices might not be interested in buying HomeAlive’s
products. In order to maintain market share, HomeAlive needs to build customer loyalty and focus on
having a flawless product.
16.7 Cost Estimate
16.7.1 Development
This section provides a detailed account of the expenditures for the HomeAlive project over the
course of the 2014-2015 school year. Table 3 contains every expenditure for the mentioned time period.
16.7.2 Production
This section estimates the cost to produce the HomeAlive system. This includes development,
manufacturing, operating, and capital expenditures. The purpose of this is to derive the cost to produce
each unit.
16.7.2.1 Financial Forecasts
16.7.2.1.1 Key assumptions
HomeAlive LLC’s financial forecasts are based on several key assumptions. Most of the
financial predictions are either directly or indirectly based on the revenue received. The assumed revenue
affects the cash flows, the amount of money requested, the Gross Margin, Profit Margin on Sales, Total
Asset Turnover, Debt to Asset Ratio, and Break even analysis. Each year has its own amount of product
produce. The product is assumed to be sold and collected as revenue spaced over four quarters. It is
assumed that in the year it was produced 16% (1/6) will be sold in the third quarter and 50% (1/2) in the
fourth. Then, in the year following in the first quarter 8% (1/12) will be sold and in the second quarter the
final 25% (1/4) will be sold. See Appendix Figures 55 - 57 for the quarterly Cash Flow Statement and its
explanation Figure 58. The forecasts assume the necessary loans will be received, and the calculations for
paying back the loans are made assuming 10% interest on the principal. HomeAlive LLC assumes that it
will break even upon selling 18,021 starter kits and 4,505 servers. Along with this assumption is the
supposition that for every four starter kits purchased one server will be sold.
16.7.2.1.2 Financial statements
16.7.2.1.2.1
Income statement
An income sheet highlights the profit or loss of a company over a period of time. HomeAlive
LLC’s Pro-Forma Statement of Income, Figure 41, shows a positive net income in each year. Assuming
sales revenue picks up in the third and fourth quarter of the first year, HomeAlive LLC should be able to
make a profit in the first year. The second and third years see an increase in profit through increasing
production.
77
Figure 41. Statement of Income.
16.7.2.2 Cash Flow Statement
A cash flow is found by taking the amount of cash for a given period and subtracting all of the
fixed and variable cost. This is the bottom line amount of cash in the bank account. This number should
not be negative. If it is the company cannot pay its bills.
HomeAlive LLC has negative cash flow in the first three quarters. This is from the cost of
starting and lack of revenue. To pay the bills HomeAlive LLC must take out a loan for $1,120,000 in the
first quarter and $1,220,000 in the second quarter.
HomeAlive LLC seeks to maximize its total asset turnover. While it is a good idea to have some
capital reserved for emergencies, large sums of cash that is not being used to generate more revenue is
being wasted. In year 2 and 3 HomeAlive LLC’s bank account gets larger. This cash will be used to
launch other products such as devices that may be coupled with HomeAlive LLC starter kit. This cash
will also be used to expand and increase production.
See Appendix for a quarterly Cash Flow Statements, Figures 54 -58.
Figure 42. Statement of Cash Flows
78
16.7.3 Break-even analysis
The fundamental question to answer when proposing a business is how much product needs to be
made, assuming it all sells, in order to cover the fixed and variable costs. This is the point where the
finances are netted to zero. This is called break-even analysis.
HomeAlive LLC has two products it sells. The starter kit is sold for $125 and comes with an offsite server rental fee included. If a homeowner wants to own the server one may be purchased for $175.
This server comes with the software downloaded onto it. HomeAlive LLC uses a model that predicts
25% of customers who buy a starter kit will also buy a server. Using this information HomeAlive LLC
needs to sell 18,021 starter kits and 4505 servers in the first year, 18,745 starter kits and 4,686 servers in
the second year, and 17365 starter kits and 4341 servers in the third year. For details see Figure 52 - 58 in
the Appendix.
16.7.4 Ratio Analysis
HomeAlive LLC uses the following four ratios (quarterly gross margin, profit margin, asset
turnover, and debt to asset ratio) to measure the health, growth, and asset management of the company.
See the Appendix for a sheet containing quarterly ratios, Figure 43. Also see Appendix for an
explanation of how each of these ratios are calculated, Figure 59 - 60.
Figure 43. Ratio Analysis.
The gross and profit margins are low in the first quarter of each year. This is because revenues
are down after the holiday season. They improve in the second quarter with predicted increase revenue.
In the third quarter many people are on vacation and revenue is down again. Finally in the fourth quarter
these margins are high. Revenues increase with the holiday season boosting these margins.
79
The total asset turnover is very poor until revenues start coming in the third quarter. This ratio is
best in the early second year. The third year could improve by reinvesting the cash asset into other
products as mentioned earlier.
The debt to asset ratio is the worst at the beginning. Startup costs are not covered by revenues
until the third quarter. It takes well into the second year before the debt of startup is paid off.
16.7.4.1.1 Unit Price
The material costs can be found in Figures 47 and 48 in the Appendix. Figure 44 shows the sell
price for a starter kit and server. The cost of goods sold and operating costs for the first three years can be
found in Figure 52 in the Appendix. The fixed and variable cost can be found in Figures 49 in the
Appendix. For further information on the pricing see the business report downloadable from the team
website.
Figure 44. Revenue Sheet – If Everything Produced In a Year Is Sold In That Year
16.7.4.2 Loan or Investment Proposal
16.7.4.2.1 Funds Requested
HomeAlive LLC will not seek to use any money from its leadership. This will allow for
decisions to be made without the effect of personal agendas. HomeAlive LLC will need some capital to
start. Thus, a loan for $1,120,000 will be taken out and $1,220,000 in the second quarter.
16.7.4.2.2 Purpose & Uses of Funds
These loans will pay for all of the cost of the operations. This includes fixed and variable costs,
equipment, etc.
16.7.4.2.3 Repayment or "Cash Out" Schedule
In the event of HomeAlive LLC is splitting, assuming the loans have already been paid back,
HomeAlive LLC can easily dissolve its assets. This is because cash will be the biggest asset. HomeAlive
LLC has very little equipment or facilities that it owns. The strategy would be to pay off any outstanding
debts and split the remaining assets with the employees based on rank in the company.
80
17 Conclusion
17.1 Future Tasks
Over the course of this project many features were thought of and even considered, but ultimately
did not make it into the scope of the project for various reasons such as the complexity of designing them,
the time required to implement them, or the cost of implementing them. The features may have been out
of the project scope but are still worth mentioning as a means of articulating the level of thought put into
this project and also as future tasks for any group wanting to further this project.
17.1.1 User Interface
The user interface has endless major and minor future tasks. The HomeAlive user interface
provided good functionality and performance, but further improvements are needed. More graphing
displays could be added to plot thermostat history data and outlet voltage. In the case of additional
devices such as coffee maker and washing machine, the graphing history of their usage could be
displayed in the user interface.
HomeAlive did not create applications for specific operating systems because they are out of the
scope and not universal. Certain features can be maximized if applications are used as the user interface.
One of the example is the setting/customization of the themes and additional devices. However, in terms
of functionality and performance, website is sufficient.
One of the most fascinating update for the user interface is the customizable modes. This feature
will allow a particular user to set his/her favorite settings for a specific device. This feature involves
updating the server to allow more database variables. Some examples are setting of room temperature
and setting of the coffee maker. Another related improvement for the customizable mode is to allow
scheduling for all of the devices including outlet adapter. This allows the outlet to automatically turn off
and on at certain times of the day. Again, the server needs to comprehend this new scheduling feature.
Table 35 shows the summary of the future and finished work of user interface.
81
Table 35. User Interface Tasks
Task
Inside Scope Task Applied
Graph of thermostat history
Yes
No
Graph of outlet history
Yes
Yes
Graph of additional devices
No
No
Applications for user interface
No
No
Customizable modes
No
No
Outlet Scheduling
Yes
No
Sends input forms
Yes
Yes
Hides unselected features
Yes
Yes
Receives database data
Yes
Yes
Follows the original theme view
Yes
Yes
Alerts user for changes
Yes
Yes
Accessible worldwide
Yes
Yes
17.1.2 Server
The server could be improved to provide a more advanced messaging algorithms. This improved
algorithm allows the server to choose which commands should be sent before others. In other words, the
priority queuing system will help each household to function efficiently. It would utilized the strengths of
MySQL database.
Second, the server can implement the multithreading/multiprocessing method for the database
manager. This will allow the server to operate faster depending on the server’s processing speed. With
the technological update in the computing world, the server could have twice to three times faster every
year. In order to fully implement the multithreading method, a more suitable programming language can
be used. HomeAlive decided to use PHP as their programming language. Java and Python can be used in
the future.
82
Third, the database could be improved to accommodate the changes in the user interface. Some
future improvements listed for user interface are scheduling and customizable mode. These features
require more tables in the database as well as more processing strength as the network traffic will increase
by two fold per device. Table 36 shows the summary of the future and finished work of server.
Table 36. Server Tasks
Task
Inside Scope
Task Applied
Advanced messaging algorithms
No
No
Multithreading/multiprocessing
No
No
Add scheduling database table
Yes
No
Handle status request from User Interface
Yes
Yes
Handle status request from the Gateway
Yes
Yes
Handle request to register commands in the database
Yes
Yes
Handle request to register status of the devices in the database
Yes
Yes
Host an AMQP server
Yes
Yes
Host a database
Yes
Yes
Database structure
Yes
Yes
Message Integrity
Yes
Yes
Send message to the gateway
Yes
Yes
Receive message from the gateway
Yes
Yes
17.1.3 Gateway
The gateway needs future improvements if the number of devices increase. There is a low chance
that the gateway is unable to handle more devices. In the case that more devices means worst gateway
performance, a future improvement has to be implemented. Table 37 shows the summary of the future
and finished work of gateway.
83
Table 37. Gateway Tasks
Task
Inside Scope
Task Applied
Improve gateway performance if devices are
added
No
No
Converts messages from AMQP to DigiMesh
Yes
Yes
Converts messages from DigiMesh to AMQP
Yes
Yes
Receives and sends DigiMesh messages
Yes
Yes
Receives and sends AMQP messages
Yes
Yes
Does not alter or confuse messages
Yes
Yes
17.1.4 Devices
The devices that can be added into the system are endless. The increase in number of electronic
appliances makes HomeAlive opportunity to expand bigger. Coffee maker and lighting system are the
main consideration when HomeAlive decided on their scope. These devices are considered as essential
devices because most users will use them almost every day. Furthermore, robot vacuum, lawnmower,
washing machine, and mp3 player are other devices that could be added in the future. Table 38 shows the
summary of the future and finished work of devices.
Table 38. Devices Tasks
Task
Inside Scope Task Applied
Implement a coffee maker
No
No
Implement a lighting system
Yes
No
Implement additional devices
No
No
Implement a thermostat
Yes
Yes
Implement an outlet adapter
Yes
Yes
17.1.4.1 Thermostat
The improvement for thermostat involves a flawless manual button reading. The long pressing of
buttons in the thermostat are not recorded in the system. This improvement will provide a better system
synchronization in the future. In addition, the thermostat could provide the data of the current room
temperature. The gateway, server, and user interface can then accommodate this new variable to allow
user to see almost all the data that they need. Furthermore, the casing of the thermostat and the
processing unit can be improved in the future. Table 39 shows the summary of the future and finished
work of thermostat device.
84
Table 39. Thermostat Tasks
Task
Inside Scope Task Applied
Gives current room temperature
No
No
Physical Button Pressing
Yes
Yes
Electrical Button Pressing
Yes
Yes
Remember previous settings & calibration
Yes
Yes
Bidirectional Communication
Yes
Yes
Wireless Communication (DigiMesh)
Yes
Yes
Safe to use
Yes
Yes
17.1.4.2 Outlet Adapter
The outlet adapter will need more calibration in the future to provide a more accurate voltage and
current reading. This will allow the user to compare their monthly electricity bill with their outlet history
record. Additionally, the outlet adapter should have its own display of power usage and switch. This will
give two options for the user: control from the home manager or directly control the outlet. The outlet
will need a safer casing in the future as well as smaller circuit board design. Table 40 shows the summary
of the future and finished work of outlet adapter.
Table 40. Outlet Adapter Tasks
Task
Inside Scope
Task Applied
Conduct more calibration
Yes
No
Displays the power usage and switch
No
No
Smaller circuit design
No
No
Measure Power (VA)
Yes
Yes
Turn On & Off
Yes
Yes
Remember previous settings & calibration
Yes
Yes
Bidirectional Communication
Yes
Yes
Wireless Communication (DigiMesh)
Yes
Yes
Safe to use
Yes
Yes
Dimensions
Yes
Yes
17.1.5 System Level
HomeAlive did not focus on adding extra layer of security in their user interface, server, and
gateway. This will certainly improve the hacker resiliency as well as robustness of the overall system. In
85
the future, more powerful server and gateway will allow for devices on the market to be integrated into
HomeAlive system.
An integration of more devices including coffee makers, electronic door locks, garage doors,
lighting system, and others are favorable compared to adding the number of same devices. After further
testing of these new devices, HomeAlive could improve by allowing new devices to be “synced” to the
system with ease. This pairing system are popular and favorable compared to predefined device
connection. Table 41 shows the summary of the future and finished work of system level.
Table 41. System Level Tasks
Task
Inside Scope
Task Applied
Increase security layer
No
No
Handles more devices than 4
No
No
Easy pairing system
No
No
Allows remote control of prototype devices
Yes
Yes
Allows multiple distinct devices
Yes
Yes
Allows multiple distinct households
Yes
Yes
Scalable to multiple distinct user interfaces
Yes
Yes
Scalable to 256 devices per household
Yes
Yes
Scalable to numerous households
Yes
Yes
17.1.6 System Testing
The improvements for the system testing involves more number of houses. Before increasing the
number of prototype household, HomeAlive needs to improve their server, gateway, and devices. This
improvement will give more efficient replication as well as better performance and features. The cost of
will also decrease which mostly depend on the PCB design. Table 42 shows the summary of the future
work of system testing.
Table 42. System Testing Tasks
Task
Inside Scope
Task Applied
Increase number of house prototype
No
No
17.2 Summary
17.2.1 Lessons Learned
Throughout the HomeAlive project, the team members learned numerous valuable lessons related
to both technical details and team-oriented project details. The most notable of these are summarized in
Table 43 below.
86
Table 43. Lessons Learned Summary
Lesson
Order spare parts
Leave schedule space for
mistakes
Multithreading in Java
UI development
Backend database design
Communicate purposefully
Recognize external schedule
factors
PCB fabrication challenges
Team responsibility
Predict shipping delays
Description
It is important to order spare parts in case anything
critical breaks.
It is important to plan for unexpected delays when setting
up a preliminary schedule – also ensure that the schedule
is reevaluated frequently.
Java multithreading using the synchronization keyword is
one of the simplest ways to implement thread-safe
programs.
Developing a user interface is challenging and
incorporeal. Its requirements depend to some extent on
different users, and there are numerous open-source tools
for UI construction.
Having a carefully constructed database format increases
the reliability and scalability of the system that it is a part
of.
Ensuring that each team member receives all information
that they require to efficiently perform their tasks is
critical to the success of a project.
Planning for external schedule interferences like known
holidays or periods of team member busyness is
important to building a realistic schedule.
Moving from a fully functional breadboard circuit design
to a PCB is often much more difficult than simply
etching and populating the PCB. Debugging PCBs is
difficult.
Working on a team where each member can be relied
upon to complete their tasks on time and in a quality
manner helps to define a good project and encourages a
great result.
It is important to be aware of shipping delays when
determining when to order new parts, otherwise stagnant
periods of waiting for shipments could occur.
Type
Project
Project
Technical
Technical
Technical
Team
Project
Technical
Team
Project
17.2.2 Project Status
The HomeAlive project has been successfully completed as of 5/13/2015. This includes
submission of all deliverables to the project faculty advisor as well as participation in all of the project
speeches, demonstrations, and events. The HomeAlive team was able to successfully implement their
prototype home automation system including four devices, two gateways, the server, and a user interface.
These interacted primarily as expected with a few minor bugs remaining. The project will not be
continued in a definite way; however, personal experimentation with home automation systems by the
team members based on this project is expected.
87
18 Appendices
Figure 45. Thermostat Device PCB Layout
Figure 46. Outlet Adapter PCB Layout
88
Table 44. Whole System Testing
Prototype
Has
Already
Passed
Informally
Test Type I
Test Type II
Processing
Speed &
Signal Delays
Test Name
Component
Under Test
Prototype
Should
Pass
End-to-End Delay Single
(up)
Whole System
Yes
Maybe
Timing
End-to-End Delay Flood
(up)
Whole System
Yes
No
Timing
End-to-End Delay Single
(down)
Whole System
Yes
Yes
Timing
End-to-End Delay Flood
(down)
Whole System
Yes
No
Timing
Gateway Unexpected
Shutdown Recovery
Whole System
Yes
Maybe
Unexpected
Shutdown
Server Unexpected
Shutdown Recovery
Whole System
Yes
No
Thermostat Unexpected
Shutdown Recovery
Whole System
Yes
Outlet Adapter
Unexpected Shutdown
Recovery
Whole System
Knowledgeable User
Testing (All)
Unknowledgeable User
Testing (All)
Test
Conditions
Test Measured
Value
Does the whole system work fast
enough for single messages? (d->ui)
Normal
Time from device sent
to UI received
Does the whole system work fast
enough for many messages? (d->ui)
Flood, rest
normal
Time from device sent
to UI received
Does the whole system work fast
enough for single messages? (ui->d)
Normal
Time from UI sent to
device received
Does the whole system work fast
enough for many messages? (ui->d)
Flood, rest
normal
Time from UI sent to
device received
Unexpected
Use-case
Can the system recover from an
unexpected shutdown of the gateway?
Unexpected
restart, rest
normal
Unexpected
Shutdown
Unexpected
Use-case
Can the system recover from an
unexpected shutdown of the server?
Unexpected
restart, rest
normal
Maybe
Unexpected
Shutdown
Unexpected
Use-case
Can the system recover from an
unexpected shutdown of the
thermostat?
Unexpected
restart, rest
normal
Yes
No
Unexpected
Shutdown
Unexpected
Use-case
Can the system recover from an
unexpected shutdown of the adapter?
Unexpected
restart, rest
normal
Whole System
Yes
Maybe
Robustness
User Testing
Have knowledgeable users evaluated
the system experience?
Normal
Some sort of survey
with scales of 1-10?
Whole System
Yes
No
Robustness
User Testing
Have unknowledgeable users evaluated
the system experience?
Normal
Some sort of survey
with scales of 1-10?
Processing
Speed &
Signal Delays
Processing
Speed &
Signal Delays
Processing
Speed &
Signal Delays
Test Description
Time until operation
resumes, number of
missed/corrupted
messages
Time until operation
resumes, number of
missed/corrupted
messages
Time until operation
resumes, number of
missed/corrupted
messages
Time until operation
resumes, number of
missed/corrupted
messages
89
Table 45. User Interface Testing
Test Name
Component
Under Test
Prototype
Should
Pass
Prototype
Has
Already
Passed
Informally
Test Description
Test Type I
Test Type II
Can the UI continue to operate
effectively during a received
message flood?
Test
Conditions
Test Measured Value
Flood, rest
normal
Number of
messages/time before
operation stopped or
disturbed
Long times,
rest normal
Time until operation
stopped or disturbed
Normal
Intangible…
UI Message Flood
User Interface
Yes
No
Robustness
Possible
Use-case
UI Continuous
Running
User Interface
Yes
No
Continuous
-Running
Expected
Use-case
UI Hacker Resilience
User Interface
No
No
Security
Custom
Security
Knowledgeable User
Testing (UI)
User Interface
Yes
Maybe
Robustness
User
Testing
Have knowledgeable users
evaluated the UI experience?
Normal
Some sort of survey
with scales of 1-10?
Unknowledgeable
User Testing (UI)
User Interface
Yes
No
Robustness
User
Testing
Have unknowledgeable users
evaluated the UI experience?
Normal
Some sort of survey
with scales of 1-10?
Can the UI continue to operate
effectively after long periods of
run time?
How hard would it be to 'hack'
the system via the userinterface?
90
Table 46. Server Testing
Component
Under Test
Prototype
Should
Pass
Prototype
Has
Already
Passed
Informally
Test Type I
Test Type II
Test Description
Test
Conditions
Test Measured
Value
Server Processing
Speed (up)
Server
Yes
Maybe
Timing
Processing
Speed
Does the server process gateway
messages at an acceptable rate?
Normal
Time from received
to processed
Server Processing
Speed (down)
Server
Yes
Yes
Timing
Processing
Speed
Does the server process UI
messages at an acceptable rate?
Normal
Time from received
to processed
Test Name
Server Message
Flood
Server
Yes
Maybe
Robustness
Possible
Use-case
Server Bad Message
Discard
Server
No
No
Robustness
Unexpected
Use-case
Server Continuous
Running
Server
Yes
Maybe
Continuous
-Running
Expected
Use-case
Server Internet
Connection Strength
Server
Maybe
Yes
Robustness
Unexpected
Use-case
Server Hacker
Resilience
Server
No
No
Security
Custom
Security
Can the server continue to
operate effectively during a
received message flood?
Can the server continue to
operate effectively after receiving
a bad message?
Can the server continue to
operate effectively after long
periods of run time?
What is the server internet
connection speed?
How hard would it be to 'hack'
the system via the server's
internet connection?
Flood, rest
normal
Bad message,
rest normal
Long times,
rest normal
Normal
Normal
Number of
messages/time
before operation
stopped or
disturbed
Continued
operation as
expected
Time until
operation stopped
or disturbed
Connection speed
(kbits/s ?)
Intangible…
91
Table 47. Gateway Testing
Component
Under Test
Prototype
Should
Pass
Prototype
Has
Already
Passed
Informally
Test Type I
Test Type II
Test Description
Test
Conditions
Test Measured
Value
Gateway Processing
Speed (up)
Gateway
Yes
Yes
Timing
Processing
Speed
Does the gateway process device
messages at an acceptable rate?
Normal
Time from received
to resent
Gateway Processing
Speed (down)
Gateway
Yes
Yes
Timing
Processing
Speed
Does the gateway process server
messages at an acceptable rate?
Normal
Time from received
to resent
Does the gateway work in
conditions of extreme heat?
Hot, rest
normal
Test Name
Gateway Extreme
Heat Resilience
Gateway
No
No
Ambient
Unexpected
Use-case
Gateway Extreme
Cool Resilience
Gateway
No
No
Ambient
Unexpected
Use-case
Does the gateway work in
conditions of extreme cold?
Cold, rest
normal
Gateway Room Temp
Operation
Gateway
Yes
Yes
Ambient
Expected
Use-case
Does the gateway work in
conditions of typical heat?
Normal
Gateway Water
Resistance
Gateway
Maybe
No
Ambient
Unexpected
Use-case
Does the gateway work if it gets
wet?
Wet, rest
normal
Gateway Heat
Dissipation
Gateway
Yes
No
Continuous
-Running
Expected
Use-case
Does the gateway dissipate heat
fast enough to run forever
without overheating?
Long times,
rest normal
Gateway Message
Flood
Gateway
Yes
Yes
Robustness
Possible
Use-case
Can the gateway continue to
operate effectively during a
received message flood?
Flood, rest
normal
Gateway Bad
Message Discard
Gateway
No
No
Robustness
Unexpected
Use-case
Can the gateway continue to
operate effectively after receiving
a bad message?
Bad message,
rest normal
Temperature max
before operation
stopped or
disturbed
Temperature min
before operation
stopped or
disturbed
Continued
operation as
expected
Amount of water
before operation
stopped or
disturbed
Equilibrium
temperature
reached for 'busy'
and 'idle' periods
Number of
messages/time
before operation
stopped or
disturbed
Continued
operation as
expected
92
Prototype
Has
Already
Passed
Informally
Test Type I
Test Type II
Test Name
Component
Under Test
Prototype
Should
Pass
Gateway Continuous
Running
Gateway
Yes
Maybe
Continuous
-Running
Expected
Use-case
Gateway Internet
Connection Strength
Gateway
Maybe
Yes
Robustness
Unexpected
Use-case
Gateway Hacker
Resilience
Gateway
No
No
Security
Custom
Security
Physical
Strength
Does the gateway's casing
adequately protect its circuitry?
Test Description
Can the gateway continue to
operate effectively after long
periods of run time?
What is the gateway internet
connection speed?
How hard would it be to 'hack'
the system via the gateway's
internet connection?
Gateway Casing
Strength
Gateway
Maybe
No
Physical
Strength
Gateway SW Unit
Tests
Gateway
No
No
Software
Unit Tests
Has the gateway SW passed
thorough unit tests?
Gateway SW Module
Tests
Gateway
Maybe
Maybe
Software
Module
Tests
Has the gateway SW passed
module-level tests?
Test
Conditions
Long times,
rest normal
Normal
Normal
Typical
impact, rest
normal
All possible
cases
All normal
and likely
invalid cases
Test Measured
Value
Time until
operation stopped
or disturbed
Connection speed
(kbits/s ?)
Intangible…
Force of impact
before operation
stopped or
disturbed
SW-defined tests
pass rate %
SW-defined tests
pass rate %
93
Table 48. Devices Testing
Prototype
Has
Already
Passed
Informally
Test Type I
Test Type II
Test Name
Component
Under Test
Prototype
Should
Pass
Thermostat Extreme
Heat Resilience
Thermostat
No
No
Ambient
Unexpected
Use-case
Does the thermostat work in
conditions of extreme heat?
Hot, rest
normal
Thermostat Extreme
Cool Resilience
Thermostat
No
No
Ambient
Unexpected
Use-case
Does the thermostat work in
conditions of extreme cold?
Cold, rest
normal
Thermostat Room
Temp Operation
Thermostat
Yes
Yes
Ambient
Expected
Use-case
Does the thermostat work in
conditions of typical heat?
Normal
Thermostat Water
Resistance
Thermostat
No
No
Ambient
Unexpected
Use-case
Does the thermostat work if it
gets wet?
Wet, rest
normal
Thermostat Heat
Dissipation
Thermostat
Yes
No
Continuous
-Running
Expected
Use-case
Does the thermostat dissipate
heat fast enough to run
forever without overheating?
Long times,
rest normal
Thermostat Arduino
Battery Life
Thermostat
Yes
No
Power
Usage
Expected
Use-case
Is the thermostat's Arduino
battery life sufficient?
Normal
Thermostat Arduino
Spike Resilience
Thermostat
Maybe
No
Power
Usage
Unexpected
Use-case
Do power spikes destroy the
thermostat's control circuit?
Power spike,
rest normal
Thermostat Message
Flood
Thermostat
Yes
Maybe
Robustness
Possible
Use-case
Can the thermostat continue
to operate effectively during
a received message flood?
Flood, rest
normal
Thermostat Bad
Message Discard
Thermostat
No
No
Robustness
Unexpected
Use-case
Thermostat
Continuous Running
Thermostat
Yes
No
Continuous
-Running
Expected
Use-case
Thermostat Casing
Strength
Thermostat
Maybe
No
Physical
Strength
Physical
Strength
Test Description
Can the thermostat continue
to operate effectively after
receiving a bad message?
Can the thermostat continue
to operate effectively after
long periods of run time?
Does the thermostat's casing
adequately protect its
circuitry?
Test
Conditions
Test Measured Value
Temperature max
before operation
stopped or disturbed
Temperature min
before operation
stopped or disturbed
Continued operation
as expected
Amount of water
before operation
stopped or disturbed
Equilibrium
temperature reached
for 'busy' and 'idle'
periods
Time from full charge
to battery death
Continued operation
as expected or fuse
blown
Number of
messages/time before
operation stopped or
disturbed
Bad message,
rest normal
Continued operation
as expected
Long times,
rest normal
Time until operation
stopped or disturbed
Typical impact,
rest normal
Force of impact before
operation stopped or
disturbed
94
Prototype
Has
Already
Passed
Informally
Test Type I
Test Type II
Test Name
Component
Under Test
Prototype
Should
Pass
Thermostat SW Unit
Tests
Thermostat
No
No
Software
Unit Tests
Has the thermostat SW
passed thorough unit tests?
Thermostat SW
Module Tests
Thermostat
Maybe
Maybe
Software
Module
Tests
Has the thermostat SW
passed module-level tests?
Test Description
Test
Conditions
All possible
cases
All normal and
likely invalid
cases
Thermostat
Yes
Maybe
Robustness
User Testing
Does the system allow
manual button presses on the
thermostat and handle them
without getting out of sync?
Outlet
Adapter
No
No
Ambient
Unexpected
Use-case
Does the adapter work in
conditions of extreme heat?
Hot, rest
normal
Outlet
Adapter
No
No
Ambient
Unexpected
Use-case
Does the adapter work in
conditions of extreme cold?
Cold, rest
normal
Outlet
Adapter
Yes
Yes
Ambient
Expected
Use-case
Does the adapter work in
conditions of typical heat?
Normal
Outlet Adapter
Water Resistance
Outlet
Adapter
No
No
Ambient
Unexpected
Use-case
Does the adapter work if it
gets wet?
Wet, rest
normal
Outlet Adapter Heat
Dissipation
Outlet
Adapter
Yes
No
Continuous
-Running
Expected
Use-case
Does the adapter dissipate
heat fast enough to run
forever without overheating?
Long times,
rest normal
Outlet Adapter Spike
Resilience
Outlet
Adapter
Yes
No
Power
Usage
Unexpected
Use-case
Do power spikes destroy the
adapter?
Power spike,
rest normal
Outlet Adapter
Message Flood
Outlet
Adapter
Yes
No
Robustness
Possible
Use-case
Can the adapter continue to
operate effectively during a
received message flood?
Flood, rest
normal
Outlet Adapter bad
Message Discard
Outlet
Adapter
No
No
Robustness
Unexpected
Use-case
Can the adapter continue to
operate effectively after
receiving a bad message?
Bad message,
rest normal
Thermostat Manual
Read Syncing
Outlet Adapter
Extreme Heat
Resilience
Outlet Adapter
Extreme Cool
Resilience
Outlet Adapter Room
Temp Operation
Normal
Test Measured Value
SW-defined tests pass
rate %
SW-defined tests pass
rate %
Continued operation
as expected
Temperature max
before operation
stopped or disturbed
Temperature min
before operation
stopped or disturbed
Continued operation
as expected
Amount of water
before operation
stopped or disturbed
Equilibrium
temperature reached
for 'busy' and 'idle'
periods
Continued operation
as expected or fuse
blown
Number of
messages/time before
operation stopped or
disturbed
Continued operation
as expected
95
Prototype
Has
Already
Passed
Informally
Test Type I
Test Type II
Test Name
Component
Under Test
Prototype
Should
Pass
Outlet Adapter
Continuous Running
Outlet
Adapter
Yes
No
Continuous
-Running
Expected
Use-case
Outlet Adapter
Measurement
Accuracy (typical)
Outlet
Adapter
Yes
Maybe
Accuracy
Expected
Use-case
Outlet Adapter
Measurement
Accuracy (atypical)
Outlet
Adapter
Accuracy
Unexpected
Use-case
Outlet Adapter Rapid
Toggling
Outlet
Adapter
Yes
No
Robustness
Possible
Use-case
Outlet Adapter
Casing Strength
Outlet
Adapter
Maybe
No
Physical
Strength
Physical
Strength
Outlet Adapter SW
Unit Tests
Outlet
Adapter
No
No
Software
Unit Tests
Outlet Adapter
Module Tests
Outlet
Adapter
Maybe
No
Software
Module
Tests
Yes
No
Test
Conditions
Test Measured Value
Long times,
rest normal
Time until operation
stopped or disturbed
Normal
Difference between
measured wattage
and actual wattage
Does the adapter accurately
measure power in the
unexpected range?
Higher/lower
wattage
plugged in, rest
normal
Difference between
measured wattage
and actual wattage
Does rapidly plugging and
unplugging the adapter
destroy it?
Plugged/unplu
gged rapidly,
rest normal
Test Description
Can the adapter continue to
operate effectively after long
periods of run time?
Does the adapter accurately
measure power in the
expected range?
Does the adapter's casing
adequately protect its
circuitry?
Has the adapter SW passed
thorough unit tests?
Has the adapter SW passed
module-level tests?
Typical impact,
rest normal
All possible
cases
All normal and
likely invalid
cases
Time between plug
and unplug before
operation stopped or
disturbed (fuse blown)
Force of impact before
operation stopped or
disturbed
SW-defined tests pass
rate %
SW-defined tests pass
rate %
96
Table 49. Interface Testing
Component Under
Test
Prototype
Should
Pass
Prototype
Has
Already
Passed
Informally
Test Type I
Test Type II
UI Multiple Identical
Logins
Link UI/Server
Yes
No
Robustness
Possible Usecase
UI Multiple Separate
Logins
Link UI/Server
Yes
No
Accuracy
Expected Usecase
Maybe
Yes
Security
Yes
No
Range
Yes
No
Range
Yes
No
Range
Yes
Maybe
Range
Yes
No
Range
Test Name
AMQP Hacker
Resilience
Test Description
Built-in
Security
Signal
Strength
Signal
Strength
Signal
Strength
Signal
Strength
Signal
Accuracy
Can the system handle multiple
logins of the same household on
separate different devices?
Can the system handle multiple
logins of the different households
on different devices?
How hard would it be to 'hack' the
system via the AMQP clients?
What are the XBee Pro chips
range?
Do the XBee Pro chips have an
acceptable range?
What are the XBee Std chips
range?
Do the XBee Std chips have an
acceptable range?
Do the XBee Pro chips work in
noisy environments?
Test
Conditions
Test Measured Value
Normal
Continued operation as
expected or feedback
message
Normal
Continued operation as
expected
Normal
Intangible…
XBee Pro Noise
Resilience
Link
Server/Gateway
Link
Device/Gateway
Link
Device/Gateway
Link
Device/Gateway
Link
Device/Gateway
Link
Device/Gateway
XBee Pro Interference
Resilience
Link
Device/Gateway
Yes
No
Range
Signal
Accuracy
Do the XBee Pro chips work in
dampened environments?
XBee Std Noise
Resilience
Link
Device/Gateway
Yes
No
Range
Signal
Accuracy
Do the XBee Std chips work in
noisy environments?
XBee Std Interference
Resilience
Link
Device/Gateway
Yes
No
Range
Signal
Accuracy
Do the XBee Std chips work in
dampened environments?
XBee Mesh Range
Effect
Link
Device/Gateway
Yes
Yes
Range
Signal
Strength
How much extra range does the
XBee mesh network give as
compared to a nonmesh network?
Normal
Difference in distance
of consistent, accurate
messages with and
without
XBee Encryption
Effectiveness
Link
Device/Gateway
Yes
Yes
Security
Built-in
Security
Does the XBee encryption stop
communication to nodes without
the encryption key?
Normal
Ability of node without
key to communicate
XBee Hacker Resilience
Link
Device/Gateway
Maybe
Yes
Security
Built-in
Security
How hard would it be to 'hack' the
system via the XBee network?
Normal
Intangible…
XBee Range Open Pro
XBee Range Typical Pro
XBee Range Open Std
XBee Range Typical Std
Open Field
Normal
Open Field
Normal
Noisy, rest
normal
Dampened
environment,
rest normal
Noisy, rest
normal
Dampened
environment,
rest normal
Distance of consistent,
accurate messages
Distance of consistent,
accurate messages
Distance of consistent,
accurate messages
Distance of consistent,
accurate messages
Distance of consistent,
accurate messages
Distance of consistent,
accurate messages
Distance of consistent,
accurate messages
Distance of consistent,
accurate messages
97
Figure 47. Break-Even Analysis
98
Figure 48. Material Costs Sheet
99
Figure 49. Material Costs Sheet (cont.)
Figure 50. Fixed & Variable Costs Sheet Break-Downs with Totals
100
Figure 51. Fixed Cost of Goods Sold
101
Figure 52. Variable Cost of Goods Sold
Figure 53. Variable Cost of Operation
102
Figure 54. Variable Cost of Operation (cont.)
103
Figure 55. Fixed Cost of Operation.
104
Figure 56. Cash Flow Statement (Quarterly) Year 1
Figure 57. Cash Flow Statement (Quarterly) Year 2.
105
Figure 58. Cash Flow Statement (Quarterly) Year 3
Figure 59. Cash Flow Statement (Quarterly) Revenue Explanation.
106
Figure 60. Ratio Analysis Calculation Year 1 & 2
107
Figure 61. Ratio Analysis Calculation Year 3
108
Figure 62. HomeAlive Prototype Devices
Figure 63. HomeAlive Prototype Thermostat
Figure 64. HomeAlive Prototype Outlet Adapter
109
19 References & Bibliography
[1] “ XBee Pro Module - Series 1 - 60mW with Wire Antenna - XBP24-AWI-001”, Adafruit, [online]
2014, https://www.adafruit.com/products/964 (Accessed: 8 November, 2014).
[2] “USB WiFi (802.11b/g/n) Module with Antenna for Raspberry Pi”, Adafruit, [online] 2014,
https://www.adafruit.com/products/1030 (Accessed: 8 November, 2014).
[3] “VideoSecu 12V DC 500mA Regulated CCTV Camera Power Supply UL Listed Switching 100V240V AC to DC 2.1mm x 5.5mm Plug Power Adapter MCQ”, Amazon, [online] 2014, from
http://www.amazon.com/VideoSecu-Regulated-Switching-100V-240VAdapter/dp/B000VRL632/ref=sr_1_11?s=electronics&ie=UTF8&qid=1415500451&sr=111&keywords=power+supply+ac+to+dc (Accessed: 8 November, 2014).
[4] “Adafruit Assembled Pi Cobbler Breakout + Cable for Raspberry Pi”, Adafruit, [online] 2014,
http://www.adafruit.com/products/914?gclid=CLOP3ZnC7MECFQYvaQodZicA9Q (Accessed: 8
November, 2014).
[5] “Waterproof Plastic Electric Project Case Junction Box”, Amazon, [online] 2014,
http://www.amazon.com/Waterproof-Plastic-Electric-Junction-60x36x25mm/dp/B00O9Y633G/
(Accessed: 8 November, 2014)
[6] J. VanAntwerp, “Design Norm Lectures”, in ENGR-325 Lectures, 2014. (Accessed: 8 November,
2014).
[7] “System Properties Comparison Microsoft SQL Server vs. MySQL vs. Oracle”, DB-Engines,
[online]2014, http://db-engines.com/en/system/Microsoft+SQL+Server%3BMySQL%3BSQLite
(Accessed: 8 November, 2014).
[8] “MySQL Differences from Standard SQL”, MySQL, [online] 2014, http://dev.mysql.com/doc/mysqlreslimits-excerpt/5.5/en/differences-from-ansi.html (Accessed: 8 November, 2014).
[9] “What is a Web Framework?”, RailsGuides, [online] 2014,
http://guides.rubyonrails.org/getting_started.html (Accessed: 8 November, 2014).
[10] “What is a Web Framework?”, Everything I Know About Phython, [online] 2014,
http://www.jeffknupp.com/blog/2014/03/03/what-is-a-web-framework/ (Accessed: 8 November, 2014).
[11] “RoR MVC, ORM, Frameworks”, RailsGuides, [online] 2014,
http://guides.rubyonrails.org/getting_started.html (Accessed: 8 November, 2014).
[12] “Comparison of Web Application Framework”, Wikipedia, [online] 2014,
http://en.wikipedia.org/wiki/Comparison_of_web_application_frameworks (Accessed: 8 November,
2014).
[13] “Web MVC framework”, RailsGuides, [online] 2014,
http://guides.rubyonrails.org/getting_started.html (Accessed: 8 November, 2014).
[14] “Web MVC framework”, Spring Framework Reference Documentation, [online] 2014,
http://docs.spring.io/spring/docs/current/spring-framework-reference/html/ (Accessed: 8 November,
2014).
110
[15] “Frequency Asked Questions”, MQTT, [online] 2014, http://mqtt.org/faq ((Accessed: 8 November,
2014).
[16]“SparkFun Xbee Dongle”,SparkFun,[online] 2014, https://www.sparkfun.com/products/11697
(Accessed: 8 November 2014)
[17] ]“SparkFun Xbee Sheild”,SparkFun,[online] 2014, https://www.sparkfun.com/products/12847
(Accessed: 8 November 2014)
[18] “SparkFun Uno”, SparkFun, [online],2014, https://www.sparkfun.com/products/11021 (Accessed: 8
November 2014)
[19] “Arduino Nano I/O Sheild”, Amazon [online],2015, http://www.amazon.com/Arduino-Nano-I-OShield/dp/B00BD6KEYC (Accessed: 22 April 2015)
[20] “Ardunio Nano”, Amazon,[online], 2015, http://www.amazon.com/SainSmart-Nano-v3-0Compatible-Arduino/dp/B00761NDHI (Accessed: 22 April 2015)
[21] “Arduino Stackable Header”, SparkFun, [online], 2015, https://www.sparkfun.com/products/9279
(Accessed: 28 April 2015)
[22] “9V Battery Connector”, Amazon, [online], 2015, http://www.amazon.com/Piece-Battery-PowerCable-Arduino/dp/B00CDYG60E (Accessed: May 05 2015)
[23] “Honeywell Programmable Thermostat”, Amazon,[online], 2015,
http://www.amazon.com/Honeywell-RTH6350-5-2-Programmable-Thermostat/dp/B00421BGHY
(Accessed: May 05,2015)
[24] “RMS to DC Converter”, DigiKey,[online], 2015, http://www.digikey.com/productdetail/en/AD736JNZ/AD736JNZ-ND/751028 (Accessed: April 22,2015)
[25] “DC-DC Converter”, DigiKey,[online], 2015, http://www.digikey.com/productdetail/en/MAX1044CPA%2B/MAX1044CPA%2B-ND/947733 (Accessed: April 22,2015)
[26] “General Purpose Relay”, DigiKey,[online], 2015, http://www.digikey.com/product-detail/en/G5CA1A-E%20DC5/Z2161-ND/699988 (Accessed: April 22,2015)
[27] “Current Transducer”, DigiKey,[online], 2015, http://www.digikey.com/productdetail/en/ACS712ELCTR-05B-T/620-1189-1-ND/1284606 (Accessed: April 22,2015)
[28] “Current Sensor”, DigiKey,[online], 2015, http://www.digikey.com/product-detail/en/AD628ARZR7/AD628ARZ-R7CT-ND/3903355 (Accessed: April 22,2015)
[29] “RMS to DC Converter”, DigKey [online], 2015, http://www.digikey.com/productdetail/en/AD8436ARQZ-R7/AD8436ARQZ-R7TR-ND/3542851 (Accessed: April 22, 2015)
[30] “Raspberry Pi”, Raspberry Pi, [online], 2015, https://www.raspberrypi.org/ (Accessed: November
08, 2014)
[31] “Beagle Board”, Beagle Board,[online], 2015, http://beagleboard.org/ (Accessed: November 08,
2014)
[32] “Arduino Uno”, Arduino Uno, [online], 2015, http://www.arduino.cc/en/Main/ArduinoBoardUno
(Accessed: November 08 2014)
111