Project Plan Version 1.1

Transcription

1 Project Hestia Senior Design Group Project Plan Version 1.1 Students Anderson, Taylor Clark, Patrick Laugen, Austin Montag, Andrew Spiess, Alison Adviser Zambreno, Joseph Client Laugen, Austin

2 Executive Summary TODO 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. Concept Sketch

3

4 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. Operating Environment

5 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 Non-Functional Requirements

6 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 Home Security interface

7 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.

8 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 Miniature Christmas tree

9

10 Project Schedule

11 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 Not working with a company as a client. Working with uncertain embedded linux drivers. Transmitting signals over the electrical grid. Unreliable networks. Network Security: Enabling our communication to reach the embedded linux board, but blocking unauthorized communication from external sources. Cloud being spammed with more commands than it can handle. Mitigation strategy Following procedures well and working closely with our advisor. Creating well defined requirements and success criteria. There are several open source projects that we could adapt. Large online support community. We re using a protocol (X10) that is tested and proven to work. 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. 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. 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. Dependency on Google App Engine Limited usage on Google App Engine Ability for fix bugs after system s initial release. 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. Google App Engine is far more reliable than anything we could do on our own. Set up various levels of usage for users to subscribe to. (Measured by commands issued per month) We will develop a way to install updates automatically. Table 1: Risks and Mitigation Strategies

12 Appendix A : Android Screen Sketches

13

14

15