WiFi-Konnektivität bei der Inbetriebnahme des FiPy hakelt

um das psk kommste grade glaube ich nicht rum.

wpa enterprise ist auf iot devices eher nicht so verbreitet. ich hab da mal patches gesehn, die haben dann aber auf dem event nicht getan und wir hatten es dann auf ner extra essid mit psk (wpa2) gefahren.

ps: im pycom forum und auf esp32 arduino listen gibts auch diskussionen ueber probleme mit fritzboxen.
alles sehr unklar, aber power-saving modes und automatische kanalwahl sind wohl keine tolle idee, wenn es um die stabilitaet von esp32 im wlan geht. kann man ja mal testen, ob es hilft das auszumachen auf der fritzbox.

Ok Mein Router verwendet AES CCMP das ist glaube ich der Nachfolger von TKIP. (bin da leider etwas raus aus dem Thema)
PSK kann ich gar nicht auswählen. Was mich wundert beim Gastzugang klappt es WPA2(CCMP)
nur halt beim normalen Zugang nicht.

Die Terkin-Datenlogger MicroPython Firmware hat diese Probleme übrigens nicht, es liegt also nicht explizit an den FiPy sondern höchstwahrscheinlich an der Software (WLANManager). Habe hier vom Hamburger Workshop min. 3 Teilnehmer, die dieses Problem ebenfalls haben und auf eine Lösung warten.

Sollte also eine Lösung gefunden werden bevor es zum Nächsten Workshop geht. Wir können nicht von allen Teilnehmern erwarten, das sie ihr Wlan zu Hause umstellen und evtl alle anderen Geräte evtl. neu Konfigurieren müssen.

1 Like

uff… aus den details bin ich auch ein bisschen raus… Wi-Fi Protected Access - Wikipedia liest sich wie ‘tkip’ meint wpa(1) und aes-ccmp meint wpa2
mit psk meinte ich ‘preshared key’ also ‘wlan mit passwort’ und nicht einen enterprise mode mit username passwort oder gar (client specific) certifikaten.

hab grade mal in den code der hiverize fw geschaut (die ist gemeint, right?) … tut der wlan manager irgendwas ausser die dinge aus der api als strings zu speichern und zurueck?
kann die pycom api echte utf8 strings handlen oder nur ‘strings’ ? das ist das einzige was mir da beim drueberbrowsen einfaellt was schiefgehn koennte… channel ist auch ein string? vielleicht muss da an die eine oder andre stelle nur noch ne kleine type-conversion und alles ist huebsch…( str() bzw int() )

So habe es denke ich hin bekommen. Scheint ein Timing Problem zu sein. Wahrscheinlich dauert das aushandeln der Verbindung bei WPA/WPA2 länger, sodas der Watchdog zuschlägt.
habe jetzt mal in der Config den timeout auf 10 sec gestellt, jetzt läuft es.

1 Like

super :)
das kann sein, wenn der esp frisch gebootet ist (also bei uns dauernd) kann es nen moment dauern bis so ein sessionkey ausgehandelt ist. schon viel crypto fuer so wenige bytes. wobei da oft auch einfach random knapp ist, und dann kanns auch von ap seite mal nen delay geben. ich hatte sowas mit openwrt wo nach einem reboot die clients rejected wurden weil die kiste noch zuwenig random hatte.

Software
Version: pinguin999/FiPy last commit [6d75cfe], Jul 2, 2019
der code geht nicht, daher
Hiverize/FiPy last commit [55d5a0e] Jun 13, 2019
Config File: settings_preset_didi.json in defailt_settings.json umbenannt
Upload mit Atom und Pymakr-Plugin
Firmware :1.20.0.rc12

Hardware
Board: FiPy v1.2
Filesystem: LittleFS
Shield: Didi

Test 1, Fritz-Box

