Submission Format for IMS2004 (Title in 18-point Times font)



Smart Home

Daniel Arnett, Brian Krueger, Joseph Vanciel

School of Electrical Engineering and Computer Science, University of Central Florida, Orlando, Florida, 32816-2450

Abstract — The objective of this project is to design and implement a “Smart Home” with functionality that reduces energy consumption and allows for remote viewing and access to household electronics. The project will reduce energy consumption by shutting off unused lights by automatically sensing when someone leaves a room. The second main component of the project is a website that is hosted on the main microcontroller that will allow a user to remotely access their devices connected to the network from any web browser. There will be a graphical user interface on the website which will allow the user to view the status of lights and electronics in various rooms. The user will be able to turn any connected light or electronic device on or off at anytime, which will not only be convenient, but will also once again reduce wasted energy.

Index Terms — Graphical User Interface (GUI), Household Remote Access, Smart Home, Energy Conservation, RF, Microcontroller

I. Introduction

Facing the ever present need to conserve energy and lower monthly electricity bills, one main focus of the smart home being designed was power conservation. In reducing energy consumption, the major consideration when implementing a system is to save energy but to not let it be so cumbersome as to actually increase energy use. To this degree, it was decided to use components that consume as little power as possible in order not negate the energy savings by these electronics’ power consumptions. The various power modes and consumption of current, voltage, and power in each of these modes for the microcontrollers we used in our project can be seen in Table 1. For a comparison to our devices being used, the average light bulb uses 60 W. The average household, according to the U.S. Department of Energy in 2001, used 29.2 kWh per day. Per the Department of Energy, Figure 8 shows a breakdown of what different household electrical devices consumed as a percentage of a household’s power usage. [3]

The components consuming energy in the household that the project would impact are lighting and home electronics. Subsequently, having the lights on for a reduced amount of time will introduce less heat into the room and thus have an effect on the air conditioning bill. Even though kitchen appliances have the largest percentage of household usage, lowering energy use with these devices requires smart energy usage rather than cutting energy usage through turning appliances off when they are not in use. Lowering energy uses through smart energy uses requires another project in itself and is a future exploration of the prototype but is not the current object. However, the uses the project is looking to decrease account for a total of 32% of household energy, using the system to cut down on time when electronics are not in use but consuming energy. Considering the average household uses 29.2 kWh per day, the percentage the system is trying to decrease uses 9.34 kWh per day. Progress Energy, a common energy provider in Florida, charges Orlando users 10.76 cents per kWh. If the system can lower this amount by a net value of 3 kWh, then the system saves the user $9.68 a month. If the system can cut this value in half, then the system can save the user $15.08 a month. These figures do not take into account the price of energy when the user goes over a certain threshold and is charged more per that threshold. For Progress Energy, their threshold is at 1000 kWh per month. For the summer months, it is not uncommon for a household to go over their threshold and with Progress Energy a household would pay 12.85 cents per kWh. For a household where, during a summer month, the household consumes 1300 kWh of energy for the month, 416 kWh are used by the devices that the project is looking to lower their usage. If the project cuts this value in half, the system saves the user $26.73 per month. So it can clearly be seen that if the project can meet the objectives of cutting down energy uses in these strategic devices, extrapolating out these values, even with a meager savings of $9.68 a month, the project can save the user $116.16 per year. [1] [4]

Table 1: Microcontroller Power Usage

| |Current |Voltage |Power |

|MSP430 sleep |0.5 µA |5 V |2.5 µW |

|MSP430 awake |230 µA |5 V |1.15 mW |

|Stellaris sleep |20 mA |5 V |100 mW |

|Stellaris awake |160 mA |5 V |800 mW |

The problem with a setup that uses continuous sensor inputs alone is that once the sensors do not sense any activity, the lights will shut off in that room. This is a problem if someone is in a room, but not moving, and the lights go out since no activity was sensed after a period of time. This project gets around this problem by placing motion sensors in each room and at each doorway. If someone walks through a doorway, the sensors in each room will look for motion, thereby detecting if someone has left the room, or entered the room. This will prevent the lights from turning off unless someone has left the room. This setup will conveniently allow someone to go from one room to another without having to turn lights off and on as they leave and enter rooms. That convenience will be combined with the energy savings of eliminating instances where someone forgets to turn off lights in unoccupied rooms.

