ESP RGBWW Controller - Firmware v5

pjakobs · 05 Februar 2026, 22:26:18

release candidate hab ich gedacht... hmf...
Gerade gab es einen Schwung Updates und Bugfixes in Sming, unter anderem einen neuen HTTP Parser (der gleich einen Bug zum Vorschein gebracht hat, die Fehlersuche hat aber auch dazu geführt, dass ich den Webserver Code aufgeräumt habe), eine Methode um in ConfigDB zur Compilezeit Defaults zu setzen (die Funktion hatte ich mir gewünscht, weil ich damit anhand des Build-Mode entscheiden kann, ob die Telemetrie per default ein- oder ausgeschaltet ist), eine neue FSTR_LOAD Methode (ich halte den gesamten HTML / JavaScript Text als Flash-Strings im Code, statt wie früher als Datei im Flash Filesystem, dadurch brauche ich nur noch ein binary File).
Aber es wird einen Release Kandidaten geben. Bestimmt. Und ziemlich sicher 2026!

pjakobs · 02 März 2026, 11:57:32

so, nach alldem und einem umfangreichen Hardening für den Server, der Lightinator.de hostet, ist eine neue Version der Firmware live. Wundert Euch nicht über den großen Versionssprung, da sind zwar etliche Änderungen drin (vornehmlich in Sming, wie oben beschrieben) aber die vielen Builds kamen primär dadurch zustande, dass ich die CI umbauen musste, um mit dem Hardening des Servers mitzuziehen (die CI "klopft" jetzt beim Server an, und wird dann explizit für eine ssh Verbindung freigeschaltet)

pula · 14 März 2026, 23:54:55

hm. lightinator.de scheint grad nicht zu funktionieren.
leider scheine ich grade zu dämlich zum flashen des lightinator v3 zu sein.
da ist ein block mit 6 pins. wenn ich das richtig verstehe ist links oben rx und links unten tx. mitte oben ist gnd. ich hatte das vor zwei jahren oder so schon mal, habs aber vergessen.
könnte bitte jemand so nett sein und mir sagen, wie die pins belegt sind?
danke und cheers,
Pula

pjakobs · 15 März 2026, 07:20:52

Hi @pula, die Belegung steht hier https://forum.fhem.de/index.php?topic=101240.0

auf http://lightinator.de hatte sich offenbar der nginx aufgehängt und mein uptime monitoring hat nix davon mitbekommen.
Läuft wieder!

pj

pula · 16 März 2026, 07:56:22

Hi @pjakobs!

danke schön für die sehr rasche und hilfreiche Antwort!
ich hatte das gesehen aber glatt drübergelesen...
Cheers,
Pula

pjakobs · 03 April 2026, 15:21:47

heute gibt's ne neue Version, ich hab jetzt viel Zeit damit zugebracht, die neue ESP32 Hardware und die zugehörige neue HardwarePWM Implementation zu testen - das ist jetzt drin.
Weil ich damit ein paar Probleme hatte, habe ich heute noch was implementiert, was grundsätzlich sinnvoll sein dürfte: ich habe endlich remote logging vernünftig implementiert und zwar als einfaches BSD rSyslog.

Dazu gibt es eine neue Konfigurationskarte auf der "network" Seite, auf der Ihr rsyslog ein und ausschalten, sowie host und port konfigurieren könnt.

Ihr braucht dazu einen rsyslog host, das kann etwa ein fhem host sein, in meinem Fall habe ich ein `lightinator.config` file in `/etc/rsyslog.d/` mit folgendem Inhalt angelegt:

Code Auswählen

template(name="LightinatorLog" type="string" string="/var/log/lightinator.log")

template(name="LightinatorWithIP" type="list") {
    property(name="timegenerated" dateFormat="rfc3339")
    constant(value=" ")
    property(name="fromhost-ip")
    constant(value=" : ")
    property(name="rawmsg")
    constant(value="\n")
}

ruleset(name="LightinatorLogProcessing") {
    action(type="omfile" dynaFile="LightinatorLog" template="LightinatorWithIP")
    stop
}

module(load="imudp")
input(type="imudp" port="514" ruleset="LightinatorLogProcessing")

die Version ist live, sobald die CI durchgelafuen ist.

pjakobs · 03 April 2026, 23:38:14

