Fragen zum iAQ-MQTT-Sensor von locutus

[Pfriemler]

Moinsen,

ich liebe es, wenn man Dinge auspacken, einschalten, konfigurieren und benutzen kann.
Allerdings stoße ich jetzt an meine Grenzen.
Es geht um das im Markt angebotene Board von locutus, zu dem ich mich gern austauschen würde, allerdings habe ich bisher keine Diskussionen dazu gefunden, obwohl das Teil ja doch ein paar Leuts gekauft haben.
Wenn ich was übersehen habe, bitte dorthin schicken.

Die Einrichtung des Sensors selbst war problemlos nach den nötigen Handgriffen (die ich aber von Tasmota ohnehin kenne).

Vielleicht kann ja auch locutus noch ein wenig Erhellung bringen.

1. gehe ich recht in der Annahme, dass der BMP280 auf dem Board eigentlich nur dazu da ist, Temperaturwerte zur Genauigkeitsverbesserung an den CSS811 zu liefern und dies irgendwie auch boardintern bereits passiert? Sonst ist ja immer von einem NTC im Zusammenhang mit dem CCS811 die Rede. Ich frage mich aber, wie das passieren soll ... auf dem ESP läuft ja schlicht ein Tasmota. Oder ist das Bestandteil der Routinen die aktiv werden, wenn man die (auch in 6.6.0 default deaktivierte) "USE_CCS811" auskommentiert?

Denn als Raumsensor ist er an dieser Stelle offenbar fehl am Platze, denn ich bekomme gut 5 Grad höhere Werte als anderswo im Raum. Ich schiebe das schlicht auf die Eigenerwärmung des Boards. Luftdruck ist natürlich nutzbar.

2. Die im Verkaufsthread genannten "Color x" Einstellungen:

Color 1 - LED3 leuchtet rot, CO² Wert z. B. über 1200 ppm
Color 2 - LED3 leuchtet grün, CO² Wert z. B. unter 800 ppm

schalten n.m.b.E. nur tumb die Farbe der WS2812 um - jeglicher Zusammenhang mit realen Messwerten scheint mir auf dem Board nicht hergestellt - bzw. auch nicht herstellbar, weil Tasmota aus meiner Sicht dafür das Handwerkszeug nicht mitbringt. Mit ESPeasy könnte man rules erstellen. Muss es also Aufgabe von fhem sein, der LED überhaupt eine sinnvolle Aktion zuzuweisen? Denn out of the box bleibt die LED zwischen 400 und 3000 ppm eCO2 unbeeindruckt weiß.

3. Muss ich bei dem mit angebotenen Gehäuse unbearbeiteten Gehäuse reichlich Lüftungsöffnungen vorsehen oder diffundiert die Luft auch so genügend ein?

Sorry, aber es ist mein erster Sensor dieser Art und ich fühle mich gerade ein bisschen doof. Jeder auch vage Hinweis ist willkommen.

[juergs]

Hallo Pfriemler,
befürchte, dass ich Dir mit dem CS811 + Tasmota nicht direkt weiterhelfen kann, da ich gerade in ESPEasy  unterwegs bin.
Bei Gelegenheit schaue ich mir das in der Tasmota-Firmware auch mal an.

Aber zumindest hast Du mich mit meinem BME680 + MQTT-Problem auf die richtige MQTT-Spur geleitet.

Danke + Grüße,
Jürgen

[Pfriemler]

Also jetzt wird doch der Hund in der Pfanne verrückt. 

Also dass es zwischen eCO2 und TVOC eine Korrelation gibt, mag ich ja noch verstehen (bei mir ist sie in diesem Bild etwa eCO2 = TVOC*6,64+382). eCO2 und die so aus der TVOC errechnete eCO2 decken ziemlich.
Fröhlich vor sich hin mäandert die gemessene Temperatur - Schwankungen um die 2 Grad (in dem Raum war niemand bis kurz nach 22 Uhr!).
Immerhin: es zeigt sich ein Einfluss auf die Luftgütewerte. Entweder das Board erwärmt sich tatsächlich - es ist kein Akku angeschlossen, aber das kann doch nicht das Problem sein... oder aber das Bord bleibt kühl, der T-Sensor spinnt - und sein Einfluss auf die Luftgütewerte ist zu sehen. Ob das überhaupt größenordnungsmäßig passt ... ?

