Stabilität und längere Testzeiträume des Terkin-Datenloggers

GitHub - Hiverize/FiPy mit Messwertfilterung DS18B20 von mir.

Just a short welcome note for @pinguin.

1 Like

Mich würde brennend interessieren, wie du die Messwerte Filterst.
Da nur alle paar Std. ein Außreißer zu erwarten ist, würde ich denken, Mitte von 3 oder von 5, ist am einfachsten und effektivsten.
Das heißt, wenn man die höchsten und den niedrigsten Werte der letzten 3 oder 5 Messungen ignoriert.
man hat dann zwar ne Phasenverschiebung um eine Messungsperiode, ist aber Denke nicht wirklich tragisch solange man in einigermaßen kurzen Abständen misst. Die Bienen haben ja auch keine Atomuhr.:rofl:
Oder Filterst Du anders?

Da die Messwerte alle 10 sec gemessen werden, liegen sie nah beieinander. Nur alle paar Minuten bei DS18B20 und alle paar Stunden bei HX711 weichen sie deutlich davon ab.
z.B. 22.3 22.3 22.3 22.3 22.3 80.5 22.3 22.3 22.4 22.3 usw.
Ich gehe davon aus, dass irgendwo ein bit verschluckt wird und betrachte den Messwert als völlig falsch und ersetze ihn durch den letzten Wert.

Codebeispiel für HX711

### HX711 Waage
hx711akt =  0
hx711old = hx711.get_value(times=5)
hx711tol = 15.0

        hx711akt = hx711.get_value(times=5)
        hx711akt = int(hx711akt*10)/10            # 1 Dezimalstelle nach Komma
        if (hx711akt > hx711old + hx711tol):           # Aktueller Wert > alter Wert
            print('korr>  Gewicht:  {} kg >  old: {} kg + {} kg'.format(hx711akt, hx711old, hx711tol))
            hx711akt = hx711old
        if (hx711akt < hx711old - hx711tol):           # Aktueller Wert < alter Wert
            print('korr<  Gewicht:  {} kg <  old: {} kg - {} kg'.format(hx711akt, hx711old, hx711tol))
            hx711akt = hx711old
        hx711old = hx711akt

Danke, so geht es natürlich auch.
Wenn ich jetzt mal beide Software vergleichen darf oder überhaupt kann.
Ich teste jetzt ja aktuell mit dem Hiveeyes MicroPython Datalogger 0.5.1 mit 15 Sec Deep Sleep der Wachzustand mit hochfahren der Sensoren und des WLan dauert ca. 30 sec…
Übertragen und gemessen werden also in etwa alle 45sec.
Also muß ich die Fehlerhäufigkeit fairer weise bei mir bei mir um Faktor 4,5 höher ansetzen.
Dennoch st diese Firmware doch einiges besser bei den Sensoren aufgestellt.
Die HX711 haben bei mir auf allen 4 Systemen (Addierte Dauerlaufzeit ca 2 Wochen + zzgl.vorherige kürzere Tests) bisher nur ein einiges mal, und dann aber auch extremen Außreißer (-19,7t) gemacht.
Von den insgesamt 18 DS1820 haben im gleichen Zeitraum, 4 Stk zusammen 6 mal Schluckauf gehabt.
Die Frage die sich mir jetzt stellt woran liegt es? Es scheint ja die Möglichkeit zu geben die Fehler zu reduzieren.
Sind es die Bibliotheken, das Layout des Boards oder andere Probleme (Spannungsversorgung? Timing?) die die Fehlmessungen erzeugen.

Vor ca.2 Jahren habe ich Dauermessungen von DS18B20 und HX711 mit einem RaspberryPi gemacht. Da sind mir Fehlmessungen der DS18B20 fast nicht aufgefallen, die vom HX711 waren aber viel häufiger.
Dann bin ich im Oktober 2018 auf einen ESP32 DevKitC mit Arduino-IDE umgestiegen, habe aber kaum Dauermessungen gemacht und sie auch nicht graphisch dargestellt. Auch da sind mir Fehlmessungen kaum aufgefallen.
Ab März 2019 habe ich den FiPy mit der Arduino-IDE programmiert, ober ohne Dauermessungen.

