ESP RGBWW Controller - Firmware v5

[pjakobs]

so, passend zu Weihnachten gibt es nochmal eine neue Version - 5.0-550 mit der Webapp V5.0-214

diesmal habe ich in erster Linie im Frontend aufgeräumt und die Synchronisation von Gruppen und Presets gearbeitet.
Aktuell gibt es noch ein paar Dinge, die mir aufgefallen sind:

• • mit den virtuellen "on" / "off" Presets macht es eigentlich keinen Sinn mehr, die presets Seite nur nach Bedarf anzuzeigen. Darüber muss ich nochmal nachdenken, vielleicht gibt es da eine bessere user experience
  • im "hostname and Icon" Dialog steht "localhost" - nicht der eigentliche Name, der für den Controller konfiguriert ist. Das ist ein Resultat der Tatsache, dass der name im /hosts API anders sein kann als im /config - eine Diskrepanz, mit der ich noch aufräumen will.
  • die ausgewählten Icons werden offenbar nicht korrekt geladen, darum wird das default Icon dargestellt

Ich wäre dankbar, wenn Ihr Euch die Firmware mal genauer anseht, und mir sagt, was nicht oder nicht wie erwartet funktioniert, hier oder (eigentlich lieber) drüben als Github issue.

• • für die Firmware selbst hier: firmware issues
  • für die Webapp hier: webapp issues

Ich hab mal ein paar Screenshots aus dem Telemetrie-Dashboard angehängt - aus dem letzten, dem X/Y Chart, glaube ich abzulesen, dass es immer noch ein, wenn auch sehr geringes, Memory Leak gibt, je länger die Controller laufen, desto weniger free Heap ist verfügbar - aber das scheint sich um etwa 512Byte pro Monat zu handeln, Ich wüsste zwar gerne, was das ist, aber im Moment hab ich keine Idee.

[vbs]

Auch wenn ich nicht so großer Fan vom Sammeln von Nutzerdaten bin (auch wenn ich den Nutzen hier total sehe), find ich deine Dashboards echt sehr gelungen!

[pjakobs]

