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?
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.
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
wir sollten die Batteriespannung auch bei BOB messen
nicht mehr weiter Daten sammeln wenn die Batterie kritisch wird, sondern
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.
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!
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
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?
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?
DS1307 wie die Linker Kit RTC - Joy-IT 3 die @didilamken erwähnt hat
DS3231 ohne EEprom
DS3231 inkl EEprom
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.
