Funksensor mit Bosch sensortec BME680 / Luftgüte

Begonnen von juergs, 28 Oktober 2017, 18:05:43

Vorheriges Thema - Nächstes Thema

hdgucken

Hallo Peter,

Zitat von: PeMue am 04 November 2017, 20:38:50
nein, so geht es nicht. Das schreibt das Datum auf die serielle Schnittstelle.
Ups, stimmt natürlich, war wohl nicht ganz bei der Sache  ;)
Aber das Script sieht gut aus ! Könnte ein Linuxprofi auch nicht besser  ;D

Bin ja mal auf die morgigen Messwerte (Feier) gespannt ...

Gruß Thomas

juergs

#76
So, der Referenzwert-Sender über LaCrosse für den iAQ-core-Sensor ist ebenfalls fertig und funkt seine Werte an FHEM.  :D

Man kann schon erkennen, der iAQ hat schon wesentlich besseren Glättungs-Algorithmus eingebaut.
Beim BurnIn zeigte er etwas "abstruse" Werte an, die sich nach einiger Zeit in realistische Werte-Bereiche änderten.
Status 4 ist nicht im Datenblatt ... 

ZitatCO2:1458, Status:4, Resistance:28062, TVoC:403
2017-11-04 19:36:23   Message   BurnIn?

Die Grafik zeigt mal wieder die bekannten Fenster-Öffnen-Aktionen und die Reaktion des Sensors darauf.
Jetzt müssen doch noch Langzeitwerte gesammelt werden. Man sieht auch, dass die Werte von CO2 + TVOC eigentlich korrelieren.
So dass sich je nach Gusto noch ein Dallas18B20 oder BME280-Sensor zur möglichen Temperatur-Kompensation anbieten würde. 

In der Zwischenzeit kümmere ich mich um die Außreißer der BME680-Werte, die die SVG-Grafik ungünstig skalieren.
Mal schauen, ob das per FHEM/Perl oder eher im Code passieren kann.

Als Option wären dann Status-Icons, die abhängig vom CO2 farblich den Zustand anzeigen sinnvoll. In FHEM habe ich Entsprechendes schon gesehen ...

Den passenden VisualMicro-Code "iAQ-NANO-LACROSSE-TX3" dazu habe ich hier bei Github veröffentlicht.
Voreingestellt ist die SensorID: 92.

Anbei ein paar CSV-Daten zum analysieren ...

PS: Bei Amazon sind die BME-Breakboards wech ...  :'(

juergs


juergs

#78
Zu erkennen ist:
Einfluß der Temperatur-Gradienten auf den TVOQ, sowohl iAQ-Core als auch BME.
Fenster öffnen und wieder Fenster zu und Heizung an. Der Sensor befindet sich in Nähe des Fensters.   
Zwei Störende Pearl Funksensoren habe ich die Batterien entfernt um deren Einfluß bei der Übertragung zu minimieren.
Sie haben kurze Intervallzeiten und viele Repetitions. Evtl. hat das zu den fehlenden Daten geführt ... 
Zumindest beim iAQ wird man nicht um eine Temperatur-Kompensation herumkommen.
Besonders bei großen Delta-T's, da reagiert der iAQ empfindlich. 

Beim BME habe ich testweise eine Ausreißer-Erkennung in die Resistance-Ausgabe eingebaut.
Mal schauen, ob sich die SVG-Grafik dadurch verbessert.

PeMue

#79
Zitat von: hdgucken am 04 November 2017, 23:25:03
Bin ja mal auf die morgigen Messwerte (Feier) gespannt ...
Da war CO2/IAQ-mäßig (und auch sonst  ;D) ziemlich was los, siehe Anhang.

