ESP RGBWW Controller - Firmware v5

Begonnen von pjakobs, 01 Januar 2025, 21:14:31

Vorheriges Thema - Nächstes Thema

Mafi

Guten Morgen!

Tests haben ergeben, dass du richtig liegst mit deinen Vermutungen.
Beide Probleme sind auch mit der neuen Firmware vorhanden, weil der Fehler gar nicht in der Firmware liegt! Das fhem Modul ESPLedController ist fehlerhaft! Andere RGBWW Platinen zeigen nämlich mit älterer Firmware genau dasselbe Verhalten, wenn ich sie RAW ansteuere.
Das bedeutet, der Fade, den ich vermisse, kommt nicht aus dem Controller selbst, sondern wird vom fhem Modul eingefügt. Wie von dir vermutet. Ebenso wird dort das RAW Kommando falsch zusammengebaut, sodass führende leere Einträge in der Kanalliste als 0 gesetzt werden.
Ich muss mal aus meinen Backups die Vorgängerversion des Moduls rauskramen und testen. Wird ziemlich sicher dann wieder gehen.
Sorry, dass du dich jetzt umsonst auf die Suche begeben hast.

Grüße
Markus

pjakobs

Zitat von: Mafi am 23 April 2026, 10:54:27Guten Morgen!

Tests haben ergeben, dass du richtig liegst mit deinen Vermutungen.
Beide Probleme sind auch mit der neuen Firmware vorhanden, weil der Fehler gar nicht in der Firmware liegt! Das fhem Modul ESPLedController ist fehlerhaft! Andere RGBWW Platinen zeigen nämlich mit älterer Firmware genau dasselbe Verhalten, wenn ich sie RAW ansteuere.
Das bedeutet, der Fade, den ich vermisse, kommt nicht aus dem Controller selbst, sondern wird vom fhem Modul eingefügt. Wie von dir vermutet. Ebenso wird dort das RAW Kommando falsch zusammengebaut, sodass führende leere Einträge in der Kanalliste als 0 gesetzt werden.
Ich muss mal aus meinen Backups die Vorgängerversion des Moduls rauskramen und testen. Wird ziemlich sicher dann wieder gehen.
Sorry, dass du dich jetzt umsonst auf die Suche begeben hast.

Grüße
Markus


kein Ding, schön, dass Du's gefunden hast.

Aber wie gesagt: die Funktion eines "default fade" will ich auch in der Firmware einbauen, weil's einfach schöner ist.

pjakobs

Im Moment habe ich echte Probleme mit den develop und experimental Versionen, es scheint mit der Anzahl freier TCP Verbindungen zusammenzuhängen, aber genau weiß ich es nicht.
Aktuell solltet Ihr nicht auf die neuen (700er) Versionen updaten.
Ich melde mich, wenn's besser wird

pjakobs

so, ich glaube, die V5.0.0-807-develop ist wieder okay.
Du darfst diesen Dateianhang nicht ansehen.
Das Problem war scheinbar, dass ich im Controller zu aggressiv gecached habe, jetzt nutze ich cache-busting im Vue/vite build Prozess, was dafür sorgt, dass jetzt alle Objekte, die nachgeladen werden einen eindeutigen String pro Build angehängt bekommen (siehe Anhang). Die Dateien sehen dann so aus:
/assets/index-DjEmwXxm.js
/assets/index-BdtixC0s.css
und wenn es einen neuen Build gibt, dann verändert sich der String, so dass der Browser Cache automatisch ein neues Dokument zieht, aber innerhalb eines Build die Datei gecached wird.
Nebenbei ist die CI für die Firmware jetzt deutlich ausgeweitet, inclusive valgrind checks, um eventuell neue Memory Leaks zu finden.
Ich arbeite gerade daran, dass API fast komplett aus dem http server heraus zu nehmen und in eine eigene Klasse zu packen, auf die Weise ist das API dann über HTTP, MQTT und Websocket nahezu 100% deckungsgleich, das Frontend wird das nutzen, um die Kommunikation mit dem Controller über Websocket abzuwickeln. Das sollte, besoders auf dem ESP8266 dazu führen, dass es seltener zu Verbindungsabbrüchen wegen vollständig benutzter TCP Verbindungen kommen wird.