ESP RGBWW Controller - Firmware v5

[pjakobs]

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]

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]

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]

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]

Hi @pjakobs!

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

[pjakobs]

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 Erweitern

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]

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]

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

[pjakobs]

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