ESP RGBWW Wifi Led Controller - Hinweise zu Sammelbestellung 2.5

[Tom71]

Ja, erster Prototyp hier im fred

vg
joerg

Ich finde ihn nicht, kannst du bitte einen Link posten?
Update: Ah, hier: https://forum.fhem.de/index.php/topic,48918.msg451914.html#msg451914
Danke

[pjakobs]

Ja, erster Prototyp hier im fred

vg
joerg

@herrmannj
Hi Joerg, danke für den Hinweis, ich hab's gefunden.
Spricht was dagegen, das Modul auf githup zu packen? Würde die gemeinsame Entwicklung vereinfachen.

Grüße

pj

[uniqueck]

Das würde ich auch begrüßen, würde auch mithelfen sofern es die begrenzte Zeit zu lässt. 

Gesendet von meinem GT-N7100 mit Tapatalk

[herrmannj]

Keine einwände

[pjakobs]

et voilá:

https://github.com/pljakobs/RGBWW_fhem_module

ich habe ausgesprochen simplen RGB Support (ohne WW und CW) hinzugefügt.

pj

[mrpj]

@TeeVau
Ich kann dir auch anbieten, dass du mir den Controller mal zuschickst.

@pjakobs/uniqueck/hermannj

Macht es Sinn das fhem Modul in einem repo bei mir im Account zu hosten? Dachte daran dass es dann "einfacher" zu finden ist?
Kann (sofern github das bei privaten accounts erlaubt) jedem hier gerne commit/push Berechtigung geben

[pjakobs]

mrpj,

fänd ich auch besser.

brauchst ja keine Commit rights zu vergeben, langt ja, wenn wir forken und pull requests aufmachen.

pj

[herrmannj]

Passt. Denke das ist eh nur temporär weil wenn ok checken wir das ja in fhem ein.

Vg
Joerg

[pjakobs]

ich hab mal ein bisschen weiter gebaut.
Keine grundsätzlichen Veränderungen (also: Fehlerhandling immer noch sehr rudimentär)
aber: ich habe "set RGB" und "on/off" eingebaut (letzteres erstmal nur nach HSV x,0,100).
RGB habe ich so implementiert, dass zuerst nach HSV umgerechnet wird, denn auf diese Weise wird die Farbkorrektur und die zusätzliche Auflösung des Controllers verwendet.
RGB widgets funktionieren nun weitgehend, sowohl im klassichen FHEM web frontend als auch im tablet ui.

das soll aber nicht heißen, dass nicht noch viel fehlt

momentan noch hier @mrpj wenn Du willst kannst Du es ja einfach zu Dir forken und wir machen dort weiter.

pj

[pjakobs]

@herrmanj sag mal, macht's Dir was aus, statt HSB doch lieber HSV als Nomenklatur zu verwenden? Die Schwierigkeit ist, dass wir bei HSB sehr leicht die Komponentenvariablen durcheinanderbringen, weil $b ja für "blue" und "brightness" stehen könnten. Ich glaube, das war auch der Grund, warum ursprünglich mal das B durch das V ersetzt wurde.

pj

[herrmannj]

@herrmanj sag mal, macht's Dir was aus, statt HSB doch lieber HSV als Nomenklatur zu verwenden? Die Schwierigkeit ist, dass wir bei HSB sehr leicht die Komponentenvariablen durcheinanderbringen, weil $b ja für "blue" und "brightness" stehen könnten. Ich glaube, das war auch der Grund, warum ursprünglich mal das B durch das V ersetzt wurde.

pj

Kein Einwände - das ist eh nur kosmetisch. Das mit $b verstehe ich nicht ganz, das ist ja nur intern. Das könnte auch $otto heisen - oder ,misverstehe ich da was.

Idee war weitere SET anzubieten die bisher noch fehlen, nämlich "hue" "sat" und "bri"||"val" einzeln. Da erschien mit "bri" für "brightness" irgemndwie flauschiger als "val". Aber, wie gesagt, keine wirkliche Relevanz.

