CONTENT
During the times of lockdown and own lack of will to go outside, I have noticed the indoors air to go a bit stale at times. But how stale exactly?
One can now buy some relatively inexpensive sensors to measure the concentration of CO2 in indoors air, and after acquiring one, a simple data-logger has been slapped together out of some mostly leftover parts from other unfinished projects. Yay!
This one has WiFi and a microSD card for storing logged data!
Last updated sometime in 2023/07, initially built in 2022/02
Basic Hardware
The basic hardware setup consists of an ESP8266 microcontroller module, an SCD40 CO2 concentration sensor, and an MS5637 pressure sensor.
All these sensors are connected to a shared I²C bus, along with a SSD1306-based OLED display for showing the currently measured values.
Additionally, a socket for a micro SD card has been added, and a USB-to-serial bridge for ease of programming/development.
A red/green LED was originally meant to be populated, however, it turned out that the IO pins originally meant to drive it were necessary for other (basic) functions.
Circut Board
The circuit board and is some 5x5 cm², with several “designed-in” jumper-wires. It has been designed with Eagle CAD, its copper layer image has been then exported to an image, and this image has then been converted to a file digestible by my SLA 3D printer using a modified version of UVtools. The photosensitized PCB stock was then exposed using the 3D printer, and subsequently developed and etched.
Eventually, a larger number than designed of jumper wires was necessary, since yours truly failed to redraw the schematic of the usual ESP8266 development boards, and instead wired several things quite wrong. Several connections went to incorrect places, which ended up killing several of the USB-to-serial chips before he really found out why. This should explain the unsightly rats-nest of thinner wires all across the board.
Software
Similarly to WiProg, the software is built on top of some silly Arduinous libraries.
Unlike WiProg, however, it hasn’t been touched for over a year, and the software is currently in a rather bad shape. Thus, it will not be published until it has been cleaned up.
A move to some more sensible platform is being considered; NodeMCU seems to be much nicer.
The software consists of a simple web server; an NTP client, for keeping track of current time; a timer, for periodically capturing data; and an extension of the web server, letting one access current readings via an extremely simple API.
The web server is serving files directly from the microSD card, which means one can easily download the data files too, “for free”.
The SD card also contains some configuration files for storing the WiFi credentials. I have chosen to do it this way, as it’s much easier to modify some microSD card’s contents than to figure out how’d one talk to the thing over serial (or something), and change the setup that way. Keeping this in mind, the device automatically creates its required configuration file placeholders, so one should still be able to configure it - even if they have as bad a memory as I do!
There is also a simple webby interface showing the previously captured data: (You can see when I’ve opened my window!)
The data is then appended onto a daily CSV file. This makes the data easy fairly easy to interpret, and easy to query day by day without needing to download a massive continuously-logged-into file as in previous versions.
The pressure sensor was originally intended to provide some pressure reference data for correcting the SCD40’s output. This was however never attempted so far, and the data from both sensors is currently logged “as is” for future data-fudging.
Currently, I only download the entire data file about once a month, and for casual value checking, I use the simple API, showing values like this:
API description
The API has changed a good bit in 0.3.x firmware version:
GET /api/v2/data
Returns current/most recent data samples.
{
"fwver":"0.3.0", //firmware version
"time":1701148914, //unix timestamp
"sensors":[ // sensor values
{"sensor":"SCD40", //CO₂ sensor
"api":"0.1.0",
"co2ppm":1685, //Air CO₂ PPM (Pretty bad here!)
"rhum":39.60571289, //Relative humidity, %RH
"temp":27.07641602 //Temperature, °C
},
{"sensor":"MS5637", //Air pressure sensor
"api":"0.1.0",
"temp":28.28000069, //Temperature, °C
"pres":954.1900024 //"raw" pressure, hPa
}
// ... add more sensors here
]
}
GET /api/v2/data-list
Returns a directory listing of data files for download.
Currently, the same effect can be got by querying /data
instead.
{
"directory": "data",
"files": [
"data/2023-07-29.csv",
"data/2023-07-30.csv",
"data/2023-07-31.csv",
//...
]}
Unfinished Bits
- More sensible data logging.
- The logged data is now split into individual daily CSV files.
Currently, all the logged data is appended at the end of the one single data file.This data file can get rather large - a year in, it has grown over 250MB in size!It would make sense to split the log into separate daily logs.
- Better web server.
- Currently, the web server is synchronous, meaning that only one client/download can happen at a time.
- This is not fun, especially when one wants to download the entire massive log file.
- Make the web UI more responsive in general
- It really wasn’t too fun to pull hundreds of megs of data
- Cache all the things browser-side to avoid pulling it from the device
- But only do this for ‘complete’ data from previous days
- => This should probably be handled with local storage, not browser cache.
- Better air temperature sensing.
- Currently, the sensors are soldered on-board, and typically read several degrees too high compared to the “real” room temperature.
- It would make sense to extend them further away from the warm-ish circuits.
- A case.
- There isn’t one yet.
- The thing currently sits on a shelf somewhere, quietly doing its thing for over a year now.
- 3D print one!
- Actually write some releasable firmware
- Then publish it
- The current version is incredibly bad.
Nice-to-haves for V2
- A portable version would be nice.
- Measure stuff in other places too!
- This would necessitate a “real” real-time-clock to keep time even when off-line.
- One would need to come up with some low-power modes of operation too…
- Additional sensors.
- Air particulate sensors
- More sensors