2022 und die CO2-Ampel – Shoutout (1)

Im ersten Teil standen die Beweggründe für das, was jetzt kommt: viele Sensoren messen das Gleiche.

Im Rennen sind:

Model	Typ	Ergebnis	Preis in EUR
CCS811	Luftqualitäts-Sensor	VOC, eCO2	11,92
SGP30	Luftqualitäts-Sensor	VOC, eCO2	18,05
MH-Z19C	NDIR CO2-Sensor	CO2	23,40
MQ-135	Gas-Sensor	eCO2	1,72
BME680	4in1 Sensor	VOC, eCO2, T/H/P	15,90
SCD40	NDIR CO2-Sensor	CO2, T/H	39,90
nicht betrachtet (Spenden willkommen ;-))
SCD41	NDIR CO2-Sensor	CO2, T/H	91,69
SCD30	NDIR CO2-Sensor	CO2, T/H	60,80

Der BME680 ist, wie gesagt, ein kleiner Sonderling; zu den Meßgrößen Temperatur, Luftfeuchte, Luftdruck des BME280 hat man noch einen Gas-Sensor hinzugesellt, im Grunde sollte also ein kleiner BME680 ausreichen für eine CO₂-Ampel. Dazu ein ESP8266, und die Sache wäre für rund 20 EUR – ohne Gehäuse und Signalisierung – fertig.

Allein: der BME680 gibt keinen eCO₂-Wert raus, sondern nur einen Widerstandswert in Ohm. Um daraus PPM [e]CO₂ zu machen – was bei CCS811 oder SGP30 direkt aus dem Sensor fällt –, braucht’s bei Boschs BME die closed-source-binary-only BSEC-Library. BSEC steht für Bosch Sensortec Environmental Cluster und wird als externe Library zur Abfrage des BME680 verwendet. Theoretisch fallen dann neben dem Wider­stands­wert noch eCO₂– und weitere Werte zur Luft­qualität aus der Sensor­ab­frage raus. Allerdings war der erste (und zeite und dritte) Versuch meinerseits, mit BSEC den BME680 abzufragen, eher nicht von Erfolg gekrönt:

[15:06:40][I][app:029]: Running through setup()...
[15:06:40][I][i2c.arduino:161]: Performing I2C bus recovery
[15:06:40][C][bme680_bsec.sensor:016]: Setting up BME680 via BSEC...
[15:06:40]Guru Meditation Error: Core  1 panic'ed (Unhandled debug exception)
[15:06:40]Debug exception reason: Stack canary watchpoint triggered (loopTask) 
[15:06:40]Core 1 register dump:
[15:06:40]PC      : 0x401244fb  PS      : 0x00060336  A0      : 0x80120189  A1      : 0x3ffb0070  
WARNING Decoded 0x401244fb: __ssprint_r at /Users/ivan/e/newlib_xtensa-2.2.0-bin/newlib_xtensa-2.2.0/xtensa-esp32-elf/newlib/libc/stdio/../../../.././newlib/libc/stdio/vfprintf.c:280
[15:06:40]A2      : 0x3ffb8100  A3      : 0x3ffb03b0  A4      : 0x3ffb0294  A5      : 0x00000010  
[15:06:40]A6      : 0x00000003  A7      : 0x3ffb02d4  A8      : 0xa0000000  A9      : 0x00000000  
[15:06:40]A10     : 0x00000000  A11     : 0x10000000  A12     : 0x00000000  A13     : 0x00000000  
[15:06:40]A14     : 0x00000020  A15     : 0x3ffaf750  SAR     : 0x00000004  EXCCAUSE: 0x00000001  
[15:06:40]EXCVADDR: 0x00000000  LBEG    : 0x400014fd  LEND    : 0x4000150d  LCOUNT  : 0xffffffff  
[15:06:40]
[15:06:40]ELF file SHA256: 0000000000000000
[15:06:40]
[15:06:40]Backtrace: 0x401244fb:0x3ffb0070 0x40120186:0x3ffb00a0 0x40122956:0x3ffb03b0 0x40122992:0x3ffb0440 0x400e5dbd:0x3ffb0480 0x400e5df3:0x3ffb04d0 0x400d454d:0x3ffb04f0 0x400d46ca:0x3ffb0da0 0x400d470e:0x3ffb0f90 0x40180ac5:0x3ffb0fb0 0x40180bbd:0x3ffb0fd0 0x400e52cd:0x3ffb0ff0 0x400ec3ba:0x3ffb1040 0x40100ce2:0x3ffb1fb0 0x4008a422:0x3ffb1fd0
WARNING Found stack trace! Trying to decode it
WARNING Decoded 0x401244fb: __ssprint_r at /Users/ivan/e/newlib_xtensa-2.2.0-bin/newlib_xtensa-2.2.0/xtensa-esp32-elf/newlib/libc/stdio/../../../.././newlib/libc/stdio/vfprintf.c:280
WARNING Decoded 0x40120186: _svfprintf_r at /Users/ivan/e/newlib_xtensa-2.2.0-bin/newlib_xtensa-2.2.0/xtensa-esp32-elf/newlib/libc/stdio/../../../.././newlib/libc/stdio/vfprintf.c:1774 (discriminator 1)
WARNING Decoded 0x40122956: _vsnprintf_r at /Users/ivan/e/newlib_xtensa-2.2.0-bin/newlib_xtensa-2.2.0/xtensa-esp32-elf/newlib/libc/stdio/../../../.././newlib/libc/stdio/vsnprintf.c:72
WARNING Decoded 0x40122992: vsnprintf at /Users/ivan/e/newlib_xtensa-2.2.0-bin/newlib_xtensa-2.2.0/xtensa-esp32-elf/newlib/libc/stdio/../../../.././newlib/libc/stdio/vsnprintf.c:41
WARNING Decoded 0x400e5dbd: esphome::str_snprintf[abi:cxx11](char const*, unsigned int, ...) at /home/wusel/esphome/.esphome/build/esp32-env-2/src/esphome/core/helpers.cpp:233
WARNING Decoded 0x400e5df3: esphome::to_string[abi:cxx11](int) at /home/wusel/esphome/.esphome/build/esp32-env-2/src/esphome/core/helpers.cpp:233
WARNING Decoded 0x400d454d: esphome::bme680_bsec::BME680BSECComponent::load_state_() at /home/wusel/esphome/.esphome/build/esp32-env-2/src/esphome/components/bme680_bsec/bme680_bsec.cpp:393
WARNING Decoded 0x400d46ca: esphome::bme680_bsec::BME680BSECComponent::setup() at /home/wusel/esphome/.esphome/build/esp32-env-2/src/esphome/components/bme680_bsec/bme680_bsec.cpp:55
WARNING Decoded 0x400d470e: esphome::bme680_bsec::BME680BSECComponent::setup() at /home/wusel/esphome/.esphome/build/esp32-env-2/src/esphome/components/bme680_bsec/bme680_bsec.cpp:22
WARNING Decoded 0x40180ac5: esphome::Component::call_setup() at /home/wusel/esphome/.esphome/build/esp32-env-2/src/esphome/core/component.cpp:122
WARNING Decoded 0x40180bbd: esphome::Component::call() at /home/wusel/esphome/.esphome/build/esp32-env-2/src/esphome/core/component.cpp:122
WARNING Decoded 0x400e52cd: esphome::Application::setup() at /home/wusel/esphome/.esphome/build/esp32-env-2/src/esphome/core/application.cpp:38
WARNING Decoded 0x400ec3ba: setup() at /home/wusel/esphome/.esphome/build/esp32-env-2/src/esphome/core/gpio.h:62
WARNING Decoded 0x40100ce2: loopTask(void*) at /home/wusel/.platformio/packages/framework-arduinoespressif32/cores/esp32/main.cpp:18
WARNING Decoded 0x4008a422: vPortTaskWrapper at /home/runner/work/esp32-arduino-lib-builder/esp32-arduino-lib-builder/esp-idf/components/freertos/port.c:355 (discriminator 1)
[15:06:41]
[15:06:41]Rebooting...
[15:06:41]ets Jun  8 2016 00:22:57

Ach so: wie man sieht, nutze ich derzeit ESPHome zur Programmierung der ESPs, weil sich damit ein einfaches Templating umsetzen läßt, sodaß dann auch gleich via MQTT die Meßwerte aus dem ESP in die InfluxDB fallen — recht nifty.

