Smart Devices(Home Automation via the Web)

Project Final Report

Team number: May03-21

Client: Senior Design

Faculty advisor: Doug Jacobson

Team members: Brendan HickeyBrian Thorp

Mark MelvilleMike FernholzScott Reeder

Date submitted: 4/8/03

1

Table of Contents

Definition of Terms.............................................................................................................5Introduction..........................................................................................................................5

Executive Summary.........................................................................................................5Problem Statement...........................................................................................................5

General Problem Statement.........................................................................................5General Solution-Approach Statement........................................................................5

Operating Environment...................................................................................................5Intended User(s) and Intended Use(s).............................................................................5

Intended User(s)...........................................................................................................5Intended Use(s)............................................................................................................5

Assumptions and Limitations..........................................................................................5Assumptions................................................................................................................5Limitations...................................................................................................................5

Expected End Product and Other Deliverables...............................................................5Project Approach and Results..............................................................................................5

End-Product Functional Requirements............................................................................5X-10 Control Software................................................................................................5X-10 Custom Hardware...............................................................................................5

Resultant Design Constraints...........................................................................................5Approaches Considered and One Used...........................................................................5Detailed Design...............................................................................................................5Implementation Process Description...............................................................................5End-Product Testing Description....................................................................................5Project End Results..........................................................................................................5

Resources and Schedules.....................................................................................................5Personal Budget...........................................................................................................5Required Resources.....................................................................................................5Financial Budget..........................................................................................................5

Schedules.........................................................................................................................5Closure Materials.................................................................................................................5

Project Evaluation............................................................................................................5Commercialization...........................................................................................................5Recommendations for Additional Work..........................................................................5Lessons Learned..............................................................................................................5Risk and Risk Management.............................................................................................5Project Team Information................................................................................................5Closing Summary............................................................................................................5References........................................................................................................................5

2

List of Figures

Figure 1: X-10 Home Automation System.........................................................................5Figure 2: X-10 Home Automation Local Software Screenshot..........................................5Figure 3: X-10 Home Automation Local Software............................................................5Figure 4: X-10 Home Automation Local Software “Network Options” Dialog Screen....5Figure 5: X-10 Home Automation Remote Operation Java Applet Screenshot.................5Figure 6: LM465 Schematic...............................................................................................5Figure 7: Garage Door Sensor Receiver Circuit.................................................................5Figure 8: Garage Door Sensor Transmitter Circuit............................................................5Figure 9: First Semester Schedule......................................................................................5Figure 10: Second Semester Schedule................................................................................5Figure 11: First Semester Deliverables...............................................................................5Figure 12: Second Semester Deliverables..........................................................................5

3

List of Tables

Table 1: Commercially available X-10 Parts......................................................................5Table 2: Original Personal Budget.....................................................................................5Table 3: Revised Personal Budget......................................................................................5Table 4: Final Personal Budget...........................................................................................5Table 5: Original Estimate for Required Resources...........................................................5Table 6: Revised Estimate for Required Resources...........................................................5Table 7: Final Estimate for Required Resources................................................................5Table 8: Original Financial Budget....................................................................................5Table 9: Revised Financial Budget.....................................................................................5Table 10: Final Financial Budget.......................................................................................5

4

Definition of Terms

API Application Program Interface. Acts as an interface between the operating system and application programs, which allows the application programs to communicate with the operating system, vice versa.

Applet A little application. An applet is a simple program written in Java that can be attached to HTML documents.

C++ An object oriented programming language that formed the basis for Java.

CGI Common Gateway Interface, or CGI, is a program that can access information in a database and format the results as HTML.

Client / Server An architecture in which one computer can get information from another. The client is the computer that connects to the server in order to gain access to a service or data.

Device Controller Device that is attached between a wall plug and an appliance that is to be controlled by the X-10 system.

GUI Graphical user interface. What the user sees and interacts with while using a program.

Host Controller Device that is attached between a wall plug and a computer that sends and receives signals for the X-10 system.

House Code X-10 can operate on 16 different frequencies and each one is referred to as a House Code.

HTML A markup language used to structure text and multimedia documents and to setup hypertext links between documents, used extensively on the World Wide Web.

Java An object oriented programming language similar to C++ but which is cross platform and can create applets.

Macro One instruction representing a sequence of other instructions.Protocol A set of formal rules describing how to transmit data,

especially across a networkSerial Port A socket on a computer, which allows reliable, long distance

communication.Smart device Any piece of electronic equipment that is highly automated,

or imitates human intelligence.X10 or X-10 A communications language that allows compatible products

to talk to each other via the existing 110V electrical wiring in the home.

X-10 Module Hardware that facilitates communication between appliances and an X-10 controller. A module would plug into an outlet, and a lamp, for example, would plug into the module.

5

Introduction

Executive SummaryThis document outlines the major goals and accomplishments that have been achieved with respect to the implementation of the web-controlled X-10 home network as well as the garage door status hardware.

There are many reasons for implementing a web-controlled X-10 home network. The most obvious reason for such a system is obviously security. A homeowner with this system will be able to give their home a “lived in” look by turning on electrical appliances such as a TV or lamp when the homeowner is on extended travel. In addition to providing security, the system will also give the homeowner piece of mind by allowing the homeowner to check the status of their X-10 enabled devices from any web-enabled device such as a PC connected to the internet or a web-enabled cell phone.

