Daten auf SD schreiben und als bulk senden

Ich habe ausprobiert, wie wir Daten von der SD lesen können und als Bulk senden können, wenn WLAN da ist.

Da wir 2 Kits in Kamerun nutzen wollen habe ich im Moment folgenden Use-Case im Kopf. (Der lässt sich aber leicht umbauen). Standart-mäßig ist kein WLAN da. Alle 1-2 Wochen kommt jemand zum Bienenstand, macht auf dem Handy einen AP auf. Er / sie drückt auf einen Button und alle Daten von der SD werden gesendet.

Dazu speicher ich die Daten auf der SD direkt im InfluxDB-lineprotocol-Format. Falls benötigt, können sie zusätzlich in einem anderen Format gespeichert werden. Das senden hab ich jetzt über die influx api gelöst.

Folgende Fragen haben sich für mich ergeben:

  • ist es save, wenn ein influx-db-user mit write permission und das passwort auf dem FiPy liegt? oder könnte das jemand missbrauchen?
  • nach dem Senden, könnten die Dateien einfach wieder gelöscht werden?

Der Code zum ausprobieren liegt aktuell hier:
https://github.com/Hiverize/FiPy/tree/kamerun

In influx.py muss in Zeile 13 folgendes eingefügt werden:
http://[server-ip]:[port]/write?db=[db-name]&u=[db-user]&p=[db-password]

  • Der AP ist in der user-setting auf “P16” also SW1 auf der grünen Platine gesetzt.
  • Der Button zum senden ist “P14” also SW2 auf der grünen Platine.
  • Das Senden an Beep in jedem Interval ist zum testen auskommentiert.

Vielleicht habt ihr ja Tipps und Gedanken dazu oder sogar Zeit zum testen.

