ESP RGBWW Wifi Led Controller - Firmware

[pjakobs]

Ein eigener Thread für alle Themen rund um die Firmware des RGBWW Controllers

https://github.com/patrickjahns/esp_rgbww_firmware

[pjakobs]

um mal eben meine Wünsche an die Firmware zusammenzutragen:

• Einfaches Bündeln / Abtrennen von Kanälen
  Was ich mir vorstelle ist eine Architektur, in der ich Gruppen von Kanälen (5x einzeln, RGB +2x einzeln, RGBWW +1x einzeln, RGBCW +1x einzeln, RGBWWCW) belegen und diese einzeln addressieren kann. Meine Idee wäre, dass ich mich quasi mit meinem Bedarf beim Controller anmelde (ich will RGBWW machen!) und der Controller mir die vier nötigen Kanäle zuweist. Identifizieren könnte sich der client (also das fhem Modul) dann z.B. mit einem eindeutigen Cookie aus dem sich die Kanalzuweisung (Modus, Kanalnummern) ableiten lässt. Ich glaube, dass @vbs in seiner Version schon eine wesentliche Grundlage dafür geschaffen hat: er hat Queues für die einzelnen Kanäle aufgetrennt, jeder Kanal kann also da schon unabhängig von den anderen faden.
  Idealerweise würde diese Änderung auch die Möglichkeit beinhalten, die Anzahl noch freier Kanäle abzufragen.
