group 36: the occupancy project - iowa state...

Group 36: The Occupancy Project Advisor: Mani Mina, Client: Mani Mina

Team Email: [email protected]

Group Members:

Shaun VanWeelden - [email protected] Sam Ennis - [email protected]

Lee Robinson - [email protected] Mike Pruszinske - [email protected]

mailto:[email protected]

Senior Design | The Occupancy Project | Final Report

Table of Contents

Where’s An Empty Room? 2

Project Statement 2

System Design 2

Minimum System Requirements 3

Input Specification 3

Output Specification 3

Hardware Specification 3

Software Specification (Arduino) 3

Final Hardware Implementation 4

User Interface Specification 4

Challenges 5

Testing 6

Software Design Diagram 8

Conclusion 8

APPENDIX I: Operation Manual 10

APPENDIX II: Design Progression 11

Initial Hardware Implementation and Prototype 11

Progress this Semester 12

Spring 2016 | Group 36 1


Where’s An Empty Room? Every finals week, students have trouble finding places to get together and study exam materials, finish group assignments, and meet up. Not only that, throughout the year, school administrators try and make informed decisions about room and power usage for on campus buildings. We focused on developing a solution to assist both students and school administrators with some intuitive software and hardware innovations.

Project Statement As homes and offices around the country are rapidly becoming connected to the web via the Internet of Things, they provide people with previously unknown information that can offer a wide variety of benefits. We want to provide these benefits to Iowa State University, as well, by making its lecture halls, classrooms, and offices “smart.” Our project makes use of IoT data to reveal classroom availability information to both Iowa State students and staff. We noticed the occupancy sensor pictured on the right is in almost every classroom at Iowa State to turn the lights on and off. Wouldn’t it be cool if we could make it “smart” by gathering its data to store, process, and visualize online? Rooms around the university will report their current occupancy status via an occupancy sensor to a userfriendly web application. With this new room occupancy information, students can make informed choices about where to study and meet, and the university can make informed decisions using our application’s analytics about classroom usage (room popularity, energy consumption, etc). Because of Iowa State’s continued growth in enrollment, managing classroom usage effectively is more important than ever. The Occupancy Project will help Iowa State get the most out of their current buildings and be at the forefront of smart and sustainable technologies.

System Design Our entire ecosystem has three main components: the existing occupancy detection sensor, the integrated hardware device, and the web portal. Successful communication between these three components is crucial. Our final hardware device integrates directly with the existing occupancy detector. We use the voltage that powers one of the debugging LED lights to signal the microcontroller on our hardware device that motion has been detected. As referenced later in more detail, our device then communicates with the web portal, allowing users easy access to data we’ve collected. This entire ecosystem is designed to be costeffective and easily scalable for a large institution such as Iowa State University.



Minimum System Requirements ● Preexisting occupancy sensor ● Our WiFienabled integrated hardware device ● Our interactive web application ● WiFi network ● User

Input Specification The input to our device and microcontroller is the LED output from the existing occupancy sensor. This output voltage ranges between 05V. The value changes when the existing sensor detects a change in occupancy. From there, we update the database with the new state.

Output Specification The output of our occupancy sensor is readings sent to the database. Our sensor communicates via wifi with our NoSQL database (Parse.com). When the input value passes the threshold and is triggered, we use the Parse REST API to send the updated state to the database. This value is either “true” or “false”. Each device has a MAC address that allows the database to know which boolean value to update.

Hardware Specification Our device, which has an Adafruit HUZZAH ESP8266 microcontroller at its core, is powered by the existing 20V power supply to the occupancy sensor. This allows the device to connect to the wifi network. The device remains on and connected to the network while the occupancy sensor is powered on. Our device receives its input signal from one of the outputs of the occupancy sensor. When the signal is high, it signifies that the sensor detects occupancy.

Software Specification (Arduino) The Arduino software on the microcontroller has two main states: setup and loop. Our setup involves establishing a Serial connection for debugging. We communicate that we are setting up the device and connecting to the network. Next, we attempt to establish a connection to the IASTATE wifi network. If that connection was successful, we send out our initial state, which is false. The next state is the loop phase. This section repeats in the background for the entire lifecycle. Our software is continuously monitoring the input specification, and then inturn potentially producing the output specification.



Final Hardware Implementation

Our final hardware design involves the device integrating directly with an existing occupancy sensor. We use the voltage that powers one of the debugging LED lights to signal our microcontroller that motion has been detected. Once our servers receive this, we log and visualize the data accordingly.

User Interface Specification The user interacts with our application via our web application.The application displays floor maps of buildings that we have wired up with our occupancy sensors. The building map will display the occupancy status of these “smart” rooms, pulled from our database, with either a green dot for “room open” (not occupied) or a red “x” for “room occupied.” The user is able to click on the room to view more details about it its capacity, amenities it contains, etc., as well as view the room’s reservation status and historical usage (analytics).



Challenges We face multiple challenges this semester as we worked on both the hardware and software implementations of our final solution. Here is a brief description of a few of the issues that we faced and how we resolved them. Pinging the server on every reading complicates things The sensor reads every second. If we pinged the server every time, that would create unnecessary WiFi traffic and redundant data (86,400 readings per day). Solution: ● Algorithm on sensor’s microcontroller makes judgement based on previous minute’s (60

readings) worth of readings stored in memory ○ For example: If >20% of readings were “occupied”, room is “occupied” during that

minute ● Pings only on state change

○ Maximum 1,400 readings per day, realistically significantly less Too many readings to load in for analytics Even after reducing the amount of pings to the server, there are far too many data points for analytics. Solution: ● We must aggregate and store this data, because loading every single data point (say, for

the last month), is way too expensive. ● Created “DailyReport” database class, with the following form for efficient data access:

● Can be aggregated further to weekly and monthly reports with hourly averages.



Determining if solar panels provided enough power We created solar powered circuits and ran tests against a variety of indoor lighting conditions throughout Coover to see how much voltage and current could be obtained ● We discovered that solar panels would not create enough power for our device due to

indoor lighting and minimal sunlight ● 4050 mV and <.200 mA in normal Coover classroom conditions

● Even multiplying the number of solar panels still wouldn’t be a viable solution Solution: ● Decided to tap into the constant power supply from the existing device

● This mitigates fluctuating solar conditions and ensures consistent power

● Lower cost than compared to solar panels on each device Using interrupts caused WiFi to reconnect every time, causing occasional errors While searching for a powersaving alternative to a constant connection, we realized that using interrupts would cause the wifi to disconnect and reconnect every time the device powered off. Not optimal since the connection time could be slow and the device could potentially not connect. Solution: ● Explored using the hardwired power from the existing device

● Purchased existing occupancy sensors identical to existing ISU sensors

● Modified the device and added our customized microcontroller

● Consistent success rate when pinging server with status

Testing Phase I – Preliminary Functionality Goals:

Ensure network connectivity from device Determine battery life of device using 9V battery Confirm occupancy status updates appear on website

Methods:

Created system to ping database from website to simulate data for new rooms Monitor device output & text log to determine connectivity



Device pings website until it dies, check last ping time Attached sensor to real hardware in Coover to demonstrate application Visit website and verify changes are shown visually

Results:

Connectivity successful. Repeated 10+ times. Pass Battery life was 4248 hours when constantly pinging. Fail Web application successfully shows updated status. Repeated 25 times. Pass

Phase II – Final Functionality Goals:

Determine solar panel + capacitor voltage/current output Test device when connected directly to host device power Test continued network connectivity Test scalability when adding many sensors & classroom data

Methods: Use EE lab equipment to test hardware capabilities and output Wire device to building power from existing sensors Monitor logs to determine connectivity status Spoof multiple sensors, data, and simultaneous pings

Results:

Solar panel performance abysmal. 4050mV and <.200mA in classroom conditions. Fail. Device successfully powered and operated. Pass. Connectivity successful. Repeated 10+ times. Pass. Web application successfully continued to work. Pass.

Phase III – Anomalies & Security Goals:

Test what happens if wifi/network goes down temporarily Analyze security/public accessibility of device Test access to database restricted to approved devices

Methods:

Monitor device output logs after disabling wifi and power Manually turn off device and observe how database/web app handles situation Attempt to send spoofed/fake pings to our database

Results:

Device successfully reconnects to network and continues reporting. Pass.



Device maintains a sufficient level of security, unable to be accessed. Pass. Database maintains a sufficient level of security, unable to gain access. Pass.

Software Design Diagram

Conclusion We are confident that our project will provide Iowa State University’s students and staff with extremely valuable analytics on room occupancy. We are enthusiastic that the information we provide will be utilized in a way that will provide many benefits. Whether students are using it to find an open study location or the university’s building staff is using it to make sure that a building is being used in the most energyefficient way, we are adamant that our product will make a positive impact. By implementing a userfriendly website and mobile application, we will make sure the data our hardware generates is easily accessible and usable by as many people as possible, while also allowing us to showcase the strong software background we have built during our education at



Iowa State. We will also strive to deliver hardware that not only works as described, but also is packaged compactly and efficiently, with intent for it to become a scalable, marketviable device. In combination with the diverse hardware and software skills we will be utilizing throughout this project, we will continue to learn and practice business skills such as negotiation, pitching, marketing, and product adaption to customer needs, all of which will be extremely valuable in our future careers.



APPENDIX I: Operation Manual Setup

1. Gather the required materials listed in “Minimum System Requirements” 2. Ensure the WiFi network is up and running 3. Power on the occupancy sensor 4. This will in turn power on our hardware device located inside 5. Check the database for the initial reading of false from the MAC address

Demo / Testing

1. Ensure device is properly setup and configured 2. Check the database and confirm the occupancy reading is false 3. Have someone/something trigger a change in occupancy 4. Recheck the database and view the updated state



APPENDIX II: Design Progression

Initial Hardware Implementation and Prototype

We initially brainstormed a solarpowered occupancy sensor addon attached to the exterior of a sensor, transmitting over WiFi to our software system. Our first try is pictured above. We evaluated software and hardware components for cost, ease of integration, longevity , and electrical and spatial requirements. As we built out our application, several initial ideas had to change before we decided on our final hardware implementation integrated inside the sentence . The original prototype was designed to latch on the back of the device and be selfpowered by a 9V battery. After a variety of experiments and testing, we determined this was not the best solution. A 9V battery was not sufficient to power the device reliably for longer than 48 hours. Our target was a minimum nomaintenance period of one year. Through testing, we realized that a solar panel would not be a viable power source, either. This was resolved when our hardware design changed to an integrated solution inside the sensor. We now get power from the sensor itself.



Progress this Semester Hardware

1. Revisited prototype from last semester 2. Ran tests with interrupts to determine if it was viable 3. Created solar panel circuits to test output power 4. Determined we needed new approach, hardwired power 5. Ordered new hardware (existing sensors) 6. Developed new prototype using existing sensors power 7. Successfully pinged database with status of sensor

Software

1. Populated database with room information for all of campus 2. Developed advanced search functionality to find particular rooms 3. Used graphs to display frequency of room usage 4. Improved user interface by adding additional list view


group 36: the occupancy project - iowa state...

Documents