und noch ein Update, ich hab ein paar UI Elemente aufgefrischt (an die Szenen muss ich nochmal ran, die sind noch nix), ein paar Bugs gefixt und - einen integrierten Log Viewer im UI gebaut.

Nun ist das mit den Logs so eine Sache, ich hatte mal versucht, Logs über websocket zu schicken, aber das hat beim ESP8266 immer dazu geführt, dass der heap ruck zuck voll war und der Controller abgestürzt ist. Die rSyslog Lösung funktioniert prima, der Controller "wirft" seine Logzeile einfach zu einer IP und hofft, dass sie ankommt, der Overhead ist minimal.

Nun könntet Ihr alle einen rSyslog server aufsetzen (siehe oben, ist nicht wirklich schwer) aber ich will ja lieber eine integrierte Lösung, und hier ist sie:
Es gibt jetzt einen kleinen Container mit rSyslog und einem http Interface. Wenn Ihr auf die Log Viewer Karte im Lightinator UI geht, dann findet Ihr dort eine Erklärung, wie Ihr den Log Service aktivieren könnt. Dazu braucht Ihr (irgendein) Linux mit Podman oder Docker sowie git, auf dem Ihr das Teil ausführen könnt. Wenn der Container gestartet ist, seht ihr die ip-addresse auf der Konsole, die tragt Ihr im entsprechenden Feld der Log Viewer Karte ein, das konfiguiert den aktuellen Controller so, dass er seine Logs an den Log Service schickt, von wo das Frontend sie abholt. Von dort könnt ihr das Log auch speichern und ggf. versenden.
Ihr könnt den Log Collector einfach laufen lassen und alle Controller loggen dahin, die Daten werden 7 Tage dort vorgehalten und dann gelöscht. So könnt Ihr bei Problemen immer in die Vergangenheit schauen.

Du darfst diesen Dateianhang nicht ansehen.

pjakobs · 04 April 2026, 12:58:35

es scheint, als ob ich in den aktuellen Versionen ein Memory Leak eingebaut habe - ich such mal weiter.

pjakobs · 05 April 2026, 20:46:33

so, der OTA bug ist behoben und insgesamt habe ich ein paar Funktionen eingebaut, um den OTA Prozess noch sicherer zu machen (so rebootet ein Controller etwa automatisch, wenn er zwei Minuten im OTA festhängt - das sollte genügen, um selbst auf vergleichsweise langsamen Verbindungen das 1MB Binary runterzuladen)

Was ist neu: Wenn Ihr die System Settings Seite auf einem PC aufruft, werden jetzt die Informationen und die anderen Punkte nebeneinander dargestellt. Das schafft etwas mehr Überblick. Auf kleinen Bildschirmen bleibt alles wie gehabt.

