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

Hallo!

Ich habe seit knapp 2 Wochen, im Rahmen des Bob-Projektes, den FiPy mit den entsprechenden Sensoren hier in meinem Garten laufen.

Das ganze steht ca. 200m vom Haus entfernt und wird durch ein entsprechend langes Kabel mit Strom versorgt. Da mein WLAN nicht bis zu den Bienenstöcken reicht, habe ich noch ein CAT-5 Kabel verlegt und hinten im Garten eine FritzBox - zwecks WLAN - installiert.
Die Einrichtung der Hard- und Software war - dank guter Anleitung - recht simpel, so dass das Setup relativ schnell lief und Daten gesendet hat.

Seitdem musste ich jedoch schon mehrfach die Dose aufschrauben, um den Reset-Knopf zu betätigen, da der Datenversand in dieser Zeit schon 3-4 mal abgebrochen ist.

Heute Nacht um 00:40 Uhr war es wieder soweit. Nun hatte ich gerade mal versucht, per telnet auf das Gerät zuzugreifen, was zu meinem Erstaunen auch funktionierte.

Die telnet Session lässt sich noch aufbauen, aber danach hängt sie:

telnet 192.168.178.70
Trying 192.168.178.70…
Connected to espressif.fritz.box.
Escape character is ‘^]’.
MicroPython v1.9.4-81167ed on 2019-07-15; FiPy with ESP32
Login as: micro
Password:
Login succeeded!
Type “help()” for more information.

Eine Eingabe von z.B. “help()” ist dann nicht möglich. Es kommen auch keine sonstigen Ausgaben mehr…

Per FTP bin ich auch drauf gekommen, aber auch das verhält sich “ungewöhnlich”. Ein “ls” listet mir z.b. folgendes:
ftp> ls
502
502
150
^C
receive aborted
waiting for remote to finish abort
502
502

Gibt es eine Möglichkeit, zu sehen, was das Problem ist? (Logfiles o.ä.)
Bin ich der Einzige, der so ein Verhalten beobachtet?

Viele Grüße,
Frank

Ich habe meinen BOB seit Anfang Juni im Garten per Wlan-Repeater. Es liefen verschiedene Varianten von hiverize/FiPy mit meinen Modifikationen. Leider ist das Ganze noch nicht stabil. Der FiPy rebootet mehrfach am Tag. Da er alle 10 sec misst und sendet und der Reboot wenige sec dauert, fällt oft nur 1 Messwert aus, so dass man in der BOB-App nichts merkt. Nur ab und zu hängt er sich so auf, dass nur noch Strom aus/ein hilft. Das ist einfacher als Deckel ab und Reset drücken.
Ich benutze zur Anzeige der aktuellen Werte das OLED-Display. Ich gebe die Uhrzeit aus und zähle die Messzyklen. Ich sehe sehr selten Anzeigen über 1000 Zyklen. D.h. er rebootet in weniger als 1000 * 10 = 10000 sec = 166 min = 2,7 h. Das ist noch unbefriedigend.
Vor einem halben Jahr habe ich einen ESP32 DevKitC mit Arduino-IDE die gleichen Sensoren messen lassen: ich bin nonstop auf über 1 000 000 Messzyklen gekommen.
Ich vermute die Instabilitäten nicht in der Hardware ( ESP32 oder FiPy ) sondern in der Software ( MicroPython oder Arduino-IDE )
Beim Programmieren mit MicroPython ist mir aufgefallen, dass ein einziges Zeichen z.B. in der Formatierung ausreicht, um nicht nur eine Fehlermeldung, sondern auch einen Dauer-Reboot zu erzeugen.

1 Like

Hallo Frank,

unserer Erfahrung nach brauchen die Pycom Geräte mindestens einen aktivierten Watchdog, damit sie rund laufen. Ab und zu kommt das Gerät wohl in einen nicht gutartigen Zustand. Vielleicht ist es aber auch nur so, dass kurz™ das WLAN fehlt und das Gerät daher selbständig in den AP Modus wechselt?

Viele Grüße,
Andreas.

Hi!

Im AP Modus scheint er nicht zu laufen, da er ja über die IP erreichbar ist und der Webserver auch nicht läuft…

Mit aktiviertem watchdog meinst Du eine Hardware-Komponente, oder eine Software-Lösung? Bei letzterem: kommt die schon mit dem microPython mit und muss nur noch aktiviert werden?

Gruß,

Frank

Ja, das ist eine Software-Komponente, die aktiviert werden muss, allerdings ist das nicht ganz so einfach, man muss beim restlichen code auch schauen, dass der watchdog zuwischendurch “gefüttert” wird.

Wir haben mit der GitHub - hiveeyes/terkin-datalogger: Datalogger for MicroPython and CPython. schon eine Software-Version, bei der der watchdog eingebaut ist, allerdings hat diese Softwareversion noch keine Konfigurationsmöglichkeit über einen webbrowser und ist eher – in der aktuellen Version – für Leute, die sich auch mal an eine Konfigurationsdatei trauen und da von Hand änderungen vornehmen. Perspektivisch soll diese Software aber auch ein captive portal bekommen, so wie die momentan bei BOB eingesetzte Software.

