ESP RGBWW Controller - Firmware v5

[pjakobs]

Ich habe die grüne, mit den 5 liegenden auf der Rückseite.
Gruß Peter

Interessant, die haben wir doch eigentlich alle mit der @vbs firmware ausgeliefert, zumindest im Rahmen der Sammelbestellung. Dann ist meine Hypothese wohl falsch.

[PSI69]

zumindest im Rahmen der Sammelbestellung

Meine beiden sind daraus...

[PSI69]

Ich habe eben noch einmal nachgeschaut, in meinem Changelog steht das hier als alte Version:

Code Auswählen Erweitern

Firmware vbs35
Web Interface 0.3.3-shojo7
RGBWW Version 0.8.1-vbs5
SMING Version 3.5.1 Ich habe ich die OTA URL geändert und das Update durchgeführt: OTA URL: 'http://lightinator.de/version.json'; (ALT: 'http://rgbww.dronezone.de/release/version.json')
Danach dann der AP Mode nach dem reboot beider Controller.

[pjakobs]

hmm.. das war die letzte Firmware vor der jetzigen.
Aber ich meine, Sming 3.5 hatte noch keine Partition Tables. Ich muss mal suchen.
Jetzt hast Du aber Firmware "pj-1-719-gad87" und Sming Version 6, oder?
(ich muss die git-version Strings mal fixen)

[pjakobs]

info-firmware ad87-dirty-[develop]
info-sming_version 6.0.0
info-webapp_version 8843-dirty-[devel]

ich muss wirklich die git-version Strings fixen

[PSI69]

Hier bin ich 'gelandet' nach dem Update:
Git Version ad87-dirty-[develop]
Build Type release
Git Date 2025-03-25
Webapp Version 8843-dirty-[devel]
Sming Version 6.0.0

[pjakobs]

So, ich hab mal die Release Struktur komplett umgebaut. Es gibt jetzt drei production Stages:
stable/testing/develop

• develop ist, wo ich teste. Die kann schonmal komplett kaputt sein, im Normalfall sollte aber von dort aus sollte zumindest immer ein OTA funktionieren (gestern ging das nicht, weil ich eben am Umbauen war)
• testing ist die Stage, in die ich builds schiebe, von denen ich glaube, dass sie stabil genug für den normalen Gebrauch sind. Wer nicht allzu abenteurlustig ist, aber neue Features testin will, sollte die verwenden.
• stable gibt es aktuell noch nicht, denn noch verändert sich ja vieles. Sobald die 5.0 fertig ist, wird das die stable und neue Features für eine 5.1 laufen dann in die anderen beiden stages ein

Dazu gibt es für alle Stages mindestens zwei Builds zur Auswahl: Stable und Testing haben immer eine aktuelle und eine historische Version, so dass, wenn etwas wirklich nicht funktioniert, eine Fallback Möglichkeit besteht. Für develop gibt es 10 historische Versionen.

zudem haben die Versionen jetzt alle sinnvolle Version Strings im Fommat V<major>.<minor>-<build>-<stage> also etwa V5.0-334-develop. Beachtet, dass V5.0 für Frontend und Firmware immer gleich ist, aber die Build Nummer sich unterscheidet (in diesem Moment 334 für die Firmware und 116 für das Frontend). Weil ein Update des Frontend immer einen Rebuild der Firmware mit sich bringt, nicht aber umgekehrt, wird die Firmware build-Nummer immer größer sein und schnelelr größer werden als die des Frontends.

Was ich noch nicht implementiert habe sind entsprechend aufgeteilte Stages für das Frontend, was ggf. zu Problemen führen kann, weil der Firmware build aktuell immer den develop Zustand des Frontend nutzt, d.h. wenn ich eine neue Testing Version starte, nimmt sie das aktuelle Frontend. Ich glaube aber, dass das kein wirklich großes Problem ist.

[weini]

Wow, vielen Dank für die neue Version.

Ich habe eine Platine V1.3, meiner Erinnerung nach aus der allerersten Serie (stehende LED Treiber).
Mit OTA Update war da leider nichts zu machen, auch nicht über die curl Tricks aus der Linux Shell. In der Web GUI hat mir der Controller sofort einen "Netzwerkfehler" gemeldet. Via curl ist er mal länger mal kürzer auf "ota ongoing" gegangen, hat aber immer den alten Stand behalten.

