[dieses Posting ist ein Wiki und kann von jedem angemeldeten user editiert und ergänzt werden!]
Wir sind gerade dabei die “neue” Micropython-Firmware zu testen. Letzte Woche habe ich u.a. mit @pinguin, @Diren und @caro über die Stabilität gesprochen. Selbst bin ich gerade dabei ein System aufzusetzen, das nur für Langzeittest da sein soll. Berichtet doch bitte wie stabil euer System läuft.
Mögliche Dinge, die mal anschauen sollte, wenn es nicht rund läuft:
Bei mir läuft’s recht stabil. Hab derzeit 2 Systeme im Dauerbetrieb. Bei dem einen machen 2 der ds18b20 ca. einmal am Tag einen Fehlwert. Die HX711 laufen stabil ±10g . Allerdings gab es seit die Systeme laufen auch keine besonders heißen oder kalten Tage.
Sobald ich die Zeit dafür finde editiere ich die Dashboards hier rein.
Bei Bob habe ich einen Virtuellen Teststand mit einer Test-Beute dafür erstellt. Wenn jemand Interesse hat, kann ich diese über Kooperieren auch mit euch teilen. Dann bitte PN mit Bob ACC Benutzername/E-Mail.
Vielleicht lohnt es sich, systematische Komponententests zu machen? Scheinbar sind ja bei uns allen die Logfiles nicht sehr aufschlussreich und die Ursachenforschung entsprechend schwer.
Vorschlag: wir testen die Einzelkomponenten
(0) WLAN (FiPy ist einfach nur an, mit den WLAN verbunden )
(1) Wägezelle (nur messen),
(2) Temperaturen (nur messen),
(3) BME (nur messen),
(4) Telemetrie (statische Testdaten verschicken). (Leider geht (4) nicht ohne (0), aber das ist eben unvermeidbar),
(5) Deep Sleep (im Wechsel schlafen und aufwachen, keine Sensoren, kein WLAN)
Erst wenn alle Komponenten stabil laufen - 7 Tage könnte hier eine Schallmauer sein - fangen wir mit Integrationstests an: Messdaten verschicken, zwischen Messungen schlafen, etc.
Dass die Sensoren ab und an einen Messfehler machen, ist meiner Meinung nach nicht verwunderlich und auch nicht weiter tragisch. Das ist bei Sensoren dieser Preisklasse so. Didi hatte auch schon einen Filter implementiert.
Folgende Tests sind bei mir durch. Denke das Einzeltests der Komponenten, ohne das vorher überhaupt ein Problem festgestellt wird nicht nötig ist und nur Zeit und Arbeit frisst.
WLAN 7 Tage OK.
Übertragung ohne Deep Sleep nicht OK. Wenn die Verbindung Mal zwischendurch abreißt wird sie nicht selbständig wieder aufgenommen. Sensoren werden aber weiterhin ausgelesen.
Übertragung mit Deep Sleep über 7 Tage OK. Wird ja jedes Mal neu aufgebaut!
BME 280 und DS18B20 über 7 Tage mit und ohne Übertragung und mit und ohne Deep Sleep OK.
Getestet wurde mit einem WiPy und 2 verschiedenen FiPy’s. 2 FiPy laufen derzeit im Dauertest mit allen Sensoren über mehrere Tage auf 12V Solaranlage mit DC DC Stepdown Converter problemlos.
Hatte vorher auch Mal einen längeren Verbindungsabbruch (ca. 6h) weil die maximale Reichweite meines Routers durch ein anderes WLAN gestört wurde. Nach Wechsel des Kanals am Router, auf einem freieren Kanal, lief das System ohne Eingriff weiter und übertrug wieder seine Daten.
Würde daher sagen Aktuell läuft die Firmware aus meiner sicht sehr robust, solange Deep Sleep aktiviert ist.
Wir bekamen ein paar Stacktraces zugeflüstert. Das ist immer gut, weil STGTFO.
load:0x4009fa00,len:14592
entry 0x400a059c
Traceback (most recent call last):
File "main.py", line 31, in <module>
File "hiveeyes/datalogger.py", line 14, in <module>
File "terkin/datalogger.py", line 11, in <module>
File "terkin/device.py", line 13, in <module>
File "terkin/telemetry.py", line 624
SyntaxError: invalid syntax
Traceback (most recent call last):
File "main.py", line 31, in <module>
File "hiveeyes/datalogger.py", line 14, in <module>
File "terkin/datalogger.py", line 12, in <module>
File "terkin/network/__init__.py", line 1, in <module>
File "terkin/network/core.py", line 10, in <module>
File "terkin/network/wifi.py", line 279
IndentationError: unindent does not match any outer indentation level
Gedanken
Das sieht ganz nach Dateisystemkorruption durch Strommangel aus, entsprechende Beobachtungen konnten wir anfangs leider auch machen. Die einfachste Lösung war für uns, a) eine stabile und ausreichende Stromversorgung zu verwenden und b) die neueste Pycom-Firmware aufzuspielen und gleichzeitig von FatFS auf LittleFS umzusteigen.
Gut das kann bei meinem Setup natürlich nicht vorkommen, es sei denn bei mir sind die 12V Akkus komplett am Ende. Habe außerdem die neuste Firmware und LittleFS.
Könnte auf einem weiteren FiPy Mal ein Dauertest, mit meinem Programmierbaren Netzteil starten. Würde sagen alle 30 sec. 0,05V runter bis 2,5V und dann wieder von 4V beginnen. Das in einer Dauerschleife.
Einwände oder andere, niedrigere Spannungen?
Denke ich auch. Hab mir auch Mal Vue.js und den Code von @vinz grob vertraut gemacht.
Hab jetzt zumindest aus den riesen großen, viele kleine Fragezeichen gemacht.
Evtl. bekomme ich das Webinterface, zumindest provisorisch verheiratet so das wenigstens die Grundfunktionen für Bob Betrieb laufen. Alles weitere werde ich merken wenn ich dabei bin.
Nur am 21. und 24.6. deutliche Messwertausreisser, die nicht gefiltert wurden.
Nur einmal ist der FiPy stehengeblieben und musste mit Power off/on gestartet werden.
Das WLAN lief stabil: Router WlanBOB1 auf dem Dachboden und Repeater WlanBOB2 auf der Terrasse.
Wie oft der FiPy zwischendurch resettet hat, kann ich nicht sagen. Aber er hat zuverlässig Messwerte im Dauerbetrieb übertragen.
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.
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.
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.
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.