Die Raumtemperatur hat jedenfalls keine Sprünge gemacht - die zeigt die untere Linie an, gemessen mit einem (korrigierten) LaCrosse TX29DHT.

Wie ich eingangs schon sagte: Eine generell höhere Temperatur könnte durch Borderwärmung sein. Aber die Schwankungen sind sehr seltsam.

Was ist hier kaputt? 

edit: links lies "Temperatur °C" statt TVOC
edit2: um 22:45 habe ich das Fenster aufgemacht

edit 3: Gerade ist der Akku in der FLIR verreckt. Der nach zu urteilen tut sich da wärmemäßig auf dem Board schon unterschiedliches. Die hohe Temperatur am BMP280 ist plausibel, allerdings hatte ich im Lifebild zu Beginn den CCS811 (hat über 36 Grad) und einen kleinen (auf dem Board IC1, aber das passt weder zu den Fotos noch zu dem Schaltplan im Thread) als helle Punkte, danach eine recht flächige Erwärmung (rückseits ist der ESP). Ich brauche auch mein anderes USB-Strommessgerät.
Irgendwas läuft da Amok...

edit 4: Board kurz ausgestromt und wieder eingestromt. Messwerte auf Minimum eingebrochen - so wie gestern zuerst.
Braucht der ein paar Minuten zum Warmwerden?

[locutus]

... allerdings habe ich bisher keine Diskussionen dazu gefunden, obwohl das Teil ja doch ein paar Leuts gekauft haben. Wenn ich was übersehen habe, bitte dorthin schicken.

https://forum.fhem.de/index.php/topic,28905.msg856906.html#msg856906

gehe ich recht in der Annahme, dass der BMP280 auf dem Board eigentlich nur dazu da ist, Temperaturwerte zur Genauigkeitsverbesserung an den CSS811 zu liefern und dies irgendwie auch boardintern bereits passiert? Sonst ist ja immer von einem NTC im Zusammenhang mit dem CCS811 die Rede.

Dazu dient der NTC. Der BMP180 misst hauptsächlich den barometrischen Luftdruck. Die Raumtemperaturmessung ist zwar damit möglich aber aufgrund der Wärmeentwicklung auf der Platine nicht empfehlenswert.
Temperaturkalibrierung mit Tasmota Add<x>, Sub<x>, Mult<x> Rules:
https://github.com/arendst/Sonoff-Tasmota/issues/2872

Ich frage mich aber, wie das passieren soll ... auf dem ESP läuft ja schlicht ein Tasmota. Oder ist das Bestandteil der Routinen die aktiv werden, wenn man die (auch in 6.6.0 default deaktivierte) "USE_CCS811" auskommentiert?

Tasmota baut auf der Adafruit_CCS811 Library auf.
https://github.com/arendst/Sonoff-Tasmota/tree/development/lib

Die im Verkaufsthread genannten "Color x" Einstellungen:schalten n.m.b.E. nur tumb die Farbe der WS2812 um - jeglicher Zusammenhang mit realen Messwerten scheint mir auf dem Board nicht hergestellt - bzw. auch nicht herstellbar, weil Tasmota aus meiner Sicht dafür das Handwerkszeug nicht mitbringt. Mit ESPeasy könnte man rules erstellen. Muss es also Aufgabe von fhem sein, der LED überhaupt eine sinnvolle Aktion zuzuweisen? Denn out of the box bleibt die LED zwischen 400 und 3000 ppm eCO2 unbeeindruckt weiß.

FHEM Notify, DOIF oder Tastota Rules erstellt?
https://github.com/arendst/Sonoff-Tasmota/wiki/Rules

Muss ich bei dem mit angebotenen Gehäuse unbearbeiteten Gehäuse reichlich Lüftungsöffnungen vorsehen?

Ja, unbedingt!

