WiFi-Konnektivität bei der Inbetriebnahme des FiPy hakelt

Leider nein. Wäre zu schön gewesen.

Was mich irritiert ist, dass er grün leuchtet, als ob alles in Ordnung wäre…

AHHHH :-D

Merci @Andreas für die ausführliche Anleitung/Hilfe.

Es lag an der Firmware. Upgedatet und schon verbindet er sich mit meinem Netz.

1 Like

Gern. Schön dass es klappt!

Welche jetzt genau? Die Primärfirmware von Pycom oder die Sekundärfirmware von BOB?

Die Primäre von Pycom.

Nur … jetzt verbindet er sich schon wieder nicht :_(

Hi Andreas,

Alles klar, danke. Du hast jetzt auch die neueste 1.20er drauf und die Sekundärfirmware blieb dabei erhalten?

Mist! Vielleicht ist die Batterie leer?

Möglicherweise ging es vorhin nur, weil das Gerät dabei am Rechner hing und dadurch mit Strom versorgt wurde?

Falls es nicht die Batterie ist, wäre das nächste die Frage nach dem Standort: Vielleicht geht es in der Nähe Deines Rechners, jedoch nicht am eigentlichen Einsatzort des Geräts. Dafür gibts dann wieder haufenweise Ursachen…

Viele Grüße,
Andreas.

Also ich hab noch mal die Firmware upgedatet via “Pycom Firmware Update” da steht 1.18 drin. Nicht 1.20

Dann ists vermutlich die “stable” Pycom MicroPython 1.18.2.r7, die sollte auch gut gehen. Pycom MicroPython 1.20.0.rc11 ist die “development” Firmware, die wir bisher auch erfolgreich verwenden. Man kann die im Pycom Updater irgendwie zuschalten. Daran sollte es aber erstmal nicht scheitern – Hauptsache überhaupt die jeweils aktuellste.

Wie bekomme ich denn jetzt die neueste Hiverize Version drauf?

Mit Atom? Muss ich die Dateien aus dem GitHub runterladen und dann via Atom auf den FiPy laden? Oder geht das via Terminal irgendwie direkt?

Guten Morgen Andreas,

So könnte es klappen. Ich habe jedoch noch nie mit Atom oder der Hiverize Firmware gearbeitet, so dass ich Dich hier zum “wie genau” auf @vinz, @Diren, @clemens oder vielleicht auch @didilamken verweisen muss.

Mit Git bzw. GitHub könnte ich Dir bei den ersten Schritten weiterhelfen, falls Du hier Ideen brauchst.

Drüben bei der Hiveeyes MicroPython Datalogger Firmware benutzen wir GitHub - dhylands/rshell: Remote Shell for MicroPython für den Dateitransfer. Das ist zwar noch nicht für die Hiverize Firmware erschlossen bzw. dort fertig ins Repository eingebaut, man könnte sich das aber vornehmen.

Hier findest Du, wie wir die “rshell rsync” Befehle verdrahtet haben:

Vielleicht gibt es bei Pymakr/Atom auch irgendein commandline Programm, mit dem man den Dateitransfer komfortabel in einem Aufwasch erledigen könnte, auf einer Komfortstufe oberhalb von rshell. Für entsprechende Hinweise wären wir sehr dankbar.

Viele Grüße,
Andreas.

Ja, Kommandozeile hab ich wohl schon gefunden… ‘git clon’ funktioniert leider nicht :-(

git clone https://github.com/Hiverize/FiPy.git

auf der command line geht nicht? Hm, dann ist aber wohl entweder git nicht installiert oder es ist umfassenderes am Netzwerk krumm?

Fein. Würde uns freuen, wenn wir damit eine Anleitung für alle Nutzer hinkriegen, die “nur mal eben schnell” Pymakr/Atom installieren und neu flashen möchten.

Zwei Dinge vielleicht doch noch kurz.

  1. Sichere Dir vor dem Überschreiben vielleicht sicherheitshalber Deine user_settings.json und vielleicht zusätzlich die default_settings.json. Wegen “Better safe than sorry”.

  2. Formatiere Dein Flash-Dateisystem am besten gleich mit dem LittleFS-Format, wenn Du ohnehin schon neu aufspielst. Dadurch kannst Du filesystem corruption vermeiden, siehe FiPy verliert Programm nach power off durch leeren LiPo / file system corruption through brownout conditions - #3 by Andreas.

Das klappt in der REPL-Umgebung auf dem Gerät folgendermaßen:

import pycom
pycom.bootmgr(fs_type=pycom.LittleFS, reset=True)

Hinweis: Beim Wechsel zwischen LittleFS und FatFS wird das Flash-Dateisystem neu formatiert, wodurch alle Inhalte gelöscht werden.

Note: When switching between LittleFS and FatFS, the flash file system will be re-formatted thus erasing all content.

@didilamken und @Hermann schrieben über ihre ersten Schritte:

Danke!

Bin gerade wieder mal am probieren und testen.
komme dabei fast zum schluß, das es nicht zwingend das Wlan sein muß.
Kann beobachten, das es mal mit den Einstellngen funktioniert und dann gerät er wieder mal in eine art Rebootschleife wegen einer Fehlermeldung, die ich noch nicht weiter untersucht habe:

rst:0x7 (TG0WDT_SYS_RESET),boot:0x13 (SPI_FAST_FLASH_BOOT)

ab und an scheint es aber zu gehen sogar mit WPA2. Was bei mir doch für einiges an Verwirrung sorgt.
er speichert bei mir auch ein komplettes abbild aller vorhandenen SSID in der Umgebung in der user_settings.json ist das notwendig?
Habe auch mal mit einem WiPy getestet (Dort läuft die BOB Software übrigens aktuell genauso gut/schlecht) dort ist aber das kompl. gleiche Phänomen.
Für mich verhält sich momentan “Atom” und die Programmierung des FiPy sowieso etwas merkwürdig und willkürlich.
Was aber sicherlich noch an meinem fehlendem Hintergrundwissen liegt. Versuche mich mal besser einzuarbeiten.

Für alle die Probleme mit der Verbindung Zwischen ATOM un FiPy haben noch ein kleiner Tip.
Ich musste Unter File/config/ noch bei pymakr: autoconnect_comport_manufacturers:
noch Pycom Ltd hinzufügen damit er auch automatisch zum FiPy verbindet.

Hi Michael,

WDT ist der Watchdog Timer. Da zieht wohl jemand den Stecker.

Manchmal hakts da. Ja, das wurde uns auch schon berichtet. Wir arbeiten rein auf der Kommandozeile per rshell und dort läufts ganz gut. Ohne deterministische Sandbox könnte man überhaupt nicht ordentlich arbeiten, außer halt mal ein paar Schnipsel hier und da per copy&paste… ;].

Ich weiß, dass @vinz und @Diren ordentlich an der Firmware gearbeitet haben, aber aus der Erfahrung bei GitHub - hiveeyes/terkin-datalogger: Datalogger for MicroPython and CPython. weiß ich: Der Teufel steckt hier schon sehr im Detail und die cycle Zeiten sind lange – da dauert es, bis man auf allen edge cases den Deckel drauf hat.

Viele Grüße,
Andreas.

Ja, nach etwas suche im WWW habe ich gelesen das es auch die Spannungsversorgung sein kann, die zusammenbricht.
Da ich Ihn am Expansionsboard 3.1 am PC hängen habe kann das sehr sein.

Muß jetzt schauen, wie ich das ausschließen kann. Geht USB und eine zusätzliche Versorgungsspannung am Expansionsboard oder zerschieße ich mir da etwas?

Weiß aus dem 3D-Druckerbereich das man ab und an auch ein "Spezielles USB Kabel mit abgetrennter + Leitung verwenden muß.

Ja, da gibt es einige Möglichkeiten. Wir haben die ausführliche Internetrecherche vor noch nicht allzulanger Zeit gemacht und bei Power supply for the ESP32 zusammengefasst.

Davon haben wir bisher noch nichts gehört, dass das am Expansionboard liegen kann. Eher an den Dingen wie sie oben genannt sind, z.B. am Kabel ;].

