ESP RGBWW Controller - Firmware v5

[Mafi]

Guten Morgen!

Tests haben ergeben, dass du richtig liegst mit deinen Vermutungen.
Beide Probleme sind auch mit der neuen Firmware vorhanden, weil der Fehler gar nicht in der Firmware liegt! Das fhem Modul ESPLedController ist fehlerhaft! Andere RGBWW Platinen zeigen nämlich mit älterer Firmware genau dasselbe Verhalten, wenn ich sie RAW ansteuere.
Das bedeutet, der Fade, den ich vermisse, kommt nicht aus dem Controller selbst, sondern wird vom fhem Modul eingefügt. Wie von dir vermutet. Ebenso wird dort das RAW Kommando falsch zusammengebaut, sodass führende leere Einträge in der Kanalliste als 0 gesetzt werden.
Ich muss mal aus meinen Backups die Vorgängerversion des Moduls rauskramen und testen. Wird ziemlich sicher dann wieder gehen.
Sorry, dass du dich jetzt umsonst auf die Suche begeben hast.

Grüße
Markus

[pjakobs]

Guten Morgen!

Tests haben ergeben, dass du richtig liegst mit deinen Vermutungen.
Beide Probleme sind auch mit der neuen Firmware vorhanden, weil der Fehler gar nicht in der Firmware liegt! Das fhem Modul ESPLedController ist fehlerhaft! Andere RGBWW Platinen zeigen nämlich mit älterer Firmware genau dasselbe Verhalten, wenn ich sie RAW ansteuere.
Das bedeutet, der Fade, den ich vermisse, kommt nicht aus dem Controller selbst, sondern wird vom fhem Modul eingefügt. Wie von dir vermutet. Ebenso wird dort das RAW Kommando falsch zusammengebaut, sodass führende leere Einträge in der Kanalliste als 0 gesetzt werden.
Ich muss mal aus meinen Backups die Vorgängerversion des Moduls rauskramen und testen. Wird ziemlich sicher dann wieder gehen.
Sorry, dass du dich jetzt umsonst auf die Suche begeben hast.

Grüße
Markus

kein Ding, schön, dass Du's gefunden hast.

Aber wie gesagt: die Funktion eines "default fade" will ich auch in der Firmware einbauen, weil's einfach schöner ist.

[pjakobs]

Im Moment habe ich echte Probleme mit den develop und experimental Versionen, es scheint mit der Anzahl freier TCP Verbindungen zusammenzuhängen, aber genau weiß ich es nicht.
Aktuell solltet Ihr nicht auf die neuen (700er) Versionen updaten.
Ich melde mich, wenn's besser wird

[pjakobs]

so, ich glaube, die V5.0.0-807-develop ist wieder okay.

Du darfst diesen Dateianhang nicht ansehen.

Das Problem war scheinbar, dass ich im Controller zu aggressiv gecached habe, jetzt nutze ich cache-busting im Vue/vite build Prozess, was dafür sorgt, dass jetzt alle Objekte, die nachgeladen werden einen eindeutigen String pro Build angehängt bekommen (siehe Anhang). Die Dateien sehen dann so aus:

Code Auswählen Erweitern

/assets/index-DjEmwXxm.js
/assets/index-BdtixC0s.css
und wenn es einen neuen Build gibt, dann verändert sich der String, so dass der Browser Cache automatisch ein neues Dokument zieht, aber innerhalb eines Build die Datei gecached wird.
Nebenbei ist die CI für die Firmware jetzt deutlich ausgeweitet, inclusive valgrind checks, um eventuell neue Memory Leaks zu finden.
Ich arbeite gerade daran, dass API fast komplett aus dem http server heraus zu nehmen und in eine eigene Klasse zu packen, auf die Weise ist das API dann über HTTP, MQTT und Websocket nahezu 100% deckungsgleich, das Frontend wird das nutzen, um die Kommunikation mit dem Controller über Websocket abzuwickeln. Das sollte, besoders auf dem ESP8266 dazu führen, dass es seltener zu Verbindungsabbrüchen wegen vollständig benutzter TCP Verbindungen kommen wird.

[pc1246]

