CO2- bzw. Luftqualitäts-Ampel | Air-Quality-Station

[Michael_S]

Hallo zusammen,

nachfolgend möchte ich Euch eine Air-Quality-Station (vergleichbar mit einer CO2- bzw. Luftqualitäts-Ampel) als DIY-Projekt vorstellen.
Diese weist darauf hin, wann ein Raum gelüftet werden muss.

Gemessen werden CO2, VOC (vereinfacht: Gerüche), Temperatur, Feuchte, Luftdruck und Partikel (d.h. Feinstaub, Aersole, Sporen ect.) mittels CO2 Bricklet 2.0, Air Quality Bricklet und Particulate Matter Bricklet.
Das Gehäuse der Air-Quality-Station besteht aus MakerBeam-Profilen und 3 mm Plexiglas-Platten. Es ist vorn und hinten offen, damit der integrierte Lüfter das Gehäuse durchströmen kann. Die Durchströmungsrichtung ist dabei so gewählt, dass die Sensoren direkt mit der angesaugten Raumluft beaufschlagt und nicht durch die Abwärme der sonstigen Elektronik beeinflusst werden. Außerdem sind Grobstaubfilter integriert, die zumindest die Elektronik-Bauteile schützen, die keine Messaufgaben haben.

Den Aufbau habe ich zuvor mittels Google SketchUp in 3D geplant und konnte so die Abmessungen und die Anordnung der Bauteile optimieren.

Im Lüfter sind bereits einige LEDs integriert, die zusammen mit weiteren LEDs (Adafruit 1643 NeoPixel) die Ampelfunktion bilden (Ansteuerung über LED Strip Bricklet 2.0 und 5 V Versorgung mittels Spannungswandler Kemo #M015N). Der Lüfter hat bionisch optimierte Schaufeln (Noiseblocker B12X-PS) und ist daher mit gedrosselter Drehzahl (PWM mittels IO-4 Bricklet 2.0) praktisch nicht hörbar.

Bei einer Überschreitung der Grenzwerte für CO2 (1.000 bzw. 2.000 ppm), IAQ (100 bzw. 200) oder Feinstaub bzw. Aerosole (20 bzw. 40 µg/m³) schaltet die Ampel auf Gelb oder Rot und gibt kurze akustische Warnsignale aus (Piezo Speaker Bricklet 2.0 - siehe Video: IAQ-Station.avi). Die Messdaten werden auf einem LCD 128x64 Bricklet angezeigt. Nach Sonnenuntergang werden Ampel und die Displaybeleuchtung gedimmt und nachts abgeschaltet; es sei denn, man berührt das Display - dann erfolgt die Anzeige für weitere 30 Minuten.
Außerdem ist ein Empfänger für Außentemperatur- und Feuchte integriert (Outdoor Weather Bricklet + Temperatur/Luftfeuchte Sensor TH-6148). Auf Basis der Luftdruck-Entwicklung wird zudem eine kleine Wetterprognose eingeblendet.

Verarbeitet wird alles von einem Raspberry Pi 4B mit HAT Brick. Hierüber erfolgt auch die Stromversorgung mithilfe eines konventionellen 12 V Netzteils.
Die gemessene elektrische Leistungsaufnahme beträgt ca. 6 W.

Die Messwerte werden in einem 30 s Intervall erhoben und in einem Intervall von 5 Minuten auf der MicroSD-Karte des Raspberry Pi gespeichert. Eine Ausnahme bildet die Partikelmessung, hier wird nur im 10 Minuten Intervall gemessen und der Sensor zwischendurch deaktiviert, um die begrenzte Lebensdauer des Particulate Matter Bricklet besser auszunutzen.

Ausblick: Im nächsten Schritt sollen mithilfe der aufgezeichneten Messdaten die zeitlichen Verläufe der einzelnen Messgrößen auf weiteren Display-Tabs angezeigt werden, die per Wischen aufgerufen werden. Habt Ihr Tipps für die Programmierung der Anzeige von Grafen auf dem LCD 128x64 Bricklet in Python - ohne, dass jeder Pixel einzeln definiert werden muss?

Viele Grüße
Michael

Bilder:

 

bearbeitet May 29, 2021 at 19:12 von Michael_S

[rtrbt]

Moin Michael,

Das sieht echt gut aus :)