In addition to energy savings, the other motivation behind this project is that with the advances in mobile technologies, people want increasingly more access and control over all aspects of their lives. The second aspect of this project is the website hosted on the main microcontroller that allows for remote access to household devices. As long as the user has internet access, they will be able to type in the IP address of the main microcontroller and bring up the website containing the graphical user interface for the project. On this interface, the status of each connected light and electronic device in each room can be accessed. The user will also be able to turn on and off any device by clicking on the corresponding button on the interface. This convenience will be coupled with the opportunity for energy savings since the user will be able to shut off devices without having to travel home.

When researching our project, we considered other comparable systems that were already in existence to both find ways to separate ourselves and to build off of. Project JARVIS was the project that came closest to what we were designing, but using different methods to solve similar problems. [2][6]

II. System definition

A. Definition

The design starts with a main microcontroller at the center of the whole design (referred to as the “brain” of the project), which handles communication between all internal modules. Since the project also required a server hosting a website which would serve as the graphical user interface for the user, the Stellaris LM3S8962 by Texas Instruments was chosen. This microcontroller has the capability of hosting a website, while it also has the remaining functionality needed to support all of the required features. Its power consumption is low, which was an important factor in deciding which microcontroller to use in our system.

In each doorway separating each room, there is a motion sensor to detect someone entering or leaving. The motion sensor chosen was the Panasonic NaPiOn series. This motion sensor was chosen due to its lower power consumption and functionality. Each doorway sensor is hardwired to a microcontroller. The microcontroller for the doorway sensor to be wired to is the Texas Instruments’ MSP430, because of its ultra low power consumption. In a future implementation, the MSP430 could be connected via an RF connection to the Stellaris LM3S8962. However, for this project, the connections were hard wired. When RF would be implemented in the future, the transceiver chosen would be Texas Instruments’ CC1101, for its low power consumption, and would be connected to the MSP430 as well as the Stellaris LM3S8962. The communication will be bi-directional, from the doorway sensor/MSP430 to the Stellaris LM3S8962 and vice versa. When the doorway sensor senses motion, it will send a signal to the MSP430, which will then begin to listen for signals from the input sensors in both of the adjacent rooms to the doorway where the sensor was tripped. All changes of lighting status will then be communicated to the Stellaris LM3S8962. After thirty seconds of listening, if a room that an Infrared Sensor is searching for input has not found any, the main light for that room is automatically turned off.

The outlets in each room that will be able to be turned on and off have power supplied via the wall, and are connected to a low power relay and an MSP430 microcontroller. When the user accesses the graphical user interface and toggles a particular outlet, that corresponding outlet’s relay will open or close.

One MSP430 microcontroller is interfaced with the Passive Infrared sensor and its adjoining doorway MSP430 microcontroller and motion sensor module.

[pic]

Figure 2: Prototype Design

B. Prototype Layout

For demonstration purposes, a model house was constructed out of wood, having three mini adjoining “rooms”, with two doorways, one doorway connecting each of the two rooms to each other as seen in the prototype design in Figure 2.

The project will be connected to a router via an Ethernet cable that will broadcast a wireless signal to create a local network. A visual description of the overall design can be seen in Figure 3.

C. Requirements

• Once the user connects to the main microcontroller’s hosted website, the GUI is displayed in the users internet browser

• In the GUI, the latest status of all lights and outlets is displayed

• When a user clicks a selection to turn a device on or off in the GUI, the correct corresponding device will turn on or off accordingly

• When a doorway sensor is tripped, both adjoining rooms search for input for 30 seconds via the PIR sensor and the lights in both of the rooms automatically turn on during the search period

• During the search period, when input is found in one room, the lights remain on until the user turns the lights off or exits the room

• If no input is found in a room during the search period, the lights in the room turn off within 1 ms.

Figure 3: Overall Design

III. Design

[pic]

Figure 4: GUI Design

A. Graphical User Interface

The user is able to bring up the IP address of the website by typing it into their web browser. Upon doing this, the browser loads the webpage that has been created for them to view and control all of their devices connected to the network. The display is written in HTML 4.01 and uses JavaScript. The design, including the buttons, text, layout, etc., is coded in HTML. We wanted to give the users a nice backdrop to control the system, but this was not the focus of our design. The website was programmed in a way such that as the status of different electronics and lights change, the webpage is dynamically updated. The website uses JavaScript running in the web browser to send HTTP requests for special URLs, depending on the button clicked and corresponding to the device that status is being sent to or requested for. These special URLs are intercepted in the file system support layer (lmi_fs.c) on the Stellaris and used to communicate to both send a message to the corresponding MSP430 to change status as well as to store the latest status in the RAM of the Stellaris. Responses generated by the Stellaris are returned to the browser and inserted into the webpage dynamically using more JavaScript code.

Figure 5: GUI Flowchart