Board kurz ausgestromt und wieder eingestromt. Messwerte auf Minimum eingebrochen - so wie gestern zuerst. Braucht der ein paar Minuten zum Warmwerden?

48 Std. Burn-In-Prozess. TVOC geht auf 0 ppb, eCO2 auf 400 ppm zurück.

[Pfriemler]

Danke, locutus, für die Anworten.

Dazu dient der NTC.

So. Die Temperaturkompensation macht der CCS811 ganz allein. Das hatte ich bisher nicht so verstanden. Habe den NTC aber auch eben erst gesucht (und gefunden).

Der BMP180 misst hauptsächlich den barometrischen Luftdruck. Die Raumtemperaturmessung ist zwar damit möglich aber aufgrund der Wärmeentwicklung auf der Platine nicht empfehlenswert.

Und ich dachte der Sensor wäre für die Genauigkeit erforderlich.
Dann habe ich den Luftdruck sozusagen nur als Goodie mit an Bord.
Ich frage mich jetzt aber dennoch, was diese absurden Sprünge der Temperatur überhaupt verursacht. Also was heizt da so unregelmäßig auf der Plantine?
hm.. ob das mit dem Burnin-Prozess zu schaffen hat?

Tasmota baut auf der Adafruit_CCS811 Library auf.

Dass die zum Auslesen des Sensors erforderlich ist, war mir schon klar (und dass sie erst mit einkompiliert wird, wenn man den #define-Schalter setzt). Was ich nicht verstand: Welche Teil des Codes teilt dem CCS811 die Temperatur vom BMP mit? Welche Quelle? Aber das hat sich ja geklärt: Gar nichts. Dass das Hinzuziehen externer Temperaturmessung möglich (und angeraten) ist, legte die Funktionsbeschreibung des Sensors eigentlich nahe.

FHEM Notify, DOIF oder Tastota Rules erstellt?

Nö. Das wäre der nächste Schritt gewesen. Hatte den Rules-Editor gesucht bisher - gips nich, nur Console.
Hinterlegt ist nichts, muss man also selber machen. Dann baue ich mal...

Code Auswählen Erweitern

rule1 on CCS811#eCO2<600 do color 00007F endon on CCS811#eCO2>600 do color 005F7F endon on CCS811#eCO2>800 do color 007F5F endon on CCS811#eCO2>1000 do color 007F00 ndon on CCS811#eCO2>1500 do color 6F7F00 endon on CCS811#eCO2>2000 do color 7F7F00 endon on CCS811#eCO2>3000 do color 7F5F00 endon on CCS811#eCO2>4000 do color F0000 endon

und noch mit

Code Auswählen Erweitern

rule 1
aktivieren - fertig ist die Farbskala  ... Die Sensorwerte sind recht hoch, bei 5000 müsste ich ja tot umfallen, aber ich fühle mich wohl...
Was mir jetzt noch nicht gefällt: jede Farbänderung erzeugt einen write flash. Das muss noch besser gehen...

48 Std. Burn-In-Prozess. TVOC geht auf 0 ppb, eCO2 auf 400 ppm zurück.

Letzteres war gut zu beobachten - und gibt jetzt auch dem Akku einen neuen Sinn. Man sollte eine stromlose Phase vermeiden, wenn man Sensor mal im Haus umtopfen muss...
Komisch, ich hatte im Zusammenhang mit dem CCS811 von diesem "tollen neuen ams-Sensor mit 60 min burn-in gelesen". Große Zeitersparnis,  früher beim Kunden, blabla.
Ah, hier, 2018: https://www.elektroniknet.de/markt-technik/messen-testen/raumluftqualitaet-sofort-nach-dem-einschalten-beurteilen-155766.html

Im Datasheet von 2016 liest man wieder von ersten burn-in 48h - danach, nach längerer Ruhezeit, 20 Minuten "conditioning".
(Abhängig vom eingestellten Modus. Ich habe keine Anhaltspunkte dafür gefunden, dass ein anderer als der von Adafruit default programmierte 1-s-Modus eingestellt wird.)
Nun ist das Rätselraten, ob ich einen alten oder einen neueren Sensor verbaut bekommen habe.

So oder so: ich lasse ich das Ding erst mal warmlaufen.

[Pfriemler]

Die Probs mit den Schreibzugriffen sind erledigt, der Flash-Counter steigt nicht mehr.

Aber es passieren seltsame Dinge.

a) Das Teil legt alle 2-3 Tage, dann auch mal mehrmals am Tag einen Restart hin. "Reason: Blocked Loop"

