Können Sie bitte das Debuggen im Board-Menü aktivieren und sehen, warum es keine Verbindung mehr herstellen möchte, wenn Sie es dazu auffordern?

Ich kann das heute Abend versuchen. Der Arduino-Code ist ziemlich einfach, sieht sich das WiFi-Ereignis an und hat dann Folgendes:

case SYSTEM_EVENT_STA_DISCONNECTED:
    Serial.println("WiFi lost connection.  Attempting to reconnect...");
    WiFi.reconnect();
    break;

Aber sollte es nicht etwas geben, das aufgerufen werden kann, um dies selbst zu erreichen?

Nur für eine schnelle Lösung:
Starten Sie einen Timer in SYSTEM_EVENT_STA_DISCONNECTED, der WiFi.reconnect () aufruft. Funktion und stoppen Sie es in SYSTEM_EVENT_STA_CONNECTED. Das Hauptproblem besteht darin, dass das Gerät keine Verbindung herstellen kann, wenn das Ereignis SYSTEM_EVENT_STA_DISCONNECTED nicht aufgerufen wird. Daher wird nie wieder versucht, eine Verbindung herzustellen.

Leider passe ich eine andere Bibliothek an und bin mit C ++ nicht sehr vertraut, aber ich werde sehen, was ich tun kann, um einen Timer hinzuzufügen (ich kenne VB.net ... Ich kann zumindest die logischen Teile herausfinden und hoffentlich anpassen).

Aber ich denke, Sie haben Recht damit, dass Sie sich nicht wieder verbinden oder besser noch versuchen, eine Trennung zu versuchen, die dann, wenn sie nur einmal fehlschlägt, aufgibt. Das Aktivieren des Debugs könnte mir das zeigen, also fange ich dort an.

Aber zurück zur ursprünglichen Frage und dem zuvor geschlossenen Problem: Ist diese Funktionalität nicht integriert? Und wenn nicht, warum wurde die vorherige Ausgabe als "Art" Arbeit geschlossen? Auch wenn nicht, wird es sein?

Ich habe die Debug-Ebene auf Debug umgestellt und den seriellen Monitor geöffnet und dies immer wieder erhalten:

[WiFi-event] event: 5
WiFi lost connection.  Attempting to reconnect...
[WiFi-event] event: 5
WiFi lost connection.  Attempting to reconnect...
[WiFi-event] event: 5
WiFi lost connection.  Attempting to reconnect...

Ich habe das letzte Mal überprüft, als Daten an einen anderen Controller gesendet wurden, und das war vor über 24 Stunden. Ich gehe also davon aus, dass sie in diesem Modus stecken bleiben. Also habe ich es aus- und wieder eingeschaltet, es hat eine gute Verbindung zu WiFi hergestellt und Daten übertragen, wie es diesmal für ungefähr 2 Stunden sein sollte. Dann wurde es ohne andere Nachricht getrennt und immer wieder mit genau derselben Nachricht gestartet. Ich habe es eine Stunde lang laufen lassen, den Controller neu gestartet und wieder verbunden, aber ich bin mir sicher, dass es nur eine Frage der Zeit ist, bis es von vorne beginnt.

Die erste Frage ist also, wie ich das Problem beheben kann. Zweitens führt mich dies immer noch zu meinen vorherigen Fragen zur automatischen Wiederverbindung

Leute, bitte aktivieren Sie das Debuggen, damit Sie eine ausführlichere Ausgabe des WLAN-Status sehen können:

Ich verwende den folgenden Code, um zu überprüfen, ob mein Gerät noch mit der STA verbunden ist (rufen Sie dies von loop () auf). Du hast die Idee? wifi_is_connected ist eine globale Datei, die im WLAN-Ereignisrückruf festgelegt und zurückgesetzt wird.

static void poll_watchdog_sta(void) {
  static uint32_t ms = millis();
  static uint8_t watchdog = 0;

  // watch out for STA disconnects and reboot if
  // connection cannot be reestablished after
  // X minutes

  // this watchdog MUST NOT reboot the device if
  // wifi is not enabled or never was connected
  // since last reboot

  if (wifi_is_enabled && watchdog_enabled && ((millis() - ms) > 1000 * 6)) {
    ms = millis();

    if (!wifi_is_connected) {
      if (++watchdog < watchdog_timeout * 10) { // timeout in minutes ( * 10 )
        if (watchdog == 1) {
          log_print(F("WIFI: arming network watchdog (reboot in %i min.)"),
            watchdog_timeout
          );
        }
      } else {
        log_print(F("WIFI: still not connected, triggering reboot ..."));
        system_reboot();
      }
    } else {
      if (watchdog) {
        log_print(F("WIFI: network is back, disarming watchdog"));
        watchdog = 0;
      }
    }
  }
}

Ja, ich sehe keine Schleife () in der Bibliothek, die ich für WiFi verwende (wieder von Drittanbietern), aber ich verstehe, was Sie tun, und kann damit arbeiten.

Ich werde die ausführliche Protokollierung aktivieren und prüfen, ob ich zuerst weitere Informationen erhalte, bevor ich etwas ändere.

Die WiFi-Ereignisse, die überprüft und bearbeitet werden, sind auch SYSTEM_EVENT_STA_GOT_IP, SYSTEM_EVENT_STA_DISCONNECTED, SYSTEM_EVENT_STA_START und SYSTEM_EVENT_STA_CONNECTED. Weitere Informationen finden Sie jedoch unter

Ich habe in der Bibliothek gesehen, dass ich ein //WiFi.setAutoReconnect(true) verwende. Ich gehe also davon aus, dass der ursprüngliche Autor versucht hat, die automatische Wiederverbindung zu verwenden, aber es hat nicht funktioniert.

@ me-no-dev - Verbose gab eine viel bessere Erklärung. Nun ... vielleicht zu dir:

Alles war in Ordnung, dann immer wieder, vielleicht 150 Mal:

[E][WiFiClient.cpp:97] connect(): lwip_connect_r: 113

Gefolgt von diesem:

[D][WiFiGeneric.cpp:182] _eventCallback(): Event: 5 - STA_DISCONNECTED
[W][WiFiGeneric.cpp:187] _eventCallback(): Reason: 7 - NOT_ASSOCED
[WiFi-event] event: 5
WiFi lost connection.  Attempting to reconnect...
[D][WiFiGeneric.cpp:182] _eventCallback(): Event: 5 - STA_DISCONNECTED
[W][WiFiGeneric.cpp:187] _eventCallback(): Reason: 202 - ASSOC_FAIL
[WiFi-event] event: 5
WiFi lost connection.  Attempting to reconnect...
[D][WiFiGeneric.cpp:182] _eventCallback(): Event: 5 - STA_DISCONNECTED
[W][WiFiGeneric.cpp:187] _eventCallback(): Reason: 2 - AUTH_EXPIRE
[WiFi-event] event: 5
WiFi lost connection.  Attempting to reconnect...
[D][WiFiGeneric.cpp:182] _eventCallback(): Event: 5 - STA_DISCONNECTED
[W][WiFiGeneric.cpp:187] _eventCallback(): Reason: 2 - AUTH_EXPIRE
[WiFi-event] event: 5

Der letzte Teil (Wiederverbindung, Ereignis 5, Grund 2) wird nur alle 4 - 5 Sekunden wiederholt.

Aufgrund dieses ersten Fehlers, der sich immer wieder wiederholt, fand ich Folgendes: https://github.com/espressif/arduino-esp32/issues/180. Darin sagten Sie: "Versuchen Sie, den Client zu leeren oder alle verfügbaren Daten zu lesen." Wie würde ich das machen? Ich schaue auf die Bibliothek, die ich benutze, und das ist es, was sie haben, um das WiFi-Event zu verfolgen:

//**************************************************************************************
/// Event Handler for ESP32 WiFi Events (needed to implement reconnect logic for now...)
//**************************************************************************************
    void MyESP32WiFi::WiFiEvent(WiFiEvent_t event)
    {
        Serial.printf("[WiFi-event] event: %d\n", event);

        switch (event) {
        case SYSTEM_EVENT_STA_GOT_IP:
            Serial.println("WiFi connected");
            Serial.println("IP address: ");
            Serial.println(WiFi.localIP());
            break;
        case SYSTEM_EVENT_STA_DISCONNECTED:
            Serial.println("WiFi lost connection.  Attempting to reconnect...");
            WiFi.reconnect();
            break;
        case SYSTEM_EVENT_STA_START:
            Serial.println("ESP32 station start");
            break;
        case SYSTEM_EVENT_STA_CONNECTED:
            Serial.println("ESP32 station connected to AP");
            break;
        default:            
            Serial.println("Unhandled WiFi Event raised.");
            break;
        }

    }

Aufgrund der Fehler im vorherigen Beitrag erhalte ich die "5", was bedeutet, dass die WiFi-Verbindung verloren gegangen ist, und dann versucht der Code, "WiFi.reconnect ()" auszuführen. aber es funktioniert offensichtlich nicht. Soll ich dort noch etwas haben? Vielleicht ein Zähler wie @everslick Beispiel, aber einfacher (nur ai = i + 1) und wenn er nach 20 Versuchen an derselben Stelle

Versuchen Sie, WiFi.begin () aufzurufen, anstatt die Verbindung wiederherzustellen und sich zu melden :)

@ me-no-dev - Ich habe es in WiFi.begin () anstelle von WiFi.reconnect () geändert, aber es hat nicht geholfen. Arbeitete ungefähr eine Stunde und bekam dann die Zeile lwip_connect_r: 113, jede ungefähr eine Minute voneinander entfernt, gefolgt von der Trennung alle 5 oder so Sekunden:

[E][WiFiClient.cpp:97] connect(): lwip_connect_r: 113
[E][WiFiClient.cpp:97] connect(): lwip_connect_r: 113
[E][WiFiClient.cpp:97] connect(): lwip_connect_r: 113
[E][WiFiClient.cpp:97] connect(): lwip_connect_r: 113
[D][WiFiGeneric.cpp:182] _eventCallback(): Event: 5 - STA_DISCONNECTED
[W][WiFiGeneric.cpp:187] _eventCallback(): Reason: 7 - NOT_ASSOCED
[WiFi-event] event: 5
WiFi lost connection.  Attempting to reconnect...
[D][WiFiGeneric.cpp:182] _eventCallback(): Event: 5 - STA_DISCONNECTED
[W][WiFiGeneric.cpp:187] _eventCallback(): Reason: 2 - AUTH_EXPIRE
[WiFi-event] event: 5
WiFi lost connection.  Attempting to reconnect...
[D][WiFiGeneric.cpp:182] _eventCallback(): Event: 5 - STA_DISCONNECTED
[W][WiFiGeneric.cpp:187] _eventCallback(): Reason: 2 - AUTH_EXPIRE

Und dann wiederholen sich die 4 Zeilen auf unbestimmte Zeit, bis das Steuerelement neu gestartet wird. Was kann ich noch versuchen? Die Tatsache, dass @everslick den Controller neu

Nebenbei bemerkt, zwei ESP8266, die an denselben Router (Netgear R8000) angeschlossen sind, haben keine Probleme und sind seit über einem Monat ohne Unterbrechungen stabil.

hmmm .... das scheint ein Problem zu sein, entweder im unteren Stapel oder in Ihrem Router.
Sie können sehen, dass der erste Grund NOT_ASSOCED ist, und dann erhalten Sie AUTH_EXPIRE.
Könnten Sie vielleicht die STA ausschalten und dann wieder einschalten? Die Ursache für die Unterbrechung lässt mich denken, dass etwas in der Neuzuordnungsanforderung entweder nicht geändert wurde oder Ihr Router nicht akzeptiert, sodass Sie keine Verbindung mehr herstellen können. Ich werde sehen, ob ich ein internes Problem dazu aufwerfen kann. Welche Router-Firmware-Version verwenden Sie?

Es ist ein Netgear Nighthawk R8000. Derzeit auf der neuesten Firmware V1.0.3.54_1.1.37, obwohl es auch auf der letzten Version getan hat. Ich habe zu jedem Zeitpunkt 20 - 25 Geräte ohne Probleme angeschlossen, einschließlich der zuvor erwähnten zwei ESP8266.

Ich werde versuchen, die Wi-Fi-Start- / Wiederverbindungsleitung durch die STA zu ersetzen und zu sehen, was passiert.

Bearbeiten: Nicht viel darüber wissen und eine andere Bibliothek verwenden ... wie kann ich "die STA ausschalten und dann wieder einschalten"?

Zweite Änderung: Es konnte nicht mit https://github.com/espressif/esp-idf/issues/499#issuecomment -314262611 in Verbindung gebracht werden, oder? Eines der wenigen Dinge, die ich mit demselben NOT_ASSOCED und AUTH_EXPIRE gesehen habe. Ich würde das nicht nur denken, weil ich mich ohne das BLE-Zeug zusammengestellt habe, es aber nie weiß.

Ich habe auch das Wifi-Team alarmiert :) Wir werden sehen, ob etwas dabei herauskommt

Vielen Dank. Sollte ich versuchen, die STA aus- und wieder einzuschalten? Wenn ja, können Sie mich führen oder in die richtige Richtung weisen?

Ich habe auch Folgendes gesehen: https://github.com/espressif/esp-idf/issues/738#issuecomment -311626685, was darauf hinweist, dass ich WiFi.connect oder WiFi.Begin nicht vom Event-Handler aus aufrufen kann? Könnte das auch mein Problem sein? @rojer ?

