Habe von Sonntag Nachmittag bis Montag Nacht 591 Datensätze mit je 5x DS18B20 gesammelt.
Ausfälle, d.h. keine Daten / missings im Datensatz:
Sensor 1: 3x keine Daten (0,5 %)
Sensor 2: 14x keine Daten (2,4 %)
Sensor 3: 6x keine Daten (1,0 %)
Sensor 4: 11x keine Daten (1,9 %)
Sensor 5: 44x keine Daten (7,5 %)
Im Mittel sind das 2,6 % Ausfälle. Den BME habe ich leider erst bei der Hälfte der Daten zugeschaltet. Interessant ist, dass die höchste Abweichung hier nun 1,2 °C ist und es nach unten keine Abweichung gibt, d.h. die DS18B20 messen jetzt immer Werte ≥ BME. Ich messe jetzt aber auch im temperaturstabileren Keller, was die Ergebnisse verzerren kann!!
Für mich scheinen die Änderungen im code im Vergleich zur ersten systematischen Messung oben etwas verläßlichere Werte zu liefern, allerdings ist der drop out mit bis zu 7% absolut indiskutabel!
Ja, dass man den onewire-Bus aus pure-Python heraus ansteuert, ist eigentlich genau dies: Indiskutabel. Wir können echt froh sein, dass wir die dadurch vermutlich zwangsläufig auftretenden Glitches nun endlich durch die CRC-Checks im Griff haben.
Der bme und der Hx711 arbeiten derzeit absolut ohne Probleme.
Die Bme sind auch vorher problemlos gelaufen und die hx hatten nur alle Paar Tage einen Fehlwert.
Habe jetzt nochmal an Clemens Panel nachgelegt.
Jetzt werden dort auch die Anzahl der Werte der DS Sensoren angezeigt.
allerdings kann man mit meiner Formel leider nicht eine zu große Zeitspanne wählen, da dann die Werte mehrer Messungen addiert werden.
Man sieht die Anzahl der uploads / Datensätze und die Anzahl der übermittelten DS18B20-Sensoren, wenn es 6 sind werden alle korrekt gelesen und hochgeladen, wenn es 5 oder weniger sind nicht. Pfff … ja, keine Ausreißer mehr, aber eine ganze Menge verworfener, da falscher Messungen.
Ich würde der genauen Ursache dafür gerne auf die Spur kommen. Die Wahrscheinlichkeit ist hoch, dass es am 1-wire Treiber liegt, der leider vollständig in Python implementiert ist. Innerhalb dessen, was da im SDK steckt, waren solche Ergebnisse fast zu erwarten.
Falls CRC nicht passt, nochmal messen, begrenzt auf maximal 5x damit wir nicht uferlos in eine Schleife kommen. Das kostet uns dann max. gut 5 Sekunden Zeit und Strom für 5 Sekunden ohne deep sleep.
Vielleicht kommen wir auch günstiger bzgl der Zeit weg und müssen die Messung nicht neu anstoßen, sondern nur den Wert nochmal vom Sensor holen, weiß nicht, wo das timing schief läuft. .
Absolut. Für mich ist hier mit dem aktuellen Stand das korrekteste erreicht, was hier zu erzielen ist. Workarounds halte ich für keine gute Idee.
Da könnte schon noch weiter geforscht werden, ja. Da wir aber bereits so viel Zeit reingesteckt haben und nun ja absolut korrekt unterwegs sind, sehe ich weitere Arbeiten daran nicht als Bestandteil der Version 0.6.0.
Solange die Probleme mit dem Onewire- und/oder DS18B20-Treiber nicht gelöst sind, sollte man auf jeden Fall versuchen, fehlerhafte Messwerte zu erkennen, sei es durch CRC-Check oder Messwert-Toleranzen. Als Workaround würde ich im Fehlerfall den alten Wert übernehmen, denn die Temperatur kann sich gar nicht sprungartig verändern.
Ich werde meine BOB-Sensoren noch einmal an einem Raspi testen. Da sind mir solche Messwert-Ausreisser nur beim HX711 aufgefallen.
Wäre nicht eine Lücke oder null-Value deutlich sinnvoller? Lücken kann auch das Flux im Grafana (oder welche-Software-auch-immer) mit dem jeweils letzten Wert füllen (wenn einem die etwas längere Linie zwischen zwei Punkten doll stören sollte); aber nen alten Wert mit nem neuen Timestamp (schon in der Datenbank) zu versehen klingt in meinen Augen wesentlich unsauberer als ehrlich keinen Wert zu haben. (Wir wissen ja an genau diesem Punkt schon, dass der Wert nicht richtig ist.)
Vielen Dank für den Support, so sehe ich das an dieser Stelle derzeit auch und das ist nun auch der aktuelle Softwarestand.
Für mich bedeutet das absolut das höchste der Gefühle innerhalb des aktuellen Schlamassels, da die Firmware nun nach diesem aktuellen Stand absolut keine Glitches mehr in den Messungen zu produzieren und daher ausschließlich korrekte Werte zu liefern scheint – zumindest bezogen auf die Probleme beim Auslesen innerhalb der digitalen Sensordomäne, die uns lange Zeit plagten.
Jegliche Workarounds würde ich weiterhin sehr ungerne an dieser Stelle einbauen.
discodoc und Terkin 0.6.0 rufen laut nach Buschfeuerlöschung, daher muss ich kurzfristig weiterreiten und würde gerne erst bei der nächsten Gelegenheit wieder auf Optimierungen in diesem Bereich zurückkommen.
Sehe es genauso wie @wtf – bloß nicht beschönigen!
Das kann man später sonst nicht mehr nachvollziehen, wenn es einmal darauf ankommen sollte.
Grafana oder Beep kommen sehr gut damit zurecht.
Wenn man größere Messabstände in Betracht zieht, um Strom zu sparen, muß man auf alle Fälle – wie @clemens vorgeschlagen hat – die Messung des Sensors wiederholen. Eine Fehlermeldung dass ein Wert nicht gelesen wurde, gibt die Firmware bereits aus. Da sollte es kein Problem sein, sie dort nochmal zu versuchen auszulesen.
