ESP8266 WIFI Verbindung wird nicht aufgebaut

Hallo,
ich hab da immer wieder mal Probleme mit einem erneuten Aufbau der WIfi Verbindung. Eigentlich kommt es recht selten vor, ist aber recht doof da man in dem Fall den ESP neu starten muss.
Es passiert dann wenn die Fritzbox den Kanal gewechselt hat, dabei werden alle WIFI Verbindungen von der Frizbox abgemeldet und anschließend verbinden sich die alle neu. Meistens klappt das auch, aber halt nicht immer.

Der Loop und die Funktion sieht so aus.

void loop() {
  // put your main code here, to run repeatedly:

  if (WiFi.status() != WL_CONNECTED) { // neu verbinden
    conectWIFI();
    delay(5000); // ist zum testen drin
  }
  else {
    // Ist verbunden
    ArduinoOTA.handle();
    server.handleClient();// hier passiert sonst nichts
    MDNS.update();
  }

void conectWIFI() {
  byte maxzeit = 0;
  WiFi.disconnect();
  WiFi.persistent(false);   // daten nicht in EEprom
  WiFi.mode(WIFI_STA);
  Serial.printf("Connecting to %s ", ssid);

  WiFi.config(staticIP, gateway, subnet);
  WiFi.begin(ssid, password);
  while (WiFi.status() != WL_CONNECTED) {
    delay(500);
    Serial.print(".");
    maxzeit++;
    if (maxzeit > 60)return;
  }
  Serial.print(F(" connected...locale IP:"));
  Serial.println(WiFi.localIP());
  if (MDNS.begin("Stromzähler")) {
    Serial.println("MDNS responder started");
  }

}

Nun hab ich eine LED mit angebaut die ständig blinkt, allerdings sollte sie ja 5s nicht mehr blinken wenn die Verbindung weg ist.delay(5000) Daraus schließe ich das

if (WiFi.status() != WL_CONNECTED) { // neu verbinden

nicht immer wie gewünscht funktioniert.

hat da jemand eine bessere Idee,
Laut Core Doku würde ich jetzt mal umbauen auf

WiFiEventHandler disconnectedEventHandler;

WiFiEventhandler
wenn das letztlich aber am selben Ereignis hängt bringts ja nix :frowning:

Heinz

Ich würde gerne einen ESP32 als Dauerläufer verwenden, weshalb ich da auch was zur Wiederverbindung reingebastelt habe, Sieht auf den ersten Blick aus, wie bei Dir. Kannst Du den Fehler bei einem ESP32 reproduzieren? Wenn nicht, könntest Du eine Umstieg erwägen, so es keine anderen Lösungen gibt.

Hallo
Ich habe das bei einem ESP32 auch schon sowas komisches beobachtet. Der ist im Netz aber der Webserver reagiert nicht mehr.

Es gibt ja auch noch andere Möglichkeiten
WiFi.reconnect oder wifi.auto ich muss da noch mal in die Doku einsteigen wenn hier keiner eine spontane Idee hat.

Normal ist ja schnell Mal der Stecker raus und wieder rein, allerdings ist der Kandidat im Keller und das schöne Chart ist in dem Fall auch futsch. :sob:

Heinz

Ich denke, dies ist ein allgemeines Problem bei einigen ESP32 die eine Wiederverbindung manchmal einfach nicht schaffen ohne reboot.
Ich habe bereits ein paar ESP32 NODEMCU beim selben Handler gekauft und manchmal gibt es immer einen, der immer wieder Probleme bei der Wiederverbindung hat.
Und diese verbindet sich nur nach Neustart.

Fuer solche ESP mit diesen problem benutze ich ESP.restart();. Ist zwar keine Losung fur das Problem, haber ich brauche selber den Stecker nicht selber raus nehmen.

#include <WiFi.h>


const char* ssid = "--------------";
const char* password = "--------------";

unsigned long previousMillis = 0;
unsigned long interval = 30000;

void initWiFi() {
  WiFi.mode(WIFI_STA);
  WiFi.begin(ssid, password);
  Serial.print("Connecting to WiFi ..");
  uint32_t notConnectedCounter = 0;
  while (WiFi.status() != WL_CONNECTED) {
    delay(100);
    Serial.println("Wifi connecting...");
    notConnectedCounter++;
    if (notConnectedCounter > 150) {  // Reset board if not connected after 15s
      Serial.println("Resetting due to Wifi not connecting...");
      ESP.restart();
    }
  }
  Serial.println(WiFi.localIP());
}

void setup() {
  Serial.begin(115200);
  initWiFi();
  Serial.print("RSSI: ");
  Serial.println(WiFi.RSSI());
}

void loop() {
  unsigned long currentMillis = millis();
  // if WiFi is down, try reconnecting every CHECK_WIFI_TIME seconds
  if ((WiFi.status() != WL_CONNECTED) && (currentMillis - previousMillis >= interval)) {
    Serial.print(millis());
    Serial.println("Reconnecting to WiFi...");
    WiFi.disconnect();
    initWiFi();
    previousMillis = currentMillis;
  }
}

Hallo,
@solrac3f danke für deinen Hinweis, aber es scheint ja so zu sein das die Abfrage im Loop

if (WiFi.status() != WL_CONNECTED) 

nicht zum tragen kommt, ansonsten würde ja mein Blinker für 5s aussetzten, tut er aber nicht. Ich vermute jetzt mal das WiFi.status() den erfolgreichen Verbindungsaufbau mit dem Wert 3 = WL_CONNECTD zurück liefert, allerdings bei einem Verlust der Verbindung den Wert nicht immer richtig aktualisiert. Ist eventuell etwas weit her geholt

Aus der Doku Link
------------- schnip--------------
This function returns following codes to describe what is going on with Wi-Fi connection:

0 : WL_IDLE_STATUS when Wi-Fi is in process of changing between statuses
1 : WL_NO_SSID_AVAILin case configured SSID cannot be reached
3 : WL_CONNECTED after successful connection is established
4 : WL_CONNECT_FAILED if connection failed
6 : WL_CONNECT_WRONG_PASSWORD if password is incorrect
7 : WL_DISCONNECTED if module is not configured in station mode

It is a good practice to display and check information returned by functions. Application development and troubleshooting will be easier with that.
--------------- schnap----------------
Heinz

Ich bin gerade über Reconnect ESP32 to Wi-Fi Network After Lost Connection einschließlich Link zum ESP8266 gestolpert. Da könntest Du, wenn es keine Alternative gibt, erst Daten über Preferences oder Dateisystem sichern und dann entspannt in den Reset wechseln.

Die Wi-Fi Events finde ich ganz spannend, die werde ich mal testen :slightly_smiling_face:

Moin @Rentner,

ist vielleicht ein wenig "durch die Brust ins Auge", aber als Notlösung bzw. zumindest in einer Testphase könnte man regelmäßig per Ping auf eine zuverlässige Gegenstelle prüfen, ob die Verbindung steht. Das ist jedenfalls einfach umzusetzen ...

Hier gibt es dazu eine Grundlage:

https://techtutorialsx.com/2019/10/05/esp32-arduino-pinging-a-remote-host/

Gruß
ec2021

P.S.: Ich hatte mir mal einen "Telefonwächter" mit ESP32 gebaut, um der Ausfallursache der Telefonie meines DSL-Modems auf den Grund zu gehen und belastbares "Futter" für eine Reklamation beim Provider zu schaffen. Der Wächter lief glücklicherweise über 9 Monate ohne Probleme am WLAN. Ja und ich habe nach einigem hin- und her ein anderes Modem erhalten, das seitdem problemlos läuft ... :wink:

Da würde ich lieber einen HTTP(S)-Request auf einen Webserver absetzen, der mit einem festen plain Text als Payload antwortet (z.B "OK");
Es gab ja schon Fälle, dass Ping noch funktionierte, höhere Schichten aber nicht mehr.

Gruß Tommy

Das ist natürlich ein umfassenderer Test.

Wenn es aber nur darum geht zu prüfen, ob man überhaupt am Netz ist, sollte auch ein Ping genügen ...

Gruß
ec2021

Das muss jeder selbst entscheiden, was ihm die Aussage kräftigeren Erkenntnisse bringt. Wir haben hier ja schon oft gelesen, dass der ESP zwar noch per Ping erreichbar war, aber nicht mehr abgefragt werden konnte.

An der Stelle wäre es interessant zu erfahren, ob dieser dann noch einen Request an einen anderen Webserver absetzen und die Antwort empfangen könnte.
Wenn nicht, hätte der ESP selbst ein Kriterium, dass er keine Verbindung mehr hat und könnte darauf reagieren. Im Extremfall mit einem Restart.

Gruß Tommy

Hallo,
danke für Eure Antworten. Hier mal ein Zwischenstand.
Ich habe die Abfrage im loop ganz rausgenommen und die beim Setup geändert. Nach dem Verbindungsaufbau
WiFi.setAutoReconnect(true);

eingefügt.
zum testen hab ich jetzt mehrfach den ESP mit eine Blechdose abgedeckt damit die Verbindung verloren geht. Nach dem ich die Blechdose weggenommen habe wurde die Verbindung immer wieder aufgebaut. Ich werde das jetzt noch mal länger beobachten.

Letztlich ist das eine der im Link von @agmue in #6 vorgeschlagenen Möglichkeiten.

PS: so hatte die Blechdose der Plätzchen doch einen richtigen Sinn :joy:

Der Abschnitt sieht jetzt so aus.

while (WiFi.status() != WL_CONNECTED) {
    delay(500);
    Serial.print(".");
    maxzeit++;
    if (maxzeit > 60)return;
  }


  WiFi.setAutoReconnect(true);  // neu eingefügt 

Heinz

Da Ping ein anderes Protokoll ( ICMP) verwendet, kann es durchaus sein das TCP/UDP trotz erfolgreichen Ping nicht mehr funktionieren.

Dass ein Ping nicht die Erreichbarkeit höherer Schichten prüft, ist mir schon klar; hier geht es ja nicht darum festzustellen, ob der ESP von außen erreichbar ist (dann ist ein Ping von außerhalb nur teilweise aussagekräftig), sondern vom ESP aus zu prüfen, ob überhaupt eine Wifi-Verbindung besteht. Dazu sollte ein Ping vom ESP aus sicherlich genügen.

Dass das eigene Wifi-Equipment einen Ping eines externen Gerätes vortäuscht, halte ich für ziemlich unwahrscheinlich...

Dein Vorschlag ist natürlich umfassender, für diesen Zweck hier sollte Ping m.E. jedoch ausreichend sein.

Gruß
ec2021

Jo, das stimmt auf jeden Fall.

Nach den Posts von @Rentner geht es darum, dass die WiFi- Verbindung nicht wieder hergestellt wird, nachdem der Router die Teilnehmer abgeworfen hat.

Wenn man vom ESP die IP des DHCP Servers anpingt, und nix zurückkommt, wäre das ein Nachweis. Kommt der Ping und es gibt trotzdem keinen Datentransfer, so liegt das Problem auf einer höheren Schicht ..

So lässt sich die Ursache genauer eingrenzen.

Einverstanden?

Gruß
ec2021

einen Ping würde ich nicht nehmen, weil wie schon gesagt - nicht aussagekräftig genug und außerdem braucht es zusätzlichen Code/Libraries dafür (vermutlich).

Wenn der Fehler bei einem HTTP Verbindungsaufbau kommt (habs nicht gesehen, weil nur halbe Sketche gepostet wurden) könnte man auf den HTTP Response Code reagieren.

Im Fehlerfall könnte man noch einen google.de request machen oder eine andere Resource im www oder sogar lokal machen (die Fritze hat doch sicher auch eine Weboberfläche).
Wenn die lokale Resource auch nicht geht dann hats wohl was mit der Anbindung. Dann könnte man ja wirklich versuchen wifi neu zu verbinden.

Aber grundsätzlich sollte es doch erurierbar sein ob:

  • die eigentliche Resource weg ist
  • das Internet nicht erreichbar ist
  • das lokale WLAN schon nicht erreichbar ist -> neuen Wifi Verbindungsaufbau probieren

Dann war die Blechbüchsenarmee (Augsburger Puppenkiste) zu was nütze :joy:

Ich werde

WiFi.setAutoReconnect(true);
WiFi.persistent(true);

auch mal probieren.

Da ich nur volle Blechbüchsen habe, spiele ich mal Krümelmonster :rofl:

Ja, die Anmeldeseite, die über "http://fritz.box" (oder die 192.168.178.1) erreichbar ist. Man muss ja nicht mal den Inhalt auswerten, der Fehlercode genügt ja.
Für eigene Inhalte muss man das System neu kompilieren.

Gruß Tommy

Da in diesem Thread beide Esp-User (Rentner - Esp8266, agmue - Esp32) vorkommen möchte ich mal auf den Unterschied hinweisen.

Esp32 default persistent = true
Esp8266 ab CoreVersion 3.0.0. default persistent = false

Hallo,
ich glaube ich muss das noch mal klarstellen.In dem von mir beschrieben Fall im Eingangspost ist es so das der ESP auch in der Fritzbox nicht mehr sichtbar ist. laut Protokoll der Fritzbox wurden abgemeldet, wie alle anderen auch, der betreffende Kandidat meldet sich aber nicht mehr an. Da der Blinker normal weiter läuft , kann ich daraus nur schließen das der ESP mit WIFI.Status () zwar bei der Anmeldung ein WL_CONNECTED bekommt allerdings das nicht immer weggeht wen er abgemeldet wird.

WiFi.persistent(true);

habe ich nicht benutzt , im Gegenteil ich setze es sogar auf false, was aber in der aktuellen Core eigentlich default ist.

Es kann natürlich sein das ich vorher irgendwann mal die Anmeldedaten fest hinterlegt habe, da bin ich mir nicht mehr sicher. Es handelt sich um die "Testhardware" mit der ich schon viel probiert habe. Auf der anderen Seite wird ja kein Neustart gemacht, warum sollten die Daten dann aus dem Speicher weg sein. Man müsste mal testen ob in dem Fall tatsächlich die Daten aus dem Nullspannungssicheren Speicher genutzt werden.

Heinz

Heinz, du kannst doch in der IDE einstellen was alles im Flash überschrieben/ gelöscht werden soll.