Also habe ich mir ein zweites ESP32 gekauft, um sicherzustellen, dass es sich nicht um ein Hardwareproblem handelt. Ich habe die Firmware gestern Abend von einem neuen Pull von Github (https://nodemcu.readthedocs.io/en/dev-esp32/en/build/) neu kompiliert und sowohl den neuen als auch den alten Chip geflasht. Ich habe auch beide mit genau der gleichen Skizze geflasht. Das Original befindet sich in meiner Garage, ein Stück von meinem Router entfernt, und der andere Test befindet sich in meinem Wohnzimmer, wo das WLAN viel stärker ist. Beide haben einen seriellen Monitor, der auf einem angeschlossenen PC mit ausführlichem Satz ausgeführt wird. Ich melde alles zurück, was ich finde.

Gibt es noch etwas, was ich versuchen kann? Wie mache ich die STA aus und an? Kann das im STA_Disconnect-Teil gemacht werden, in dem sich die WiFi.reconnect befindet?

Nun, das hat nicht lange gedauert ... Ich habe das gleiche Problem mit dem neuen. Zuerst begann das Original mit dem gleichen Fehler "[E] [WiFiClient. Cpp : 97 ] connect (): lwip_connect_r: 113" und sendete nach knapp 30 Minuten online keine Daten. Normalerweise bekam dieser Fehler zwei auf einmal mit ungefähr 5 oder 6 Sekunden zwischen dann 45 - 50 Sekunden zwischen dem nächsten Satz, aber wieder ein bisschen zufällig. Habe das etwa 10 Minuten lang gemacht und bin dann in das gleiche Trennungsmuster gegangen:

[E][WiFiClient.cpp:97] connect(): lwip_connect_r: 113
[E][WiFiClient.cpp:97] connect(): lwip_connect_r: 113
Data: Sending: temperature1 -49.02
[E][WiFiClient.cpp:97] connect(): lwip_connect_r: 113
[E][WiFiClient.cpp:97] connect(): lwip_connect_r: 113
Data: Sending: humidity1 -5.02
[D][WiFiGeneric.cpp:182] _eventCallback(): Event: 5 - STA_DISCONNECTED
[W][WiFiGeneric.cpp:187] _eventCallback(): Reason: 7 - NOT_ASSOCED
[WiFi-event] event: 5
WiFi lost connection.  Attempting to reconnect...
[D][WiFiGeneric.cpp:182] _eventCallback(): Event: 5 - STA_DISCONNECTED
[W][WiFiGeneric.cpp:187] _eventCallback(): Reason: 202 - ASSOC_FAIL
[WiFi-event] event: 5
WiFi lost connection.  Attempting to reconnect...
[D][WiFiGeneric.cpp:182] _eventCallback(): Event: 5 - STA_DISCONNECTED
[W][WiFiGeneric.cpp:187] _eventCallback(): Reason: 2 - AUTH_EXPIRE
[WiFi-event] event: 5

Und wiederholte die letzten 4 Zeilen immer und immer wieder. Irgendwann hat es etwas anderes gemacht ... die Fehlermeldung hat sich leicht geändert:

[E][WiFiClient.cpp:97] connect(): lwip_connect_r: 113
[E][WiFiClient.cpp:97] connect(): lwip_connect_r: 118
Data: Sending: temperature2 -1.00
[E][WiFiClient.cpp:97] connect(): lwip_connect_r: 118
[E][WiFiClient.cpp:97] connect(): lwip_connect_r: 118
Data: Sending: humidity2 -1.00
[E][WiFiClient.cpp:97] connect(): lwip_connect_r: 118
[E][WiFiClient.cpp:97] connect(): lwip_connect_r: 118
[D][WiFiGeneric.cpp:182] _eventCallback(): Event: 5 - STA_DISCONNECTED
[W][WiFiGeneric.cpp:187] _eventCallback(): Reason: 2 - AUTH_EXPIRE
[WiFi-event] event: 5

Beachten Sie, dass der Fehler auf 118 im Gegensatz zu 113 umgestellt wurde. Von diesem Zeitpunkt an wiederholte er den 118-Fehler jedoch zufällig zusammen mit STA_DISCONNECTED und AUTH_EXPIRED immer und immer wieder.

Dann begann der neue ESP32 genau das Gleiche zu tun. Meistens 113 Fehler, dann das gleiche Muster von NOT_ASSOCED, ASSOC_FAIL und AUTH_EXPIRE, gefolgt von nur dem Trennen und AUTH_EXPIRE immer und immer wieder.

Sie versagten zu unterschiedlichen Zeiten im Abstand von 25 Minuten, während sie genau zur gleichen Zeit gestartet wurden. Das WiFi-Signal scheint weder ein Faktor noch ein bestimmtes Timing zu sein.

Bearbeiten: Nur um bei einem Neustart klar zu sein, wird jedes Mal beim ersten Versuch sofort eine Verbindung hergestellt:

rst:0x1 (POWERON_RESET),boot:0x13 (SPI_FAST_FLASH_BOOT)
flash read err, 1000
ets_main.c 371 
ets Jun  8 2016 00:22:57

rst:0x10 (RTCWDT_RTC_RESET),boot:0x13 (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:0x3fff0010,len:4
load:0x3fff0014,len:708
load:0x40078000,len:0
load:0x40078000,len:11460
entry 0x400789f4
Everything: init started
Everything: Free RAM = -1
Disabling ESP32 WiFi Access Point
[D][WiFiGeneric.cpp:182] _eventCallback(): Event: 2 - STA_START
[WiFi-event] event: 2
Initializing ESP32 WiFi network.  Please be patient...
ESP32 station start
Attempting to connect to WPA SSID: (SSIDRemoved)
..[D][WiFiGeneric.cpp:182] _eventCallback(): Event: 4 - STA_CONNECTED
[WiFi-event] event: 4
ESP32 station connected to AP
[D][WiFiGeneric.cpp:182] _eventCallback(): Event: 7 - STA_GOT_IP
[WiFi-event] event: 7
WiFi connected
IP address: 
192.168.xx.xx

Ich warte immer noch auf die Antwort des WiFi-Teams. Wird noch mehr Lärm machen, da mich das auch nervt. Das Problem liegt irgendwo weit unterhalb von Arduino und in der Closed Source Wifi Lib.

Vielen Dank. Ich werde versuchen, der STA_DISCONNECTED-Ereignisumschaltanweisung, die ich immer wieder erhalte, einen Zähler hinzuzufügen, und nach 5 versuche ich, das WLAN neu zu starten. Nach 10 starte ich den Controller neu und setze den Zähler bei einer Verbindung auf 0 zurück hält am wenigsten den Controller auf.

Wenn ich Ihnen noch etwas zur Verfügung stellen kann, um dieses Problem zu beheben, oder um den Code zu testen, lassen Sie es mich bitte wissen. Wenn es darauf ankommt, dass der von mir verwendete ESP32 für zwei Spannungseingänge, einen Binäreingang und einen DTH22 (Temperatur + Luftfeuchtigkeit) verwendet wird, werden diese Daten über HTTP an einen Controller gesendet.

Hallo @vseven , ich kann dieses Problem einfach nicht selbst reproduzieren.

@vseven Könntest du mir die WiFi-Wiederverbindungslogik

@liuzfesp Wifi-Protokollierung ist in Arduino deaktiviert.
@vseven kommentiere diese Zeile , damit sie angezeigt wird

Ok, ich habe diese Zeile auskommentiert und neu kompiliert. Ich melde mich zurück. Als Randnotiz habe ich versucht, einen Zähler hinzuzufügen, um die Verbindung wiederherzustellen, indem ich mein init () zurückgerufen habe, aber es hat nichts getan ... es war, als ob das init () nie aufgerufen wurde. Ich könnte es aber falsch machen. Aber als der Zähler auf 10 kam, wurde der ESP.restart trotzig aufgerufen und korrekt neu gestartet, woraufhin er sich wieder verband:

    void SmartThingsESP32WiFi::WiFiEvent(WiFiEvent_t event)
    {
        Serial.printf("[WiFi-event] event: %d\n", event);
        switch (event) {
        case SYSTEM_EVENT_STA_GOT_IP:
            Serial.println("WiFi connected");
            Serial.println("IP address: ");
            Serial.println(WiFi.localIP());
            break;
        case SYSTEM_EVENT_STA_DISCONNECTED:
            Serial.println("WiFi lost connection.  Attempting to reconnect...");
            WiFi.reconnect();
            disconnectCounter++;
            if (disconnectCounter > 5) {
                Serial.println("We have recieved the STA_DISCONNECTED event 5 times now.  Re-init...");
                void init();
            }
            if (disconnectCounter > 10) {
                Serial.println("We have recieved the STA_DISCONNECTED event 10 times now.  Reboot...");
                ESP.restart();
            }
            break;
        case SYSTEM_EVENT_STA_START:
            Serial.println("ESP32 station start");
            break;
        case SYSTEM_EVENT_STA_CONNECTED:
            Serial.println("ESP32 station connected to AP");
            disconnectCounter = 0;
            break;
        }
    }

@liuzfesp - hier sind die zusätzlichen Informationen mit dieser Zeile

I (243) wifi: wifi firmware version: c1b8a2f
I (243) wifi: config NVS flash: enabled
I (243) wifi: config nano formating: disabled
I (257) wifi: Init dynamic tx buffer num: 32
I (257) wifi: Init data frame dynamic rx buffer num: 64
I (257) wifi: Init management frame dynamic rx buffer num: 64
I (261) wifi: wifi driver task: 3ffd0d8c, prio:23, stack:4096
I (267) wifi: Init static rx buffer num: 10
I (270) wifi: Init dynamic rx buffer num: 0
I (274) wifi: Init rx ampdu len mblock:7
I (278) wifi: Init lldesc rx ampdu entry mblock:4
I (282) wifi: wifi power manager task: 0x3ffd60f0 prio: 21 stack: 2560
I (290) wifi: wifi timer task: 3ffd7148, prio:22, stack:3584
I (314) wifi: mode : null
Disabling ESP32 WiFi Access Point

I (815) wifi: Init Ampdu: 1 tx baw=6 rx baw=6
I (815) wifi: mode : sta (30:ae:a4:25:78:64)
[D][WiFiGeneric.cpp:182] _eventCallback(): Event: 2 - STA_START

Initializing ESP32 WiFi network.  Please be patient...
[WiFi-event] event: 2
ESP32 station start
Attempting to connect to WPA SSID: (SSIDREMOVED)
.I (1946) wifi: n:1 0, o:1 0, ap:255 255, sta:1 0, prof:1
.I (2603) wifi: state: init -> auth (b0)
I (2605) wifi: state: auth -> assoc (0)
I (2612) wifi: state: assoc -> run (10)
I (2670) wifi: connected with (SSIDREMOVED), channel 1
[D][WiFiGeneric.cpp:182] _eventCallback(): Event: 4 - STA_CONNECTED
[WiFi-event] event: 4
ESP32 station connected to AP
[D][WiFiGeneric.cpp:182] _eventCallback(): Event: 7 - STA_GOT_IP
[WiFi-event] event: 7
WiFi connected

Und die Dateien, die ich verwende (bevor ich den Trennungszähler hinzugefügt habe):

SmartThingsESP32WiFi.h.txt
SmartThingsESP32WiFi.cpp.txt

@liuzfesp - Also hat es das gleiche mit aktiviertem Debug gemacht, hoffentlich sagt dir etwas hier etwas. Es lief ungefähr eine Stunde lang einwandfrei und begann dann, den 113-Fehler zufällig zu werfen. Nach ungefähr 15 Minuten zufälliger 113 Fehler zwischen den eigentlichen Datensenderoutinen wurde Folgendes ausgeführt:

I (5427111) wifi: state: run -> auth (7c0)
I (5427111) wifi: pm stop, total sleep time: 0/1119534452

I (5427111) wifi: n:1 0, o:1 0, ap:255 255, sta:1 0, prof:1
[D][WiFiGeneric.cpp:182] _eventCallback(): Event: 5 - STA_DISCONNECTED
[W][WiFiGeneric.cpp:187] _eventCallback(): Reason: 7 - NOT_ASSOCED
[WiFi-event] event: 5
WiFi lost connection.  Attempting to reconnect...
I (5427133) wifi: state: auth -> init (0)
[D][WiFiGeneric.cpp:182] _eventCallback(): Event: 5 - STA_DISCONNECTED
[W][WiFiGeneric.cpp:187] _eventCallback(): Reason: 202 - ASSOC_FAIL
[WiFi-event] event: 5
WiFi lost connection.  Attempting to reconnect...
I (5427276) wifi: n:1 0, o:1 0, ap:255 255, sta:1 0, prof:1
I (5427276) wifi: state: init -> auth (b0)
I (5428276) wifi: state: auth -> init (2)
I (5428277) wifi: n:1 0, o:1 0, ap:255 255, sta:1 0, prof:1
[D][WiFiGeneric.cpp:182] _eventCallback(): Event: 5 - STA_DISCONNECTED
[W][WiFiGeneric.cpp:187] _eventCallback(): Reason: 2 - AUTH_EXPIRE
[WiFi-event] event: 5
WiFi lost connection.  Attempting to reconnect...
I (5428413) wifi: n:1 0, o:1 0, ap:255 255, sta:1 0, prof:1
I (5428414) wifi: state: init -> auth (b0)
I (5429414) wifi: state: auth -> init (2)
I (5429414) wifi: n:1 0, o:1 0, ap:255 255, sta:1 0, prof:1
[D][WiFiGeneric.cpp:182] _eventCallback(): Event: 5 - STA_DISCONNECTED
[W][WiFiGeneric.cpp:187] _eventCallback(): Reason: 2 - AUTH_EXPIRE
[WiFi-event] event: 5
WiFi lost connection.  Attempting to reconnect...
I (5429551) wifi: n:1 0, o:1 0, ap:255 255, sta:1 0, prof:1
I (5429551) wifi: state: init -> auth (b0)
I (5430551) wifi: state: auth -> init (2)
I (5430551) wifi: n:1 0, o:1 0, ap:255 255, sta:1 0, prof:1
[D][WiFiGeneric.cpp:182] _eventCallback(): Event: 5 - STA_DISCONNECTED
[W][WiFiGeneric.cpp:187] _eventCallback(): Reason: 2 - AUTH_EXPIRE
[WiFi-event] event: 5
WiFi lost connection.  Attempting to reconnect...
I (5430688) wifi: n:1 0, o:1 0, ap:255 255, sta:1 0, prof:1
I (5430688) wifi: state: init -> auth (b0)
I (5431689) wifi: state: auth -> init (2)
I (5431689) wifi: n:1 0, o:1 0, ap:255 255, sta:1 0, prof:1
[D][WiFiGeneric.cpp:182] _eventCallback(): Event: 5 - STA_DISCONNECTED
[W][WiFiGeneric.cpp:187] _eventCallback(): Reason: 2 - AUTH_EXPIRE
[WiFi-event] event: 5
WiFi lost connection.  Attempting to reconnect...
We have recieved the STA_DISCONNECTED event 5 times now.  Re-init...
I (5431826) wifi: n:1 0, o:1 0, ap:255 255, sta:1 0, prof:1
I (5431826) wifi: state: init -> auth (b0)
I (5432826) wifi: state: auth -> init (2)
I (5432826) wifi: n:1 0, o:1 0, ap:255 255, sta:1 0, prof:1
[D][WiFiGeneric.cpp:182] _eventCallback(): Event: 5 - STA_DISCONNECTED
[W][WiFiGeneric.cpp:187] _eventCallback(): Reason: 2 - AUTH_EXPIRE
[WiFi-event] event: 5
WiFi lost connection.  Attempting to reconnect...
We have recieved the STA_DISCONNECTED event 5 times now.  Re-init...
I (5432963) wifi: n:1 0, o:1 0, ap:255 255, sta:1 0, prof:1
I (5432963) wifi: state: init -> auth (b0)
I (5433964) wifi: state: auth -> init (2)
I (5433964) wifi: n:1 0, o:1 0, ap:255 255, sta:1 0, prof:1
[D][WiFiGeneric.cpp:182] _eventCallback(): Event: 5 - STA_DISCONNECTED
[W][WiFiGeneric.cpp:187] _eventCallback(): Reason: 2 - AUTH_EXPIRE
[WiFi-event] event: 5
WiFi lost connection.  Attempting to reconnect...
We have recieved the STA_DISCONNECTED event 5 times now.  Re-init...
I (5434100) wifi: n:1 0, o:1 0, ap:255 255, sta:1 0, prof:1
I (5434101) wifi: state: init -> auth (b0)
I (5435101) wifi: state: auth -> init (2)
I (5435101) wifi: n:1 0, o:1 0, ap:255 255, sta:1 0, prof:1
[D][WiFiGeneric.cpp:182] _eventCallback(): Event: 5 - STA_DISCONNECTED
[W][WiFiGeneric.cpp:187] _eventCallback(): Reason: 2 - AUTH_EXPIRE
[WiFi-event] event: 5
WiFi lost connection.  Attempting to reconnect...
We have recieved the STA_DISCONNECTED event 5 times now.  Re-init...
I (5435238) wifi: n:1 0, o:1 0, ap:255 255, sta:1 0, prof:1
I (5435238) wifi: state: init -> auth (b0)
I (5436238) wifi: state: auth -> init (2)
I (5436239) wifi: n:1 0, o:1 0, ap:255 255, sta:1 0, prof:1
[D][WiFiGeneric.cpp:182] _eventCallback(): Event: 5 - STA_DISCONNECTED
[W][WiFiGeneric.cpp:187] _eventCallback(): Reason: 2 - AUTH_EXPIRE
[WiFi-event] event: 5
WiFi lost connection.  Attempting to reconnect...
We have recieved the STA_DISCONNECTED event 5 times now.  Re-init...
I (5436375) wifi: n:1 0, o:1 0, ap:255 255, sta:1 0, prof:1
I (5436376) wifi: state: init -> auth (b0)
I (5437376) wifi: state: auth -> init (2)
I (5437376) wifi: n:1 0, o:1 0, ap:255 255, sta:1 0, prof:1
[D][WiFiGeneric.cpp:182] _eventCallback(): Event: 5 - STA_DISCONNECTED
[W][WiFiGeneric.cpp:187] _eventCallback(): Reason: 2 - AUTH_EXPIRE
[WiFi-event] event: 5
WiFi lost connection.  Attempting to reconnect...
We have recieved the STA_DISCONNECTED event 5 times now.  Re-init...
We have recieved the STA_DISCONNECTED event 10 times now.  Reboot...
I (5437405) wifi: flush txq
I (5437407) wifi: stop sw txq
I (5437410) wifi: lmac stop hw txq
ets Jun  8 2016 00:22:57

rst:0xc (SW_CPU_RESET),boot:0x13 (SPI_FAST_FLASH_BOOT)

Also versuchte es für jedes STA_DISCONNECT, WiFi.reconnect ohne offensichtlichen Erfolg aufzurufen, und versuchte dann, init () nach mehr als 5 Verbindungsabbrüchen auszuführen, was auch nicht half, sobald es 10 Verbindungsabbrüche traf, wurde es neu gestartet, was neu startete und die Verbindung wiederherstellte.

Ich habe den seriellen Monitor das ganze Wochenende über auf meinem ESP32 laufen lassen und er wurde ungefähr 10 Mal zwischen Freitagabend 18 Uhr und Sonntagabend 21 Uhr neu gestartet. Jedes Mal war es genau wie in den obigen Protokollen.

@ me-no-dev - Kannst du mich so führen, dass ich die STA einfach aus- und wieder einschalte, um zu sehen, ob dies auch zum erneuten Verbinden funktioniert, und ich kann das nach 5 fehlgeschlagenen Versuchen versuchen? Der Neustart nach 10 funktioniert, aber ich habe vor, damit die RGB-Beleuchtung zu steuern, und ich möchte wirklich nicht, dass die Lichter ein- und ausgeschaltet werden.

@liuzfesp - Kann ich Ihnen noch etwas zum Debuggen zur Verfügung stellen? Oder etwas Besonderes, das ich ausprobieren kann?

Irgendwelche Updates? Immer noch ständige Unterbrechungen mit beiden Geräten.

@liuzfesp irgendwelche Neuigkeiten hier?

Ich sehe, dass es einige Codeänderungen gibt, die mit Bluetooth und WiFi kommen. Ich bin mir nicht sicher, ob mir irgendetwas davon hilft oder nicht. Ich habe immer noch die gleichen Probleme und der Neustart arbeitet daran, dass meine Daten weitergegeben werden, aber ich konnte sie nicht für die Steuerung von RGB-Lichtleisten verwenden, da die Lichter bei einem Neustart immer wieder ausgeschaltet wurden.

@liuzfesp - Gibt es irgendetwas in den Protokollen, das hilft oder etwas anderes, das ich bereitstellen oder versuchen kann?

Ich habe einige Dinge bereinigt, in meinem Code sichergestellt, dass nichts Verzögerungen oder Blockierungen verursacht, und ich habe jetzt weniger Fehler (siehe die 113- und 118-Fehler), aber immer noch das gleiche Problem beim Trennen der Verbindung und es scheint direkt mit dem zu zusammenhängen WiFi versucht sich zu authentifizieren (erneuern?) Und schlägt fehl. Hier ist eine neue Aufnahme von diesem Wochenende, an dem ich sie innerhalb von 24 Stunden ungefähr fünfmal neu starten ließ. Wiederum, dasselbe auf zwei verschiedenen ESP32s, ich suche nach der Trennung (Ereignis 5) und versuche, die Verbindung mit einem WiFi.reconnect und einem WiFi.begin wieder herzustellen, beide ohne Glück, also startet es nach 10 Versuchen neu und verbindet sich anschließend einwandfrei:

I (1903652) wifi: active cnt: 5
I (1913652) wifi: active cnt: 5
I (1923652) wifi: send null to keep active
I (1933652) wifi: send null to keep active
I (1943653) wifi: active cnt: 1
I (1953653) wifi: active cnt: 2
I (1963653) wifi: send null to keep active
I (1973653) wifi: send null to keep active
I (1983653) wifi: send null to keep active
I (1993653) wifi: active cnt: 1
I (2003654) wifi: send null to keep active
I (2013654) wifi: send null to keep active
I (2023654) wifi: send null to keep active
I (2033654) wifi: send null to keep active
I (2043654) wifi: send null to keep active
I (2053654) wifi: send null to keep active
I (2063654) wifi: send null to keep active
I (2073655) wifi: send null to keep active
I (2083655) wifi: active cnt: 1
I (2093655) wifi: send null to keep active
I (2103655) wifi: send null to keep active
I (2113655) wifi: send null to keep active
I (2123655) wifi: send null to keep active
I (2133655) wifi: send null to keep active
I (2143656) wifi: send null to keep active
I (2153656) wifi: send null to keep active
I (2163656) wifi: send null to keep active
I (2173656) wifi: send null to keep active
I (2183656) wifi: send null to keep active
I (2193656) wifi: send null to keep active
I (2203657) wifi: send null to keep active
I (2213657) wifi: send null to keep active
I (2223657) wifi: send null to keep active
I (2233657) wifi: send null to keep active
I (2243657) wifi: send null to keep active
I (2253657) wifi: send null to keep active
I (2263657) wifi: send null to keep active
I (2273658) wifi: active cnt: 2
I (2283658) wifi: send null to keep active
I (2293658) wifi: send null to keep active
I (2303658) wifi: send null to keep active
I (2313658) wifi: send null to keep active
I (2323658) wifi: send null to keep active
I (2333658) wifi: send null to keep active
I (2343659) wifi: send null to keep active
I (2353659) wifi: send null to keep active
I (2363659) wifi: send null to keep active
I (2373659) wifi: send null to keep active
I (2383659) wifi: send null to keep active
I (2393659) wifi: send null to keep active
I (2403660) wifi: send null to keep active
I (2413660) wifi: send null to keep active
I (2423660) wifi: send null to keep active
I (2433660) wifi: send null to keep active
I (2443660) wifi: send null to keep active
I (2453660) wifi: send null to keep active
I (2463660) wifi: send null to keep active
I (2473661) wifi: send null to keep active
I (2483661) wifi: send null to keep active
I (2483663) wifi: state: run -> auth (7c0)
I (2483663) wifi: pm stop, total sleep time: 0/-1824912959

I (2483663) wifi: n:1 0, o:1 0, ap:255 255, sta:1 0, prof:1
[WiFi-event] event: 5
WiFi lost connection.  Attempting to reconnect...
I (2483674) wifi: state: auth -> init (0)
[WiFi-event] event: 5
WiFi lost connection.  Attempting to reconnect...
I (2483805) wifi: n:1 0, o:1 0, ap:255 255, sta:1 0, prof:1
I (2483805) wifi: state: init -> auth (b0)
I (2484805) wifi: state: auth -> init (2)
I (2484806) wifi: n:1 0, o:1 0, ap:255 255, sta:1 0, prof:1
[WiFi-event] event: 5
WiFi lost connection.  Attempting to reconnect...
I (2484930) wifi: n:1 0, o:1 0, ap:255 255, sta:1 0, prof:1
I (2484931) wifi: state: init -> auth (b0)
I (2485931) wifi: state: auth -> init (2)
I (2485931) wifi: n:1 0, o:1 0, ap:255 255, sta:1 0, prof:1
[WiFi-event] event: 5
WiFi lost connection.  Attempting to reconnect...
I (2486056) wifi: n:1 0, o:1 0, ap:255 255, sta:1 0, prof:1
I (2486056) wifi: state: init -> auth (b0)
I (2487056) wifi: state: auth -> init (2)
I (2487056) wifi: n:1 0, o:1 0, ap:255 255, sta:1 0, prof:1
[WiFi-event] event: 5
WiFi lost connection.  Attempting to reconnect...
I (2487181) wifi: n:1 0, o:1 0, ap:255 255, sta:1 0, prof:1
I (2487181) wifi: state: init -> auth (b0)
I (2488182) wifi: state: auth -> init (2)
I (2488182) wifi: n:1 0, o:1 0, ap:255 255, sta:1 0, prof:1
[WiFi-event] event: 5
WiFi lost connection.  Attempting to reconnect...
I (2488306) wifi: n:1 0, o:1 0, ap:255 255, sta:1 0, prof:1
I (2488307) wifi: state: init -> auth (b0)
I (2489307) wifi: state: auth -> init (2)
I (2489307) wifi: n:1 0, o:1 0, ap:255 255, sta:1 0, prof:1
[WiFi-event] event: 5
WiFi lost connection.  Attempting to reconnect...
I (2489432) wifi: n:1 0, o:1 0, ap:255 255, sta:1 0, prof:1
I (2489432) wifi: state: init -> auth (b0)
I (2490432) wifi: state: auth -> init (2)
I (2490432) wifi: n:1 0, o:1 0, ap:255 255, sta:1 0, prof:1
[WiFi-event] event: 5
WiFi lost connection.  Attempting to reconnect...
I (2490557) wifi: n:1 0, o:1 0, ap:255 255, sta:1 0, prof:1
I (2490557) wifi: state: init -> auth (b0)
I (2491558) wifi: state: auth -> init (2)
I (2491558) wifi: n:1 0, o:1 0, ap:255 255, sta:1 0, prof:1
[WiFi-event] event: 5
WiFi lost connection.  Attempting to reconnect...
I (2491682) wifi: n:1 0, o:1 0, ap:255 255, sta:1 0, prof:1
I (2491683) wifi: state: init -> auth (b0)
I (2492683) wifi: state: auth -> init (2)
I (2492683) wifi: n:1 0, o:1 0, ap:255 255, sta:1 0, prof:1
[WiFi-event] event: 5
WiFi lost connection.  Attempting to reconnect...
I (2492808) wifi: n:1 0, o:1 0, ap:255 255, sta:1 0, prof:1
I (2492808) wifi: state: init -> auth (b0)
I (2493808) wifi: state: auth -> init (2)
I (2493808) wifi: n:1 0, o:1 0, ap:255 255, sta:1 0, prof:1
[WiFi-event] event: 5
WiFi lost connection.  Attempting to reconnect...
We have recieved the STA_DISCONNECTED event over 10 times now.  Reboot...
I (2493819) wifi: flush txq
I (2493822) wifi: stop sw txq
I (2493824) wifi: lmac stop hw txq
ets Jun  8 2016 00:22:57

rst:0xc (SW_CPU_RESET),boot:0x13 (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:0x3fff0010,len:4
load:0x3fff0014,len:708
load:0x40078000,len:0
load:0x40078000,len:11460
entry 0x400789f4
Everything: init started
Everything: Free RAM = -1
I (749) wifi: wifi firmware version: c1b8a2f
I (749) wifi: config NVS flash: enabled
I (749) wifi: config nano formating: disabled
I (758) wifi: Init dynamic tx buffer num: 32
I (758) wifi: Init data frame dynamic rx buffer num: 64
I (758) wifi: Init management frame dynamic rx buffer num: 64
I (762) wifi: wifi driver task: 3ffca34c, prio:23, stack:4096
I (768) wifi: Init static rx buffer num: 10
I (771) wifi: Init dynamic rx buffer num: 0
I (775) wifi: Init rx ampdu len mblock:7
I (779) wifi: Init lldesc rx ampdu entry mblock:4
I (783) wifi: wifi power manager task: 0x3ffd6004 prio: 21 stack: 2560
I (791) wifi: wifi timer task: 3ffd705c, prio:22, stack:3584
I (815) wifi: mode : null
Disabling ESP32 WiFi Access Point

I (1816) wifi: Init Ampdu: 1 tx baw=6 rx baw=6
I (1816) wifi: mode : sta (30:ae:a4:07:f1:98)
[WiFi-event] event: 2

Initializing ESP32 WiFi network.  Please be patient...
ESP32 station start
Attempting to connect to WPA SSID: (SSIDREMOVED)
.I (2943) wifi: n:1 0, o:1 0, ap:255 255, sta:1 0, prof:1
.I (3600) wifi: state: init -> auth (b0)
I (3602) wifi: state: auth -> assoc (0)
I (3606) wifi: state: assoc -> run (10)
I (3635) wifi: connected with (SSIDREMOVED), channel 1
[WiFi-event] event: 4
ESP32 station connected to AP
[WiFi-event] event: 7
WiFi connected
IP address: 
192.168.1.142

@liuzfesp / @ me-no-dev - Gibt es weitere Informationen, die ich bereitstellen kann? Passiert dies jemand anderem oder nur mit meinen beiden HiLetGo ModeMCU ESP32s? Gibt es eine benutzerdefinierte Firmware, die ich ausprobieren kann?

-Allan

Ich habe genau das gleiche Verhalten auf meinem WROOM-32-Modul.
Bei jedem dritten oder vierten Neustart hängt es in der Schleife STA_DISCONNECTED -> AUTH_EXPIRED.
Überprüfte ein zweites Modul desselben Typs mit demselben Verhalten.
Mein Router ist ein TL-WR841 (TPLINK), aber auch ein ASUS RT-AC87U.

Wann wird es eine Lösung geben, die nutzlos ist, wenn in solchen Situationen ein Neustart erforderlich ist ...

edit: Bei mir tritt dieses Problem auch nach dem Booten auf, dh WiFi.begin () stellt überhaupt keine Verbindung her, sondern Schleifen in STA_DISCONNECTED -> AUTH_EXPIRED

Ich habe seit einem Monat keine Antwort mehr erhalten, obwohl ich froh bin, dass es jemand anderem passiert, also weiß ich, dass ich nicht allein bin.

@liuzfesp / @ me-no-dev - Hat dies Fortschritte gemacht oder irgendetwas, das wir versuchen können, damit dies zuverlässig mit WiFi verbunden bleibt.

stupste wieder

@igrr

@copercini warum?

Da ich hier getaggt wurde ... @vseven , gibt es eine Möglichkeit, die

Ein anderer Gedanke (nur um die Anzahl der Variablen zu reduzieren): Tritt dieses Problem auch auf, wenn Sie eine Verbindung zu einem offenen WiFi-Netzwerk herstellen?

Derzeit schlagen alle erneuten Verbindungen mit meinen WROOM32s mit der folgenden Debug-Ausgabe fehl:

[D] [WiFiGeneric. cpp: 265 ] _eventCallback (): Ereignis: 2 - STA_START
.... [D] [WiFiGeneric. cpp: 265 ] _eventCallback (): Ereignis: 4 - STA_CONNECTED
.. [D] [WiFiGeneric. cpp: 265 ] _eventCallback (): Ereignis: 7 - STA_GOT_IP
WiFi verbunden
... dann blockiere ich den Antennenempfang oder drücke RESET an meinem AP, um eine Trennung zu erzwingen ...
[D] [WiFiGeneric. cpp: 265 ] _eventCallback (): Ereignis: 5 - STA_DISCONNECTED
[W] [WiFiGeneric. cpp: 270 ] _eventCallback (): Grund: 200 - NO_AP_FOUND
... wenn der Empfang wieder in Ordnung sein sollte, dauert es ungefähr 2 Minuten, bis er sagt:

[D] [WiFiGeneric. cpp: 265 ] _eventCallback (): Ereignis: 8 - STA_WPS_ER_SUCCESS

In diesem Zustand bleibt es jedoch für immer vom Netzwerk getrennt.
WPS ist an meinem AP ausgeschaltet. Ich weiß nicht, was die Debug-Meldung bedeutet.
Gleiches Verhalten mit zwei verschiedenen APs und zwei verschiedenen WROOM32-Modulen anhand der Beispielskizze. Egal ob WPA2 verwendet oder ein offenes Netzwerk.
Kann bei Bedarf ein Wireshark-Protokoll im Überwachungsmodus senden.

Zunächst einmal vielen Dank an alle für Ihre harte Arbeit am SDK. Es hat mir sehr viel Spaß gemacht, mich damit zu entwickeln, und ich bin sehr dankbar für all die Anstrengungen, die damit unternommen wurden.

Ich sehe dieses Problem auch. Ich glaube, ich habe es vielleicht geschafft, es ein wenig einzugrenzen. Ich verwende diese wirklich kleine Skizze, die sowohl auf ESP8266 als auch auf ESP32 funktionieren sollte:

https://github.com/sidoh/esp32_reconnect_demo

Ich habe die automatische Wiederverbindung deaktiviert, damit ich mehr Kontrolle über die Variablen habe.

Konfiguration

1. Testen auf ESP8266 und ESP32
2. Verwenden eines mobilen Hotspot-Netzwerks. Versuchte sowohl WPA2 PSK als auch offene Netzwerke
3. Lassen Sie die MCU eine Verbindung zum Netzwerk herstellen und einige Sekunden lang ausführen. Ich habe einen NTP-Client hinzugefügt, um die Konnektivität zu überprüfen.

Dann habe ich zwei verschiedene Dinge ausprobiert:

(A) Netzwerk abreißen, sofort neu erstellen

Unter diesen Umständen wird das Netzwerk normalerweise neu erstellt, wenn die MCU feststellt, dass die Verbindung getrennt wurde.

(B) Netzwerk abreißen, warten, bis die MCU feststellt, dass die Verbindung getrennt ist, Netzwerk neu erstellen

Beobachtungen

1. Das Verhalten ist bei WPA2 und offenen Netzwerken gleich.
2. Der ESP8266 verbindet sich erfolgreich wieder mit (A) und (B).
3. ESP32 verbindet sich in Experiment (A) wieder, bleibt aber in (B) stecken.
4. ESP32 stellt die Verbindung in (A) und (B) WiFi.disconnect(true); _und_ WiFi.begin(WIFI_SSID, WIFI_PASSWD); aufgerufen werden. Scheint, als wären beide notwendig.
   \.
   Der boolesche Parameter wifioff für disconnect , der auf true gesetzt ist, scheint ebenfalls notwendig zu sein. Da WiFi.disconnect(true); die WLAN-Einstellungen zu löschen scheint, müssen Sie die SSID und das Kennwort im Aufruf von begin erneut angeben.

Protokolle

Alle diese sind mit einem offenen Netzwerk. Ich lasse die ESP8266-Protokolle weg, da das Verhalten wie erwartet war, kann aber angeben, ob sie nützlich wären.

ESP32, Experiment (A)

I (25) wifi: wifi firmware version: 708a055
I (26) wifi: config NVS flash: enabled
I (26) wifi: config nano formating: disabled
I (31) wifi: Init dynamic tx buffer num: 32
I (32) wifi: Init data frame dynamic rx buffer num: 64
I (32) wifi: Init management frame dynamic rx buffer num: 64
I (35) wifi: wifi driver task: 3ffd46dc, prio:23, stack:4096
I (40) wifi: Init static rx buffer num: 10
I (44) wifi: Init dynamic rx buffer num: 0
I (48) wifi: wifi power manager task: 0x3ffd9418 prio: 21 stack: 2560
I (425) wifi: mode : sta (30:ae:a4:04:42:c8)
[D][WiFiGeneric.cpp:265] _eventCallback(): Event: 2 - STA_START
I (2836) wifi: n:6 0, o:1 0, ap:255 255, sta:6 0, prof:1
I (2836) wifi: state: init -> auth (b0)
I (2853) wifi: state: auth -> assoc (0)
I (2872) wifi: state: assoc -> run (10)
I (2872) wifi: connected with glowyrectangle, channel 6
[D][WiFiGeneric.cpp:265] _eventCallback(): Event: 4 - STA_CONNECTED
[D][WiFiGeneric.cpp:265] _eventCallback(): Event: 7 - STA_GOT_IP
Setup completed
[4] ssid=glowyrectangle
[5] ssid=glowyrectangle
I (5872) wifi: pm start, type:0

[6] ssid=glowyrectangle
[7] ssid=glowyrectangle
[8] ssid=glowyrectangle
[9] ssid=glowyrectangle
[10] ssid=glowyrectangle
I (10388) wifi: state: run -> auth (7c0)
I (10389) wifi: pm stop, total sleep time: 0/4516399

I (10389) wifi: n:6 0, o:6 0, ap:255 255, sta:6 0, prof:1
[D][WiFiGeneric.cpp:265] _eventCallback(): Event: 5 - STA_DISCONNECTED
[W][WiFiGeneric.cpp:270] _eventCallback(): Reason: 7 - NOT_ASSOCED
W (11413) wifi: Haven't to connect to a suitable AP now!
[11] ssid=
Attempting to reconnect...
I (13822) wifi: n:6 0, o:6 0, ap:255 255, sta:6 0, prof:1
I (13823) wifi: state: auth -> auth (b0)
I (13826) wifi: state: auth -> assoc (0)
I (13839) wifi: state: assoc -> run (10)
I (13839) wifi: connected with glowyrectangle, channel 6
[D][WiFiGeneric.cpp:265] _eventCallback(): Event: 4 - STA_CONNECTED
[D][WiFiGeneric.cpp:265] _eventCallback(): Event: 7 - STA_GOT_IP
Connection result: 3
[1513219385] ssid=glowyrectangle
[1513219386] ssid=glowyrectangle
[1513219387] ssid=glowyrectangle
[1513219388] ssid=glowyrectangle
I (16839) wifi: pm start, type:0

ESP32, Experiment (B)

rst:0x10 (RTCWDT_RTC_RESET),boot:0x17 (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:2
load:0x3fff0018,len:4
load:0x3fff001c,len:812
load:0x40078000,len:0
load:0x40078000,len:11404
entry 0x40078aa0
I (25) wifi: wifi firmware version: 708a055
I (26) wifi: config NVS flash: enabled
I (26) wifi: config nano formating: disabled
I (35) wifi: Init dynamic tx buffer num: 32
I (36) wifi: Init data frame dynamic rx buffer num: 64
I (36) wifi: Init management frame dynamic rx buffer num: 64
I (39) wifi: wifi driver task: 3ffd46d0, prio:23, stack:4096
I (44) wifi: Init static rx buffer num: 10
I (48) wifi: Init dynamic rx buffer num: 0
I (52) wifi: wifi power manager task: 0x3ffd940c prio: 21 stack: 2560
I (431) wifi: mode : sta (30:ae:a4:04:42:c8)
[D][WiFiGeneric.cpp:265] _eventCallback(): Event: 2 - STA_START
I (2842) wifi: n:6 0, o:1 0, ap:255 255, sta:6 0, prof:1
I (2843) wifi: state: init -> auth (b0)
I (2846) wifi: state: auth -> assoc (0)
I (2863) wifi: state: assoc -> run (10)
I (2863) wifi: connected with glowyrectangle, channel 6
[D][WiFiGeneric.cpp:265] _eventCallback(): Event: 4 - STA_CONNECTED
[D][WiFiGeneric.cpp:265] _eventCallback(): Event: 7 - STA_GOT_IP
Setup completed
[3] ssid=glowyrectangle
[4] ssid=glowyrectangle
I (5863) wifi: pm start, type:0

[5] ssid=glowyrectangle
[1513219573] ssid=glowyrectangle
[1513219574] ssid=glowyrectangle
[1513219575] ssid=glowyrectangle
[1513219576] ssid=glowyrectangle
[1513219577] ssid=glowyrectangle
[1513219578] ssid=glowyrectangle
[1513219579] ssid=glowyrectangle
I (13174) wifi: bcn_timout,ap_probe_send_start
[1513219580] ssid=glowyrectangle
[1513219581] ssid=glowyrectangle
[1513219582] ssid=glowyrectangle
I (15676) wifi: ap_probe_send over, resett wifi status to disassoc
I (15677) wifi: state: run -> init (1)
I (15678) wifi: pm stop, total sleep time: 0/9813809

I (15678) wifi: n:6 0, o:6 0, ap:255 255, sta:6 0, prof:1
[D][WiFiGeneric.cpp:265] _eventCallback(): Event: 5 - STA_DISCONNECTED
[W][WiFiGeneric.cpp:270] _eventCallback(): Reason: 200 - NO_AP_FOUND
W (16387) wifi: Haven't to connect to a suitable AP now!
[1513219583] ssid=
Attempting to reconnect...
Connection result: 5
[E][WiFiUdp.cpp:183] endPacket(): could not send data: 118
W (17412) wifi: Haven't to connect to a suitable AP now!
[1513219584] ssid=
Attempting to reconnect...
Connection result: 5
[E][WiFiUdp.cpp:183] endPacket(): could not send data: 118
W (18437) wifi: Haven't to connect to a suitable AP now!
[1513219585] ssid=
Attempting to reconnect...
Connection result: 5
[E][WiFiUdp.cpp:183] endPacket(): could not send data: 118
W (19462) wifi: Haven't to connect to a suitable AP now!
[1513219586] ssid=
Attempting to reconnect...
Connection result: 5

... ( loops like this indefinitely ) ...

ESP32, Experiment (B) mit Disconnect (true) + begin (ssid, passwd)

rst:0x10 (RTCWDT_RTC_RESET),boot:0x17 (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:2
load:0x3fff0018,len:4
load:0x3fff001c,len:812
load:0x40078000,len:0
load:0x40078000,len:11404
entry 0x40078aa0
I (27) wifi: wifi firmware version: 708a055
I (28) wifi: config NVS flash: enabled
I (28) wifi: config nano formating: disabled
I (36) wifi: Init dynamic tx buffer num: 32
I (36) wifi: Init data frame dynamic rx buffer num: 64
I (36) wifi: Init management frame dynamic rx buffer num: 64
I (39) wifi: wifi driver task: 3ffd46d0, prio:23, stack:4096
I (45) wifi: Init static rx buffer num: 10
I (48) wifi: Init dynamic rx buffer num: 0
I (52) wifi: wifi power manager task: 0x3ffd940c prio: 21 stack: 2560
I (431) wifi: mode : sta (30:ae:a4:04:42:c8)
[D][WiFiGeneric.cpp:265] _eventCallback(): Event: 2 - STA_START
I (2842) wifi: n:6 0, o:1 0, ap:255 255, sta:6 0, prof:1
I (2843) wifi: state: init -> auth (b0)
I (2847) wifi: state: auth -> assoc (0)
I (2863) wifi: state: assoc -> run (10)
I (2863) wifi: connected with glowyrectangle, channel 6
[D][WiFiGeneric.cpp:265] _eventCallback(): Event: 4 - STA_CONNECTED
[D][WiFiGeneric.cpp:265] _eventCallback(): Event: 7 - STA_GOT_IP
Setup completed
[1513219802] ssid=glowyrectangle
[1513219803] ssid=glowyrectangle
[1513219804] ssid=glowyrectangle
I (5863) wifi: pm start, type:0

[1513219805] ssid=glowyrectangle
[1513219806] ssid=glowyrectangle
[1513219807] ssid=glowyrectangle
[1513219808] ssid=glowyrectangle
[1513219809] ssid=glowyrectangle
[1513219810] ssid=glowyrectangle
[1513219811] ssid=glowyrectangle
[1513219812] ssid=glowyrectangle
[1513219813] ssid=glowyrectangle
[1513219814] ssid=glowyrectangle
[1513219815] ssid=glowyrectangle
[1513219816] ssid=glowyrectangle
I (17282) wifi: bcn_timout,ap_probe_send_start
[1513219817] ssid=glowyrectangle
[1513219818] ssid=glowyrectangle
[1513219819] ssid=glowyrectangle
I (19785) wifi: ap_probe_send over, resett wifi status to disassoc
I (19785) wifi: state: run -> init (1)
I (19786) wifi: pm stop, total sleep time: 0/13922305

I (19786) wifi: n:6 0, o:6 0, ap:255 255, sta:6 0, prof:1
[D][WiFiGeneric.cpp:265] _eventCallback(): Event: 5 - STA_DISCONNECTED
[W][WiFiGeneric.cpp:270] _eventCallback(): Reason: 200 - NO_AP_FOUND
W (20616) wifi: Haven't to connect to a suitable AP now!
[1513219820] ssid=
Attempting to reconnect...
I (20632) wifi: mode : null
I (20634) wifi: flush txq
I (20634) wifi: stop sw txq
I (20635) wifi: lmac stop hw txq
[D][WiFiGeneric.cpp:265] _eventCallback(): Event: 3 - STA_STOP
I (20644) wifi: mode : sta (30:ae:a4:04:42:c8)
[D][WiFiGeneric.cpp:265] _eventCallback(): Event: 2 - STA_START
[D][WiFiGeneric.cpp:265] _eventCallback(): Event: 2 - STA_START
[D][WiFiGeneric.cpp:265] _eventCallback(): Event: 5 - STA_DISCONNECTED
[W][WiFiGeneric.cpp:270] _eventCallback(): Reason: 201 - AUTH_FAIL
Connection result: 1
[E][WiFiUdp.cpp:183] endPacket(): could not send data: 118
W (24182) wifi: Haven't to connect to a suitable AP now!
[1513219823] ssid=
Attempting to reconnect...
I (24254) wifi: mode : null
I (24256) wifi: flush txq
I (24257) wifi: stop sw txq
I (24257) wifi: lmac stop hw txq
I (24266) wifi: mode : sta (30:ae:a4:04:42:c8)
[D][WiFiGeneric.cpp:265] _eventCallback(): Event: 3 - STA_STOP
[D][WiFiGeneric.cpp:265] _eventCallback(): Event: 2 - STA_START
[D][WiFiGeneric.cpp:265] _eventCallback(): Event: 2 - STA_START
[D][WiFiGeneric.cpp:265] _eventCallback(): Event: 5 - STA_DISCONNECTED
[W][WiFiGeneric.cpp:270] _eventCallback(): Reason: 201 - AUTH_FAIL
Connection result: 1
[E][WiFiUdp.cpp:183] endPacket(): could not send data: 118
W (27804) wifi: Haven't to connect to a suitable AP now!
[1513219827] ssid=
Attempting to reconnect...
I (27820) wifi: mode : null
I (27822) wifi: flush txq
I (27822) wifi: stop sw txq
I (27822) wifi: lmac stop hw txq
[D][WiFiGeneric.cpp:265] _eventCallback(): Event: 3 - STA_STOP
I (27832) wifi: mode : sta (30:ae:a4:04:42:c8)
[D][WiFiGeneric.cpp:265] _eventCallback(): Event: 2 - STA_START
[D][WiFiGeneric.cpp:265] _eventCallback(): Event: 2 - STA_START
I (30311) wifi: n:6 0, o:1 0, ap:255 255, sta:6 0, prof:1
I (30312) wifi: state: init -> auth (b0)
I (30318) wifi: state: auth -> assoc (0)
I (30339) wifi: state: assoc -> run (10)
I (30340) wifi: connected with glowyrectangle, channel 6
[D][WiFiGeneric.cpp:265] _eventCallback(): Event: 4 - STA_CONNECTED
[D][WiFiGeneric.cpp:265] _eventCallback(): Event: 7 - STA_GOT_IP
Connection result: 3
[1513219831] ssid=glowyrectangle
[1513219832] ssid=glowyrectangle
I (33340) wifi: pm start, type:0

[1513219833] ssid=glowyrectangle
[1513219834] ssid=glowyrectangle
[1513219835] ssid=glowyrectangle
[1513219835] ssid=glowyrectangle
[1513219836] ssid=glowyrectangle

Einpacken

Ich habe ein bisschen im SDK herumgegraben, sehe aber nichts Offensichtliches. Ich kann ein bisschen herumgraben, aber ich hoffe, dass die obigen Informationen nützlich sind. Wenn ich weitere Informationen zur Verfügung stellen kann, lassen Sie es mich bitte wissen. Ich würde mehr als glücklich sein, zu verpflichten.

Ich habe versucht, einige PCaps im Monitormodus zu bekommen, aber sie waren nicht sehr interessant. Es schien nur, dass der ESP32 nach dem Trennen der Verbindung nichts sendete.

Ich bin froh, dass ich zumindest eine Problemumgehung gefunden habe (trennen (wahr) + beginnen (ssid, passwd)).

@vseven @Markusenz @sidoh
Entschuldigung, um später zu antworten, und vielen Dank für Ihre harte Arbeit am SDK.
Der Anhang ist die Debug-Version von wifi lib. Sie können damit einen Test durchführen. Anschließend können wir Ihre Protokolle analysieren, um das Problem zu lösen.
wifi_lib.tar.gz

@igrr - Ich habe versucht, sowohl offen als auch sicher mit den gleichen Ergebnissen. Ich kann versuchen, Ihnen eine Paketerfassung zu ermöglichen, aber das Problem ist äußerst zufällig. Es kann viermal in einer Stunde oder zweimal am Tag durchgeführt werden, sodass die Erfassung sehr mühsam sein kann. Jetzt, da mehrere Personen das gleiche Problem haben, werde ich jedoch die von @zhangyanjiaoesp veröffentlichte Debug-Version Paketerfassung versuchen.

Wird die automatische Wiederverbindung so repariert, dass sie wie beabsichtigt funktioniert? Es hört sich so an, als würde @sidoh es

Ich werde das dieses Wochenende neu kompilieren und laden lassen.

BEARBEITEN: Die Datei wifi_lib.tar.gz ist leer. Kannst du bitte umbuchen?

Ich denke, das Interessanteste, was mir aufgefallen ist, war Folgendes:

WiFi.disconnect(true);
WiFi.begin(SSID, PASSWORD);

Immer wieder eine Verbindung für mich herstellen (der Parameter true zu disconnect ist wichtig). Ich denke, WiFi.disconnect(true) schaltet das Radio aus. Ich vermute, dass unter bestimmten Umständen ein Status über das Netzwerk, zu dem der ESP32 eine Verbindung herstellen soll, gelöscht wird und durch das oben Gesagte zurückgesetzt wird.

Interessant ist auch, dass das Problem zu 100% reproduzierbar zu sein scheint, wenn Sie das WLAN-Netzwerk ausschalten, darauf warten, dass der ESP32 feststellt, dass die Verbindung getrennt wurde, und das Netzwerk wieder einschalten. Wenn das Netzwerk erneut angezeigt wird, bevor der ESP32 dies bemerkt, kann es manchmal erfolgreich eine erneute Verbindung herstellen. Aus den Protokollen geht hervor, dass der Unterschied darin besteht, dass im ersteren Fall ein NO_AP_FOUND -Ereignis ausgelöst wird, im letzteren jedoch nicht.

@vseven
wifi_debug_lib.zip

Führen Sie den mit den Debug-Bibliotheken verknüpften Code erneut aus. Protokolle hier:

• fast_ap_recreate.log - Experiment (A)
• slow_ap_recreate.log - Experiment (B)
• slow_ap_recreate_with_disconnect_true.log - wie Experiment (B) mit WiFi.disconnect(true); und WiFI.begin(SSID) .

Dies war alles in einem offenen Netzwerk.

Bearbeiten - Link zu Rohprotokollen anstelle der Hauptseite.

@zhangyanjiaoesp - @sidoh dies bereits getan hat und bereits viele Protokolle bereitgestellt hat, aber

@ Sidoh
In den slow_ap_recreate.log finden wir, dass es Drucke gibt

[1513308152] ssid =
Wiederverbindung wird versucht...

Es scheint, als ob Ihre SSID leer ist. Geben Sie nach dem Scannen aller Kanäle keine gefundene AP zurück.
Daher sollten Sie Ihren Code überprüfen, um festzustellen, ob die SSID richtig eingestellt ist.

Hallo @zhangyanjiaoesp ,

Ich denke, das ist wahrscheinlich das Fleisch des Problems. In slow_ap_recreate.log wird der Wiederverbindungscode gerade ausgeführt (vollständige Skizze hier ):

WiFi.begin();

Es wird also kein AP geliefert. Mein Verständnis des SDK ist, dass es sich einfach wieder mit dem letzten bekannten AP verbinden sollte. Wenn die zuletzt verwendete SSID nicht gefunden werden kann, wird möglicherweise die Konfiguration gelöscht. Wird das erwartet?

Dies zu verwenden scheint immer zu funktionieren:

WiFi.disconnect(true);
WiFi.begin(ssid, passwd);

Bearbeiten - Nur um sicherzustellen, dass das Setup klar ist. Wenn die erneute Verbindung nicht funktioniert, verschwindet der AP so lange, bis das SDK feststellt, dass er nicht mehr vorhanden ist. Vielleicht ist dies jedoch ein erwartetes Verhalten.

@sidoh Ja, du hast recht. Dies ist das erwartete Verhalten. Sie können es mit Ihrer Methode umgehen:

WiFi.disconnect (true);
WiFi.begin (ssid, passwd);

Ich verstehe, das macht Sinn. Ich werde versuchen, in den nächsten Tagen ohne WiFi.begin() zu reproduzieren. Denken Sie, das Richtige ist, dass das SDK nur die Verbindung wieder herstellt.

Wo wird die Wiederverbindung im SDK behandelt? Die einzige Referenz, die ich finden kann, ist hier , die WiFi.begin() zu verwenden scheint. Wird das erwartet?

ja, du hast recht

Bedeutet das nicht, dass der SDK-Code, der Wiederverbindungen verarbeitet, dasselbe Problem hat wie meine Demo? Wenn versucht wird, die Verbindung wiederherzustellen, nachdem der AP verschwunden ist, wird die SSID gelöscht und kann die Verbindung erst wieder herstellen, wenn die AP-Informationen erneut bereitgestellt werden.

Auf jeden Fall sollte das SDK versuchen, die Verbindung automatisch wiederherzustellen. Das ist der springende Punkt bei WiFi.setAutoReconnect (true).

@everslick - Ich stimme vollkommen zu, es scheint nicht zu funktionieren, weshalb ich dies ursprünglich vor mehr als 3 Monaten gepostet habe. Der WiFi.setAutoReconnect (true) scheint keine erneute Verbindung herzustellen, was gelinde gesagt ironisch ist. Das einzige, was funktioniert, ist, den Controller neu zu starten und ihn über seine normale Verbindung zurückzulassen (was bei der Steuerung der LEDs beim Ausschalten nicht funktioniert) oder das vollständige Trennen und erneute Verbinden durchzuführen.

@zhangyanjiaoesp - Sie sagen also, dass WiFi.setAutoReconnect (true) einfach nicht funktioniert? Und um das Problem zu umgehen, müssen wir die Verbindung aufrufen und die Verbindung mit der SSID und dem Kennwort erneut herstellen. Wenn dies zutrifft, wird es behoben oder zumindest die Dokumentation aktualisiert, um zu sagen, dass es nicht funktioniert?

Ich habe ein ähnliches Problem,
Nach dem Zurücksetzen der By-Software in der folgenden Reihenfolge:
WiFi.disconnect (); // Stellen Sie sicher, dass die aktuelle SSID / das aktuelle Kennwort gelöscht ist
Verzögerung (1000);
ESP.restart ();
Der ESP wird neu gestartet, stellt jedoch erst nach einem Hardware-Reset eine Verbindung zum AP her.
Die Funktion Wifi.disconnect () funktioniert ebenfalls nicht richtig.
Robert

Der schwierige Weg besteht darin, einen GPIO-Pin mit dem EN-Pin zu verbinden und einen System-Reset (GPIO Low) zu erzwingen, falls ein Neustart / Neustart oder eine WLAN-Verbindung erforderlich ist.

Trennen Sie nicht. Einfach neu starten funktioniert bei mir. Aber wieder ... sollte nicht neu gestartet werden müssen, wenn WiFi.setAutoReconnect (true) ordnungsgemäß funktioniert hat.

Es sollte schön sein, wenn Wifi.disconnect oder Autoreconnect funktioniert, aber was ist der Sinn, wenn es ein Problem mit der Wifi-Verbindung gibt, ist dies im Fall von ESP32 ein großes Problem (alle nachfolgenden Anwendungen basieren wahrscheinlich auf Wifi), also die ultimative Lösung ist ein Hardware-Reset zu versuchen, wenn dieser fehlschlägt ... bye bye ESP32-Nutzung.

Ein Neustart ist KEINE Lösung. Ich verwende dies für die RGB-LED-Steuerung und ein Neustart setzt die Lichter zurück. Wenn es eine Funktion gibt, die dem ESP mitteilt, dass es bei einem WLAN-Verlust erneut versuchen sollte, eine Verbindung herzustellen, sollte diese Funktion tatsächlich wie dokumentiert funktionieren.

OK, ich habe versucht, das ESP über ein GPIO zurückzusetzen, aber es sieht so aus, als würde ESP keinen Selbstmord mögen, so dass es ohne ein externes Gerät nicht funktioniert. Daher stimmte ich zu, dass die einzige verbleibende Lösung darin besteht, dass die WLAN-Trennung, der ESP-Neustart oder die automatische WLAN-Wiederverbindung tatsächlich funktionieren.
Ein weiteres Problem, auf das wir auf ein funktionierendes ESP-Modul warten müssen (ich stelle fest, dass das I2C-Protokoll, soweit ich es testen konnte, ein weiteres ist, auf das ich auf eine Lösung warte).
ESP32 ist bis jetzt weit davon entfernt, zuverlässig zu sein ....
Robert

und ich habe die SPI-Schnittstelle nicht erwähnt ...

esp_restart_noos ();

Wenn ESP.restart () nicht funktioniert.

Ich verwende Arduino IDE, um ein WeMos Lolin32 zu konfigurieren.
Ich benutze die Funktion:

void unitReset ()
 {
#ifdef DEBUGGING
  Serial.println ("Coordinator will REBOOT NOW ....");
#endif    
  WiFi.disconnect();                          //Ensure current  ssid/password is erased
  delay (1000);
  ESP.restart();
 }

Wenn WeMos in WiFi.mode (WIFI_STA) verbunden ist, rufe ich diese Funktion von MQTT auf.
Es startet das System tatsächlich neu und die Skizze startet, aber Wifi (kann von diesem Punkt aus nicht synchronisiert werden, Verbindungsversuche laufen in einer Endlosschleife ab). Ein manueller Reset löst das Problem.
Es funktioniert jedoch dieselbe Funktion, die mit WiFi.mode (WIFI_STA) über Telnet aufgerufen wird.

@vseven @everslick @rrobinet
Sie verstehen die Bedeutung der Funktion WiFi.setAutoReconnect(true) falsch.
In unserem Code bedeutet WiFi.setAutoReconnect(true) nicht, die WLAN-Verbindung utomotisch wiederherzustellen. Wenn der ESP32 zuvor eine Verbindung zum WLAN hergestellt hat, wird beim nächsten Neustart des Systems das zuletzt verbundene WLAN verbunden.
Wir werden also einige Kommentare in den Code einfügen. Tut mir leid, dass ich Ihre Arbeit beeinflusst habe.

@zhangyanjiaoesp Tut ich das so gesagt habe: Das ist einfach "falsch". Diese API wurde für den ESP8266 eingeführt und hat genau das getan: WLAN automatisch neu verbinden. Was Sie beschreiben, ist was das WiFi.setAutoConnect (); Methode ist für. Sie können die Semantik einer gut etablierten API nicht nach Belieben ändern.

Außerdem wäre die Funktionsbenennung unglaublich schlecht und irreführend, selbst wenn die API so funktionieren sollte, wie Sie es gesagt haben.

Wie auch immer. Wir sprechen hier von IoT-Geräten. Die Standardeinstellung sollte sein, auf jeden Fall mit dem Netzwerk verbunden zu bleiben. Wenn überhaupt, sollte es Funktionen geben, mit denen die automatische Wiederverbindung deaktiviert werden kann und der API-Benutzer nicht durch die Rahmen springen muss, damit er sich so verhält.

@vseven @everslick @rrobinet
Bitte schauen Sie hier , es sagt dem Benutzer, dass diese Funktion beim Einschalten funktioniert.

ESP.restart Problem, Korrektur.
Nun, das obige Skript funktionierte mit einem ESP8266 und nicht mit einem ESP32. Nach einigen Tests ist das Problem jedoch die Verwendung von WiFi.disconnect (true) vor dem ESP.restart (). Diese Funktion für ESP32 sollte bei der Wifi-Initialisierung platziert werden (siehe https://github.com/espressif/arduino-esp32/pull/466).
Etwas wie:

<snip>
  WiFi.disconnect(true);                                      // Clear Wifi Credentials
  WiFi.persistent(false);                                     // Avoid to store Wifi configuration in Flash
  WiFi.mode(WIFI_STA);                                        // Ensure WiFi mode is Station 
  Serial.println("Now Connecting to Access Point ...");  
  // Connect to the Access Point
  WiFi.begin(ssid,key);
<snip>

und das Zurücksetzen des Geräts sollte einfach sein:

void unitReset ()
 {
#ifdef DEBUGGING
  Serial.println ("Coordinator will REBOOT NOW ....");
#endif    
  delay (1000);
  ESP.restart();
 }

Können Sie Folgendes bestätigen, was ich bisher beim Lesen dieses Threads verstehe:

• ESP32 verhält sich anders als ESP8266, sodass beim ESP32 zur Laufzeit keine automatische WLAN-Verbindung hergestellt wird, falls der AP für einige Zeit verloren geht oder nicht erreichbar ist. Der Benutzer muss den Verlust von WLAN erkennen und die erneute Verbindung in seinem Code behandeln (nicht möglich ohne Neustart des Geräts?)
• ESP32 verhält sich anders als ESP8266, da nach dem Start manchmal keine Verbindung zum AP hergestellt wird. Wir benötigen bestimmte Codezeilen, um das Problem zu beheben, wie hier https://github.com/espressif/arduino-esp32/issues/653#issuecomment -356534618
• Die beschriebenen Probleme werden als erwartetes Verhalten angesehen und sollen das Verhalten in der API nicht ändern. Daher müssen wir unseren Code bei der Arbeit mit ESP32 entsprechend anpassen

@ Markusenz , ich kann bestätigen, dass https://github.com/espressif/arduino-esp32/issues/653#issuecomment -355659659 immer für mich zu funktionieren scheint. Es scheint, dass der einzige Verweis auf getAutoReconnect der Link ist, den ich in den Kommentar eingefügt habe, der Trennungen nicht gut handhaben würde, wenn alles.

@zhangyanjiaoesp , danke für deine Hilfe dazu. :) :)

Sie verstehen die Bedeutung der Funktion WiFi.setAutoReconnect (true) falsch.
In unserem Code bedeutet WiFi.setAutoReconnect (true) nicht, die WLAN-Verbindung utomotisch wiederherzustellen. Wenn der ESP32 zuvor eine Verbindung zum WLAN hergestellt hat, wird beim nächsten Neustart des Systems das zuletzt verbundene WLAN verbunden.

Die Methode, mit der Sie verknüpft haben, ist setAutoConnect , nicht setAutoReconnect . Ich denke, diese Methoden sind unterschiedlich. setAutoReconnect ist da . Es setzt nur eine Flagge, und ich denke, der einzige Ort, an dem die Flagge verwendet wird, ist hier .

Angesichts des Namens der Methode und der Art und Weise, wie dieses Flag intern verwendet wird, scheint diese Methode das zu tun, was die Leute annehmen - automatische Versuche aktivieren / deaktivieren, nach einer Trennung wieder eine Verbindung zu einem AP herzustellen.

Meiner Meinung nach funktioniert diese Funktion einfach nicht wie erwartet, und ich denke, dies liegt möglicherweise daran, dass das SDK intern WiFi.begin() , wodurch die SSID gelöscht wird, wenn der gespeicherte AP nicht vorhanden ist, wie ich oben festgestellt habe.

So scheint es also zu geschehen. Kann das SDK aktualisiert werden, um den AP NICHT zu löschen, wenn er nicht sofort angezeigt wird? Oder um ein WiFi.Begin mit der letzten bekannten SSID und dem Passwort zu machen, wenn WiFi.setAutoReconnect (true) oder fehlt mir etwas?

Wenn mein Denken / Graben richtig ist, bezweifle ich wirklich, dass dieses Verhalten beabsichtigt oder erwartet ist. Es ist wahrscheinlich, dass setAutoReconnect die Funktionalität haben soll, die die Leute in diesem Thread erwarten, und es hat nur einige Fehler.

Mein Vorschlag wäre, es vorerst zu umgehen. In meinem eigenen Projekt füge ich einfach einen Event-Handler hinzu, der dies tut

WiFi.disconnect(true);
WiFi.begin(ssid, passwd);

und es funktioniert bei mir.

Es scheint, als würde die Wiederverbindung derzeit eher vom Arduino SDK als vom zugrunde liegenden Material verwaltet. Mit dem ESP8266 Arduino SDK wird die Wiederverbindung vom Nicht-OS-SDK übernommen. Ein Fix für das ESP32 Arduino SDK wird also wahrscheinlich sowieso so aussehen wie diese externe Problemumgehung (wieder - vorausgesetzt, mein Denken ist richtig. Ich könnte sicherlich falsch liegen).

Bearbeiten - Hier ist der relevante Abschnitt in meinem Code, der die Wiederverbindung behandelt.

@ Markusenz
Du hast recht.
@vseven @sidoh
Ich stimme @sidoh zu , Sie können es jetzt

Nach einigem Graben fand ich, dass dies ziemlich gut funktioniert:

static bool sta_was_connected = false;

static void poll_connection(void) {                                         
#ifdef ESP32
  // this is a crude workaround due to the inability of
  // the ESP32 to reconnect to an accesspoint automatically.
  //
  // https://github.com/espressif/arduino-esp32/issues/653

  static uint32_t ms = millis();

  if (!WiFi.isConnected() && (millis() - ms) > 1000 * 5) {
    ms = millis();

    if (sta_was_connected) WiFi.reconnect(); else WiFi.begin();
  }
#endif
}

loop() {
  poll_connection();
}

Im WiFi-Ereignishandler für SYSTEM_EVENT_STA_GOT_IP müssen Sie sta_was_connected auf true setzen.

Dies funktioniert auch, wenn der Accesspoint beim Booten des ESP32 nicht verfügbar war.

Der Vorteil ist, dass die STA-Konfiguration nicht gelöscht wird. Dies ist besonders nützlich, wenn Sie eine statische IP-Konfiguration festgelegt haben (ohne DHCP).

bekommst du eine
[D][WiFiGeneric.cpp:293] _eventCallback(): Event: 8 - STA_LOST_IP
wenn Sie lange genug warten (es gibt eine Verzögerung)

Ich werde es versuchen

    } else if(event->event_id == SYSTEM_EVENT_STA_LOST_IP) {
        if(WiFi.getAutoReconnect()){
            WiFi.begin();
        }

Hier ist eine funktionierende Lösung, die einige Probleme mit der WiFi-Bibliothek umgeht.
Beachten Sie die while-Schleifen nach einem WiFi.begin ().
Ich habe festgestellt, dass die Verbindungsverzögerung je nach Router und Verschlüsselungseinstellungen variiert. AES und WPA2 scheinen am besten, schnellsten und zuverlässigsten zu sein.

Warten Sie zu diesem Zweck, bis Sie wissen, dass eine Verbindung funktioniert, aber stellen Sie sicher, dass Sie nicht abschließen.

Ich habe festgestellt, dass einige WiFi.disconnect () aufrufen. Achten Sie darauf, WiFi.persistent (false) zu verwenden. Damit oder jedes Mal, wenn Sie sich erholen, schreiben Sie den NV FLASH neu und werden ihn blockieren, wenn der FLASH stirbt.

Teilcode-Probe

setup()
{
  WiFi.begin( rssiSSID , password );

  int WLcount = 0;
  while (WiFi.status() != WL_CONNECTED && WLcount < 250 ) 
  {
    delay( 100 );
    #ifdef DEBUG
       Serial.print(".");
    #endif
    ++WLcount;
  }
}

void loop() 
{
  if (WiFi.status() ==  WL_CONNECTED) 
  {
    // PUT_YOUR_UP_TIME_CODE_HERE   

    #ifdef DEBUG
       Serial.print("C");
       if (UpCount >= 20)   // just keep terminal from scrolling sideways
       {
        UpCount = 0;
        Serial.println();
       }
       ++UpCount;
    #endif

      // END WiFi connected loop()
  } else
  {
    // PUT_YOUR_DOWN_TIME_CODE_HERE
    //  WiFi DOWN loop

    #ifdef DEBUG
        WFstatus = getWifiStatus( WFstatus );
    #endif

    WiFi.begin( rssiSSID , password );
    int WLcount = 0;
    // loop - depending on router, connect can be from 4 - 20 seconds
    // usually longer to reconnect than the connect at boot
    // lopping till reconnect seems to let it settle
    // usually around 80 count to breakout
    while (WiFi.status() != WL_CONNECTED && WLcount < 250 ) 
    {
        delay( 100 );
        #ifdef DEBUG  
            Serial.print(".");
            // just keep terminal from scrolling sideways in test
            if (UpCount >= 20)
            {
                UpCount = 0;
                Serial.println();
            }
            ++UpCount;
        #endif
        ++WLcount;
    }
    delay( 1000 );
  }  // END WiFi DOWN 
} // END loop()


int getWifiStatus( int WiFiStatus  )
{
  WiFiStatus = WiFi.status();
  Serial.print("\tStatus "); Serial.print( WiFiStatus );
  switch( WiFiStatus )
     {
        case WL_IDLE_STATUS :           // WL_IDLE_STATUS     = 0, 
                Serial.println(", WiFi IDLE "); 
                break;
        case WL_NO_SSID_AVAIL:          // WL_NO_SSID_AVAIL   = 1,
                Serial.println(", NO SSID AVAIL ");
                break;
        case WL_SCAN_COMPLETED:         // WL_SCAN_COMPLETED  = 2,
                Serial.println(", WiFi SCAN_COMPLETED "); 
                break;
        case WL_CONNECTED:      // WL_CONNECTED       = 3,
                Serial.println(", WiFi CONNECTED "); 
                WiFi.persistent(true);  
                break;
        case WL_CONNECT_FAILED:         // WL_CONNECT_FAILED  = 4,
                Serial.println(", WiFi WL_CONNECT FAILED"); 
                break;
        case WL_CONNECTION_LOST:        // WL_CONNECTION_LOST = 5,
                Serial.println(", WiFi CONNECTION LOST");
                WiFi.persistent(false); // don't keep writing FLASH
                break;   
        case WL_DISCONNECTED:            // WL_DISCONNECTED    = 6
                Serial.println(", WiFi DISCONNECTED ==");
                break;
  }
  return WiFiStatus;
}  // END getWifiStatus()

======
Es dauert durchschnittlich 8-15 Sekunden, um einen Moduswechsel zu erkennen
note "." verbindet sich
"C" sind verbunden

OUTPUT
CCCCCCCCC     Status 5, WiFi CONNECTION LOST    Unplugged Router here
.........
....................                            Trying
 More lines of dots...
....................
...........       Status 1, NO SSID AVAIL       Gave up, Changed Modes
.........                                       Replugged Router here
....................
................CCCC                            TaDa I'm Back...
CCCCCCCCCCCCCCCCCCCC

Ich benutze dies, scheint für mich zu arbeiten

void WiFiEvent(WiFiEvent_t event){
    if(event == SYSTEM_EVENT_STA_DISCONNECTED){
      Serial.println("Event: SYSTEM_EVENT_STA_DISCONNECTED, reconnecting");
      WiFi.reconnect();
    }
}

if(WiFi.getAutoReconnect()) WiFi.onEvent(WiFiEvent);

Ich denke, meine Wohnung mit den 50 APs in der Nähe ist wirklich ein großartiger Ort, um dieses Problem zu testen. Die Lösung von Tablatronix führt dazu, dass mein esp32 entleert wird, und ich sehe nicht, wie die Lösung von mickeypop etwas Gutes bewirken würde, was nicht geholfen hat. Ich habe festgestellt, dass ein Neustart der WLAN-Verbindung ziemlich gut funktioniert, aber selbst das erfordert von Zeit zu Zeit einen Hard-Reset. Nebenbei habe ich einen esp8266 in derselben Umgebung, der niemals manuelle Eingriffe erfordert. Ich habe hier ein paar andere Vorschläge ohne Glück ausprobiert.

Ich finde es erstaunlich, wie viel Entwicklung gemacht wurde. Ehrlich gesagt habe ich nicht die Fähigkeiten, eine Lösung zu finden. Wenn jemand etwas hat, das er in einer rauen Umgebung ausprobieren möchte, kann er mir gerne Tests schicken. Wir brauchen den esp32 wirklich, um eine solide Verbindung zu haben und intermittierendes WLAN elegant zu handhaben.

Bearbeiten: nach vielem Ausprobieren: @tablatronix Wenn ich diese Zeile zu schnell laufen
if(WiFi.getAutoReconnect()) WiFi.onEvent(WiFiEvent);
Edit2: dauerte 30 Minuten vor dem Absetzen

@thefatmoop Ich bin auf ein Problem mit der WLAN-Wiederverbindung
NVS-Schlüssel anzeigen

Futter.

thefatmoop

Beide Lösungen sollten funktionieren.
Wie ich bemerkt habe; "_Hier ist eine funktionierende Lösung, die einige Probleme mit der WiFi-Bibliothek umgeht._"

Während einer einige Bibliotheksprobleme umgeht, verwendet der andere den WiFi.onEvent () -Dienst. Beide erkennen einfach, wenn eine Verbindung unterbrochen wurde, und initiieren erneut eine neue Verbindung.

Während einige festgestellt haben, dass sie nach einigen Stunden immer wieder gestoßen werden, ist dies mit ziemlicher Sicherheit eine Funktion der Lease-Zeit des DHCP-Servers im Router.

Wenn die Lease-Zeit des Routers nicht gleich ist, "vergessen" Geräte manchmal das Update, was zu einer Nicht-IP-Adresse führt, obwohl manchmal die WiFi-Verbindung noch besteht.

• WiFi.begin () zwingt den DHCP, eine neue IP zusammen mit einer neuen Verbindung zu erhalten.
• WiFi.reconnect () funktioniert, geht jedoch häufig davon aus, dass das Gerät noch eine IP-Adresse hat und möglicherweise keine DHCP-Anforderung ausführt.

Der einfache Weg, dies zu umgehen, besteht darin, den DHCP-Router regelmäßig zu pingen.
Dadurch wird der Router gezwungen zu wissen, dass Sie sich noch im Netzwerk befinden, und die Lease auf dem neuesten Stand zu halten.

Beim Neustart wird möglicherweise erneut eine Verbindung hergestellt, das Problem der Trennung wird jedoch nicht behoben. Oft können Anwendungen nicht mehr synchronisiert werden, wenn Sie einfach neu starten.

Eine erneute Verbindung ohne Neustart ist daher häufig erforderlich.

reconnect wiederholt dhcp nicht. Ich habe dies herausgefunden, als ich versucht habe, den Hostnamen zu ändern und die Verbindung wiederherzustellen. Ich wollte es als Fehler ablegen.

Die Lösung von @tablatronix funktioniert für mich, danke! @thefatmoop können Sie die Implementierung auf OpenMQTTGateway.ino- Code überprüfen.

Der Code wird nach dem Trennen der MQTT aufgerufen. Wenn ich den Code außerhalb dieses Zustands platziere, wird der ESP-Speicherauszug tatsächlich erstellt.

Wenn WiFi.reconnect() Verbindung herstellt, der MQTT-Client jedoch nicht, können Sie nach einigen Versuchen zum erneuten Verbinden des Clients einen weiteren setup_wifi() : mit "connect () delay () und begin ()" erstellen Verbindung. Aber was passiert, wenn der MQTT-Server ausfällt?

Das ist ein Problem auf Anwendungsebene.

Mickeypop-Code-Vorschlag zum Wiki hinzugefügt

Es tut uns leid. Ich bin ein Anfänger in der Arduino / Esp-Programmierung. Ich bin auch mit den Fehlern / Problemen beim Verbinden und erneuten Verbinden von WLAN konfrontiert. Mein Teil des Codes, der sowohl den WiFi & MQTT-Client (PubSubClient) verwaltet als auch tatsächlich auf einem ESP32 von Adafruit / Huzzah32 funktioniert:

void setupWiFi() {
  WiFi.disconnect(true);
  WiFi.begin(WLAN_SSID, WLAN_PASS);
  WiFi.waitForConnectResult();
}

boolean clientReconnect() {
  if(client.connect("esp32_client")) {
    client.subscribe("/test");
  }
  return client.connected();
}

boolean wifi_connected_once = false;
unsigned long last_client_reconnect_attempt = 0;
int client_reconnect_attempts = 0;

void setup() {  
  client.setServer(MQTT_SERVER, 1883);
  client.setCallback(client_callback);
}

void loop() {
  unsigned long loop_start = millis();

  if(WiFi.isConnected()) {
    // WiFi connected
    if(client.connected()) {
      // client connected
      // publish data every 5 seconds
      if(loop_start - last_client_publish >= 5000) {
        client_publish_data();
        last_client_publish = loop_start;
      }
      client.loop();
    } else {
      // client not connected
      // try reconnect a few times every 5 seconds
      if(client_reconnect_attempts <= 5) {
        if(loop_start - last_client_reconnect_attempt > 5000) {
          client_reconnect_attempts++;
          if(clientReconnect()) {
            // client connected
            client_reconnect_attempts = 0;
          }
          last_client_reconnect_attempt = loop_start;
        }
      } else {
        // maybe MQTT server is down
        // try reconnect in 5 minutes
        if(loop_start - last_client_reconnect_attempt > 300000) {
          last_client_reconnect_attempt = loop_start;
          client_reconnect_attempts = 0;
        }
      }
    }
  } else {
    // WiFi not connected
    // try connect for the first time or 
    // try reconnect every 2 minutes
    if((loop_start - last_client_reconnect_attempt > 120000) || wifi_connected_once == false) {
      last_client_reconnect_attempt = loop_start;
      wifi_connected_once = true;
      client_reconnect_attempts = 0;
      setupWiFi();
    }
  }
}

Getestet mit einigen Neustarts des Routers und der Code scheint zu funktionieren, ohne dass ein ESP-Neustart erforderlich ist.
Haben Sie einen viel besseren Vorschlag?

Dieses Problem bringt mich um. Es passiert zufällig manchmal in der ersten Stunde, manchmal nach sechs Stunden, während es ohne Probleme läuft. Ich habe alle möglichen Konfigurationen ausprobiert und keine davon ist zuverlässig. Ein Neustart des ESP über Software oder Hardware ist der letzte Ausweg, der tatsächlich funktioniert, aber für mein Produkt ist dies keine praktikable Lösung.

Das letzte Mal habe ich es laufen lassen und mehr als VIER TAUSEND Versuche versucht, keiner von ihnen mit Erfolg.

Ich habe es bisher versucht:

1) Aktivieren von autoReconnect und Aufrufen von reconnect
2) Deaktivieren von autoReconnect und manuelles Trennen und erneutes Verbinden. In dieser Konfiguration habe ich beide Methoden ausprobiert, um die Antenne vollständig auszuschalten oder nicht. Funktioniert in keinem Modus.

Hier haben Sie einige Protokolle (diese werden derzeit mit mehr als 600 Versuchen ausgeführt, die Verbindung zu einem perfekt funktionierenden Router (TP-LINK) wiederherzustellen:

WARNUNG: WiFi hat die Verbindung unterbrochen. Versuch der erneuten Verbindung 632 bei der nächsten Iteration
Auslösen des WiFi-Wiederverbindungsversuchs 632
I (14944038) wifi: mode: softAP (30: ae: a4: 1a: ca: 1d)
Erstellen von WiFi mit der SSID 'Nano BAB - Entwicklung' und dem Passwort '#######'
Verbindung zu WiFi herstellen 'TP-LINK_A8FB38'
[D] [WiFiGeneric. cpp: 293 ] _eventCallback (): Ereignis: 3 - STA_STOP
[D] [WiFiGeneric. cpp: 293 ] _eventCallback (): Ereignis: 2 - STA_START
[WiFi-Ereignis] Ereignis: 2
[D] [WiFiGeneric. cpp: 293 ] _eventCallback (): Ereignis: 5 - STA_DISCONNECTED
[W] [WiFiGeneric.

Wie Sie sehen, schlägt die Authentifizierung fehl, das Kennwort ist jedoch korrekt. Bei einem früheren Versuch (Nummer 578 !!) aus demselben Beispiel wird Fehler 2 ausgelöst:

WARNUNG: WiFi hat die Verbindung unterbrochen. Versuch der erneuten Verbindung 578 bei der nächsten Iteration
Auslösen des WiFi-Wiederverbindungsversuchs 578
I (14134199) wifi: mode: softAP (30: ae: a4: 1a: ca: 1d)
Erstellen von WiFi mit der SSID 'Nano BAB - Entwicklung' und dem Passwort '##########'
[D] [WiFiGeneric. cpp: 293 ] _eventCallback (): Ereignis: 3 - STA_STOP
[WiFi-Ereignis] Ereignis: 3
Verbindung zu WiFi herstellen 'TP-LINK_A8FB38'
[D] [WiFiGeneric. cpp: 293 ] _eventCallback (): Ereignis: 13 - AP_START
[WiFi-Ereignis] Ereignis: 13I (14134890) WLAN: Modus: sta (30: ae: a4: 1a: ca: 1c) + softAP (30: ae: a4: 1a: ca: 1d)
[D] [WiFiGeneric. cpp: 293 ] _eventCallback (): Ereignis: 2 - STA_START *

[WiFi-Ereignis] Ereignis: 2 [D] [WiFiGeneric.cpp: 293] _eventCallback (): Ereignis: 2 - STA_START
[WiFi-Ereignis] Ereignis: 2I (14137748) WLAN: AP-Kanal einstellen o: 1,1 n: 6,1
I (14137749) wifi: n: 6 1, o: 1 0, ap: 6 1, sta: 6 1, prof: 1
I (14138422) wifi: state: init -> auth (b0)
I (14139423) wifi: state: auth -> init (2)
I (14139424) wifi: n: 6 0, o: 6 1, ap: 6 1, sta: 6 1, prof: 6
[D] [WiFiGeneric. cpp: 293 ] _eventCallback (): Ereignis: 5 - STA_DISCONNECTED
[W] [WiFiGeneric.

Es ist immer einer der beiden Fehler. Am Ende ist einfach, dass es nicht wieder verbindet.

Das Komische ist, dass ich den Router manuell trennen kann, indem ich einige Minuten am Netzkabel ziehe. Mein Code erkennt das Trennen und beginnt erneut zu versuchen. Dann stellt mein System die Verbindung wieder her, wenn es wieder eintritt. Wenn der Router jedoch normal funktioniert, tritt dieses Problem schließlich auf ESP verbindet sich einfach nicht wieder.

Übrigens renne ich mit:

Wird im SDK ausgeführt: 'v3.1-dev-239-g1c3dd23f-dirty'
CPU-Frequenz: 240 MHz
WiFi erstellt sowohl ein eigenes privates WiFi als auch eine Verbindung zu einem anderen mit Zugang zum Internet

Wann haben Sie das letzte Mal vom Repo abgeholt?

1132

Sie haben nur Protokolle gepostet, keine Skizze oder Lösung zum erneuten Verbinden.

Das letzte Mal war ungefähr eine Woche oder so. Meine SDK-Version ist 3.1-dev-239.
Entschuldigung, ich habe den Code nicht hinzugefügt, da ich im Grunde alle Lösungen innerhalb des Beitrags getestet habe. Beim Start rufe ich etwas Ähnliches auf wie:

WiFi.disconnect(true);
WiFi.softAP(wifiName, wifiPassword);
WiFi.begin(connectoToWifiSSID, connectToWifiPassword);

Dann behandle ich WiFi-Ereignisse und insbesondere das Ereignis

1) Als Wifi Autoreconnect aktiviert war, verließ ich das System, um die Wiederverbindung selbst zu erledigen
2) Ich habe versucht, die automatische Verbindung zu deaktivieren und bei diesem Ereignis
3) Das letzte, was ich versuche, ist das Trennen der Verbindung durch Ausschalten des Radios und erneutes Verbinden, wenn keine andere Trennung ausgelöst wurde. Ich habe so etwas wie:

reconnections++;
needsReconnection = true;
reconnectionDetection = millis();
Serial.printf("\r\nWARNING: WiFi lost connection. Trying reconnection attempt %d on next iteration\r\n", reconnections);

NeedsReconnection ist ein Flag, das in der Hauptschleife überprüft wird und die Verbindung erneut auslöst, indem im Grunde die ersten drei Codezeilen ausgeführt werden.

Hoffe es macht jetzt Sinn ;-)

Ich bin mir nicht sicher, ob es einen anderen Weg gibt.

Ich habe vergessen zu erwähnen, dass ich auch einen Mungoserver verwende, um eine Rest-API zu implementieren, die maximal 3 gleichzeitige Verbindungen zulässt. Ich bin mir nicht sicher, ob das die Ursache dafür sein könnte.

1. Es gibt keine automatische Verbindung, dafür ist dieses Problem gedacht.
2. WiFi.reconnect ist möglicherweise nicht dasselbe wie connect, begin () (dhcp usw.)
3. Dies kann modusspezifisch sein, ohne Code weiß niemand, was Sie tun, keine Ahnung, wie Sie mit Ereignissen umgehen, oder "Radio ausschalten"

Ich würde vorschlagen, Änderungen vorzunehmen und einen einfachen Testfall zu erstellen.

josmunpav

Ihr Problem kann der WiFi-Modus sein

dein Code

WiFi.softAP(wifiName, wifiPassword);
WiFi.begin(connectoToWifiSSID, connectToWifiPassword);

Sie führen gemischte Modi aus.
WiFi.softAP () ; Standard ist der WIFI_MODE_AP- Modus

WiFi.begin (); Standard ist der WIFI_AP_STA- Modus

Wenn Sie mit dem WIFI_MODE_APSTA- Modus (gemischter Modus) fortfahren, sollten sie sich nicht ändern und WiFi EVENT wird nicht mit verschiedenen Modi

WiFi.mode( WIFI_MODE_APSTA );
WiFi.softAP(wifiName, wifiPassword);
WiFi.begin(connectoToWifiSSID, connectToWifiPassword);

REF INFO
in esp_wifi_types.h

typedef enum {
    WIFI_MODE_NULL = 0,  /**< null mode */
    WIFI_MODE_STA,       /**< WiFi station mode */
    WIFI_MODE_AP,        /**< WiFi soft-AP mode */
    WIFI_MODE_APSTA,     /**< WiFi station + soft-AP mode */
    WIFI_MODE_MAX
} wifi_mode_t;

in wifitypes.h

typedef enum {
    WL_NO_SHIELD        = 255,   // for compatibility with WiFi Shield library
    WL_IDLE_STATUS      = 0,
    WL_NO_SSID_AVAIL    = 1,
    WL_SCAN_COMPLETED   = 2,
    WL_CONNECTED        = 3,
    WL_CONNECT_FAILED   = 4,
    WL_CONNECTION_LOST  = 5,
    WL_DISCONNECTED     = 6
} wl_status_t;

Hallo Mickeypop ,

Ich teste Ihre Lösung von:

WiFi.mode( WIFI_MODE_APSTA );
WiFi.softAP(wifiName, wifiPassword);
WiFi.begin(connectoToWifiSSID, connectToWifiPassword);

Ich rufe WiFi.reconnect () auf, wenn das Ereignis SYSTEM_EVENT_STA_DISCONNECTED auftritt , das ich durch manuelles Trennen des Routers versucht habe und anscheinend funktioniert (dieses Bit hat auch zuvor funktioniert).

Bisher hat es 7 Stunden ohne Unterbrechung über Nacht auf 2 verschiedenen ESP32 gearbeitet. Ich habe sie alle 5 Sekunden gepingt und bisher keine Probleme. Ich konnte mir nicht vorstellen, dass die Deklaration im WiFi.begin und WiFi.softAP () automatisch aktiviert. Daumen drücken. Ich werde jetzt mit intensiveren Tests beginnen, um zu bestätigen, dass dies die Lösung für die Probleme ist, mit denen ich konfrontiert bin.

Übrigens, vielen Dank !!

@mickeypop @josmunpav danke, dass du deine Erkenntnisse geteilt hast.
Ich habe es dem Wiki hinzugefügt

Dies macht keinen Sinn. Dies weist darauf hin, dass ein Fehler in enablesta oder enableoftap vorliegt, wenn der vorherige Einstellungsmodus das Ergebnis ändert. Aus diesem Grund habe ich vorgeschlagen, dass dies modusspezifisch ist. Problemumgehungen sollten nicht erforderlich sein. Der Reproduktionscode wäre also schön

Vieles davon macht keinen Sinn, wie @everslick oben deutlich gemacht hat: https://github.com/espressif/arduino-esp32/issues/653#issuecomment -356515973. Tatsächlich kann ich nicht glauben, dass ich dies vor 6 Monaten gepostet habe und immer noch darüber gesprochen habe, als es eigentlich nie ein Problem gewesen sein sollte.

Warum etwas namens "autoReconnect" heißt, das sich nicht automatisch wieder verbindet, ist rätselhaft. Jeder scheint seinen eigenen Code zu erfinden, um dieses Manko / diesen Fehler zu beheben. Ich werde eine neue Kopie des Codes ziehen und gemäß @ tablatronix- Vorschlag erneut springende Punkt dabei ist, dass wir nichts davon tun müssen ... es sollte wie das ESP8266 funktionieren und die Verbindung von selbst wiederherstellen !

Ich persönlich habe immer noch Probleme damit, dass der Chip gelegentlich vollständig blockiert, wenn er in diese Trennschleife gerät. Ich habe es bis 10 gezählt und neu gestartet, aber zufällig (1 von 15 oder so Neustarts) startet es nicht neu und nur harte Sperren, die einen Kaltstart erfordern. Ich würde sofort zum ESP8266 wechseln, wenn er bessere / mehr analoge Eingänge hätte, aber leider nicht. Nicht, dass der ESP32 auch darin sehr gut ist (https://www.esp32.com/viewtopic.php?f=19&t=2881).

In esp8266 ist autoreconnect im SDK implementiert, in esp32 gibt es keine Implementierung, daher wurde es der Bibliothek hinzugefügt, um eine gewisse Kompatibilität zu erreichen, obwohl es nur für WIFI_REASON_AUTH_EXPIRE implementiert ist.

Es kann implementiert werden, muss aber noch ausgearbeitet werden, und diese Bibliothek ist immer noch Alpha, so dass es wirklich keine Erwartung geben sollte. Das SDK kann sich ändern, das gesamte Ereignissystem kann sich ändern. Die Implementierung solcher Kernfunktionen braucht also Zeit.

Ganz zu schweigen davon, wenn espressif dies im SDK implementiert, haben wir nur unsere ganze Zeit verschwendet.

Wenn ich sage, dass es ausgearbeitet werden muss, meine ich, dass einige offene Fragen gelöst werden müssen. Aus diesem Grund bitte ich um Testskizzen für Personen, für die die oben genannte Ereignislösung fehlschlägt.

• Wiederverbindung, kann fehlschlagen, DHCP-Zuweisung verlieren, im Gegensatz zu Disconnect (), begin () **
• Autoconnect verursacht eine falsche Ausgabe von wl_status und eine Endlosschleife
• sdk gibt auf einigen Routern auth_expire für auth_fail aus (siehe oben)
• esp_wifi_set_mode ist eine asynchrone Rennbedingung
• Autoconnect, funktioniert nicht einmal, https://github.com/espressif/arduino-esp32/issues/173

** reconnect does not enablesta, it just returns false, you should always be checking for return values!

Wenn Sie meine oben beschriebene Problemumgehung verwenden, empfehle ich, die automatische Verbindung zu deaktivieren, um zwei dieser Fehler zu vermeiden.

Hallo Leute, ich bin zurück mit einem Beispiel, das die Probleme reproduziert, mit denen ich konfrontiert bin. Das Beispiel ist voller Kommentare, besteht aber im Wesentlichen aus:

1. Zwei Aufgaben: Hauptaufgabe und Web / WLAN (implementiert von der Mongoose 6.11-Bibliothek)
2. Einige gemeinsam genutzte Objekte für Dummy-Aufgaben wie das Setzen von PWM auf einen Pin, das Lesen des durchschnittlichen ADC-Werts und einen gemeinsam genutzten int-Zähler
3. Eine Testseite unter http: // your_esp32_ip / , auf der Sie sie laufen lassen können und die Sie darüber informiert, wenn die Verbindung getrennt wird. Außerdem werden die Werte der ausgeführten Dummy-Aufgaben angezeigt
4. Ein Semaphor zur Vermeidung von Datenbeschädigungen zwischen Aufgaben. Die Hauptaufgabe nimmt Änderungen am PWM-Pin vor, liest vom ADC und erhöht den Zähler. Die Webaufgabe präsentiert diese Daten auf der Startseite.
5. Typische WiFi-Methoden zum Verbinden, Trennen und Behandeln von WiFi-Ereignissen.
6. Es wird im APSTA-Modus ausgeführt, sodass Sie Ihr eigenes WLAN konfigurieren müssen (Ihr WLAN benötigt eine Internetverbindung, da die Homepage jQuery von einem CDN verwendet, um API-Aufrufe durchzuführen, die vom ESP32 im Beispiel implementiert wurden).

Was ich bisher festgestellt habe, ist, dass, wenn Sie die Dummy-Aufgaben deaktivieren (es gibt ein Flag dafür), beide Aufgaben endlos gut laufen. Wenn Sie sie aktivieren, wird der ESP32 möglicherweise (manchmal kann es Stunden dauern, normalerweise jedoch innerhalb der ersten Stunde) vom WLAN getrennt und kann keine erneute Verbindung herstellen. Der Verbindungsversuch wird alle 10 Sekunden ohne Erfolg ausgeführt.

Ich denke, es gibt einige Interferenzen zwischen ADC- oder PWM-Bibliothek (implementiert von durchzuführen .

Etwas anderes ist mir aufgefallen, dass das WiFi-Signal für den AP stark abnimmt, wenn die Trennung erfolgt. Ich habe dies auf meinem Smartphone überprüft.

Dies sind die typischen WiFi-Protokollnachrichten, die Sie finden können, wenn sie fehlschlagen:

[WiFi-event] event: 5
Disconnected from WiFi. Trying connection again in 10000ms
Web/Main Task is up and running. Shared counter is 11309, Average ADC Value = 1305.000000, PWM Value = 0
Connecting to WiFi 'TP-LINK_A8FB38' with password: 'C1A8FB38' on connection attempt = 108
Oops, there was a problem when connecting. It returned error: 1[D][WiFiGeneric.cpp:293] _eventCallback(): Event: 5 - STA_DISCONNECTED
[W][WiFiGeneric.cpp:298] _eventCallback(): Reason: 2 - AUTH_EXPIRE

Den beigefügten Quellcode und die Beispielseiten finden Sie:

ESP32_APSTA_Mode_Disconnection_Test.zip

PS: Meine echte App macht das Gleiche. Starten des APSTA-Modus mit zwei Aufgaben, eine zum Aktualisieren von Sensoren, Geräten und GPIOS und die zweite zum Behandeln von WLAN und dem von Mungo implementierten Webserver, bei denen das gleiche Problem auftritt.

Ich habe diese Skizze erstellt, um die Verbindung zu testen, alle 10 Sekunden 10 Mal Zeit zu erhalten, WLAN zu trennen und WLAN erneut zu verbinden. Scheint ziemlich gut zu funktionieren, daher implementiere ich meinen anderen Code, um ihn einige Tage lang auszuführen, da ich Probleme mit der erneuten Verbindung hatte.

#include <WiFi.h>
#include "time.h"

const char* ssid       = "ssid1";
const char* password   = "password1";

const char* ntpServer = "pool.ntp.org";
const long  gmtOffset_sec = 3600;
const int   daylightOffset_sec = 3600;

byte wfConnectTry = 0;
byte loopCnt = 0;

void printLocalTime()
{
  struct tm timeinfo;
  if (!getLocalTime(&timeinfo)) {
    Serial.println("Failed to obtain time");
    return;
  }
  Serial.println(&timeinfo, "%A, %B %d %Y %H:%M:%S");
}

void setup()
{
  Serial.begin(115200);

  //connect to WiFi
  Serial.printf("Connecting to %s ", ssid);
  //WiFi.begin(ssid, password);
  wifiStart();
  //init and get the time
  configTime(gmtOffset_sec, daylightOffset_sec, ntpServer);
  if (WiFi.status() == WL_CONNECTED) {
    printLocalTime();
  }

}

void loop()
{
  delay(10000);
  printLocalTime();
  while (WiFi.status() != WL_CONNECTED || wfConnectTry >=5) {
    wfConnectTry++;
    wifiReconnect();

  }
  if (loopCnt >= 10){
    wifiReconnect();
  }
  loopCnt++;
}

void wifiReconnect()
{
  Serial.println(F("Disconnecting"));
  WiFi.disconnect(true);
  delay(500);
  Serial.println(F("Starting WiFi!"));
  wifiStart();
  loopCnt = 0;
}

void wifiStart()
{
  unsigned long timer1 = millis();
  WiFi.begin(ssid, password);
  while (WiFi.status() != WL_CONNECTED && millis() - timer1 < 5000UL) {
    delay(500);
    Serial.print(".");
  }
  if (WiFi.status() == WL_CONNECTED) {
    Serial.println(F(" CONNECTED"));
    wfConnectTry = 0;
  }
  else {
    Serial.println(F("Could not connect!"));
  }
}

.... danke für den Code-Tipp @tablatronix

Verwenden Sie Codezäune drei Häkchen Newline vor und nach

Hier ist eine interessante Information. Ich habe jeden in diesem Thread erwähnten Trick ausprobiert und nichts hat funktioniert. Jedes Mal ,

Meine App stellt eine gute Verbindung zu WiFi her und irgendwann (Tage oder Wochen) verliert sie die Verbindung und nichts kann sie dazu bringen, eine Verbindung herzustellen. Ich habe alle Tricks auf diesem Thread und Nada ausprobiert. Wie oben erwähnt, kann ich mein ESP32 nur dann wieder mit Wifi verbinden, wenn ich diese andere App installiere, um die Dinge zurückzusetzen. Ich frage mich, was es bewirkt, dass mein ESP32 wieder mit WiFi funktioniert.

@gdombiak , haben Sie Debug-Informationen, die zeigen, was der ESP32 tut, wenn er abstürzt? Ich hatte kürzlich eine Ausgabe, in der eine meiner Skizzen wie ein Champion funktionierte, außer als der neue Tag überrollte und es zwei Zeilen gab, die ihn in eine Endlosschleife versetzten, und das ESP sich schließlich einfach selbst beschissen hat, bis ich zurückgesetzt oder neu geladen habe. Ein weiteres Problem, das ich hatte, war, dass ich ein anderes ESP hatte, das als AP_STA aktiv war, und es versuchte immer wieder, eine Verbindung zu ihm herzustellen, anstatt zu normalem WiFI. Musste das andere ESP neu laden und WiFi.mode (WIFI_STA) festlegen, um das zu beheben.

@ AIWIndustries

Schauen Sie sich einen Beitrag an, den ich veröffentlicht habe: https://github.com/espressif/arduino-esp32/issues/1100
Suche nach " SmartConfig / WiFi-Skelett "

Ich habe ein komplettes Skelett geschrieben, das; speichert, mit SmartConfig eingestellt, befasst sich mit WiFi UP und DOWN, stellt die automatische Verbindung wieder her, wenn Down.

Es ist eine vollständige Struktur und wurde immer wieder verbunden, wenn das WLAN ausfiel oder aus unbekannten Gründen einfach getrennt wurde.

Beachten Sie in loop () " // WiFi DOWN ". Ich benutze ein einfaches if () / else, um den WiFi-Status zu verfolgen.
Aufgrund der Espressif-Bibliotheken dauert es etwa 30 bis 40 Sekunden, um zu melden, wenn das WLAN nicht verfügbar ist, und dann nach einer erneuten Verbindung zu suchen.

Wenn der AP aus- und wieder eingeschaltet wird, dauert es ungefähr 30 Sekunden, bis der AP gestartet ist, und weitere 15 Sekunden, bis die Verbindung wiederhergestellt ist, aber immer wieder.

@ AIWIndustries

Es gibt eine Möglichkeit, eine Sperre nachzuschlagen, wenn der Traceback auf dem Terminal gedruckt wird.

Installieren Sie "ESP Exception Decoder" von; https://github.com/me-no-dev/EspExceptionDecoder
Anweisungen sind da.

Nach der Installation kopieren Sie einfach die Traceback-Zeile und fügen sie ein. Sie erfahren dann, was beim Sperren passiert.

Hallo zusammen,

Der folgende Code funktioniert für mich.

void wifiReconnect () {
while (WiFi.status ()! = WL_CONNECTED) {
WiFi.begin (ssid, Passwort);
für (int i = 0; i <= 50; i ++) {
digitalWrite (LED_BUILTIN, HIGH);
Verzögerung (100);
Serial.print (".");
digitalWrite (LED_BUILTIN, LOW);
Verzögerung (100);
}}
}}
}}

