ESP RGBWW Controller - Firmware v5

[weini]

Das mit dem WLAN Roaming wäre IMHO ein Thema mit den ESP Bibliotheken. Hast du da ggf. eine im aktuellen Build, die da ein Problem hat.

Heute morgen wieder das gleiche Bild: Ein deutlicher sichtbarer Abfall im Free Heap um kurz nach 6:00. Da schalten wir nach dem Aufstehen unsere Handys ein und blättern die Nachrichten durch, aber niemand macht etwas mit dem Controller. Ist schon spannend...

[pjakobs]

Hier noch ein Nachtrag, am Nachmittag hat es ihn wieder erwischt.
Auch zu diesem Zeitpunkt erfolgte kein Schaltvorgang.

allerdings ist hier auch noch genug RAM vorhanden. Ich glaube nicht, dass an der Stelle - jedenfalls nicht mit der Auflösung von einer Minute - RAM exhaustion das Problem war

Kann das evtl. am WLAN Roaming liegen? Ich habe mehrere Access Points als Mesh am laufen (aktuelles OpenWrt) und habe heute zu ungefähr dieser Zeit meine Access Points upgegraded, so dass die Geräte roamen mussten.

Interesante Frage. Aus Sicht der Firmware verbindet der Controller sich mit einem Wlan - dahinter steht natürlich ein spezifischer Access Point, aber davon weiß die Firmware nicht. Was passiert, wenn der ausfällt, weiß ich im Moment ehrlich gesagt nicht.
Ich hab neulich mal festgestellt, dass, nach einem längeren Ausfall des Netzes, die Controller alle ihren access point aufgemacht haben und es relativ lange gedauert hat, bis sie wieder im "normalen" Netz waren. Ich glaube aber, das ist ein anderes Ding.
Ich hab hier mehrere Controller, die über 100 Stunden durch gelaufen sind, aber auch andere, deren uptime unter 24h ist, obwohl die alle etwa zur gleichen Zeit neu gestartet wurden (ich mache immer ein Update auf alle) - ich vermute also, dass ich das gleiche Problem sehe wie Du - es nur noch nie bemerkt habe.

[pjakobs]

Ich hab mir jetzt mal ein Grafana/Prometheus Dashboard gebaut, das uptime und free_heap für alle Controller einsammelt - mal sehen, was ich herausfinden kann.

Ich überlege gerade, ob es wohl okay wäre, wenn ich, zumindest für die debug Versionen, ein paar Daten "nach Hause" senden lasse? Ich könnte z.B. über einen mqtt Server host_id, heap_free und uptime einsammeln und bekäme eine Übersicht über die Controller.

[weini]

Ich überlege gerade, ob es wohl okay wäre, wenn ich, zumindest für die debug Versionen, ein paar Daten "nach Hause" senden lasse? Ich könnte z.B. über einen mqtt Server host_id, heap_free und uptime einsammeln und bekäme eine Übersicht über die Controller.

Für eine reguläre Version (Release) wäre das für mich ein no-go. Für einen Debug Build finde ich es in Ordnung.

[pjakobs]

Ich überlege gerade, ob es wohl okay wäre, wenn ich, zumindest für die debug Versionen, ein paar Daten "nach Hause" senden lasse? Ich könnte z.B. über einen mqtt Server host_id, heap_free und uptime einsammeln und bekäme eine Übersicht über die Controller.

Für eine reguläre Version (Release) wäre das für mich ein no-go. Für einen Debug Build finde ich es in Ordnung.

ich würde es vielleicht so anlegen:
Die Funktion ist immer da und kann an- und abgeschaltet werden, im debug build ist sie default an und im release build default off.
Als Daten denke ich host_id (das ist die hardware ID des Chips), soc (das ist aktuell bei allen außer mir wohl der esp8266), uptime, heap_free und, wenn ich da ran komme, last reboot message. Ich weiß, dass es ein paar Nutzer gibt, die die Controller über Schalter an und aus schalten, wenn ich das ausfiltern kann, wird das Bild einfacher zu lesen

edit: die Software Version müsste natürlich auch rein.

[weini]

Habe ich eigentlich irgendeine Chance, nochmal auf die 424 zurückzugehen? Mit der Version hatte ich deutlich längere Uptimes.
Mein curl Aufruf (wie weiter oben beschrieben) hat ja nicht funktioniert. Sollte das gehen?

[pjakobs]

@weini was mir gerade einfällt: hast Du möglicherweise viele mDNS Geräte im Netz? Gerade IoT Geräte nutzen oft mDNS ums ihre Services anzubieten (so wie auch die controller) - wenn Du wirklich viele hast (und ich meine *wirklich* viele) dann könnte ich mir vorstellen, dass der Controller manchmal einfach von vielen Announcements überfahren wird - mDNS ist Multicast und es werden erstmal alle Pakete angenommen, bis sie dann von der Firmware als "nah, nicht für mich" verworfen werden.

