Die Limits sind die Annahme das der Widerstand irgendwo zwischen 50kOhm und 500kOhm liegt und der Bezug auf gas_reference was den Mittelwert von zehn Messungen abbildet.
Meine Erwartung wäre gewesen, dass der jetzt gemessene Wert in ein Verhältnis zum Mittelwert gesetzt wird. Bei der Luftfeuchtigkeit passiert das zumindest:
Ich habe den Code von hierum ein bischen UDP Senden erweitert und nehme die Werte dann im IPS an.
Ich habe das Gefühl, dass die Messrate viel höher sein muss und der Sensor extrem empfindlich ist.
Aktuell messe ich alle 3 Sekunden, angelehnt an Tabelle 13 (low power mode) im Bosch Dokument und berechne mir als Baseline in IPS den Median über die letzten 100 Werte.
Damit erhalte ich eine stabile Luftgüte in Prozent, die sehr schnell auf Aftershave reagiert und auch schnell wieder auf den Normalwert kommt, im Vergleich zum MH-Z14 deutlich besser.
Vermutlich wäre die schnelle Messung alle 3 Sekunden und die Medianbildung auf dem PI sinnvoll und dann alle 60 Sekunden eine Werteübermittlung, damit nicht so viele Daten durch’s Netz geschoben werden.
Update:
Ich habe die Formel falsch umgesetzt und hatte den gas_offset immer negativ, dadurch wurde beim Baseline meistens
$gas_score = 100 - ($hum_weighting * 100);
genutzt, also 75, da hum_weighting auf 0,25 steht.
Interessanterweise reagiert der Sensor bei Veränderungen (anblasen, Deo, …) extrem schnell.
Berücksichtigst du die Formeln aus Kapitel 3.4.1 und Tabelle 12 in deinem Ohm-Wert?
Aber genau das ist z.B. eines der Punkte die auch an anderer Stelle bemängelt werden:
Die Werte in der Tabelle (im Datenblatt ist das Tabelle 12) sind selbst in der Umsetzung von Bosch anders als im Datenblatt, warum weiß ich nicht, habe mich aber auch dabei an die Umsetzung von Bosch gehalten, andere haben diese ebenfalls übernommen.
Was meinen Test angeht, so wechselt die Bewertung der Luftqualität zwischen den beiden schlechtesten Bewertungen. Nun mag das an dem Raum liegen in dem mein Testaufbau installiert ist, halte es aber für deutlich zu schlecht bewertet, ohne „echte“ Referenz aber nur ein Gefühl…
Danke für die Info, ich hatte mir dann gestern auch den Quellcode angesehen.
Die Formel ist anders wie die im Kapitel 3.4.1, das PDF ist leider geschützt und ich kann nicht kopieren.
Anders wie in #663 geschrieben, berechne ich inzwischen wie folgt:
Alle 3 Sekunden messen, den Mittelwert von 20 Werten als „Gas“ und den Mittelwert von 100 Werten als Baseline. Damit erhalte ich relativ stabil Werte, die bei optimaler Luftqualität (gemäß MH-Z14) etwas pendeln zwischen 94 % und 97 %. Der MH-Z14 pendelt aber auch zwischen 565 ppm und 575 ppm, der misst aber auch seltener.
Die Reaktion des BME680 auf „schlechte Luft“ ist sehr schnell, unter 1 Minute und bei entsprechender Belüftung nach ca. 15 Minuten wieder auf dem Anfangswert. Der MH-Z14 benötigt ca. 30-40 Minuten bis er wieder auf dem Anfangwert ist.
wie ich schon sagte, das Datenblatt - was ich hier auch vorliegen habe - und der Beispielcode sind nicht immer gleich, zumindest ist es an einigen Stellen die andere Vorgehensweise nicht so trivial nachvollziehbar.
Neulich habe ich mich ja mit dem BMP180 beschäftigt, dort sind die Erläuterungen zur Funktionsweise noch sehr detailliert, diese nimmt mit dem Datenblatt des BME280 ab und im BME680 fehlen ganze Teile einfach…
Im Übrigen habe ich ja oben bereits meine Verwunderung über die Vorgehensweise bei der jetzt verwendeten Methode zum Ausdruck gebracht. Meine Erwartungshaltung wäre auch eine Relativierung zwischen einem „Basiswert“ und den aktuellen Messwerten gewesen, leider findet das so nach dem Code nicht statt.
Der Ansatz mit dem Mittelwert über 20 Werte bei 3 Sekunden Messzyklus und Baseline über 100 Werte scheint ganz gut zu passen. Leider läuft mein zurechtgepfuschtes C-Programm nicht stabil und stürzt häufiger ab, aber folgende Verläufe zeigen die Werte bzw. Abweichungen ganz gut.
Der Raum war den ganzen Tag gut belüftet, es war niemand drin und hat die Luft verpestet. Die Sensoren liegen direkt unterhalb der Zuluftöffnung :).
Die Sensoren liegen direkt unterhalb der Zuluftöffnung .
Und du weisst, was da rein kommt ?
Ich habe immer noch die IAQ2000 am laufen, und da kommen oft mal komische Werte, wenn die Zuluft (Fenster) offen ist, aber das riecht man teilweise.
Der IAQ2000 hat zum Vergleich der IAQ Engine gleiche Werte ich Raum gehabt, daher würde ich den BME680 damit vergleichen wollen, um zu sehen was passiert.
Ich muss mir mal nen 680er besorgen, wenn mal viel Zeit ist.
Und nein Ralf, neue Sensorik wird nicht mehr am LCN (IX) bei mir laufen.
Bei Nutzung des Raumes, hier duschen, also deutlich erhöhte Luftfeuchtigkeit, reagiert der BME680 etwas langsamer als der MH-Z14, aber der Normalwert wird schneller wieder erreicht, was auch der „gefühlten“ Luftqualität entspricht.
Ich werde noch ein wenig mit der Anzahl der jeweiligen Werte bei den Mittelwertbildungen spielen, um eventuell eine schnellere Reaktion zu erreichen.
In Summe gefällt mir der Lösungsansatz sehr gut, gerade auch im direkten Vergleich zum MH-Z14.
wie Du auch in der Auflistung auf Seite 1 siehst, ist dieser (noch) nicht dabei. Selbst wenn, wäre es für mich nicht möglich dann eine Nutzung mit meinem Modul zu gewährleisten.
Der PCF8574 wäre da eine Möglichkeit der schon integriert ist.
Darüber hinaus wäre auch der Einsatz der I/O-Module von GeDaD möglich, die entsprechenden GeCoS-Module für In/Out könnte ich relativ schnell hier integrieren. Basis ist dort der PCA9655E.
Noch ein wichtiger Hinweis zur Nutzung von Eingängen: Diese sind nicht immer gut geeignet um zeitkritische Prozesse abzubilden. So würde ich diese z.B. nicht empfehlen um Taster in der Verbindung mit Beleuchtung zu verwenden. Die Zeit die der Taster betätigt werden muss - auch wenn er sich im ms-Bereich bewegt - „fühlt“ sich schon „ungewöhnlich“ an.
Habe seit ein paar Wochen Dein Modul im Einsatz (Raspi 3). Bisher lief alles Prima.
Heute habe ich das Modul aktualisiert, um die L298N Motorsteuerung zu testen.
Seit dem kann ich keine GPIO-Ports mehr setzten.
Warning:
Warning: socket_connect(): unable to connect [10061]: Es konnte keine Verbindung hergestellt werden, da der Zielcomputer die Verbindung verweigerte.
in H:\IP-Symcon\modules\SymconModules\IPS2GPIO\module.php on line 1467
RESULT: in H:\IP-Symcon\modules\SymconModules\IPS2GPIO_Output\module.php on line 148
Warning:
Warning: socket_connect(): unable to connect [10061]: Es konnte keine Verbindung hergestellt werden, da der Zielcomputer die Verbindung verweigerte.
in H:\IP-Symcon\modules\SymconModules\IPS2GPIO\module.php on line 1467
RESULT: in H:\IP-Symcon\modules\SymconModules\IPS2GPIO_Output\module.php on line 148
Die Temperaturmessung per 1Wire klappt einwandfrei.
Habe den Raspi (Jessy) upgedatet / rebootet leider ohne Erfolg .
Was könnte ich noch versuchen ??
…bin noch unterwegs, daher wird es noch ein bisschen dauern.
Wenn Du auf dem entfernten Raspberry Pi mal „top“ laufen lässt, dann siehst Du ja ob PIGPIO läuft. Zum anderen solltest Du die Meldungen im IPS mal im Auge behalten.
Wenn PIGPIO sich selbst beendet, wird es vom Modul eigentlich wieder gestartet. Irgendwie passiert das bei WLAN aktuell öfters, gibt schon einige in diesem Thread die darüber berichtet haben. Einen Raspberry habe ich auch so angebunden, da passiert das leider auch öfters…[emoji17]
…was passiert denn, wenn Du PIGPIO „manuell“ startest? Gibt es eine Fehlermeldung? Was steht in den Meldungen? Was ggf. interessantes im Debug des Splitters?
Ich kann hier so im Skript erst einmal keinen Fehler feststellen… (was ja nicht immer etwas zu bedeuten hat… )
)