Verwenden Sie dies in der Schleife () als

if (WiFi.status ()! = WL_CONNECTED) {
wifiReconnect ();
}}

Hallo zusammen
Ich habe den vor ungefähr 2 Monaten aktualisierten ESP32-Kern verwendet.
In meinem Programm verwende ich Wifi.begin (ssid, pass) in setup () und rufe die WiFi.reconnect () -Methode für das Ereignis "SYSTEM_EVENT_STA_DISCONNECTED" auf. Das System stellte automatisch eine Verbindung her, wenn eine Unterbrechung auftrat. Aber gestern habe ich auf den neuesten Kern aktualisiert und das hat angefangen, Fehler mit Ursachencode 8 zu geben.
Nach einigen Treffern und Versuchen habe ich WiFi.reconnect () kommentiert, dann fing es an, perfekt zu funktionieren. Auch WLAN wird automatisch wieder verbunden, wenn der AP ein- und ausgeschaltet wird.

In meinem Fall nur in Setup-Methode verwende ich
WiFi.mode (WIFI_STA);
Wifi.begin ()

das funktioniert richtig.
Können wir sagen, dass es im neuen Kern nicht erforderlich ist, reconnect () aufzurufen, und autoreconnect jetzt im neuesten Kern funktioniert?

richtig. es besteht keine Notwendigkeit mehr, reconnect aufzurufen;) Ich habe das behoben: P.