The garage door status module was chosen to add extended use to the X-10 system that was not currently available through existing X-10 modules. Forgetting to close the garage door is perhaps one of the easiest things to do. If there is ever that doubt in a homeowner’s mind, a quick check on the web can either put their mind at ease, or let them know that their house is open and unprotected.

There were several major tasks that had to be completed for this project to be successful. Soon after choosing this project, a well-defined design needed to be developed. Several different designs were looked at and a final design implementation was chosen that contained a balanced mix of purchased hardware, free software, and team developed hardware and software. The chosen design implementation is fully explained in the Detailed Design section of this report.

The next task was to actually implement the design. This was the most time consuming and labor intensive portion of the project. It took parallel collaboration by all team members in order for this step to be completed on schedule. Constant communication between team members during this step was also extremely important to ensure that all team members were striving for the same goal.

Finally, the end product required testing to ensure that all of the design requirements were met. This step involved determining test cases that would test all possible use-cases for the software and also making sure that exceptions were handled properly.

The final result of the above developmental activities is a software system that implements a web-controlled X-10 home network and an external hardware module for monitoring the status of a garage door. Any person with a CM11A host controller and at least one X10 device module can use our software to control their X-10 network from any Java and web enabled device. Added functionality could be implemented in the software if follow-up work is desired on this project. A complete listing of follow-up recommendations is listed in the section entitled, Recommendation for Future Work.

6

Problem Statement

General Problem StatementA home automation system that is accessible via the Internet would benefit anyone who desires the ability to remotely monitor and control devices in their home. Possible users include vacationing homeowners, security-conscience homeowners, or anyone who would like to automate simple activities such as turning lights on before they get home from work. This smart device is designed to enable a homeowner to check the status of the lights, the temperature, the garage door and other devices via the web. It also will allow an owner to change device’s status from a secure web site.

General Solution-Approach StatementThe software for the X-10 system was programmed using the Java language. The Java API interfaces with the X-10 control software that directly controls the X-10 devices. There are essentially three parts to the software. There is a GUI application that can be run on the home computer that controls the X-10 devices from that computer. The other part of the software is a Java applet that can be run from any web-enabled device that connects to the home computer to control the home network. The team also created a monitoring device for a garage door. This device uses several smaller circuits to create a module that can sense whether a garage door is open or closed. There were other monitoring devices that were not implemented due to time constraints and limited knowledge of the X-10 protocol.

Operating EnvironmentMost of the X-10 devices available are designed to be operated in an indoor-household environment. All the X-10 devices that we researched were built to operate on an 112V home power grid. Since the software is written in Java, it is platform independent and can be run on any machine with an installed Java run-time environment and a serial port for communication to the X-10 modem. The client applet for remote operation can be run in any browser that supports Java applets.

The environment for the garage door sensor will be exposed to temperature changes experienced in a garage. While it will need to withstand these changes, it won’t need to withstand any other natural occurrences such as rain or snow because it will be placed on the horizontal garage door track, away from the front of the garage. Other environmental factors that will need to be accounted for are moderate vibration and dust accumulation.

Intended User(s) and Intended Use(s)

Intended User(s)Any person who currently owns or will purchase CM11A host controller can use the team-developed software to control their X-10 devices as well as the hardware to add extra features. The user will be able to download and install the software and

7

documentation with very little difficulty assuming that the user has intermediate computer skills. Businesses that also desire the same security/monitoring requirements that our system provides may also be considered potential users.

Intended Use(s)After setting up this product it is expected that the user will frequently want to reconfigure their devices until they have their desired setup perfected. Thus, the software must allow for easy reconfiguration and easy daily use with a fairly short learning curve. Reconfiguration will only take place from the home computer. Once the user has correctly setup their network and correctly configured the devices they will be able to perform operations such as turning lights on and off and monitoring a garage door.

Assumptions and Limitations

Assumptions Device shall be easy enough to use so that any person with computer experience will

be able to install, connect, and use the device without any confusion or frustration Device shall provide the user with a functionality that shall make their life easier and

less worrisome instead of more complicated User is familiar with operating a computer User will have a computer capable of controlling X-10 devices and has continuous

access to the Internet (dial-up not recommended) Home environment will comply with the specified operating environment X-10 system will not experience outside interference from other X-10 systems 112-V outlets are available in the user’s garage

Limitations The number of X-10 devices is limited to 16 different devices per house code The server will need to be running on the home computer in order for a client to be

able to connect and control the home network. If the server is down, then a user will not be able to access his/her home via the web.

The user is limited by the speed of their Internet connection. If they have a very slow connection the devices will respond very slowly to any command.

Expected End Product and Other DeliverablesThe completed X-10 home automation system will consists of an installable software package that will contain installation instructions, user software, software documentation, and the source code for adventurous individuals wishing to expand or customize the capabilities of the software. There are no X-10 hardware components as part of this system. They must be purchased separately and must be CM11A-compatable X-10 devices.

8

The completed garage door sensor module will consist of the monitoring module, attachment fixtures to attach it to a garage door rail, schematics for the curious user, and installation instructions.

Project Approach and Results

End-Product Functional Requirements

X-10 Control SoftwareMonitor and control X-10 devices locallyThe software shall be able to control the X-10 devices and show their current status when being run locally. That is, a user should have the ability to use the software from their local pc as well as from a remote pc. Checking the status of X-10 controlled devices is only available to certain appliance modules. The status will include on/off, dimmed, error, or open/shut.

