das wird sicher spannend. Den Ohm-Wert kriegt man ja gut ueber I2C ausgelesen. Für die Umrechnung in CO2/ppm macht Bosch scheinbar ein Staatsgeheimnis. Im FHEM-Forum arbeiten die schon intensiv dran, haben aber auch noch keine Lösung. [Link: https://forum.fhem.de/index.php/topic,78619.0.html]
Das Geschäftsmodell von Bosch mag verstehen wer will, aber Teile der eigentlichen Chip/Sensorsoftware (Umrechnung Ohm in CO2/ppm) in ihr BSEC-Softwaremodul auszulagern wird sicher kurze Beine haben. Na ja, die Chinesen haben Bosch mit BME/P280 Nauchbauten sicher ganz schöne geärgert.
Auch im FHEM-Forum diskutiert man darüber, den BME680 längere Zeit parallel zum iAQ laufen zu lassen und dann eine empirische Übersetzungstabelle aufzubauen. Traurig, traurig.
Ich habe angefangen die eingelesen Daten entsprechend zu verarbeiten. Aber das Datenblatt ist da - obwohl um die 50 Seiten Papier - sehr „grob“ unterwegs. Beispielsweise steht im Datenblatt nichts von Kalibrierungsdaten, in dem Beispiel-Skripten findet man jedoch eine Verarbeitung dieser. Ich muss mich da dann an das Skript-Beispiel halten, eine Verifizierung über das Datenblatt ist aber dann nicht möglich.
Ich hoffe das der BME680 nun bald aus Slowenien eintrifft, erst dann kann ich den geschriebenen Code zumindest auf Syntax-Fehler Plausibilität prüfen…
kurze Sachstandsmeldung:
Heute kam der BME680 aus Slowenien an, die PinHeader angelötet und in Betrieb genommen.
Der PHP-Code brachte schon mal keine Syntaxfehler, so weit er gediehen ist, werden die Kalibrierungsdaten und die Messdaten erst mal plausibel geholt.
Leider kann man mit denen noch nicht so viel anfangen, als das da etwas sinnvolles rauskommt, der Trigger zum Start der Messung fehlt noch, kümmere ich mich als nächstes drum. Wenn das klappt sollten Temperatur, Luftdruck und -Feuchtigkeit erst einmal laufen, danach werde ich mich dann um die Luftqualität kümmern - Step-by-Step…[emoji6]
das Modul startet ja den pigpiod neu, vermutlich, wenn es Probleme feststellt.
Wann, warum, wie oft, … :D?
Mein Test PIzeroW hängt sich häufiger auf bzw. liefert keine Daten mehr. Bei einer Analyse heute kam der Prozess innerhalb von ca. 5 Stunden von PID 422 (reboot) auf PID 27601. Ich vermute, er wurde sehr oft neu gestartet.
ein Verhalten das ich hier auch schon beobachtet habe - aber bisher nur über WLAN-Anbindungen.
Ich Joan das hier schon mal mitgeteilt habe.
Gerade gestern habe ich einen Test gemacht:
Raspberry Pi 2 mit einer PWM-Steuerung und einem DS18B20 über DS2482. Über WLAN-Anbindung ständige (aber unregelmäßige) Abbrüche, obwohl dieses m.E. nicht durch die WLAN-Anbindung selbst verursacht wird, da der Access-Point knappe zwei Meter entfernt ist und der Raspberry per SSH durchaus erreichbar ist…
Dann ans LAN angeschlossen, bisher keine Abbrüche…
Wenn die Konstellation bei Dir ähnlich ist und Du einen Github-Account Dein eigen nennst, würde ich Dich bitte in dem oben verlinkten Forum Deine Erfahrungen ebenfalls zu teilen…
Scheinbar habe ich Stress mit dem BME280, der lieferte immer mal wieder keine Daten. Ich dachte, die Verdrahtung ist „etwas wackelig“, also angelötet. Beim Initialisieren der Instanz gibt es Werte, aber komische, z.B. 708,9 hPa, danach kommt nichts mehr. 1-wire liefert fröhlich weiter.
Jede Instanz (= fast jeder Zugriff auf das Modul) baut eine neue Socket-Verbindung auf, seitens IPS wird die geschlossen, aber leider nicht seitens PIGPIO Je nach Traffic ist PIGPIO irgendwann „dicht“ und Antwort mit der Fehlermeldung 11 des Sockets. In dem Fall läuft PIGPIO zwar noch ist aber nicht mehr anspechbar, es erfolgt eine Neustart von PIGPIO.
Der andere Fehler ist der wie oben bereits geschrieben. Bei mir tritt er bisher nur in Verbindung mit WLAN auf, auch hier scheint es eine Abhängigkeit zum Traffic zu geben, je mehr Traffic um so wahrscheinlicher erfolgt nach meiner Beobachtung der „Absturz“ von PIGPIO. Aus dem Modul heraus wird PIGPIO dann neu gestartet. Auch Axel konnte dieses so beobachten, meine Tests mit dem Raspberry Pi 2 stützen diese These.
Ich hätte mr gewünscht, dass Joan (PIGPIO-Entwickler) da mal in irgendeiner Form darauf reagieren würde…
hatte mir heute mal dein Moul angeschaut, wegen der Vaillant Geschichte.
Ist schon gut gemacht, Hut ab, aber für mich leider so nicht nutzbar.
GPIO mache ich mal lieber direkt weiter, da bei mir sowiso alles auf einem Pi ist.
Dabei ist mir aber noch ein Tippfehler bei „ReturnTemperature“ aufgefallen, such mal nach „ReteurnTemperature“ im Modul…
vielen Dank für die Blumen und den Hinweis, habe die „too much fingers on keyboard error“ korrigiert…
Das Modul muss ganz sicher noch wachsen - die eine oder andere Idee ist schon im Kopf aber noch nicht im Modul - , kämpfe nur gerade mit dem BME680 und mein Heizungsmensch war immer noch nicht da…
…ist doch immer wieder peinlich - so gleich zum Einstieg…:rolleyes:
Also, Bernd Fehlermeldung resultierte daher, dass ich das Profil IPS2GPIO.ohm zweimal verwendet habe. Einmal beim iAQ (den ich selbst nicht habe) und hier im BME680, nur einmal als Float und das andere mal als Integer. Sollte behoben sein…
Die Wirkung bei Ralf’s Fehler ist klar, die Ursache etwas komplexer…
Gleich wohl meine ich auch dieses korrigiert zu haben - Aber Achtung, kann es selbst erst heute Abend testen!
die Werte vom BME680 kommen jetzt in IPS an. Ich lasse sie jetzt alle mal mit loggen und werde sie dann auf Plausibilität checken. Spannend wird es natürlich beim Widerstandswert. Da fehlt ja immer noch die Umrechnungsformel in ppm von Bosch. Die verstecken sie ja in ihrer compilierten Lib.
…hinsichtlich der Gasmessung noch mal ein paar Gedanken:
Zur Gasmessung ist mit einstellbaren Parametern durchführbar:
Messungstemperatur: 200 - 400 °C
Messungsdauer: 0 - 4032 ms
In dem Treiber (Testskript) von Bosch selbst ist hier 320 °C bei 150 ms Messdauer vorgesehen.
Ich vermute daher, dass die eingestellten Parameter auch eine Wirkung auf den daraus resultierenden Widerstand hat - neben der vorhandenen Gaskonzentration.
Um im Vergleich zum iAQ zu ähnlichen Ergebnissen zu kommen könnte es also sein, dass Messtemperatur und -dauer dort relevant sind!
Zum anderen ergibt sich daraus m.E. auch, dass die angestrebte „Vergleichstabelle“ (Widerstand <-> Luftqualität) auch impliziert, dass bei der Messung die selben Einstellungen für diese beiden Parameter erforderlich sind.
Daher folgender Vorschlag:
Durch Anpassung von Dauer und Temperatur sollte (Bernd ) versucht werden, eine möglichst große Annährung an die Messung des iAQ zu finden
Die verwendeten Parameter wären dann im Konfigurationsformular nicht mehr anpassbar sondern als Konstante gesetzt
Die aus dem Vergleich resultierenden Abhängigkeiten (Widerstand <-> Luftqualität) würde ich im Modul dann nutzen um aus dem Widerstandswert auf die Luftqualität/Stufung zu schließen
Ich lasse das Loggen des BME680 und iAQ-Core jetzt mal eine Zeit laufen, bis es sich eingependelt hat. Dann kann ich ja versuchsweise an den Parametern drehen. Ich bin aber nicht ganz sicher ab man dadurch eine Annäherung der Kurven erreicht.
Ich vermute in die Umrechnungsformel von Widerstand nach CO2/ppm fließen mindestens Temperatur und eventuell auch Druck und Feuchte mit ein.
Ich werde heute Abend mal erste Graphs für Temp, Feuchte, Druck und Widerstand von BME280/iAQ-Core gegen den BME680 posten.
Ich möchte einen Raspberry Pi Zero W mit 4 Relais als Remote-GPIO nutzen.
Die Verbindung klappt soweit und ich kann schalten.
Leider schaltet der pi bzw. Symcon die Relais nach einem Reboot oder Reconnect alle auf AN.
Ganz egal, welchen Wert ich bei „Status des Ausgangs nach Neustart“ zuweise…
bei meiner Schaltung (Ich möchte die Garagentore schalten) ist das eher etwas dumm…
Ich habe zwar Wechsler-kontakte dran, aber ungewolltes Schalten bei einem reconnect bzw. neustart würde immer das Tor öffnen, (entweder beim Absturz des Pi, oder nach dem Reconnect.
…welchen Status der GPIO beim Start des Raspberry Pi hat, darauf hat weder IPS noch PIGPIO bzw. mein Modul Einfluss.
Du kannst es nur austesten und dann entsprechend handeln.
Andere Optionen ergeben sich ggf. bei der Nutzung von I2C-Komponenten…
Pullup oder Pulldown ist da entscheident.
Ev. muss man die Relais einfach anders verschalten.
Wenn der Pi neu startet, sollte auf jedenfall das Relais aus bleiben, und erst wenn ein Befehl von IPS kommt, sollte sich was tun.