Es gibt einen schwerwiegenden Fehler in wifi.Reconnect ().

Bei einem tiefen Blick durch die Bibliotheken, die ich unter verschiedenen Bedingungen gefunden habe, wird die Verbindung ohne DHCP-Update hergestellt, sodass Sie ohne IP-Adresse verbunden sind. - Ich habe es gemeldet, aber noch keinen Fix gesehen.

Ich habe dies einmal bewiesen, indem ich einen UDP-Aufruf in einem Testcode hinzugefügt habe. - Ich konnte per UDP mit dem AP sprechen, hatte aber keine IP-Adresse. Gleichzeitig wurde der MAC in der AP-Verbindungsliste angezeigt.

Sie möchten wifi.begin () verwenden, es ist immer zuverlässig. - Sie müssen einfach sicher sein, dass Sie beim Aufrufen der Verbindung nicht erreichbar sind, da sonst Probleme mit dem Stapelüberlauf auftreten können.

_Die Vorlage, die ich unten geschrieben habe, konnte nie wieder eine Verbindung herstellen._ Sie verwendet SmartConfig und Einstellungen, anstatt den AP / Pass fest zu codieren, obwohl dies leicht geändert werden kann.

Ein Teil meines Codes ist Eigentum des LED-Blinkers, daher habe ich stattdessen Kommentare hinterlassen. Sie können dort einen beliebigen Indikatorcode eingeben.

