Mergen der Änderungen von pinguin999/FiPy in Hiverize/FiPy

Mein erster Versuch, die aktuelle Version von @pinguin’s code GitHub - pinguin999/FiPy einfach zu übernehmen scheiterte, auch @Diren berichtete, dass der Code so nich läuft. Mit dem aktuellen code bekome ich

Initializing filesystem as LittleFS!
Starting boot process...
File not found: [Errno 2] ENOENT
Traceback (most recent call last):
  File "boot.py", line 33, in <module>
  File "/flash/lib/wlanmanager.py", line 21, in scan
  File "/flash/lib/config.py", line 52, in set_value
KeyError: networking
File not found: [Errno 2] ENOENT
File not found: [Errno 2] ENOENT
Initialised CSV logger in directory /sd/hiverizelog
File not found: [Errno 2] ENOENT
File not found: [Errno 2] ENOENT
Traceback (most recent call last):
  File "main.py", line 26, in <module>
AttributeError: 'NoneType' object has no attribute 'items'

Habe auch ein paar probleme mit GitHub - pinguin999/FiPy last commit [6d75cfe].
Lief bei mir erst, als ich 2 zeilen auskommentiert habe.
Zuerst gab es eine Fehlermeldung, das das Modem nicht gefunden wurde und das Programm wurde abgebrochen. deshalb musste ich in zeile 23 der main.py

23 #  lte = LTE()

Auskommentieren. Tippe mal das mein LTE Modem derzeit deaktiviert ist. dort fehlt also noch ne abfrage ob es deaktiviert ist

Dann hatte ich Probleme das sich ständig der AP-Mode Aktiviert hat (selbst wenn der Button Aktiviert war.), da er nach dem Deep-Sleep automatisch gestartet wurde. also auch erstmal Auskommentiert

156 # enable_ap()

nun läuft wenigstens die Messung erstmal. ist aber momentan alles andere als Deep Sleep
Der Fipy schluckt dauerhaft 157-140mA also 0,73-0,65W

Es ist allerdings nicht das gleiche Problem was Du hast @Clemens. bei dir versucht er auf der SD Karte eine Datei zu finden, die nicht vorhanden ist um das LOG fortzusetzen. entweder SD Karte raus oder eine Leere Datei anlegen. Irgendwie scheinen die Abfragen in der lib/csv.py nicht zu greifen, ob das Verzeichnis, und die Datei vorhanden sind. Habe derzeit keine SD dran kann also nichts testen.

/sd/hiverizelog/logging.csv

Ich weiß ich habe noch nicht versucht zu mergen aber vielleicht sind die Infos ja etwas hilfreich.

Weiterhin gibt es im AP Mode aber Probleme, da er alle 10 Sec (Nach jeder Messung neu gestartet wird.) nach ca. 10 Min wird er wieder deaktiviert und Oh Wunder da wurde auf einmal ein echter Depp Sleep ausgeführt, bis der Watchdog mal zugeschlagen hatte. Danach schluckt er Satte 250mA -260mA bis zum nächtsten Wachdog danach wieder 150mA

Watchdog wird bei mir so alle 20 -30 Mal ausgelöst, je schlechter Wlan desto häufiger.
Die micropyton Firmware versucht mit meheren Anläufen eine Verbindung Aufzubauen was auch nicht immer klappt aber die FiPy nur ein einziges mal, was bei meiner Fritz Box anscheinend nicht immer zum Erfolg führt.

Irgendwie sehr verwirrend und verbuggt die Software.

Ich lass jetzt erstmal die Finger davon, ich weiß derzeit nicht OB, Wo , Welche Version weiter verfolgt wird /werden sollte. Für Infos und Aufgaben wäre ich dankbar.

1 Like

So hab mir mal auf die schnelle aus einen SD>MicroSD Adapter einen MicroSD-Schacht gebastelt.

Also bei mir läuft das Logging @Clemens evtl. ist deine SD-Karte defekt, schreibgeschützt oder falsch Formatiert (FAT32).

image

Warum benutzt Du nicht das ExpansionBoard von PyCom? Bei mir hat das Loggen bislang immer funktioniert.

Weil ich bei meinem Set das Expansionsboard nicht zusammen mit meinem Board verwenden kann.
Und weil das Expansionsboard vollkommen überbewertet wird, es geht komplett und sogar besser ohne.

im Anhang mal die Log um zu zeigen wie unruhig es bei mir läuft.
logging.csv (852,8 KB)

Da die Hiveeyes/Andreas-Version der Software noch nicht mit der Hiverize/Bob/Vinzent-Version zusammenführen konnten, die captive portal-Funktionalität aber essentiell für die workshops sind, ist der Plan zumindest die

  • deep sleep und
  • voltage measurement-Funktionen

in die Software von @vinz für den nächsten Workshop einzubauen. Um später schnell von der aktuellen Software auf eine neuere Umzuschalten ist noch geplant das feature

  • updates over the air (OTA)

einzubauen.

Wir haben bei der Anmeldung zum Köln-Workshop ziemlich klar angesagt, dass man Strom am Beuten-Standort bereitstellen muss, wenn man das BOB-Kit in seiner aktuellen Version nutzen möchte.
Meiner Meinung nach ist daher OTA sogar noch wertvoller, als deep-sleep und voltage measurement.

