Project Plan Version 1.1

Project Hestia

Senior Design Group 13-30

Project Plan Version 1.1

Students

Adviser

Client

Executive Summary

Common Terms

Cloud -- The backend layer operating on remote servers - for our case Google App Engine. This sends all commands to the Hestia Embedded Device and also communicates back and forth with the Hestia Portal

Hestia Embedded Device -- The physical platform that sits in the users home and communicates between Nodes _{and the} Cloud_.

Hestia Portal -- General term to describe the user interface options to control Hestia Embedded Devices and check statuses. For our project, this consists of a web portal and a mobile

application portal - either of which can be used to send commands or check statuses. Home Automation Protocol -- A standard for communicating with nodes in a home/small business to send commands and/or check statuses. Examples include X10, Insteon, and ZWave.

Home Automation Protocol Commands -- a piece of data that controls Nodes or reports a Node’s status. Examples: turnOn, turnOff, getStatus, statusIs...

Node -- A physical device which listens for and responds to Home Automation protocol commands.

Transceiver -- A physical device which connects to the Hestia Embedded Device (via USB) and sends and receives Home Automation Protocol commands.

Problem/Need Statement

Many home automation control protocols and applications exist. However, most require servers running at home to relay commands. Others are specialized and only support one of the many available protocols. They also require professional installation (i.e. security systems). There is no system which supports multiple protocols, is easily installable by end users, and doesn’t require a server running at the user’s home.

System Block Diagram

System Description

The Hestia system allows users to remotely control devices in the home or small business via existing home automation protocols.

The concept sketch above portrays the capabilities and flow of the system. We can see the user with a mobile device, which communicates with the Hestia Cloud via a Hestia Portal Application The Hestia Cloud can communicate with all the Hestia Embedded Devices owned by that user, shown in the Concept Sketch as Home1, Home2, and SmallBusiness.

Each Hestia Device has a number of Transceivers attached. Each transceiver communicates with its associated Nodes via Home Automation Protocol Commands.

The operating environment for this project consists of a house that contains light switches, garage doors, sprinkler systems, air conditioning unit , etc. that the user wishes to control or view the status of remotely.

User Interface Description

Users will communicate with nodes by using a Hestia Portal. We will provide both a web portal and a mobile app portal which can be used to send commands to nodes and check statuses. The Hestia Portal will communicate with the cloud to check statuses and send commands. The web portal will also provide pages for changing settings, adding devices, and updating user information. To control/check devices, the user will select the appropriate home/small business using the Hestia Portal. He/she will then select the node desired. A page with information about the node will load, showing its current status. This page will also have buttons to send any of the available commands to the node.

The user interface of the Mobile App are shown in Appendix A.

Functional Requirements

● Transceivers

○ Can handle up to 4 transceivers

○ Can support multiple protocols of transceivers at the same time (test with 2) ○ Can support multiple of the same protocol transceivers at the same time

● Response time

○ X10 Light must respond in under 3 seconds to command from portal (When ping at each step is <200ms)

○ Web portal should load in under 1 second (When ping time is <200ms)

○ Status should update in cloud within 3 seconds of node state change (on nodes

which support status updates)

● Nodes

○ Hestia Portals can support unlimited nodes

○ Cloud can support unlimited nodes

○ Response time requirements should still be met with 100 nodes ● Locations

○ Hestia Portals can support multiple locations per user account - up to 4

○ Cloud can support multiple locations per user account - up to 4

● Power Consumption

○ The embedded device should consume no more power than 500mW under load ○ The embedded device should consume no more power than 300mW when idle

● Hestia Embedded Device Appearance

○ Will be no larger than 6”x6”x6” ○ Will be in plastic enclosure ● Installation Process

○ Does not require any router changes with a modern router (IE: No port forwarding)

○ Entirely available through Hestia Web Portal

○ Requires user to physically interact with device for security (IE: Push button) ● Physical Interfaces

○ Will have 2 USB ports (or a way to connect to 2 USB devices)

○ Will have 1 Ethernet port

○ Will have push button to authenticate device with user’s account

Market Survey

Customer Focus

Our product is intended for technology savvy home and small-business owners. The 24 to 35 year old young professional is a key consumer of this product.

Existing Products

There are many existing devices on the market for home automation, but most do not support a computer or internet connection.

● X10 Remotes

● Insteon Remotes

Other existing devices may interface with PCs, but do not have inherent internet connectivity.

● Insteon PC interfaces

● X10 PC interfaces