Schauen Sie sich den WLAN-Teil von loop () an. Ich rufe WiFi.begin (PrefSSID.c_str (), PrefPassword.c_str ()) auf. während immer auf einen Rückgabestatus von WL_CONNECTED geprüft wird.

Hoffe das hilft einigen.

// ESP32 only,  8266 will not work here
#include "FS.h"
#include "esp_system.h"
#include <esp_wifi.h>
#include <string.h>
#include <WiFi.h>
#include <Preferences.h> // WiFi storage

const char* rssiSSID;        // NO MORE hard coded set AP, all SmartConfig
const char* password;
String PrefSSID, PrefPassword;   // used by preferences storage

int WFstatus;
int UpCount; = 0;
int32_t rssi;         // store WiFi signal strength here
String getSsid;
String getPass;
String MAC;

// SSID storage
  Preferences preferences;       // declare class object
// END SSID storage

void setup() {
  Serial.begin(115200);

  Serial.printf("\tWiFi Setup -- \n" ); 
  wifiInit();      // get WiFi connected
  IP_info();
  MAC = getMacAddress();

  delay(2000);  // let thing settle
} // END setup()

void loop()
{
  if ( WiFi.status() == WL_CONNECTED )
  {   // Main connected loop

         // ANY MAIN LOOP CODE HERE

  }   // END Main connected loop()
  else
  {      // WiFi DOWN

    //  wifi down start LED flasher here

    WFstatus = getWifiStatus( WFstatus );
    WiFi.begin(  PrefSSID.c_str() , PrefPassword.c_str() );
    int WLcount = 0;
    while (  WiFi.status() != WL_CONNECTED && WLcount < 200 )
    {
      delay( 100 );
      Serial.printf(".");

        if (UpCount >= 60)  // keep from scrolling sideways forever
        {
           UpCount = 0;
           Serial.printf("\n");
        }
        ++UpCount;
        ++WLcount;
    }

    if( getWifiStatus( WFstatus ) == 3 )   //wifi returns
    { 
      // stop LED flasher, wifi going up
    }
   delay( 1000 );
  } // END WiFi down
} // END loop()