b) die gemessenen Werte unterliegen teilweise wüstesten Schwankungen, wie hier etwa: Nachts im Treppenhaus. Kein Durchzug, keine Personen (durch Bewegungsmelder bestätigt )
Dann der Reset und alles ist wieder ruhig.

c) die seltsamen Temperaturschwankungen sind Geschichte, nun dauerhaft hoch

d) Die LED für die Akkuladung ist plausibel, LED1 hatte früher sehr kurz geblitzblinkert (sah aus wie eine direkte Spiegelung der WLAN-Aktivität) jetzt nur rhythmisches Blinken (kurz-lang, kurz-kurz usw), dessen System ich bisher nicht durchschauen konnte.

Bis jetzt hat der Sensor bestenfalls unterhaltenden Charakter 

Was mache ich falsch?

[locutus]

Das Teil legt alle 2-3 Tage, dann auch mal mehrmals am Tag einen Restart hin. "Reason: Blocked Loop"

Bitte Tasmota Reason Blocked Loop googeln!

die gemessenen Werte unterliegen teilweise wüstesten Schwankungen, wie hier etwa: Nachts im Treppenhaus. Kein Durchzug, keine Personen (durch Bewegungsmelder bestätigt )
Dann der Reset und alles ist wieder ruhig.

Ich sehe kurz vor 3 Uhr einen Neustart. Aufgrund von ...? ... instabiler Spannungsversorgung?

die seltsamen Temperaturschwankungen sind Geschichte, nun dauerhaft hoch

Ich wiederhole noch einmal: für Raumtemperaturmessung ungeeignet!
2 weitere Ports für externe Sensoren sind auf dem Board vorhanden.

LED1 hatte früher sehr kurz geblitzblinkert (sah aus wie eine direkte Spiegelung der WLAN-Aktivität) jetzt nur rhythmisches Blinken (kurz-lang, kurz-kurz usw), dessen System ich bisher nicht durchschauen konnte.

https://github.com/arendst/Sonoff-Tasmota/wiki/Commands#ledstate
https://github.com/arendst/Sonoff-Tasmota/wiki/Status-LED

Bis jetzt hat der Sensor bestenfalls unterhaltenden Charakter

Ich verkneife mir weiterer Kommentare an dieser Stelle.
Platine bitte zurücksenden. Ich werde den Geldbetrag zurückerstatten.
Ich rate zu kommerziellen Produkten ab 100 € aufwärts.

[Pfriemler]

locutus,
das hast Du glaube ich in den völlig falschen Hals bekommen, sorry. Also nochmal etwas ausgeholt:

Das ist keine Kritik an der der Entwicklung oder an der Ausführung der Platine! Ich hatte nur die Hoffnung, dass andere Leuts ähnliche Symptome ebenfalls wahrgenommen und so easy mit links umschifft haben dass sie es nicht einmal zu erwähnen für nötig hielten bis ich hier "jammerte".

Leider scheine ich der Einzige mit den Problemen zu sein. Schade, aber das ist zunächst mein Pech. Und mein alleiniges Risiko, so sehe ich das jedenfalls.
Und sollten alle meine oder die Tipps anderer zu keinem Erfolg führen oder der Sensor kaputt sein, verbuche ich das Projekt unter Lehrgeld, denn dazugelernt habe ich schon reichlich dabei.
Ich habe halt auch noch Verständnisprobleme mit den Messwerten vor allem im Zusammenhang mit der Arbeitsweise des CSS811.

locutus, Dein Angebot ehrt Dich wirklich, aber Du hattest Ausgaben, die ich Dir erstattet habe und wirst für die Fehlfunktion des Boards absolut nichts können, also warum sollte ich jetzt eine Gewährleistung in Anspruch nehmen, die Du völlig zu recht im Kleingedruckten zuvor ausgeschlossen hast. Punkt.

