Funksensor mit Bosch sensortec BME680 / Luftgüte

[herrmannj]

Offenbar niemand (außer Bosch in Library) hat sich bislang wohl mal genauer um die Kompensation der Widerstandswerte des VOC-Sensors gekümmert.

Sag das nicht Könntest hier im forum fündig werden.

Daher sehen auch die selbsterrechneten IAQ-Werte aus den ganzen Drittanbieter-Librarys (z.B. die Python-Library von Pimoroni) teilweise irgendwie schrottig aus.

yepp, sind idR unbrauchbar.

Achtung, Du korrigierst mit der relativen Feuchte. Das funktioniert weil T in Deinem Aufbau ausreichend konstant ist. Ausschlaggebend ist jedoch die absolute Feuchte. Der Zusammenhang R und aH ist umgekehrt exponentiell.

Zwei weitere Faktoren sind Alterung und Sättigung. Stell mal Aceton daneben, entferne dann die Quelle und Lüfte bei (möglichst gleichbleibender T und aH). Der bleibt in der Sättigung (R steigt aber bleibt weit vom Ausgangswert entfernt). Erst wenn aH runter geht "erholt" der sich.

Bei 1Hz Abtastrate steigt die Abweichung des Temperatur Sensor (on-Chip). Empfehlung > 10S wenn Du T auch auswertest.

vg
Joerg

[peterk_de]

Tatsächlich, hab ich nun gefunden - wie konnte ich nur an euch zweifeln

Mit absHum zu rechnen macht natürlich total Sinn in Anbetracht des beheizten Sensors. Deine Formel ...

  float ratio = (float)base / (r * aF * 7.0F);
  float tV = (1250 * log(ratio)) + 125;

... ist mir allerdings noch ein bisschen unklar. Wozu hast du den Faktor 7 da drin? M.E. wäre 1/7 sinnvoll, dann rechnet man zumindest ca. den ursprünglichen Widerstandswert (bei typischen 7g/m^3). Bei der Berechnung der tVOC kürzt er sich ja raus (da in base schon enthalten).

Stell mal Aceton daneben, entferne dann die Quelle und Lüfte bei (möglichst gleichbleibender T und aH). Der bleibt in der Sättigung (R steigt aber bleibt weit vom Ausgangswert entfernt). Erst wenn aH runter geht "erholt" der sich.

OK das kriegt man vermutlich nicht rausgerechnet.

Bei 1Hz Abtastrate steigt die Abweichung des Temperatur Sensor (on-Chip). Empfehlung > 10S wenn Du T auch auswertest.

Hier messe ich beim startup den Temperatur-Offset. rH rechne ich entsprechend um.

[herrmannj]

Ja das Mal 7 ... Durch 7 war sinnfrei

Ich hab mittlerweile einen verfeinerten Algorithmus der bisher alle Hürden genommen hat. Ich schaue Mal dass ich den in GitHub bringe

[peterk_de]

Also die Korrektur mit *absHum/7 übertrifft schonmal meine Erwartungen - das ist in dem oberen Diagramm die Kurve in Orange, gelb ist der rohe Widerstand.

Man sieht super wie der korrigierte Widerstand beim Lüften (Sensor direkt hinter dem offenen Fenster) fast konstant bleibt und nur ein bissel zittert (ist noch nicht sonderlich gefiltert). Ab um 11 schwappt schwallweise Küchenmief rüber ^^

Eigentlich reicht mir das so schon vollkommen um weiterzumachen mit dem IAQ-Score ^^ Die Baseline-Korrektur mache ich jetzt einfach über FHEM (Fenster nach mindestens 10 min geschlossen (oder CO2 < 500, wo Sensor vorhanden) --> Baseline Reset auf aktuellen Wert; mit kontinuierlicher Vergrößerung, falls mal dann doch noch mal ein größerer R-Wert kommt während das Fenster zu ist)

[juergs]

Hallo peterk_de,

... wilkommen im Club...  

Ich denke auch, daß die Baseline-Korrektur eigentlich noch die betstehende Schwachstelle im Meßverfahren ist.
Eigentlich müsste der Sensor immer wieder in "sauberer" Luft kalibriert werden.
Bei Positionierung an einem offenen Fenster erübrigt sich das (im Sommer) bei gelegentlichen ESP-Resets ... 

Nachdem sich seit Herauskommen des BME680-Sensors um die 2016, haben hier viele Leute in diesem Thread sehr viel Zeit, Arbeit und Mühe
investiert um das Projekt immer wieder weiter nach vorne gebracht haben. Dann fände ich es toll, wenn Du Deine
Ergebnisse  konkreter hier zur Verfügung stellen würdest, um uns alle einen Schritt weiter nach vorne bringen.   


