Bislang war es so, dass der WLAN-Connect den Start des ESPuino blockiert hat. Nachdem @sonovice das Thema vorhin nochmal bei mir in Erinnerung gerufen hat, habe ich mal geschaut, was sich machen lässt und den Connect nun nicht-blockierend (asynchron) eingerichtet. Sachen von SD lassen sich damit viel früher starten und ich denke das ist bei den meisten Kindern der übliche Anwendungsfall. Macht also Sinn.
Das bedeutet, dass wie bisher, ein Verbindungsversuch initiiert wird. Dessen Ergebnis wird jedoch nicht aktiv abgewartet sondern das passiert im Hintergrund. Vorteil: Sobald man die vielen orange-farbenen LEDs sieht, dauert es nur noch etwa eine Sekunde, bis der ESPuino einsatzbereit ist. Einsatzbereit zu diesem Zeitpunkt jedoch nur für Sachen, die lokal auf SD liegen. Für Webradio muss man natürlich weiterhin die Verbindung abwarten.
Die Anzeige des Neopixels läuft jetzt so:
- Zuerst signalisieren viele orange-farbene LEDs, dass ESPuino startet
- Sobald der Bootvorgang abgeschlossen ist, jedoch die WLAN-Verbindung noch nicht besteht, wird der IDLE-Modus durch vier orange-farbene LEDs signalisiert. Es findet also ein Wechsel von vielen LEDs auf vier LEDs statt; die Farbe ändert sich nicht.
- Ist der WLAN-Verbindungsversuch abgeschlossen, so bleibt im IDLE-Modus alles wie bisher: Entweder die LEDs leuchten weiß (erfolgreich) oder sie leuchten grün (nicht erfolgreich => AP wird geöffnet).
Bei den vier orange-farbenen LEDs bin ich mir bisschen unsicher, ob das der richtige Weg ist. Aber irgendwie wollte jetzt auch nicht noch eine weitere Farbe einführen. Wie auch immer: Man kann diesen zwischenzeitlichen Zustand auf jeden Fall erkennen. Für Vorschläge bin ich offen.
Anmerkungen:
a) Bislang war der Farbübergang (z.B. Wechsel Wlan an/aus) im IDLE-Modus ziemlich langsam. Das war ein Bug, den ich nun mitgefixt habe.
b) Hat man einen ESP32, bei den die WLAN-Zugangsdaten nicht im NVS gespeichert sind, dann geht der ESP32 direkt in den AP-Modus. Das spart inbesondere für „frische“ ESP32 Zeit.
c) ESPuino-Benutzer, die bisher den tryCount erhöht haben, um dem WLAN-Verbindungsversuch mehr Zeit zu geben (Info: der wurde mit 500 ms multipliziert), müssen die Zeiten nun hier anpassen:
Dass es hier zwei Zeiten gibt, geht auf einen ESP32-Bug zurück. Dieser führt nämlich dazu, dass jeder zweite WLAN-Verbindungsversuch fehlschlägt. Das kann man umschiffen, indem man nach einer gewissen Zeit, wenn man vermutet, dass das mit der Verbindung nix mehr wird, einen neuen Verbindungsversuch startet. Die erste Zeit ist also die Zeit, nach der der zweite Verbindungsversuch gestartet wird. Und die zweite Zeit ist die Zeit, nach der ESPuino „aufgibt“.
Bitte testen