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?