Bitte Tasmota Reason Blocked Loop googeln!

Das hatte ich zuvor schon reichlich und das war bisher außerordentlich wenig erhellend. Alle von mir gefundenen "Blocked Loop" issues behandeln n.m.b.E. entweder Probleme beim OTA (habe ich nie angestoßen) oder mit einem speziellen Sensor, wobei es dort auch noch zum Verlust von Einstellungen kam. Das ist ja hier nicht der Fall. Auffällig waren einzig die Resets der Messwerte, sonst gab es keine Funktionsänderung.
Auch ein Betrieb mit deaktivierter Rule (die ich zur Einfärbung der RGB je nach Messwert benutze) resultierte in mindestens einem Reset.
Ausfälle des WLAN könnten ebenso ein Problem sein, aber andere Tasmota-Geräte laufen seit mehr als einem halben Jahr ohne Resets.
So oder so: Ich vermute ja gleich ein Problem mit Tasmota. Und wenn ich das richtig verstanden habe, bin ich auf Tasmota auch nicht angewiesen und könnte genausogut ESPeasy oder ähnliches nutzen - etwas Aufwand für die Umstellung, aber das scheue ich nicht.
Auch an ledState, SetOption31 etc. ... Ich hatte daran eigentlich nichts geändert, aber das Verhalten der LED wurde von einem auf den anderen Tag anders - sprich eigentlich seit dem Einbau in das Gehäuse. Und die Blinkcodes sind leider nirgend erklärt (oder wieder für mich zu gut versteckt). Ich hätte zunächst Probleme mit MQTT oder WLAN vermutet, aber das rennt total stabil und ist auch gut "bestückt".

edit: Mir ist inzwischen völlig unklar, warum ich anfangs LED1 nur kurz blitzelnd sah (das Muster erinnerte echt an das was man sonst so an LEDs in LAN-Schnittstellen sieht oder an der blauen LED eines ESP8266 beim Wifi-Datenpaketen. Dieser Zustand ist einfach nicht mehr reproduzierbar.
Das Dauerfeuer nun ist geklärt: durch die aktive Rule (die alle 2 Sekunden getriggert wurde) überlagern sich Power- und MQTT-Meldungen - auch mit ledstate 6 (nur MQTT) blinkert es wie wild, weil die Rule den POWER-Status fortlaufend aktualisiert. Jetzt setze ich die LED aus FHEM sobald ein neuer Messwert publiziert wurde und die Rule ist inaktiv - und es herrscht Ruhe.

Ich sehe kurz vor 3 Uhr einen Neustart. Aufgrund von ...? ... instabiler Spannungsversorgung?

Würde mich sehr wundern. Die Neustarts treten mit drei verschiedenen Netzteilen auf. Außerdem ist das Board seit Tagen mit einem Akku (300 mAh, heute problemlos zwei Stunden "Ausfall" gebrückt) und dem mit reichlich Öffnungen versehenen Gehäuse komplettiert - zwei große über den Sensoren und oben und unten breite Schlitze für den "Durchzug"). Ein Blick in den Schaltplan machte dann auch klar, warum die RGB-LED auf Akku nicht mehr geht

Ich wiederhole noch einmal: für Raumtemperaturmessung ungeeignet!