• Synchronisation mehrerer Controller (idealerweise außerhalb von fhem)
  Oft und kontrovers diskutiert: @vbs hat einen Patch für das fhem Modul geschrieben, der es ermöglicht, auf API Ebene Befehle an mehrere Controller zu senden und diese ggf. auch noch zu transformieren (also Farbe / Helligkeit / Sättigung in Abhängigkeit vom Master zu verändern). Die Idee finde ich gut, die Implementation im Modul gefällt mir weniger, meines Erachtens sollte das eine Funktion des Controllers sein.
  Ich würde hier eine Lösung über MQTT bevorzugen, einfach, weil das am wenigsten Komplex ist. UDP Broadcast / Multicast wird immer ein Problem in der Netzwerkkonfiguration sein (auch wenn man vielleicht davon ausgehen kann, dass die übergroße Mehrheit der Anwender die Controller alle im gleichen Netz einsetzt). MQTT hat genau einen Broker, der läuft bei vielen fhem Usern sowieso schon auf dem Raspi mit. MQTT erzeugt vielleicht auch etwas mehr Netzwerktraffic, aber ich sehe eigentlich nicht, dass das überwältigend viel werden würde. Zuletzt denke ich, dass sich mit Dingen wie NodeRed MQTT so oder so zum IoT Standard mausern wird und wir da auf einen fahrenden Zug aufspringen (man könnte sowas wie NodeRed sogar verwenden, um basierend auf den Controllern noch wesentlich aufwendigere Dinge zu machen, manche reden immer vom Disco Mode, ich denke gerade an einen Controller, der z.B. Information über die gerade laufende Musik an NodeRed liefert (per MQTT) und darüber die Beleuchtung steuert. Irgendwo von "ich nehme den mp3 Style Tag und mache ein Moodlight daraus" bis hin zu "ich mache eine Fourieranalyse der Musik und nutze mehrere Controller als Ausgabemedium"

[thorwin]

Fehlt mir hier irgendetwas oder mach ich grundsätzlich was falsch?
Entschuldigt bitte die vielleicht dummer Frage aber ich habe noch nicht so viel Erfahrung rund um FHEM.

Hast du das JSON-Modul installiert? Für debian/raspbian:

Code Auswählen Erweitern

# apt-get install libjson-perl

[vbs]

Ist das Problem noch aktuell? Konfiguration würde ich ausschließen, ehrlich gesagt. Hätte jetzt auch auf das fehlende Perl-Modul getippt. Oder zumindest irgendwas aus der Ecke. Hast du FHEM schonmal neu gestartet nach Installation des Moduls?

Ich fürchte, du bist hier mit dem Thema im Firmware-Thread etwas offtopic, ich würds mal eher hier im Modul-Thread probieren:
https://forum.fhem.de/index.php/topic,55065.0.html

[Kuse]

Hallo vbs,
ja...ist leider noch aktuell. Danke für den Hinweis, ich versuche mal dort mein Glück. Entschuldigt bitte das OT hier.

VG

[lewej]

Hallo Zusammen,

wenn man die Controller vom Strom trennt, dann wird ja der letzte Zustand gespeichert und beim wieder einschalten wieder auf Ursprungsfarbe gesetzt.
Wäre es machbar, das man in die Firmware folgende Punkt einbaut?

- Standard Farbe definieren, ist diese gesetzt, wird nach wiedereinschalten immer diese Farbe gesetzt
- ist keine Standard Farbe definiert, wird immer die zuletzt ausgewählte Farbe wieder gesetzt

Grund, Family spielt immer wieder gerne mit den Farben rum.

Gruß
lewej

[pjakobs]

Hallo Zusammen,

wenn man die Controller vom Strom trennt, dann wird ja der letzte Zustand gespeichert und beim wieder einschalten wieder auf Ursprungsfarbe gesetzt.
Wäre es machbar, das man in die Firmware folgende Punkt einbaut?

- Standard Farbe definieren, ist diese gesetzt, wird nach wiedereinschalten immer diese Farbe gesetzt
- ist keine Standard Farbe definiert, wird immer die zuletzt ausgewählte Farbe wieder gesetzt

Grund, Family spielt immer wieder gerne mit den Farben rum.

Gruß
lewej

der Controller kommt, wenn der Strom abgeschaltet wurde, in dem Zustand zurück, in dem er vorher war.

Die Standard Farbe ist im Modul durch die entsprechenden Attributes definiert.

Deine Familie liegt außerhalb des Scopes dieses Projektes

pj

[Blauhorn]

Hallo zusammen,

ich habe mir entsprechend der Hardwareliste außerhalb der Sammelbestellungen die Einzelteile für zehn Controller zusammengestellt, ist auch alles angekommen. 2 Geräte habe ich bereits zusammengelötet. Das  hat Dank der Lötanleitung von Peter Jakobs auch wunderbar geklappt, und sogar trotzdem ich in meiner Bekanntschaft als Lötmuffel gelte, und bisher eher Klumpen als saubere Lötstellen hinbekommen habe.  Das Flashen ging nach ein paar Startschwierigkeiten dann auch irgendwann.
Jetzt laufen die beiden Controller sauber im Fhem, alles in Allem ein unglaublich tolles Projekt.

Frage:
Der Controller summt (wahrscheinlich im PWM-Takt). Je stärker ein Kanal aufgerissen wird, desto lauter. Also im RAW-Mode deutlich hörbar und deutlich vom Controller, nicht vom Netzteil.
Ich muss aber dazu sagen, dass ich C1 mit 330 µF bestückt habe. Kann das sein, dass das zu wenig ist? Was kann ich gegen das Geräusch tun, könnte z.B. in der Firmware die PWM-Frequenz erhöht werden, dass der Effekt abgemildert wird?

Gruß
Blauhorn

[pjakobs]

Hallo zusammen,

ich habe mir entsprechend der Hardwareliste außerhalb der Sammelbestellungen die Einzelteile für zehn Controller zusammengestellt, ist auch alles angekommen. 2 Geräte habe ich bereits zusammengelötet. Das  hat Dank der Lötanleitung von Peter Jakobs auch wunderbar geklappt, und sogar trotzdem ich in meiner Bekanntschaft als Lötmuffel gelte, und bisher eher Klumpen als saubere Lötstellen hinbekommen habe.  Das Flashen ging nach ein paar Startschwierigkeiten dann auch irgendwann.
Jetzt laufen die beiden Controller sauber im Fhem, alles in Allem ein unglaublich tolles Projekt.

Frage:
Der Controller summt (wahrscheinlich im PWM-Takt). Je stärker ein Kanal aufgerissen wird, desto lauter. Also im RAW-Mode deutlich hörbar und deutlich vom Controller, nicht vom Netzteil.
Ich muss aber dazu sagen, dass ich C1 mit 330 µF bestückt habe. Kann das sein, dass das zu wenig ist? Was kann ich gegen das Geräusch tun, könnte z.B. in der Firmware die PWM-Frequenz erhöht werden, dass der Effekt abgemildert wird?

Gruß
Blauhorn

Seltsam. Das PWM Signal liegt ja nur auf einer kurzen Strecke zwischen dem ESP, den MOSFET und den Klemmen an, und wenn etwas summt, dann ist es meinstens eine Spule - da ist aber keine.
Die PWM Frequenz liegt auch weit jenseits von 10kHz, also würde ich eher nicht vermuten, dass die es ist.
Bist Du Dir ganz sicher, dass es nicht das Netzteil ist? Meine Netzteile pfeifen auch manchmal, und das ändert sich mit der Last.

pj

[Blauhorn]

Bist Du Dir ganz sicher, dass es nicht das Netzteil ist? Meine Netzteile pfeifen auch manchmal, und das ändert sich mit der Last.

pj

Naja, eigentlich hätte ich auch selbst mal drauf kommen können, das Netzteil zu tauschen, obwohl meine Ohren eine andere Information lieferten.
Das Summen ist mit anderem Netzteil weg, und ich mach mir einen Termin beim HNO.

Gruß
Blauhorn

[fotoniker]

Grüße in die Runde.

Bisher ist die Firmware ja darauf ausgelegt per PWM RGB-LEDs zu Bespielen. Wie würde es aussehen mit Support für WS8201//5050 und so weiter? Ich hoffe ich habe jetzt keinen "was die zukunft bringt" Post übersehen dazu.

Schönen abend euch.

[Per]

Wie willst du die WS denn anschließen? Dieser Controller gibt lediglich ein PWM-Signal, nichts codiertes ab.
Auch bräuchtest du die Endstufen nicht. Wäre also Perlen vor die Säue...

Ein einzelner ESP8266 täte es da auch.

[fotoniker]

Hallo Per danke für deine Antwort,

ich benutze die Firmware in verbindung mit einem ESP. Für normale LEDs mit entsprechendem Mosfet habe aber eben auch einen strpe im Wohnzimmer der allerdings WS2801 verbaut hat. Der wird momentan von einem Pi1 bespielt. Daher das intresse die RGBWW Firmware dahingehend aufzubohren. Für den eigentlichen Controller wäre das natülich blödsinn da kann ich dir nur zustimmen.

[Per]

Zumindest die Signalaufbereitung ist eine völlig andere. Das Interface und damit das Fhem-Device könnte man übernehmen. Zumindest wenn man es kann . Ich kann es nicht.
Ich glaube aber, dass ein solches Device viele Möglichkeiten verschenkt.

[Per]

Ich stell die Frage nochmal hier, weil sie ja eigentlich hierher gehört:

Ich habe öfter das Problem, dass mein WLAN schwach, gestört oder was auch immer ist. Oder der Router rebootet. Dann setzt sich der Controller zurück und spielt wieder AP. Reboote ich den Controller, hängt er sich wieder brav ins richtige Netz.

Besteht die Möglichkeit, im (automatischen, also nicht durch Reset erzwungenen) AP-Modus zu testen, ob das Netz wieder da ist und dann wieder automatisch zurückzukehren? Durch den aktuellen Bug in der ESP-Arduino IDE (der mich einige Nerven gekostet hat!) weiss ich, dass der ESP in der Lage ist, AP UND Client gleichzeitig zu sein. Ich weiss aber nicht, ob es programmtechnisch beherrschbar und vom Speicherplatz her möglich ist.

[Garagenhaus]

Ich möchte demnächst meinen RGBWW aufbauen und bin noch sehr unbedarft was ESP und Firmware angeht. Ich habe ein paar konkrete Fragen:

1. Kann man die Firmware so konfigurieren, dass Sie einen Default Wert für die Farben hat, wenn der Controller eingeschaltet/mit Strom vom Trafo versorgt wird. (Farbe, Helligkeit)?
Hintergrund ist, dass ich gerne ein Verhalten wie Hue oder Tradfri hätte, dass immer Warmweiss volle oder fast volle Leuchtkraft kommt, sobald man den Hue per Unterputz Lichtschalter mit 230V Strom versorgt.

2. Ist das per Webinterface nachträglich zu konfigurieren, oder muss ich das vor dem Flashen im Code ändern?

Sonst müsste ich ja immer mein Smartphone rausholen, wenn ich die Lampe einschalten möchte oder ne Fernbedienung statt dem klassichen Lichtschalter... Wie macht ihr das?

[Per]

Selbst wenn es die Firmware nicht kann, kannst du mittels DOIF abfragen, ob der Controller erreichbar (online) ist, wenn nicht, bekommt er nach der ersten Rückmeldung den von dir gewünschten Zustand von Fhem übermittelt. Eine extra FB oder der Griff zum Handy ist damit nicht notwendig.

[Garagenhaus]

Danke für den Hinweis. Bin FHEM Beginner, sehe aber zwei Probleme:
1. Das Booten des ESP sollte doch sehr schnell (<1 sek) gehen, bis der sich aber ins WLAN hängt, anmeldet und ein Doif Anweisung bekommt dauert wie lange?
2. FHEM ist bei mir nicht produktiv sonder nur Spielweise , ich suche daher eine FHEM-kann, aber nicht muss Lösung.

Gesendet von meinem ONE A2003 mit Tapatalk

[pjakobs]

der On-Wert des Controllers ist der, mit dem er abgeschaltet wurde, sprich: wenn Du das Ding hinter einen Schalter hängst, kannst Du es wie ein normales Licht an- und abschalten.

pj

[Per]

Darf ich nochmal meine Anfrage hochschubsen?

Ich stell die Frage nochmal hier, weil sie ja eigentlich hierher gehört:

Ich habe öfter das Problem, dass mein WLAN schwach, gestört oder was auch immer ist. Oder der Router rebootet. Dann setzt sich der Controller zurück und spielt wieder AP. Reboote ich den Controller, hängt er sich wieder brav ins richtige Netz.

Besteht die Möglichkeit, im (automatischen, also nicht durch Reset erzwungenen) AP-Modus zu testen, ob das Netz wieder da ist und dann wieder automatisch zurückzukehren? Durch den aktuellen Bug in der ESP-Arduino IDE (der mich einige Nerven gekostet hat!) weiss ich, dass der ESP in der Lage ist, AP UND Client gleichzeitig zu sein. Ich weiss aber nicht, ob es programmtechnisch beherrschbar und vom Speicherplatz her möglich ist.

[pjakobs]

Darf ich nochmal meine Anfrage hochschubsen?
[/quote

soweit ich mich erinnere, hat Patrick vor ca einem Jahr genau an der Stelle was geändert, um den Reconnect nach einem Netzwerkverlust robuster zu machen.
Welche Firmware hast Du drauf?

Meine Controller waren zuletzt alle ausgesprochen stabil, bis auf einen, der plötzlich anfing, seine Konfiguration zu verlieren und dann noch nicht einmal per Flash zu bändigen war. Da hab ich den ESP austauschen müssen, um ihn wieder brauchbar zu machen.

pj

[Per]

Welche Firmware hast Du drauf?

Die, die bei den Fertig-Teilen drauf war. Kann ich dir aber heute abend genau sagen.

[pjakobs]

Die, die bei den Fertig-Teilen drauf war. Kann ich dir aber heute abend genau sagen.

aus der letzten Sammelbestellung? Das ist dann die aktuellste.
Ich bin momentan nicht im Land, lass uns nächste Woche mal sehen, ob wir das debuggen können.

pj

[pjakobs]

Moin Firmware Community!

Ich hab gerade einen der neuen Controller getestet, und dabei fiel mir auf: wir haben immer noch den Bug in der White Balance  (float->int Fehler, wenn ich mich recht entsinne) in der Firmware, die als "aktuell" im Github steht
Außerdem habe ich einen Controller, bei dem jetzt schon zum zweiten Mal das SPIFFS ausgefallen ist. Dieser Controller hängt an einem Bewegungsmelder und wird entsprechend häufig geändert. Ich befürchte, dass wir dem Flash da einfach zu viele Schreibzyklen zumuten, weil die Firmware iirc nach jeder Änderung der HSV/RGBWWCW Werte diese im SPIFFS speichert. Ich schlage vor, dass wir hier was ändern:
a) der aktuelle Wert wird nur noch alle x Minuten geschrieben
b) wenn x=0 dann wird er nicht automatisch geschrieben
c) wir fügen einen API Call hinzu, mit dem wir den aktuellen / einen speziellen Wert explizit schreiben können