Create, modify and schedule macrosThe software shall allow a user to create macros. A macro will give the user the ability to change the state of devices of their choosing at a given point in time. For example, a user could create a “Morning” macro that turns on a radio, the bathroom light, and the kitchen light at 7:00 AM every day. The software will also allow a user to change existing macros and schedule them to run at any time they choose.

Monitor and control X-10 devices remotelyUsers will be able to monitor and control their X-10 controlled devices remotely via a secure Java applet. The applet, in conjunction with a server on the user’s home pc, will allow the user to send commands to their X-10 devices from any PC with a Java-enabled browser and an internet connection. The applet will not function without the user logging in first with a username and password.

X-10 Custom HardwareMonitor garage door statusThe garage door sensor shall allow a user to monitor whether the garage door is open or closed. The sensor will operate using the standard X-10 protocol for receiving and sending events.

Resultant Design ConstraintsMost X-10 lighting controllers cannot be used with fluorescent lightsOnly standard incandescent lamps can be used with the X-10 lighting controller modules. The lamp modules cannot dim fluorescent lights.

9

X-10 was never designed for unattended remote operationThe control software and ability to control devices via the web are not meant to allow a user to control certain devices. For example, it is not wise to control your home’s thermostat, refrigerator, or water heater using X-10. There are too many variables that could cause a change in the status of the X-10 device controller and it would be dangerous to allow the control of these devices over the web, even from a secure web site.

CostThe cost of parts shall be kept around $100. This includes X-10 host controllers, device controllers, sensors and miscellaneous parts.

Low BandwidthIn order to accommodate low-bandwidth Internet connections, the applet and server shall use a minimal amount of bandwidth.

Location of power outletThe location of a power outlet in a garage is different for each house. We though about using two 9V batteries, but this would be an added hassle for the owner. Instead, we stepped down the 120VAC to 9VAC and used diodes and capacitors to convert it to a +9 and -9 VDC. The user may also need extension cords to get power to the module.

Approaches Considered and One UsedThere were several approaches considered for the different parts of the project. For this section the project can be divided into three categories: programming language, client/server architecture, and custom hardware implementation.

Programming LanguageTwo programming languages were considered: C++ and Java. Both meet or exceed the requirements for the type of software being created. C++ offers good flexibility, especially when controlling other devices. On the other hand, the team was generally unfamiliar with GUI programming in C++. Java was the alternative to C++. It offered excellent GUI support but seemed lacking in the area of device communication. The deciding factor here was a Java X-10 API created by Jesse Peterson. Other APIs were considered but Jesse Petersons’s Java X-10 API was the most complete. The API gives programmers the ability to easily control X-10 devices and contained several open source samples and files to build from. In the end, Java was used because of the team’s familiarity with it and the X-10 API.

Client / Server ArchitectureSeveral architectures were looked at before deciding on one. A stand-alone client/server system, a secure website using XML, and a Java applet were the most discussed. A stand-alone client/server architecture offers great security, but was eliminated because of the requirement that allows the user to operate their X-10 devices from any remote PC with an Internet connection, without having to install extra software. The secure website

10

idea will be implemented, time permitting. The website will be using in conjunction with the Java applet as another security precaution. Using a Java Applet only slightly limits the user. They must use a Java-enabled browser to access the applet. Security comes in the form of a login mechanism in the applet as well as the secure web site login when implemented.

Custom Hardware ImplementationA decision had to be made as to what kind of custom X-10 device the team could create. Two ideas were settled on: a temperature sensor and a garage door sensor. The team soon realized that time and budget only allowed for one idea so the temperature sensor was scrapped in favor of the garage door sensor.

The initial designs for the garage door sensor were a lever system, an optical trip circuit, and a contact circuit. The lever system would rise and fall with the garage door itself. When the lever was down/up the garage door was down/up. The optical trip circuit used a constant beam of infrared light to signal if the door was up or down. This signal was based on if the beam was operating in a closed circuit, or broken by a raised garage door. The contact circuit operates, simply as the name says, if the door is open, a piece of metal would contact with the door and send a signal, when it was down, there is no contact and therefore no signal. We finally decided on the optical trip circuit, as we believed it would be more reliable as well as longer lasting.

Detailed DesignThe design of the X-10 Home Automation System was done in stages. Since the team had no problem statement or project definition other than to “create a smart device”, a lot of work went into defining the project scope. Also, much time was spend hammering out the details of what the team could and couldn’t do concerning X-10 hardware and software.

The team decided on purchasing an X-10 ActiveHome kit. This kit is available from several online retailers including www.x10.com, which is where the team was able to purchase the kit from. Also purchased was a 2-Way Appliance Module (AM14A). Table 1 shows each part with its estimated price and an image of what the part should look like.

11

Table 1: Commercially available X-10 Parts

Part Name Part No. Est. Price Part Image

Computer Interface CM11A $50.00

Transceiver Appliance Module

RR501 $20.00

Lamp ModuleLM465 $13.00

2-Way Appliance Module AM14A

$33.00

Note that the estimated price for each part is that part alone. The team purchased all of the parts except for the 2-Way module in a kit for $50.00.

The team followed a simple project plan, shown graphically in figure 1. This diagram shows how the different X-10 components, the team’s hardware and software, and the user could possibly interact.

12

Figure 1: X-10 Home Automation System