Hatte ich schon beim ersten Mal verstanden. Die Schwankungen der Temperatur müssen mit den Bauteilen auf der Platine zusammenhängen und deren eigentlich kontinuierliche Arbeitsweise ließ diese Bocksprünge eigentlich nicht erwarten. Allerdings traten die zuvor im Test bei Betrieb ohne Akku auf. Seit der dort dran ist, ist es ruhiger geworden. Und der heutige Verlauf zeigt um 10 Uhr nur einen Temperaturabfall und ab 12:30 Uhr eine Beule mit Tendenz zum Grundwert - das war schlicht die Phase des Akkubetriebs mit folgender Wiederaufladung des Akkus. Ziemlich heftig. Und die erste eCO2-Spitze ist Folge einer häuslichen Durchlüftung, bei der anderswo "verbrauchte" Luft am Sensor vorbei kam. Ein Bilderbuchverlauf sozusagen.
Ein weiteres Problem hätte ich in stark wechselnder Last des ESP vermutet, was auch zu Temperaturschwankungen hätte führen müssen. Eine Korrelation der Temperatur mit Resets oder starken Schwankungen der Messwerte ist nicht feststellbar. Tatsächlich sind die Messwerte teilweise absurd hoch angestiegen (alles >5000 ppm sollte eigentlich schon klare körperliche Symptome hervorrufen, aber nix). Warum nach einem Reset sich sowohl die Sprünge sofort erledigen (siehe Bild aus dem Vorpost) als auch der Messwert wieder "genullt" wurde, kann ich mir nur dahingehend erklären dass es im Zuge eines Boardneustarts auch einen Reset an den CSS811 gibt, der daraufhin wieder einen Warmup startet.

In diesem Zustand jedenfalls sind sinnvolle Reaktionen auf Messwerte nicht machbar, deshalb mein flapsiges "unterhaltend". Wie gesagt: Wenn andere Boards aus der gleichen Charge stabil und solide laufen, habe ich halt Pech gehabt. Wenn nicht, könnte ich vielleicht Puzzleteilchen für die Fehlersuche liefern.

Ich rätsele derweil mal weiter: was erzeugt die aus den Umweltbedingungen kaum erklärlichen Schwankungen der Messwerte (bis auf den heutigen Bilderbuchverlauf)? ist der Sensor doch möglichweise defekt?  "Dampft da noch was von der Platine ab?" Die Korrelation aus Temperatur- und Schadstoffmesswert  ab 12:30 Uhr ist doch irgendwie auffällig...

[locutus]

Ich kann dieses Verhalten weder nachvollziehen noch reproduzieren. Jede einzelne Platine läuft min. einen 7-tägigen Probelauf durch bevor sie im Markplatz landet. Mein eigener iAQ-Sensor läuft seit 19 Tagen ohne unerklärliche Neustarts. Die 10 Startvorgänge sind auf das Trennen der Spannungsversorgung zurückzuführen. Dagegen setzt der mit Tasmota programmierte Sonoff TH16 (1 Generation) willkürlich aus.

Tasmota ist doch keine Zwangsjacke für den iAQ-Sensor. Auch andere Open Source Projekte, wie ESPEasy oder ESPHome unterstützen CCS811.

Mit einem 300 mA Akku kommt der ESP nur wenige Stunden aus. Dauerhafter WLAN-Betrieb ist Stromintensiv.

Solche Spitzen sehe ich tagtäglich. Mein iAQ-Sensor liegt im Wohnzimmer aber sobald ich in der Küche den Wasserkocher, die Kaffeemaschine oder den Herd einschalte, wandert die Kurve nach oben. Noch extremer reagiert er nur auf einen speziellen chemischen Reiniger.

Interessant ist auch die Auswertung von trebron106:
https://forum.fhem.de/index.php/topic,78619.msg978356.html#msg978356

[Pfriemler]

Das mit den 7 Tagen Testlauf ist mir neu und das ist doch mal eine klare Aussage. Die Platine ist in Ordnung, Punkt.

Abgesehen von einem Neustart wegen LED1-Umprogrammierung beruhigt sich das Teil jetzt auch auf allen Fronten. Und das Tasmota keine Pflicht ist, schrieb ich ja selbst schon.
Der 300-mAh-Akku war halt noch im Bastelkeller (gehörte zu einem Ersatzkauf für ein Bosch Intuvia eBike-Display) und ist klar nur zum Puffern bei Ausfall gedacht, und dafür reicht er dicke.

Genau, die Chemikalien. Eigentlich war mir das klar, aber das ist das Stichwort für die Korrelation von (Akku-)Erwärmung und Messwert in meinem letzten Bild:
Der Akku ist mit Klebetape befestigt  . Das kann ja dann mal so nicht bleiben. Und: Nein, ich werde die Klebereste nicht in der Nähe des Sensors entfernen 
Ich werde auch das Gefühl nicht los, dass der Sensor hier in meinem Zimmer auf irgendwelche Elektronikausdünstungen reagiert. Es folgt ein Test im Vorratskeller - der hat konstante Temperatur und da kommt manchmal tagelang keiner rein. 

