Measuring air quality in my home (part 2)

April 7th, 2017

Part 1 gave some context around why I got a Dylos DC1100 PRO air monitor. In short: China.

My wife and I are now back in North California and the air is much better. We live about 100 feet from a major road though, and I started wondering about the impact of morning and evening commutes on air quality.

So I brought my old Dylos back to active duty.

The old-school two-line display is perfect for a quick live read, but not so great for accessing historical data. Thankfully, this model comes with a serial port, over which it sends one measurement per minute or hour. Few computers have built-in serial ports these days, but Serial-to-USB adapters are easy to find and work well. Just make sure to buy one that comes with drivers for your favorite OS. I bought a Plugable a few years back that offers drivers for Windows, OS X, and Linux. (Rant: The missing g in Plugable irks me, just like Cristaline water used to back in France.)

Dylos offers ready-made software for getting data out of the serial port and plotting graphs. This software only runs on Windows, and the output can’t easily be embedded in a webpage, so I decided to roll my own.


It’s a toy project, but let’s try to build something decent anyway. We want:

Running everything on a single computer at home doesn’t meet the first two requirements. So we need a server somewhere. I already had a $5/mo VPS on Digital Ocean, so I went with that. It’s cheap but still easily beats my home internet connection in latency, throughput and uptime.

This brings us to a simple architecture:

  1. The Dylos transmits a live measurement to a home computer via serial.
  2. The home computer transmits this measurement to a server.
  3. The server inserts this measurement into a database.
  4. Some JS in a webpage fetches measurements from the server and displays them in a human-friendly manner.

There’s one issue though. If home internet goes down, or the server goes down, then the home computer cannot transmit live measurements anymore and loses data. This leads us to split step 2 above into two:

We use a persistent queue (instead of purely in-memory) to avoid losing queued measurements in case of a loss of power.

That’s it! Comcast can bring internet down for an hour, or the server can go offline for a day—in both cases there won’t be any data loss. We will lose data only if:

I don’t care enough about this data to implement any of these solutions, but it’s good to know they are available.

Tech stack

Off-the-shelf monitoring solutions exist (e.g. Sensu), but it seemed fun to write my own code for communicating over serial and a shared queue. :)

I picked Redis for the queue:

And Rust for the glue code:

On the other hand, I had very little interest in the DB and graph rendering part, so I went with InfluxDB and Grafana and was done in about 5 minutes.

Since InfluxDB offers an HTTP API, measurements can be sent straight to it. But Dylos measurements need to be converted from particle count per cubic foot to a more human-readable AQI (Air Quality Index, see Part 1). The home computer can do this conversion at the source, but that’s generally a bad architecture decision. Ideally, devices should contain as little code as possible, and send raw data only, with any further processing left to the servers. Most reasons for that are moot for this toy project, but apply to many real-world cases:

So I wrote a tiny HTTP server that receives raw measurements, adds a field with the computed AQI, and writes the whole thing to InfluxDB. This also makes it easier to swap InfluxDB with another DB later.

That’s it! It was a fun week-end project. The code is on GitHub, and the dashboard is live here.

Turns out cooking is much worse than commuting.