WLAN-Start jetzt asynchron

biologist · 15. Oktober 2022 um 22:08

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:

github.com

biologist79/ESPuino/blob/18ed588e6af4cb5994caf32c7bd11505dcf466a9/src/Wlan.cpp#L116


      
                  snprintf(Log_Buffer, Log_BufferLength, "Try to connect to WiFi with SSID '%s'...", _ssid);
              #endif
              Log_Println(Log_Buffer, LOGLEVEL_NOTICE);
              wifiCheckLastTimestamp = millis();
              wifiConnectIteration = 1;   // 1: First try; 2: Retry; 0: inactive
              wifiInit = false;
              wifiNeedsRestart = false;
          }
          
          
if (wifiConnectIteration > 0 && (millis() - wifiCheckLastTimestamp >= 500)) {
              if (WiFi.status() != WL_CONNECTED && wifiConnectIteration == 1 && (millis() - wifiCheckLastTimestamp >= 4500)) {
                  snprintf(Log_Buffer, Log_BufferLength, "%s", (char *) FPSTR(cantConnectToWifi));
                  Log_Println(Log_Buffer, LOGLEVEL_ERROR);
                  WiFi.disconnect(true, true);
                  WiFi.begin(_ssid, _pwd); // ESP32-workaround (otherwise WiFi-connection fails every 2nd time)
                  wifiConnectIteration = 2;
                  return;
              }
          
          
    if (WiFi.status() != WL_CONNECTED && wifiConnectIteration == 2 && (millis() - wifiCheckLastTimestamp >= 9000)) {
                  wifiConnectIteration = 0;

github.com

biologist79/ESPuino/blob/18ed588e6af4cb5994caf32c7bd11505dcf466a9/src/Wlan.cpp#L125


      
          if (wifiConnectIteration > 0 && (millis() - wifiCheckLastTimestamp >= 500)) {
              if (WiFi.status() != WL_CONNECTED && wifiConnectIteration == 1 && (millis() - wifiCheckLastTimestamp >= 4500)) {
                  snprintf(Log_Buffer, Log_BufferLength, "%s", (char *) FPSTR(cantConnectToWifi));
                  Log_Println(Log_Buffer, LOGLEVEL_ERROR);
                  WiFi.disconnect(true, true);
                  WiFi.begin(_ssid, _pwd); // ESP32-workaround (otherwise WiFi-connection fails every 2nd time)
                  wifiConnectIteration = 2;
                  return;
              }
          
          
    if (WiFi.status() != WL_CONNECTED && wifiConnectIteration == 2 && (millis() - wifiCheckLastTimestamp >= 9000)) {
                  wifiConnectIteration = 0;
                  accessPointStart((char *) FPSTR(accessPointNetworkSSID), apIP, apNetmask);
                  wifiConnectionTryInProgress = false;
                  free(_ssid);
                  free(_pwd);
                  return;
              }
              
              if (WiFi.status() == WL_CONNECTED) {
                  wifiConnectionTryInProgress = false;

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

compactflash · 16. Oktober 2022 um 08:32

Hi , das ist auch meine Erfahrung … und hier nochmals meine Gedanken zu WiFi überhaupt. Wir hatten das vor gefühlt Jahren schon einmal diskutiert.
WLAN bein Einschalten garnicht starten , auch wegen "Strahlung im Kinderzimmer " , Betrieb im Auto auf langen Fahrten . Du hast das damals nicht machen weil ihr MQTT nutzt. Bei meinen Enkeln wird WLAN fast garnicht gebraucht , nur von Opa wenn er mal in Kanada ist .

Deshalb hier mein Vorschlag:
WLAN grundsätzlich aus , evtl. per #define in den settings konfigurierbar.
Aktivieren möglich durch Festhalten einer Taste , z.Bsp. Taste Play per CMDxxx, beim Bootvorgang.
Mittels Tastenfunktion und Karte wie bisher.
Automatisch beim Auflegen einer Radiokarte.

Wie sehen andere User das , wäre dies praktikabel? Bitte schreibt mal eure Meinung dazu. Ich möchte @biologist dazu gerne überreden.

VG

biologist · 16. Oktober 2022 um 08:52

Es gibt Modifikationskarten und auch Tastenkombinationen. Darüber kann man WLAN deaktivieren und ESPuino merkt sich das über den Start hinweg. Das ist aus meiner Sicht ausreichend.
Das Deaktivieren per Tastenkombination habe ich zwischenzeitlich rausgenommen, da Kinder auch gerne mal wild auf den Tasten rumdrücken. Und dann kann es passieren, dass WLAN deaktiviert wird und man wundert sich, warum der Connect scheinbar nicht klappt.

Lösung: Modifkationskarte. Damit können Eltern WLAN aktivieren/deaktivieren zum beliebigen Zeitpunkt.

Exakt das, was ich beschreibe.

tueddy · 16. Oktober 2022 um 11:08

Hab’s gerade getestet:
Start der Musik ist jetzt deutlich beschleunigt, perfekt!

Diesen jeden 2. WLAN Verbindungsfehler bekomme ich nur mit Arduino 2. Hier reicht die Änderung von 9 auf 15 Sek. für den 2. Verbindungsversuch, dann kann ich auch dort zuverlässig verbinden.

Schönen Dank @biologist für die Verbesserungen!

biologist · 16. Oktober 2022 um 14:16

Ich habe das Ganze mal auf dem ESPuino meines Sohnemanns getestet. Da steckt ein Lolin D32 drin - ohne PSRAM also. Das geht jetzt schon grandios schnell . Das Ganze mit Arduino 1.0.6.

Was mich nochmal zur Frage bringt: Wie kann man den PSRAM-Check des ESP32 umgehen? Wir hatten hier vor einer Weile das Thema. War glaube ich nur ein Befehl. Nur ich weiß leider nicht mehr wo.

tueddy · 16. Oktober 2022 um 17:48

Das könnte mit bool testSPIRAM(void){ return true; } gehen, bin mir aber nicht sicher ob das erst ab Arduino 2 geht. Hier der Link dazu:

github.com/espressif/arduino-esp32

PSRAM severely affects wakeup time from deepsleep

opened 07:52AM - 24 Jun 22 UTC

closed 06:31PM - 24 Jun 22 UTC

Algonsi

Status: Awaiting triage

### Board ESP32-PICO-DevKitM-2 (config as ESP32 Dev Module with 8MB Flash) … ### Device Description 2 DevKit modules on breadboard sharing power supply from USB 1 output pin from one device attached to 1 input pin from the other device 1 button connected at one end to the positive and at the other end to 1 input pin of each device (shared button) ### Hardware Configuration GPIO21 from one device attached as OUTPUT to GPIO21 from the other device as INPUT_PULLDOWN GPIO33 attached to a button as INPUT_PULLDOWN (for 2 devices) ### Version v2.0.3 ### IDE Name Arduino IDE ### Operating System Windows 11 ### Flash frequency 80Mhz ### PSRAM enabled yes ### Upload speed 921600 ### Description Measuring wakeup time from deepsleep: There are two devices, A and B, and a button conected to both. Device A goes into Deep Sleep mode and wakes up by pressing the button. In its setup() the first thing it does is activate the output of pin 33 which is connected to device B. Device B measures the time that elapses from when the button is pressed until it receives the signal from pin 33 of device A, that is, until device A starts executing its setup(). Results: If device A has PSRAM enabled, wakeup time is 537 ms. If it has PSRAM disabled, wakeup time is 101 ms. Expected behaviour: Not increase wakeup time when PSRAM is enabled ### Sketch ```cpp // SKETCH FOR DEVICE A: #define OUTPUT_PIN 21 #define BUTTON 33 void setup() { pinMode(OUTPUT_PIN, OUTPUT); pinMode(BUTTON, INPUT_PULLDOWN); digitalWrite(OUTPUT_PIN, 1); delay(1000); esp_deep_sleep_disable_rom_logging(); esp_sleep_disable_wakeup_source(ESP_SLEEP_WAKEUP_ALL); esp_sleep_enable_gpio_wakeup(); esp_sleep_enable_ext1_wakeup(0x200000000, ESP_EXT1_WAKEUP_ANY_HIGH); // PIN 33 esp_deep_sleep_start(); } void loop() {} /////////////////////// // SKETCH FOR DEVICE B: #define INPUT_PIN 21 #define BUTTON 33 uint32_t buttonTime; uint32_t wakeupTime; void setup() { Serial.begin(115200); pinMode(INPUT_PIN, INPUT_PULLDOWN); pinMode(BUTTON, INPUT_PULLDOWN); Serial.println("Waiting..."); } void loop() { if (digitalRead(BUTTON)) { buttonTime = micros(); while (!digitalRead(INPUT_PIN)) delay(1); wakeupTime = micros() - buttonTime; Serial.print("Wakeup time = "); Serial.println(wakeupTime); delay(1000); } delay(1); } ``` ### Debug Message ```plain No error messages ``` ### Other Steps to Reproduce Removing in the sketch for device A the line `esp_deep_sleep_disable_rom_logging();` the wakeup time increases by about 20 ms in any case The same issue happens in PlatformIO (Arduino framework), but the times are greater than in Arduino IDE ### I have checked existing issues, online documentation and the Troubleshooting Guide - [X] I confirm I have checked existing issues, online documentation and Troubleshooting guide.

compactflash · 17. Oktober 2022 um 11:22

Hi @biologist
Ich weiß das es so geht , ist mir aber eigentlich nicht genug , wie schon gesagt , WLAN wird kaum gebraucht.
Die Aktivierung per Karte ist ok , hat aber einen Nachteil : Wenn man sie braucht liegt sie irgendwo… ich kenne meine Familie.
Die Tastenfunktion würde ich nie deaktivieren , es sei denn ich hätte den Joker im Notfall beim Booten WLAN aktivieren zu können.
VG

biologist · 17. Oktober 2022 um 12:07

Das analoge Problem der Tasten ist: Wenn man die Kombination braucht, dann weiß man sie nicht mehr. Irgendwas ist halt immer, was irgendwem irgendwann irgendwelche Probleme bereitet.

Deswegen haben wir das ja alles konfigurierbar. Bei mir war’s eher so, dass irgendwann das WLAN deaktiviert war und ich habe mich gewundert warum.

Ich meine ich hätte zu dem ganzen Thema auch mal ne Frage hier „in die Runde“ gestellt, ob man diese Funktion zeitlich (beim Start) einschränken soll, damit nicht (unbeabsichtigt) rumgespielt wird. Kann mich nicht dran erinnern, dass es da großartig Resonanz gegeben hätte. Aber es verhindert Fehlbedienungen auch nicht zwingend

Nee, also für mich passt das so.

compactflash · 17. Oktober 2022 um 12:39

Deshalb liefere ich alle Boxen mit einem „Typenschild“ auf der Rückseite aus. Ist der gleiche Sticker von DM wie für die RFID-Karten.
Z.Bsp.

bw87 · 21. Dezember 2022 um 15:02

Hallo, ein Problem ist mir aufgefallen:

Ich nutze PLAY_LAST_RFID_AFTER_REBOOT und DONT_ACCEPT_SAME_RFID_TWICE.

Wenn ich ein Webradio höre und neu starte, fängt der Espuino nicht wieder mit dem Webradio an und bleibt idle (ich denke, weil noch keine Wifi Connection besteht).

Weil ich auch DONT_ACCEPT_SAME_RFID_TWICE setze, habe ich dann noch zusätzlich das Problem, dass ich die gleiche Webradiokarte nicht noch einmal auflegen kann. D.h. ich muss erst eine andere Karte und dann wieder die Karte auflegen, die ich eigentlich hören will.

Gruß Bernhard

biologist · 21. Dezember 2022 um 16:03

Das Problem hatte mir schon jmd. berichtet. Und es so lösen wollen, dass sich ESPuino die Karte für Webradio einfach merkt und es ein paar Sekunden wieder versucht. Klingt erstmal ok. Aber:

a) Was, wenn in der Zwischenzeit eine andere Karte aufgelegt wurde? Das willst du ja nicht einfach implizit überschreiben. Oder noch stranger: Du legst zwischenzeitlich eine Karte auf und die Playlist läuft. Aber dann, nach einer gewissen Verweilzeit, wird dann plötzlich die „eigentliche“ Karte gestartet.
b) Wenn man wartet: Wie lange wartet man denn? Die Connect-Zeit ist nicht immer gleich und vor allem von WLAN zu WLAN nicht immer gleich. Ziehen wir da jetzt noch einen Parameter raus?
c) Wie signalisierst du dem Benutzer denn, dass ESPuino auf WLAN wartet? Klar, aktuell sind es vier grüne LEDs. Aber führen wir da neben weiß, grün, gelb und blau noch eine Farbe ein, die sagt: Ich warte auf WLAN wegen Webradio beim Start?
Klar: In der Konsole ist das völlig eingängig, dass ESPuino einen Timeout abwartet. Aber als Benutzer lege ich eine Karte auf und wundere mich, dass vielleicht 10s lang nix passiert. Määäh!

Kurz: Bislang fand ich keinen Lösungsweg toll. Und daher ist es halt so, wie es jetzt ist .

biologist · 22. Dezember 2022 um 08:11

Aber macht mir gerne Lösungsvorschläge .
Ich wollte nur mal verdeutlichen: Das ist nicht so trivial und eindeutig lösbar, wie es vielleicht scheint.

IngoJo · 30. Dezember 2022 um 18:44

Mir ist ein ähnliches Problem wie @bw87 aufgefallen: Ist man im Bluetooth-Modus und legt eine Radio-Karte auf, so schlägt die Wiedergabe beim ersten Versuch fehl. Ich vermute mal, dass es am nötigen Neustart des ESPuino liegt, um wieder in den WLAN-Modus zu wechseln. Wie von @bw87 beschrieben ist das WLAN nicht schnell genug verfügbar, um das Radio abzuspielen.

Könnte man als einfache Lösung in solchen Fällen das WLAN wieder synchron starten? Es würde sich ja nur auf die Bootvorgänge für diese Sonderfälle beziehen. Evtl. könnte man eine Flagge ablegen, die dafür beim nächsten Boot ausgewertet wird.