Verstehe mich bitte nicht falsch, musste das einfach mal loswerden ... 

Grüße,
Jürgen

[peterk_de]

Hey Juergs, selbstverständlich mache ich das. Ich bin aber noch nicht weiter als diejenigen, die das Ding schon länger haben, insofern kann ich noch nicht allzuviel beitragen.

Es läuft bei mir darauf hinaus, dass ich den BME die weitestgehend rohen Werte an FHEM liefern lassen werde (also das, was ihr alle schon habt) und dann einen Score durch FHEM berechne. Wenn das bei mir zufriedenstellend funktioniert, poste ich es natürlich. Hat den Vorteil, dass es dann völlig egal ist, wie man das Ding technisch angebunden hat. Und man bei Updates am Algorithmus, wenn man mehrere davon hat, nicht diverse ESPs neu flashen muss.

[twenta]

Hallo,
Darf ich mal so unverschämt reingrätschen und fragen ob Herrmannj schon die verfeinerte Version hochgeladen hat?
Danke

[herrmannj]

Ne, hat er noch nicht ... Macht er aber noch

[juergs]

Hallo Jörg,
Du wirst wohl Deine Gründe haben, schade dass es bisher nicht geklappt hat.

Güße,
Jürgen

PS: plane zwei Erweiterungen des BME680:




• Mit RISC-V-Sipeed-Longan-Nano
• Plus Air602, in Micrpython ...  als WLAN-Kommunikations-Prozessor

[herrmannj]

Hallo Jörg,
Du wirst wohl Deine Gründe haben, schade dass es bisher nicht geklappt hat.

Güße,
Jürgen

PS: plane zwei Erweiterungen des BME680:




• Mit RISC-V-Sipeed-Longan-Nano
• Mit Air602, in Micrpython ... ]

ganz unspektakulär. Muss nochmal aufgeräumt werden. Keine Zeit bisher. kommt asap

[juergs]

Hi,
beim "Aufräumen" kann ich auch gerne helfen

[peterk_de]

Das erinnert mich daran, dass ich euch meinen Algorithmus auch noch "schulde".

Der ist mittlerweile sehr gut abgehangen und funktioniert bei mir prima. Ich nutze dazu die rohen Widerstandswerte des BME680 und betreibe eine sehr simple "Sensorfusion" mit einem CO2-Sensor.

So sehen die Userreadings von meinem BME680-Device aus:

Code Auswählen Erweitern

correctedKOhm {

my $absH = dewpoint_absFeuchte(ReadingsVal("$name","temperature",0), ReadingsVal("$name","humidity",0));
my $kOhm = ReadingsVal("$name","kOhm",0);

return int(($absH * $kOhm / 7)+0.5);

},voc {

my $absH = dewpoint_absFeuchte(ReadingsVal("$name","temperature",0), ReadingsVal("$name","humidity",0));
my $kOhm = ReadingsVal("$name","kOhm",0);

my $correctedKOhm = ($absH * $kOhm) / 7;
my $baseCorrectedKOhm = ReadingsVal("$name","baseCorrectedKOhm",370);
my $startup = ReadingsVal("$name","startup","");

my $diff = max(0,$baseCorrectedKOhm-$correctedKOhm);
my $tVOCfak = 2200/$baseCorrectedKOhm;

if ($startup eq "done") {
  return int(400+($diff*$tVOCfak));
} else {
  return 0;
}


},quality { (ReadingsVal("$name","voc",450)<700?"sehr gut":(ReadingsVal("$name","voc",450)<1000?"gut":(ReadingsVal("$name","voc",450)<1500?"mittel":"schlecht"))) }

In den Readings  kOhm, temperature und humidity des Devices müssen dazu die "nackten" Werte des BME680 drinstehen, wie auch immer ihr die in FHEM hineinbekommt. Startup wird bei mir done wenn der Sensor nach dem Einschalten warmgelaufen ist (nach 5 Minuten).

Die Baseline wird dann über ein ausgesprochen simples DOIF gesetzt:

Code Auswählen Erweitern

([kue.balkontuer:"geschlossen"] and [kue.co2:co2] < 500)
  (setreading kue.iaq baseCorrectedKOhm [kue.iaq:correctedKOhm])

Mit anderen Worten, neue Baseline immer dann, wenn wirklich vollständig gelüftet wurde (machen wir immer über die dortige Balkontür). Geht auch ohne CO2-Sensor - dann könnte man z.B. auf  "Fenster war 30 Minuten offen" triggern.