From figure 1, the work was broken into several parts. First there was the local X-10 control software, which would allow a user to control the X-10 devices from their local PC. The second part was the X-10 control server, which provided communication from a remote Java applet and the local control software. Third was the Java applet, which allowed the user to remotely control their X-10 devices. The fourth and last part was custom X-10 hardware that was to be designed to work with the existing X-10 protocol. Each part will be looked at more in depth, starting with the local X-10 control software.

X-10 Lamp Module

X-10 Appliance Module

X-10 Computer Interface

Local X-10 Control Software

X-10 Control Server

Living room Lamp

Television

Custom X-10 Hardware

Remote PCJava-enabled PDA or Phone

Sensor

Java Applet

Local PC

Key:Team created Hardware or SoftwareCommercial X-10 Modules

Web server

13

Figure 2: X-10 Home Automation Local Software Screenshot

Figure 2 is a screenshot of the main program used to control and monitor X-10 devices. The software is designed to run on a users local PC. From this GUI, a user can turn their X-10 controlled devices on and off. Lights can be dimmed and brightened. The status of 2-Way X-10 devices can be updated and checked. Devices can be added, edited and removed. Finally, the networking options can be set and the server can be started from this GUI.

A more in depth look at the “Add device” option is shown in figure 3 below. Here a user can add a device by specifying the device type (1-Way or 2-Way), the device ID number (1-16), and a simple description of the device.

Figure 4 provides a look at the networking options dialog box. Here a user can specify which serial port their X-10 computer interface is connected to. Also, the user can choose which ports to use for the server to listen on. Finally the user can choose which address to use for the status address.

14

Figure 2 through Figure 4 make up the bulk of the local X-10 control software GUI. The next part to examine is the X-10 control server.

Figure 3: X-10 Home Automation Local Software

Figure 4: X-10 Home Automation Local Software “Network Options” Dialog Screen

The X-10 control server is code that has been implemented into the local X-10 control software that allows the user to start the server, and then have remote access to their X-10 devices. The user must start the server.

The last part of the software is the Java applet that allows the user to access their X-10 devices remotely. The interface of the applet is shown in figure 5. Here a user can log in

15

to their home PC via the X-10 control software and control their X-10 devices. The applets implementation differs from the local software in that the applet does not allow the user to add or remove devices. The command options a user has are: on, off, get status, all on, and all off. The user must supply a login name and password in order to have access to the local X-10 control software.

Figure 5: X-10 Home Automation Remote Operation Java Applet Screenshot

The design of the garage door sensor was based off of a lamp module schematic. See figure 6 for the LM465 schematic. Using basic knowledge gained from the X-10 protocol description and the parts listed for the custom X-10 hardware, the garage door sensor was built to specification.

16

Figure 6: LM465 Schematic

Implementation Process DescriptionIn order to implement all of the different pieces of software and hardware, all of the testing and assembly had to take place at one location and on one PC. While this allows the team to work only on the project task at hand instead of troubleshooting other problems, it also means that the system will have to be tested in other locations as well to ensure that the system is not location dependant.

While many problems were encountered, most only required fixes. The testing location had to be moved from one location to another in order to get the X-10 devices to function properly. Many software fixes were required to get all of the software and hardware working together.

End-Product Testing DescriptionThe testing for the project software was done between several members of the team and with the help of a few outside helpers. The local testing was done in one location, to provide a constant environment from which to work from. The remote testing was done between several different remote computers and the one local computer running the X-10 control software with the server activated.

Tests were performed at major stages of the software development, in order to try and catch any little mistake before it became a big mistake.

17

Two tests were performed after the first version of the local control software was working which was around 3/3/03. These tests showed that while the software was able to do its job, it was still a long way off from working how it was supposed to. Many of the errors were simple fixes but may have been missed if the tests had not been performed.

Another test was performed after the first version of the Java applet was implemented on 3/21/03. The applet at that time was slow and bug-ridden. But the feedback from the tester helped the team to evaluate were they were at and were their attention should be focused.

Two final tests were performed on 3/25/03 and the system as a whole performed exceptionally well. The local X-10 control software was all but flawless; the only problems came from the applet. One tester marked it for speed and stability, which are two things the team cannot do much about at this point due to network congestion, etc. Also, the “get status” function did not perform well, which the team believes was caused by the increased network traffic.

The team members themselves performed several more unofficial tests. The applet was tested on several different computers running several different operating systems. The applet loading perfectly providing the newest version of the Java virtual machine was installed on the computer. Some tests were run using a remote session while the local machine was heavily using its network connection. The results were encouraging. Even when several large files were transferring and two other computers were sending and receiving traffic, the applet was able to send events to the local control software.

18

Figure 7: Garage Door Sensor Receiver Circuit

In regards to the garage door sensor, most of the testing was done in the EE333 lab. We first tested each sub-circuit individually to ensure correct operation. The receiver circuit is shown in figure 7 (above) and the transmitter circuit is shown in figure 8 (below). After that was completed, testing began on the circuit as a whole. The testing procedures for this module weren’t extensive, but were thorough. We only needed to test for the situations we would be encountering. With this circuit, there are no user inputs, so there are no external variables that we need to watch out for. After we ensured correct operation of our base circuit, we then set off to test the communication of our circuit with the X-10 system. This proved to be the hardest part because we had to find a way for a circuit to send a signal to the X-10, not a plug-in. After more effort than we would have liked in this area, we got the entire module to work properly and communicate with X-10 properly.

19

Infrared Emitter

+9 V DC

R3

1987.5

R110k

NC

R2

20k

+

-

U1

UA741

3

26

7 14 5

NC

R41987.5