Ich hatte die Gelegenheit, mit einem "Insider" zu sprechen:
- Der BME680 sollte eine ähnliche Charakteristik haben, wie der AMS Sensor.
- Der BME680 braucht etwa 4 Tage (eigentlich sollte es weniger sein), bis er sich kalibriert hat (soll vermutlich heißen, die Einschaltdrift ausgeregelt hat).
- Der IAQ ist mathematisch nicht definiert, d.h. jeder Hersteller kann den Wert irgendwie berechnen.
- So wie es scheint, macht der BME680 auch eine Driftkorrektur (nach unten), wenn lange im Raum nichts passiert (warum auch immer).

Gruß PeMue
RPi3Bv1.2 rpiaddon 1.66 6.0 1xHM-CC-RT-DN 1.4 1xHM-TC-IT-WM 1.1 2xHB-UW-Sen-THPL-O 0.15 1x-I 0.14OTAU  1xCUNO2 1.67 2xEM1000WZ 2xUniroll 1xASH2200 3xHMS100T(F) 1xRFXtrx 90 1xWT440H 3xTFA30.3150 5xFA21
RPi1Bv2 LCDCSM 1.63 5.8 2xMAX HKT 1xMAX RT V200KW1 Heizung Wasser

icey

Hallo zusammen,

bin neu hier und komme von der IP Symcon Fraktion. Wir versuchen gerade auch dem BME680 anständige CO2/ppm Werte zu entlocken. Meine ersten Versuche den BME680 parallel zum iAQ laufen zu lassen, empirisch anzugleichen,  könnt ihr hier sehen. https://www.symcon.de/forum/threads/32284-Modul-zur-Nutzung-der-Raspberry-Pi-GPIO?p=340551#post340551

Gruss
Bernd

juergs

#81
Hallo Bernd,
Schön auf gleichgesinnte Mitstreiter zu treffen  :)
Schau gerne mal dort bei Euch vorbei ...

Die Interpretation der Messergebnisse steht erst mal im Raum.
Sowie eine Verbesserung der Ausgaben .... Strategie?

Ich würde vorschlagen, wir stellen unsere Messergebnisse als CSV-Datei zur weiteren
Analyse zur Verfügung?

Vorschlag-Format:
Timestamp | Temperatur | Luftfeuchte | Resistance_680 | CO2_680 | Resistance_iAQ | IAQ_iAQ

Grüße,
Jürgen

joschi2009

Zitat- So wie es scheint, macht der BME680 auch eine Driftkorrektur (nach unten), wenn lange im Raum nichts passiert (warum auch immer).

Vielleicht denkt er dann, er sei auf einem Prüfstand.  ;D ;D ;D ;D

icey

Zitat von: juergs am 07 November 2017, 07:13:45
.... Strategie?

Ich würde vorschlagen, wir stellen unsere Messergebnisse als CSV-Datei zur weiteren
Analyse zur Verfügung?

Vorschlag-Format:
Timestamp | Temperatur | Luftfeuchte | Resistance_680 | CO2_680 | Resistance_iAQ | IAQ_iAQ

Grüße,
Jürgen

Hallo Jürgen,

genau das war auch meine Idee. Ich lasse jetzt mal den BME680 und den iAQ mehrere Tage am selben Ort laufen, ich schaue mir das dann mal näher an. Das mit der Driftkorrektur macht es nicht einfacher. Bei meine ersten Kurven habe ich schon so etwas vermutet.

Hoffnung ist aber immer noch, dass Bosch die Umrechnungsformel von Widerstand auf CO2/ppm oder TVOC/ppm bereit stellt.

Gruss
Bernd

HCS

Zitat von: icey am 07 November 2017, 09:45:47
Hoffnung ist aber immer noch, dass Bosch die Umrechnungsformel von Widerstand auf CO2/ppm oder TVOC/ppm bereit stellt.
Das wäre wirklich hilfreich. Die Bosch-IAQ ist eigentlich nutzlos, wenn man nicht weiß, wie sie zustande kommt.
Nur zu sagen "die Luft ist gut" ohne die Grenzwerte zu "schlecht" zu kennen macht wenig Sinn.

