AP Mode verliert Verbindung nach einigen Minuten FastLED Effekten

[nflug]

Hallo zusammen,

ich hab ein NodeMCU V3.2 Arduino ESP8266 ESP-12E Board.
Folgendes Problem: Ich steuer LED's mit dem FastLED Library an über eine Webpage die über einen AP läuft.
Website, Effekte sowie der AP laden alle super und funktionieren. Problem ist nun das wenn ich einen Effekt aktiviere und dieser nun einige Minuten läuft der AP sich automatisch disconnected. Die Effekte laufen weiter und das Board crasht auch nicht, sondern nur der AP. Ich benutze bei meinen Effekten kein delay bis auf das "FastLED.delay()". Wenn man abfragt wie viel Clients beim AP connected sind wird angezeigt das ich noch verbunden bin, der AP wird mir aber trotzdem nirgendsangezeigt und ich bin auch nicht mehr verbunden.

Vielleicht könnt ihr mir weiterhelfen.

MFG
PD

- - - Aktualisiert - - -

Ok Problem hat sich gerade erledigt. Es lag tatsächlich am "FastLED.delay()" habe ersetzt durch ein millis() delay und jetzt geht es!

[Rabenauge]

Gibst du denn den Controller auch Zeit, sich hin und wieder um den Wifi-Kram zu kümmern?
Sonst schmiert die Wifi-Geschichte recht zuverlässig regelmässig ab....

[Ceos]

Dazu gibt es im Github ein Issue, leider kann ich es nicht finden (Github Suche nutzt Elastic Search und das ist richtig kacke)

Ich habe aber ein verwandtes Issue gefunden das vermutlich das gleiche Problem hat
https://github.com/marvinroger/async...ent/issues/124

Kern des anderen Issue welches ich meinte war, dass der ESP wohl Probleme mit dem Thread handling hat (@HaWe hatte auch bei ESP mit Thread Priority einen Trick gefunden, der wohl auch in dem Issue als Workaround angeführt worden ist) und der Main Thread mit irgend einem Makro oder einem Befehl eine bestimmte Prio zugewiesen bekommen muss.

[HaWe]

(@HaWe hatte auch bei ESP mit Thread Priority einen Trick gefunden, der wohl auch in dem Issue als Workaround angeführt worden ist) und der Main Thread mit irgend einem Makro oder einem Befehl eine bestimmte Prio zugewiesen bekommen muss.

jein - mein Prob war bei einem ESP32 mit std::thread multithreading, hier aber geht es wohl um einen esp8266, der kein std::thread unterstützt.
Dennoch hat auch der ESP8266 ein freeRTOS eingebaut, das allerdings selbstständig, automatisch den (single core) Prozessor mit Rechenzeit für WiFi versorgt, daher darf eine loop aber auch nicht sehr viel länger als etwa 2 sec dauern (wegen Watchdog).

[Ceos]

Ja genau das meinte ich, aber ich meine mich zu erinnern, dass es da parallelen zwischen deinem und dem Github Issue gab, du aber mit ESP32 und dort mit ESP8266 gearbeitet worden ist, das workaround aber das gleiche war. Dabei ging es ebenfalls um FastLED (vielleicht war das issue auch im Github Projekt zu FastLED selbst, wo ich gerade nochmal darüber nachdenke) welches bei zu häufiger Aktualisierung den AP dropt.

EDITH:

https://github.com/bruhautomation/ES...LEDs/issues/60

das scheint ganz gut in deine Richtung zu zielen