Wichtiger wird es sein dass Readings und SET gleichlautend benannt werden.  Sprich: es sollte imho ein Reading "HSB||V" geben und ein gleichlautendes SET "HSB||V". Dito dann eben für "hue", "sat" usw. Jeweils ein Reading und ein gleichlautendes SET.

Beim absetzen der Befehle (SET) gibt es eine kleine Tücke. Aktuell wäre es möglich das, wenn zwei SET, nacheinander und direkt abgesetzt werden, dass für den ersten SET dir asynchrone Kette noch niicht durchlaufen ist wenn das zweite schon angestossen wird. Das müsste man intern als FIFO organisieren - mit dem Ziel das ein Kommando an den controller erst abgeben wird wenn das vorhergehende fertig bearbeitet ist (in dem Sinn das die JSON API gelesen und ok gemeldet hat).

@MPRJ: was würde der contoller machen wenn er zwei Kommandos gleichzeitig bekommt ? Speichert der seöber zwischen ?

Bei den Transitions gibt es die Tücke das der Controller keine aktualisierten Farbwerte sendet. Grundsätzlich könnte man pollen, das benötigt einen Timer vlt mit 250 oder 500msec. Mein Vorschlag wäre aber auf das ressourcenintensive pollen zu verzichten und statt dessen in dem Timer die Farbe "mitzukoppeln".

Beispiel zur Erklärung, angenommen einen Transition 10 sek von 0,0,0 auf 0,0,100:

bei 500msec wäre der controller bei 0,0,5. Anstelle jetzt bei dem controller erst umständlich die Farbe zu pollen schlage ich vor einfach die "rechnerische" 0,0,5 als gegeben anzunehmen und die Readings danach zu aktualisieren. Man könnte zur Sicherheit zum Start und zum Ende einer Transition einmal die Farbe beim controller abholen. Das würde, bei Abweichungen, an dieser Stelle die Readings mit dem Controller synchronisieren.

Das Modul müsste dann eine Awareness auch für Transitions in einer QUEUE haben, sprich intern das mitspeichern was der controller in der QUEUE hat.

Für WifiLight hatte noch ich eine request bekommen Funktion (SET) für HUE und SAT analog zu DimDown und DimUp anzubieten. Also ein SET welches den HUE zum Beispiel relativ um 30° bewegt. Der Vorschlag war, glaub ich TINT, wobei ich das noch nicht so intuitiv fand. Die Idee an sich finde ich charmant.

vg
joerg

[pjakobs]

Kein Einwände - das ist eh nur kosmetisch. Das mit $b verstehe ich nicht ganz, das ist ja nur intern. Das könnte auch $otto heisen - oder ,misverstehe ich da was.

klar ist das nur kosmetisch, aber ich bin eben drüber gestolpert, weil ich ja für RGB erstmal nach HSV (HSB) umrechne und prompt mein Variable für Blau $b nannte und damit die für Brightness überschrieb. Es ist halt ne Fehlerquelle.

Idee war weitere SET anzubieten die bisher noch fehlen, nämlich "hue" "sat" und "bri"||"val" einzeln. Da erschien mit "bri" für "brightness" irgemndwie flauschiger als "val". Aber, wie gesagt, keine wirkliche Relevanz.

Nachvollziehbar, man kann ja im externen Interface das als Synonym anbieten, also bri oder val - intern den gleichen Code.

Wichtiger wird es sein dass Readings und SET gleichlautend benannt werden.  Sprich: es sollte imho ein Reading "HSB||V" geben und ein gleichlautendes SET "HSB||V". Dito dann eben für "hue", "sat" usw. Jeweils ein Reading und ein gleichlautendes SET.

auch das geht natürlich, aber dann wird's langsam verwirrend. Nachdem WifiLight HSV verwendet, und wir vermutlich irgendwann zumindest teilweise dorthin mergen, halte ich HSV für sinnvoller.