Ich habe eine Test-Firmware laufen, die auf der Bosch BSEC basiert.
Die habe ich etwas erweitert, dass ich auch den Widerstand und die Heizparameter für die hotplate bekomme (weil mir auch noch völlig unklar ist, welchen Einfluss die Zieltemperatur, die zwischen 200 und 400 °C liegen kann, hat).
So wie es aussieht, heizt die BSEC immer auf 320°C mit einer Heizdauer von 192ms.

Was man erkennen kann ist, dass der Widerstand kontinuierlich steigt und die IAQ sich nur ändert, wenn der Widerstand nicht mehr der ursprünglichen Steigung folgt.
Ich lasse das jetzt mal einige Tage laufen, um zu sehen, wo das hinführt. Der Widerstand kann ja nicht unendlich steigen.
Momentan ist die Messreihe noch zu kurz und nicht lange genug gelaufen, um da schon was vernünftig rauszuinterpretieren.

Und ich habe den Eindruck, dass die gemessene Temperatur nicht so deutlich zu hoch liegt, wie bei den BME280, die ich habe. Das scheint beim BME680 besser zu sein.

Vielleicht sollten wir eine "was noch unklar ist" Liste führen. Zusammengetragen könnten die bereits gefundenen Antworten dann mit etwas Glück ein Bild ergeben.

blehnert

Hallo Ihr fleißigen Entwickler,
Zitat von: juergs am 07 November 2017, 07:13:45
Hallo Bernd,
Schön auf gleichgesinnte Mitstreiter zu treffen  :)
Schau gerne mal dort bei Euch vorbei ...

Die Interpretation der Messergebnisse steht erst mal im Raum.
Sowie eine Verbesserung der Ausgaben .... Strategie?

Ich würde vorschlagen, wir stellen unsere Messergebnisse als CSV-Datei zur weiteren
Analyse zur Verfügung?

Vorschlag-Format:
Timestamp | Temperatur | Luftfeuchte | Resistance_680 | CO2_680 | Resistance_iAQ | IAQ_iAQ

Grüße,
Jürgen

Ich würde gerne Unterstützung anbieten durch Bereitstellen meiner Messdaten.
Habe bislang eine Messreihe der letzten sechs Tage, erstellt mit der "Test680.bin" von HCS vom 30.10. (aus diesem Thread).

Wäre vielleicht gut, wir würden alle die selbe 'Firmware' verwenden, welche hier genannten Ansprüchen genügt.

@HCS: würdest du Deine aktuelle FW wieder zur Verfügung stellen (oder habe ich diese übersehen)?

Habe drei BME680 zur Verfügung und würde wirklich gerne mit den Logs weiterhelfen (mehr kann ich nicht)

Grüße, Bernd

HCS

Zitat von: blehnert am 07 November 2017, 13:05:40
@HCS: würdest du Deine aktuelle FW wieder zur Verfügung stellen (oder habe ich diese übersehen)?
Ja, klar, heute Abend oder so. Muss die Normaliserung vom Luftdruck auf meine Meereshöhe für euch wieder ausbauen.

Mit "Resistance_iAQ | IAQ_iAQ" kann ich nicht dienen, weil ich diesen Sensor nicht habe.

Die Firmware läuft auf einem ESP8266 und liefert auf der Seriellen dieses Format:
TS: 52620 T: 19.8 H: 57.5 P: 1020.1 Gas: 5472 IAQ: 71 HT: 320 HD: 197 AC: 3
TS: 52680 T: 19.8 H: 57.4 P: 1020.1 Gas: 5467 IAQ: 72 HT: 320 HD: 197 AC: 3

TS: Zeitstempel
T: Temperatur
H: Feuchte
P: Druck
Gas: Widerstand
IAQ: von Bosch berechete IAQ
HT: Zieltemperatur hotplate (von BSEC gesetzt)
HD: Heizdauer hotplate (von BSEC gesetzt)
AC: Genauigkeit IAQ (1...3) (von BSEC geliefert)