Moin
Jetzt habe ich doch wirklich mal wieder Zeit gefunden mich diesem Thema zu widmen.
Irgendwie meinte ich ja vor einem Jahr, dass ich hier mitlesen wollte, habe ich aber nicht.
Irgendwie war ich aber auch schon ewig nicht im Forum.
Mein Problem ist jetzt, dass ich auf irgendeiner sehr alten Ursprungsversion bin, und OTA nicht updaten kann.

Code Auswählen Erweitern

Firmware 4.3.1-rc1
Web Interface 0.3.3-shojo7
RGBWW Version 0.9.0
SMING Version 4.0.0 Die Variante von Rippi in https://forum.fhem.de/index.php?msg=1350784 hat auch nicht geklappt:

Code Auswählen Erweitern

C:\Users\Christoph>curl -X POST http://192.168.178.243/update -H 'Content-Type: application/json' --data '{"rom": {"url": "http://lightinator.de/download/develop/V5.0-503-develop/esp8266/debug/rom0.bin"},"spiffs": {"url": "http://rgbww.dronezone.de/testing/spiff_rom.bin"}}'
{"error":"could not parse HTTP body"}curl: (6) Could not resolve host: application
curl: (3) unmatched brace in URL position 1:
{url:
 ^Ueber fhem wollte er auch nicht, da stand er ueber eine Stunde im OTA active, bis ich ihn spannungslos gemacht habe.
Muss ich den jetzt wirklich seriell flashen?
Danke und Gruss
Christoph

[pjakobs]

Moin Christoph,

sorry, das das so lange gedauert hat, ich war unterwegs.

4.3.1-rc1 ist ja so alt nicht, ich galube, dass das OTA danach bis zur 5.0 nicht mehr angefasst wurde.

Dein json sieht okay aus,

Code Auswählen Erweitern

{
  "rom": {
    "url": "http://lightinator.de/download/develop/V5.0-503-develop/esp8266/debug/rom0.bin"
  },
  "spiffs": {
    "url": "http://rgbww.dronezone.de/testing/spiff_rom.bin"
  }
}

die Fehlermeldung ist verwirrend:

Code Auswählen Erweitern

{"error":"could not parse HTTP body"}
das sieht nach einer Fehlermeldung des Controllers aus - das ist ein "bad request"

Code Auswählen Erweitern

curl: (6) Could not resolve host: application
curl: (3) unmatched brace in URL position 1:
{url:

die erste Fehlermeldung kommt sehr sicher hierher:

Code Auswählen Erweitern

        String body = request.getBody();
        if (body == NULL) {
            sendApiCode(response, API_CODES::API_BAD_REQUEST, F("could not parse HTTP body"));
            return;
        }

das ist ein leerer Request Body

die weiteren Teile kommen von curl - ich seh's noch nicht, aber irgendwas an Deiner curl Zeile stimmt nicht, Dein Rechner  sendet eine leere Anfrage und curl versucht dann mit dem Rest der Zeile irgendwas anzufangen.


bei mir funktioniert die gleiche Zeile allerdings -

Code Auswählen Erweitern

$ curl -X POST http://192.168.29.101/update -H 'Content-Type: application/json' --data '{"rom": {"url": "http://lightinator.de/download/develop/V5.0-503-develop/esp8266/debug/rom0.bin"},"spiffs": {"url": "http://rgbww.dronezone.de/testing/spiff_rom.bin"}}'
{"success":true}

Die curl fehlermeldung "could not resolve host" lässt mich vermuten, dass irgendwie das "application/json" als host portion gelesen wurde, dann das "unmachted brace position.." - irgendwas stimmt mit dem Quoting in Deiner ursprünglichen Zeile nicht. Führst Das auf einer Linux Shell aus? Die Backslashes im Prompt lassen mich Windows befürchten, und da weiß ich nicht, ob ' und " genauso interpretiert werden wie unter Linux.

Wenn Du die Möglichkeit hast, führ doch die gleiche curl Zeile mal auf Linux aus, das sollte m.E. funktionieren

Grüße

pj

[vbs]

Die Variante von Rippi in https://forum.fhem.de/index.php?msg=1350784 hat auch nicht geklappt:

Code Auswählen Erweitern

C:\Users\Christoph>curl -X POST http://192.168.178.243/update -H 'Content-Type: application/json' --data '{"rom": {"url": "http://lightinator.de/download/develop/V5.0-503-develop/esp8266/debug/rom0.bin"},"spiffs": {"url": "http://rgbww.dronezone.de/testing/spiff_rom.bin"}}'
{"error":"could not parse HTTP body"}curl: (6) Could not resolve host: application
curl: (3) unmatched brace in URL position 1:
{url:
 ^

Das scheint ein curl-Aufruf von Linux zu sein, der unter Windows ausgeführt wird? Soweit ich weiß läuft unter Windows das Quoting anders. Also den Linux-Befehl kann man syntaktisch nicht 1:1 übernehmen. Also Single-Quotes kennt Windows-cmd erst einmal nicht. Könnte man evtl. so ersetzen:

Code Auswählen Erweitern

curl -X POST http://192.168.178.243/update -H "Content-Type: application/json" --data "{\"rom\": {\"url\": \"http://lightinator.de/download/develop/V5.0-503-develop/esp8266/debug/rom0.bin\"},\"spiffs\": {\"url\": \"http://rgbww.dronezone.de/testing/spiff_rom.bin\"}}"

[pc1246]

@vbs
Danke, das hat in Theorie funktioniert.
Die Linux Version aus Linux heraus natuerlich auch.
Leider mag der Controller nicht updaten. Dann hole ich den mal aus der Ecke raus, wenn ich Lust habe.
Danke und Gruss
Christoph

[pjakobs]

@vbs
Danke, das hat in Theorie funktioniert.
Die Linux Version aus Linux heraus natuerlich auch.
Leider mag der Controller nicht updaten. Dann hole ich den mal aus der Ecke raus, wenn ich Lust habe.
Danke und Gruss
Christoph

bekommst Du eine Fehlermeldung?
Ich habe glaube ich ein oder zwei mal Controller gesehen, die partout kein OTA Update machen konnten, so ganz habe ich das nicht analysieren können, und weil die neue Version ja auch einen überarbeiteten OTA Prozess hat, habe ich mich da nicht so reingefummelt.

Kannst Du sehen, ob der Fehler beim Download passiert oder ob der Controller versucht, die neue Version zu starten, das aber nicht funktioniert?

pj

[pc1246]

@Peter
Jetzt muss ich mich entschuldigen, einfach keine Zeit gehabt!
Nein es gab nichts, nur die OTA Meldung.
Jetzt hab ich in seriell geflasht. Zum Glueck habe ich das hier: https://forum.fhem.de/index.php?msg=949024 gefunden.
Da ich natuerlich nicht wusste, wie ich den in den Flashmodus bekomme.
Jetzt ist er erstmal wieder da, und bei Gelegenheit schaue ich mir das naeher an.
Gruss und schoene Pfingsten weiterhin
Christoph

[pjakobs]

So, riesen Änderung:

Ich hatte ja am Anfang entschieden, die Webapp in die eigentliche Firmware einzubauen (als Flash Strings, also direkt im Flash Binary). Mit den letzten Änderungen ist das ganze Binary trotz aller Tricks größer geworden, als meine ROM Partitionen zulassen, also musste ich mir was anderes überlegen.
Was ich nicht wollte ist, wie die Version 4 der Firmware, jedesmal die Filesystem Partition überschreiben, denn da liegt auch die ganze Konfiguration.
Der Weg, den ich jetzt gehe ist:
- die Firmware kommt mit einem extrem minimalen UI, das nur die Verbindung zum WIFI übernimmt.
- sobald die Firmware im WIFI ist, fragt sie auf Lightinator.de nach, ob es eine neue Webapp gibt, dafür hat Lightinator extra ein neues API bekommen
- die Firmware läd dann die Webapp von Lightinator.de in das lokale Dateisystem, startet neu und ab da ist das UI wie üblich zu erreichen.

Kleiner Wermuthstropfen: die HTML Dokumente aus dem Dateisystem zu liefern scheint mehr RAM zu verbrauchen als aus dem ROM, es kommt leider immer wieder dazu, dass einzelne Files nicht beim ersten Mal geladen werden. Der Controller antwortet dann mit einem "Too many connections" und einem Back Off Value, der Client sollte es dann nach ein paar Sekunden nochmal versuchen.
Leider habe ich ein paar mal schon gesehen, dass vor allem die Icons nicht angezeigt werden.

Großer Vorteil: jetzt können Webapp Versionen auch unabhängig von der Firmware ausgeliefert werden und ich hab wieder 300kB Platz für Firmware Funktionen

Das ganze gibt's im Moment nur im "Experimental" Branch - und auch nur für die Mutigen - nicht mal ich hab bisher alle Leuchten auf die Version upgedatet, sie ist also noch nicht wirklich getestet.

[pjakobs]

kurzes Update: ich habe einen Bug behoben, durch den alte Webapp Versionen nicht vollständig gelöscht wurden, dadurch ist das Dateisystem vollgelaufen und der Controller war zwar noch funktionsfähig, aber nicht mehr upzudaten. (das Webapp OTA läd die neue Version erst in einen Staging Bereich und verschiebt sie nur dann in den aktiven Bereich, wenn sie vollständig übertragen worden ist. Dazu werden auch md5 Summen der Dateien überprüft.).
Weil ich gehashte Dateinamen verwende (zum Cache Busting), überschreiben neue Dateien nicht die bestehenden. Wenn die staging Version also nicht gelöscht wird, dann wächst die Anzahl der Dateien im Staging Bereich halt an, bis das Filesystem voll ist.
Jetzt löscht der Code den Staging Bereich nachdem die Webapp erfolgreich aktiviert wurde.

Es gibt noch einen Bug, der dazu führt, dass manchmal der Haupt Teil der Applikation (also alles rechts des Menüs) nicht dargestellt wird - das scheint ein caching Ding zu sein, ich bin noch nicht sicher. Shift-Reload hilft.

[pjakobs]

die Experimental Version wird langsam stabiler.
Auf dem Esp8266 ist ein Hauptproblem immer noch, dass ich viel RAM brauche (gut, vor einem halben Jahr habe ich den verfügbaren freien RAM auf ca. 27kB hochgedreht, aber den nutze ich jetzt auch wieder, so dass ungefähr 20kB frei sind)

Was neu ist:
- die Kommunikation zwischen Webapp und Firmware ist jetzt fast vollständig auf websocket umgestellt
- Firmware und Webapp sind voneinander getrennt, damit habe ich wieder ca. 300kB Flash für weitere Funktionen zur Verfügung (wenn, ja wenn der RAM ausreicht)
- trotz der RAM Knappheit ist die Firmware stabiler - auf Kosten der "gefühlten" Geschwindigkeit - alle Netzwerk Interaktionen sind über RAM Gates abgesichert, wenn der nötige Speicher nicht zur Verfügung steht, wird die Funktion nicht aufgerufen und der Client bekommt eine Antwort, (HTTP_ERR429, too many requests) die ihn auffordert, die Anfrage in ein paar Sekunden zu wiederholen.

Die allerwichtigste Veränderung ist aber: das gesamte API ist aus dem Webserver in einen eigenen APIHandler umgezogen, das heißt mqtt, websocket und http können alle (fast) alle API Funktionen ausführen. Das gilt nicht für /data und /config, weil diese direkt von ConfigDB als Stream gehandled werden.

Experimental ist immer noch ein bisschen "rough around the edges" aber durchaus brauchbar.

was mir auffällt ist: nicht alle Browser Reloads sind korrekt, manchmal ist der Controller zu langsam und liefert noch kein Frontend aus, manchmal ist er zu schnell und re-bootet, bevor er den Client informiert hat, dass alle Frontend Files geladen wurden.

Aber: es ist schonmal wert, sich die Version anzusehen.

[pjakobs]

jetzt hab ich eine ganze Weile gebraucht, um zwei hässliche Bugs zu beheben.
- eine endlose Rekursion in "parseJsonBody()" - ich habe alle statischen Strings auf Flash Strings umgestellt (Sming F("<string>") helper Macro) und danach ist die Firmware bei jedem POST Request gnadenlos abgestürzt, natürlich ohne sinnvolle Fehlermeldung, denn es ist ja "einfach" der Stack übergelaufen. Der Fehler war, dass Funktionsaufrufe mit F-String einfach mit dem Typ "const String" und nicht einen Pointer auf den String im Flash. Die Funktion hat dann, statt eine überladene Funktion mit String immer sich selbst aufgerufen. Bäm.
- ein use after free im neuen "invalid json" response path - wenn ein Client ungültiges json schickt, antwortet der Controller mit einer Fehlermeldung `{"error":"Invalid JSON: IncompleteInput"}` - tat er in diesem Fall aber nicht, weil der Speicher wieder aufgeräumt wurde, bevor die Nachricht versandt war.

Ich habe die Experimental jetzt wieder auf einigen Controllern laufen, ein paar Sachen scheinen noch nicht ganz zu funktionieren - unter anderem funktioniert ein <shift><reload> im Browser nicht. Da bin ich noch dran.

Aber: mit all dem lief die Version auf dem Esp8266 immer noch nicht stabil, und ich denke, langsam hab ich das Ende der Fahnenstange für die Plattform erreicht. Zwischen 20 und 28kB nutzbarer RAM sind halt nicht die Welt, wenn man einen ganzen Zoo an Schnittstellen hat. Die Tatsache, dass ich die Webapp jetzt aus dem Filesystem liefere hat das System wieder über die Kante gestoßen.
Klar, bisher waren es einfach Strings im FLASH, das System brauchte quasi keine Buffer sondern hat einfach nur Zeichen aus dem Flash zum Wifi geschoben, jetzt muss es die entsprechenden Blöcke im Dateisystem zusammensuchen, das ist ein bisschen Overhead.

Ich habe für den ESP8266 jetzt die Länge der Animationsqueue von 100 auf 20 Einträge gekürzt - ich weiß nicht, ob jemand mehr nutzt. Da die Queues beim Erstellen des RGBWWLed Objekts angelegt werden, und das gleich für neun Kanäle (R, G, B, WW, CW, H, S, V und CT, glaube ich) spare ich mir damit fast 3,9kB Heap. Das rettet den 8266 erstmal wieder.

Für die Zukunft muss ich mir aber überlegen, wie ich damit umgehen will, mehr Funktionalität auf der Platform wird nur noch im Frontend möglich sein.

Da gibt's jetzt übrigens mehrsprachige Versionen (Deutsch, Englisch, Französisch, Spanisch, Italienisch und Portugiesisch - alles per KI übersetzt aber soweit ich diese Sprachen verstehe sieht das ganz okay aus)

Wer auf die aktuelle Experimental Firmware geht, der bekommt, per default, in Zukunft immer alle aktuellen Neuerungen im Frontend - solange sie mit der Firmware kompatibel sind.

Als nächstes werde ich mich aber einer anderen Sache zuwenden:
Ich habe vor kurzem ziemlich coole und bezahlbare LED Hardware auf ESP32 Basis gefunden https://quinled.info/

dort gibt es für knapp 50€ einen extrem gut aufgebauten Controller mit ESP32 und 15 PWM Kanälen - das ist genau die Hardware, die ich immer haben wollte.
Die nächste wesentliche Änderung wird es also sein, die Firmware so aufzubohren, dass sie bis zu 15 unabhängige Kanäle als eine Anzahl "virtueller Leuchten" anbieten kann.

Ich stelle mir dabei vor, die Farbmodelle zu ändern:

• Einzelfarbe
• Weiß mit Farbtemperatur (WW/CW - zwei Kanäle)
• RGB
• RGBWW
• RGBCW
• RGBWWCW

und davon sollen sich dann in der Firmware so viele anlegen lassen, wie PWM Kanäle verfügbar sind, auf dem ESP32 also bis zu 15. In beliebigen Kombinationen. Also vielleicht ein RGBWWCW und 10 einzelne Schmuckfarben (es gibt da diese 2mm breiten einfarbigen Streifen)
Das wird eine ziemliche Änderung an der RGBWWLed Library, aber ich glaube, es wird nicht so wahnsinnig viel.
Aber wie gesagt: das wird Esp32 only.

What could possibly go wrong?

[pjakobs]

Man mag es ja nicht glauben, zwei Wochen hab ich einen Bug gesucht, der dazu geführt hat, dass er Controller, auf dem ich neue Builds in Produktion teste alle paar Minuten neu gestartet ist und es wurde scheinbar mit jeder Version schlimmer.
Gestern habe ich dann genau diesen Controller gegen einen anderen ausgetauscht, weil ich mir wirklich keinen Rat mehr in der Software wusste und siehe da, jetzt funktioniert er wieder.
Ich hab mir die Hardware noch nicht angeschaut, aber ich habe den Verdacht, dass die Spannungsversorgung ein Problem hat. (es ist ein Controller, den ich mit 24V betreibe und der ungefähr 10m LED Leiste steuert)
Aktuell ist die Experimental 964 die neueste Version und die scheint ganz gut zu funktionieren.
Der Experimental Branch bringt ja primär zwei Änderungen:

• die eigentliche API Implementierung ist vom Webserver in eine apihandler Klasse umgezogen und ist damit fast 100% funktionsgleich über mqtt, websocket und http erreichbar, was die aktuelle Webapp auch nutzt, um über Websocket mit dem Controller zu kommunizieren.
• die Webapp musste das Flash Segment verlassen und liegt jetzt als einzelne Dateien im Dateisystem
  
  • beim ersten Start werden alle nötigen Datein von http://lightinator.de übertragen, währenddessen sieht der Nutzer eine Fortschritsanzeige
  • bei jedem Reboot wird, in der default Einstellung, geschaut, ob es eine neue Webapp gibt und wenn ja, wird automatisch upgedatet. Das passiert über einen staging Bereich, d.h. wenn der Controller etwa während des Updates neu gestartet wird, dann bleibt das alte UI weiterhin funktional, er läd nach dem Neustart die fehlenden Dateien weiter und tauscht die Webapp erst nach vollständigem, korrektem Epmfang aller Dateien
  • es gibt in den System Settings einen eigenen Bereich "Webapp Update", in dem der Nutzer auch manuell ein Update anstoßen kann. Da stimmt irgendwas mit der Logik noch nicht, aber es funktioniert
• dazu hab ich wieder an vielen Stellen versucht, wertvollen Speicher einzusparen und das System robuster zu machen.
  
  • Alle API Aufrufe sind jetzt von Heap Guards umgeben und schicken, wenn nicht genug HEAP zur Verfügung steht ein "temporarily unavailable" an den Client, damit der es später nochmal versucht.
  • das Web Frontend hat jetzt auch ein paar Modifikationen, damit es weniger einzelne Dateien braucht, und bei Fehlern nach einer Zeit einen neuen Anlauf startet

Was mir noch nicht gefällt:

• der Esp8266 ist einfach am Ende seiner Möglichkeiten, ich muss die Anzahl der gleichzeitig verfügbaren TCP Verbindungen extrem einschränken was dazu führt, dass manchmal das Web Frontend sehr langsam läd oder gar keine Verbindung zustande kommt.
  Das ist aber leider ein Problem der geringen Ressourcen des Esp8266
• der neue Konfigurationsflow (wenn der Controller ganz frisch ist bzw noch keine Netzwerkverbindung hat) bringt den Nutzer zwar in das WebUI (nachdem es von Lightinator.de geladen wurde) aber idealerweise würde es zum Network Init Flow springen - das sollte einfach sein.
• das ganze Szenen und Presets Management ist gerade ein halber Trümmerhaufen, darüber muss ich nochmal grundlegend nachdenken.

Ich werde jetzt mal die experimental Version auf alle meine Controller ausrollen und wenn ich dann nicht zu viele Tage im Dunkeln sitze, dann wird sie, denke ich, zur develop befördert.
Neben den UI Verbesserungen (vor allem Gruppen, Szenen und Presets) werde ich mir dann Gedanken machen müssen, wie ich die Branches für Esp32 und Esp8266 deutlicher trenne, denn wie gesagt: mehr dürfte auf dem 8266 kaum mehr machbar sein.