Bezüglich der Graphen kannst du dir die Funktionen set_gui_graph_configuration bzw. set_gui_graph_data ansehen. Damit solltest du die Daten deutlich einfacher anzeigen können, als wenn du mit write_pixels händisch zeichnest. Das GUI-Beispiel legt einen der Graphen an.

[Michael_S]

Hallo rtrbt,

besten Dank für den Hinweis! Hat gut geklappt mit den Graphen. Nun lassen sich die Aufzeichnungen der letzten 8 h, 24 h, 7 Tage sowie des letzten Monats und letzten Jahres für verschiedene Messgrößen wie CO2, IAQI, T_a, PM usw. aufrufen, siehe Bilder.
Zwischen einer Anzeige der einzelnen Messgrößen kann man mit der rechts/links Wischgeste wechseln, zu einem anderen Zeitintervall jeweils mit der oben/unten Wischgeste. So sind insg. 46 "Tabs" zustande gekommen, was den Code etwas aufbläht... Die Daten werden zwar immer nur bei Aufruf des jeweiligen "Tabs" aus einer Textdatei gelesen und entsprechend gemittelt bzw. skaliert; ich bin jedoch mal gespannt, ob der Raspberry Pi (4B 8 GB) das auch bei Vorliegen von Messwerten für ein ganzes Jahr noch flüssig schafft. Dann sind es 105.120 Werte bzw. Zeilen pro Messgröße, die verarbeitet werden müssen.

Einzig etwas unglücklich finde ich, dass die set_gui_graph_data offenbar nicht in Callbacks (z.B. cb_touch_gesture oder von Sensoren) eingebaut werden kann, da sonst immer ein IP-Connection-Error auftritt. Demnach ist ein regelmäßiges Update der Daten für die Graphen nur mit einer for / while -Schleife möglich, oder?

Beste Grüße
Michael

[photron]

On 6/5/2021 at 5:25 PM, Michael_S said:

Einzig etwas unglücklich finde ich, dass die set_gui_graph_data offenbar nicht in Callbacks (z.B. cb_touch_gesture oder von Sensoren) eingebaut werden kann, da sonst immer ein IP-Connection-Error auftritt.

Welcher Fehler tritt denn da auf? An sich ist das erlaubt.

[Michael_S]

Am 7.6.2021 um 13:31 schrieb photron:

Welcher Fehler tritt denn da auf? An sich ist das erlaubt.

Hallo photron,

tatsächlich konnte ich den o.g. Connection-Error nicht mehr reproduzieren... Damit bestätigt sich wohl mal wieder, dass 99 % der IT-Probleme am Nutzer liegen 😅
Habe etwas mit den einfachen GUI-Beispielen herumgespielt und da hat es in der Tat immer problemlos funktioniert, set_gui_graph_data in diverse Callbacks einzusetzen. Sorry...

Gruß

[Michael_S]

kurzes Update nach fünf Monaten: funktioniert weiterhin recht gut; bisland keine Anzeichen von Überforderung bzgl. Datenhandling beim Raspberry (außer dass er unabhängig von der gespeicherten Messdatenmenge ab und an ein wenig hängt...).

Eine Frage zum Air Quality Bricklet kam mir jedoch noch auf. U.a. hier im Forum wird das Thema Selbstkalibrierung des Sensors ja recht ausführlich diskutiert. Dem habe ich entnommen, das der Sensor seine 4 bzw. 28-Tage-Kalibrierung in einen internen FlashSpeicher schreibt. Mein Eindruck ist, dass dieser geleert wird, wenn der Sensor bzw. das Bricklet stromlos ist. Stimmt das? Und wenn ja, gibt es eine Möglichkeit, den Kalibrierungs-Code auszulesen, zu Speichern und beim nächsten Start wieder in den Flash zu schreiben?

