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.
Untersuchung und Verbesserung des Timings bei der Ansteuerung der DS18B20 Sensoren unter MicroPython
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.
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.
1 Like
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.
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.
1 Like
Nein keine Außreißer. Allerdings eine andere Beobachtung, wie drüben bei Solarregler regelt ab geschildert.
1 Like
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.
Considered to be a good thing™
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.)
2 Likes
This.
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.
@roh und andere haben Interesse signalisiert, gemeinsam auf etwaige Streifzüge in Richtung Pycom Firmware selber bauen zu gehen, um zu schauen ob wir uns die esponewire.c und die zugehörige modonewire.c aus dem Genuine MicroPython Projekt zu eigen machen können.