Beim absetzen der Befehle (SET) gibt es eine kleine Tücke. Aktuell wäre es möglich das, wenn zwei SET, nacheinander und direkt abgesetzt werden, dass für den ersten SET dir asynchrone Kette noch niicht durchlaufen ist wenn das zweite schon angestossen wird. Das müsste man intern als FIFO organisieren - mit dem Ziel das ein Kommando an den controller erst abgeben wird wenn das vorhergehende fertig bearbeitet ist (in dem Sinn das die JSON API gelesen und ok gemeldet hat).

hmm... stimmt, ist jetzt für mich nicht das große Problem, sogar eine Kette mit zu queuenden Sets in einem Event ist gerade relativ problemlos durchgelaufen, aber es könnte tatsächlich gleichzeitige Zugriffe geben.
Die Frage ist: wenn wir in WifiLight mergen wollen - müssen wir uns dann darum kümmern?
Zum zweiten: ich würde das als nachgelagert zur initialen Funktionalität sehen, sprich: ein queuing außenrum bauen geht auch später noch.

Bei den Transitions gibt es die Tücke das der Controller keine aktualisierten Farbwerte sendet. Grundsätzlich könnte man pollen, das benötigt einen Timer vlt mit 250 oder 500msec. Mein Vorschlag wäre aber auf das ressourcenintensive pollen zu verzichten und statt dessen in dem Timer die Farbe "mitzukoppeln".

nett, aber ist das wirklich nötig?
Was Du vorschlägst ist ja, die  gesamte Transitionqueue auch lokal auf dem fhem mitzufahren, wenn auch grober als das der Controller macht. Meinst Du nicht, dass das aufwendiger ist, als pollen? Ok, Polling bedeutet Netzwerkoverhead - ganz offen ist das imho eine Sache, die irgendwann mal auf MQTT aufgebaut werden kann, das REST Interface ist dafür eher ungeeignet und lokal mitrechnen - was passiert, wenn Du das für 10 oder mehr Controller machst?

Für WifiLight hatte noch ich eine request bekommen Funktion (SET) für HUE und SAT analog zu DimDown und DimUp anzubieten. Also ein SET welches den HUE zum Beispiel relativ um 30° bewegt. Der Vorschlag war, glaub ich TINT, wobei ich das noch nicht so intuitiv fand. Die Idee an sich finde ich charmant.

Die Idee ist nicht schlecht, aber - das kann ich doch problemlos mit FHEM Bordmitteln, sprich set ReadingsVal{"LedDevice", "Hue", 0}+30 (oder so ähnlich) - verstehe ich da was nicht?

pj

[pjakobs]

@mrpj:

Hi Patrick,

zwei Fragen hätt ich:
1. hab ich gerade mal nachgemessen, in Ruhe braucht die Schaltung unter 300mW, das ist viel weniger als die ca. 550mW, die ich bisher mit ESP8266 und aktivem WLAN gesehen habe, nutzt Du irgendwelche low power Zustände?
2. errm.. hast Du vielleicht noch eines der Spannungswandler-Module? Ich frage für eines, das keine Ausgangsspannung mehr produziert...

ansonsten: mein Wohnzimmer erstrahlt nun im Licht von 10m RGBwW single Chip LEDs (also etwa 600 Stück), angesteuert durch den RGBWW Controller und das fhem Modul wie's im Github liegt - ok, da war noch ein kleiner Bug drin, aber den check ich nachher auch noch ein.

Grüße

pj

[Hauswart]

Blöde Frage zum Ausschalten der LED-Kette gibt es bisher keine Möglichkeit?

[Icinger]

Doch, die selbe Möglichkeit wie zum Einschalten:

Einfach die Farbe setzen, in diesem Fall halt dann "Schwarz", also HSB=0,0,0

lg, Stefan