Team Status Report for 04/29/2023
At the moment, our biggest risk is the uncertainties we will face when moving our project to the demo environment. We have already tested the ESP on CMU devices and gotten the hotspot for the smart plugs to mitigate any Wifi-related risks. Our biggest risk is likely the infrared motion sensors, as we designed and planned our setup around a doorway, but we will have to use a tent’s entrance to demonstrate its functionality. Once the tent arrives, we will be able to get a better sense of how we can modify our design for the demo, and work on mitigating issues on demo day.
As a result, this will lead to some design changes, although we are not 100% sure what they are until the tent arrives. We may need to increase the size of the tent entrance as the motion sensors need at least 1 feet of distance from the person to operate.
Throughout the past week Rong continued verifying our web application performance. After taking a while to properly learn the Python Locust testing library, we started to write proper load testing on how much stress our deployed website can handle. It appears to be consistent with our predicted user-case requirements which we had defined at the beginning of the semester of 50 users hitting the server endpoint at a time. We can see from our load test charts that response time starts increasing as the number of requests increase, and the number of failures start to increase as we start to hit 50 user requests per second.
Team Status Report for 04/22/2023
Currently, our biggest risk is that we are a little behind schedule due to some roadblocks with the sensors. Luckily, our project is functional, and the work we have ahead of us is mostly detailed testing and optimization. As a result, we are hoping we can finish all of our goals in time, and in the worst case scenario that we hit another roadblock, we will at least have a functional project to present.
We had another small design change to the DynamoDB table. Instead of using the HeaterID as the primary key, we will use the timestamp as the primary key, as it allows the Python script to sort and search through the DB more efficiently and prevents any race conditions between adding to and removing items from the DB.
After several visits to T-mobile, troubleshooting with the refurbished Personal Hotspot machine (which we ordered from Amazon through the order placement form), and adjusting our data services plan, the hotspot is able stream 5G LTE in the Wiegand gym area to properly connect the Shelly Plugs to the internet so that they can serve as functioned for our project. It is important to mention that this hotspot is simply a means of demonstrating our project on a campus situation. Our project was initially designed with a user case scenario in which customers have our system connect to a home wifi in an off campus setting.
Given the lackluster quality of our existing block diagrams, Rong also spent significant time recreating them with proper detail indicating the name of the specific resource, descriptions demonstrating relationships, and aesthetic features that allow our diagrams to be visually appealing and easily digestable. This should help clear up existing confusions of how our AWS EC2 instances connect with our physical hardware.
Testing is also a critical part of ensuring a product’s success. On top of the unit testing we have done with our independent pieces of our project throughout, it is important that we conduct user testing and take in constructive feedback. We have started to schedule meetings with some of our off campus peers to test out our product experience.
Team Status Report for 04/08/2023
This week, Rong spent significant time experimenting and testing out potential Wifi sources for our Shelly Smart Plug to demo our project circuitry on campus. Although the intended user-case purpose of our space heater system is for customers living within houses with basic Wifi setup, for the purpose of our ECE demo, we will require a more unconventional wifi set up.
To properly set up the Shelly Smart Plug to respond to API calls (which is how we will regulate the temperature of a personal space area with our space heaters), both the Shelly Smart Plug and a phone need to be connected to the same Wifi. I attempted to use each of our iPhone’s hot spot as a source but the bandwidth is not sufficient and disconnects before the Shelly Smart Plug is registered to respond to API calls. I then attempted to use CMU wifi options. I was unable to use CMU-Guest and CMU-Secure because both of these wifi’s require a second authentication or verification portal/layer that the Shelly Smart Plug interface is unable to access. Therefore, it made more sense for me to connect to CMU-Device by registering the MAC-Address of my Shelly Smart Plug. This is sufficient enough to allow us to register the Shelly Smart Plug to respond to API calls. However it is not stable enough and experiences brief moments of inconsistent responses.
Therefore, after reconsidering our budget after last week’s financial review, Jay and Rong went to Squirrel Hill to visit AT&T and T-mobile. We discussed Hotspot options and simple subscription plans. We then placed an order request form for an Hotspot router. We are currently waiting on that object’s arrival for further work on this area.
Currently, our biggest risk is the temperature sensor, which stopped working. In order to address this issue, Eric ordered a breadboard power supply module to supply constant power to the breadboard. This ensures the issue is not from the low voltage of the ESP. To further address this risk, Eric will use a voltmeter on campus to identify exactly which part of the circuit is not working, and ask for additional help if necessary.
Team Status Report for 04/01/2023
This week, there was a design change to the motion sensor setup. The current issue is when people are moving inside and outside of the room within ~6ft of the sensors, the sensors will continuously sense them. This is an issue because this will block their functionality in sensing people moving through the door, as the occupancy requires a short period of no movement sensed to trigger. To mitigate this risk, we plan to use aluminum foil, which blocks infrared signals, to limit the sensors’ “vision.” To further mitigate against the edge case issue where people are moving near the wall of the door, we will eventually try extending the sensors to the top of the door so that the sensors will only sense around 1 feet of the door.
Our biggest risk currently is the unforeseen failure of our motion sensors. Eric will continue to work on this tomorrow, but to prevent further delays, we are hoping to get some help with the issue if it continues, as we have tried everything we could think of to try to solve the problem.
Additionally, after reviewing our remaining budget constraints with our Teaching Assistant Will, we have double checked that we indeed have ~$270 left for our project order supplies. During the group check in, we were made aware by Professor Fedder that we should prepare for internet outage scenarios, given our project’s heavy reliance on the internet. I am currently in the process of running through documentation and stress testing the internet/wireless capabilities of the Shelly Smart Plug within the context of our project. After a full analysis, I will determine if additional funds will be required to purchase a portable hot-spot internet router. We are also facing some roadblocks with our circuitry for our hardware. We are experimenting with our other breadboards to determine if there is an urgent need to purchase additional sensors or cables given our situation. Besides this, additional thought has been placed into other possible orders that may supplement the user-experience for our project.
Team Status Report for 03/25/2023
One risk we realized as we are building our system is that the user will have to set up their Smart Plug by registering it with their home Wifi System. Since the Smart Plug is a relatively new technology, the process for doing this is not as intuitive as we would like to achieve our goal of making our project very easy to set up. For reference, it took us about half an hour to get the Smart Plug registered with our home Wifi, even though we are relatively experienced in using contemporary technology. We are worried that some of our users may find the process of setting up their Smart Plug frustrating and time consuming, especially since they would have other devices to set up. We have 2 strategies in order to mitigate this risk. First of all, we can write in depth instructions on how to set up the Smart Plugs based on our experience. Secondly, we can set up a wifi hotspot that Smart Plugs are already connected to. This also simplifies the process of connecting the ESP32, temperature sensor and motion sensors, as they would be already connected to the wifi hotspot. We are considering this design addition for our project; while this would increase the cost of our system, it could improve user friendliness. We are currently looking into this possible design change, Rong is responsible for finding the cheapest viable option for the wifi hotspot. This is relevant for our project, since part of our target audience is lower income users.
Team Status Report for 03/18/2023
After further developments this week, we decided on a design change regarding the web application portion of our project. Beforehand, we were planning on only using the web application to be the middleman between the hardware portion (ESP32, temperature sensors, motion sensors, and smart switches). However, we found that there are some complications if we include all the algorithm within the web app. First of all, we need to run a while true loop that checks the sensor data updated onto DynamoDB, checks the data with user’s settings, and in turn powers the heaters on or off using the shelly smart plugs. We were originally planning to do this within the web application, however, we thought that it was very inefficient to do so since the web application is already handling the users. Secondly, we found that we need two dynamoDB tables. Since the ESP32 uses a different API call than python does, we need one table for the ESP32, and one table for the web application. In order to make the design scheme more efficient, we decided to make another script that will run on EC2. This script will connect the two tables mentioned above. It will periodically check the sensors dynamoDB table, compare it to user’s settings, and make the according shelly API calls. It will also update the values in the dynamoDB table for the web application so the users can see the updated values in our user interface. The script will also be responsible for checking the circuit limits, and creating the queue of heaters when the circuits reach their limits.
While there were no changes to the general design of the sensor system, we figured out some of the more detailed aspects to how the sensors communicate with our AWS Dynamo DB table. We can now include the certification, MTTQ policies, and message routing steps of sending a MTTQ message to AWS IOT endpoints in our design.
Team Status Report for 03/11/2023
This week, we had a change to the physical design of our occupancy counter. Originally, we were going to place the two motion sensors far apart on one large breadboard. However, as mentioned in the previous status report, we found this was not quite as reliable as our requirements needed, as we needed each sensor to consistently respond only when the person is either outside or inside of the room. We tried using two breadboards and long jumper wires to spread the sensors out more, which helped, but was still not accurate enough, especially if we walked quickly. Through a meeting with Professor Fedder and Will, we came up with a new design where we would connect the sensors to long ribbon cables, then tape them on each side of the door frame around torso height. We will test this next week, as the ribbon cables just arrived.
One small risk is that our occupancy counter is still not reliable after our design change. However, to mitigate this, we tested our design by manually holding the sensors and breadboard where we plan to place them and tested the performance. It was a massive improvement (near-perfect detection under our conditions of only one adult-height person walking through at once), so we are confident that it was a positive design change.
One of the risks that we found after further testing is that we are only connecting to the Shelly smart remote plugs via local networks. Since the website will be published on the AWS EC2 instance, we are still working on making that connection through the internet as the EC2 will be running the algorithm for turning the heater on or off. Currently, we are still researching different methods of communication that shelly supports, and we will attempt to access shelly smart remote plugs through another network. If we don’t find a way to do so, one of the contingency plans will be uploading the power status onto AWS and using ESP32 to turn the remote plugs on or off. Since the ESP32 will most likely be on the same network as the shelly smart remote plug, it will be very easy to implement.
Team Status Report for 02/25/2023
This week, we are on schedule. We had to delay fully building the motion sensors, but we moved up our integration planning to compensate. Our tasks for this week have only had minor problems come up that we were able to solve. Our biggest upcoming risk is still integration of devices with the Web Application, which we will soon be implementing and testing. To mitigate this risk, we have been planning how we will integrate such that our individual components are designed well for smooth integration. One other small risk is the reliability of our occupancy design, which we will mitigate by discussing our physical set up next week in our meeting.
Our strategy for teaming has not changed much. We have not hit a major setback in our design plans yet and everyone has been on schedule. We have done a good job of allocating both hardware and software tasks to Rong so that he can support Jay and Eric and everyone has a fair workload.
Team Status Report for 02/18/2023
This week, we had to make a change to our plans after we realized the Raspberry Pi Zero we wanted to use was out of stock. This caused a risk as we did not want to delay ordering our supplies to stay on schedule, but we had to make sure we ordered the right devices. We were able to mitigate this risk and ensure our project would still work by talking to Will during lab and checking to make sure all of our devices were compatible with our new microcontroller, the ESP32. Although some of our more detailed planning for programming the microcontrollers and communicating to our WebApp have changed, we were able to research and figure out how to accomplish these tasks using the ESP32.
This setback did not affect our schedule for developing the Web Application, but it did delay our device setup by a few days. We compensated by working on some of the Arduino code and scheduling a few extra hours next week to work on our project and get back on schedule.
Team Status Report for 02/11/2023
This week, we are on schedule for our project. We have researched the possible devices and are ready to order. In addition, we have a plan for how we will set up and integrate our devices with our Web Application.
Our biggest risk at the moment is not ordering the right devices, which may lead to wasted time trying to make them compatible or having to reorder completely. In order to mitigate this risk, we spent many hours researching the specs of each device and planning some of the details (eg. how we plan to code our HTML communication with our devices) to make sure we get the ideal resources, which we will go into more detail in our personal status reports.
Our original plan was to use active infrared detectors that will constantly detect if a person is in the room. However, through our searching, we realized these sensors are rare for commercial use and lack direct compatibility with our own software. In addition, we thought using an active infrared sensor would be energy inefficient, which goes against one of our main goals to reduce energy consumption. Our new plan is to use two passive infrared motion sensors and place them at the door, which will be able to count the occupancy of a room, thus determining whether someone is in the room or not. This will actually cost less, because the infrared motion sensors are cheaper, and will allow us to use a sensor that has better compatibility with Raspberry Pi. Additionally, through our research, we decided to use a Raspberry Pi for the motion sensors because we need a better processing speed to differentiate between someone entering and leaving the room. However, we will use Arduinos for the temperature sensors, which are cheaper and simpler, as the constraints are less strict. Finally, our plan to buy smart plugs that can directly connect to Wifi has stayed the same.
Our project includes considerations for safety and environmental benefits. Not only are we preventing overloaded circuits, which could cause electrical fires, but our temperature sensor will sense if there is an abnormally high temperature and alert the user for a possible fire. This will be faster than a smoke detector because one danger of space heaters is fires, so the temperature sensor will be near the space heater. Our project has a primary goal of the reduction of energy consumption for saving our user’s money, but also to reduce the environmental strain our high energy consumption causes.