for EECS and CSE Majors at UC Irvine
Smart A/C Ventilation System
This is an archive site. Current senoir design projects are at https://projects.eng.uci.edu.
Topic:
Idea source:
Team Name:
Group 43: Team Harambe
Project Title:
Smart A/C Ventilation System
Team Members:
Aaron Daniel
Austin Raun
Hunter Meurrens
Tex Taylor
Team Mentor:
Professor Fadi Kurdahi
Project Description:
Our team will be creating a Wi-Fi connected air vent which is controllable via a smartphone app and serves as a replacement to existing air conditioning vents. The purpose of our product is to easily open and close vents as necessary to optimize airflow and reduce cooling costs.
Our project will be using a microcontroller (MCU), an electric motor, a physical vent, a power source, a temperature sensor, and a smartphone app. We will then connect the components and ensure that the motor, and therefore the air vent, is controllable via the MCU. Simultaneously, our team will be designing a prototype control app which will be used to connect to the MCU via Wi-Fi.
The overall goal of this project is to design a cheap and simple product that anyone can use to optimize their pre-installed home cooling systems, thus reducing electricity consumption. With our mobile application, our design allows users to conveniently manage the air conditioning vents throughout a house remotely. Using the app, a user can control vents to open or close manually, or automatically depending on the temperature of each room, allowing the user to save energy that would have been otherwise spent on making a cold or unused room colder.
Bill of Materials:
Materials:
Air Vent: $8.50
o Acord 202 Series Painted Steel Sidewall/Ceiling Register
Actuating Component (to open and close vent): $18.42
o Spektrum Linear Tail Servo
o https://www.amazon.com/Spektrum-2-9g-Linear-Tail-Servo/dp/B008X68OG0
Microprocessor: $16.00
o Adafruit Feather
o https://www.adafruit.com/product/2821
Power Source: $7.00
o Lithium Ion Polymer Battery – 3.7V, 350mAh
o https://www.adafruit.com/products/2750
Thermistor: $1.00
o NTC Thermistor 10k
o http://www.oddwires.com/ntc-thermistor-10k/
Total Unit Price: $50.92
Similar Products:
Keen Home Smart Vent
o The Keen Home Smart Vents utilize temperature and pressure sensors to determine the opening/closing of the vents.
o Conceptually similar product with equivalent usability but for an outrageous price; individual vents costing over $100.00.
o Also, for each vent to be wirelessly compatible the user must purchase a vent central hub from the same manufacturer called the Smart Bridge for roughly $40.00.
o https://keenhome.io/smart-vent
Vent-Miser Programmable Energy Saving Vent
o Manually operated programmable vents with individual timers that require frequent reprogramming of scheduled settings on a weekly basis.
o Costing roughly $40.00 per vent, the Vent-Miser is the cheapest alternative to our design but is lacking in optimal usability and a user-friendly mobile interface.
o https://www.amazon.com/Vent-Miser-91665-Miles-Kimball-Vent-MiserTM/dp/B000MWA15U
Mobile Application Design:
Project Update 1
In order to try and optimize the manner in which we progress, we have decided to split into two teams: the hardware team, which will deal with the Arduino coding environment used to interface with the Adafruit Feather and ensuring power is taken into account, and the software team, which will use Android Studio to handle the application side of the project, ensuring that the Java application works as intended and correctly communicates data to and from the Feather. Any other obstacles that we face, such as how exactly we’ll attach the materials to the vent, we will solve as a team.
Hardware Team
We started off by installing the required software to setup the Adafruit Feather board. After getting everything set up, we then wanted to write a script to control writing data to the default 0 pin on the board, which controls a red LED. Our first script for the board caused the red LED to blink on and off, repeatedly. Knowing how to interface with the pins will be useful later when needing to control the motor and temperature sensor.
Running a blink test script to test writing data to pin 0 (red LED).
We then moved on to connecting to WiFi; luckily the Adafruit website provides a tutorial on how to connect to WiFi, and after some time we were able to get a console output of the picture shown below, confirming our board connected successfully. Now that we know how to establish a connection with WiFi, this will help us for when we need to communicate data between the vent and the phone application.
Arduino serial console result after running WiFi test script.
Our next goal was to do figure out how we were going to interface with the servo motor, although we didn’t have it at the time. After doing some research, we were able to find out a few specifications of the motor we bought (listed below), with some notable ones being the operating voltage (3.2V - 4.2V) and the torque (272g). One concern is whether this will be enough force to move the air vent slider, otherwise our final product may either need a different vent with a less resistive slider, or a more powerful linear servo. We then learned of Arduino’s Servo library, giving access to simple-to-use commands that allow you to control a servo motor; the documentation also came with examples, which will prove to be useful when we are going to implement our algorithm.
Product Specifications for Linear Servo Motor
This week we managed to setup the board, ran scripts that dealt with setting pins and connecting to WiFi, and did a little research on controlling servos. Since we don’t have any experience working with the Arduino coding environment, it has proven to be a bit of a challenge. Next week we plan to test out the linear servo and begin writing algorithms for it.
Software Team
On the software end, our goal for the week was to research Android applications and then create a skeleton UI for our Android app interface. With very little exposure to Android application development our primary challenge is learning how the software works. Working with and browsing a handful of open-source resources online, we were able to make some solid progress on the UI. The portion of the application we completed was the UI skeleton. This allows us to tap through screens, however we have yet to add any additional functionality.
Utilizing this skeleton, we will be able to keep our work more organized and focus, completing functionality for the app on screen at a time. Our goal for our next meeting will be to create working buttons that, once connected to the vent, will control its open and closed states. In addition, a backend database of some form will need to be implemented to store the data regarding each vent. As of now each button is hardcoded, but in the future, they will be created dynamically depending on the vent information the user has added utilizing the “Add Vent” screen.
Our current progress on the UI skeleton is shown below:
UI Skeleton Interface Progress - XML, Java (Android)
Java (Android) Code Progress - Flipping Between Pages
Project Update 2
Hardware Team
Over the past week we first looked at the actual vent itself. It seemed that the friction caused by the metal against metal was far too much and the strength of the motor was nowhere near strong enough. Deciding on what was the best plan action, we first chose to lubricate all the moving parts on the vent. It dramatically smoothed out the opening and closing. However there is still an initial tug in the beginning so as of now the vent will not be 100% closed.
In terms of the servo we have set up the connection onto the breadboard with the feather weight setup as well. However when we run the code using the arduino ide on the laptop we get no result on the linear servo. The two reasons for this could be code error and wrong API reference or maybe voltage is too small. Also we noticed the connector was too small and the wires are extremely thin and weak, which might play into the factor of not enough current/voltage.
Despite the setback of the servo not reading signals properly, we have begun the process of writing code for the behavior of the servo motor depending on the state it is in. In order to achieve the functionality we want, we chose to use 4 different states the servo/vent can be in: Open, Closed, Opening, Closing. Since we cannot test with the servo motor right now, we are using LED blinks on pin 0 to represent the states. During the 'open' and 'closed' states the motor doesn't move, but in the 'opening' and 'closing' states the motor will continually move until it reaches an 'open' or 'closed' state.
The 4 Servo Motor states represented with LED blinks
Software Team
The previous iteration of the app was more of a slideshow rather than in interactive app. After redesigning the layouts and better understanding how to assign functions to button presses. The updated version now has specific screens for each function and can be intuitively navigated with associated buttons. It should be noted however, that the buttons corresponding to the example vents are hard coded. In other words, they are buttons that have been placed in the layout that can either be turned on or off. The goal for the next iteration of the app is to create a database which is capable of holding “vent” objects. These objects will be associated with a physical vent when it is connected via the “Add vent” screen. For testing however, the new vent screen will simple create new “vent” objects within the software. These vents will be stored in an array. All screens (such as the “Vent Control” screen) will have their vent list and vent states populated dynamically based on the Vent_Array’s data.
Furthermore, our team implemented tabs to navigate from one screen to another screen. We have also implemented a settings button at the top right which will forward the user to the mobile applications user’s settings page that can be configured (such as notifications, customizations, etc.). For application usability, it is likely that we will combine the above “mock” applications pages with the layouts tab. Examples of the implementation of these tabs can be found below.
Project Update 3
Hardware Team
This week we attempted to connect and send signals to the linear servo again, but after hours of messing around with it we still couldn’t seem to get the servo to respond. Nevertheless, we proceeded working by researching how to control servos using the Arduino Servo library and began implementing the servo functionalities as if the servo were still working.
The servo library includes 6 functions: attach(), write(), writeMicroseconds(), read(), attached(), and detach(). These functions are explained in more depth below.
attach() - Attaches the servo to a specific pin, allowing for that pin to be where the servo gets it’s data from. You can also specify minimum/maximum pulse widths if needed.
write() - Writes a value to the servo, causing the shaft to move accordingly depending on the angle input (typically from 0 to 180 degrees).
writeMicroseconds() - Writes a value to the servo, causing the shaft to move accordingly similar to the write() function except is in microseconds (typically from 1000 to 2000 microseconds).
read() - Reads the current angle of the servo (the last value written to it).
attached() - Checks whether a servo is attached to a pin, returning 1 if true, and 0 if false.
detach() - Detaches a servo variable from the pin it’s attached to.
After familiarizing ourselves with the Servo library, we altered our previous code to reflect more the algorithm we will need to use to control the servo. As you can see, the major changes are that the opening and closing states now show how the servo will have to continually make small steps towards an open or closed position (all the way to 0 or 180 degrees).
4 Servo Motor states -- Updated
Software Team
Our goal for this week was to implement a database in which to store Vent objects, as well as programmatically creating the Vent objects themselves. In addition, these vent objects should each dynamically populate a button under the “Vent Control” which will later be used to control the state and set temperature of the Vent. All three main goals were accomplished. Primarily, we created a Vent class which stores all information about a single vent such as its name, state (open/closed) and set temperature (which will be utilized much later in the project); it also holds helper methods for the class. Next we created the ventList class, which holds an ArrayList of vents as well as necessary helper methods for simply implementing the class. Finally, the application creates buttons associated to each vent held in ventList on the main “Vent Control” screen. Upon initializing the app, “Vent Control” appears populating no vents because none have been added:
Next, by selecting “Edit” -> “Add New Vent” -> “New Test Vent”, a new vent object is created. Note that this “New Test Vent” button is only for testing purposes. In the final product, a vent object will only be added when a physical air vent is connected to the app.
Once one or more Vents have been added, they will be displayed under the vent control screen. Since we have yet to figure out how to utilize android’s keyboard, the vents currently create their names automatically using a counter. Later on, the user will be prompted to enter the vent’s name upon vent creation. Below shows the “Vent Control” screen after vents have been created.
Also, it is worth noting that the app currently holds all data in RAM, meaning that once it is closed and restarted, it looses all stored vent data. As the app’s development progresses, permanent storage will be implemented.
Our goals for next week are as follows:
- Figure out how to use the Android keyboard to enter text and name vents
- Have each button initialize to a green color (indicating the vent is open) and be able to click it to turn it red (indicating the vent is closed). These colors should be associated to the vents current state, held in the “Vent” class.
- Finally, once the above goals have been met, the “Edit Vents” page should be populated with vents and allow the renaming and removal of them.
Project Update 4
Hardware Team
This week we set out to try and connect to the servos again, and after much trial and error and messing around with wires and connections we were finally able to have one of the servo motors respond. The motor we were able to get to respond is the Tower Pro SG90 servo we have, while the linear servo still seems to be having trouble getting the signal. The SG90 may not be a linear servo, but we feel like it can still be used to implement the sliding of the vent.
The Rotational Servo turning 180 degrees to switch states
The SG90 is a rotational servo as opposed to a linear one, but it has holes on the rotating arms that we could use to tie a string between it and the slider of the vent. Once we get it up and running, we modified our code to switch back and forth between open/closed states, with a red LED turning on when it is open, and off when it is closed. Now that we have the different servo states implemented and the code to have the servo go between the two, we will now have to work with our software team to figure out our method we plan on using to send and receive the data between the app and feather through WiFi.
The Servo in a closed state (LED off) and an open state (LED on)
Software Team
Over the past week a solid amount of progress has been made. Although we initially struggled with Android onClick() functionality, we successfully surpassed the checkpoint we set as a goal last week. As illustrated in the following figures, our Android application now has colors to represent vents that are open (green) or closed (red). Within the Edit Vents layout, we also added further functionality that allows for all vents configured to be turned off, or turned on. Similarly, clicking indivudal buttons will change their state to the opposite of its current state.
Our team is excited to work on connecting all components over the next week and hope to begin on basic communication functionality. As a goal it would be exciting to successfully have some aspect of the app able to command the vent (through the Arduino) to open/close. At the very least, we want to further the practicallity of our application and figure out how to connect our devices before the end of next week.
App Vent pages with Open/Close functionality
Project Update 5
Hardware Team
This week we made huge steps toward integrating the motor with the internet as well as connecting to the app. We wanted to test to see if the arduino device could connect to the internet and pull information off of it. To do this we set up a host server using adobe tomcat and uploaded a javascript file to the loopback ip address. Then getting the actual ip address of my laptop we fed that to the arduino device and were able to fully connect the two devices. Not only that, but we were able parse and modify strings in the body of the html page(hosted on tomcat) confirming that we could pull data from the internet becoming one step closer towards communicating with the app.
HTML Code of Example Web Page
However we do realize that this is just a testing stage and that tomcat can only host a local file meaning the file isn’t actually connected to the internet, just the computer. Nonetheless, since we can read data from an HTML file, we can create a system in which we can represent our vents, their status, and use this to update the vents with the Feather.
Example HTML web page with Vent information
Software Team
The focal point of this week’s development was allowing the vents to open and close in a dynamic manor. In the previous update, the open/close buttons were created statically, meaning that there were always 5 of them, regardless of how many vent objects were stored in the app. In addition, we wanted to have the colored vent buttons control their states on their own, without the need for additional buttons. In this revision of the app, both of these goals have been accomplished.
The next goal we had for the week was building the functionality to delete a vent. While the “Test Add” button on the “add vent” screen handles adding vent objects, there was previously no way to remove vent objects from the system. This functionality has now been implemented, and all screens and buttons update accordingly when a vent object is removed.
Project Update 6
Hardware Team
This week we worked on algorithms for interpreting text on the html file and deciding how to handle the information. Basically, a set of rules for interpreting the text on the html page and turning it into commands sent from the arduino to the motor. The current method for reading the vent information is that while reading the information on the page, the algorithm looks for a ‘v’ to signify a vent, the next two numbers represent the number of the vent, and the character after that determines whether it is open, closed, or on automatic mode. We have also implemented buttons that update the information on the page.
Code snippet for reading the web page
Unfortunately, while we were working with the on campus wireless network we ran into some problems. It might have had to do with the fact in order to use the wireless network on campus you need to register the mac address online. It seems that the arduino does not have a mac address easily viewable by function or listed on the device. Thus, leaving us with a hard time testing functionality on campus.
Software Team
This week was focused on interconnecting the app component of the project with the hardware. After a group meeting, we decided the simplest and most efficient way to do this would be via the following protocol:
- All vent states are assembled into a temporary text file by the app.
- The format is: Unique_vent_idState
- In this example, the first vent ID is “Vent0” and the State is o (as depicted in the screenshot below)
- States are either ‘o’ for open or ‘c’ for closed
- The text file is then uploaded to a central server location.
- Each vent then retrieves the file and updates its state according to the text file every 10 seconds.
- Note: This is an energy inefficient method because each vent must, in the worst case, search through all N vents in the list before it finds its own ID. This algorithm is for the prototype only.
As of this update, the app is able to successfully create a text file representing all the vents and their states. There is also functionality to upload the file via an HTTP request, however since this has not been tested, it is assumed to be in a non-functional state. It is also important to note that the current version of the app has buttons to export and upload the text file (visible on the “Vent Control” screen). In later versions, once everything has been thoroughly tested, both the export and upload functionality will happen automatically and in the background.
Project Update 7
Hardware Team
For our final week, we focused on finishing integrating the app and the hardware, allowing them to work as a cohesive unit. We managed to get the vent to react with sending/reading e-mails, or by posting a text file and reading it with HTTP post. For the text that contains information on the vents, we had to decide on a system of separating the data. The system we settled on is in the format of "#X&Y@Z" where X is the number of the vent, Y is the state of the vent (open/closed/automatic), and Z is the name of the vent. In order to save power, our design only checks for vent information updates once every couple minutes. Unfortunately, our servo doesn't appear to be strong enough to move the vent slider on its own, so it appears we may either need a stronger servo motor or a vent whose slider is easier to move for our final design.
E-mail containing vent state information
Layout of Vent Design
Software Team
For our final version of the app. We had two primary goals: establish communication between the app and the vent, and add temperature-sensitive features to the project as well. The former was initially implemented utilizing email. When the user would change the state of or add a vent, an email was sent automatically from the app. Each vent would then check for new emails every five seconds and update their states accordingly.
After implementing this, our team decided that, due to the high latency and power consumption associated with sending emails, we would instead utilize HTTP post and get requests to allow our software and hardware to communicate. This is both lower latency and has lower power consumption than sending emails. In addition, HTTP post/get requests allowed us to have the vent send as well as receive data from the app. This allowed our team to install temperature sensors on the vent and send its data back to the app in real time.
With this two-way line of communication established, we were able to give the app smart-control of the vents it was connected to. In previous iterations of the app, the user would always have to manually open or close the vent. They had no way of automating the process and now way to acquire temperature readings from the app. The final iteration of the app displays the ambient temperature around each connected vent. It also allows the user to set a desired temperature. The vent will then automatically open or close depending on the ambient temperature and which mode the A/C unit is on (heating or cooling). For example, if the A/C unit is set to cool, the vent is set to 70 degrees and the ambient temperature is 75 degrees, then the vent will remain open until the ambient temperature is less than or equal to 70-1 = 69 degrees, at which point the vent will automatically shut. The vent will automatically open again if the temperature reaches 70+1 = 71 degrees. The +- 1 degree fluctuation avoids the vent being open and shut too frequently and thus reduces the overall power consumption of the vent. In a release version of the app, a settings screen would allow the user to set the range of fluctuation required to trigger the vent to switch states. The greater the range of fluctuation, the greater the long term energy efficiency and thus battery life of the vent.