[Superp]

Michael,

What a brilliant project you have created!

I had big plans with the Air Quality Bricklet, supplying input for a light art object, but found the readings not reliable enough for a public project (see discussion here).

I know of no way to save/load calibration data. So, I took the Bricklet out of the project, but I am still very interested in using it when I can make the readings "behave".

Best!

[Michael_S]

Hi @Superp,

thank you very much for the positive feedback.
In the meantime I have added some more visualizations of the measurement data (see pictures).

Thanks also for the hint regarding the IAQ sensor. For this I have done some searching. I think the basic problem is the design of the BME680 itself. It is a metal oxide semiconductor gas sensor. The conductance of the material then changes depending on the chemical reactions that take place between the oxide layer and the gases. This is expressed in a (non-linear) but nevertheless highly simplified relationship, see e.g. here.

Various factors such as aging, gas type and humidity strongly influence the correlation (and thus the calibration). Bosch processes all this, as @borg already said, in a non-published algorithm.
Ultimately, the sensor is particularly well suited for showing trends, but less well suited for determining an absolute level. The sensor seems to store the calibration in three calibration parameters, for which specific addresses are given in the user manual (p. 19). It should therefore be possible to read and write them. For me, it would be great if this would be possible at least via code in the TinkerForge API. One could then store the parameters externally (e.g. on a Raspby) and write them from there back to the BME680 on initialization.
Personally, however, I assume that the measured values would nevertheless still fluctuate strongly. I have made good experiences regarding a fast and quite robust calibration when the sensor gets to know two extremes (outside air and e.g. a nearby tissue with spirit).

For your project, however, you could consider using a CO2 sensor as an alternative. As for human emissions, both the Bosch IAQ index and CO2 are good indicators of air quality. If human emissions are dominant, both values run in good approximation parallel with a factor of about 10 (i.e. very roughly simplified: CO2 in ppm = about 10 x Bosch IAQ index). The CO2 sensor is in comparison very robust and reliable. The IAQ sensor "only" offers a "real advantage" if additional emission sources are present (e.g. cooking, peeling mandarins, cleaning solvents, ...), as they are not "noticed" by the CO2 sensor.

Excursus: at this point one really has to realize that CO2 itself is only an indicator. For example, even 20,000 ppm are completely harmless to humans. Because even at a CO2 concentration of 20,000 ppm, only about 2% of the oxygen has been converted into CO2. The remaining approx. 19 % oxygen are more than sufficient for metabolism. Such CO2 concentrations are common on submarines, for example. However, among other things, carbon filters are used there to remove the substances that really have a negative impact on our well-being: VOC. Without such carbon filters, the VOCs emitted by humans usually reach a hygienically critical level after the time after which the CO2 concentration caused by humans has also risen to > 1,000 ppm. As already mentioned, the situation is different if additional VOC sources are present (e.g. plasticizer vapors from furniture, especially formaldehyde).

[Superp]

Michael, you are a goldmine of information. Thank you!

Quote

 It should therefore be possible to read and write them. For me, it would be great if this would be possible

I second that. The Bosch module behaves quite like a black box; it would be helpful if it was a bit more transparent. Even better if you could control what happens inside (re-load calibration). Maybe one of the Tinkerforge guys like @photron can chip in and tell us how likely it is to get this implemented?

CO2 as an alternative measurement sounds like an idea worth investigating. Thank you for explaining the IAQ/CO2 relationship in such detail, very helpful.

BTW, do you not have problems with the LCD Bricklet flooding the Brickd log on your RPi?

[Michael_S]

I'm happy if the information was helpful.

To be honest, I can even understand why Bosch doesn't really want to open the sensor's black box. Probably, no one could do anything with the "raw data" anyway. As mentioned, you only get a conductivity value or its change over time as a measurement signal. The sensor does not know which gases or which VOCs are reacting on the oxide layer... Therefore, a very robust evaluation routine is needed. Of course, this has its limits - but on the other hand the sensor is cheap and available in masses.