Neu ist der Log Viewer, der erstmal keine Funktion hat, wenn Ihr nicht den Log Companion laufen habt. Log Companion ist ein kleiner Container, den Ihr auf einem beliebigen Linux Rechner (etwa Eurer fhem Instanz - auf Fritzboxen wird es eher nicht gehen) mitlaufen lassen könnt. er ist nötig, weil ein javascript frontend wie das Lightinator WebUI nicht selbst einen udp Port aufmachen kann. Der Companion ist ein udb rSyslog listener, der die Logs für alle Controller mitschreibt.
Darauf zugreifen könnt Ihr auf zwei Weisen: einmal über das Controller Frontend selbst - der Logviewer hier zeigt Euch das Log des aktuellen Controllers (Achtung: nur die debug builds schreiben logs, die anderen habe die Funktion zwar im Grunde, aber sie schreiben keine logs)
Alternativ könnt Ihr direkt auf das UI des Log Companions zugreifen, das ist unter <host-auf-dem-der-container-läuft>:4821 erreichbar und bietet zwei Ansichten:
- einmal eine Übersicht über alle Controller, die im Netz bekannt sind. Dort könnt Ihr entweder zentral für alle oder gezielt für einzelne die log funktion ein und ausschalten.
- oben rechts ist ein settigs Button, über den Ihr ein paar grundlegende Einstellungen vornehmen könnt (obwohl das meiste automatisch entdeckt werden kann) und - ich weiß nicht für wie viele das interessant ist - die Logs auch an eine Loki Instanz weiterleiten könnt. Loki ist die Logdatenbank des Grafana Projektes und wird in großen Netzen meist zum zentralen Logging genutzt. So habt Ihr dann etwa über ein Grafana Frontend die Möglichkeit, die Logs aller Eurer Controller einzusehen.
- links ist die Liste der verfügbaren Controller, wenn Ihr dort auf einen klickt, dann wird der rechte Bereich des Fensters zum Log Fenster des gewählten controllers, sprich Ihr seht dort live, was Ihr sonst auf der seriellen Konsole sehen würdet - weitestgehend jedenfalls, denn wenn der Controller nicht mit dem Netz verbunden ist, kann er natürlich auch nichts senden.
- es gibt ein paar Änderungen, die hoffentlich dafür sorgen, dass Ihr mir in Zukunft trotzdem Crash Dumps schicken könnt. Ich speichere jetzt 56 Stack Worte und die Register bei einem Crash im RAM der Echtzeituhr, der wird bei einem Reboot nicht gelöscht und ist auch bei einem Crash relativ sicher zu beschreiben - wenn dort ein Crash hinterlegt ist, wird der nach einem neustart auf den Logserver geschrieben. Wenn alles funktioniert kann der sogar sofort eine Analyse vornehmen, das ist aber, mangels Crash, bisher nicht getestet.
Was gab's sonst noch.
Ich habe die Speichernutzung ein bisschen optimiert. Das Frontend hat sich manchmal drauf verlassen, dass der Controller auch große Datenstrukturen schon streamen kann - kann er nicht immer, dann hat er mit einem HTTPERR 429 geantwortet und der Client hat zunehmend länger gewartet, bis er erneut versucht hat, auf den Controller zu schreiben.
Jetzt zerlegt das Frontend von Vornherein große Strukturen und schreibt sie in kleineren Paketen. Wenn dabei ein 429 auftritt, verzögert es.
Im Info block (den gibt es jetzt in zwei Versionen, einmal unter "/info" in der alten Version für fhem, einmal unter "/info?v=2" in einer strukturierten Variante für moderne Clients) lieft der Controller jetzt auch den niedrigsten HEAP in den letzten 10 Minuten und seit Neustart sowie die Anzahl der Situationen, in denen er eine Anfrage abgelehnt hat, weil nicht genug RAM zur Verfügung stand. Wenn ich meine Implementation richtig gemacht habe, sollte der 10 Minuten Fehler Counter nie mehr als eins oder zwei sein.

ansonsten ist viel hinter den Kulissen passiert und es passiert noch mehr, etwa arbeite ich gerade an einem komplett neuen Szeneneditor. Der kommt dann später.

Edit: ich hab dann mal noch das README upgedatet: https://github.com/pljakobs/esp_rgbww_firmware/blob/develop/README.md

pjakobs · 21 April 2026, 14:31:31

und jetzt gibt es auch eine erste HomeAssistant integration für Lightinator.
https://github.com/pljakobs/Lightinator_HA_module/

Die Integration ist noch ein bisschen holprig, sollte aber grundsätzlich funktionieren.
- controller werden automatisch über mDNS hinzugefügt
- sobald ein controller erkannt wurde, werden alle, die in dessen /hosts Tabelle stehen auch entdeckt
- wenn das nicht funktioniert, kann der erste Controller auch von Hand hinzugefügt werden.

Im Moment werden HSV und RAW Geräte angelegt, ich muss noch besser verstehen, wie HA grundsätzlich Leuchten anzeigt, und außer der Lichtsteuerung ist derzeit noch nicht viel implementiert.

