NodeMCU V3 als Server stürzt nach ein paar Minuten ab.

[HaWe]

hallo,
deine Abfrage in der loop() ist etwas anders gestrickt als wie ich es kenne:

  WiFiClient client = wifiserver.available();

  while ( client.connected() ) {
     if ( client.available() )   {
         char c = client.read();
         //...
         //... z.B. switch-Abfrage
         //...
         client.stop();
     }
     //...
     delay(1);
  }

Bin aber auch kein Fachmann, vlt hilft es aber trotzdem

- - - Aktualisiert - - -

PS,
ich mache aber nur die Koomunikation mit websites über die wifiserver/client libs,
die Kommunikation mit mehreren ESP-Clients mache ich über die webserver lib.

[Philippp]

Danke,
werde ich mal ausprobieren. Wofür ist das delay von einer ms am Ende?
LG,
Philippp

[HaWe]

Wofür ist das delay von einer ms am Ende?

kA, ob das nötig ist, stand bei mir so im example-Code.

[Philippp]

Also ich habe ein delay(10) an das Ende des Programmes gesetzt. Seit dem hatte ich nur noch einen Absturz, und das nachdem das Programm schon lange lief. Das ist zwar noch immer einer zuviel, aber um Welten besser als das was ich vorher hatte. Ein ehemaliger Kollege von mir meinte das er in so ziemlich jede Schleife ein kleines delay() reinschreibt, weil sich die Chips sonst "tot rechnen". Werde ich mir wohl auch angewöhnen.
Als nächstes werde ich mir mal die Stromversorgung anschauen. Ich wollte die ganze Geschichte eigentlich mit USB 3.0 versorgen. Das müsste locker ausreichen. Frage ist nur wie sauber die Spannung ist. Ich habe mal gelesen das ESP8266 Chips da sehr empfindlich sind...
LG,

Philippp

[Klebwax]

Ein ehemaliger Kollege von mir meinte das er in so ziemlich jede Schleife ein kleines delay() reinschreibt, weil sich die Chips sonst "tot rechnen".

Selten einen größeren Blödsinn gelesen.

Ich habe mal gelesen das ESP8266 Chips da sehr empfindlich sind...

Was man im Internet so alles lesen kann. Der Chip braucht bis zu 380mA, das liefert jeder USB Anschluß selbst mit einem Linearregler für die 3,3V. Praktische Erfahrungen zeigen, daß der Chip auch noch mit rund 2,5V arbeitet. Das führt dann leicht zu der Annahme, daß die Versorgung ok ist, obwohl sie in Wirklichkeit zu schwach ist.

Übliche Probleme sind, daß der ESP an den internen 3,3V Regler eines USB-Chips angeschlossen wird. Die können typisch weniger als 100mA (Data Sheet not read Error). Bei einem großen Stützkondensator reichts dann manchmal gerade so, da die knapp 400mA nur kurz beim Senden gebraucht werde. Dafür verlangsamt dieser Kondensator die Anschaltflanke so stark, daß der ESP keinen sauberen Power-On Reset mehr bekommt und damit ab und an mal nicht anläuft. Sporadische Abstürze sind da aber nicht zu erwarten. Ich verwende 3-Bein Schaltregler von z.B. Recom. Mit der 500mA Variante laufen bei mit alle ESP zuverlässig.

Abstürze nach einigen Minuten Laufzeit haben typisch 2 Gründe: Temperatur oder Speicherüberlauf. Wäre es Temperatur, würde die Zeit bei schnell aufeinanderfolgenden Tests immer kürzer werden.

Für mich klingt das Problem nach einem Speicherüberlauf. Bei TCP Verbindungen ist es ein häufig auftretendes Problem, daß Verbindungen nicht sauber geschlossen werden und offen bleiben, obwohl die Übertragung eigentlich beendet ist. Die Verbindung belegt dabei Buffer und Kontrollstrukturen. Am Ende beendet dann eine Timer im TCP-Stack die ganze Sache und gibt den Speicher wieder frei. Da auf einem PC Gigabytes Speicher zur Verfügung stehen, fällt das selten auf und solche fehlerhaften Programme haben ein langes Leben. Auf einem System mit wenig Speicher wird das dann ein Problem. IMHO kann der TCP-Stack des ESP maximal 4 Verbindungen gleichzeitig, mehr Speicher steht nicht zur Verfügung.

Also ich habe ein delay(10)...

Ich werte das als Bestätigung für meine Vermutung. Das delay() ermöglicht (meistens) dem Timer im TCP-Stack die Verbindung zu schließen. Das ist natürlich keine Lösung des wirklichen Problems.

MfG Klebwax

[HaWe]

hmmh, ich habe 5 ESP8266 clients am ESP8266 Server verbunden, und auf dem Server wird auch noch eine website aufgebaut, neben anderen services, und da hängt nichts.
Man muss aber aufpassen, dass while Schleifen nicht länger als ca. 5 sec ohne Unterbrechung laufen, sonst wird das interne RTOS Multithreading blockiert und dann führt der ESP RTOS Scheduler einen Reboot aus. Ein delay(1) in der Schleife kann das verhindern. Evt ist das der Grund, warum es auch im obigen example code verwendet wird.

[Klebwax]

hmmh, ich habe 5 ESP8266 clients am ESP8266 Server verbunden, und auf dem Server wird auch noch eine website aufgebaut, neben anderen services, und da hängt nichts.

Das sind keine stehenden TCP Connections. Ein WEB-Server ist ein Socket im Zustand Listen. Wenn sich ein Client (Browser) verbindet, wird eine Verbindung aufgebaut, die Seite geliefert und die Verbindung sofort wieder geschlossen. Das dauert auf einem ESP einige hundert Millisekunden, manchmal auch weniger. Der Timeout beim Verbindungsaufbau ist im Bereich Sekunden. Selbst wenn deine 5 Clients gleichzeitig versuchen, eine Verbindung aufzubauen, können sie ohne Probleme nacheinander abgewickelt werden, ohne daß ein Timeout im Client ausgelöst und damit auffällig wird. Mit allen anderen Services ist es ähnlich. Voraussetzung ist aber, daß die Verbindung am Ende der Übertragung zügig beendet wird. Deine Konfiguration kann also mit einem Socket und daher einer TCP-Verbindung gleichzeit realisiert werden.

Man muss aber aufpassen, dass while Schleifen nicht länger als ca. 5 sec ohne Unterbrechung laufen, sonst wird das interne RTOS Multipthreading blockiert und dann führt der ESP RTOS Scheduler einen Reboot aus.

Ich hab da eher 50ms in Erinnerung. Das Verhalten ist schon richtig beschrieben, aber eine lange Schleife blockiert einfach das RTOS (es ist ein kooperatives Tasking System) und der HW-Watchdog löst den Reboot aus.

MfG Klebwax