Es wird alle 60 Sekunden ein Datensatz rausgegeben.

Mit dem bash script vom PeMue setze ich es in ein Logfile für FHEM um, auf dem der SVG von weiter oben läuft.

djbugs

HD: 197 passt nicht für ein 60s Intervall.
Die Heizdauer bei der BSEC ist abhängig vom Messintervall auch die internen Berechnungen bauen auf diese Timings auf.
ca 190ms beim LP Mode also alle 3s. Bei ULP sind es ca 2s und Messintervall 5min.

Bugs

HCS

Zitat von: djbugs am 07 November 2017, 15:41:44
HD: 197 passt nicht für ein 60s Intervall.
Die Messung findet alle drei Sekunden statt, aber es wird nur ein mal pro Minute der Wert übermittelt, um das log im Zaum zu halten.

juergs

#89
ZitatDas wäre wirklich hilfreich. Die Bosch-IAQ ist eigentlich nutzlos, wenn man nicht weiß, wie sie zustande kommt.
Nur zu sagen "die Luft ist gut" ohne die Grenzwerte zu "schlecht" zu kennen macht wenig Sinn.
Das macht nur Sinn wenn die Werte generell vergleichbar wären. Ich glaube [ppm] ist da Aussage-kräftiger.

ZitatIch habe eine Test-Firmware laufen, die auf der Bosch BSEC basiert.
Worauf basiert Deine Lösung?

ZitatVielleicht sollten wir eine "was noch unklar ist" Liste führen. Zusammengetragen könnten die bereits gefundenen Antworten dann mit etwas Glück ein Bild ergeben.
Sehr guter Vorschlag.  "was noch unklar ist" Liste => Github?

Zitatblehnert
Gerne.

Bei mir kann ich schon mal anfangen, fallls  es Sinn, macht den iAQ sinnvoll als Referenz mit einzubinden, dazu muss ich es schaffen den Resistance-Wert des BMEs zu glätten
(oder den möglichen Fehler zu finden  :( ... )

Vielleicht ist es im Vorfeld aber auch egal, wenn CSV-Werte vorliegen. Das lässt sich dann in der Tabellen-Kalulation besser prüfen bzw. ausblenden.

@HCS
Habe den Fehler bei meiner nodeMCU gefunden: I2C-Standard ist nicht auf D4/D5 (Weil GPIO) sondern auf D1 (SCL) / D2 (SDA).
War wohl in meiner Doku nicht sofort ersichtlich was "D"-Port und was GPIO ist ...
Versuche dann mal mein Compile ohne die WDT-Problematik durch zu  bekommen ...  oder Deine (neue) BIN einzusetzen.  ;)
Frage: Deine BIN ist für die gesamte LaCrosseGateway-Infrastrucktur oder nur für den BME? Falls ja, läuft das ohne den RFM69 nicht ...
Dann muss ich noch nachrüsten ...
Heute ist das bestellte BlueDot-Board gekommen, dann kann ich zusätzlich die ESP-Version ans laufen bringen.
Wegen dem CSV-Format würde ich für einen Standard plädieren, sonst muss man jedesmal umbauen ... oder Skripte dafür schreiben...  :'(

@bugs
ZitatHD: 197 passt nicht für ein 60s Intervall.
Die Heizdauer bei der BSEC ist abhängig vom Messintervall auch die internen Berechnungen bauen auf diese Timings auf.
ca 190ms beim LP Mode also alle 3s. Bei ULP sind es ca 2s und Messintervall 5min.
Sobald bei mir die BSEC-Version läuft, werde ich mir die Timing-Details noch genauer anschauen. Danke für den Hinweis.

Heute reicht es bei mir leider nicht zu mehr ...

Grüße,
Jürgen