Vielen Dank für Deine Beobachtungen.
Welcher Art ist dieser denn?
Habe auf jeden Fall sicherheitshalber Revert "Adjust waiting time after resetting 1-Wire bus" · hiveeyes/terkin-datalogger@11e8eaf · GitHub nachgeschoben, der eine kürzliche Änderung wieder rückgängig macht, die u.U. dazu beigetragen hat. Da müssen wohl die Pferde mit mir durchgegangen sein. Kriegst Du die Änderung noch mit unter?
Auf nahezu allen DS 1820 Sensoren geht wie bei 0.5.1 von ein paar Grad Abweichung bis zu 534°C alles vertreten. Ausbleiben einiger Werte von DS1820 Sensoren konnte ich auch schon sehen.
Ok, schade! Um sicherzugehen: Löschst Du vielleicht gerne kurz Deinen dist-packages Ordner komplett und holst Dir die Inhalte erneut per make setup? Better safe than sorry…
Hast Du Deine Daten auch bereits im Grafana?
An jenem Gerät bei Labor / FiPy Workbench 01 sind zwar Sensoren angeschlossen, allerdings wird dort bisher nur selten bis kaum konkret auf die Werte geschaut.
Bei den Aufzeichnungen gibt es viele Lücken, weil es recht häufig recycled wird. Daher sind die Aussetzer (bei allen Sensoren) der Betriebsweise geschuldet.
Frage an die Grafana-Spezis: Würde man solche Ausreißer durch Glitches gegen 451°F oder darüber hinaus nicht auch hier bei min/max in der Legendentabelle von Grafana zu Gesicht bekommen, um eindeutig mit dem Finger drauf zeigen zu können?
Das einzige “Misreading” sehe ich oben bei system-temperature. Das war aus der Zeit, in der wir mit dem Voltage Divider und der Ansteuerung des ADC beschäftigt waren.
Bei diesem Gerät sind aber halt auch nur 2x DS18B20 am Bus und ich habe vermutlich auch Anfängerglück mit den Sensoren.
ja hab ich eben schon gemacht. Ja Daten sind in Grafana: Baue ich aber gerade noch um
Neue Version mit CRC-Checks allerdings noch ohne die letzten beiden commit bezüglich der Rückstellung der Timings der Ds1820.
2 Fehler allerdings einer auf 0 hatte ich bisher noch nie das einer nach unten ausgeschlagen hat
Danke. Hier die Rohdaten auf die betroffenen Sensoren sowie den passenden Zeitraum eingeschränkt: Labor / MKO-Teststand 2019-08-02T01:30:00 bis 2019-08-02T02:30:00 für DS18B20 286cd7799704031f sowie 282ad9799704037a.
hier noch der dazugehörige Log.
Ich habe jetzt nochmal ein Git Pull gemacht und vorher den den Fipy und und den dist-packages Ordner gelöscht.
3:18 Uhr mal schauen was Jetzt raus kommt
Edit: Schaut jetzt wieder viel ruhiger aus. Aktuell noch kein Fehler seit dem.
Allerdings gab es in den 432 Messungen 128 mal keine Daten von einzelnen oder mehrerern Sensoren. Was aber vergleichbar mit dem Org. 0.5.1 ist.
Was schließen Ich daraus? das Timing um die Wartezeiten sind extrem wichtig. Und wir sollten dort nur langsam dran drehen. gibt also auch ein zu lange warten.
Wie erzeugst Du das letze Bild? Mit der BOB-App sieht das anders aus, da wird auch gemittelt.
Exzellent, vielen Dank für Deine bisherige Messreihe!
Exakt.
Die Optik des Revert "Adjust waiting time after resetting 1-Wire bus" · hiveeyes/terkin-datalogger@11e8eaf · GitHub kann trügen. Ich hatte dort unüberlegt eine Änderung gemacht, die kürzer (750ms) gewartet hatte als bisher (1s) - mea culpa => langsam dran drehen ;].
Diese Änderung wurde nun wieder zurückgenommen, so dass zwischen Bus-Reset und Bus-Scan wieder eine ganze Sekunde Zeit eingeräumt wird.
Hi Didi,
ist mit Grafana erstellt. Die hiveeyes-micropython-firmware kann zusätzlich auch zu swarm.hiveeyes.org per MQTT übertragen. Das kann die hiverize/FiPy leider (noch?) nicht.
Lasse dort nur Datenpunkte und keine Linien anzeigen.
Mitteln tut Grafana auch allerdings auch, aber nur wenn man größere Zeiträume über ein Tag betrachtet.
Bei unter 20h zeigt er bei mir die Echtdaten kann auch sein das er nur eine maximale Datensatz-zahl darstellen kann und dann mittelt.
Auf alle fälle ist Grafana viel besser zur darstellung und analyse der Daten geeignet, da man beliebige Zeitabschnitte betrachten und einstellen kann.
Hoffe das ist mit Andreas Änderung nun wieder besser, hatte mit der alten Version bei ca. 1300 Datensätzen und 5 DS18B20 nur um die 20 Ausfälle – dann fast immer der ganze bus!
Da nun die CRC-Checks mit dabei sind, wird es u.U. häufiger zu beobachteten Aussetzern kommen als bisher.
Falls wirklich 1/4 der Messungen Schrott sind wechsel ich wieder auf Arduino-C! ;-)
@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?