Ergebnis ist dann ein Reading voc, das wirklich ziemlich gut mit dem CO2-Wert korreliert, aber eben auch durch Kochdünste mal nach oben ausreißt. Siehe z.B. Grafik am 13.4. gegen 21 Uhr

[juergs]

Hallp peterk_de,

interessante Herangehensweise.

Mit Jörgs Methode sieht es aber auch sehr plausibel aus.
Hier meine Anbindung üner ESPEasy und MQTT, die durchaus als wirklich sehr stabil und aussagekräftig zu betrachten ist.
Bei mir ist aber noch ein Glättungsalgorithmus zwischengeschalten, der die Ausreißer unterbindet und Steigungsänderungen etwas verzögert ...

Aber in der Tat, Baseline beim Lüften ... Aus- und -Wiedereinschalten.

[herrmannj]

Hi,
beim "Aufräumen" kann ich auch gerne helfen

Wenn Du das mal nicht bereust - allerdings kann ich aus bestätigen dass das in der Vergangenheit sehr gut funktioniert hat.

Hier ist das git: https://github.com/herrmannj/airq-mqtt

Ziele waren/sind: Umbau auf mqtt, die config vernünftig im Sensor speichern und TVOC noch besser.

Mein "Problem" ist eigentlich dass ich jetzt 4 Monate andere Sachen gemacht habe und ich weiß nicht mehr genau wo ich "damals" stehen geblieben bin.    Fertig ist es nicht, soviel ist sicher. Ich erinnere mich dunkel das ich in der Adafruit BME was machen wollte, da hatte ich die richtige Stelle für den Temperatur Offset gefunden.

Zum TVOC: der Algorithmus war ja schon gut, Pferdefuß war die ABC, insbesondere in extrem Situationen (wie draußen bitter kalt / Luft trocken, etc)

Die Baseline hier arbeitet daher anders: da ist ein Lowpass vorgeschaltet.

Wenn "saubere Luft" erkannt wird (vie Res * AbsHum) wird nicht mehr blind und sofort die Baseline neu gesetzt. Statt dessen wird die Baseline (über den Filter) vergleichsweise langsam angepasst. Die Filterkonstanten und das Ausleseintervall zusammen machen so etwa 10-15min aus in denen die Baseline schrittweise immer weiter angehoben wird. Dadurch gleichen sich die Latenzen der Sensoren (Hum ist extrem) gegen den Filter aus. Das bedeutet jetzt nicht das man 15min lüften muss weil die Luft ja erstmal ok ist und der Filter läuft weiter.

Baseline (und in der Folge TVOC) "nutzen" sich im Verlauf von etwa 2 Tagen "ab" (Filter). Damit wird sicher gestellt dass im Normalfall alle ein bis 2 Tage eine Baseline Korrektur durchgeführt wird. Das bedeutet dass der Raum halte alle 1-2 Tage auch saubere Luft "sehen" muss. Das passiert aber eigentlich ganz automatisch: Büro bin ich tagsüber, Nachts wird von der Lüftung "durchgelüftet". Schlafzimmer andersrum , usw. Auch die Familie ist ja nie immer und überall gleichzeitig.

Die Werte de da jetzt aus dem Sensor rauspurzeln passen daher durchgängig zu dem was man Erwartet (sind logisch) und es gibt auch keine extremen Ausreißer mehr. Die "alte" Version hatte ja noch die Macke das eine verfälschte ABC teilweise dann 2-3 Wochen lang TVOC Werte von 600ppm angezeigt hat - selbst bei geöffnetem Fenster. Das ist alles weg- ist sogar auf etwas konservativ getuned. Aber so dass eben Essen kochen (oder Ausdünstungen wie auch immer) sicher erkannt werden.

Schau mal, vielleicht kannst Du ja erkennen wo ich stehen geblieben bin. Der Sensor läuft hier auf dem Schreibtisch seid jetzt 4 - 5 Monaten, viel fehlte da mMn nicht - mqtt aber zb fehlt, Config ist auch erst 80% (meine ich)

[juergs]

Hallo Jörg,

das hört sich genau nach dem Passenden an. 
Meine Erfahrungswerte sind mit der "alten" Version eigentlich schon sehr gut und nachvollziehbar.
Aber das Bessere ist des Guten Feind

Sobald ich am Thema dran bin arbeite ich mich auch wieder ein, da es mir da genauso geht wie Dir.

Danke + Grüße
Jürgen