Als alter Amiga-Programmierer finde ich die Rückkehr des »Gure Meditation Errors« einerseits witzig — andererseits auf einem Gerät ohne Ausgabedevice (TTL-RS232, horray!) auch maximal nervig 😉 Ich taste mich langsam ran — die Sensoren werden nach und nach per Breadboard angeschlossen —, aber schon mit BMP280 und BME680 knallt’s mit der BSEC-Library 🙁

Aktuell habe ich folgende Geräte am I²C-Bus des ESP32:

[I][i2c.arduino:060]: Found i2c device at address 0x23 # BH1750 Lux
[I][i2c.arduino:060]: Found i2c device at address 0x38 # AHT20 T/H
[I][i2c.arduino:060]: Found i2c device at address 0x3C # SSD1306 OLED
[I][i2c.arduino:060]: Found i2c device at address 0x40 # HTU21D-F T/H
[I][i2c.arduino:060]: Found i2c device at address 0x76 # BMP280 T/P
[I][i2c.arduino:060]: Found i2c device at address 0x77 # BME680 T/H/P/Gas

Dank des Faktes, das BSEC closed source ist, bleibt es nebulös, warum der ESP32 direkt crasht … Aber es liegt nahe, daß die Library mit dem BMP280 auf dem gleichen Bus nicht zurande kommt.

Nun hat so ein ESP32 ja glücklicherweise gleich zwei I²C-Busse, also flugs BMP280, HTU21D und BH1750 samt dem Display auf einen anderen Bus gezogen, und nun spielt auch die BSEC-Library mit meinem BME680.

[01:22:14][C][i2c.arduino:038]: I2C Bus:
[01:22:14][C][i2c.arduino:039]:   SDA Pin: GPIO21
[01:22:14][C][i2c.arduino:040]:   SCL Pin: GPIO22
[01:22:14][C][i2c.arduino:041]:   Frequency: 50000 Hz
[01:22:14][C][i2c.arduino:044]:   Recovery: bus successfully recovered
[01:22:14][I][i2c.arduino:054]: Results from i2c bus scan:
[01:22:14][I][i2c.arduino:060]: Found i2c device at address 0x38
[01:22:14][I][i2c.arduino:060]: Found i2c device at address 0x77
[01:22:14][C][i2c.arduino:038]: I2C Bus:
[01:22:14][C][i2c.arduino:039]:   SDA Pin: GPIO16
[01:22:14][C][i2c.arduino:040]:   SCL Pin: GPIO17
[01:22:14][C][i2c.arduino:041]:   Frequency: 50000 Hz
[01:22:14][C][i2c.arduino:044]:   Recovery: bus successfully recovered
[01:22:14][I][i2c.arduino:054]: Results from i2c bus scan:
[01:22:14][I][i2c.arduino:060]: Found i2c device at address 0x23
[01:22:14][I][i2c.arduino:060]: Found i2c device at address 0x3C
[01:22:14][I][i2c.arduino:060]: Found i2c device at address 0x40
[01:22:14][I][i2c.arduino:060]: Found i2c device at address 0x76

Ein Sensor geschafft, vier stehen noch aus. Also mal den MQ-135 ansehen; für unter zwei Euro klares Schnäppchenpotential …

Um ehrlich zu sein, habe ich mit dem MQ-135 sogar angefangen, denn einerseits hatte ich eine Handvoll davon schon da, zum anderen gibt es dafür eine Vorlage für ESPHome. Schwierig ist nur die Kalibrierung, aber irgendwas ist ja immer. Wenn man einen echten CO₂-Sensor zur Hand hat, ist das natürlich einfacher … Und so entstand dann letztlich die Idee zum Shootout der Sensoren — denn ›wer viel mißt mißt Mist‹, wie mein GK-Physiklehrer immer sagte 😉

Der Breadboard-Ansatz allerdings ist kein guter, oder mein Material ist schlecht, oder für mich als grobmotorischen Programmierer sind die 2,54mm-Raster-Steckerchen nicht gebaut, was auch immer. Ich werde mir nun doch einen »I²C-Verteiler« zusammenlöten, auf den ich dann nur noch die Sensoren stecken muß — auf ’ner 2×8 cm Lochrasterplatine sollten sich 10+ Abgriffe realisieren lassen, quasi ein I²C-Bus für den Test. Mehr dazu in Teil 3.