I’ve done a few rounds of 100 Days of Code in the past, but never really made it past 2 weeks. Part of the reason for that failure is the weekend portion - I don’t like to computer on the weekend since I computer very hard during the week.
I decided it would be a really good use of my time to work on my Indoor Air Quality platform as a part of my attempt at 100 Days of Code. It’s the next step for me in my career, so I need a way to force my effort.
There are two parts to making my IAQ platform successful, the sensors themselves, and the backend system.
- Day 1 - Getting the infrastructure setup for development
- Day 2 - Getting basic data out of Temp/Hum sensor, figuring out scope for others
- Day 3 - Publish data to InfluxDB
First thing I worked on today was trying to iron out an i2c issue I noticed last night where the i2c bus stops responding. This was rather annoying and I’m curious if it’s directly related to hitting the i2c bus too quickly. For now, I’ve disconnected the Pi from power, pulled the i2c pins, then reconnected everything. After booting back up, everything seemed to be working properly. We’ll see if it sticks.
Today I started thinking through how the authentication and backend would work for provisioning a new IAQ-ONE Sensor. I plant to store authentication, sensor, and customer details in CouchDB. There will be a Flask API that glues together all of the services in the IAQ-ONE Platform. In the end, we will need an admin interface and a customer facing interface. There will be a web based interface and native iOS/Android apps for customers to use. I most likely will be hiring out the development of the iOS/Android apps, as I just have no interest in learning an entirely new development stack. I will slap together an ugly web interface for now, but long term I’ll probably hire a web designer as well.
NOTE: my “test platform” is just my NAS for now. I’m a little short on hardware that’s up and running at the moment, until I get my network/server rack moved and re-patched.
I got CouchDB up and running today on my test platform.
https everywhere. First up, I wanted to start mocking together the Flask API and get it running on the test platform. I got the docker container roughed in and the initial part of
app.py written up to import all of the things I’ll need, as well as loading in secrets from
I’ll spend the next 24 hours thinking about how I want to structure the API routes as well as how I want to handle authentication.
I noticed that the
publisher container has been crashing every so often. Unfortunately I didn’t have any logging in place and up until now was just running the container in detached mode. So I started up a
screen session and am running the container in interactive mode, hoping that it’ll point me to where I need to do some error handling or solve the problem causing it to crash.
I let that run for a while and found an error that was pointing to the function not receiving any data. I’m not sure exactly where the data is missing, but I’m guessing it’s more likely that the function isn’t seeing any data or having a hard time reading from file. I went ahead and put a
pass on the exception handler, to see if it continues to work and pass good data.
I’ll keep an eye on this and see how it goes. I probably should look into a log collection mechanism to make it easy for me to troubleshoot some of these issues, will ponder.