Ich bin froh, dass ich funktionierende Hardware hier stehen habe und kann dazu nichts sagen, weil ich mich mit der Elektrik der Hardware leider null auskenne. Sorgfalt ist dabei bestimmt angebracht, gerade wenn es um Strom geht.

Viele Grüße,
Andreas.

Meinte da nicht das Epansionsboard sondern die Spannungsversorgung übers Board vom PC.

Gerade weil ich mich mit Elektronik sehr gut auskenne gehe ich leider immer vom schlimmsten aus.
wenn man 2 Spannungsquellen verwendet können wenn die Schaltung das nicht vorsieht die internen Spannungsregler Überlastet und Zerstört werden.

Werde sicherheitshalber mal mein Spezialkabel verwenden, solange ich nichts gegenteiliges höre.
Habe dann sogar noch einen Zusätzlichen Vorteil ich kann dann sogar Parallel die Stromaufnahme Messen.
Bin mal gespannt was da raus kommt.

Wenn ich mich recht entsinne, habe ich die massiven Probleme nicht von Anfang an. Erst nach dem ersten Problemen mit dem WiFi bin ich vom externen Netzeil an den PC und habe versucht dort den Fehler zu analysieren. Ab da wurde es etwas Paradox und irgendwie noch schlimmer.

Gruß Michael

Heute nachmittag war das Fernsehteam von “naturnah” bei mir im Garten in Otterstedt und wollte den Einbau der Sensoren mit Bienen filmen. Natürlich hatte ich alles bei mir am Schreibtisch in Bremen getestet und Konfiguriert. Es lief alles perfekt bis zum Abbau um 14 Uhr.
Dann der Vorführeffekt im Garten mit den gleichen Sensoren. Der Fipy wollte nicht messen, sondern nur neu konfiguriert werden. Da ich in Otterstedt noch kein WLAN habe, habe ich die LEDs zur Anzeige programmiert: rote LED für Konfiguration, grüne LED blinkt alle 10 sec wenn ein Datensatz fertig ist.
Es hätte also grün blinken sollen. Das Fernsehteam hat trotzdem schöne Bilder gemacht, das Wetter war sehr gut.
In der letzten Woche hatte ich Hermanns FiPy mit Sensoren bei mir fertig gemacht, er hatte bei sich ähnliche/gleiche Probleme.
Ich werde heute Abend die Probleme analysieren.

Ich habe gerade alles am Schreibtisch eingeschaltet: es geht wieder.
Wo war der Fehler?

Hallo Didi,

Kabel/Strom oder Standort?

Viele Grüße,
Andreas.