Router= FRITZ!Box FritzBox 7412 mit aktuellster Firmware FritzOS 06.85
Verschlüsselung = WPA2(CCMP)
Kanal: Funkkanal-Einstellungen automatisch setzen (empfohlen), Kanal 1

ok, funktioniert!

Test 2, Handy-WLAN-Hotspot

Router=Sony Xperia
Verschlüsselung = WPA2 PSK
Kanal: ??

ok, funktioniert!

Der timeout – ganz oben in der settings.json – unter

"networking": {
    "wlan": {
        [...]
        "timeout": 1000,

ist standardmäßig auf 1000 (ms) eingestellt, wenn das jetzt mit einer 0 dran besser funktionieren würde wäre das prima!

        "timeout": 10000,

wie gesagt bei mir hat es wunderbar geholfen, ob jetzt 10s der Wahrheit letzter Schluss sind mal dahingestellt, vielleicht klappt es auch mit 5s.
Mir ist es nicht wichtig, ob er jetzt vor dem Watchdog 10 Sec. hängt, bevor er es nochmal versucht (Neustartet), sondern, dass es überhaupt klappt.

1 Like

Danke für den Tipp, mit der firmware von Vinzent und den default-Einstellungen läuft es bei mir auch. Manchmal hate ich beim upload der Dateien über Atom Probleme, da sagt Atom ganz gut bescheid, dass der upload nicht funktioniert hat. Nach einem Reset des FiPys oder an-/abstöpseln läuft es dann meist.

Ab und an komme ich auch nicht auf den FiPy, dann hilft die Tastenkombi save boot-Knopf auf dem expansion board plus reset auf dem FiPy.

Was ab und an auch nciht ging, das Komplette Löschen der Dateien über den PyCom-Firmware-Flasher, da nutze ich dann das command line tool von Andreas mit make format-flash.

Bei mir am FiPy brennt mit Vinzents Firmware die LED dauerhaft gelb, dachte nur beim Betrieb als AP? Das Gerät liefert aber Daten.

Bin jetzt auch wieder zurück auf Vincent´s Version. Meine LED Leuchtet beim ersten Boot für ein paar Sec. und dann weder im AP Noch im Feldmodus.
Allerdings habe ich wieder das Problem, wenn Wlan aktiviert und verbunden ist, das der AP Mode ständig für jede Messung unterbrochen wird, und man so praktisch keine Einstellungen mehr vornehmen kann.

Benutze allerdings nur noch Visual Studio Code mit Pymakr Plugin und zusätzlich noch Remote -WSL. Leider funktioniert bei mir da das Pymakr plugin leider nicht. Ist aber trotzdem genial da in VS dann auch gleich das bash ist und pymakr daher gar nicht gebraucht wird.

@clemens bei mir funktioniert es jetzt übrigens auch mit der Standarteinstellung von 1000ms
Hab es nochmal überprüft, wenn der FiPy einmal bei der Fritzbox eingetragen ist geht es auch mit 1000ms beim ersten mal anmelden dauert es anscheinend länger.
Ist wahrscheinlich auch der Grund, warum es bei dir auch erst nicht ging und dann auf einmal problemlos.

1 Like

Wir sind bei den Versuchen, Fehler aus der Ferne aufzuspüren, nicht ganz alleine.

Hi. Ich wollte heute eigentlich meine zweite Einheit in Betrieb nehmen, aber der Fipy will nach dem Start einfach keinen AP aufmachen um die Konfig Daten zu editieren.
Die LED leuchtet gelb
Neu flashen?
Oder was kann helfen?

Hatte so eine Situation vor ein paar Wochen auch, das Ding wollte sich einfach nicht connecten. Nach ein paar Tagen ging es dann, was es am Ende war konnte ich nicht herausfinden.

Letzte Woche konnten wir ein ähnliches Phänomen beobachten: Wir hatten einen FiPy eingerichtet (der allerdings Probleme mit dem lokalen WLAN hatte) und nach ein paar Konfigurationsversuchen hat der Rechner das WLAN des FiPy nicht mehr mehr gefunden. Mit dem Handy gings dann komischerweise. D.h. vielleicht noch mal versuchen mit dem Handy oder einen anderen Rechner den AB zu finden.

Generell läuft der Hiveeyes MicroPython Datalogger deutlich stabiler, sowohl was das WLAN betrifft als auch sonst.

Leider hat er noch keine webbasierte Konfigurationsseite aka. “captive portal”. Bei HTTP- und webbasierte Konfiguration des Terkin-Datenloggers zur Implementierung eines Captive Portal wird daran gearbeitet.

Ok ich probiere es nachher noch einmal. Was kann ich machen, wenn gar nichts mehr geht?

Haben evtl. die ganzen WLANs in der Nähe eine Auswirkung?
Sprich es werden erst alle versucht zu connecten?
Ggf. Könnte man zwangsweise bei nicht gesetzten Daten / nicht Erreichbarkeit des konfigurierten WLAN der AP aufmachen- also forced mode

hat nichts gebracht … der FiPy will partout nicht mehr.

Schade, was du versuchen könntest: Mit Atom die ursprüngliche Software nochmals aufzuspielen und dann schauen, ob es wieder funktioniert. Ist denn LittleFS als filesystem schon ausgewählt? Bei den FiPys, die wir vor einigen Monaten verteilt haben war das noch nicht der Fall, wenn du den FiPy erst im August von uns bekommen hast, sollte LittleFS bereits aktiviert sein.

Habe nun mal mit ATOM den FiPy in Betrieb genommen und erhalte beim call des AP :

>>> Called. Pin Pin('P2', mode=Pin.IN, pull=Pin.PULL_UP, alt=-1).
Unhandled exception in callback handler
Traceback (most recent call last):
  File "main.py", line 97, in enable_ap
  File "main.py", line 88, in log
NameError: name '_csv' is not defined 

Also, dass das FS gecrashed wäre glaube ich jetzt nicht, da ich LittleFS im LOG beim BOOTen sehe:

rst:0x1 (POWERON_RESET),boot:0x12 (SPI_FAST_FLASH_BOOT)
configsip: 0, SPIWP:0xee
clk_drv:0x00,q_drv:0x00,d_drv:0x00,cs0_drv:0x00,hd_drv:0x00,wp_drv:0x00
mode:DIO, clock div:1
load:0x3fff8028,len:8
load:0x3fff8030,len:2156
ho 0 tail 12 room 4
load:0x4009fa00,len:19208
entry 0x400a05f4
Initializing filesystem as LittleFS!
Starting boot process...
4 SSIDS found
Boot finished.
No DS1820 found. Is it connected properly?
Gain & initial value set
BME280 initialization failed. Is it connected properly?
CSV Logger failed. Is a SD card inserted?
Traceback (most recent call last):
  File "main.py", line 114, in <module>
OverflowError: overflow converting long int to machine word
Pycom MicroPython 1.20.0.rc12 [v1.9.4-81167ed] on 2019-07-15; FiPy with ESP32
Type "help()" for more information.

Vielmehr macht die main.py wohl Ärger

Ich kann beim Firmware-Aufspielen das Filesystem nicht auswählen:
image

Vielleicht geht es so:
image

1 Like

hast Du denn beim ATOM gesehen welches FS auf dem PY ist?

in ATOM das ADD on Pakte pymakr installiert?

dann siehst do beim drücken des RESET Buttons welches FS beim BOOTEN genutzt wird

Update mit 1.20.0.rc13 hat funktioniert. -> LittleFS ok
Firmware 0.6.0 läuft
settings.example-bob.py nach settings.py kopiert
BME280 ok
5 DS18B20 ok
Waage zeigt noch 40366 kg an
Wo finde ich die Werte für Tara und Scale und wo trage ich sie ein?

1 Like