Die Auswertung von tebron106 ist höchstinteressant: CSS811 korrelieren nur mäßig miteinander, BME680 misst ganz anders.
Jedenfalls ein guter Blick auf die Verlässlichkeit der Messwerte.

Zwei Dinge sind mir noch klar(er) geworden:
Die "Nullinie" im Betrieb passt der Sensor von sich aus automatisch an, schleichende Kurven sind also normal. Eben habe ich ganz schleichend im Normalbetrieb wieder ein TVOC = 0 erreicht. Kein Reset
Und für den Betrieb des Sensor selbst sind nun einmal beträchtliche Temperaturen erforderlich.

Danke bis hierher, ich hoffe ab jetzt komme ich alleine klar ... 

edit (statt nachgeschobenen Beitrag):
Die Deaktivierung der Rule und die Ansteuerung aus FHEM scheint den Durchbruch gebracht zu haben. Den letzten Reboot wegen Blocked Loop hatte ich vor 9 Tagen.
Und die Kurven werden immer besser und ruhiger - und die Werte normalisieren sich im <1000er Bereich.

[JHo]

Hallo Pfriemler,

hätte ich das gute Stück damals nicht nach Kauf erstmal ewig auf Halde gelegt (bis gestern), hätte ich mich wohl gleich am Thread beteiligt.
Ich habe mich ein wenig abgemüht, das Teil in den WLAN-AP-Modus zu bekommen, irgendwie wollten die Switches nicht so wie ich. Hat letztlich aber doch funktioniert, wie auch das Einbinden mit MQTT2 in FHEM. Alles wunderbar. Vor dem Kauf habe ich mir (zu?) wenig Gedanken über Sinn und vor allem den zu messenden Ort gemacht und kann daher mit den Werten, die der Sensor ausspuckt, noch überhaupt gar nix anfangen. Also noch viiel zu lesen für mich.

Um zumindest schonmal die FHEM- bzw. Tasmota-technische Seite gebacken zu bekommen, kannst du mir vielleicht mit deinen Erfahrungen und Einstellungen weiterhelfen:

• Die Werte werden über MQTT in FHEM deutlich seltener aktualisiert, als die Anzeige im Tasmota-WebIF. Normal, eine Folge des "sleep 50" aus locutus' Tipps im Verkaufsthread, oder...? (exakt alle 10 Minuten, habe kein event-on-irgendwas gesetzt)
• Verstehe ich das richtig, dass jeder Stromverlust ohne Pufferbatterie den 48-stündigen Burn-In zur Folge hat?
• Hast du die Regel für die LED-Farbe von hier

  
  rule1 on CCS811#eCO2<600 do color 00007F endon on CCS811#eCO2>600 do color 005F7F endon on CCS811#eCO2>800 do color 007F5F endon on CCS811#eCO2>1000 do color 007F00 ndon on CCS811#eCO2>1500 do color 6F7F00 endon on CCS811#eCO2>2000 do color 7F7F00 endon on CCS811#eCO2>3000 do color 7F5F00 endon on CCS811#eCO2>4000 do color F0000 endon
  und noch mit
  rule 1
  aktivieren - fertig ist die Farbskala  ... Die Sensorwerte sind recht hoch, bei 5000 müsste ich ja tot umfallen, aber ich fühle mich wohl...
  Was mir jetzt noch nicht gefällt: jede Farbänderung erzeugt einen write flash. Das muss noch besser gehen...
  

  nochmal überarbeitet bzw. (dein letzter Eintrag vom 1.10.) eine FHEM-Regel stattdessen erstellt? Wie sieht die aus?

Danke!
Jan

[Pfriemler]

