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.
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!
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 ;-)
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:
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.
Auffällig ist, daß nach dem Zurückstellen an den ersten Standort die RSSI nicht wieder besser geworden ist, sondern etwa 10 dB schlechter bleibt als am Vormittag. Ebenfalls gibt es zwei Spannungseinbrüche in Momenten, an denen die RSSI zweimal spikes nach unten (aka schlechter) hat.
Das sieht mir eher nach WLAN- und ggf. noch Stromversorgungs-issues aus, als nach software-Problemen. Natürlich weiß ich nicht, ob Du in dieser Zeit noch software-Änderungen vorgenommen hast.
Nein, beim FiPy “im Feld” gab es keine Änderungen an der Software, die läuftvom Start an. Das WLAN muss hier durch zwei Kellerwände und ein Fenster, ggf. habe ich die Box auch nicht genau so ausgerichtet wie sie vorher stand.
So mal ein Aktueller Bericht der Langzeittests bei mir.
Immer noch mit Datalogger 0.5.1 auf 1.20.0.rc11 FiPy 0
12 Tage
5 DS Fehler
1 HX Fehler
0 Abstürze
FiPy 1
10 Tage
7 DS Fehler
0 HX Fehler
0 Abstürze
WiPy 1
8 Tage
2 DS Fehler
0 HX Fehler
0 Abstürze
FiPy 2 habe ich selbst vom Test ausgeschlossen, da ich derzeit mit im für das Webinterface arbeiten will. Er hat aber nach 5 Tagen 0 Störungen gehabt.
Abstürze hatte ich bei ihn aktuell aufgrund des abgeschalteten Deep Sleep aber schon ein paar mal.
Herzlichen Dank für die Testberichte! Das hört sich ja vielversprechend an.
Du meinst, das Gerät stürzt manchmal ab, wenn es nicht im Deep Sleep Modus ist? Kannst Du ungefähr eingrenzen, an welcher Stelle oder unter welchen Umständen?
Muß ich noch genauer untersuchen. Habe leider immer den PC nicht an gehabt, um das Logging zu sehen auch ist die Telemetrie aktuell ausgeschaltet, wodurch ich keinen Zeitpunkt ausmachen kann.
Kann aber auch an dem Branch liegen ist aktuell das merge Branch von Diren mit Webserver drauf.
Wie gesagt, muß ich daher nochmal untersuchen.
Vielen Dank für diese Details zu Deinen Beobachtungen. Wir haben die notwendigen Schritte zur Analyse und Lösung bei [Backlog] Terkin-Datenlogger für BOB aufgenommen.
Unmotivierte Abstürze
Vielleicht ist das genau das Ding, das @pinguin beobachtet hatte und ich neulich ebenfalls. Ich glaube, dass das Gerät bei mir ebenfalls nicht im Deep Sleep Modus war. Wir sollten hierzu dringend den Watchdog ins Spiel bringen.
Wir haben fast immer die 9-10 Übertragungen pro Stunde, der längere Ausfall am 2019-07-10 geht auf mein Konto, da habe ich den Node in die Sonne gestellt und damit zu weit vom WLAN weg, es konnten also keine Daten übertragen werden, dass der node aber weiterlief und läuft zeigt die system.time, die auch in der Zeit ohne Datenübertragung zunahm, es gab also keinen Ausfall der Hardware oder reset in der Zeit:
Batterie ok, die letzte gemessene Spannung war 4 V, passt also.
WLAN ok, das WLAN an das der node die Daten sendet wurde in den letzten Tagen normal genutzt, offensichtliche Ausfälle sind nicht aufgefallen.
Server ok einen Serverausfall gab es nicht, andere Systeme lieferten kontinuierlich Daten.
Beim Blick auf andere Daten ist mir aufgefallen, dass zur gleichen Zeit Stockgewichte um 1 kg – mitten in der Nacht – zugenommen haben und ich erinnerte mich an die Wetterwarnung des DWD! Auch wir hatten hier Wind und Regen.
Bei einer weiteren Inspektion habe ich die Spannung des LiPos gemessen: 3,1 V! Wie passt das zum letzten Datensatz mit 4 V? Ein Blick unter den Blumentopf:
Hmm, der BME lag da “schön” flach ganz unten! Könnte ein ordinärer Kurzschluss über den BME durch viel Regenwasser das Problem gewesen sein?
Nach einem Tausch der Batterie sendet der node wieder und er scheint keine bleibenden Schäden gegeben zu haben.
Fazit
Durch die Koinzidenz von Regen und Nodeausfall gehe ich mal davon aus, das beides miteinander zu tun hat (obwohl ich das Wort Scheinkorrelation auch kenne und weiß, dass Schuhgröße und Intelligenz hoch korrelieren),
Der sehr ungeschützte, flach auf der Steinplatte liegende BME könnte in Verbindung mit starkem Regen zu einem Kurzschluss geführt haben.
Alle Systemteile laufen mit vollem LiPo nun wieder.
Habe am Sonntag nacht um 1:20 Uhr das erste mal einen Totalcrash das erstaunliche ist, das absolut zeitgleich beide FiPy abgeschmiert sind. Kann also nur am WLan oder an der Spannungsversorgung gelegen haben. Die Spannungsversorgung ist zusammen über einen 12V mppt Laderegler mit USB Anschluß und 12V Akkus geregelt, da der Akku heute Mittag zu 100% gefüllt war und der eine FiPY durch ab und anstecken des USB neu gestartet werden konnte, schließe ich sie fast aus (der zweite bleibt stumm also auch kein IP Crash und der USB liefert Spannung) .
Den 2. habe ich extra noch nicht neu gestartet, da ich morgen Vormittag mal versuchen will bei ihn ins REPL. zu kommen. Bezweifel zwar das das klappt, aber einen versuch ist es Wert.
Wenn ja, wie sollte ich vorgehen, um möglichst viel Infos über den Ausfall zu bekommen?
Wollte erstmal mit Atom ran, da er beim Anschließend einfach ins Logging verbindet, ohne einen Reset auszuführen.
Interessant. Um das für die nächsten Iterationen zu verbessern, müsste die Aufmöbelung des Watchdogs dank @pinguin nun aus dem aktuellen Master heraus einsetzbar sein. Lass den Datenlogger doch gerne ab sofort mal (testweise) damit eine Weile losrennen.
Ich wüsste nicht, wie man da irgendetwas herausfinden könnte. Die Ausgaben auf der UART sind ja schon geschehen und wurden auf keinerlei Terminal geschrieben, wo man sie rauslesen könnte.
Andere benutzen für solche Feldforschungen einfache aber effektive AVR-basierte Datenlogger.