pj

[vbs]

Ich hab es bei mir in der FW so gemacht, dass der Wert immer geschrieben wird, wenn er für x Sekunden stabil ist. Momentan habe ich das auf 2 Sekunden eingestellt. Bisher noch keinen Ausfall (auch mit BM). Kann das aber nicht abschätzen, wie "ausgeleiert" der Flash jetzt ist. War hauptsächlich dafür gedacht, die Fades etwas zu entlasten.

[pjakobs]

ich hab gerade die original FW nicht zur Hand, weißt Du zufällig, wann dort der Wert geschrieben wird? Sicher doch nicht mit jedem fade Step, sondern nur wenn ein neuer Wert per API gesetzt wird?

Das wäre sonst ja tödlich für den Flash!

pj

[vbs]

Hab es nochmal nachgesehen: beim Original wird immer gespeichert, wenn eine Animation durchgelaufen ist. Also es ist nicht so, dass während des Fades ständig gespeichert wird (sorry, hatte ich falsch im Gedächtnis). Bin trotzdem der Meinung, dass ich eine Konstellation hatte, wo sehr oft gespeichert wurde und weshalb ich dann diese Regelung gebaut hatte. Mag mich aber auch täuschen...

[Markus.]

Hallo Zusammen,

wo finde ich den die BIN's für die letzte Version ?