Zusätzlich gibt es in der aktuellen Version 5.0-710 einige Fixes in der Firmware und Webapp, sowie, für esp32 Builds, eine massiv überarbeitete Esp32HardwarePwm library (https://github.com/pljakobs/Esp32HardwarePwm) die aber noch nicht vollständig implementiert ist. Der nächste Schritt ist da, die RGBWWLed library so anzupassen, dass das ganze Fade Queueing in der PWM library (und damit weitgehend in Hardware) passiert. Das öffnet den Weg zu noch besseren Fades (12 oder 14 Bit Auflösung).

Auf den Esp8266 sehe ich im Moment ungewöhnlich viel API Latenz was immer wieder zu Fehlern führt, ich bin mir nicht ganz sicher, woran das liegt. Da bin ich noch am debuggen.

Mafi · 21 April 2026, 14:57:09

Mir ist kürzlich etwas aufgefallen, was sich im Verhalten geändert hat. Leider kann ich nicht sagen, welche Version genau die Änderung mitgebracht hat.
Aktuell ist jedenfalls pj-1-725-ga648-dirty-[testing] drauf. So steht es im info-firmware Reading.

Das eine ist, dass per RAW Kommando ein- und ausgeschaltete Kanäle jetzt nicht mehr schön sanft auf den Zielwert dimmen, sondern hart ein- bzw. ausgeschaltet werden. Beim Ändern der Helligkeit dürfte es genauso sein, aber das nutze ich in dieser konkreten Anwendung nicht.

Das andere ist, dass das RAW Kommando nicht mehr so funktioniert wie bisher. Wenn ich nur einen Kanal verändern will und daher die anderen durch leere Werte zwischen den Kommas ersetze (z.B. ,,,900 um nur den Weißkanal zu ändern), dann werden alle Werte vor dem zu ändernden nicht als "unverändert lassen" behandelt, sondern auf 0 gesetzt. Kanäle, die hinter dem zu ändernden Wert noch folgen (also im Beispiel der zweite Weißkanal) bleiben aber richtigerweise unverändert.
Aufgefallen ist mir das mal wieder bei meinen Aquarien. Da habe ich eine Leuchte im Schrank und eine für Wassertests oben am Regal. Beide sind einfach zwei Kanäle am Controller, die per RAW Kommando einzeln geschaltet werden. Die werden jetzt hart geschaltet und das Einschalten des einen schaltet den anderen plötzlich aus, aber das Einschalten des anderen lässt den einen an... da musste ich erst einmal kurz forschen.

Vielleicht kannst du bei Gelegenheit mal schauen, wie das kommt.

Grüße
Markus

pjakobs · 21 April 2026, 16:58:39

Moin Markus,

Zitat von: Mafi am 21 April 2026, 14:57:09Mir ist kürzlich etwas aufgefallen, was sich im Verhalten geändert hat. Leider kann ich nicht sagen, welche Version genau die Änderung mitgebracht hat.
Aktuell ist jedenfalls pj-1-725-ga648-dirty-[testing] drauf. So steht es im info-firmware Reading.

der namens-syntax nach, ist die aber schon echt alt

Zitat von: Mafi am 21 April 2026, 14:57:09Das eine ist, dass per RAW Kommando ein- und ausgeschaltete Kanäle jetzt nicht mehr schön sanft auf den Zielwert dimmen, sondern hart ein- bzw. ausgeschaltet werden. Beim Ändern der Helligkeit dürfte es genauso sein, aber das nutze ich in dieser konkreten Anwendung nicht.

Das andere ist, dass das RAW Kommando nicht mehr so funktioniert wie bisher. Wenn ich nur einen Kanal verändern will und daher die anderen durch leere Werte zwischen den Kommas ersetze (z.B. ,,,900 um nur den Weißkanal zu ändern), dann werden alle Werte vor dem zu ändernden nicht als "unverändert lassen" behandelt, sondern auf 0 gesetzt. Kanäle, die hinter dem zu ändernden Wert noch folgen (also im Beispiel der zweite Weißkanal) bleiben aber richtigerweise unverändert.
Aufgefallen ist mir das mal wieder bei meinen Aquarien. Da habe ich eine Leuchte im Schrank und eine für Wassertests oben am Regal. Beide sind einfach zwei Kanäle am Controller, die per RAW Kommando einzeln geschaltet werden. Die werden jetzt hart geschaltet und das Einschalten des einen schaltet den anderen plötzlich aus, aber das Einschalten des anderen lässt den einen an... da musste ich erst einmal kurz forschen.

Vielleicht kannst du bei Gelegenheit mal schauen, wie das kommt.

Grüße
Markus

ich hab gerade mal beides bei mir hier getestet, und das funktioniert.
Nutzt Du das ursprüngliche LedController Fhem Modul oder das EspLedController von @vbs, soweit ich mich erinnere war das "channel skipping" etwas, das da rein kam.
Technisch ist das ja nur ein sparse json update, also es wird im {"color":{"raw":{ ... }} objekt nur die tatsächlich gegebenen Werte eingetragen werden.

Ich bin mir nicht mehr sicher, ob die ursprüngliche Firmware einen default fade hatte, oder ob das im fhem modul war, da schau ich nochmal.