In den wirklich sehr komplexen Berechnung für den Gas-Widerstand (der gesetzt wird um die Temperatur zu erreichen!) fließt lediglich die Umgebungstemperatur ein. Man kann da laut Datenblatt die Temperatur nehmen die der Sensor selbst gemessen hat oder eine konstante Annahme der Umgebungstemperatur einsetzen. daraus würde ich mal schließen, dass es insgesamt wohl nicht so relevant ist: amb_temp is the ambient temperature (hardcoded or read from temperature sensor)
In die Berechnung des Ausgangswertes geht nichts dergleichen ein…
anbei ein erster Vergleich der Widerstandswerte von BME680 und iAQ-Core. Ähnlich sind die Kurven in manchen Bereichen schon, aber die Peaks nach oben und unten sind sehr seltsam. Ich habe die im Graph mal rosa eingekringelt.
Werde weiter Daten loggen und versuchen eine Muster zu finden. Machen die bei FHEM auch gerade so. Echt blöd, hat etwas von Reverse Enginieering.
bitte einmal manuell das Variablenprofil „IPS2GPIO.ohm“ bei den Float-Variablenprofilen löschen.
Dieser Fehlermeldung resultiert aus der Umstellung bzw. Doppelbelegung von IPS2GPIO.ohm als Integer (vom iAQ) und als Float für den BME680 (Fehlermeldung die Bernd gepostet hatte). Ich habe es jetzt aber in der Visualisierung beim BME auch auf Integer umgestellt.
Ja, ihr habt Recht nach direktem Neustart des raspi w bleiben die Relais aus. Sobald aber symcon die Verbindung wieder aufnimmt schalten nacheinander alle auf ein.
Ich habe auch eine Probe aufs example gemacht und einen Output in IPS deaktiviert. Der bleibt dann auch aus.
Ich vermute schon stark dass dieses Verhalten an sich nichts mit IPS zutun hat, sondern IPS konfiguriert den GPIO bei jedem reconnect neu auf ausgang. Und ich vermute PIGPIO setzt den Ausgang dann automatisch auf High.
zunächst einmal das Betriebssystem des Raspberry Pi selbst auf den Zustand, danach startet PIGPIO das ohne weiteres selbst dann aber nichts mit den Zuständen der GPIO anstellt.
Irgendwo in diesem Thread habe ich schon mal auf diese Frage geantwortet, auch mit einer Tabelle, wie der Startzustand ist - auch was die Startdefinition ist in Hinblick auf Input oder Output.
Wenn IPS und dann das Modul in Aktion tritt, wird zunächst der GPIO als Output definiert, im zweiten Schritt dann gesetzt.
Es läuft übrigens seit heute morgen derselbe pigpiod, also kein Neustart, trotz WLAN und aktuell eher schlechter Verbindung am aktuellen Standort.
Der BME280 ist nicht angeschlossen, der BME680 läuft nicht, nur 1 x 1wire Temperatur und die ohne Probleme. Meine Vermutung mit den Restarts ging schon in die Richtung BME/I2C. Teilweise hängt die Konsole zum PI und es dauert ein paar Sekunden, bis ich wieder tippen kann.
Der PizeroW ist „standard“ installiert und nur mit pigpiod, sonst nichts weiter drauf.
Die Ohmwerte springen ziemlich, aber es kommen welche, dann soll er sich erstmal einpendeln. Ich lege den PI mal zu einem MH-Z14, der liefert direkt ppm ;). Dort liegt auch noch ein MQ135 zum Vergleich.
lass das mal min. 2-3 Tage laufen, vorher kommt bei fast allen CO2-Sensoren nur Zick Zack. Hängt irgendwie mit den hohen Temperaturen und metallischen Membranen zusammen (bin kein Chemiker), die sich thermisch erst zurecht rücken muessen.
Ich bin die nächsten Tagen auf Dienstreise und komme wenig dazu auf die PIs zu schauen. Mal schauen, eventuell werfe ich später doch noch nen Openvpn-Tunnel nach zuhause an.
Zum I2C noch ein Tipp. Mit „i2cdetect -y 1“ kannst du auf der Shell nachsehen, welche HEX-Adressen auf dem Bus sind. Der BME280 und BME680 belegen default normal 0x76 und kommen sich dann in die Quere. Am besten jeden einzeln mal an den Bus hängen und prüfen. Bei vielen Breakouts kann man durch Lötbrücken oder CS auf 0 die Adresse auf 0x77 ändern.
Hallo Joachim,
erstmal vielen Dank für das tolle Modul.
Wie Ralf auch schon vor längerer Zeit berichtet hat, wird im BT-Modul der Status Summary nicht auf off gesetzt wenn kein BT Gerät mehr erreicht wird. Könntest du da nochmal nachschauen.
Habe jetzt auch versucht, meinen Gigaset G-tag und meine Smartwatch mit dem BT-Modul zu erfassen. Diese beiden Geräte werden jedoch nicht erkannt. Wenn ich bei dem Raspi mit dem Befehl bluetoothctl in der Komandozeile nach BT-Geräten scanne, werden sie dort auch gelistet. Woran könnte das liegen?
werde ich mir mal anschauen, hatte - wohl fälschlicherweise - angenommen, dass sich das erledigt hat…
@Bernd und Ralf:
Gibt es schon Abschätzungen zu Minimal- und Maximalwert der „gültigen“ Messung? Wäre zwischen 50 und 70kOhm eine realistische Abgrenzung? Bei der ersten Messung werden offenbar sehr hohen Werte zurückgegeben (hier so um und bei 200kOhm).
Habe mich in den letzten Stunden/Tagen mit dem Einsatz des MUX beschäftigt, da war doch noch einiges im Argen, jetzt scheint es aber zu laufen… BME280 und BME680 sind jetzt nebeneinander an einem „Test-Pi“ mit der gleichen Adresse, nur an anderen Kanälen des MUX.
Die Temperaturen sind sehr ähnlich, Luftfeuchtigkeit liegt beim BME680 ca. 10% über dem Wert des BME280, beim Luftdruck liegt der BME680 immer ca. 10hPa über dem BME280.
Habe beide Berechnungen noch mal intensiv mit dem Treiber von Bosch selbst abgeglichen, sollte so in Ordnung sein. Was mir fehlt ist etwas das als Referenz dienen könnte…
in dem Vergleichsdiagramm bei mir liegen die Min/Max Werte für den BME680 so zwischen 55 und 95 kOhm. iAQ-Core zum Vergleich zeigt großteils ähnlichen Kurvencharakter, aber an einigen Stellen sieht es sehr unterschiedlich aus.
Zu den Temperaturen kann ich sagen, dass sie sich bei mir zwischen BME280 und BME680 relativ konstant um 0,4 Grad unterscheiden. Beim Luftdruck sind es ~8 hPa. Ob der direkte Vergleich so aussagekräftig, kann ich nicht sagen, die beiden Sensortypen haben sicher auch eine gewisse Streubreite.
Der interessante und wichtige Punkt der Umrechnung von Gas-Widerstandswert in CO2/ppm bleibt natürlich.
