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!