Ich hab auch ne Weile darüber nachgedacht, was ich da sinnvoll einsammeln kann und wie ich es vermeiden kann, persönlich identifizierbare Daten zu sammeln und mich dann entschiednen, es sehr klar zu machen, was wann übertragen wird (siehe Screenshot oder die Telemetrie Seite im Netzwerk Menü)
Ich übertrage etwa bewusst nicht die ssid, weil ich damit in diversen Datenbanken die Lokation des Controllers nachsehen könnte - geht mich nix an und - sollte jemand sich Zugriff auf die Daten verschaffen, dann will ich nicht, dass das drin ist.
Dazu kommt: die Telemetrie kann jederzeit an- und aus geschaltet werden, wie auch das (sehr rudimentäre) logging über mqtt (da werde ich noch mehr rein packen, weil es ein extrem hilfreiches Feature ist - vielleicht aber dann mit Timeout, also "einschalten für 24h" oder so.
Die Telemetrie wird automatisch nur dann eingeschaltet, wenn der Nutzer einen debug build installiert, bei einem release build bleibt es aus (allerdings wird sie nicht automatisch abgeschaltet, wenn man vom Debug zum Release wechselt).
Eigentlich ist das genau die Transparenz, die ich mir von jedem Anbieter von Netzwerkgeräten wünsche, aber selbst im open source wird nicht immer ganz offen damit umgegangen.

Die Daten laufen dann ja über den (password geschützten) mqtt server auf lightinator.de und werden von einem kleinen Python Service auf meinem lokalen Server abgeholt und in eine Influxdb geschoben. Das zugehörige Bucket ("rgbww") ist dabei mit einer Retention von 30 Tagen konfiguriert, d.h. alle älteren Daten werden gelöscht.
(ich kann dennoch längere Uptimes als 30 Tage messen, weil die Controller die Uptime ja in Minuten seit dem letzten Start reporten).
Das Dashboard ist dann einfach Grafana.

und damit Glückwunsch an den Uptime König 192.168.178.135!

[pjakobs]

das bleibt jetzt, hoffentlich, bis auf diese Nachricht für Euch unbemerkt:
Ich habe eben lightinator.de auf eine größere Instanz umgezogen.
Die alte Instanz war die kleinstmögliche, mit nur 2GB RAM, was eigentlich genügen sollte.
Aber: die alte Instanz hat alle ein bis zwei Monate mal die Arbeit komplett eingestellt und ich vermute, dass es am geringen Speicher liegt.
Jetzt hat lightinator.de 8GB RAM (und sechs CPU Kerne) das sollte genügen.

Aber: der Tausch wird zu ca. einer Stunde Unerreichbarkeit führen (nicht so schlimm, wenn ich bedenken, dass der alte Server heute früh schon wieder sechs Stunden unerreichbar war).

Was gerade nicht funktioniert:

• Firmware updates
• Telemetrie
• Github publish workflow

Update
Lightinator ist auf den neuen Server umgezogen, Download und Telemetrie laufen wieder - die Telemetrie lief ein bisschen später, weil ich noch eine Firewall Regel einfügen musste.

Der Deployment Workflow von Github läuft noch nicht, aber das ist nur nötig, wenn ich die nächste Version pushe.

Update 2
Der Deployment Worflow funktioniert auch wieder. Ein Nutzer muss schon Mitglied einer Gruppe sein, um der Gruppe Dateien zuzuweisen.
In dem Fall: der deployment user, den mein github workflow nutzt, um die Dateien hochzuladen muss dem nginx Prozess die Rechte darauf geben - dazu muss er Mitglied der nginx Gruppe sein.

[pjakobs]

ich hatte ein bisschen Zeit und hab mal ein Subset des Dashboards in die Homepage für lightinator.de eingebaut.
So könnt Ihr auch sehen, wie viele Controller gerade Telemetrie lifern, welche Versionen draußen laufen und wie stabil die Versionen sind - bzw. wie lange die Controller einer Version durchschnittlich online sind - das ist natürlich eine geringe Zeit, wenn sie gerade erst upgedatet wurden.

Die aktuelle V5.0-555 sollte stabil sein, mehr freien Heap haben und vor allem einen Bug im Scene Management gefixed haben.
Dazu hatte ich zuletzt das Problem, dass Firmware und Frontend zusammen nah an die 1024kByte heran kamen, die auf dem ESP8266 für ein Firmware Image zur Verfügung stehen.
Ich hatte im Scene Management ein draggable Objekt (die Abfolge von Elementen einer Animation konnte durch drag&drop geändert werden), das habe ich jetzt durch einfache up/down Buttons ersetzt - das alleine spart mir 80kByte im Flash Image - absurd, wie viel Speicher JavaScript Frameworks heute so verschwenden.

Ich habe neulich mal angefangen, eine Integration für ioBroker zu bauen, das sollte eigentlich ziemlich gut funktionieren, weil ich hoffentlich manches an Code aus dem Frontend wiederverwenden kann. Für Home Assistant habe ich minimale mqtt Integration und hoffe, dass ich die Arbeit von @vbs wiederverwenden kann, damit hätten wir dann zwei moderne Hausautomationsframeworks eingebunden.

Ich werde mich dann wohl mal wieder um die Hardware kümmern.

[2space]

Mein Controller kann plötzlich kein rot mehr darstellen. Wähle ich reines rot geht der Stripe quasi aus. Habt ihr einen Tipp an welcher Stelle ich mit der Suche beginnen soll?

Firmware 566

Vielen Dank

[pjakobs]

moin @2space - als allererstes würde ich die Physik überprüfen: Kontakte, Lötstellen etc.
Wenn das alles funktioniert (Du kannst zum Test mal den Kontakt für Rot gegen Masse brücken, wenn das funktioniert, ist bis zu der Stelle alles richtig.
Die zweite Frage ist: ist die Pinbelegung korrekt eingestellt? Für Dich sollte das das mrpj Layout sein.
Du schreibst hier im Thread für die Version 5, ich vermute also mal, dass Du die nutzt - da kannst Du mal unter system settings / controller config / pin configuration nachsehen, sollte so aussehen wie im Anhang.
Zuallerletzt könnte es theoretisch auch ein MOSFET oder gar der ESP8266 sein, damit wärst Du aber in den ersten beiden Entwürfen der erste, halte ich für extrem unwahrscheinlich.

(upps, gerade gesehen, dass Du Build 566 hast, das ist die aktuellste Version, ich kann jedenfalls bestätigen, dass die bei mir problemlos funktioniert.)
((was übrigens ein Glück ist, denn irgendwann in den 540ern waren mal ein paar Versionen dabei, in denen der Pinconfig Editor nicht funktionierte))

[2space]

Danke für die schnelle Info. Zeitlich viel das das ungefähr mit einem Update der Firmware zusammen. Ich prüfe asap die angesprochenen Punkte.

[pjakobs]

so, gerade noch ne neue Version (V5.0-568) gepusht,

die bisherige Version lässt Euch für jeden Controller ein Icon auswählen. Weil ich auf dem Controller selbst Platz sparen muss, werden diese Icons aus dem Web nachgeladen - aus dem Google material icon set. (ich könnte auch andere einfügen, im Moment geht aber nur Google).

Das ist nicht jedermann's Sache und deshalb habe ich jetzt eine Konfigurationsoption hinzugefügt, die es ermöglicht, die Nutzung von online Icons zu unterbinden.

Default ist, dass online Icons möglich sind, allerdings werden so oder so keine geladen, wenn Ihr keine konfiguriert habt.

[pjakobs]

ping @2space

hast Du Dein Problem irgendwie beheben können?

[pjakobs]

Release Candidate

vor etwas über zwei Jahren habe ich angefangen, die Firmware für ESP[8266|32|32c3] Controller zu überarbeiten, und so rückblickend ist viel passiert:

Firmware

• Migration auf die aktuellste SMING Version
  die alte Firmware steckte auf SMING 4 fest und war auf neueren Versionen nicht mehr kompilierbar, was ein Problem war, weil erst mit den neueren Versionen andere Controller als der ESP8266 unterstützt wurden
• Verfügbarkeit zusätzlich auf ESP32 Plattformen
  damit konnte ich eine Firmware bauen, die sich jetzt problemlos für alle drei relevanten Controller compilieren lässt
• LittleFS statt SPIFFS
  - besseres wear levelling
  - besseres Fehler handling
  Dieser Schritt war riesig für mich, statt des alten Layouts, wo es jeweils ein Firmware und ein Frontend Image gab, ist in dieser Version das Frontend im Firmware Image eingebettet, dadurch gibt es nur noch eine Flash Datei und das Dateisystem bleibt frei.
  Die Partitionierung ist heute so, dass es zwei ROM Bereiche gibt (rom 0 und rom 1) und zwei LittleFS Dateisysteme, von denen aktuell nur das erste genutzt wird. Ich will in der nächsten Version eine Backup / Versionierungsfunktion für die Konfiguration einbauen, dafür würde ich dann die zweite LittleFS Partition nutzen.
  
• ConfigDB statt Konfigurationsstruktur im RAM
  Noch ein riesen Schritt für mich: zusammen mit Mikee74, dem Maintainer des SMING Frameworks haben wir eine Konfigurationsdatenbank für SMING entwickelt. Jetzt kann ich die notwendigen Konfigparameter als JSONSchema definieren und beim bauen der Firmware werden daraus C++ Accessor Klassen (also getter und, wenn auch etwas aufwendiger, setter) generiert. Ich kann auf die Konfigurationsparameter also so zugreifen, als seien sie normale C++ Klassen, dahinter liegt allerdings eine Datenbank, die diese Daten in JSON Strukturen im Dateisystem speichert.
  ConfigDB kümmert sich dabei halbautomatisch um das Locking, so dass nicht zwei konkurrierende Zugriffe auf eine Struktur geschehen und liefert mir zudem eine Streaming API um die Konfiguration direkt über HTTP zu senden und zu empfangen.
  
• mDNS
  die Controller nutzten nun mDNS um alle anderen Controller im Netz zu finden. Sie führen eine lokale Liste der sichtbaren Controller die vom Frontend genutzt wird, um die Swarm Funktionalitäten zu implementieren. Mehr dazu im Frontend Block.
  
• neues PWM für die ESP32 Familie
  eines der Probleme beim ESP8266 ist die Tatsache, dass die PWM Funktion softwarebasiert ist, und deshalb keine hohen Frequenzen kann. Der ESP32 hat PWM Hardware mit wirklich gutem Funktionsumfang und einer großen Bandbreite an möglichen Frequenzen.
  Ich habe eine neue PWM Implementierung für den ESP32 für SMING geschrieben, und dann nochmal eine verbesserte für die Controller Firmware (die muss ich noch zu SMING submitten, in der Hoffnung, dass sie den strengen Augen dort genehm ist)
  Die Basis-PWM ist im Grunde einfach eine Reimplementierung des Interface für den ESP8266 für den ESP32, die viele Parameter als Default so setzt, dass sich das System ziemlich genau so verhält wie erwartet - mit der Ausnahme, dass höhere Frequenzen möglich sind.
  Die erweiterte PWM implementation nutzt das led_c Interface das Espressif hier anbietet weitergehend und definiert Gruppen von Kanälen, die gemeinsame Eigenschaften haben. Dadurch konnte ich zusätzlich zur 'normalen' PWM ein paar Funktionen einbauen, die die elektromagnetische Verträglichkeit der Controller erhöhen sollte. So können die Kanäle jetzt phasenverschoben betrieben werden (default für die ESP32(c3) Builds der Firmware. Das heißt, dass für jeden Kanal (R, G, B, WW, CW) der PWM Zyklus um ein fünftel der Zykluslänge verschoben beginnt. Was bedeutet das? Normalerweise beginnt der Zyklus für alle Kanäle gleichzeitig bei t=0ms, sind mehrere Kanäle an (egal mit welcher Helligkeit) schalten alle zu diesem Zeitpunkt an und erzeugen eine große Stromspitze auf der 12V Schiene. Phasenverschoben werden sie entsprechend später geschaltet, etwa R bei 0µs, G bei 200µs, B bei 400µs und so weiter, damit "verwischt" sich der Einschaltimpuls und die Stromspitze wird über einen breiten Bereich gestreckt und damit flacher.
  Die zweite Funktion, die die Verträglichkeit erhöhen sollte ist ein Spread Spectrum. Normalerweise laufen PWM Controller mit einer konstanten Grundfrequenz, etwa 1kHz. Das heißt, dass die Schaltvorgänge sich exakt jede Millisekunde widerholen und somit ein EM Feld von 1kHz ausgesendet wird. Bei den LED Controllern kann da ziemlich viel Strom geschaltet werden, dass heißt dann auch, dass ziemlich viel Energie in das Feld geht - zumal die MOSFETs ja "hart" schalten, also ein steiles dI/dt haben. Das lässt sich systembedingt nicht wirklich ändern, aber durch Spread Spectrum Modulation kann ich diesen Peak "verschmieren", und das geht so: wenn am Controller eine PWM Frequenz von 1kHz eingestellt und zudem Spread Spectrum mit einem Spread von 15% konfiguriert ist, dann springt die tatsächliche PWM Frequenz zufällig zwischen 1kHz-15% und 1kHz+15% herum, so dass das tatsächlich ausgestrahlte Spektrum zwischen 850Hz und 1150Hz verschmiert wird. Die Energie wird, statt auf einer schmalen Frequenz, auf allen 300 diskreten Frequenzen in diesem Bereich abgegeben, beträgt also auf jeder einzelnen Frequenz nur 1/300stel dessen, was sonst auf einer Frequenz abgegeben werden würde.
  (wenn jemand mit mehr HF / Funkamateurwissen als ich hier was korrigieren will, nur zu)
  
• Bugfixes
  Während der Arbeit mit der Firmware habe ich mehrere Bugs, sowohl in Sming als auch in darunterliegenden Komponenten wie etwa dem IP Stack (LWIP) gefunden, das alte Problem, dass Controller manchmal nur noch eine leere Seite statt des Web Frontends zeigten ist damit behoben. Durch LittleFS können auch Controller, die das Frontend nicht mehr laden können, weil das SPIFFS kaputt ist ("no filesystem mounted") wieder aktiviert werden.
  

Frontend

• komplette Neuimplementierung auf Quasar
  Das alte Frontend war mit AngularJS implementiert und um damit auf eine aktuelle Version zu kommen, wäre nicht weniger Aufwand nötig gewesen, wie es nötig war, das Frontend komplett neu auf einer modernen Plattform zu implementieren.
  Ich habe mich damals für Quasar entschieden, weil das mir auch die Möglichkeit bietet, Apps für Android und Apple zu bauen, auch wenn diese im Grunde nur embedded Browser mit der Webapp sind.
• Reimplementation der bestehenden Webapp
  Ich habe, soweit das möglich ist, die Funktionen der alten App 1:1 reimplementiert, die entsprechenden Settings für ColorMode, TransitionMode etc. funktionieren wie gehabt
• Swarm Funktionen
  Ich finde es nervig, wenn so einfache Dinge wie Leuchten irgendein Cloud API benötigen, um zu funktionieren, viele große Unternehmen finden das aber super, denn so können Kunden gebunden werden. Wenn dann irgendwann eine Technologie "zu alt" ist, werden die entsprechenden Cloud Funktionen abgeschaltet und man hat mit Glück noch eine dumme Leuchte, mit Pech ein Leuchte, die sich gar nicht mehr bedienen lässt. (es gibt da gerade so einen Fall mit einem Staubsaugroboter, wenn ich mich recht entsinne).
  
  Mein Ansatz für den Lightinator war daher, Schwarm-Funktionen einzubauen, so dass Nutzer ohne einen Server (Cloud oder Hausautomation) mehrere Controller von einer App aus bedienen können.
  
  Das geht über das einfach ein- und Ausschalten weit hinaus und ermöglicht es etwa, Szenen zu bauen, die über mehrere Controller hinweg abgespielt werden oder die Firmware auf allen Controllern im Schwarm upzudaten.
  (wie sehr ich mittlerweile der Firmware vertraue seht ihr vielleicht daran, dass ich neulich mitten in der Nacht ohne groß darüber nachzudeken auf "update all" geklickt habe - und es gibt Räume bei mir, die haben keine anderen Leuchten als die vom ESP Controller betriebenen.
  

Ich will die Frontend Funktionen gar nicht alle aufzählen, ich glaube (hoffe) sie sind weitgehend selbsterklärend.

Im Laufe des Tages werde ich die aktuelle development Version zur "stable" machen, und betrachte das als den Release Candidate für die finale 5.0.

Ideen für eine 5.1 habe ich genug, aber vielleicht sollte ich mal eine Weile lang wieder andere Projekte machen.

PS: heute oder morgen sollten neue Platinen für einen kleineren, ESP32C3 basierten Controller kommen. Ich hatte ein bisschen Probleme mit dem Startup Verhalten des C3, der scheinbar ein paar GPIOs "floaten" lässt, was mir immer wieder einen meiner MOSFETs zerschossen hat. Die neue Version nutzt andere Pins und sollte funktionieren. Dann mache ich auch eine neue Version des größeren Controllers aus der Sammelbestellung mit dem ESP32C3.