[weini]

Ich glaube eher nicht, aber ich bin da etwas unsicher.

Vielleicht ein dutzend ESPs, dazu ein ca. 5 Raspis (teils als Musikspieler, die machen mDNS). Aber unter "wirklich viele" würde ich was anderes verstehen.

[Mafi]

Hallo ihr!

Ich erinnere mal an meinen Post vom 1.06.25. Vermutlich sehen weini und ich dasselbe Problem. Bei mir ist ebenfalls ein Mesh vorhanden, in dem die Fritzbox hin und wieder entscheidet, ein Gerät umzubuchen. Zum freien RAM im Fehlerfall kann ich allerdings nichts sagen. "Wirklich viele" mDNS Geräte gibt es hier ebenfalls nicht.

Hallo zusammen,

ich habe mal wieder eine neue Beobachtung zu vermelden. Aktuell habe ich die Software V5.0-374-develop auf meinen Controllern laufen. Aufgefallen ist mir folgendes:
Immer wenn die WLAN Verbindung aus irgend einem Grund mal kurz ausfällt rebooten die Controller. Dabei wird natürlich jegliche laufende Animation abgebrochen. Beim Reboot kommt dann ein zweiter Fehler zum Tragen.
"Ab Werk" steht der Parameter config-color-startup_color auf last. Das funktioniert aber nicht. Es wird nach dem Reboot nicht der zuletzt eingestellte Wert wiederhergestellt, sondern die Controller gehen auf 10% Helligkeit in weiß. Das habe ich inzwischen bei drei verschiedenen Controllern beobachtet. Die haben inzwischen allerdings einen festen Wert vorgegeben bekommen, sodass ich nicht sagen kann, ob die Einstellung last generell nicht geht oder nur einmal von Hand neu gesetzt werden muss.
Wünschen würde ich mir, dass die Lightinators einen kurzen Ausfall des WLAN ignorieren, das heißt die laufende Animation nicht abgebrochen wird und es auf gar keinen Fall einen Reboot gibt. Dass sie dann während dieser Zeit nicht erreichbar sind ist natürlich klar. Sollte das WLAN länger ausfallen dürfen und sollen sie natürlich ihr eigenes WLAN wieder aufspannen, idealerweise auch das ohne Reboot. Notfalls wäre das nach einer angemessenen Wartezeit (z.B. 60s) aber OK.

Warum die WLAN Verbindung hin und wieder kurz abbricht weiß ich nicht. Denkbar wäre, dass meine Fritzbox versucht, einen Controller im Mesh umzubuchen von Repeater zur Box oder umgekehrt. Danach sieht es aber im Log der Box eigentlich nicht aus. Aber bei allen Funkverbindungen muss man ja ohnehin immer mit Störungen rechnen.

Markus

[pjakobs]

Ich habe tatsächlich schon einen ersten Neustart hier gesehen - danke @weini für den bug report.

Jetzt muss ich mal sehen, ob ich herausfinden kann, was da passiert, denn dieser Controller hat auch kein logging, das ich ansehen könnte...

Interessanterweise hat aber der Neustart hier, zumindest scheinbar, nichts mit RAM zu tun - alle Controller sind bei um die 25 bis 27kB free heap.

Du darfst diesen Dateianhang nicht ansehen.

(nb: ich baue gerade einen Container, der Prometheus und Graphana beinhaltet sowie ein paar Scripten, die, ausgehend von einem ersten Controller, versuchen alle Controller im Netzwerk zu finden - wenn ihr das testen wollt sagt bescheid)

[pjakobs]

Ich hab dann mal komplettes Monitoring für alle gebaut(okay, bauen lassen, das hat Copilot zusammengesteckt)
Das Bild ist aber ganz interessant:
- zwei Controller (Ku und Facelight) haben Reboots hingelegt. Facelight würde ich außenvor lassen, weil der nur ein esp8266 in einer anderen Schaltung ist und immer wieder Probleme mit der Stromversorgung hat.
Ku ist die Küche, das ist noch einer der alten (schwarze Platine, stehende MOSFETs), und der scheint die größten Probleme zu haben.
RAM Exhaustion scheint mit den Reboots bei mir keinen Zusammenhang zu haben.
Ich behalte das mal im Auge.

Du darfst diesen Dateianhang nicht ansehen.

ps: wer mehrere Controller hat, und das selbst mal testen will: hier ist das Repo, die Containerisierte Vesion sollte sich leicht mit docker compose up / podman compose up starten lassen und ist dann auf port 3000 erreichbar. Username Admin Password rgbww123

[pjakobs]

Aalso, ich kann bestätigen, dass die Teile unvorhergesehen neu starten, aber bisher habe ich noch kein log davon mitbekommen.
Ich bleib da mal dran.