So, gerade nochmal ausprobiert:
make setup
Schlug fehl beim “setup-virtualenv2”. Ich musste virtualenv nochmal mit pip deinstallieren und mit conda neu installieren. Danach lief make setup durch
make install läuft jetzt auch ohne Fehler durch und endet mit:
Installing setuptools, pip, wheel…done.
[INFO] Installing mpy-cross
[INFO] Installing mpy-cross-all
Allerdings scheint die onewire.py immer noch nicht auf dem Gerät gelandet zu sein. Der Fehler ist leider bestehen geblieben :-(
Hi Frank,
vielen Dank für Deine Beobachtungen.
Kannst Du sicherstellen, dass die Datei im lokalen Verzeichnis dist-packages vorhanden ist? Bei mir sieht das folgendermaßen aus:
$ l dist-packages/onewire/
total 16
drwxr-xr-x 4 amo staff 128 Aug 28 12:10 ./
drwxr-xr-x 24 amo staff 768 Aug 28 12:10 ../
-rw-r--r-- 1 amo staff 0 Aug 28 12:10 __init__.py
-rw-r--r-- 1 amo staff 7391 Aug 28 12:10 onewire.py
Viele Grüße,
Andreas.
Hi @Andreas,
ja, die Datei ist bei mir lokal vorhanden. Aber das kopieren beim “make install” scheint in der Tat Probleme gemacht zu machen. Auch nach mehrmaligen “make install” kam die Datei nicht sauber auf das Gerät.
Erst nachdem ich per “rsync rm -rf /flash/” einmal den kompletten flash-Ordner vom Gerät gelöscht hatte, hat der anschliessende “make install” das Problem jetzt wohl behoben.
Da es gerade regnet, kann ich die Sensoren (die in der Beute hängen), nicht anschliessen. Der finale Test steht also dann in den nächsten Tagen noch aus 
Gruß,
Frank
Wunderbar. Danke für die Info und viel Erfolg bei der erneuten Inbetriebnahme nach dem Regen.
Bei mir läuft die Version 0.6.0 mit Atom und Pymkr seit Mo. 3.9. leider mit einigen Aussetzern: die Telemetrie setzt aus, das Messen ging weiter wie ich an der seriellen Schnittstelle gesehen habe:
Heute um 11:23 fiel der Update wieder aus, ich wollte mit der seriellen Schnittstelle nachsehen, doch der FiPy reagierte auch auf Reset nicht, obwohl die LED kurz blau blinkte. Erst Strom aus/ein hat ihn wiederbelebt.
Frage: kann der Watchdog Fehler erkennen und bei Bedarf einen Reboot auslösen?
An der WLAN-Verbindung kann es nicht liegen, da zur gleichen Zeit am gleichen AP dieses Notebook und mein erster FiPy ohne Fehler online waren.
Hallo Didi,
vielen Dank für Deine Beobachtungen. Hast Du den Watchdog in Deiner settings.py aktiviert? Im Auslieferungszustand ist er das noch nicht:
Außerdem ist der Betrieb im Deep Sleep Modus empfehlenswert, weil er die sicherste Betriebsart darstellt, da der Datenlogger bei jedem Meßzyklus komplett neu anläuft. Dieser muss ebenfalls aktiviert werden:
Für ein weiteres Debugging der Probleme mit der Konnektivität wären Auszüge aus den Logdateien sehr hilfreich. Um Core Dumps entsprechender Totalabstürze erfassen zu können, haben wir die Ausgaben der seriellen Schnittstelle über Monitoring and recording the serial interface output of a microcontroller attached to an UART interface mitgeschnitten.
Viele Grüße,
Andreas.
Langsam komme ich der Sache näher.
Die Temperatur-Sensoren funktionieren jetzt und sind auch korrekt konfiguriert.
Mit der kalibrierung der Waage habe ich noch so meine Verständnis Probleme:
Auf der Waage stehen aktuell 37,2kg. Was muss ich denn jetzt bei scale eintragen? Sind das g oder kg Werte? Ich hatte jetzt auf gut Glück mal mit kg gerechnet und bei scale 37.2 eingetragen.
Den Offset hatte ich auf 0.0 stehen und als Wert kam dann 20483.4 raus. Also müsste ich als offset vermutlich 20446.2 eintragen!? Oder liege ich mit meiner Annahme komplett falsch?
Des weiteren habe ich jetzt komischerweise Probleme beim Übertragen der Telemetrie an bee-observer.org: (zu debugging Zwecken habe ich die Daten mal ausgeben lassen)
32.7726 [terkin.telemetry ] WARNING: Sending data: "{'p': 1011.389, 't_i_1': 33.0, 't_i_2': 33.25, 't_i_3': 21.0625, 't_i_4': 14.1875, 'h': 81.50586, 'weight_kg': 20483.37, 't_i_5': 11.875, 'key': 'GVk8CXLeJrLsp9Vw', 't': 12.24704, 'bv': 3.71, 't_o': 8.8125}"
32.8048 [terkin.telemetry ] INFO : Sending HTTP request to https://bee-observer.org/api/sensors
33.4056 [terkin.telemetry ] ERROR : Telemetry to https://bee-observer.org/api/sensors failed
Traceback (most recent call last):
File "/flash/lib/terkin/telemetry.py", line 120, in transmit
File "/flash/lib/terkin/telemetry.py", line 280, in transmit
File "/flash/lib/terkin/telemetry.py", line 338, in send
File "/flash/dist-packages/urequests/__init__.py", line 144, in post
File "/flash/dist-packages/urequests/__init__.py", line 60, in request
TypeError: function takes 2 positional arguments but 4 were given
Hast Du eine Idee, was da schief läuft?
Ich glaube, dass bei mir die Fehlermeldung ähnlich war, die ich nicht dokumentieren konnte.
Ok. so wie es aussieht, kennt die Methode “usocket.getaddrinfo()” der von “mir” benutzten micropython Version (1.9.x?) nur 2 Parameter. Die neuste Version (latest) kennt aber 4 Parameter.
Das urequests-Paket (urequests/init.py, Zeile 60) ruft die Methode jedoch mit 4 Parametern auf, erwartet also eine neuere micropython Version!?
Nun kenne ich mich mit dem Paketmanagement von python nicht so gut aus, gehe aber davon aus, dass dort immer die neuste Version der jeweiligen Pakete geladen wird und somit die Version pycopy-urequests-0.9.3 zu neu für meine micropython Installation ist!?
Wie bekomme ich das micropython ge’upgradet?
Hallo Frank,
vielen Dank für Deine Nachforschungen. Es gibt durchaus Anomalien zwischen verschiedenen MicroPython Versionen und Varianten, die sich mehr oder weniger stark auf die Kompatibilität auswirken können.
Ja, so sehe ich das auch.
Innerhalb des Pycom-Universum klappt das derzeit leider gar nicht ohne weiteres.
Wir müssen andersherum vorgehen: Dadurch, dass die Version des Moduls pycopy-urequests nicht auf einen festen Wert gepinnt war, hat vermutlich ein aktuelleres Release dieses Moduls dazu geführt, dass es nicht mehr kompatibel zum Pycom-Universum ist.
Das müssen wir bei der Vorgehensweise im Rahmen von make setup entsprechend ändern, vermutlich indem wir die Quellen der älteren Version von pycopy-urequests 0.9.2 benutzen.
Unabhängig davon finden sich kohärente und getestete Module auch immer in den Release-Paketen bei Releases · hiveeyes/terkin-datalogger · GitHub.
Viele Grüße,
Andreas.
So,
ich habe die init.py in der urequests jetzt erstmal manuell angepasst und die Waage kalibriert - und jetzt kommen auch valide Daten…
Ich lasse das jetzt mal in der Konfiguration laufen und bin gespannt, wie die uptime sein wird.
Der watchdog ist aktiviert und deepsleep läuft auch
Vielen Dank auf jeden Fall für das Stück Software! 
Viele Grüße,
Frank
Das ist wirklich seltsam. Die erwähnte Zeile ist sowohl in den Erweiterungsbibliotheken von Vanilla MicroPython als auch im Pycopy-Fork vorhanden und weist keine frischen Änderungen auf.
https://github.com/micropython/micropython-lib/blob/master/urequests/urequests.py#L53-L53
https://github.com/pfalcon/pycopy-lib/blob/master/urequests/urequests/\_\_init\_\_.py#L60-L60
Das legt die Vermutung nahe, dass die Funktion usocket.getaddr schon länger so gerufen wird. Den von Dir zur Verfügung gestellten Stacktrace sehe ich jedoch, daher würden mich die genauen Details Deiner Laufzeitumgebung interessieren.
Unser Softwarestand ist der folgende:
=====================================
Hiveeyes MicroPython Datalogger 0.6.0
=====================================
CPU freq 160.0 MHz
Device id 807d3ac342bc
Python : 3.4.0
lorawan : 1.0.2
machine : FiPy with ESP32
nodename: FiPy
release : 1.20.0.rc12.1
sigfox : 1.0.1
sysname : FiPy
version : 6c0000f on 2019-08-01
Das ist wirklich seltsam.
Die API Doku von micropythons usocket besagt für Version 1.9.3 etwas anderes:
http://docs.micropython.org/en/v1.9.3/pyboard/library/usocket.html
Mein FiPy scheint nicht ganz so gesprächig, wie Deiner:
=====================================
Hiveeyes MicroPython Datalogger 0.6.0
=====================================
CPU freq 160.0 MHz
Device id 807d3ac31d0c
Python : 3.4.0
Aber ich hab vor kurzem ein Firmware Update eingespielt und hatte, wenn ich mich recht entsinne, die letzte stabile Version genommen. Das müsste die 1.16.0 (stable) gewesen sein
Bitte versuche einmal die letzte development Version, vor ein paar Tagen war es die 1.20.0.rc13, die nutzen wir gerad und sie läuft ohne Probleme.
Ich glaube ich hatte mit der letzten stable und der hiveeyes software auch Probleme, kann sein dass sie beiden inkompatibel sind. … und littleFS als Filesystem nicht vergessen!
Hi @clemens,
ich denke, lass es erstmal in dem jetzigen Setup so laufen - sieht für den Moment zumindest stabil aus.
Sollte ich Probleme feststellen, werde ich auf den develop snapshot mit littleFs wechseln…
Gruß,
Frank
Ah, daher weht der Wind. Ja, wir haben uns im Entwicklungsverlauf schon früh für die development version der Pycom Firmware entschieden. Hier haben scheinbar bereits teilweise Features aus MicroPython 1.10bis per Backport Einzug gehalten.
Ab MicroPython 1.10 hat die Funktion usocket.getaddrinfo() offiziell die erweiterte Signatur spendiert bekommen.
usocket.getaddrinfo(host, port, af=0, type=0, proto=0, flags=0)
– usocket – socket module — MicroPython 1.10 documentation
Die Ergebnisse dieser Analyse zeigen uns, dass wir ggf. also keine Feature-Flag-Auswertung bzw. entsprechende Plattform-Weichen nur rein an die MicroPython-Versionsnummer kleben können – genauso wenig wie wir ebensolche Dinge rein an Dinge wie sys.platform o.ä. kleben können.
Wenn das wirklich die einzige Änderung ist, die die Firmware sonst an der Lauffähigkeit auf einem älteren Versionsstand der Pycom-Firmware hindert, freuen wir uns und nehmen diese Änderung gern in die Codebasis auf.
Grundsätzlich empfehlen wir jedoch eine modernere Firmware-Version und damit vor allem die Formatierung des eingebauten Flash-Dateisystems mit dem LittleFS-Dateisystem aufgrund deutlich verbesserter Robustheit ggü. Dateisystemkorruption.
Ich muss leider berichten, dass es mit meinen Setup (Firmware 1.16.0) leider nur ein kurzes Vergnügen war und die Datenübertragung heute Nachmittag um 15:59 Uhr endete…
Als ich gerade an den Bienenstand ging, blinkte auch die LED nicht mehr.
Ich hab jetzt auch mal die 1.20.0.rc13 aufgespielt und auf LittleFS ge’switched und hoffe auf mehr Stabilität
Gruß,
Frank
Bei mir läuft das System auch nur ca. 24 Std. Ich stecke aber nicht so tief in der Materie, kann jemand erläutern wie ich auf das LittleFS-Dateisystem wechseln kann und eine neue Firmware bzw. Programmversion installieren kann? Werde mich sehr freuen. Danke dafür im Voraus
Hallo zusammen,
neben dem Wechsel auf LittleFS, um Dateisystemkorruption beim Brownout zu vermeiden, ist auch die Aktivierung des Watchdog essentiell für einen robusten Betrieb.
Viele Grüße,
Andreas.
Nächste Woche gibt es eine ausführliche Anleitung, wie man unter Windows mit dem PyCom-Firmware-updater und Atom / alternativ FTP das anstellt.