Gruß

Markus

[pjakobs]

Moin zusammen,

aktuell wird die Firmware zunehmend zum Problem, wir haben quasi keinen Community Support und ich habe es doch immerhin diese Woche geschafft, zum ersten Mal ein komplettes Paket zu kompilieren.
Insgesamt halte ich mittlerweile aber die Architektur der Firmware für viel zu aufwendig

• völlig andere Toolchain für das UI als für die ESP Firmware
• ESP Firmware in einem recht wenig verbreiteten Framework (SMING)
• Firmware in einer alten Version des Framworks entwickelt

[li]bekannte Bugs (cw/ww colorbalance flicker) bis heute nicht in einer "offiziellen" Firmware gelöst
[/li][/list]

Es gibt dazu noch ein paar Dinge, die ich gerne implementieren bzw. implementiert sehen würde.
Alleine schaff ich das aus vielen verschiedenen Gründen nicht (Zeit ist dabei wohl der wichtigste).

Daher meine Bitte:

wenn sich jemand berufen und in der Lage sieht, mir bei der Weiterentwicklung der Firmware zu helfen, bitte melden!

danke

pj

[Markus.]

Hallo Patrick,

mal ein "ahnungsloser" Einwurf.. Bitte nicht krumm nehmen. Aber bei mir läuft die VBS FW echt prima, wäre es da nicht eine Möglichkeit das ihr zwei da an einem Strang zieht. Glaube das wäre ein irrer Zugewinn für uns einfachen Nutzer....