kurz von unterwegs:
Rules nach wie vor deaktiviert. LED-Farbe wird von Fhem aus gesetzt.
Die Häufigkeit der Aussendung von Sensordaten regelst Du mit der telemetryPeriod (oder so ähnlich). Setzt Du am besten von der Kommandozeile in Tasmota. Es gibt hunderte Stellschräubchen!
sleep 50 hat damit gar nichts zu tun und ist in neueren Tasmotas eher obsolet.
Ja, auch ich sehe einen erneuten Burn-In nach Stromausfall. Deswegen ist die Pufferbatterie hilfreich.
Ich hatte in den letzten Monaten einen Reboot aus ungeklärter Ursache, teilweise größere Schwankungen, aber irgendwas in meinem PC mieft tatsächlich arg ... Netzteil?

[Prof. Dr. Peter Henning]

Ich hatte diesbezüglich einen eigenen Thread aufgemacht, weil ich diesen bisher nicht gesehen hatte. Also hier noch einmal mein Anfangspost:

Ich habe zwei der Air Quality Sensoren von locutus in Betrieb genommen (siehe https://forum.fhem.de/index.php/topic,95803.0.html).
Der verwendete Sensor ist ein CCS811 von AMS (das ist der Laden, der gerade Osram übernommen hat - bei guten Nerven konnte man damit 10% Gewinn aus den Osram-Aktien erlösen...)

Leider hat die Firmware aber noch einen Fehler, den ich bisher nicht lokalisieren konnte. Nach einem nicht konkret vorhersagbaren Zeitraum, in der Regel einigen Stunden, hauen die Messwerte für CO2 und TVOC (total volatile organic compounds) nach oben zu unrealistischen Werten hin ab. Und zwar parallel beiden zu Testzwecken unmittelbar nebeneinander betriebenen Sensoren, siehe Bild.

Durch einen Reset lassen sie sich wieder einfangen (siehe Bild kurz nach 17:00), aber eben nur begrenzte Zeit.

Aus der Funktionsweise der Sensoren - die zu messenden Moleküle werden in Zwischenräume eines porösen Metalloxids adsorbiert - nehme ich die Vermutung, dass die Sensoren nicht in regelmäßigen Zyklen ausgeheizt werden.


Update:

Gestern (5.1.) liefen die Sensoren stabil bis ca. 8:00 (Aufstehzeit, ich musste zum Landesparteitag...). Danach ziemlich wilde Werte. Um ca. 10:15 haben beide Systeme sich selbst neu gestartet. Danach kurz sinnvolle Werte, dann haute es richtig ab. Nach 22:00 habe ich sie noch einmal zurückgesetzt.

Heute Nacht (5.-6.) sind beide Sensoren ebenfalls stabil durchgelaufen. Natürlich - wie immer - mit fast gleichen Absolutwerten. Witzigerweise scheint die Temperaturkompensation nicht optimal zu sein, daher die zyklischen Schwankungen im zweiten Bild. Die Messwerte steigen immer an, wenn der danebenliegende Heizkörper warm wird. Bei den TVOC-Werten kann ich das noch verstehen, bei CO2 sollte das aber nicht der real sein.

LG

pah

[locutus]

Falls jemand an einem Firmware Update für den CCS811 interessiert ist:
https://github.com/maarten-pennings/CCS811/tree/master/examples/ccs811flash

Ein CCS811 mit Firmware Ver. 2.0.x sollte auf jedem Fall ohne den NTC-Widerstand betrieben werden:
https://forum.fhem.de/index.php/topic,28905.msg1052750.html#msg1052750

[ucm73]

Hallo zusammen, bei funktioniert der Sensor leider (ebenfalls) nicht stabil.
Zunächst war alles gut.
Dann zeigte er nach kurzer Laufzeit (einige Stunden bis max. 2 Tage) dauerhaft sinnlose (hohe) Werte.
z.B.: TVOC und eCO2 über 20.000
Neustarten/ geändertes Netzteil/ andere Position hat zu keiner dauerhaften Veränderung geführt.
Mein CCS811 hatte bereits die neue Firmware und da ich ein Board V2 mit ESP-M1 Modul habe, wurde, wie empfohlen, der R12 (NTC-Widerstand) ausgelötet.
Auch verschiedene Tasmota Versionen haben zu keiner Änderung geführt.
Hat jemand noch eine Idee?
Besten Gruß