-9 V DCC4

10n

C310n

Figure 8: Garage Door Sensor Transmitter Circuit

Project End ResultsThe final statuses of the main parts of the project are detailed here. The first part was the local X-10 control software. This software is fully functional. A user can completely control all of their X-10 controlled devices from their local PC via the local X-10 control software. Also working is the X-10 control server, which is now seamlessly implemented into the local X-10 control software interface.

The Java applet, providing remote access is also fully functional, allowing commands to be sent from a remote PC to the users local PC running the X-10 control software. Finally, the custom X-10 hardware has been designed and is now a functional garage door sensor implemented as an X-10 device.

20

Resources and Schedules

Personal BudgetTable 2: Original Personal Budget

Mike Fernholz

Brendan Hickey

Mark Melville

Scott Reeder

Brian Thorp

Research 15 11 14 15 15Design/Fabrication 42 40 43 39 40Project Plan 11 9 9 9 9Poster 3 5 4 5 4Design Report 11 6 14 16 12Testing 16 15 14 13 10

Final Report 2 4 3 3 3

Presentation 9 8 10 10 9Meetings 35 35 35 35 35

Total 144 133 146 145 137

Table 3: Revised Personal Budget

Mike Fernholz

Brendan Hickey

Mark Melville

Scott Reeder

Brian Thorp

Research 15 11 14 15 15Design/Fabrication 42 40 43 39 40Project Plan 7 6 6 7 6Poster 6 4 6 5 5Design Report 11 6 14 16 12Testing 16 15 14 13 10Final Report 2 4 3 3 3Presentation 9 8 10 10 9Meetings 33 33 33 33 33Total 141 127 143 141 133

21

Table 4: Final Personal Budget

Mike Fernholz

Brendan Hickey

Mark Melville

Scott Reeder

Brian Thorp

Research 15 11 14 15 15Develop project design 5 4 4 6 5Hardware design and implementation 15 0 17 0 0Software coding 0 23 0 20 30Software and hardware testing 5 10 7 9 9Product revision 4 4 4 4 5Documentation 1 3 1 3 3Misc. (poster, reports, meetings) 43 44 43 44 44

Total 88 99 90 101 111

A comparison between Table 2 and Table 4 reveals a 16 - 38% reduction in each person’s total hours for the project. This reduction was brought about mainly from changing team meetings from every week to a need to meet basis and from a large reduction in the actual project implementation time.

The reason for changing the team meetings from every week to a need to meet basis was that the project was split up between hardware and software. The software was split up even farther so that each team member had their own project to work on so the only reason to have a team meeting was so that everyone could touch base with each other.

The actual implementation of the project took considerably less time than originally estimated. This is due to the project being easier to implement.

Required ResourcesTable 5: Original Estimate for Required Resources

Item Team Hours Other Hours CostPoster printing 2 0 $65.00X10 kit 0 0 $100.00Misc. printing / Binding 0 0 $5.00

Totals 6 0 $170.00

Table 6: Revised Estimate for Required Resources

22

Item Team Hours Other Hours CostPoster printing 2 0 $65.00X10 kit 0 0 $100.00Garage door sensor parts 0 0 $50.00Misc. printing / Binding 0 0 $5.00

Totals 6 0 $220.00

Table 7: Final Estimate for Required Resources

Item Team Hours Other Hours CostPoster printing 2 0 $65.00X10 kit 0 0 $100.00Garage door sensor parts 0 0 $50.00Misc. printing / Binding 0 0 $10.00

Totals 6 0 $225.00

There was as 25% cost increase for resources for this project. The additional purchase of parts for a garage door sensor accounts for this large increase in cost. The need for these parts was the result of wanting to have custom sensors available to use with the software being created for the project.

Financial BudgetTable 8: Original Financial Budget

Item W/O Labor With LaborParts and materials Poster $50.00 $50.00 X10 kit $100.00 $100.00 Printing $0.00 $0.00

Subtotal $150.00 $150.00

Labor at $10 per hour Mike Fernholz $1,440.00 Brendan Hickey $1,330.00 Mark Melville $1,460.00 Scott Reeder $1,450.00 Brian Thorp $1,370.00

Subtotal   $7,050.00Total $150.00 $7,200.00

Table 9: Revised Financial Budget

Item W/O Labor With Labor

23

Parts and materials Poster $65.00 $65.00 X10 kit w/ extra modules $100.00 $100.00 Garage door sensor parts $50.00 $50.00 Printing $5.00 $5.00

Subtotal $220.00 $220.00

Labor at $10 per hour Mike Fernholz $1,410.00 Brendan Hickey $1,270.00 Mark Melville $1,430.00 Scott Reeder $1,410.00 Brian Thorp $1,330.00

Subtotal   $6,850.00Total $220.00 $7,070.00

Table 10: Final Financial Budget

Item W/O Labor With LaborParts and materials Poster $65.00 $65.00 X10 kit w/ extra modules $100.00 $100.00 Garage door sensor parts $50.00 $50.00 Printing $10.00 $10.00

Subtotal $225.00 $225.00

Labor at $10 per hour Mike Fernholz $880.00 Brendan Hickey $990.00 Mark Melville $900.00 Scott Reeder $1,010.00 Brian Thorp $1,110.00

Subtotal   $4,890.00Total $225.00 $5,115.00

