Wir haben es mit Problemen an mehreren Fronten zu tun.
Als erstes habe ich das main.py mit den Messungen durch ein sehr einfaches main.py mit Tests von RGBLed, Switche und I2C-bus in Dauerschleife ersetzt. Alle anderen Files sind unverändert vom 10.5.2021. Die Idee war, wenn es ohne Fehler durchläuft, muss der Fehler im ersten main.py sein. Aber es crashte ebenfalls oft.
Ich wollte noch andere Testfiles testen, aber beim Flashen mit Pymkr gab es viele Probleme und Abstürze bis gar nicht mehr ging. Ich vemute, der Flash vom FiPy Nr. 3 ist defekt.
Also den FiPy Nr. 4 geholt. Die Testprogramme von vor 2 Wochen liefen noch, doch Flashen mit Pymkr ging gar nicht mehr.
Mit Thonny konnte ich dann lib… logger… sensors… default_settings.json, user_settings.json, boot.py und main.py flashen. Das kleine main.py lief eine Stunde in Dauerschleife ohne Probleme, das grosse lief ohne import von webserver.py ohne crash, mit import von webserver,py stürzte es mit den oben beschriebenen Fehlern ab.
Ich bin jetzt genau so weit wie vor zwei Tagen.
Es gibt also Probleme mit dem Flash im FiPy UND beim flashen mit Pymkr.
Dazu noch eine Vermutung. Im Sommer 2019 war ich Python-Anfänger und die ganze Software in den libraries und in main.py undurchschaubar für mich. Also bin ich angefangen, kleine Testprogramme zu schreiben, in denen ich mich um einzelne Themen kümmerte. So entstanden einige unabhängige Testprogramme für BME280, DS18B20, HX711, OLED, config, WLAN, SD-Karte usw.
Bei den DS18B20 wurde viel über Messwertausreisser diskutiert. Mir fiel dann auf, dass CRC-Error im Treiber nicht sauber abgefangen wurden und execptions zum Absturz führen konnten. Im Hauptprogramm war das durch GarbageCollector und Watchdog nicht leicht zu erkennen.
Ebenso stockte der FTP-Transfer. Da war ein “_” bei der Initialisierung die Ursache.
Deshalb befürchte ich immer noch Unsauberkeiten im Code, die nur manchmal auffallen und nur sehr schwer zu finden sind.
Wir sollten nicht mehrere Baustellen parallel aufmachen, wenn wir nicht wissen wo das Problem ist. Fakt ist ja, dass Diren / Uni Bremen und andere das Ding irgendwie fliegen, d.h. bis auf die bekannten Macken und Unzulänglichkeiten sollte “die Software” laufen.
Bei der Firmware brauchen wir zwingend die in der Doku
wegen der Onewire-Implementierung, d.h. die ist gesetzt!
Die IDE transportiert im besten Fall nur Dateien vom Rechner zum FiPy, d.h. eigentlich sollte Atom oder VS Code egal sein, wenn die Dateien mal auf dem Gerät sind. Da Atom letztes Jahr eingemottet wurde und (für mich) auch unklar ist, ob es überhautp ein working plugin für eine Neuinstallation gibt, würde ich für den Workshop auf jeden Fall VS Code empfehlen, bzw. das den Leuten empfehlen, die noch am Code Hand anlegen wollen.
Nun ist noch die Frage, warum der Code von GitHub - Hiverize/FiPy bei dir, @didilamken nicht funktioniert. Bei mir scheint er ja zu laufen, abgesehen von den (bekannten) AP-Problemen. Du hast auch die Firmware von oben verwendet und die neueste Version des firmware update tools, gibt es da Eintellungen, die zu Problemen führen können?
Bringt “erase flash file system” etwas? Als FS ist LittleFS angegeben, das war in der Vergangenheit ja auch immer ein massiver Instabilitätsfaktor falls nicht, die Probleme oben bei dir hören sich etwas danach an, manchmal geht es manchmal nicht, unvorhergesehene Abstürze … magst du nochmal doublechecken, ob LittleSF beim Firmware einspielen aktiv war und “Enable Pybytes” deaktiviert ist?
Ah, https://thonny.org/ “Python IDE for beginners”, kannte ich bisher gar nicht.
Das Firmware Update Tool von PyCom läuft in der neuesten Version auch auf dem neuen Notebook sehr gut, die Einstellungen habe ich auch alle beachtet. Da sehe ich keine Probleme.
Mit /lib/onewire.py funktionieren die DS18B20 mit beiden … vanilla-squirrel… Firmware Versionen
Atom läuft nur noch auf dem alten Notebook und PyMkr hakte schon früher manchmal.
Der Menüpunkt " Download from device " ging nie richtig und " Upload projekt to device " stottert heute.
Mit der händischen Konfiguration in user_config.json funktioniert FiPy Nr. 4 seit gestern Abend. Also sollten FiPy, Flash, Firmware, die Libraries und main.py OK sein.
Bleibt die Frage, warum der webserver nicht will.
Eben gerade habe ich an der seriellen Schnittstelle beobachtet, daß das Messen gestoppt hat und der AP für 10 Minuten aktiv war, dann startete das Messen wieder, als wenn nichts geschehen wäre.
Warum ??? Auf dem Bienenmonitor ist nichts zu erkennen.
13 Uhr
Ich habe versucht, 15 FiPy mit der BOB-Software zu flashen : bei 12 hat es auf Anhieb geklappt, bei 2 erst beim zweiten Mal und 1 ist definitiv kaputt. Der hat mir auch am Freitag so viel Ärger bereitet.
Vorgehensweise: mit Atom / pymkr müssen 30 Files zügig geflasht werden. Beim kleinsten Problem muss Atom/pymkr neu gestartet werden. Beim anschliessenden Boot muss sofort das Wlan verbunden werden und es müssen mindestens 50 Messungen zum Bienenmonitor gesendet werden.
Die beiden Wiederholer wurden mit dem Pycom Updater neu geflasht.
Beim dritten kommt jede Hilfe zu spät.
16 Uhr
Es scheint Probleme mit dem Flash zu geben: ein FiPy, der nicht auf Anhieb geflasht werden konnte, sondern erst beim zweiten Mal, hat dann schon gemessen. Aber in der letzten Stunde hat er mitten im Messen gedacht, der Switch an P16 wäre gedrückt und hat den AP aufgemacht. Da der webserver.py noch auskommentiert ist, kann man sich zwar mit einem Tablet verbinden, erhält aber keine Webseite. Nach 10 Minuten schliesst der AP und das Messen geht weiter.
Im Bienenmonitor fällt das kaum auf, man muss schon danach suchen.
Ich schliesse inzwischen einen schlechten Flash nicht mehr aus, um die seltsamen Fehler zu erklären.
Ich habe gestern von @Diren eine neue FiPy-Firmware bekommen. Sie gleicht in Namen und Größe der, die ich schon benutzt habe . FiPy-1.20.2.rc6-0.10.2-vanilla-squirrel-nosmartconfig.tar.gz (1,2 MB) ( 1188 KB in Windows10 ).
Also noch einmal geflasht ( alles OK ). Dann mit Atom die FiPy-Programme aufgespielt ( alles OK )
Doch beim reboot der gleiche Fehler wie am Wochenende:
Vielleicht kann ja jemand die folgenden Meldungen interpretieren:
entry 0x400a05bc
Starting boot process...
Boot finished.
Init -> CSV logger in directory /sd/hiverizelog
init sensors
init -> DS18B20
Found 6 DS1820.
Gain & initial value set
in webserver.py
Traceback (most recent call last):
File "main.py", line 14, in <module>
File "webserver.py", line 142, in <module>
File "/flash/lib/microDNSSrv.py", line 19, in Create
File "/flash/lib/microDNSSrv.py", line 161, in Start
OSError: Network card not available
Pycom MicroPython 1.20.2.rc6-0.10.2-vanilla-squirrel-nosmartconfig [v1.20.1.r2-122-gd82a6f43e-dirty] on 2020-03-06; FiPy with ESP32
Type "help()" for more information.
'>>>
Datei main.py
import sys
import time
import uos
'# own code imports
import webserver -> line 14
from config import Config
from sensors import hx711, bme280, ssd1306, ds1820
def Create(domainsList) :
mds = MicroDNSSrv()
if mds.SetDomainsList(domainsList) and mds.Start() : -> line 19
return mds
return None
if not self._started :
self._server = socket.socket( socket.AF_INET,
socket.SOCK_DGRAM,
socket.IPPROTO_UDP ) -> line 161
self._server.setsockopt( socket.SOL_SOCKET,
Fehlermeldung: OSError: Network card not available ist die Folge.
Damit ich weiterkomme, habe ich main.py line 14 import webserver auskommentiert. Der AccessPoint liess sich zwar starten, aber die Konfiguration funktioniert nicht ohne Webseite.
Das ist nichts neues, die hattest Du doch vorher auch schon drauf, nicht? Bei https://packages.hiveeyes.org/hiveeyes/foss/pycom/vanilla/ sind sie alle aufgelistet, die wir selbst gebacken haben. FiPy-1.20.2.rc6-0.10.2 ist die neueste, ja.
Dieser Code hier steht global auf Modulebene in der webserver.py Datei, wird also bereits beim Laden der Module ausgeführt. Das ist ganz schlecht!
Der Code muss in eine Routine gekapselt werden, die erst gerufen wird, wenn sinnvoll, also erst wenn das “Netzwerk da ist”. Es bietet sich vielleicht jene enable_ap Funktion an?
Es ist wie verhext. Ich habe die Einstellungen des PycomUpdaters überprüft und 6 Fipy mit Diren’s File geflasht. Dann mit Atom die FiPy-Files ( alle vom 10.5.2021 , unverändert ) geflasht. Alles OK.
Dann beim booten der bekannte Fehler line 14 …
Soll ich jetzt versuchen, webserver.py erst später zu importieren?
Z.B. so
293. '# enable ap
294. def enable_ap(pin=None):
import webserver
295. global _wm, loop_run, _wlan, wdt, button_ap
296. '# if in button mode, make sure we don't enter this function again
297. if _config.get_value('general', 'general', 'button_ap_enabled'):
298. button_ap.callback(Pin.IRQ_FALLING, handler=ap_already_enabled)
299. print("Called. Pin {}.".format(pin))
Didi / @didilamken ich muss nochmal nachfragen welcher code genau bei dir läuft? Ich frage nochmal, weil die Fehlermeldungen bei mir nicht kommen und ich eigentlich davon ausgehe, dass wir identischen code verwenden.
In der Powershell vom alten Notebook habe ich noch die alten Befehle gefunden.
.\pycom-fwtool-cli.exe --verbose --port COM5 erase_all
hat in 15 sec funktioniert
PS C:\Users\admin\Documents\uPython\PycomFlash> .\pycom-fwtool-cli.exe --verbose --port COM5 erase_all
Running in PIC mode
Erasing the board can take up to 40 seconds.
Product ID: 152 HW Version: 7 FW Version: 0.0.11
Connecting........
Uploading stub...
Running stub...
Stub running...
Changing baud rate to 921600
Changed.
Auto-detected Flash size: 8MB
Board erased successfully in 15.57 seconds
PS C:\Users\admin\Documents\uPython\PycomFlash>
PS
dann
PS C:\Users\admin\Documents\uPython\PycomFlash> .\pycom-fwtool-cli.exe --verbose --port COM5 flash --tar .\FiPy-1.20.2.rc6-0.10.2-vanilla-squirrel-nosmartconfig.tar.gz
Running in PIC mode
Product ID: 152 HW Version: 7 FW Version: 0.0.11
Connecting.....
Uploading stub...
Running stub...
Stub running...
Changing baud rate to 921600
Changed.
Auto-detected Flash size: 8MB
Script Version: 2.1
Flash params set to 0x023f
Compressed 28672 bytes to 15646...
Writing bootloader.bin at 0x00001000... (100 %)
Hash of data verified.
Wrote 28672 bytes (15646 compressed) at 0x00001000 in 0.8 seconds (297.9 kbit/s)...
Compressed 4096 bytes to 141...
Writing partitions_8MB.bin at 0x00008000... (100 %)
Hash of data verified.
Wrote 4096 bytes (141 compressed) at 0x00008000 in 0.1 seconds (364.1 kbit/s)...
Compressed 2027520 bytes to 1199452...
Writing fipy.bin at 0x00134000... (100 %)
Hash of data verified.
Wrote 2027520 bytes (1199452 compressed) at 0x00010000 in 22.1 seconds (732.8 kbit/s)...
Compressed 4096 bytes to 51...
Writing at 0x001FF000... (100 %)
Hash of data verified.
Wrote 4096 bytes (51 compressed) at 0x001ff000 in 0.1 seconds (364.1 kbit/s)...
Flash operation successful.
PS C:\Users\admin\Documents\uPython\PycomFlash>
dann mit Atom/pymkr projekt fipy_master ohne Änderungen geflasht
boot: keine Fehlermeldung nach import webserver mehr ( Freu , freu )
Exzellent. Ich vermute stark, dass erase_all auch die WiFi Kalibrierungsdaten löscht. Diese werden dann beim nächsten Neustart neu initialisiert, und damit geht dann die Funke auch wieder.
