Posted on

Angela’s Status Report 4/16

This week, I was in direct contact with someone who tested positive, so I was not able to make it to class, as well as still feeling extremely sick. However, I was able to get frontend work done. The main feature I was able to get working was the zoom on the map. This includes being able to zoom out enough to see different sections in the full map as well as zoom in to individual tables.

Next week, I hope to finish all features of the frontend as well as helping out with hardware testing and load/stress testing. The features would include having different tabs for different sections and refining the proportions so that the website would look as planned on all phones.

Right now, I want the web app displayed on a desktop/laptop to look like this:

while the mobile app looks the same. Currently, I’m using responsive web design (responding to different screen sizes/media) in order to accomplish this.

Posted on

Jake’s Status Report 4/16

This week I focused on completing a few of the remaining things from my schedule. The first of these was to convert the EC2 database to run MySQL. For the demo we were just running sqlLite as a proof of concept but to ensure we are optimizing for our design requirements a change to MySQL was preferred. I also worked on updating some of Angela’s old front end html and django code and implemented that on the ec2 so that it runs on our website. I think this upcoming week I am going to create seperate versions of both this front end and our esp8266 code so that we can have the compartmentalized demos that we discussed with Tamal this week. The webapp code for some of the demos will be able to display info on exact latency and capacity.

I additionally developed two of the tests/validations our team initially had planned to do. The first of these is tracking the aws -> website capacity and loading times. I’m utilizing GTMmetrix which is a pretty standard speed test tool that performs multiple tests across various browsers, locations, and connections. I have yet to run this as Angela is finishing up her finalized front end which is the element of our pipeline this seeks to stress test. The Second of these tests is a fleet of node mcu’s that all are publishing json packets. This stress tests the device node -> aws capacity. This is more of a verification/validation than a test as there isn’t a solid metric for this other than delay and packet loss.

Last week I mentioned that we needed to  convert all devices to access CMU-SECURE through a wifi access point as CMU-DEVICE was blocking certain things we were trying to do with NTP. Now that we have confirmed our final demo location as Wiegland Gym we have concluded an ethernet based wifi access point is not viable as there isn’t accessible ethernet access for our team. I spent a lot of time researching wifi repeaters as a circumnavigation and we found several possible options that would work for our final demo. We are going to test one of these options, using a Samsung Phone as a wifi repeater this upcoming week. This is probably our greatest issue for risk mitigation at the moment. Our initial demo proved that we can still have a working project without this solution however to realize the full vision of our project this will need to be solved.

In terms of our updated schedule I am right on pace.

Posted on

Team Status Report 4/10

This week was super busy in terms of preparing for demos, because of this we are going to break down progress and issues by platform

AWS IoT – Originally our design had our incoming data going to AWS IoT’s internal time series data base and then the platform’s rules engine would utilize a Lambda Rule to pass this along to a MySQL DB hosted by Amazon RDS. Django would access this directly. We fully implemented this but kept running into errors integrating this pipeline with Django’s models. Django models are intended to be a wrapper that sits over SQL and keeps the programmer completely removed from it, but because we were writing a bunch of SQL by hand as part of the Lambda function Django really didn’t like that. This left us with two options either abandon Django models and go with straight py sql or integrate the DB on the EC2. Because as a team we wanted to go with Django b/c of the abilities of models we made the design pivot to move towards a database with the django MVC on the EC2. This simplified the AWS IoT portion of our project in that we completely cut out the Amazon RDS MySQL server and lambda function and we replaced them with an AWS IoT rule that sent data within a https to a subdomain of our hosted website.

EC2/Django – So this clearly had trickle down effects within the EC2 Django deployment. For one we created a bunch of code that established Django models for tables with all their necessary features i.e. table_id, occupancy status, time of last update, etc.. We didn’t just create the templates as we also created a migration such that whenever the database is reinitialized  or the server reboots the database is pre-populated with instances of tables for all the devices we are currently supporting. In terms of data communication from AWS to Django we talked briefly about how AWS IoT was sending a post request to a specific url, this is specifically a json dictionary that contains all data transfered off the esp8266 as well as a key to match for security so nobody can spoof send data.

Because of the change in overall design we performed some extensive load testing to ensure this could still meet our project requirements. We converted the domain to point to an elastic IP to help with load. For testing We flooded the EC2 with 80 db updates and 100 get requests within a minute and it experienced no issues whatsoever so the change still meets our project requirements.

We additionally worked a bunch on the front end. We built out a basic html file to hold table information (id: status) and then tied this in with a javascript, jquery, and Ajax set of functions that would via a url automatically refresh occupancy data at a set interval of time. This tied into some backend code We wrote in Django that would query the database for all Table model instances, package these in a dictionary and send them off in json as a xml request response to the browser for our Demo. Although it had yet to be synced with the rest of the Django code on the EC2, We also developed a basic front end representations of tables and their occupancies.

hardware/esp8266 – We wrote a script to perform basic pir based occupancy detection for the demo. This consisted of two versions of detection. One that would connect to wifi only when detection had occurred as a preliminary power saving technique and one that would stay connected. This will slot into our final demo idea of having two detection algorithms running. One that will show purely how well we can detect occupancy and another that will show our in practice version designed around saving power through wifi use minimization strategies.  We ran into a new problem using CMU-DEVICE Wifi where we wern’t allowed to use NTP for any accurate time synchronization. In our demo testing we found that there isn’t a reliable delay between detection and when status updates reach our sql. Because of this as well as our desire to ensure we are operating our esp8266’s  during our desired running window, 8am-5pm, we wanted to use NTP for a variety of things on our nodes. Because of this we will be pivoting from CMU-DEVICE to using a wifi access point to connect to CMU-SECURE.

 

