2026-02-07
See https://paul.walko.org/blog/2026_01_25-meshtastic-fosdem-part1.html for background about this effort. This idea was initially thought of by Crofton, but it wasn’t until we came across Meshtastic as a good method of transporting metrics that this became a reality.
Here’s a good overview of what’s considered “good” Air Quality:
This was a very good test run of the CO2 stack. To no surprise the CO2 levels were quite high, hitting 4000 ppm around 8pm.
Here’s the detailed readings for each node:
See https://fosdem.org/2026/schedule/roomtracks/ for the actual room location for each of the above rooms.
At first glance here, the CRA devroom makes everything else look
insignificant. This is partially true, but excluding that shows that
most other rooms were above 2000 ppm nearly the whole day
This isn’t particularly surprising given just how many people attend FOSDEM each year, and hopefully it will encourage devroom managers to think about air circulation in future years. A very rough guideline is to start opening windows or doors when the ppm gets above 2000. I believe the CRA devroom windows weren’t easily openable, plus the hallway was rather noisy so opening the doors wasn’t practical.
The scd41 sensors measures temperature & humidity in addition to
CO2:
You can see a rough correlation between temperature and CO2. I believe the sensor at the Grafana stand was placed on top of a 3d printer, hence the high temps. The CRA sensor may have also been placed on top of a radiator (?), which affects the sensor in weird ways.
By this point I was tired of organizing distribution of nodes so we
had much fewer rooms to monitor than Day 1, but there are still some
interesting results:
The SDR devroom topped out at about 3000 ppm in the morning, but unfortunately the sensor was not present in the room for the afternoon. The room reportedly got more packed as the day went on, so this likely went at least to 4000 ppm if not higher.
This stack consists of MQTT, python poller, postgres, and Grafana.
Initially I was using telegraf to poll mqtt, but this didn’t have very good integration with the meshtastic protobufs meaning I was forced to use the JSON output option when decoding packets. This also meant I had to use esp32, as the nrf52 chips don’t have enough capacity for the JSON decoder library. This is a issue if you are relying on battery power for the MQTT uplink as esp32 uses much more power than the nrf52 chip. Thankfully we did have a reliable power uplink (huge thanks to the gnuradio stand).
Storing and visualizing the data was pretty straightfoward with postgres as the database and Grafana for all the visuals.
By far, the biggest hurdle was distribution of the monitoring nodes. FOSDEM staff did not allow us to place nodes without someone (such as devroom managers) watching over them at all times, otherwise we would’ve liked to place them Friday evening before the conference started. Once sessions got going, nodes proved to be very difficult to get into rooms.
I am hoping that by next year there is a low cost commercial alternative that FOSDEM staff can trust, since a large part of them being against this year’s nodes was that it was DIY and they have no knowledge of how hacked together the nodes were. (Note that we only had 1 out of 20 nodes stop working for some random reason).