Unterstützung beim Debugging von Abstürzen und der Installation der Firmware

Du hast es mittlerweile ja geschafft, super, hier der Vollständigkeit halber:

Die letzte Version von Andreas’ / hiveeyes software liegt als release unter:

Hier ist auch nochmal die zugehörige config / settings-Datei:

Ne, das geht leider nicht, weil die nicht kompatibel sind. Die hiverize-settings-Datei ist JSON (s. FiPy/default_settings.json at master · Hiverize/FiPy · GitHub) die von Andreas nicht. Man könnte aber die Werte aus der einen in die andere übertagen, nicht 1:1 aber angepasst.

Das ist diese hier: GitHub - Hiverize/FiPy

Du redest jetzt von der hiveeyes / Andreas’-Software, ja. Da muss erst mal die telemetrie zu BOB aktiviert werden:

'enabled': True, muss da stehen. Und dein “Sensor-Key” muss noch ergänzt werden.

Dann noch ganz unten in der settings.py einen Abschnitt editieren:

dann kommen die Daten auch bei bee-observer.org an.

1 Like

Wow, großartig. Bei der Steilvorlage kann ja kaum noch etwas schief gehen…

Ich versuche das die Tage mal.

Vielen Dank auf jeden Fall schon mal!

1 Like

Guten Morgen!

Nachdem ich der “hiverize/Fipy” Firmware nochmal eine Chance gegeben habe, diese aber schon nach 1,5 Tagen wieder abgestürzt war, würde ich mich jetzt doch nochmal ernsthaft an die von Andreas wagen.
Die Telemetrie wurde dabei auch schon übertragen, allerdings habe ich meine Probleme mit den Temperatur-Sensoren. Handelt es sich um ein Hardware-/Software- oder Konfigurationsproblem?

Hier ein Logfile-Auszug:

   27.0364 [terkin.sensor.core       ] INFO   : Starting all busses [{'enabled': True, 'family': 'i2c', 'pin_scl': 'P10', 'pin_sda': 'P9', 'id': 'bus-i2c-0', 'number': 0}, {'pin_data': 'P11', 'id': 'bus-onewire-0', 'number': 0, 'family': 'onewire', 'enabled': True}]
   27.0950 [terkin.sensor.core       ] INFO   : Found 1 I2C devices: [119].
   27.1079 [terkin.sensor.core       ] INFO   : Registering bus "i2c:0"
   27.8373 [terkin.sensor.core       ] ERROR  : 1-Wire hardware driver failed
Traceback (most recent call last):
  File "/flash/lib/terkin/sensor/core.py", line 205, in start
ImportError: no module named 'onewire.onewire'

   27.8588 [terkin.sensor.core       ] INFO   : Registering bus "onewire:0"
   27.8696 [terkin.datalogger        ] INFO   : Registering system sensors
   28.0385 [hiveeyes.datalogger      ] INFO   : Registering Hiveeyes sensors
   28.0619 [hiveeyes.datalogger      ] INFO   : Setting up HX711 sensor with id "scale-1" described as "Waage 1"
   29.1664 [hiveeyes.sensor_hx711    ] INFO   : Selected HX711 hardware driver "heisenberg"
   29.1882 [hiveeyes.sensor_hx711    ] INFO   : Initializing HX711 sensor with pin_dout=P22, pin_pdsck=P21, gain=128, scale=4.424242, offset=-73000
   29.2062 [hiveeyes.datalogger      ] INFO   : Setting up DS18B20 sensor with id "ds18b20-1" described as "Wabengasse 1"
   30.0673 [terkin.sensor.core       ] INFO   : Trying to find bus by name "onewire:0"
   30.0808 [terkin.sensor.core       ] INFO   : Found bus by name "onewire:0": <OneWireBus object at 3f99da20>
   30.1947 [hiveeyes.sensor_ds18x20  ] ERROR  : DS18X20 hardware driver failed
Traceback (most recent call last):
  File "/flash/lib/hiveeyes/sensor_ds18x20.py", line 29, in start
ImportError: no module named 'onewire.onewire'

Viele Grüße,
Frank

Welche Software-Version hast du denn verwendet? Bei mir läuft das letzte release https://github.com/hiveeyes/hiveeyes-micropython-firmware/releases/download/0.6.0/hiveeyes-micropython-firmware-0.6.0-source.zip sehr stabil. War alles komplett hochgeladen? Die Fehlermeldung hört sich so an als ob onewire.onewire nicht gefunden wird. Bei mir liegt eine Datei onewire.py in dist-packages\onewire

Verwendest du Atom zum Hochladen der Software auf den Fipy oder die sog. “sandbox” / Komandozeilenbasiert mit make ... unter Linux / WSL?

Ich verwende die 0.6.0 und habe sie mittels sandbox hochgeladen.
Ob der Upload sauber funktioniert hat, kann ich nicht mit Sicherheit sagen, da ich die Meldungen nicht mehr parat habe. Kann natürlich sein, dass dabei etwas fehlgeschlagen ist…
Auf jeden Fall hat der “make install” sehr lange (ca. 5 Minuten) gedauert

Ich versuche es heute Abend nochmals per Atom

Hast du vorher ein make setup gemacht? Das verschiebt ein paar Dinge von den installationsverzeichnissen an die Stellen wo sie beim Hochladen gebraucht werden, s. Setup commandline-based MicroPython development environment on Linux, macOS and Windows

Ja, den hatte ich gemacht - der war aber auf jeden Fall mit Fehlern abgebrochen. (die habe ich hier leider auch gerade nicht parat)
Ich versuch’s heute Abend oder morgen früh nochmal

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 :slight_smile:

Gruß,
Frank

1 Like

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:


In der 3. und 4. Zeile war die Fehlermeldung, die ich leider nicht dokumentieren konnte.

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.

1 Like

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?

1 Like

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?

1 Like

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! :slightly_smiling_face::+1:

Viele Grüße,
Frank

2 Likes

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