Above, Figure 5 shows the flow of the system from the software standpoint can be seen.

B. Stellaris Design

The project is built on a system based on passing ASCII characters as a means of encoding each message. Using the 8 bits that comprise each ASCII character, the message is broken down as seen in Table 2 below:

Table 2: Message Bit Descriptions

|Bit |Description |

|1 |0=Sending Status, 1=Requesting |

| |Status |

|2 |Unique Address |

|3 |Unique Address |

|4 |Unique Address |

|5 |Device Type |

|6 |Device Number |

|7 |Device Number |

|8 |Device Status (On or Off) |

Once the Stellaris receives the URL within the file system support layer that specifies what action to take, the character is passed on to two separate functions. First, the state of the device, as stored in memory, is loaded. Then, if the URL sent is requesting to toggle the device, the character is sent to the UART_Send function and placed in the UART buffer to be outputted. The status of the device, which is stored in the on chip RAM, is then updated. Table 3 shows how the device is stored in RAM:

Figure 6: Stellaris Code Flowchart

Figure 7: Stellaris Schematic

Table 3: Memory Storage Design

|Initialized Value|Status On |Status Off |Address in Memory|

|0x99 |0xFF |0x00 |0xXX |

where XX = the ASCII value of the message, and the physical memory address = 0xXX + 0x20002000. Using this design from Table 3, there is direct access to memory without even needing to use a hashing function or allocate a large amount of memory. In the event that a light’s status is changed via the MSP430’s Passive Infrared sensor connected to it, the input received by the Stellaris triggers an interrupt and the UART_Receive function is called. This function pulls the value that has been pushed onto the UART Buffer and then updates the status of the device in memory using the encoded message. The overall software flow of the Stellaris can be seen in Figure 6.

The design of the Stellaris, as seen in Figure 7, was built with the intention to use a design similar to that of the evaluation module.

[pic]

Figure 8: RF Schematic

C. RF Design – Future Implementation

In a future implementation, it would be advantageous to have the communication between the different modules go through RF channels. Figure 8 shows a designed RF schematic. When using RF, once a message has been put into the UART buffer, the RF module then reads and pulls the value off of the buffer and broadcasts the message to all the other RF modules. These modules would be outfitted with the CC1101 transceiver. Each message is sent out over the 900 MHz frequency (One of the non-proprietary frequencies per the FCC). In order to ensure the modules are all tuned to the correct frequency, the module would be outfitted with a variable capacitor. When sending out messages to a specific device on the network, all devices are sent the message, and the message’s encoded address allows the devices that the message is not intended for to discard it.[3]

[pic]

Figure 9: MSP430 Schematic

D. MSP430 Design

Whenever a message is received the MSP430 will immediately put on hold whatever it was doing to process the data. The address bits are examined first to determine if any action is needed or if another processor is being called. If it is, it continues on, otherwise it goes back to sleep. The next bit that is looked at determines if the brain wants a full status update. If it requires the full status update, the MSP430 will load up the queue with the current status of the lights and outlets. If not the last four bits are pulled out for processing. If all the bits are high then the MSP430 will remove the next value in the queue and decrease the count of values to send to the brain. Otherwise it will determine what the brain wants changed and update the memory accordingly. Lastly, before returning to whatever it was doing before, it changes the outputs to the relays according to what is stored in memory.

E. Relay Design

When the MSP430 needs to turn the relay on or off, the signal must first be sent through a transistor pair to amplify it to the point where it can drive the solenoid.

[pic]

Figure 10: Relay Schematic

The transistor pair can be seen in Figure 9. This amplified signal is then sent over a cable to the inputs of the relay in Figure 10. The pair was needed as opposed to a single transistor due to the possibility of needing to control a highly inductive load. Unless the signal from the processor is strong enough the inductive load can overpower the relay and keep it in the undesired position.

[pic]

Figure 11: PIR Schematic

F. PIR Design

Passive Infrared (PIR) sensors were chosen to be the eyes of the system. When someone passes through a doorway, the PIR sends a signal to the MSP430 through a single transistor amplifier that can be seen in Figure 11. As can be seen in Figure 12, the MSP430 will then turn the lights on in its room, send a status update to the brain, and start taking readings from the room PIR sensor. Using the same set up from Figure 11, the room PIR will search for movement for about 30 seconds. If no movement is found the MSP430 will turn the lights off and update the brain. If movement is found the MSP430 will leave the lights on and return to sleep. The messages are created by the MSP430 in the same way they are decoded; bit by bit it goes through and constructs the byte to be sent. The message is then loaded into the UART buffer created in software to be periodically sent. The message will re-send every few seconds until confirmation is received from the brain that it was received.

