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.