@clemens: Kannst Du auf die Daten von @MKO noch die neulich von Dir erschlossene Grafana-Zauberei drauflegen, die optisch gut auf etwaige komplett fehlende Datensätze schließen lässt?
Als neues panel unten hinzugefügt, das zählt aber nur die uploads von “weight” pro Stunde! Keine Rückschlüsse auf fehlende DS18B20 o.ä., eher zum checken der Konnectivität.
Habe von Sonntag Nachmittag bis Montag Nacht 591 Datensätze mit je 5x DS18B20 gesammelt.
Ausfälle, d.h. keine Daten / missings im Datensatz:
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.
Kleiner Exkurs, wie ist das beim BME und dem HX711? Wurde es da in unseren Bibliotheken “richtig” gemacht?
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.
Dank @robert-hh konnten wir hier die Treibersituation neulich ebenfalls verbessern. Beackert wurde das Thema bei…
Da haben wir selber geringfügig Hand angelegt, das ist aber schon länger her.
Nein keine Außreißer. Allerdings eine andere Beobachtung, wie drüben bei Solarregler regelt ab geschildert.
Exzellent. Die Aufzeichnungen vom 4. August bis zum 10. August zeigen weiterhin keine Ausreißer, stimmts?
Coole Darstellung! Wer hat denn die gebastelt!
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.
Fazit: Hätte schlimmer kommen können.
Drüben bei Kontinuierliche Verbesserungen des Terkin-Datenloggers (600er) - #116 by Andreas fragte @Andreas, welche weiteren Dinge für
Ein weites Feld, essentiell sind für mich korrekte Messungen. Da wir die drop outs des DS18B20 wie hier berichtet Untersuchung und Verbesserung des Timings bei der Ansteuerung der DS18B20 Sensoren unter MicroPython - #61 by Andreas nicht kurzfristig in den Griff bekommen, würde ich für einen workaround auf Stromkosten plädieren, etwas so:
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.
Sehe ich anders, wenn Messwerte fehlen ist das alles andere als absolut korrekt und auf jeden Fall einen workaround wert.
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.)
