ESP32 WROOM mit Async Webserver WDT Reset nach dem Verbinden von 2. Client

[Luca S. (chababo)]

Hallo zusammen,

Ich betreibe einen ESP32 WROOM als Async Webserver mit der Library 
"ESPAsyncWebServer".
Das Problem ist, wenn ich einen 2. Client verbinde, während bereits ein 
Client verbunden ist und damit das Webinterface aufrufe, wird der WDT 
getriggert und der ESP startet neu.

Habe den Debug Output im Anhang.

Hat jemand eine Idee, wie man das Problem löst?

Das Wifi-Netzwerk wird hier erstellt:

void createWifiNetwork(const char* ssid, const char* password) {
  Serial.print("Setting soft-AP configuration ... ");
  Serial.println(WiFi.softAPConfig(local_IP, gateway, subnet) ? "Ready" : "Failed!");

  Serial.print("Setting soft-AP ... ");
  Serial.println(WiFi.softAP(ssid, password) ? "Ready" : "Failed!");

  Serial.print("Soft-AP IP address = ");
  Serial.println(WiFi.softAPIP());
}

Ansonsten werden im setup() einfach die routes gesetzt a la:

server.on("/", HTTP_GET, [](AsyncWebServerRequest * request)
  {
    request->send(LittleFS, "/index_user.html", "text/html");
  });

Die loop() Methode ist leer.

[MaWin O. (mawin_original)]

Deine Library ist kaputt. Wende dich an den Hersteller.

[Lothar M. (Firma: Titel) (lkmiller) (Moderator)]

Luca S. schrieb:
> Hat jemand eine Idee, wie man das Problem löst?
Grundsätzlich: man sorgt dafür, dass der Watchdog rechtzeitig vor Ablauf 
des Timeouts wieder zurückgesetzt wird.

Der wird nämlich nur deshalb "ausgelöst", weil irgendwer auf irgendwas 
wartet, was nicht (schnell genug) passiert.

[Εrnst B. (ernst)]

Luca S. schrieb:
> Ansonsten werden im setup() einfach die routes gesetzt a la

Sind alle Routes solche statischen LittleFS-Dateien? Oder hast du auch 
Routen in denen du dynamisch Content erstellst und dabei länger wartest? 
Das geht nämlich nicht.

[Luca S. (chababo)]

Εrnst B. schrieb:
> Luca S. schrieb:
>> Ansonsten werden im setup() einfach die routes gesetzt a la
>
> Sind alle Routes solche statischen LittleFS-Dateien? Oder hast du auch
> Routen in denen du dynamisch Content erstellst und dabei länger wartest?
> Das geht nämlich nicht.

Ja, ist alles statischer Content.

[Εrnst B. (ernst)]

Hmmm... Hab mit der ESP-Async-Webserver schon deutlich mehr Verbindungen 
gleichzeitig offen gehabt, das ist eigentlich kein Problem. Nichtmal auf 
dem kleineren ESP8266. Auch nicht wenn Daten für einen Request dynamisch 
über viele tausende Callbacks zusammengesammelt und Bröckchenweise 
rausgesendet werden.

Aber: Hab das noch nie im Soft-AP-Modus getestet. Kann das einen 
Unterschied machen?

Schlägt der Watchdog schon zu wenn mehrere Clients nur verbunden sind, 
aber keine HTTP-Verbindung offen haben?

[Monk (roehrmond)]

Εrnst B. schrieb:
> Schlägt der Watchdog schon zu wenn mehrere Clients nur verbunden sind,
> aber keine HTTP-Verbindung offen haben?

Nein

[Luca S. (chababo)]

Εrnst B. schrieb:
> Aber: Hab das noch nie im Soft-AP-Modus getestet. Kann das einen
> Unterschied machen?

Also heißt, immer über einen Router?


Ich aktualisiere einige Daten dynamisch per XML:

index.js

function triggerESP32Xml() {
  var readyState = "ReadyState: " + xmlHttpSensors.readyState;
  xmlHttpSensors = createXmlHttpRequestObject();
  xmlHttpSensors.open("PUT", "xml", true);
  xmlHttpSensors.onreadystatechange = processXmlResponse;
  xmlHttpSensors.send(null);

  setTimeout("triggerESP32Xml()", 100);
}

function processXmlResponse() {
  if (xmlHttpSensors.readyState == 4) {
    var xmlResponse;
    var xmlElements;

    // Get the XML stream
    xmlResponse = xmlHttpSensors.responseXML;
    //************************************ */
    // Update System Info section
    // Bat. Percentage / Voltage
    xmlElements = xmlResponse.getElementsByTagName("Vb");
    batteryVoltage = xmlElements[0].firstChild.nodeValue;
...
}
}

Ob es damit zusammenhängen kann?

Aber sollte ja trotzdem jeder Client seine eigenen Requests haben.

Εrnst B. schrieb:
> Schlägt der Watchdog schon zu wenn mehrere Clients nur verbunden sind,
> aber keine HTTP-Verbindung offen haben?

Nein.

[Εrnst B. (ernst)]

Ohje, 1990er-Style-Javascript.

Starte den nächsten "setTimeout" erst, nachdem der vorherige Request 
komplett abgearbeitet wurde.


Und überleg dir, das auf aktuelles JS und Json umzustellen. Da wird der 
ganze Code-Block oben zu

const status = await (await fetch("/status")).json();
batteryVoltage = status.Vb;

o.Ä.

[Luca S. (chababo)]

Εrnst B. schrieb:
> Ohje, 1990er-Style-Javascript.

Ja, bin kein JS Pro.

Εrnst B. schrieb:
> Und überleg dir, das auf aktuelles JS und Json umzustellen. Da wird der
> ganze Code-Block oben zu
> const status = await (await fetch("/status")).json();
> batteryVoltage = status.Vb;

Danke für den Tipp. Ja, JS Kenntnisse zu verbessern steht auch noch auf 
meiner Liste.