The financial budget of this project shows a dramatic decrease in total costs when labor is included because of the decrease in actual labor. A comparison between table 8 and table 10 shows a reduction of almost 30% in total cost. An explanation of this reduction can be found in the Personal Budget section. If labor isn’t included, there was a 25% increase in costs. The explanation for this increase can be found in the Required Resources section.

24

SchedulesID Task Name Duration Start Finish1 Project Planning and Technology Selection 43 days? Tue 8/27/02 Tue 10/22/022 Define Project Scope(Final) 6 days? Tue 8/27/02 Tue 9/3/02

3 Define Project Scope(Revised) 6 days? Tue 8/27/02 Tue 9/3/02

4 Define Project Scope(Original) 6 days? Tue 8/27/02 Tue 9/3/02

5 Define General Functions Required(Final) 5 days? Wed 9/4/02 Tue 9/10/02

6 Define General Functions Required(Revised) 5 days? Wed 9/4/02 Tue 9/10/02

7 Define General Functions Required(Original) 5 days? Wed 9/4/02 Tue 9/10/02

8 Draft Project Plan(Final) 5 days? Wed 9/11/02 Tue 9/17/02

9 Draft Project Plan(Revised) 5 days? Wed 9/11/02 Tue 9/17/02

10 Draft Project Plan(Original) 5 days? Wed 9/11/02 Tue 9/17/02

11 Review and Update Project Plan(Final) 4 days? Wed 9/18/02 Mon 9/23/02

12 Review and Update Project Plan(Revised) 4 days? Wed 9/18/02 Mon 9/23/02

13 Review and Update Project Plan(Original) 4 days? Wed 9/18/02 Mon 9/23/02

14 Choose Smart Device(Final) 6 days? Tue 9/24/02 Tue 10/1/02

15 Choose Smart Device(Revised) 6 days? Tue 9/24/02 Tue 10/1/02

16 Choose Smart Device(Orginal) 6 days? Tue 9/24/02 Tue 10/1/02

17 Define Poster Content(Final) 5 days? Wed 10/2/02 Tue 10/8/02

18 Define Poster Content(Revised) 5 days? Wed 10/2/02 Tue 10/8/02

19 Define Poster Content(Orginal) 5 days? Wed 10/2/02 Tue 10/8/02

20 Create Poster(Final) 9 days? Wed 10/9/02 Fri 10/18/02

21 Create Poster(Revised) 9 days? Wed 10/9/02 Fri 10/18/02

22 Create Poster(Orginal) 9 days? Wed 10/9/02 Fri 10/18/02

23 Revise and Finalize Poster(Final) 3 days? Sat 10/19/02 Tue 10/22/02

24 Revise and Finalize Poster(Revised) 3 days? Sat 10/19/02 Tue 10/22/02

25 Revise and Finalize Poster(Orginal) 3 days? Sat 10/19/02 Tue 10/22/02

26 Develop Project Design 38 days? Wed 10/23/02 Wed 12/18/0227 Define Operating Environment(Final) 2 days Wed 10/23/02 Thu 10/24/02

28 Define Operating Environment(Revised) 2 days Wed 10/23/02 Thu 10/24/02

29 Define Operating Environment(Original) 2 days Wed 10/23/02 Thu 10/24/02

30 Define Intended Users and Uses(Final) 2 days Wed 10/23/02 Thu 10/24/02

31 Define Intended Users and Uses(Revised) 2 days Wed 10/23/02 Thu 10/24/02

32 Define Intended Users and Uses(Original) 2 days Wed 10/23/02 Thu 10/24/02

33 Define Initial Assumptions and Limitations(Final) 2 days Wed 10/23/02 Thu 10/24/02

34 Define Initial Assumptions and Limitations(Revised) 2 days Wed 10/23/02 Thu 10/24/02

35 Define Initial Assumptions and Limitations(Original) 2 days Wed 10/23/02 Thu 10/24/02

36 Define Schedule and Budget(Final) 2 days Wed 10/23/02 Thu 10/24/02

37 Define Schedule and Budget(Revised) 2 days Wed 10/23/02 Thu 10/24/02

38 Define Schedule and Budget(Original) 2 days Wed 10/23/02 Thu 10/24/02

39 Create Project Design(Final) 13 days? Fri 10/25/02 Tue 11/12/02

40 Create Project Design(Revised) 13 days? Fri 10/25/02 Tue 11/12/02

41 Create Project Design(Original) 13 days? Fri 10/25/02 Tue 11/12/02

42 Unbound Project Design Report(Final) 4 days? Thu 11/14/02 Tue 11/19/02

43 Unbound Project Design Report(Revised) 4 days? Thu 11/14/02 Tue 11/19/02

44 Unbound Project Design Report(Original) 4 days? Thu 11/14/02 Tue 11/19/02

45 Revise and Update Project Design Report(Final) 18 days? Wed 11/20/02 Wed 12/18/02

46 Revise and Update Project Design Report(Revised) 18 days? Wed 11/20/02 Wed 12/18/02

47 Revise and Update Project Design Report(Original) 18 days? Wed 11/20/02 Wed 12/18/02

48 Implement Project Design(Hardware) 87 days? Mon 11/11/02 Fri 4/11/0349 Gather Parts(Final) 82 days? Mon 11/11/02 Fri 4/4/03

50 Gather Parts(Revised) 17 days? Sun 12/1/02 Fri 12/20/02

51 Gather Parts(Original) 17 days? Sun 12/1/02 Fri 12/20/02

52 Assemble Product(Final) 60 days? Mon 1/13/03 Fri 4/11/03