Posted on

Ryan’s Status Report for 4/10

These past two weeks, since I missed a weekly update last week, a lot of work was done. I first identified that our thermal sensor, which had been ordered earlier this semester, can only communicate between I2C and has a specific header that needs purchasing, as well as a logic level converter. I talked to Tamal and made a contingency plan of ordering a breakout cable and level converter needed, with the understanding that the thermal sensor will not be a part of our interim demo.

I then soldered male header rows onto both of the regulator boards and built the hardware for the interim demo. A completed picture of the hardware can be seen below!

The battery runs into a 3.7V to 5V boosting regulator (which doubles as a charging board). That 5V powers both the ESP8266 dev board (which powers the processor and wi-fi module) and the PIR sensor. During the demo, the PIR sensor was taped to the bottom of a table, however the idea is to eventually mount the entire system under a table so it is out of the user’s way. After further testing, I determined that we did not need the 5V to 3.3V buck regulator, since the dev board steps down voltage levels internally.

Finally, we completed our interim demo! I think that it went well overall, and we were able to take a reading from the PIR sensor and send it all the way to a mocked up version of the web app. My major next steps involve integrating the thermal sensor into the rest of the design both hardware- and software-wise, now that the parts have come in, and finally doing some battery testing and work on power saving to round out the end of the semester, and I am currently on schedule to finish that out.

Posted on

Jake’s Status Report for 4/10

This week was super busy in terms of preparing for demos. Due to Ryan’s illness and Angela being busy I had to do a lot more work than initially anticipated. Because of this I am going to break down all my progress and issues by platform

AWS IoT – Originally our design had our incoming data going to AWS IoT’s internal time series data base and then the platform’s rules engine would utilize a Lambda Rule to pass this along to a MySQL DB hosted by Amazon RDS. Django would access this directly. I fully implemented this but kept running into errors integrating this pipeline with Django’s models. Django models are intended to be a wrapper that sits over SQL and keeps the programmer completely removed from it, but because I was writing a bunch of SQL myself as part of the Lambda function Django really didn’t like that. This left me with two options either abandon Django models and go with straight py sql or integrate the DB on the EC2. Because as a team we wanted to go with Django b/c of the abilities of models I made the design pivot to move towards a database with the django MVC on the EC2. This simplified the AWS IoT portion of our project in that I completely cut out the Amazon RDS MySQL server and lambda function and I replaced them with an AWS IoT rule that sent data within a https post to a subdomain of our hosted website.

EC2/Django – So this clearly had trickle down effects within the EC2 Django deployment. For one I created a bunch of code that established Django models for tables with all their necessary features i.e. table_id, occupancy status, time of last update, etc.. I didn’t just create the templates as I also created a migration such that whenever the database is reinitialized  or the server boots up the database is prepopulated with instances of tables for all the devices we are currently supporting. In terms of data communication from AWS to django I talked briefly about how AWS IoT was sending a post request to a specific url, this is specifically a json dictionary that contains all data transfered off the esp8266 as well as a key to match for security so nobody can spoof send data.

Because of the change in overall design I performed some extensive load testing to ensure this could still meet our project requirements. I converted the domain to point not an the original server instance but rather an elastic IP to help with load. For testing I flooded the EC2 with 80 db updates and 100 get requests within a minute and it experienced no issues whatsoever so the change still meets our project requirements.

I additionally worked a bunch on the front end as nothing really existed for it yet. I built out a basic html file to hold table information (id: status) and then tied this in with a javascript, jquery, and Ajax set of functions that would via a url automatically refresh occupancy data at a set interval of time. This tied into some backend code I wrote in Django that would query the database for all Table model instances, package these in a dictionary and send them off in json as a xml request response to the browser.

hardware/esp8266 – Ryan hasn’t been able to do any programming on the esp8266 yet so I wrote a script to perform basic pir based occupancy detection for the demo. This consisted of two versions of detection. One that would connect to wifi only when detection had occurred as a preliminary power saving technique and one that would stay connected. This will slot into our final demo idea of having two detection algorithms running. One that will show purely how well we can detect occupancy and another that will show our in practice version designed around saving power through wifi use minimization strategies.  We ran into a new problem using CMU-DEVICE Wifi where we wern’t allowed to use NTP for any accurate time synchronization. In our demo testing we found that there isn’t a reliable delay between detection and when status updates reach our sql. Because of this as well as our desire to ensure we are operating our esp8266’s  during our desired running window, 8am-5pm, we wanted to use NTP for a variety of things on our nodes. Because of this we will be pivoting from CMU-DEVICE to using a wifi access point to connect to CMU-SECURE.

 

Posted on

Jake’s Status report 4/2

This week has been primarily focused on getting everything in order for the demo. I purchased the domain occupancymonkey.com. I started a new Ec2 as Angela was having difficulty and cloned our project there. The django development server is not an acceptable way to run our program as it doesn’t handle high loads /service restarts  so I pursued using apache2 to run our program via a wsgi mod. I successfully completed this and then using ip forwarding I tied this to our domain at occupancymonkey.com. From here I utilized ssl to allow for https inbound and outbound traffic. This serves two purposes one it will allow aws iot to send messages safely via https which will greatly simplify data matriculation. Secondly it will help keep data more secure following the ethics discussion realizations are team had.

We hit a slight schedule snag in that our esp8266s are no longer behaving with cmu-device. Whereas in the past we were able to connect to EC2 cmu-device is now refusing us the ability to use pub sub client. Our mitigation strategy that I’m working on before the demo is converting a raspberry pi to a router/wifi access point