void wifiInit() //
{
  WiFi.mode(WIFI_AP_STA); // required to read NVR before WiFi.begin()

  // load credentials from NVR, a little RTOS code here
  wifi_config_t conf;
  esp_wifi_get_config(WIFI_IF_STA, &conf);     // load wifi settings to struct comf
  rssiSSID = reinterpret_cast<const char*>(conf.sta.ssid);
  password = reinterpret_cast<const char*>(conf.sta.password);

  //  Serial.printf( "SSID = %s\n", rssiSSID );  // un-comment for debuging
  //  Serial.printf( "Pass = %s\n", password );  // un-comment for debuging
  // Open Preferences with wifi namespace. Namespace is limited to 15 chars
  preferences.begin("wifi", false);
    PrefSSID     = preferences.getString("ssid", "none"); //NVS key ssid
    PrefPassword = preferences.getString("password", "none"); //NVS key password
  preferences.end();

  // keep from rewriting flash if not needed
  if( !checkPrefsStore() )   // see is NV and Prefs are the same
  {                          // not the same, setup with SmartConfig
    if( PrefSSID == "none" ) // New...setup wifi
    {
      initSmartConfig();
      delay( 3000);
      ESP.restart(); // reboot with wifi configured
    }
  }

  // I flash LEDs while connecting here

  WiFi.begin( PrefSSID.c_str() , PrefPassword.c_str() );

  int WLcount = 0;
  while (WiFi.status() != WL_CONNECTED && WLcount < 200 ) // can take > 100 loops depending on router settings
  {
    delay( 100 );
    Serial.printf(".");
    ++WLcount;
  }
  delay( 3000 );

  // stop the led flasher here

} // END wifiInit()

// match WiFi IDs in NVS to Pref store, assumes WiFi.mode(WIFI_AP_STA); was executed
bool checkPrefsStore()
{
  bool val = false;
  String NVssid, NVpass, prefssid, prefpass;

  NVssid = getSsidPass( "ssid" );
  NVpass = getSsidPass( "pass" );

  // Open Preferences with my-app namespace. Namespace name is limited to 15 chars
  preferences.begin("wifi", false);
    prefssid  =  preferences.getString("ssid",     "none"); //NVS key ssid
    prefpass  =  preferences.getString("password", "none"); //NVS key password
  preferences.end();

  if( NVssid.equals(prefssid) && NVpass.equals(prefpass) )
  { 
    val = true; 
  }
  return val;
} // END checkPrefsStore()

void initSmartConfig()
{
  // start LED flasher here
  int loopCounter = 0;

  WiFi.mode( WIFI_AP_STA );     //Init WiFi, start SmartConfig
  Serial.printf( "Entering SmartConfig\n" );

  WiFi.beginSmartConfig();

  while (!WiFi.smartConfigDone())
  { // flash led to indicate not configured
    Serial.printf( "." );
    if( loopCounter >= 40 )
    {
      loopCounter = 0;
      Serial.printf( "\n" );
    }
    delay(600);
    ++loopCounter;
  }
  loopCounter = 0;

  // stopped flasher here

  Serial.printf("\nSmartConfig received.\n Waiting for WiFi\n\n");
  delay(2000 );

  while( WiFi.status() != WL_CONNECTED )
  { // check till connected
     delay(500);
  }
  IP_info();

  preferences.begin("wifi", false); // put it in storage
    preferences.putString( "ssid" ,    getSsid);
    preferences.putString( "password", getPass);
  preferences.end();

  delay(300);
} // END SmartConfig()

void IP_info()
{
  getSsid = WiFi.SSID();
  getPass = WiFi.psk();
  rssi = getRSSI( rssiSSID );
  WFstatus = getWifiStatus( WFstatus );
  MAC = getMacAddress();

  Serial.printf( "\n\n\tSSID\t%s, ", getSsid.c_str() );
  Serial.print( rssi);  Serial.printf(" dBm\n" );  // printf??
  Serial.printf( "\tPass:\t %s\n", getPass.c_str() ); 
  Serial.print( "\n\n\tIP address:\t" );  Serial.print(WiFi.localIP() );
  Serial.print( " / " );              Serial.println( WiFi.subnetMask() );
  Serial.print( "\tGateway IP:\t" );  Serial.println( WiFi.gatewayIP() );
  Serial.print( "\t1st DNS:\t" );     Serial.println( WiFi.dnsIP() );
  Serial.printf( "\tMAC:\t\t%s\n", MAC.c_str() );
}  // END IP_info()

int getWifiStatus( int WiFiStatus )
{
  WiFiStatus = WiFi.status();
  Serial.printf("\tStatus %d", WiFiStatus );
  switch( WiFiStatus )
  {
    case WL_IDLE_STATUS : // WL_IDLE_STATUS = 0,
        Serial.printf(", WiFi IDLE \n");
        break;
    case WL_NO_SSID_AVAIL: // WL_NO_SSID_AVAIL = 1,
        Serial.printf(", NO SSID AVAIL \n");
        break;
    case WL_SCAN_COMPLETED: // WL_SCAN_COMPLETED = 2,
        Serial.printf(", WiFi SCAN_COMPLETED \n");
        break;
    case WL_CONNECTED: // WL_CONNECTED = 3,
        Serial.printf(", WiFi CONNECTED \n");
        break;
    case WL_CONNECT_FAILED: // WL_CONNECT_FAILED = 4,
        Serial.printf(", WiFi WL_CONNECT FAILED\n");
        break;
    case WL_CONNECTION_LOST: // WL_CONNECTION_LOST = 5,
        Serial.printf(", WiFi CONNECTION LOST\n");
        WiFi.persistent(false); // don't write FLASH
        break;
    case WL_DISCONNECTED: // WL_DISCONNECTED = 6
        Serial.printf(", WiFi DISCONNECTED ==\n");
        WiFi.persistent(false); // don't write FLASH when reconnecting
        break;
  }
  return WiFiStatus;
}  // END getWifiStatus()

// Get the station interface MAC address.
// <strong i="14">@return</strong> String MAC
String getMacAddress(void)
{
  WiFi.mode(WIFI_AP_STA); // required to read NVR before WiFi.begin()
  uint8_t baseMac[6];
  esp_read_mac( baseMac, ESP_MAC_WIFI_STA ); // Get MAC address for WiFi station
  char macStr[18] = { 0 };
  sprintf(macStr, "%02X:%02X:%02X:%02X:%02X:%02X", baseMac[0], baseMac[1], baseMac[2], baseMac[3], baseMac[4], baseMac[5]);
  return String(macStr);
}  // END getMacAddress()