8/25 9/1 9/8 9/15 9/22 9/29 10/6 10/13 10/20 10/27 11/3 11/10 11/17 11/24 12/1 12/8 12/15 12/22 12/29 1/5 1/12August September October November December January

Figure 9: First Semester Schedule

25

ID Task Name Duration Start Finish52 Assemble Product(Final) 60 days? Mon 1/13/03 Fri 4/11/03

53 Assemble Product(Revised) 15 days? Mon 1/13/03 Fri 1/31/03

54 Assemble Product(Original) 15 days? Mon 1/13/03 Fri 1/31/03

55 Software Coding and testing 77 days? Sun 12/1/02 Fri 4/11/0356 Main Application(Final) 55 days? Mon 1/13/03 Fri 4/4/03

57 Code Software(Revisedl) 35 days? Sun 12/1/02 Wed 2/5/03

58 Code Software(Original) 35 days? Sun 12/1/02 Wed 2/5/03

59 Web Application(Final) 10 days? Mon 3/24/03 Fri 4/4/03

60 Software Testing(Final) 5 days? Mon 4/7/03 Fri 4/11/03

61 Test Code(Original) 6 days? Thu 2/6/03 Thu 2/13/03

62 Test Product(Revised) 14 days? Thu 2/6/03 Tue 2/25/03

63 Test Product(Original) 11 days? Fri 2/14/03 Fri 2/28/03

64 Product Revision 35 days? Mon 3/3/03 Fri 4/25/0365 Revise Product(Final) 11 days? Fri 4/11/03 Fri 4/25/03

66 Revise Product(Revisedl) 13 days? Mon 3/3/03 Wed 3/26/03

67 Revise Product(Original) 13 days? Mon 3/3/03 Wed 3/26/03

68 Retest Product(Revised) 6 days? Thu 3/27/03 Thu 4/3/03

69 Retest Product(Original) 6 days? Thu 3/27/03 Thu 4/3/03

70 Documentation 26 days? Fri 3/28/03 Fri 5/2/0371 Documentation(Final) 5 days? Mon 4/28/03 Fri 5/2/03

72 Documentation(Revised) 11 days? Fri 3/28/03 Sun 4/13/03

73 Revised Documentation(Revised) 9 days? Tue 4/15/03 Fri 4/25/03

74 Product Demo 31 days? Fri 3/28/03 Fri 5/9/0375 Demonstrate Product(Original) 3 days? Fri 4/4/03 Tue 4/8/03

76 Develop Final Report and Presentation(Original) 21 days? Wed 4/9/03 Wed 5/7/03

77 Define Final Report Contents(Final) 5 days? Mon 3/31/03 Fri 4/4/03

78 Define Final Report Contents(Revised) 6 days? Fri 3/28/03 Fri 4/4/03

79 Define Final Report Contents(Original) 3 days? Wed 4/9/03 Fri 4/11/03

80 Draft Final Report(Final) 4 days? Mon 4/7/03 Thu 4/10/03

81 Draft Final Report(Revised) 5 days? Mon 4/7/03 Fri 4/11/03

82 Draft Final Report(Original) 5 days? Mon 4/14/03 Fri 4/18/03

83 Revised Final Report(Final) 11 days? Fri 4/11/03 Fri 4/25/03

84 Revised Final Report(Revised) 11 days? Mon 4/14/03 Mon 4/28/03

85 Revised Final Report(Original) 13 days? Mon 4/21/03 Wed 5/7/03

86 Final Presentation(Final) 10 days? Mon 4/28/03 Fri 5/9/03

87 Give Final Presentation(Revised) 7 days? Thu 5/1/03 Fri 5/9/03

88 Give Final Presentation(Original) 5 days? Thu 5/1/03 Wed 5/7/03

1/12 1/19 1/26 2/2 2/9 2/16 2/23 3/2 3/9 3/16 3/23 3/30 4/6 4/13 4/20 4/27 5/4 5/11January February March April May

Figure 10: Second Semester Schedule

26

There was almost no change for the entire first semester schedule. Only during the second semester did the team have to rework the schedule and this was because the team had started to actually implement the design and had a better understanding of how much time and what was needed to complete the project. Consequently, the hardware implementation and the software coding timelines were extended to better accommodate the project. The addition time spent on coding and hardware was taking from the testing, revision, and documentation phases. This was possible because a lot of extra time had been built into these phases and wouldn’t affect the overall project if the amount of time was shortened.

Project Deliverables Schedules

ID Task Name1 Email project preferences

2 Subscribe mail list

3 Update web site

4 Unbound project plan

5 Post project plan to web

6 Bound project plan

7 Poster

8 Unbound design report

9 Course eval. form

10 Departmental eval. forms

11 Team eval. form

12 Post design report to web

13 Bound design report

8/309/6

9/109/24

10/810/8

10/2211/19

12/312/312/3

12/812/18

8/18 8/25 9/1 9/8 9/15 9/22 9/29 10/6 10/13 10/20 10/27 11/3 11/10 11/17 11/24 12/1 12/8 12/15 12/22August September October November December

Figure 11: First Semester Deliverables

ID Task Name14 Unbound final report

15 Classroom presentation

16 Departmental eval form

17 course eval form

18 Team eval form

19 Final presentation

20 Post final report to web

21 Bound final report

4/84/15

4/24

4/244/24

4/305/14

5/7

