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.