Home Sensor Project Pt. 2

I began writing about this project in Part 1 to lay out a general overview of my motivations and goals, and want to come back again to elaborate and update on some of the progress and pivots I've made.

Why Am I Building This?

Seriously, can you tell me? 😂 Setting out this was an idea to fit within the curriculum of Terra.do's Climate Tech Stack cohort, to take the ideas we were using in IoT and data modeling, and make a final project. To that I would claim Success! So then why continue building?

On one hand I am genuinely curious about the changing environmental factors within my house. Might be partially that as a new and first time home owner, it's another tool to help me learn on the go and adjust habits towards more efficiency, or at least find out if the air in here is hella-stanky (in the utmost scientific sense).

Beyond that I'm motivated to build build build, and this is an excellent project to flex full stack muscles and tinker in several areas beyond the front end where I am familiar. I've touched on DB operations, RPC call crafting, and lately building out a FastAPI backend to run scheduled tasks and send & receive SMS interactions. More on that later.

Product Design

Or more aptly, "Fool's Product Design". As I progress in basic feature development as the sole User of this project, the feedback loop is very tight. Some features I've been working on have become clearly lower priority, or leading to a less optimized UX and need to be abandoned. By taking a ramshackle approach to developing this project, I'm making a lot of the time-old mistakes of product development and project management over again.

I think this is a good thing. In the professional life of a developer living and building through real product cycles, you are taking care to prioritize the right things, vet ideas into valuable designs, and stay on task building out features to a coherent, maintainable, and well tested resting state.

But a personal project? Pffft! Just let 'er rip! Best Practices be damned!

(Hmmm . .. this should end up being another post so I don't get too off topic)

OK back to the point . . . This project is more than anything an exercise in Product Development. I'm haphazardly iterating towards concept proofing, whittling out a viable idea from the stacks at my disposal, and using my desires as a user to see if I'm heading in the right direction or not. It's not a classical model of product development, and I'm not going about it in the most disciplined manner, but again, that's a great way to remember the high value of the processes that we utilize in real enterprise environments.

Feature Pivot

Here's one example of a detour I've been taking this week in the interest of making this UX a bit better.

My original UI remains, it's just a bone-simple input interface to simply log any activity I'm starting that I want to see the air-quality impact of. Great, I like the ease of use and pro-active affordance.

But this user expectation is optimistic. I can't count on myself to be so proactive, and logging events and activities into my tracker is usually an after thought. I began building up some flexibility, like interfaces to update times and durations for logged activities, but I can do better.

I'm already taking constant samples of the air, so rather than anticipate an activity's effect on air, I'd do better to enable a reaction to a measured change in the environment.

Automated Sampling and Alert Dispatch

To create this reactive UX, I am adding another element to the system design and playing with a FastAPI backend service in Python. There are a lot of details for me to work out, particularly in properly calculating normal trends and what constitutes a non-negligeable divergence. But the core of the service was relatively easy to build out in an afternoon (Thanks GPT 🥸).

I set up an endpoint that retrieves sensor readings from the last 10 minutes, as well as a function that analyzes the fluctuations against an average (so far I'm just looking at CO2 levels in the house).

Then I've added a scheduler that grabs the latest data, runs it through the analyzer, and classifies the current CO2 levels, for example if they are rising or falling or dangerously high, etc. I'm curious here what the ideal scheduler frequency will be to make it reactive enough to capture an event in the relevant time span, without being a ridiculous rate or high cost.

Then the fun part: if the analysis determines a change that might indicate any note worthy events or activities that are affecting the environment, a Twilio integration sends me an SMS message, alerting me to the kind of change that is taking place at this very moment!

One step past that, I've also set up a POST route for a Twilio webhook so that I can simply reply to the SMS with the event taking place, which then routes back to the BE service to make a row insertion in my Activities DB.

Revise and Refine

Getting this up and running was great fun. I think it will be a great UX improvement and lead to better quality logs and more insights about activities and indoor air quality, the ultimate purpose of this project. It definitely opens up an entire host of new engineering objectives, and will lead to a lot more UX problems in the details.

I'm excited to address them, to refine it to be the best UX and quality code that I can make it. But it's clear that right now I'm going for breadth and looking for opportunities to touch more across a growing stack than dive deeply into single features.

As I get deeper in the weeds on specific technical problems, I might write and share some fun solutions I come across, but for now I'm enjoying a Plinko-like progression in developing this project, and comparing it to the guardrails and limitations of a professional development environment. There's plenty to appreciate in both approaches.