Konkret könnte das für dich bedeuten die Software oben zu nutzen, dann mit “Komforteinschränkungen”, d.h. kompliziertere und aufwändigere Einrichtung von WLAN (das ist noch das einfachste), Zuordnung der DS18B20-Sensoren und Justierung der Waage. Oder eben zu waren bis die Software das captive portal hat.

Bei mir tauchten die Reboots auch ohne WLAN auf. Bei der Entwicklung von

habe ich sie an der seriellen Schnittstelle gesehen und der Zyklenzähler wurde zurückgesetzt. Eine Ursache habe ich nicht gefunden.
Ich finde, dass das Messen von Gewicht, Luftfeuchte und Temperaturen mit der Anzeige auf einem Display auch ohne Watchdog funktionieren sollte.

Hi Didi, ja, das finde ich im Prinzip auch. Und mit einem Arduino mit einer sequentiellen Code-Abarbeitung auf einem “Kern” funktioniert das ja auch, auch meine Seeduino-Software läuft seit mehreren Jahren und über Monate stabil.

Nun wollen wir die Dinge aber nicht nur messen, sondern auch wegschicken und dafür brauchen wir etwas mehr power und zusätzliche Bausteine. Wir haben zwei Möglichkeiten: entweder weiterhin den Arduino mit kleinem Speicher und begrenzter Rechenpower zu nutzen und als “Hilfs-chip” einen ESP oder ein GSM-Modul dranzuhängen, das von Speicher und Leistung x-mal mehr hat als der Arduino oder eben gleich einen ESP “für alles” zu nehmen. Und nun kommen halt mit der großeren power wieder andere Probleme rein. Besonders die zwei Kerne des ESP machen nun mit der alten Software, die ja keine Rücksicht auf parallele Prozesse nehmen musste, weil alles sequentiell abgearbeitet wurde, Probleme. Da muss die Software nun drauf Rücksicht nehmen. Da der ESP bzw. die Software noch relativ neu ist gibt es auch mehr bugs als in alten Arduino-Bibliotheken, die schon tausendfach und über Jahre im Einsatz und gereift sind. Wir sind halt da auch an der Spitze einer Entwicklung, die uns heute noch ab und an Zeit, Kopfzerbrechen und Schmerzen ;-) bereitet.

Bei parallelen Prozessen kann es immer wieder mal vorkommen, dass der eine auf den anderen wartet und man da nicht zusammenkommt, daher der watchdog als Zugeständnis unserer immer komplexer werdenden Hardware- und Softwarearchitektur und auch (noch) instabilerer Bibliotheken und Software.

Eine Frage, spricht für die Übergangszeit etwas dagegen den FiPy cyclisch jede Stunde automatisch kurz vom Stromnetz zu nehmen? Ich habe mittlerweile eine Homematic-Schaltsteckdose vor der Stromversorgung gesteckt. Diese kann ich zwar aus der Ferne schalten aber ich sehe ja nicht immer sofort wenn der FiPy hängt.

Wenn du den FiPy zusammen mit dem Extension Board verwendest und als Backup die Daten auf SD loggst ist es vielleicht keine so gute Idee spontan den Strom abzuschalten und das noch alle 60 Minuten. Falls da gerade die SD beschrieben wird könnte es sein, dass die komplette Backup-Datei korrupiert wird und nicht mehr lesbar ist.

Hi,

manuell zu bearbeitende config-files stellen erstmal keine Hürde dar. Allerdings habe ich mich noch nicht sehr intensiv mit dem Setup beschäftigt, so dass ich einen Startpunkt bräuchte, der beschreibt, wo die config files liegen und welches Format sie haben…!?
Könnte ich nicht einfach das config File der jetzigen Firmware sichern und an gleiche Stelle zurück spielen?
Auch habe ich noch keine so richtige Ahnung, wie der Flashvorgang bei der Hardware läuft… bislang habe ich immer mit rasperry pi’s und einer SD Karte gearbeitet :slight_smile:

Wo finde ich denn eigentlich die Firmware, mit denen die Komponente aktuell ausgeliefert wird?

Viele Grüße,
Frank

Ok,

die firmware habe ich drauf bekommen, im WLAN bin ich tatsächlich auch…
Wie ich die Sensoren konfiguriere, muss ich nochmal ausprobieren, und wie ich die Telemetrie an bee-observer.org schicke, ist mir auch noch Schleierhaft :slight_smile:
…da bin ich für jeden Tip natürlich dankbar!

(btw.: wie ich auf die alte Firmware zurück komme, ist mir aktuell allerdings leider auch noch ein Rätsel :frowning: )

Mit Atom und dem pymakr plugin ging dar restore der original firmware dann doch recht einfach :slight_smile:

2 Likes

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