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!
@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:
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. .