(-: wow!!!

@Diren: Doofe Frage, sind die Daten dann auch gleich in Beep verfügbar?

Ich stell mir auch die Frage, woher er nach einem Neustart durch WDT oder Stromausfall die Zeit bekommt und wie der Imker sicher sein kann, das die Zeit korrekt ist, wenn er die Beute verläßt.
Bräuchten wir für so einen Fall nicht eine externe Uhr? Die interne Uhr im Pycom ist ja auch Recht ungenau.

Also zusätzlich eine batteriegepufferte I2C RTC wie diese hier
https://eckstein-shop.de/DS3231-RTC-Modul-LIR2032

1 Like

Die RTC des FiPy passt schon für solche Anwendungen! Man könnt überlegen, ob beim Holen der Daten auch die Zeit neu synchronisiert wird.

Was passiert aber nach einem (versehentliches) reset? Da würde die init time in settings genutzt, und wenn wir mehrere Resets hätten werden auch mehrere Datensätze mit 2000-01-01 auf SD und ggf. später in der DB.

Was passiert wenn der wdt zuschlägt? Wird dann auch die Zeit gelöscht??

Ohne Strom bleibt die RTC stehen, z.B. wenn die Versorgung ( auch kurzzeitig ) unterbrochen wurde. Es gibt RTC-Module mit Batterie mit I2C-Anschluss. Die könnte man auf den OLED-Anschluss setzten.
Für den RPi habe ich die im Einsatz ( LK-RTC Linker Kit RTC - Joy-IT

Genau das habe ich mich ja auch gefragt. Auch was passiert, wenn die Batterie mal aufgrund der Umelteinflüsse Mal nicht voll genug für die Nacht ist. Wär mir auf alle Fälle zu unsicher wenn nur Mal einer alle X Wochen vorbei kommt.

Wie geschrieben die oben von mir genannte RTC hat schon eine Batterie zusätzlich hat sie auch noch ein EEprom welcher sicher auch für den terkin Datenlogger und deep sleep interessant ist.

Zusätzliche Pins brauchen wir auch nicht. Da ein i2c ja schon für den BME vorhanden ist.

Ja, das sind dezidierte Puffer-Batterien für die RTC, was sicher für eine robustere Ausbaustufe mit zu erwartenden längeren Stromausfällen Sinn macht. Meine Motivation wäre erst mal zu schauen, was mit dem bisherigen System ohne zusätzliche Hardware und Implementierungsaufwand möglich ist. Wir haben ja eine Batterie! Die dürfte nur nicht leer gesaugt werden, sprich

  1. wir sollten die Batteriespannung auch bei BOB messen
  2. nicht mehr weiter Daten sammeln wenn die Batterie kritisch wird, sondern
  3. das System in den deep sleep schicken und nur noch alle x Stunden schauen, ob das Solarpanel die Batterie wieder so weit aufgeladen hat, dass man weiter messen kann.

… und zuvor nochmal testen, ob die eingestellt Zeit einen wdt-Reset überlebt, sonst bleibt uns tatsächlich nur die zusätzliche externe RTC

Ich persönlich finde es nicht so tragisch diese Daten (Zugangsdaten zur influx-db) im Gerät zu speichern, solange sie nur Write rechte haben und vor allem nur für einen stark abgegrenzten Bereich der Datenbank gelten.

Es müss ja erstmal der Fipy entwendet, dann ausgelesen und dann noch der richtige gefunden werden der ein Intresse hat, damit unfug zu treiben. Spätestens, wenn man bemerkt, das der FiPy nicht mehr in den Händen ist, wo er sein sollte, sollte man den User dann löschen oder alle Rechte entziehen

Sicherlich ist es auch durch write rechte möglich schadhaften code bei bestimmten Datenbanken einzuschleusen. Ob das auch bei Influxdb möglich wäre, kann ich persönlich nicht sagen.

Ich habe mal ein wenig geschaut die interne RTC scheint weder WDT noch RST zu Überleben. Habe dafür die zeilen 286 und 289 in der main.py Auskommentiert, damit sie auch nicht immer von der config überschrieben wird.

Ein gewisser andreas schreibt hier im PyCom-Forum RTC in combinattion with deepsleep unusable | Pycom user forum ;-)

we can confirm the clock of the RTC works as intended after invoking machine.deepsleep() using the most recent firmware on a FiPy device. See also [1].

Verwendet die BOB-Software überhaupt die RTC? oder wird das über eine programmspezifische Variable “hochgezählt”?

[edit] Sorry, ging um WDT, ich war gerade noch bei deep sleep!

So ist es. Nur nach einem Deepsleep wird sie nicht neu initialisiert bzw. zurückgesetzt.

1 Like

Doof! Ich frag’ mal nach RTC time does not survive WDT | Pycom user forum habe aber wenig Hoffnung, das Ding hängt und dann macht der eben einen reset!

Ja die Bob-Software verwendet den internen RTC soweit ich das beurteilen kann.

habe auch wenig hoffnung auf Antwort,WDT Reset, RTC also reset | Pycom user forum über ein Jahr alt und keine Antwort.

Ein weiterer Vorteil eines externen RTC wären sicher noch die programierbaren Timer man könnte dadurch sicher auch die <2h deep sleep blockade brechen oder einen externen WDT als doppelte sicherheit einrichten - traue dem internen noch immer nicht ganz

hab bei dem kamerun branch auch ab und an abstürze bemerkt scheint von der SD zu kommen.
Müssen da bei den schreib und lesezugriffen noch Fehler abfangen.
ohne SD oder schlechten kontakt geht da bei mir momentan gar nichts außer

Error, dumping memory
(<class 'OSError'>, OSError(2,), None)

und der WDT schlägt nach programabruch zu. liegt evtl mit am, in der config, deaktivierten W-Lan

du meinst wie beim ESP8266? die gibt es beim ESP32 nicht mehr, das geht, habe ich schon probiert (mit Arduino-code)!

Jo, wir müssten dann für jeden FiPy einen eigenen User anlegen? Andreas hat mir auch schon gesagt, dass er das mit den User-Daten nicht so kritisch sieht. Eigene User anzulegen wäre aber evtl. schon ne gute Versicherung? Aber auch ziemlich aufwendig.

nach dem Bulk-Senden, ja, genau.

Sehr gute Frage!

Klingt für mich auch nach der robustesten Lösung.

Einziger Hack, der mir noch einfällt wäre in jedem Messzyklus die aktuelle Uhrzeit als Start-Uhrzeit in die Config zu schreiben. Das hätte den Vorteil, dass die Uhrzeit, falls der WDT nen Neustart veranlasst, bis auf wenige Sekunden Abweichung stimmt.

Wäre natürlich optimal. Wie ist das nochmal? Die Solarladeregler, die wir bestellt haben sind nur für kleine Module. Wenn wir einen externen Solarladeregler für größere Module verwenden, wie Didi testet, dann kommt der FiPy nicht an die Batteriespannung?
Ich favorisiere aber generell schon den externen Laderegler für große Module.

Ich nehme folgende ToDos für mich mit:

  • Zeit synchronisieren beim Holen der Daten
  • Fehler abfangen beim Schreiben auf SD
  • Kennzeichnen der schon gesendeten Daten/ löschen von gesendeten Daten
  • wahrscheinlich am besten externes RTC-Modul implementieren

Vielleicht nicht für jeden FiPy, aber einen user für alle FiPys, die so Daten schicken, werden ja nicht zu viele sein. Als worst case wenn das doch ausgenutzt wird.

Können wir Zugangsdaten nicht auch encrypten, damit sie nicht ganz so offensichtlich als Klartext im Dateisystem liegen?

würde folgendes noch hinzufürgen:

  • WLan aktivieren und verbinden wenn der Senden Button gedrückt wurde.
  • Rückmeldungen über RGB LED an den Benutzer über RGB
    -sollte im unbeaufsichtigten Betrieb nur nur kurzzeitig leicht/schwach Blinken z.B nur beim schreiben auf SD um ordnungsgemäßen Betrieb zu signalisieren.
    -Rückmelden ob Daten erfolgreich Gesendet wurden Langes helles Blinken.
    -Uhrzeit syncronisiert? oder vor Jahr 2000? Binken betrieb z.B rot und Grün

Ich will mir die Tage ein paar Teile bestellen.
Würde mir dann auch gleich eine Externe RTC holen.
Die Frage ist welches?

  1. DS1307 wie die Linker Kit RTC - Joy-IT 3 die @didilamken erwähnt hat
  2. DS3231 ohne EEprom
  3. DS3231 inkl EEprom
  4. Oder andere Typ ___?

@all Wär schön wenn wir uns vorweg schon auf einen Typen festlegen könnten, auch wenn sie später nicht verbaut werden. Am besten gleich für beide Firmware Varianten.

Ich wäre aktuell für die DS3231, da ich von den DS1307 gelesen habe, das sie Probleme haben sollen.
@Andreas macht es für Dich bzw. Terkin Datalogger Sinn gleich mit EEprom zu nehmen und wie schätzt du die bestehenden lib’s für Micropython ein.
Würde mir sonnst die ohne EEprom bestellen.

Die DS1307 vom LinkerKit haben bei mir seit Jahren funktioniert, allerdings nur am RPi mit Raspbian, nicht mit eigenen Python-Programmen.
Auch wenn der Raspi monatelang aus war, hat die Uhrzeit gestimmt, aber ich habe nicht genau hingeschaut, da meistens mit NTP synchronisiert wird.
Ich habe in github eine MicroPython-Library gefunden, aber noch nicht ausprobiert.

Die DS3231 habe ich zwar liegen, aber noch nie getestet.

Die DS1307 sollen Zeit verschiebungs Probleme beim häufigeren lesen haben und auch sonnst veraltet und etwas ungenauer sein.
Auch sollen sie eher nur für 5V was taugen.

Die DS3231 sollen weniger Problematisch sein.
Auch verbrauchen sie etwas weniger Energie zumindest wenn kein zusätzliches EEprom verbaut ist.

Wie gesagt ist nur aus div. Foren zusammengetragen.
Ich verstehe, wenn Du sagst, es sollen die 1307 sein, da Du sie kennst und weißt das sie zumindest in Python gut funktionieren.