Ich habe ihn dann schließlich via Kabel geflasht und nach dem üblichen Drama, das Ding in den Flash-Modus zu bekommen, hat der Update auch funktioniert.
Danach waren die Einstellungen weg, was ich erwartet hatte. Nicht erwartet hatte ich aber, dass der AP nun per Default ein Passwort benötigt. Das ist dann auch nur hier in einem Post zu finden - ganz schön gemein    . Für andere wäre es sicher hilfreich, das hier im ersten Post und in Github noch zu wiederholen.

Eine Kleinigkeit ist mir noch aufgefallen: Ich habe manuell einen Hostnamen vergeben. Der wurde mir aber zweimal überschrieben und zwar mit dem Devicename aus FHEM. Da scheint irgendwas zu aktualisieren, was nicht soll.

[pjakobs]

Wow, vielen Dank für die neue Version.

Ich habe eine Platine V1.3, meiner Erinnerung nach aus der allerersten Serie (stehende LED Treiber).
Mit OTA Update war da leider nichts zu machen, auch nicht über die curl Tricks aus der Linux Shell. In der Web GUI hat mir der Controller sofort einen "Netzwerkfehler" gemeldet. Via curl ist er mal länger mal kürzer auf "ota ongoing" gegangen, hat aber immer den alten Stand behalten.

so einen hatte ich auch schonmal, und kann nicht sagen, was da los ist.

Ich habe ihn dann schließlich via Kabel geflasht und nach dem üblichen Drama, das Ding in den Flash-Modus zu bekommen, hat der Update auch funktioniert.
Danach waren die Einstellungen weg, was ich erwartet hatte. Nicht erwartet hatte ich aber, dass der AP nun per Default ein Passwort benötigt. Das ist dann auch nur hier in einem Post zu finden - ganz schön gemein  . Für andere wäre es sicher hilfreich, das hier im ersten Post und in Github noch zu wiederholen.

Password braucht der AP eigentlich immer schon, aber Du hast recht, ich sollte es nochmal irgendwo vermerken.

Eine Kleinigkeit ist mir noch aufgefallen: Ich habe manuell einen Hostnamen vergeben. Der wurde mir aber zweimal überschrieben und zwar mit dem Devicename aus FHEM. Da scheint irgendwas zu aktualisieren, was nicht soll.

das fhem modul kann den Hostnamen überschreiben, das stimmt, tut es das? @vbs?

[Mafi]

Wow, vielen Dank für die neue Version.

Ich habe eine Platine V1.3, meiner Erinnerung nach aus der allerersten Serie (stehende LED Treiber).
Mit OTA Update war da leider nichts zu machen, auch nicht über die curl Tricks aus der Linux Shell. In der Web GUI hat mir der Controller sofort einen "Netzwerkfehler" gemeldet. Via curl ist er mal länger mal kürzer auf "ota ongoing" gegangen, hat aber immer den alten Stand behalten.

so einen hatte ich auch schonmal, und kann nicht sagen, was da los ist.

So ging es mir auch, aber auch mit der neueren Hardware (SMD Transistoren). Ich habe alle Controller der Reihe nach seriell geflashed. Nur beim allerersten Controller (alter Stand) hat es tatsächlich über das GUI mit geänderter OTA URL funktioniert. Jetzt laufen alle mit der neuen Software (noch die AD87 Version, noch nicht die allerneuste). Die Variante mit der wget Anfrage zum Anstoßen des Updates war in keinem einzigen Fall erfolgreich. Nach dem vermeintlichen Update startete der Controller nicht von alleine neu und hatte dann auch keine neue Software drauf.

Ich habe ihn dann schließlich via Kabel geflasht und nach dem üblichen Drama, das Ding in den Flash-Modus zu bekommen, hat der Update auch funktioniert.
Danach waren die Einstellungen weg, was ich erwartet hatte. Nicht erwartet hatte ich aber, dass der AP nun per Default ein Passwort benötigt. Das ist dann auch nur hier in einem Post zu finden - ganz schön gemein  . Für andere wäre es sicher hilfreich, das hier im ersten Post und in Github noch zu wiederholen.

Password braucht der AP eigentlich immer schon, aber Du hast recht, ich sollte es nochmal irgendwo vermerken.

