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!
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. 
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:
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.
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.
14 posts were merged into an existing topic: Untersuchung und Verbesserung des Timings bei der Ansteuerung der DS18B20
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.
Die Diskussion rund um die Glitches beim Auslesen der DS18B20 haben wir nun bei Untersuchung und Verbesserung des Timings bei der Ansteuerung der DS18B20 untergebracht.
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.
Bisher schaut das – was die Stabilität angeht – alles recht gut aus:
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:
Das Gerät läuft also stabil seit ca. 7 Tagen!
1 Like
Testsystem-Ausfall 2019-07-20
Leider stieg mein Testsystem am 2019-07-20, 23:16 (GMT) komplett aus und wollte auch bis jetzt keine Daten mehr senden:
- 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.