// Return RSSI or 0 if target SSID not found
// const char* SSID = "YOUR_SSID"; // declare in GLOBAL space
// call: int32_t rssi = getRSSI(SSID);
int32_t getRSSI( const char* target_ssid )
{
  byte available_networks = WiFi.scanNetworks();

  for (int network = 0; network < available_networks; network++)
  {
    if ( strcmp( WiFi.SSID( network).c_str(), target_ssid ) == 0)
    {
      return WiFi.RSSI( network );
    }
  }
  return 0;
} // END getRSSI()

// Requires; #include <esp_wifi.h>
// Returns String NONE, ssid or pass arcording to request
// ie String var = getSsidPass( "pass" );
String getSsidPass( String s )
{
  String val = "NONE"; // return "NONE" if wrong key sent
  s.toUpperCase();
  if( s.compareTo("SSID") == 0 )
  {
    wifi_config_t conf;
    esp_wifi_get_config( WIFI_IF_STA, &conf );
    val = String( reinterpret_cast<const char*>(conf.sta.ssid) );
  }
  if( s.compareTo("PASS") == 0 )
  {
    wifi_config_t conf;
    esp_wifi_get_config( WIFI_IF_STA, &conf );
    val = String( reinterpret_cast<const char*>(conf.sta.password) );
  }
  return val;
}  // END getSsidPass()

Ich habe das auch bemerkt, aber nie eingegrenzt, aber ich habe bemerkt, dass reconnect () und begin (ssid ..) nicht immer dhcp zurücksetzen, Randfall, denke ich

Beginnen Sie (Argumente)
wiederholt dhcp nur, wenn config nicht gleich ist oder noch nicht verbunden ist, andernfalls wird es zurückgegeben, was möglicherweise ein Problem darstellt.

    wifi_config_t current_conf;
    esp_wifi_get_config(WIFI_IF_STA, &current_conf);
    if(!sta_config_equal(current_conf, conf)) {
        if(esp_wifi_disconnect()){
            log_e("disconnect failed!");
            return WL_CONNECT_FAILED;
        }

        esp_wifi_set_config(WIFI_IF_STA, &conf);
    } else if(status() == WL_CONNECTED){
        return WL_CONNECTED;
    }
 // We do not always get here
    if(!_useStaticIp) {
        if(tcpip_adapter_dhcpc_start(TCPIP_ADAPTER_IF_STA) == ESP_ERR_TCPIP_ADAPTER_DHCPC_START_FAILED){
            log_e("dhcp client start failed!");
            return WL_CONNECT_FAILED;
        }
    } else {
        tcpip_adapter_dhcpc_stop(TCPIP_ADAPTER_IF_STA);
    }

@mickeypop danke für das Teilen von Code. Aber ich habe einen Zweifel.
Wie du gesagt hast:
I proved this once buy adding a UDP call in some test code. - I could talk to the AP by UDP but had no IP address. At the same time the MAC showed up on the AP connection list.

aber soweit ich weiß, können wir keine UDP-Verbindung herstellen, ohne eine IP zu haben. UDP basiert auf der IP-Schicht.

@jjassar

UDP benötigt überhaupt keine IP, nur einen eigenen MAC.

In UDP liegt die Magie in der SmartConfig. Die App in Ihrer Zelle sendet ein speziell formatiertes UDP-Paket nur für den ESP32 mit den AP-Anmeldeinformationen.

Da UDP verbindungslos ist, können alle WLAN-Geräte auf oder neben dem AP dies sehen.

Wenn der ESP32 dies sieht, sendet er ein anderes UDP an den AP, um eine Verbindung und die IP-Adresse vom AP zu erhalten. Denken Sie daran, dass vor dem Verbinden keine IP vorhanden ist.

UDP ist die Unterschicht, die in DHCP verwendet wird, um die IP zu erhalten, wird aber auch auf viele andere Arten verwendet.

@mickeypop ist es möglich, dass Sie TCP / UDP mit Broadcast / Multicast mischen?
TCP und UDP befinden sich beide auf der Transportschicht, die auf der Internetschicht aufbaut, auf der sich IP befindet.

@mickeypop @bedenko Sie beide haben vielleicht Recht, ich denke, es könnte eine UDP-Sendung unter der Adresse 255.255.255.255 sein.
Wie auch immer, ich habe eine neue Ausgabe mit dem neuesten Repo gefunden.
Ich hatte einen esp32, der mit dem AP verbunden war. Ich schaltete den AP aus und schaltete ihn nach einiger Zeit wieder ein.
Wenn beim Trennen der Ursachencode 201 (REASON_NO_AP_FOUND) lautet, wird die Verbindung automatisch hergestellt
Aber manchmal wird der Trennungsgrundcode 7 (REASON_NOT_ASSOCED) nie wieder hergestellt. Erst nach einem Neustart der Hardware wird die Verbindung wieder hergestellt.
Warum kommt der Ursachencode 7, wenn ich den AP ausgeschaltet habe?

Wahrscheinlich, weil Code 201 hier entfernt wird, Code 7 jedoch ignoriert wird.

@jjassar @bedenko

Denken Sie einen Moment darüber nach.
Es muss ein Protokoll vorhanden sein, um eine Verbindung herzustellen, BEVOR das Gerät eine IP hat, da DHCP sonst keine Möglichkeit hätte, den DHCP-Server zu kontaktieren, um eine IP abzurufen.

Ich war über 30 Jahre lang Netzwerkingenieur und wenn UDP kein integraler Bestandteil von TCP / IP wäre, müssten Sie IPs jedes Mal neu einrichten, wenn Sie in ein anderes Netzwerk wechseln.

Hier ist eine kleine Grundierung.

DHCP-PROTOKOLL

Das _DHCP-Protokoll ist ein verbindungsloses Protokoll, das die UDP- Ports 68 und 67 verwendet. Es arbeitet mit dem Client- und

DHCP arbeitet mit UDP, da der DHCP-Client mit Broadcasts arbeitet, die nur von UDP unterstützt werden können. Dies ist erforderlich, da der Clientcomputer noch keine IP-Adresse erhalten hat (dies ist der Zweck des DHCP-Verhandlungsprotokolls) und es ohne die IP-Adresse selbst keine Möglichkeit gibt, einen TCP-Stream einzurichten.

Der DHCP-Client sendet zunächst das DHCP DISCOVER-Paket. Die Sendung wird von den DHCP-Servern empfangen, die wiederum mit der DHCP-ANGEBOT-Nachricht antworten. Die DHCP-ANGEBOT-Nachricht enthält die vom Server angebotene IP-Adresse und den Zeitraum, für den die IP-Adresse zugewiesen wird (Die IP kann zufällig sein oder auf einer Administratorrichtlinie basieren).

Der DHCP-Client kann mehrere DHCP-ANGEBOT-Nachrichten empfangen, wählt jedoch nur eine DHCP-ANGEBOT-Nachricht basierend auf der im DHCP-Client konfigurierten Richtlinie aus. Normalerweise ist es auf der Basis "Wer zuerst kommt, mahlt zuerst". Wir können den DHCP-Client jedoch so konfigurieren, dass er das DHCP-ANGEBOT mit der längsten Lease-Zeit oder ein bevorzugtes Subnetz auswählt. Der DHCP-Client antwortet jetzt mit der Nachricht DHCP REQUEST.

Die DHCP REQUEST-Nachricht ist eine Broadcast-Nachricht. Wenn andere DHCP-Server diese Nachricht erhalten, ziehen sie alle Angebote zurück, die sie möglicherweise an den Client abgegeben haben, und geben die angebotene Adresse an den Pool verfügbarer Adressen zurück. Der beabsichtigte DHCP-Server sendet beim Empfang der Nachricht eine DHCP-ACK-Nachricht, wodurch die Transaktion bestätigt und die IP für die angegebene Zeit dem Host zugewiesen wird.

@mickeypop : Ich stimme Ihrer Erklärung zu, außer der Tatsache, dass UDP ohne IP-Adresse arbeiten kann. Alle DHCP-Verhandlungen werden auf Broadcast-IP 255.255.255.255 ( Info ) durchgeführt.

@bedenko
Sie müssen so ziemlich zustimmen. Ich habe es direkt aus den offiziellen Dokumenten ausgeschnitten und eingefügt.

Sie haben Recht und Unrecht und hier ist der Grund dafür.

Alle Netzwerkprotokolle verwenden dieselbe Paketstruktur. AppleTalk, TCP / IP, Arpnet, AIX usw. Dadurch konnten sie konfliktfrei auf demselben Ethernet koexistieren.

Die Struktur enthält Bits für Protokoll, Typ, Prüfsumme, Ziel usw. Alle suchen nach den 24 (255.255.255.255) Bits in der Zielkennung als spezielle Kennung.

das gesagt;

Der IP-Verkehr wird über eine Netzwerkmaske verarbeitet, sodass alle Geräte feststellen können, ob ein Paket für sie bestimmt ist oder nicht, sowie das Routing.

UDP hat keine Netzwerkmaske. Der 255.255.255.255 ist nicht für den UDP-Absender gedacht oder wird sogar von ihm verwendet. Daher sehen alle anderen Geräte die spezielle Kennung. Es wird in diesem Fall überhaupt nicht wie eine IP behandelt.

HINWEIS: UDP sendet per MAC, nicht per IP.

Nehmen wir zum Beispiel DHCP, Sie haben noch keine IP- oder Netzmaske, sodass das Gerät in den Promiscuous-Modus wechselt und nach Paketen mit einer eigenen MAC-Adresse sucht.

Ein DHCP DISCOVER-Paket wird von UDP mit der MAC-Adresse des Absenders gesendet, da der DHCP-Server wissen muss, wer eine IP anfordert.

Der Absender kann es eindeutig noch nicht als IP-Verkehr verarbeiten, und zu diesem Zweck kann der DHCP-Server IP nicht zum Senden einer Antwort verwenden. Daher UDP.

Die von UDP zurückgegebene DHCP-ANGEBOT-Nachricht muss den MAC enthalten, damit der Client weiß, dass er für ihn bestimmt ist. Wohlgemerkt, der gesamte Datenverkehr ist gleich aufgebaut, aber noch nicht IP.

Erst wenn alle Verhandlungen abgeschlossen sind, ist IP-Verkehr überhaupt möglich.

=====
Separat sollte ich beachten;
Ich war 1968 - 70 im Team und entwickelte das UNIX-Betriebssystem. Dort ist TCP / IP entstanden.
Wir haben einen frühen Entwurf von UDP verwendet, bevor es überhaupt TCP / IP gab.

@mickeypop Danke für deine Arbeit! Wir können alle den Himmel berühren, weil wir auf den Schultern der Riesen stehen!

Futter.

Hallo.
Ich benutze diesen Code dafür

  if (WiFi.status() != WL_CONNECTED)
{
  digitalWrite(26,0);
  WIFI_Connect();
} else {
  digitalWrite(26,1);
}

und dies ist die Funktion "WIFI_Connect"

void WIFI_Connect ()
{
digitalWrite (26, HIGH);
WiFi.disconnect ();
Serial.println ("Reconectando WiFi ...");
WiFi.mode (WIFI_AP_STA);
WiFi.begin (ssid, Passwort);
// Warte auf Verbindung
für (int i = 0; i <50; i ++)
{
if (WiFi.status ()! = WL_CONNECTED) {
Verzögerung (500);
digitalWrite (26,0);
Serial.print (".");
Verzögerung (500);
digitalWrite (26,1);
}}
}}
digitalWrite (26,0);
}}

Für mich funktioniert dieser Code.
Obs: Die Version 2.3

einschließen

einschließen

definiere WIFI_SSID "===="

definiere WIFI_PASSWORD "==="

// Dieses Firebase-Projekt wurde gelöscht
// Sie müssen Ihre eigenen Firebase-Informationen eingeben

definiere FIREBASE_HOST "home-automation-1122.firebaseio.com"

definiere FIREBASE_AUTH "============"

LED1 definieren 5

LED2 definieren 4

LED3 0 definieren

LED4 definieren 2

LED5 definieren 14

LED6 definieren 12

LED7 definieren 13

LED8 definieren 15

void setup () {

PinMode (LED1, OUTPUT);

digitalWrite (LED1,0);

PinMode (LED2, OUTPUT);

digitalWrite (LED2,0);

PinMode (LED3, OUTPUT);

digitalWrite (LED3,0);

PinMode (LED4, OUTPUT);

digitalWrite (LED4,0);

PinMode (LED5, OUTPUT);

digitalWrite (LED5,0);

PinMode (LED6, OUTPUT);

digitalWrite (LED6,0);

PinMode (LED7, OUTPUT);

digitalWrite (LED7,0);

PinMode (LED8, OUTPUT);

digitalWrite (LED8,0);

Serial.begin (9600);

WiFi.begin (WIFI_SSID, WIFI_PASSWORD);

Serial.print ("Verbinden");

while (WiFi.status ()! = WL_CONNECTED) {

Serial.print (".");

Verzögerung (500);

}}

Serial.println ();

Serial.print ("verbunden:");

Serial.println (WiFi.localIP ());

Firebase.begin (FIREBASE_HOST, FIREBASE_AUTH);

Firebase.setInt ("LEDStatus", 0);

}}

void loop () {

if (Firebase.getInt ("field1"))

{

digitalWrite (LED1, LOW);

}}

sonst

{
digitalWrite (LED1, HIGH);

}}
if (Firebase.getInt ("field2"))

{

digitalWrite (LED2, LOW);

}}

sonst

{

digitalWrite (LED2, HIGH);

}}

if (Firebase.getInt ("field3"))

{

digitalWrite (LED3, LOW);

}}

sonst

{
digitalWrite (LED3, HIGH);

}}

if (Firebase.getInt ("field4"))

{

digitalWrite (LED4, LOW);

}}

sonst

{

digitalWrite (LED4, HIGH);

}}
if (Firebase.getInt ("field5"))

{

digitalWrite (LED5, LOW);

}}

sonst

{

digitalWrite (LED5, HIGH);

}}
if (Firebase.getInt ("field6"))

{

digitalWrite (LED6, LOW);

}}

sonst

{

digitalWrite (LED6, HIGH);

}}
if (Firebase.getInt ("field7"))

{

digitalWrite (LED7, LOW);

}}

sonst

{

digitalWrite (LED7, HIGH);

}}
if (Firebase.getInt ("field8"))

{

digitalWrite (LED8, LOW);

}}

sonst

{

digitalWrite (LED8, HIGH);

}}

//Serial.println(Firebase.getInt("led1 "));
//Serial.println(Firebase.getInt("led2 "));
//Serial.println(Firebase.getInt("led3 "));
//Serial.println(Firebase.getInt("led4 "));
//Serial.println(Firebase.getInt("led5 "));
//Serial.println(Firebase.getInt("led6 "));
//Serial.println(Firebase.getInt("led7 "));
//Serial.println(Firebase.getInt("led8 "));

Serial.println ("...............");
if (Firebase.failed ()) // Auf Fehler prüfen {

Serial.print ("Einstellung / Nummer fehlgeschlagen:");

Serial.println (Firebase.error ());

Rückkehr;

}}

Mein nodemcu esp8226 stellt die Verbindung nach einem Verbindungsverlust nicht wieder her, bis ich ihn wieder einschalte

Dieser Thread ist für esp32. Verwenden Sie esp8266 oder war es ein Tippfehler?

esp82255 nodemcu

Am Dienstag, den 11. September 2018 um 13:45 Uhr schrieb Bedenko, [email protected] :

Dieser Thread ist für esp32. Verwenden Sie esp8266 oder war es ein Tippfehler?

- -
Sie erhalten dies, weil Sie kommentiert haben.
Antworte direkt auf diese E-Mail und sieh sie dir auf GitHub an
https://github.com/espressif/arduino-esp32/issues/653#issuecomment-420196435 ,
oder schalten Sie den Thread stumm
https://github.com/notifications/unsubscribe-auth/ApKpJ7SS4fk4KrHA1sVKmwV7brGVeh93ks5uZ3gxgaJpZM4PfOia
.

Entschuldigung, das ist esp8266

Am Dienstag, 11. September 2018, 13:48 Uhr schrieb Ijaz Ahmad, konzeptioneller [email protected]:

esp82255 nodemcu

Am Dienstag, den 11. September 2018 um 13:45 Uhr schrieb Bedenko, [email protected] :

Dieser Thread ist für esp32. Verwenden Sie esp8266 oder war es ein Tippfehler?

- -
Sie erhalten dies, weil Sie kommentiert haben.
Antworte direkt auf diese E-Mail und sieh sie dir auf GitHub an
https://github.com/espressif/arduino-esp32/issues/653#issuecomment-420196435 ,
oder schalten Sie den Thread stumm
https://github.com/notifications/unsubscribe-auth/ApKpJ7SS4fk4KrHA1sVKmwV7brGVeh93ks5uZ3gxgaJpZM4PfOia
.

hilft mir hier jemand?

Dieser Thread ist für einen ESP32, nicht für einen 8266. Versuchen Sie es mit einem anderen Repo.

Kannst du mir bitte mit 8226 helfen?

@vseven Wie kann ich dieses Problem lösen?

@ ijaz1122 Schauen Sie hier, wenn es ein Problem gibt, das zu Ihrem Problem passt. Andernfalls öffnen Sie dort eine neue.
Sie fragen derzeit nach einer Lösung auf einem anderen Gerät. Dies ist das falsche Repo für Ihr Problem.

Hallo zusammen, endlich funktioniert dieser Code, um meinen WLAN- / tragbaren Hotspot mehrmals zu verbinden und wieder zu verbinden

Vielen Dank an @ThiagoCas für seine Codes

`/ * * * * * * * * * * * * *
Bibliotheken einschließen
* * * * * * * * * * * * * /

einschließen

/ * * * * * * * * * * * * *
Konstanten definieren
* * * * * * * * * * * * * /

definiere WIFISSID "== Deine Wifi SSID ==" // Gib deine WifiSSID hier ein

PASSWORT definieren "== Ihr Passwort ==" // Geben Sie hier Ihr WLAN-Passwort ein

// Konstanten ändern sich nicht. Wird hier verwendet, um eine PIN-Nummer festzulegen:
const int ledPin = 2; // die Nummer des LED-Pins

/ * * * * * * * * * * * * *
Variablen definieren
* * * * * * * * * * * * * /
// Variablen ändern sich:
int ledState = LOW; // ledState zum Setzen der LED

int Intervall = 100; // Intervall zum Blinken (Millisekunden)

// Im Allgemeinen sollten Sie "unsigned long" für Variablen verwenden, die die Zeit halten
// Der Wert wird schnell zu groß, als dass ein Int ihn speichern könnte
unsigned long previousMillis = 0; // speichert die letzte Aktualisierung der LED

/ * * * * * * * * * * * * *
Hilfsfunktionen
* * * * * * * * * * * * * /
void WIFI_Connect ()
{
WiFi.disconnect ();
Serial.println ("Verbindung zu WiFi herstellen ...");
WiFi.mode (WIFI_AP_STA);
WiFi.begin (WIFISSID, PASSWORD);

für (int i = 0; i <60; i ++)
{
if (WiFi.status ()! = WL_CONNECTED)
{
Verzögerung (250);
digitalWrite (ledPin, LOW);
Serial.print (".");
Verzögerung (250);
digitalWrite (ledPin, HIGH);
}}
}}
if (WiFi.status () == WL_CONNECTED)
{
Serial.println ("");
Serial.println ("WiFi Connected");
Serial.println ("IP-Adresse:");
Serial.println (WiFi.localIP ());
}}
digitalWrite (ledPin, 0);
}}

/ * * * * * * * * * * * * *
Hauptfunktionen
* * * * * * * * * * * * * /

void setup ()
{
Serial.begin (115200);

// setze den digitalen Pin als Ausgang:
pinMode (ledPin, OUTPUT);
WIFI_Connect ();
}}

void loop ()
{
unsigned long currentMillis = millis ();

if (currentMillis - previousMillis> = Intervall)
{
if (WiFi.status ()! = WL_CONNECTED)
{
Serial.println ("WLAN getrennt");
WIFI_Connect ();
}}
// Speichern Sie das letzte Mal, wenn Sie die LED blinken
previousMillis = currentMillis;
// Wenn die LED aus ist, schalten Sie sie ein und umgekehrt:
if (ledState == LOW)
{
ledState = HIGH;
Intervall = 100;
}}
sonst
{
ledState = LOW;
Intervall = 2500;
}}
// setze die LED mit dem ledState der Variablen:
digitalWrite (ledPin, ledState);
}}
} `

Neuere Firmware scheint zu helfen, dies zu schließen.

@vseven von neuerer Firmware ... meinst du die neueste Version vom Master dieser Bibliothek? Ich sehe seit dem 26. September keine neuen Commits mehr, also frage mich, ob du dich auf etwas anderes beziehst.

Vielen Dank für Ihre Klarstellung
Gaston

Ich habe das jetzt vor über einem Jahr eröffnet, also ja, neuer als in den letzten paar Monaten.

Großartig. Danke für die Klarstellung. Ich bin mir nicht sicher, wann ich das letzte Update durchgeführt habe (vor 2 Monaten?), Aber ich habe diesen Fehler nach dem letzten Update nie gesehen (und er ist alle paar Monate einmal aufgetreten). Ich dachte, ich hätte Glück gehabt, aber jetzt sehe ich, dass es mehr als Glück war. ;)