Erst seit Mai programmiere ich den FiPy mit MicroPython und stelle die Dauermessungen mit der BOB-App dar. Jetzt zeigt der BME280 nie, der HX711 selten und die DS18B20 oft Fehlmessungen.

Fazit: es könnte noch an der Software liegen. Die Hardware war in allen Fällen ähnlich oder gleich. Stromversorgung war ein 2,5A USB-Netzteil.

Ja kann an der Software oder an der Hardware liegen. Meine laufen noch nicht lange genug um da Rückschlüsse zu ziehen, dafür sind die Fehler zu selten.
Alle Messungen derzeit mit Datalogger 0.5.1
FiPy 0

  • 7 Tage
  • 3 DS Fehler
  • 1 HX Fehler
  • 0 Abstürze

FiPy 1

  • 4 Tage
  • 2 DS Fehler
  • 0 HX Fehler
  • 0 Abstürze

FiPy 2

  • 2 Tage
  • Keine Störungen

WiPy 1

  • 2 Tage
  • Keine Störungen

Bei den Kurzzeitmessungen vorher teilweise mit unterschiedlichen Softwareversionen die nur 1-3 Tage gelaufen sind sind mir keine Mess-Fehler aufgefallen(hab allerdings nicht intensiv danach gesucht)

Mit der FiPy Software allerdings schon auffällig viel. Lief allerdings auch nur 4 Tage auf einen FiPy. Da ich dort aber ernste Probleme mit meinem WLAN Router hatte (müsste die Routereinstellungen für die tests ändern). Und dazu noch im Testzeitraum 3 Abstürze hatte hab ich den neuen Datalogger probiert.

Beim Rasperry sind mir früher aber auch häufige HX Fehler aufgefallen. Die DS laufen dort auch gefühlt sauberer, allerdings waren da auch nur 2 dran, was das Gefühl wieder verfälscht.

Vielen Dank für Eure Beobachtungen.

Ich nehme auf jeden Fall nochmal den onewire-Treiber und die entsprechende Ansteuerung unter die Lupe.

Ja aber bitte nicht sofort. Eine Baustelle nach der anderen.
Die Fehlmessungen fallen ja auf da bis auf einmal nur je ein Sensor gesponnen hat.
Später kann es nervig werden, wenn man sich veränderungen im Brutnest über einen längeren Zeitraum anschauen möchte und die Sala durch einen falschen Wert so grob wird, das man nichts mehr erkennen kann.
Beim HX711 ist es das selbe, aber bei mir bisher nur ein einziges Mal.

Hier mein Testsystem draußen, aber ohne Bienen:

  • FiPy mit littleFS als file-System und hiveeyes-Software pull vom 08.07.
  • BOB-Platine Clemens
  • mit Solar-Lader CN3065 breakout
  • und 0,5 W-Solarpanel
  • plus 2000 mAh 1S-LiPo
  • HX711 mit Bosche H30
  • 5x DS18B20
  • 1x BME280

das läuft ab 8. Juli und liefert ca. alle 6 Minuten Daten:

https://swarm.hiveeyes.org/api/hiveeyes/testdrive/area-005/fipy-cg-01/data.txt?from=2019-07-08T15:27:05&to=now&include=weight.0,temperature.0x77.i2c:0,system.voltage,system.uptime

[Zeitangaben in UTC, d.h. “für echt” müssen momentan noch 2 Stunden drauf, MESZ = UTC+2]

Auch eine nette Ansichtsmöglichkeit, nur schade das die DS1820 nicht dabei sind.
±25g finde ich jetzt aber etwas viel, für die paar °C Abweichung. Obwohl sie nicht so stark zu Rauschen scheinen, wie meine. Hast du wieder die Einbalkenwaage am Start?

Wenn du Teile des search-strings weglässt, bekommst du auch alle Daten inkl. aller DS18B20! ;-)
https://swarm.hiveeyes.org/api/hiveeyes/testdrive/area-005/fipy-cg-01/data.txt?from=2019-07-08T15:27:05&to=now