Other home automation devices have an internet connection, but it is not cloud-based.

● Insteon embedded server

There also exist cloud enabled devices for control and monitoring; these are the most similar to what we are implementing.

● ADT Pulse

○ Home Security interface ○ Exclusive to Z-Wave ○ $50+ per month

● Vivint

○ Exclusive to Z-Wave

○ $50+ per month ● Ninja Blocks

○ Generic device control from the cloud

○ Open Source

● Control4

○ A/V Control from mobile device ● Orchestrated Home

○ Exclusive to Insteon ● Crestron

○ Full Home Automation

○ Professional grade ○ A/V and Lighting control

Mobile apps to interface with existing home automation devices, most using your own server.

● iPhone Home Controller

○ iPhone to X10 only

○ Manual install process <link>

● A myriad of other Apps

Literature Survey

Formal literature on this topic is lacking, since it is not an academic or research area. We have been using the following resources.

● Official X10 protocol specification ● eLinux Wiki

Deliverables

The expected deliverables for this project includes two forms of Hestia Portals, a web portal and Android application. Both would allow the user to access their account, add nodes, poll nodes for status, and send commands to nodes through the cloud. The cloud will be created using Google App Engine and will support communication to the Hestia embedded device.

The Hestia embedded device will consist of a Beaglebone, or other pre-made embedded platform, running a form of embedded Linux. This embedded device will be able to securely communicate with the cloud to send commands to nodes in the correct home automation protocols via a USB transceiver, such as the CM19A. Supported automation protocols for this project include X10, Insteon, and serial (Arduino).

The testing and demonstration for this project will be encompassed in a model house running the aforementioned setup. The model home will include a variety of different demonstration opportunities including light bulbs, garage door, sprinkler system, fans.

Work Plan

Work Breakdown Structure - Austin

● Alison

○ Connection Manager on Hestia Embedded Device

○ Plan for and connect to drivers for Transceivers

○ Connect to RPC code on Hestia Embedded Device

● Andy

○ Product Owner for Hestia Embedded Device

○ Hestia Embedded Device side of RPC connection to Hestia Cloud

○ Plan for updating code on Hestia Embedded Device

○ Plan for configuring Hestia Embedded Device

● Austin

○ Product Owner for Hestia Cloud

○ Hestia Cloud side of RPC connection to Hestia Embedded Device

○ Hestia Cloud storage of all needed information

○ Hestia Cloud side of connection to Hestia Portal

○ Hestia Web Portal ● Patrick

○ Device drivers for Transceivers

○ Deals with connection between Connection Manager and transceiver

○ Responsible for actually communicating with currently available Transceivers

● Taylor

○ Product Owner for Hestia Portal on Android ○ Communication with cloud from Android ○ Full command-set implemented on Android

○ Help with Hestia Web Portal

Resource Requirements

We will require the following resources for our development:

● Google App Engine Account (acquired)

● Beaglebone board (acquired)

● USB X10 transceiver (acquired)

● X10 Node (acquired)

● Arduino (acquired)

● Materials for Model Home Demo ○ Wood

○ Light bulbs

○ Servos (for garage door)

○ Fans

Risks

Table 1 shows the major risks to the success of this project. We have calculated the probability, criticality, and mitigation strategy for each risk.

Risk Mitigation strategy

Not working with a company as a client. Following procedures well and working closely with our advisor. Creating well defined requirements and

success criteria. Working with uncertain embedded linux

drivers.

There are several open source projects that we could adapt. Large online support community. Transmitting signals over the electrical

grid.

We’re using a protocol (X10) that is tested and proven to work.

Unreliable networks. Clearly note a warning in the installation/instruction manual that notifies the user that the system will not

work if they’re network is disrupted. Network Security: Enabling our

communication to reach the embedded linux board, but blocking unauthorized communication from external sources.

We will punch holes in NAT to allow our communication to enter. We will have to do further

research about how to provide a security layer to prevent external sources from reaching our system. Cloud being spammed with more

commands than it can handle.

Limit users to a tolerable number of commands per second.

Hestia embedded device security. Preventing users from being able to

interface with the device directly.

Protocol will be secured so that users won’t be able to fabricate faulty commands. Further security will not

be evaluated as part of this senior design project. Dependency on Google App Engine Google App Engine is far more reliable than anything

we could do on our own.

Limited usage on Google App Engine Set up various levels of usage for users to subscribe to. (Measured by commands issued per month) Ability for fix bugs after system’s initial

release.

We will develop a way to install updates automatically.