Also ich wurde von der alten Software (vbs) noch nie nach einem Passwort für den WLAN AP gefragt! Das passierte mit der neuen V5 das erste mal und auch ich habe längere Zeit gesucht, um das Passwort hier zu finden.

Eine Kleinigkeit ist mir noch aufgefallen: Ich habe manuell einen Hostnamen vergeben. Der wurde mir aber zweimal überschrieben und zwar mit dem Devicename aus FHEM. Da scheint irgendwas zu aktualisieren, was nicht soll.

das fhem modul kann den Hostnamen überschreiben, das stimmt, tut es das? @vbs?

Auch das ist mir ebenfalls passiert! Ganz klar wird der Hostname von fhem überschrieben, aber offenbar nicht immer. Unter welchen Bedingungen das passiert oder durch was es ausgelöst wird, ist mir nicht klar. Es führt jedenfalls zu Verwirrung.

Apropos Verwirrung: Die Maske zum Setzen der WLAN Zugangsdaten fragt zweimal nach der SSID, in Wirklichkeit ist das zweite SSID Feld aber das Passwort für das WLAN. Außerdem ist mir nicht klar, wie und wann diese Daten übernommen werden. Ich brauchte jedes mal mehrere Versuche bis der Controller sich dann mit dem WLAN verband. Soll das nach der Eingabe des Passworts von selbst passieren oder muss ich unten auf den grünen Haken tippen oder noch was anderes?

[weini]

das fhem modul kann den Hostnamen überschreiben, das stimmt, tut es das?

Ja, genau! Das kam für mich unerwartet. So etwas über einen Set-Befehl anzubieten fände ich gut. Es "automatisch" zu tun ist überraschend.

Auch das ist mir ebenfalls passiert! Ganz klar wird der Hostname von fhem überschrieben, aber offenbar nicht immer. Unter welchen Bedingungen das passiert oder durch was es ausgelöst wird, ist mir nicht klar. Es führt jedenfalls zu Verwirrung.

Ich habe mittlerweile das Attribut "deviceName" auf den FQDN gesetzt. Seitdem überschreibt er den Hostname auf dem Controller nicht mehr. Sieht für mich gut aus, sollte man nur noch dokumentieren (habe zumindest in der Hilfe nichts dazu gefunden).

Meine Farbrotation geht aktuell wohl auch noch nicht. Die starte ich in FHEM durch "set led_Bartresen hsv +5,100, 120 r", da ändert der Controller aber keine Farben.

[vbs]

das fhem modul kann den Hostnamen überschreiben, das stimmt, tut es das? @vbs?

Puhh, ist ein paar Jahr her, aber so aus dem Kopf würde ich sagen: kann es nicht (und tut es nicht). Also zumindest die vbs-Variante.

[pjakobs]

So ging es mir auch, aber auch mit der neueren Hardware (SMD Transistoren). Ich habe alle Controller der Reihe nach seriell geflashed. Nur beim allerersten Controller (alter Stand) hat es tatsächlich über das GUI mit geänderter OTA URL funktioniert. Jetzt laufen alle mit der neuen Software (noch die AD87 Version, noch nicht die allerneuste). Die Variante mit der wget Anfrage zum Anstoßen des Updates war in keinem einzigen Fall erfolgreich. Nach dem vermeintlichen Update startete der Controller nicht von alleine neu und hatte dann auch keine neue Software drauf.

Ich kann nur vermuten, dass das ein Fehler in der OTA Komponente ist. Damit hat mein Code wenig zu tun, der übergibt einfach eine URL und rebootet, wenn der Flash Bereich erfolgreich geschrieben wurde (so ungefähr).
Wenn dazwischen was schief geht, dann funktioniert das OTA Update nicht. Es kann sein, dass das Update nicht korrekt heruntergeladen werden konnte, dass es nicht korrekt geschrieben werden konnte oder dass beim Reboot was schief ging.
Ich muss mir das bei Gelegenheit mal ansehen.

Also ich wurde von der alten Software (vbs) noch nie nach einem Passwort für den WLAN AP gefragt! Das passierte mit der neuen V5 das erste mal und auch ich habe längere Zeit gesucht, um das Passwort hier zu finden.