Gruß

Markus

[pjakobs]

das wäre vermutlich ja auch die Basis, auf der wir weiter machen würden. Aber es ist halt wirklich viel Aufwand, und auch @vbs hat offenbar nicht so viel Zeit, sich darum zu kümmern.

pj

[PeMue]

Hallo Peter,

das wäre vermutlich ja auch die Basis, auf der wir weiter machen würden. Aber es ist halt wirklich viel Aufwand, und auch @vbs hat offenbar nicht so viel Zeit, sich darum zu kümmern.

was empfiehlst Du dann für die Inbetriebnahme bzw. das Testen eines RGBWW Controllers? Die originale oder eher die von vbs?

Bezüglich Hardware:
Ich habe mir jetzt mal ein Netzteil mit Hohlbuchse (der Amazon Link war irgendwo in diesem Thread) geholt, ggf. könnte man zusätzlich auf die neue Platine einem Hohlstecker draufmachen ...
Die Stromfestigkeit dieser Dinger ist12 bzw. 24 V, 5 A, ich denke, das sollte reichen, oder?

Gruß PeMue

[Sidey]

das wäre vermutlich ja auch die Basis, auf der wir weiter machen würden. Aber es ist halt wirklich viel Aufwand, und auch @vbs hat offenbar nicht so viel Zeit, sich darum zu kümmern.