Da @pinguin von einem funktionierenden deep-sleep berichtet hatte und @didilamken sich sehr positiv dazu geäußert hatte, voltage measurement-Funktionen zu implemenieren, wäre OTA auf jeden Fall eine Aufgabe, der du, @MKO, dich widmen könntest. Hättest du da Lust zu?

Lust schon, aber OTA ist ein relativ komplexes Thema.
Muß mich da erstmal ein wenig einarbeiten.
Müsste auch übers Webinterface also VUE implementiert werden. Heißt wieder einarbeiten oder vernünftige Beispiele finden.

Und die Frage ist woher kommt die neue Firmware? GitHub, FTP oder direkt von einer seperat bereitgestellten Datei.

Was ich vorher noch wichtiger finde, ist die bisherigen Bugs zu beheben, dafür müsste die Firmware mal in Sachen Webserver, Wlanmanager mal von Grund auf überarbeitet und die Betriebsmodi klarer definiert werden.

Hatte am Wochenende Mal versucht den AP Mode über Button (P2) zum laufen zu bekommen und bin auf eine ganze Kette von Falsch oder notdurftig an ungünstiger Stelle zusammengeflochten Code gestoßen.

Für OTA wäre es zumindest von enormen Vorteil, wenn man im Wlan-Mode und nicht nur im AP-Mode, das Webinterface über IP oder DNS erreichen könnte. Um Live abzufragen, ob eine neue Version verfügbar ist.
Das geht aber momentan nicht. Und wenn man es erzwinngt gibt es nur Fehlermeldungen oder Watchdog Neustarts.

Ich würde daher lieber doch erstmal dort ansetzen bevor wir noch einen zusätzlichen “Baustein” Notdürftig Reinflicken.

Wann wär den der Termin für den Köln Workshop? Nur, das man ungefähr abschätzen kann was bis dahin umsetzbar ist.

Im Notfall bleibt hier so etwas wie das hier.

1 Like

Bugs beheben ist auch eine sehr gute Idee. Könntest du alle, die
du bisher entdeckt hast, vielleicht als issues bei github
dokumentieren? Der Workshop ist jetzt am Sonntag, wir haben also
noch ne Woche Zeit, um Dinge zu fixen.

ota_updater = OTAUpdater('url-to-your-github-project')

Direkt von GitHub – nett! Gepaart mit einem ordentlichen Releasemanagement könnte da für einfachere source trees ein Schuh draus werden, wenn sich also die Struktur 1:1 aufs Dateisystem abbilden lässt. Ein schöner Fund, danke dafür!

Für andere Szenarien, innerhalb derer aus dem source tree erst im Zuge eines Vorgangs ein release tree entsteht, hatten wir unsere Hoffnungen auf Release-Archive im .zip oder .tar.gz Format gelegt, wie sie bei Releases · hiveeyes/terkin-datalogger · GitHub zu sehen sind. Ein alternatives Szenario “Download und entpacken einer Zip-Datei” wäre also ebenfalls nett.

Disclaimer: Bei solcherlei Träumereien bin ich mir natürlich hochgradig bewusst, dass das hier erstmal “wünschdirwas” Level ist. Ob das in der Realität machbar ist, wird sich erst zeigen, sobald man tiefer in die Materie im Pycom-Kontext einsteigt.


Die VBATT lässt sich so auslesen:

from machine import ADC
adc = ADC(0)

#ADW-Eingang G3 = P16 = VBATT mit Jumper BAT auf ExtensionBoard

adw = adc.channel(pin='P16',attn=ADC.ATTN_11DB)  #  max. 6.9 V
wert = adw()
print(' VBATT:', wert, end=' ')
ist  = 2727 # Wert des ADW
soll = 4.60 # Sollausgabe in V
volt = wert * (soll / ist)
print('Volt:', volt )

Zum Abgleich misst man mit einem Voltmeter die Spannung an Vin ( z.B. 4.60 V ) und gibt den zugehörigen ADW-Wert ( z.B. 2727 ) in die Variable ist und soll. Damit braucht man nicht die Werte des Spannungsteilers auf dem Expansionboard zu kennen. Das Verhältnis kann man einfacher messen als berechnen.
Beim BOB-HAT-V5 muss man die beiden Widerstände R10 und R11 einlöten und beachten, dass P16 doppelt belegt ist. Also SW1 und R5 nicht einlöten. Die Werte wurden unter

ausführlich diskutiert. Ich empfehle die Werte R10 ( 1M ) und R11 ( 470k )

Die Imker sollten da nicht nachmessen müssen, viele werden gar kein Multimeter Zuhause haben. Die Berechnung muss auf Grundlage der verwendeten Widerstände für den voltage divider erfolgen. Code dafür gibt es bei der hiveeyes-Firmware per class SystemBatteryLevel.

Bei paralleler Verwendung des expansion board muss der voltage divider dort deaktiviert werden.

Der attenuation -Faktor im code hängt von der maximal zu erwartenden Eingangsspannung und den verwendeten voltage dividern ab.

Man braucht ja nicht jedes Board individuell auszumessen, sondern nur verschiedene Widerstandspaare.
Für mein Expansionboard gilt der Faktor 4.60 / 2727 , ohne dass ich die Widerstandswerte kenne.
Vermutlich gilt er für alle Boards. Meins hat die Version V3.0r
Problem ist der genaue Wert bzw. die Toleranz der Widerstände. Verbauen die Chinesen 1% Widerstände?. Misst man mit einem Voltmeter für 10€ nach, hat man ausreichende Genauigkeit.