Which log file do you mean exactly? (Unfortunately I'm quite a greenhorn concerning Pi OS and Linux based operating systems...)
Indeed, the Raspby has certain performance problems from time to time. I.e. when I wipe between the tabs and want to access the tabs for which it has to calculate and visualize a long data history...

[Superp]

On Pi OS, most likely /var/log/brickd.log

If you want to monitor, try

tail -f /var/log/brickd.log

in a terminal. Hit ctrl-C to exit.

I have ordered a CO2 Bricklet 2.0, but it is taking its time.

[Michael_S]

Thank you for the explanation.
I found the file and it looks quite unremarkable. A few reboots and twice there were in deed some cecksum-errors at the port of the LCD, but then they disappeared as well.

[Superp]

Michael,

Your project and explanation inspired me to add a CO2 sensor to my project, and is has been very interesting so far.

With Covid-19 even more so, as an indicator of how much of the air you breathe is actually second hand. I put the whole thing on the table at a meeting, for instance. Quite graphic.

Other discoveries are how little the CO2 ppm differ between city and countryside. Or that when you're sleeping, CO2 is relatively low, it starts to rise as soon as you wake up.

As a portable device, it is almost like a sixth sense.

I find CO2 levels at the high side (rarely below 1000ppm, outside or in), so will be getting a second sensor to compare.

[Michael_S]

Hi Superp,

that sounds pretty interesting. Do you also operate your mobile sensor with a Raspby?

Indeed, people's CO2 emissions vary strongly depending on activity (and body size). Sleeping about 8-11 l/h, sitting about 16-22 l/h and physically active about 34-44 l/h.

In fact, CO2 concentration in outdoor air varies more globally than locally, see e.g. here. Interestingly, there is a tendency for little higher values in winter (northern hemisphere) of about +10-15 ppm, as plants then have a lower photosynthetic activity.
However, significant differences between urban and countryside can be observed in particulate matter concentrations (Particulate Matter Bricklet).

Best regards
Michael

[Superp]

Indeed, a Pi with HAT Brick, GPS, CO2, AirQ, sound pressure, multi-touch, segment display. One module is an adapter plate for external power packs. You click in a power pack and off you go. I really like that. Took a few experiments to get it right.

Thanks for the info on CO2.

Grüße!

[Michael_S]

Sounds great - I also thought about a mobile devices with a USB powerbank...

Do you have a photo?

[Superp]

Sure. I build little cubes. The battery adapter plate is on the right, occupying one side of the cube. It looks a bit like a bay window. No battery. Rightmost the button to unlock/eject the battery.

And this is the same cube, with a 3350mAh @ 7.2V battery attached. The display is switched to show DC Voltage:

A USB powerbank works well, too. I have tried this; it is simple, it just works. This requires (almost) no changes to your design. When your experiment fails, you can still use the powerbank for many other purposes. I can only encourage you to do this. Taking your project with you on the road, or even just to all corners of the house, opens up many opportunities.

 

[Superp]

I guess you would like to know a bit more about the batteries 🚀

Pictured above is a Jupio Proline NP-F550.

The plate accepts anything compatible with Sony NP-Fnnn series. These three are NP-F550, NP-F750, and NP-F970, all Jupio Proline (3350, 6700, 10050 mAh @ 7.2V):

The 550 is great for handheld use. The 750 is somewhat heavy but still good for handheld use.

The 970 is big, heavy and expensive. It makes a cube not so much portable, as autonomously powered. It can run 24 hours on a charge.

[Michael_S]

Looks realy great, thank you for the pictures and informations!

Think I will build a second and more compact one. Also with light and sound Bricklets and maybe (hopefully) with some new sensor Bricklets (?)

For example Sensirion has some very interesting IAQ-combi-sensors^^ Also an update with the FLIR Lotus 3.5 for the Thermal Imaging Bricklet would be nice.

Keep you informed!