auch die alte Version hatte mit großer Sicherheit ein Password auf dem Accesspoint, den Teil des Code habe ich nicht geändert. Aber: sobald das mal eingegeben worden ist, behält sich das Endgerät die SSID/Password Kombi. Ich glaube, der richtige Weg ist, das sauber zu dokumentieren.

Apropos Verwirrung: Die Maske zum Setzen der WLAN Zugangsdaten fragt zweimal nach der SSID, in Wirklichkeit ist das zweite SSID Feld aber das Passwort für das WLAN. Außerdem ist mir nicht klar, wie und wann diese Daten übernommen werden. Ich brauchte jedes mal mehrere Versuche bis der Controller sich dann mit dem WLAN verband. Soll das nach der Eingabe des Passworts von selbst passieren oder muss ich unten auf den grünen Haken tippen oder noch was anderes?

Du hast völlig recht, damit hab ich mich selbst schon verwirrt, da muss ich das UI ein bisschen verbessern.
Die Felder sind, von oben nach unten:

• ein Dropdown Selector mit allen WIFI SSIDs, die der Controller gefunden hat
• ein Freitext Feld, um sich mit einem nicht sichtbaren Netz verbinden zu können
• das zugehörige Password (wann sich da eingeschlichen hat, dass das Feld SSID heißt weiß ich nicht, fällt mir gerade zum ersten mal auf! dafür sind Tester gut )
  

Auf die Seite gehört auch noch ein "connect" Button. Mach ich in einem Aufwasch.

Der grüne Haken unten rechts ist kein Action Button, sondern zeigt lediglich den Zustand der Websocket Verbindung an. Da mach ich noch ein Tooltip dran.

Ja, genau! Das kam für mich unerwartet. So etwas über einen Set-Befehl anzubieten fände ich gut. Es "automatisch" zu tun ist überraschend.

Ich habe mittlerweile das Attribut "deviceName" auf den FQDN gesetzt. Seitdem überschreibt er den Hostname auf dem Controller nicht mehr. Sieht für mich gut aus, sollte man nur noch dokumentieren (habe zumindest in der Hilfe nichts dazu gefunden).

mir fehlt im Moment die Zeit, mir das fhem Modul auch noch anzusehen. Vielleicht kann das wer anderes machen?

Meine Farbrotation geht aktuell wohl auch noch nicht. Die starte ich in FHEM durch "set led_Bartresen hsv +5,100, 120 r", da ändert der Controller aber keine Farben.

hmm... und auf Controllern mit der alten Firmware funktioniert das?
Das triggert drei Stellen im Code, an einer hab ich was getan:

• jsonprocessor.cpp - da werden json Messages verarbeitet.
  
  • einen Bug in der Verarbeitung von Messages gefixt, die mehr als einen Befehl beinhalten und den dafür verfügbaren Speicher etwas vergrößert
  • die Anzahl der Meldungen wenn sich die Farbe verändert auf 2/s verringert.
  beides sollte so eine einfache Operation nicht stören.
  
  • ledctrl - hier werden die eigetlichen Aktionen für die LED gesteuert - da habe ich außer der Umstellung auf named channels nichts geändert. Und wenn andere Animationen funktionieren, dann sollte das auch für Rotation gelten
  • RGBWWLed - die Library, die die ganze Farbraumkonversion und das eigentliche Ansteuern der PWM Kanäle übernimmt. Da habe ich ein paar große statische Tabellen vom Heap in's PGM Mem verschoben, aber auch das sollte nicht eine einzelne Animation stören.
  kurz: seltsam.
  
  

[pjakobs]

und: die neuen Prototypen sind da!

[pjakobs]

ich hab für das "failing OTA" mal ein Issue aufgemacht - aaaber: was immer da passiert, passiert im alten Code, mit altem SMING. Ich weiß, dass sich auch im OTA manches geändert hat, ich kann mir vorstellen, dass es da noch bugs gibt, aber im Grunde ist es für mich wertlos, danach zu suchen, denn damit die gefixt werden können, muss der Controller ja sowieso auf die neue Firmware geflasht werden.
Ich werde aber mal sehen, ob ich vielleicth mehr Status Reporting für das aktuelle OTA einbauen kann, falls sowas da auch mal passiert.

Die UI issues im Network Config hab ich gefixt, ship' ich dann mit dem nächsten dev build