Ja, die kleine Taschenwaage! ;-) Steht leider fast den ganzen Tag im Schatten, muss mal schauen, ob ich sonniger noch WLAN habe.

± 15 g hatte ich schon bei fast konstanter Temperatur auf der Werkbank, finde ich nicht problematisch. Bei einem normale Stock hat man mit Luftfeuchte, Regen usw. garantiert mehr.

Nächste Test-Waage ist dann eine mit Holz-Magazin, konstantem Gewicht und ohne Bienen.

Bei mir sind die Sensoren schon in der Beute.
Auch mit der neuen Firmware und der aktuellen Micropython Firmware läuft das System nicht komplett stabil. Trotz Deep-sleep setzt das System häufig nach ein paar Stunden aus und lässt sich nur durch Trennung vom Strom wieder aufwecken.
Ich werde noch einmal das Netzteil austauschen, obwohl das verwendete eigentlich ausreichen sollte.
Das WLAN hatte ich schon einmal durch einen Repeater verstärkt, da dies aber keinen Unterschied brachte habe ich es wieder zurück gebaut. Können die Signalstärke Werte die @MKO gefunden hat uns hier Aufschluss geben?

Bei den Messwerten ist es so, dass ich gelegentlich fehlende Messwerte bei den Temperatursensoren beobachte. Es ist nicht immer der gleiche Sensor, daher gehe ich nicht von einem Sensorproblem aus.

Grüße aus dem Norden

Andreas

Moin @waggi .
Hmm. Hattest du auch die Gerätefirmware Upgedatet und dabei auch gleich das Dateisystem auf LittleFS gestellt?

Denke Mal da liegt das Problem.

1 Like

Um zu überprüfen, wie viele Datenpakete wirklich ankommen, habe ich mir in Grafana ein einfaches panel gebaut, das die Datensätze per Stunde zählt und anzeigt. Damit sollten Ausfälle und Instabilitäten gut sichtbar gemacht werden können:

Passt bisher ganz gut, ich lade ca. alle 6 Minuten Daten hoch, d.h. es sind 10 Datensätze / Stunde oder auch mal nur 9 wenn es etwas mehr als 6 Minuten sind, 9-10 sind also im Normalbereich, d.h. bisher gab es also 0 % Ausfall und alles läuft stabil!

2019-07-09%2020_52_10-Greenshot

Live-Daten unter https://swarm.hiveeyes.org/grafana/d/DP9PYvgZz/hiveeyes-testdrive-area-005-fipy-cg-01?refresh=5m&orgId=2&from=now-7d&to=now

2 Likes

Moin @MKO,
Die Gerätefirmware habe ich geupdated. Wie würde die Umstellung des Dateisystems funktionieren? Ich habe mich da ganz an deine Beschreibung gehalten ;-)

Hallo @clemens,
Mögt ihr mir bitte einen Account für Grafana erstellen. :pray:

P.S. Schöne Grüße von Ralf (RaSe) - habe ich am Wochenende getroffen ;-)

2 Likes

Wie es über die Konsole geht hat Andreas hier bschrieben: FiPy verliert Programm nach power off durch leeren LiPo / file system corruption through brownout conditions - #3 by Andreas

Note: When switching between LittleFS and FatFS, the flash file system will be re-formatted thus erasing all content.

D.h. es wäre gut die settings.py vorher zu sichern, falls man sie nicht eh lokal irgendwo hat.

Noch einfacher – für mich – ist es wenn die Firmware mit dem PyCom-Tool geupdatet wird https://pycom.io/downloads/#firmware und man während dessen zu LittelFS switchet:

2019-07-10%2009_09_32-Greenshot

2 Likes

Wenn man die Sandbox installiert hat, klappt das ganze nun am komfortabelsten per

make format-flash

@pinguin und @Andreas können bestätigen, dass die oben dargestellten Optionen in der für macOS angebotenen Version 1.15.1 des Pycom Firmware Update Tool scheinbar noch nicht ansteuerbar sind.

Kann sein, dass es nur in der developer-Version geht! Bitte nochmal testen. Gleich auf der ersten Seite (zumindest beim Windows-Toll):

“Include development releases”, ist ein etwas komisches bundling von features und dev vs. non-dev.