Ich habe mir ein ESP Board von Electrodragon für den Betrieb von LED Streifen zugelegt.
Die Firmware, die auf dem Board drauf ist, bringt mich nicht wirklich weiter.

Ich habe beim durchsuchen des Internets nun auch diese Firmware hier gefunden, da ich nicht bei 0 anfangen wollte.


Zeit ist auch bei mir nur begrenzt vorhanden, mein ESP Board möchte ich aber brauchbar einbinden.
Was wären denn die Todos bei der Firmware?

Soll weiterhin mit SMING gearbeitet werden oder auf Arduino8266 gewechselt werden?


Grüße Sidey

[pjakobs]

Ich habe mir ein ESP Board von Electrodragon für den Betrieb von LED Streifen zugelegt.
Die Firmware, die auf dem Board drauf ist, bringt mich nicht wirklich weiter.

Ich habe beim durchsuchen des Internets nun auch diese Firmware hier gefunden, da ich nicht bei 0 anfangen wollte.


Zeit ist auch bei mir nur begrenzt vorhanden, mein ESP Board möchte ich aber brauchbar einbinden.
Was wären denn die Todos bei der Firmware?

Soll weiterhin mit SMING gearbeitet werden oder auf Arduino8266 gewechselt werden?


Grüße Sidey

Moin,

mir persönlich wäre eine Abkehr von SMING recht, einfach weil Arduino für viele eine bekannte Umgebung ist und die Einstiegshürde für SMING doch recht hoch ist. Ich erinnere mich aber, dass das Problem damals war, dass der Arduino8266 Core die fünf Hardware PWM Kanäle nicht unterstützte, das müsste also erstmal überprüft werden (steckt in der RGBLed Library)

Ansonsten habe ich mal meine "wishlist" für die Firmware hier zusammengetragen.

pj

[Sidey]

Moin,

Ich stehe noch ganz am Anfang und weiss daher auch noch nicht, was ein Controller alles können muss.

Ich habe nun aber espeasy mit einem light Plugin getestet.

Aus meiner Sicht, geht damit schon so fast alles.
Die Synchronisation zwischen mehreren Controllern kann ich nicht einschätzen. Irgendwas geht da, wie gut kann ich nicht sagen.

Vielleicht wäre es halt auch möglich, dort fehlende Funktionen zu ergänzen.

Grüße Sidey

Gesendet von meinem XT1650 mit Tapatalk

[pjakobs]

[...]
Ich habe nun aber espeasy mit einem light Plugin getestet.

Aus meiner Sicht, geht damit schon so fast alles.
[...]
Vielleicht wäre es halt auch möglich, dort fehlende Funktionen zu ergänzen.

[...]

das wäre ein kompletter Neuanfang (und steht natürlich jedem offen).
Die Eleganz der aktuellen Firmware liegt darin, dass sich der Nutzer um das Farbmodell keine Sorgen machen muss. RGB, RGBWW, RGBWWCW, die Farbmischung macht immer der Controller.

pj