Kann mir bitte jemand erklären was ich machen muss, damit die Sensorwerte der beiden BME680 stimmen? Luftfeuchte rel., Taupunkt und Luftqualität sind doch irgendwie total daneben.
Ein BME280 zeigt mir dagegen plausiblere Werte an. Anbindung über PIGPIO. Sensoren sind auf Steckbrett nebeneinander und zeitgleich gemessen.
Vielen Dank!
Hallo pjotrweliki,
wichtig wäre zunächst das gleichzeitig (zeitgleich bringt da wenig) gemessen wird, ansonsten ist die Vergleichbarkeit nicht unbedingt gegeben. Der BME680 benötigt etwas Zeit um sich selbst zu kalibrieren. Wie lange sind diese denn schon an der Spannung, bzw. im aktiven Betrieb?
Ansonsten bitte mal schauen ob im Debug der jeweiligen Instanzen Fehlermeldungen auftauchen.
Joachim
Hallo JPaeper,
meinte natürlich gleichzeitig. Entschuldigung für die Verwirrung.
Die BME680 sind schon länger im aktiven Betrieb. Ich weiß, das der Luftgütesensor sich selbst kalibrieren muss. Aber selbst nach Tagen ändert sich nichts. Die rel. Luftfeuchte liegt ja auch mit 100% völlig daneben. Ich hatte mir erst ein BME-Modul gekauft und vermutete einen Hardwarefehler. Das 2. Modul ist von einem anderen Händler mit dem gleichen Problem.
Konfiguration ist bei Beiden bis auf Höhe über NN (25m) auf Default.
Anbei der Debug. Kann man da was erkennen?
BME280.txt (15,8 KB)
BME680_01.txt (19,9 KB)
BME680_00.txt (19,8 KB)
Hallo pjotrweliki,
die Debug-Ausgaben sehen erst einmal unauffällig aus…
Das mit dem hohen Wert bei der Luftfeuchtigkeit kommt mir irgendwie bekannt vor, kann das aber aktuell nicht zuordnen.
Die Daten werden nicht direkt aus dem BME680 gelesen, sondern in einem aufwendigen mathematischen Verfahren im Modul aus den Rohdaten berechnet.
Magst Du die BME680 mal ein paar Sekunden spannungslos machen und wieder in Betrieb nehmen?
Joachim
Hallo JPaeper,
ich habe um 13:26 Uhr die Leitung der Betriebsspannung beider Sensoren getrennt und dann wieder verbunden. SCL, SDA und GND blieben dabei verbunden.
Anbei der Debug bei diesem Vorgang.
BME680_00.txt (24,2 KB)
BME680_01.txt (24,2 KB)
Gibt es neue Erkenntnisse zum BME680?
Ich habe dann auch gleich das nächste Problem:
Nach der Umstellung von Jessy auf Bullseye (egal ob 32 oder 64 Bit) gibt es Fehler im IPS2GPIO_RPi.
Die Messung der GPU-Temperatur und der Spannung wird jeweils mit „0“ angezeigt.
Diese werden als Einzige im module.php mit Pfad (/opt/vc/bin/vcgencmd …) angegeben. Im Jessy gibt es bei mir diesen Pfad, in Bullseye nicht. Ich habe mal die Pfadangaben gelöscht, dann geht es bei allen Versionen.
Ist das so richtig, oder habe ich einen Denkfehler?
Leider passiert hier nichts, so gebe ich mir mal die Antwort zum Punkt 2 selber:
Auf einem frisch installiertem und mit Updates versehenem 32Bit oder 64Bit Raspbian OS existiert der Path mit der Datei /opt/vc/bin/vcgencmd nicht. Also kann das Modul IPS2GPIO_RPI auch nichts auslesen.
Erst nach einem „rpi-update“ werden diese erstellt. Allerdings ist „rpi-update“ unstable!
Selbst mehrere Male an verschiedenen Tagen ausprobiert. Während es mit dem 32Bit-OS gut ging, bootete das 64Bit-OS nicht mehr (Dateien aus boot.bak nach boot zurückspielen). Gestern bootete das System, aber die vcgencmd war korrupt und nicht ausführbar.
Bei einer funktionierenden sind höchstens Bugfixes drin, die bei dem nächsten regulären Release sowieso in der normalen /usr/bin/vcgencmd übernommen werden.
Fazit, die Zeilen:
$CommandArray[0] = „/opt/vc/bin/vcgencmd measure_temp“;
$CommandArray[2] = „/opt/vc/bin/vcgencmd measure_volts“;
gehören so:
$CommandArray[0] = „vcgencmd measure_temp“;
$CommandArray[2] = „vcgencmd measure_volts“;
Ein 64Bit-OS mögen einige Module so gar nicht. Hier mal zum Vergleich auf derselben Hardware(6xDS18B20, 4xI2C-Geräte, kein MUX, 1xDS2482:
Raspbian-OS-Versionen:
Linux version 5.10.63-v8+ (dom@buildbot) (aarch64-linux-gnu-gcc-8 (Ubuntu/Linaro 8.4.0-3ubuntu1) 8.4.0, GNU ld (GNU Binutils for Ubuntu) 2.34) #1459 SMP PREEMPT Wed Oct 6 16:42:49 BST 2021
Linux version 5.10.89-v7+ (dom@buildbot) (arm-linux-gnueabihf-gcc-8 (Ubuntu/Linaro 8.4.0-3ubuntu1) 8.4.0, GNU ld (GNU Binutils for Ubuntu) 2.34) #1508 SMP Tue Jan 4 19:51:16 GMT 2022
MfG
Peter
Hallo Peter,
ich habe leider keine Nachricht bekommen das es in diesem Thread weiterging, eben erst durch Zufall gesehen.
Wenn mir das was Du geschrieben hast mal ansehen und mich dann melden.
Joachim
Hallo Peter,
versuche darauf mal zu antworten:
$CommandArray[0] = „/opt/vc/bin/vcgencmd measure_temp“;
$CommandArray[2] = „/opt/vc/bin/vcgencmd measure_volts“;
gehören so:
$CommandArray[0] = „vcgencmd measure_temp“;
$CommandArray[2] = „vcgencmd measure_volts“;
Die Angabe ohne Pfad führt bei mir auf einem 32Bit Raspbian Buster auch zu einer identische Ausgabe wie mit Pfad. Vielleicht könnte man das allgemein „kürzen“? Ich habe keine Ahnung ob das allgemeingültig ist…
Bei den 1-Wire-Bausteine musste man ja ein bißchen tricksen damit man die Bausteine mit der 64-Bit-ROM-ID ansprechen kann - das scheint jetzt zum Problem zu führen…
Vermutlich müsste man im Modul abfragen ob man ein 32 oder 64 Bit System hat und die ganzen 1-Wire-Programmteile anpassen?
Die PiGPIO-Versionen ab 78 sollen auch mit 64Bit zurechtkommen, versuche dort mal bitte ein Update:
Joachim
Hallo Joachim,
Bis zum upgrade von Jessy auf Bullseye ging das bei mir auch. Aufgrund der 1Wire-Problematik habe ich dann ein frisches Bullseye aufgesetzt (inzwischen mehr als 15 Mal 32-Bit & 64Bit probiert) und damit dieses Problem „eingefangen“.
In Deinem Modul arbeitest Du ja 2 Zeilen tiefer auch ohne Pfad-angabe und das funktioniert ja einwandfrei.
public function Measurement_1()
{
If (($this->ReadPropertyBoolean("Open") == true) AND (IPS_GetKernelRunlevel() == 10103)) {
$this->SendDebug("Measurement_1", "Ausfuehrung", 0);
$CommandArray = Array();
// GPU Temperatur
$CommandArray[0] = "/opt/vc/bin/vcgencmd measure_temp";
// CPU Temperatur
$CommandArray[1] = "cat /sys/class/thermal/thermal_zone0/temp";
// Spannung
$CommandArray[2] = "/opt/vc/bin/vcgencmd measure_volts";
// ARM Frequenz
**$CommandArray[3] = "vcgencmd measure_clock arm";**
// CPU Auslastung über /proc/stat
$CommandArray[4] = "cat /proc/stat";
// Speicher
$CommandArray[5] = "cat /proc/meminfo | grep Mem";
// SD-Card
$CommandArray[6] = "df -P | grep /dev/root";
// Uptime
$CommandArray[7] = "uptime";
PIGPIO habe ich auch schon seit meinem Jessy auf Version 79.
I2C-Configuralor läuft ja auch noch Amok und zeigt alle Adressen an, die es gibt ohne das Geräte am Bus hängen…
MfG
Peter
Hallo Peter,
das Modul IPS2GPI_RPi habe ich dann kurzerhand mal angepasst. Bei mir in der 32Bit Buster-Version läuft das.
Bei 1-Wire wird das sicherlich aufwendiger, man sieht es ja schon an der angezeigten Adresse (die vielen „F“).
Bringt auch bei der I2C-Suche der Restart von PiGPIO nichts? (Button im Konfigurationsformulars des Splitters?
Joachim
Hallo Joachim,
Nein, glaube es mir. Ich habe alles bis zum geht nicht mehr probiert. Unendliche Male. Nutze 5 USB-Sticks + 1 SD-Karte. Heute ist der 3 Raspberry eingetroffen, damit ich alles parallel prüfen kann. Anhand meiner Screenshots kannst Du auch sehen, dass die Systeme zu unterschiedlichen Zeiten (& damit Neustarts) liefen.
Da ich von Softwareprogrammierung keine Ahnung habe, habe ich mir extra eine Anleitung geschrieben, um immer exakt die gleiche Vorgehensweise bei der Installation zu erreichen.
Installation RPI-Symcon neu.txt (5,8 KB)
Vielleicht solltest Du ja auch mal ein 64Bit-OS testen.
MfG
Peter
Hallo Peter,
magst Du mal bitte bei Gelegenheit die Debug-Ausgabe des Splitters posten? Insbesondere wenn Du im Konfigurator einen I2C-Device-Scan durchführst?
Joachim
Hallo Joachim,
anbei heute das funktionierende System mit 32-Bit-OS & rpi-update.
2022.01.10_32Bit-OS_rpi-update.txt (21,0 KB)
2022.01.11_64Bit-OS_rpi-update.txt (20,0 KB)
MfG
Peter
Hallo Joachim,
Bei Bullseye auch.
Hier noch der Debug vom 32Bit-OS ohne rpi-update.
2022.01.11_62Bit-OS_ohne_rpi-update.txt (23,5 KB)
MfG
Peter
Hallo Joachim,
hast Du das Ursprungsthema noch auf dem Schirm?
Hat das eigentlich jemals funktioniert? Ich frage, weil ich jetzt mal eine Symcon 4.4 probiert habe und da ging das auch schon nicht.
MfG
Peter
Hallo Peter,
selbstverständlich an der BME680 mal funktioniert. Wo man „tricksen“ musste war bei der Luftqualität weil Bosch - im Gegensatz zu den anderen Funktionen - die Berechnung nicht veröffentlicht hatte (habe da lange nicht mehr nach geschaut). Aktuell habe ich auch keinen im Einsatz.
Gleichwohl nutzte ich das Modul mit anderen Sensoren…
Joachim