Gut gemacht.
Gaston

Auch das scheint zu helfen:

    esp_wifi_set_ps(WIFI_PS_NONE);

@vseven

Neuere Firmware scheint zu helfen, dies zu schließen.

Hallo,
Ich habe immer gedacht, dass platformio durch das Aktualisieren der arduino-esp32-Bibliothek auch die so genannte Firmware aktualisieren kann. Liege ich falsch? Ich leide immer noch unter diesem Problem!

@vseven
Neuere Firmware scheint zu helfen, dies zu schließen.

Hallo,
Ich habe immer gedacht, dass platformio durch das Aktualisieren der arduino-esp32-Bibliothek auch die so genannte Firmware aktualisieren kann. Liege ich falsch? Ich leide immer noch unter diesem Problem!

Hier gilt das gleiche. Möchten Sie einen Hinweis darauf haben, wie Sie die Firmware von platformio aktualisieren, um das Problem der Trennung selbst zu umgehen ...

@vseven
Anweisungen zur Einrichtung und Aktualisierung der Plattform-E / A werden hier behandelt
https://github.com/espressif/arduino-esp32/blob/master/docs/platformio.md

Ein kleines bisschen jedoch: Sowohl auf Arduino als auch auf Platform IO, wenn ich Git verwende, um das SDK zu aktualisieren, habe ich gelegentlich festgestellt, dass das Update nicht vollständig war und Probleme hatte.

Benennen Sie den esp32-Ordner um und installieren Sie ihn von einem neuen Git neu. Ich habe immer ein sauberes Update erhalten.
Folgen Sie einfach ihren Anweisungen.

@mickeypop :

@ Miq1 Gibt es dieses Problem, wenn nur das IDF-Beispiel verwendet wird?

Ich muss gestehen, dass ich das Arduino nur in der Platformio-Umgebung verwende - ich habe mich nie mit der IDF befasst. Ich werde heute prüfen, ob ich dort eine Basisversion meiner Anwendung einrichten kann.

Nur für die Datensätze: Ich habe festgestellt, dass die Problemumgehung mit Disconnect () und anschließendem begin () für mich funktioniert, wenn ich einen Modus (WIFI_OFF) und einen Modus (WIFI_STA) dazwischen mache. Ich versuche derzeit 5 Mal hintereinander, die Verbindung wiederherzustellen, und würde einen esp.restart () ausführen, wenn alle Versuche fehlschlagen, aber bisher war kein Neustart erforderlich.

Ich habe in der Zwischenzeit einige Neustarts beobachtet, daher scheint die Problemumgehung nicht so effektiv zu sein.

Gibt es ein Update zu diesem Fehler?

FWIW Ich sehe dies oft auch bei ESP8266-Geräten - genau die gleichen Symptome. Ich habe festgestellt, dass ich die Verbindung ganz drastisch ändern kann, indem ich das Gerät anders ausrichte. Es scheint also damit zu tun zu haben, wie die Geräte (sowohl ESP8266 als auch ESP32) auf ein schlechtes Signal reagieren.

Da ich NonOS und einen ESP8266 verwende, scheint der gemeinsame Nenner das Low-Level-Netzwerk unter lwIP zu sein

(Verwenden der Version 1.0.4 von Arduino-esp32)

Ich hatte hier das gleiche Problem (mit ESP32). Es wurde festgestellt, dass ein Neustart des Routers das Problem löst ... einmal . Das heißt, nach dem Neustart ist das ESP32 kann in der AP verbinden, eine IP - Adresse erhalten und bleibt verbunden, aber wenn etwas die Verbindung fehlschlägt (wie die ESP32 Neustart), die ESP32 dann _is nie in der Lage das verbinden AP wieder_.

Der Router ist ein TP-Link TL-MR2030, den ich für kabelgebundene Ethernet-Tests aufbewahre. Er verfügt über eine Firmware, die um Jahre hoffnungslos veraltet ist, und es gibt keine neuere offizielle Firmware.

Wenn ich jedoch versuche, andere APs zu verwenden, wie z. B. einige ganz neue Ubiquiti-Einheiten im Büro, tritt das Problem einfach überhaupt nicht auf. Ich habe sogar bei den IT-Mitarbeitern Verdacht erregt, indem ich das Board gezwungen habe, absichtlich neu zu starten und stundenlang so schnell wie möglich wiederholt eine Verbindung herzustellen ... und das ohne Probleme.

_So, während es möglich ist, dass etwas in den Bibliotheken des ESP32 nicht stimmt oder unvollständig ist, bin ich bereit, die Firmware des alten Routers zu beschuldigen._ Zeit, einen neuen Router für Tests zu bekommen, nicht von TP-LINK , jedoch.

Ich vermute normalerweise DNS für solche Dinge. Oder manchmal denkt der Router immer noch, dass Sie verbunden sind, und lässt Sie nie wieder eine Verbindung herstellen

Nein, der Router ist nicht schuld. Zumindest in meinem Fall. Sicher, es ist nicht das neueste (wnr2200), aber mit einem aktuellen DD-WRT und mehreren Android-, Linux- und Windows-Geräten, die ohne Probleme funktionieren.

Um dieses Problem endlich für mich selbst zu lösen, habe ich mit einer völlig neuen Implementierung begonnen, die auf WiFiClientEvents.ino basiert - also ereignisbasiert. Ich habe auch die neuesten Commit-Nachrichten von arduino-esp32 gelesen, die sehr aktuelle, aber relevante Commits enthüllten. Ich musste in WiFiGeneric.cpp debuggen und stellte fest, dass der Modus nicht immer das tut, was erwartet wird (https://github.com/espressif/arduino-esp32/issues/1306).

Endergebnis: Mit einem kleinen Patch auf WiFiGeneric.cpp (siehe Dateiende) konnte ich mehrmals eine Verbindung zu meinem AP herstellen und trennen - Hurra :)

Lassen Sie mich wissen, wenn Sie etwas zu verbessern sehen.

/*
 * This is a very stable example of repeated connecting and disconnecting to/from a wifi access point on STA32
 * Unfortunately, it needs patching of the WiFiGeneric.cpp library file
 * Author: Daniel Alder, based on the example WiFiClientEvents.ino
 * Tested with Arduino 1.8.5 and 1.8.10 with ESP library from Nov 11 2019 (cec3fca4) + patch
*/

#include <WiFi.h>   

#include "HomeWifiConfig.h" // use an extra include or uncomment the following 2 lines
//const char* ssid     = "myssid"; // your network SSID (name of wifi network)
//const char* password = "****";   // your network password

typedef enum {
  MYSTATE_OFFLINE = 0,
  MYSTATE_CONNECTING,
  MYSTATE_ONLINE,
  MYSTATE_DISCONNECTING
} mystate_t;
mystate_t mystate = MYSTATE_OFFLINE;
long state_since = 0;

#define TIMEOUT_ONLINE     20  // reconnect after this [s] offline time
#define TIMEOUT_OFFLINE    20  // disconnect after this [s] online time
#define TIMEOUT_CONNECTING 20  // cancel connecting after this [s] without success

////////////////////////////////////////////////////////////////////////////////

long getUptime() {
  return esp_timer_get_time() / 1000000L;
}

void changeState(mystate_t state) {
  mystate = state;
  state_since = getUptime();
}

void WiFiEvent(WiFiEvent_t event, WiFiEventInfo_t info)
{
    Serial.printf("[WiFi-event] event: %d\n", event);

    switch (event) {
        case SYSTEM_EVENT_WIFI_READY: 
            Serial.println("WiFi interface ready");
            break;
        case SYSTEM_EVENT_SCAN_DONE:
            Serial.println("Completed scan for access points");
            break;
        case SYSTEM_EVENT_STA_START:
            Serial.println("WiFi client started");
            break;
        case SYSTEM_EVENT_STA_STOP:
            Serial.println("WiFi client stopped");
            changeState(MYSTATE_OFFLINE);
            break;
        case SYSTEM_EVENT_STA_CONNECTED:
            Serial.println("Connected to access point");
            break;
        case SYSTEM_EVENT_STA_DISCONNECTED:
            Serial.println("Disconnected from WiFi access point");
            break;
        case SYSTEM_EVENT_STA_AUTHMODE_CHANGE:
            Serial.println("Authentication mode of access point has changed");
            break;
        case SYSTEM_EVENT_STA_GOT_IP:
            Serial.print("Obtained IP address: ");
            //Serial.println(WiFi.localIP());
            //Serial.println("WiFi connected");
            //Serial.print("IP address: ");
            Serial.println(IPAddress(info.got_ip.ip_info.ip.addr));

            changeState(MYSTATE_ONLINE);

            break;
        case SYSTEM_EVENT_STA_LOST_IP:
            Serial.println("Lost IP address and IP address is reset to 0");
            //changeState(MYSTATE_OFFLINE);
            break;
        case SYSTEM_EVENT_STA_WPS_ER_SUCCESS:
            Serial.println("WiFi Protected Setup (WPS): succeeded in enrollee mode");
            break;
        case SYSTEM_EVENT_STA_WPS_ER_FAILED:
            Serial.println("WiFi Protected Setup (WPS): failed in enrollee mode");
            break;
        case SYSTEM_EVENT_STA_WPS_ER_TIMEOUT:
            Serial.println("WiFi Protected Setup (WPS): timeout in enrollee mode");
            break;
        case SYSTEM_EVENT_STA_WPS_ER_PIN:
            Serial.println("WiFi Protected Setup (WPS): pin code in enrollee mode");
            break;
        case SYSTEM_EVENT_AP_START:
            Serial.println("WiFi access point started");
            break;
        case SYSTEM_EVENT_AP_STOP:
            Serial.println("WiFi access point  stopped");
            break;
        case SYSTEM_EVENT_AP_STACONNECTED:
            Serial.println("Client connected");
            break;
        case SYSTEM_EVENT_AP_STADISCONNECTED:
            Serial.println("Client disconnected");
            break;
        case SYSTEM_EVENT_AP_STAIPASSIGNED:
            Serial.println("Assigned IP address to client");
            break;
        case SYSTEM_EVENT_AP_PROBEREQRECVED:
            Serial.println("Received probe request");
            break;
        case SYSTEM_EVENT_GOT_IP6:
            Serial.println("IPv6 is preferred");
            break;
        case SYSTEM_EVENT_ETH_START:
            Serial.println("Ethernet started");
            break;
        case SYSTEM_EVENT_ETH_STOP:
            Serial.println("Ethernet stopped");
            break;
        case SYSTEM_EVENT_ETH_CONNECTED:
            Serial.println("Ethernet connected");
            break;
        case SYSTEM_EVENT_ETH_DISCONNECTED:
            Serial.println("Ethernet disconnected");
            break;
        case SYSTEM_EVENT_ETH_GOT_IP:
            Serial.println("Obtained IP address");
            break;
        default: break;
    }
}

#include "esp_wifi.h" // only for fixWifiPersistencyFlag()
/**
 * Disable persistent mode, see https://github.com/espressif/arduino-esp32/issues/1393
 */
void fixWifiPersistencyFlag() {
  wifi_init_config_t cfg = WIFI_INIT_CONFIG_DEFAULT();
  Serial.printf("cfg.nvs_enable before: %d\n", cfg.nvs_enable);
  cfg.nvs_enable = 0;
}

////////////////////////////////////////////////////////////////////////////////

void setup()
{
  Serial.begin(115200);
  Serial.println("-----------------------------------------");
  Serial.println("THIS IS: newWifiImplementationUsingEvents");
  Serial.println("-----------------------------------------");

  WiFi.persistent(false);
  fixWifiPersistencyFlag();

  //Serial.setDebugOutput(true); 
  //WiFi.printDiag(Serial); 

  // delete old config
  WiFi.disconnect(true);

  state_since = getUptime();

  delay(1000);

  // warning: only the last defined event handler gets events!
  WiFi.onEvent(WiFiEvent);

  Serial.println("End of setup");
}

bool firstTime = true;

void loop()
{
  long uptime = getUptime();
  if (mystate == MYSTATE_ONLINE && state_since + TIMEOUT_ONLINE < uptime) {
    Serial.println("Disconnecting NOW");
    changeState(MYSTATE_DISCONNECTING);
    WiFi.disconnect(true);
    WiFi.mode(WIFI_OFF);
  } else if (mystate == MYSTATE_OFFLINE && state_since+TIMEOUT_OFFLINE < uptime) {
    Serial.println("Connecting NOW");
    changeState(MYSTATE_CONNECTING);
    if (firstTime) {
      Serial.println("(firstTime)");
      WiFi.begin(ssid, password);
      firstTime = false;
    } else {
      // doesn't work without WiFiGeneric.cpp patch below
      WiFi.mode(WIFI_STA);
      WiFi.reconnect();
    }
  } else if (mystate == MYSTATE_CONNECTING && state_since+TIMEOUT_CONNECTING < uptime) {
    Serial.println("Cancelling NOW after no connect success");
    changeState(MYSTATE_DISCONNECTING);
    WiFi.disconnect(true);
    WiFi.mode(WIFI_OFF);
  }

  delay(1000);
  if (uptime % 10 == 0) {
    Serial.printf("uptime %d\n", uptime);
  }
}

/* PATH FOR LIBRARY
diff --git a/libraries/WiFi/src/WiFiGeneric.cpp b/libraries/WiFi/src/WiFiGeneric.cpp
index e562921..aab5805 100644
--- a/libraries/WiFi/src/WiFiGeneric.cpp
+++ b/libraries/WiFi/src/WiFiGeneric.cpp
@@ -483,8 +483,10 @@ void WiFiGenericClass::enableLongRange(bool enable)
 bool WiFiGenericClass::mode(wifi_mode_t m)
 {
     wifi_mode_t cm = getMode();
+    log_d("mode() cm=%d, m=%d", cm, m);
     if(cm == m) {
-        return true;
+        log_d("HACK: skip return true");
+        //return true;
     }
     if(!cm && m){
         if(!wifiLowLevelInit(_persistent)){
*/


/* ISSUES:
 *  
 * 1) The example WiFiClientEvents.ino says:
 * 
 *   WiFi.onEvent(WiFiEvent);
 *   WiFi.onEvent(WiFiGotIP, WiFiEvent_t::SYSTEM_EVENT_STA_GOT_IP);
 *   
 *   but the WiFiEvent function never receives a SYSTEM_EVENT_STA_GOT_IP!
 *   
 * 2) I used code from https://github.com/espressif/arduino-esp32/issues/1393 to fix the persistent config issue
 * 
 * 3) The list of events in WiFiClientEvents.ino (comment block) is missing an event. Same bug as fixed in 188560e7f33
 * 
 * 4) Without pathing of WiFiGeneric.cpp, the mode() function doesn't do anything anymore once WiFi it was initialized (not even connected)
 * 
 *   see also: https://github.com/espressif/arduino-esp32/issues/1306 (but the this patch is not yet mentioned there)
 * 
 * 5) just a note: there is a STA_LOST_IP event, 2 minutes after disconnecting. 
 *   So if you want to make your code stable, you should also test with TIMEOUT_OFFLINE > 130
 */

Hat jemand dies verdrahtet?

Hatte ein ähnliches Problem mit einem Arduino Wifi Rev. 2 (andere Hardware, aber die Probleme bei der Aushandlung zwischen APs und dem Gerät waren unheimlich ähnlich.)

https://github.com/arduino/nina-fw/issues/14

@mrarmyant Was erwarten Sie von Wireshark? Ich denke, wir sprechen über Probleme auf den OSI-Schichten 1 und 2. Anders gesagt: keine SSID, keine Frequenz, keine Pakete

Mein Code (über Ihrem Beitrag) läuft stabil, seit ich ihn gepostet habe. Ich glaube jedoch nicht, dass das Problem auf etwas anderes als ESP * -Chips portierbar ist, da es Probleme des ESP-SDK und nicht von Arduino behebt

Ich beschuldige solche Probleme mit der Stromversorgung

Ich würde die PS nicht beschuldigen, es ist sehr unwahrscheinlich, wenn Sie nicht ein wirklich schwaches Angebot haben, wird dies nicht passieren.

Wireshark ist hier wirklich nutzlos.

Um zu verstehen, müssen Sie tief in die RTOS-Bibliotheken eintauchen, in denen die eigentliche Arbeit erledigt wird, nicht in die Arduino-Bibliotheken, da sie ein Wrapper sind.

Wenn Sie WiFi.reconnect () anstelle von WiFi.begin () verwenden, müssen Sie einige Dinge wissen.

WiFi.begin () setzt zunächst alle erforderlichen Register auf dem WLAN-Chip und die RTOS-Zustände vor dem Verbinden, reconnect () jedoch nicht.
Dies wurde vor über 2 Jahren gemeldet.

WiFi.reconnect () stellt häufig nur die Hälfte der Verbindung her und stellt eine MAC-Verbindung auf Chipebene mit UDP her, stellt jedoch niemals die TCP / IP-Verbindung her, da dies separate Protokolle sind. Dies liegt daran, dass benötigte Zustände nicht durch reconnect () voreingestellt werden. Es wird lediglich davon ausgegangen, dass sie vorhanden sind.
Aus diesem Grund erhalten einige von Ihnen SYSTEM_EVENT_STA_GOT_IP beim erneuten Verbinden nicht.

Merken; Eine erneute Verbindung ist erforderlich, da sich die Status bereits geändert haben.

Ich verbinde mich IMMER wieder mit WiFi.begin () und bin nie gescheitert.

======
Wenn ein Reset keine Verbindung herstellt und angibt, dass bereits eine Verbindung besteht, müssen Sie DHCP kennen.
Die DHCP-IP-Adresse wird normalerweise alle 15 Sekunden wiederhergestellt.
Nehmen wir nun an, Sie drücken 2 Sekunden nach dem Wiederherstellen den Reset.
Der DHCP-Server gibt die IP-Adresse für weitere 13 Sekunden nicht frei. Wenn Sie versuchen, eine Verbindung herzustellen, wird sie als verwendet gemeldet.

Eine einfache Verzögerung beim Booten vor dem Verbinden hat dies jedes Mal für mich behoben.
Wenn Sie mehrere andere Bibliotheken einrichten, legen Sie alle zuerst vor WiFi.begin () fest.

Ein guter Start-Timer hilft hier.
nimm eine lange var = millis (); in der ersten Zeile von setup () und Serial.print (millis () - var); kurz vor WiFi.begin () und finden Sie heraus, wie schnell Sie tatsächlich booten. Dann entsprechend einstellen.

Ich benutze das ESP32 seit über 6 Jahren und das hat immer funktioniert.

AKTUALISIEREN; Ich sehe eine Menge WiFiEvent verwendet und zum Debuggen ist es gut, aber einfach WLAN zu erkennen und die IF / ELSE unten wieder anzuschließen, funktioniert jedes Mal zuverlässig.

Dies funktioniert, da es ungefähr 18 Sekunden dauert, bis die Änderung von WL_CONNECTED gemeldet wird. Dadurch hat der DHCP-Server Zeit, die IP für eine zuverlässige spätere erneute Verbindung freizugeben.

Es arbeitet seit über 6 Jahren und zählt.

loop()
{
  if ( WiFi.status() ==  WL_CONNECTED ) 
  {
    // WiFi is UP,  do what ever
  } else
  {
    // wifi down, reconnect here
   WiFi.begin(  );
    int WLcount = 0;
    while (WiFi.status() != WL_CONNECTED && WLcount < 200 ) 
    {
      delay( 100 );
         Serial.printf(".");
         if (UpCount >= 60)  // just keep terminal from scrolling sideways
         {
            UpCount = 0;
               Serial.printf("\n");
         }
         ++UpCount;
      ++WLcount;
    }
  }
} // END loop()

Schauen Sie sich den Skelett-Code an, den ich auf https://github.com/espressif/arduino-esp32/issues/1100 veröffentlicht habe

Obwohl es für die Einrichtung mit SmartConfig vorgesehen war, funktioniert es einfach.

@mrarmyant Was erwarten Sie von Wireshark? Ich denke, wir sprechen über Probleme auf den OSI-Schichten 1 und 2. Anders gesagt: keine SSID, keine Frequenz, keine Pakete

Mein Code (über Ihrem Beitrag) läuft stabil, seit ich ihn gepostet habe. Ich glaube jedoch nicht, dass das Problem auf etwas anderes als ESP * -Chips portierbar ist, da es Probleme des ESP-SDK und nicht von Arduino behebt

Ich bezog mich nicht wirklich auf Arduino, sondern auf das WLAN, das sich an Bord dieser bestimmten Einheit befindet. Es gab Probleme mit der erneuten Verbindung, weil ich mit DHCP nicht zufrieden war. Jemand berichtete, dass ein Neustart des Routers das Problem behoben hat. Dies ist das Problem, das wir hatten (also ein Neustart eines Windows-DHCP-Servers). Es gab ein Problem mit der Art und Weise, wie bestätigt wurde, ob die Verbindung getrennt wurde oder nicht. Ich dachte nur, es könnte bei diesen Problemen dort oben helfen, da keine Einheit jemals als verbunden bei den Wiederverbindungen angezeigt werden würde, und wireshark zeigte uns warum. Statische IPs hatten kein Problem. Es war schließlich die WLAN-Firmware, die repariert werden musste, um die für DHCP-Probleme erwähnte Verzögerung zu bewältigen. All dies wurde über Wireshark entdeckt.