Figure 12: MSP430 Code Flowchart

G. MSP430 Initiates Change

The MSP430’s message is sent out based on the device

that has been changed. The message, as described before, is a single ASCII character encoded with which device has been changed. This is received by the Stellaris, and then stored in the onboard RAM of the Stellaris accordingly. When the user then views the controls page, the webpage will request the current status from the Stellaris’ on board memory and send it back to the browser by inserting the status into the page dynamically using the JavaScript functions.

IV. Testing

The system was subjected to a modular testing environment, in which all modules were tested before the final prototype with all modules integrated was tested. The main goal of unit testing was to verify:

• The MSP430 and Stellaris could both send and receive any character between one another, with acknowledgements being sent when messages were received

• The webpage could send updates to the Stellaris board and change the status of an LED

• The webpage could retrieve information from the Stellaris stored within the chip’s own internal RAM

• The MSP430 could detect which room is receiving input via the PIR sensor

• The MSP430 could be turned off by an external switch

Upon all of these conditions being met, project was tested at a system level. The goals of system level test was to

• Verify when a device is toggled on the webpage the corresponding light is changed on the MSP430

• Verify when a device was toggled from the MSP430’s end (switch or room change), the website was updated automatically

V. conclusion

Our project was a very enjoyable experience for the entire group. Our project was one with high expectations and many different methods of implementation which was avidly debated within the group and ultimately highly agreed upon by all group members. We set out to demonstrate the capabilities our project in terms of both home automation and energy conservation. We feel we accomplished our goal, and would like to build upon what we’ve done in the future.

Acknowledgement

The authors wish to acknowledge the assistance and support of Workforce Central Florida for providing funding and mentorship for our project, as well as Dr. Michael Georgiopoulos for helping coordinate the program.

We would like to thank Sean Donovan for acting as a mentor to the group and overseeing and guiding the project as well as providing helpful insight into all of our presentations and documentation.

We would like to thank Herb Gingold from Texas Instruments for, as is usually the case, providing us with many resources with no charge to us including training, hardware, and help whenever needed.

Finally we would like to thank Dr. Samuel Richie for his overall guidance and support. He was constantly there to help push us to excel beyond our own expectations.

Biography

Joseph Vanciel will be graduating Summa Cum Laude in May of 2012 with his Bachelor of Science in Electrical Engineering. His studies have concentrated in control and embedded systems. Joseph currently works as a tutor for Valencia College and as an associate manager for Classic Architectural Products. Joseph plans on moving directly into the workforce after graduating, and slowly working towards a Masters degree through the finacial assistance of the company he works for.

Brian Krueger will be graduating in May 2012 with his Bachelor of Science in both Electrical Engineering and Computer Engineering. His main focus in his studies has been embedded systems. He is currently interning in the UCF College Work Experience Program with Lockheed Martin and will do so until graduation. Brian plans to move directly into the workforce in government defense after graduation and then pursue a Masters degree in Computer Engineering abroad after working for a few years.

Dan Arnett will graduate with honors and receive his Bachelor of Science in Computer Engineering in May of 2012, and previously received a Master of Science in Business Administration from the University of Florida. Dan plans on moving into the workforce as a software engineer in Brevard County after graduation.

References

John Conti, “Annual Energy Outlook 2011 with Projections to 2035,” DOE/EIA-0383(2011), no. 2011.

[1]

Chad Barraford, “Project Jarvis.” [Online]. Available: . [Accessed: 04-Dec-2011].

[2]

D. Grini, “RF Basics, RF for Non-RF Engineers,” presented at the MSP430 Advanced Technical Conference 2006 (Texas Instruments), Dallas, Texas, 2006.

[3]

Texas Instruments, “Stellaris® LM3S8962 Microcontroller Datasheet.” Texas Instruments.

[4]

“U.S. Household Electricity Report,” 14-Jul-2005. [Online]. Available: . [Accessed: 04-Dec-2011].

[5]

Ahmed, I.; Hong Wong; Kapila, V.; "Internet-based remote control using a microcontroller and an embedded Ethernet," American Control Conference, 2004. Proceedings of the 2004 , vol.2, no., pp.1329-1334 vol.2, June 30 2004-July 2 2004

URL:

[6]

Panasonic Electric Works, “MP Motion Sensor ‘NaPiOn Datasheet.’” Panasonic.

[7]

-----------------------

Figure 1: Energy Usage

[pic]

[pic]

[pic]

[pic]

................
................

In order to avoid copyright disputes, this page is only a partial summary.

Google Online Preview   Download