1/12 1/19 1/26 2/2 2/9 2/16 2/23 3/2 3/9 3/16 3/23 3/30 4/6 4/13 4/20 4/27 5/4 5/11January February March April May

Figure 12: Second Semester Deliverables

Closure Materials

Project EvaluationThe overall project has been a success. Although they were a little late to be completed most of the milestones were met.

Identify three possible designs to implement – fully metThe group found many different designs that would suit our project, Smart Device. Some of these include, vocal recognition device for creating a grocery list and home automation system using X10 protocol.

27

Pick one design – exceededThe design chosen was the home automation system using X10 protocol. The team decided to add a garage door sensor to the X10 package as well as an interactive webpage.

Completed writing software and hardware specifications for device – fully metDocumentation for the design has been written.

Completed building the design – metThe design was very frustrating at first because of the lack of information given to the team by the designers of the X10 package that was purchased for the project. Once the project got start, though, much time and work were put into its completion.

Completed testing the design – partially metThe delay in initially starting the project gave the group little time to give the project the appropriate testing. The testing that was given is suitable for presentation of the product, but not for production.

The total project met many of the predetermined milestones. The team worked hard to develop a Smart Device.

Commercialization What might be the cost to produce the product?

The team’s cost totaled about 100 dollars. If the cost of manufacturing the garage door sensor and software CD were included, the entire package would cost about 115 dollars per package.

What might be the street selling price of the product?The selling price of this package would be approximately 150 dollars.

What might be the potential market for the product?The potential market for this product would be any homeowner looking for security in his/her home. This would include parents and/or homeowners with priceless valuables.

Recommendations for Additional WorkAdditional work may include a wireless version of the X10 package. Instead of communicating through the house power lines, a wireless connection to the PC could be used.

Additional components could be a door sensor and a house thermometer. More control could also be given to the hardware modules, such as they could monitor and lock doors,

28

monitor and control the garage door, and monitor and control the temperature in the house.

Lessons Learned What went well?

Our team maintained excellent communication from the start. This allowed for our project to get off to a good start. The group was able to find the necessary equipment and was also able to easily use it. The fact that our group consisted of three Computer Engineers (CprE) and two Electrical Engineers (EE) worked out well because there was slightly more work for the Computer Engineers. The team decided on a project, stuck with it, and was able to come up with a decent product.

What did not go well?The generalization of the project’s subject made the planning and development more difficult. Before we could start working on our project, we first had to decide what device to make. Group decisions always take more time. There were some initial arguments on the EE group about how to create the garage door sensor. In addition, after our group broke into teams the sections didn’t always update one another on progress.

What technical knowledge was gained during the project?The group discovered X10 protocol and its benefit to home automation. The EE team learned about the benefits of operation amplifiers in optical transmission circuits.

The CprE learned how to develop a GUI (Graphical User Interface) web page. The CprE group also enhanced their knowledge of the Java language.

Both teams learned how to communicate with the X10 controller and how to develop input devices that improved the X10 package.

What non-technical knowledge?The team saw how much time went into a project and learned how hard it is to estimate the time needed. Time management is difficult when trying to work around everyone’s schedules. After breaking into two groups, it was easier to meet. Teamwork became more difficult as the deadline approached. The team learned how to work around that by listening to everyone’s input.

What would be done differently if you have the school session to do over again?If the school session were done over, the team would have started our project earlier. During the first semester, much of our time for senior design was spent on the project plan, the poster, the design report, and figuring out what our project should be in the first place. The group also should have budgeted time for more extensive experimentation. Time was running out and only little testing was done. If the group had communicated better with X10 Company for documentation, the project would’ve become much easier. If the school session was done over, the group would’ve contacted the X10 Company for any information they could give us.

29

Risk and Risk Management Anticipated potential risks and planned management thereof.

The anticipated risks include: team scheduling, loss of a team member, and inability to find/purchase the needed equipment for the project.

Anticipated risks encountered and success in management thereofNone

Unanticipated risks encountered and attempts to manage None

Resultant changes in risk management that were made as a result of encountering unanticipated risks.None

30

Project Team Information

Faculty AdvisorAssoc. Prof. Doug JacobsonOffice Address: 2419 Coover Hall City/State: Ames, IA 50011-3060 Office Phone: 515-294-8307 dougj@iastate.eduEcpE Department

Team MembersBrian Thorp1125 Frederickson CtAmes, IA 50010515-572-7655bthorp@iastate.edu CprE E

Scott Reeder216 S. Kellogg #3Ames, IA 50010515-233-9859sreeder@iastate.eduCprE E

Brendan Hickey244 Campus AveAmes, IA 50014515-292-5775baxter@iastate.edu CprE E

Michael Fernholz531 Welch AveAmes, IA 50014515-268-1703fernholz@iastate.eduEE

Mark Melville617 12th St.Ames, IA 50014515-232-4929melville@iastate.eduEE

31

Closing SummaryThe project itself was to design a home automation system that allowed the owner to easily check the status of his/her home (i.e. whether or not the garage door was closed or whether lights were on or not) through Internet access. The team developed the garage door sensor as well as the interactive web page. The group also configured these items to work with the X10 package that was purchased. The project’s final project will leave any homeowner with a greater sense of security.

References1. http://www.x10.com/products/x10_ck11a.htm2. http://www.chipcenter.com/circuitcellar/july00/c0700cw2.htm3. Op-Amps and Linear Integrated Circuits, Fourth Edition, Ramakant A.

Gayakwad, Prentice Hall, 2000.

32