ESP RGBWW Wifi Led Controller - Firmware

Begonnen von pjakobs, 12 April 2017, 12:52:18

Vorheriges Thema - Nächstes Thema

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

Zitat von: Kuse am 16 April 2017, 20:05:58
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:

# 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

Zitat von: lewej am 21 April 2017, 07:16:36
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 :D

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
1xBananaPi; 1x FB7490; 1xCUL433; 1x CC2530+CC2591; OpenMiLight-Gateway; 1xHMUART; HM-LC-Sw4-DR; Sonoff* mit TASMOTA, LEDController; MySensors; zigbee2mqtt;

pjakobs

Zitat von: Blauhorn am 04 Mai 2017, 13:36:47
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

Zitat von: pjakobs am 04 Mai 2017, 15:23:15

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. :o

Gruß
Blauhorn
1xBananaPi; 1x FB7490; 1xCUL433; 1x CC2530+CC2591; OpenMiLight-Gateway; 1xHMUART; HM-LC-Sw4-DR; Sonoff* mit TASMOTA, LEDController; MySensors; zigbee2mqtt;

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:
Zitat von: Per am 15 Juni 2017, 23:32:41Ich 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.