ESP RGBWW Wifi Led Controller - fhem - Modul

[pjakobs]

hoffentlich ist @herrmannj nicht der Himmel auf den Kopf gefallen!

[herrmannj]

Nö, alles jut.

War auch einer doch recht anstrengenden Geschäftsreise - ich konnte aber schon ein wenig weitermachen. Bin dabei den async call noch schöner zu machen, inkl dns und so. Auch mit fw update und co. Ist state-of-the-art. Das POC modul äuft ja soweit, brennt doch nix an - oder. ?

vg
joerg

[pjakobs]

och, war nur verwundert.
magst Du nicht mal einen Zwischenstand pushen? Ich bin so außenvor, und würde nebeinbei gerne testen, ob pause (bzw. solid) jetzt auch in längeren queues funktioniert.

pj

[herrmannj]

yepp gern. Der Umbau bedingt das im Augenblick ausser viel logging nix passiert. Ich stell die nächste die Funktion bieten rein. Wird aber eher gegen WE

vg
joerg

[kadettilac89]

Ich hab bei mir schon ne Version mit RAW support laufen, allerdings hab ich noch keine klare Idee, wie ich die Readings abbilde.
Momentan verwenden wir ja hsv und rgb mit 8-Bit Werten und die sind immer äquivalent, weil wir rgb in hsv umrechenen.
Bei RAW habe ich 1. 10 Bit rgb Werte und 2. zusätzlich bis zu 2x 10 Bit weiß. Daraus einen vernünftigen hsv Wert zu rechnen mag mir gerade nicht einfallen. Vielleicht frage ich einfach den Controller, was er errechnet hat.
Dazu müsste ich dann ansich auch 10 Bit Readings einbauen, das könnte etwas unübersichtlich werden:

h     [0-255]
s     [0-255]
v     [0-255]
rgb [0x000000-0xffffff]
r10 [0-1023]
g10 [0-1023]
b10 [0-1023]
ww10 [0-1023]
cw10 [0-1023]
rgb10 [0x000000000-0x03ff03ff03ff]
ziemlich unelegant, finde ich, zumal die Werte nicht mehr eineindeutig sind. Der worauf sollte sich der hsv Wert beziehen, wenn ich r10, g10, b10, ww10, cw10  gesetzt habe? Nur auf rgb? oder auch auf hsv?
Eigentlich denke ich, ich möchte den RAW Modus ganz unabhängig vom hsv Modus halten.

pj

Hi Pjakobs,

ich denke was du vorhast ist die eierlegende Wollmilchsau wie es so schön heißt. Ich denke das ist nicht bedienbar abzubilden.

Meine Empfehlung wäre das hier der Controller durch das Modul 2 Funktionen bekommt
- reiner RGB wie jetzt schon abgebildet
- reiner Weiß-Modus

So ähnlich ist es auch bei HUE gelöst wenn ich mich nicht irre. Das RGB hat schon 3 Dimensionen. Wenn jetzt auch noch die CW/WW mit Helligkeit eingearbeitet werden soll ... gäbe es dann noch weitere Farbflächen und Schieberegler hinter dem RGB-Picker?

Wie ich mir das vorstellen könnte
- wie beim RGB-Picker ein Quadrat das hier nur CW/WW hex abgreift. x-Achse ist links CW, rechts WW. Y-Achse ist Helligkeit.
- beim Umschalten zwischen RGB und Weißmodus wird kein Fading durchgeführt da es der Controller nicht implementiert hat
- Parameter der angibt ab wieviel Prozent CW/WW gefadet wird
-- Bei 100 Fading wäre die Helligkeit immer gleich
-- Bei 50 Fading würde erst bei Schieberegler 50% abnehmend die Helligkeit reduziert. Dadurch kann maximale Helligkeit erzielt werden. Helligkeitsunterschiede müssen dann akzeptiert werden.

Ist schwer zu erklären. Habe eine Grafik erstellt, vielleicht ist es besser verständlich. 0-100% ist mit einem Schieberegler zu verglichen. 0% wäre 100% CW, 50% ist die Mitte, 100% wäre 100%WW.

Wie das intern abgebildet wird ist dann zweitrangig. Hex mit 256, 100% oder in wie vielen bit auch immer.

Man könnte die WebCmd eine RGB-Picker, CW/WW-Picker, Ein-Aus verpassen dann wäre das aus Sicht Usability verständlich. Durch 2 separate Picker ist auch vom Ablauf ersichtlich dass hier 2 verschiedene Dinge dahinter liegen.

[kaihs]

Ich hab bei mir schon ne Version mit RAW support laufen, allerdings hab ich noch keine klare Idee, wie ich die Readings abbilde.

Ich hatte eher an unterschiedliche Modi gedacht:

RGB/CW/WW, Einstellungen beziehen sich auf alle Kanäle, Farben werden aus allen Kanälen gemischt (geht ja aktuell schon)
nur RGB (geht auch schon)
RGB CW WW, die drei Bereiche sind getrennt steuerbar, d.h. Farbeinstellungen gehen nur auf RGB, CW und WW lassen sich getrennt aber nur in der Helligkeit steuern.

[mrpj]

Ich hab bei mir schon ne Version mit RAW support laufen, allerdings hab ich noch keine klare Idee, wie ich die Readings abbilde.
Momentan verwenden wir ja hsv und rgb mit 8-Bit Werten und die sind immer äquivalent, weil wir rgb in hsv umrechenen.
Bei RAW habe ich 1. 10 Bit rgb Werte und 2. zusätzlich bis zu 2x 10 Bit weiß. Daraus einen vernünftigen hsv Wert zu rechnen mag mir gerade nicht einfallen. Vielleicht frage ich einfach den Controller, was er errechnet hat.

Aus RAW errechnet der Controller keine weiteren Werte. RAW bedeutet übersetzt: direkte Steuerung der Ausgangsleistung des Kanals - der Nutzer dieses Modus ist selbst für seine Ansteuerung verantwortlich und der Controller hält sich dabei raus.

Einzig bietet der Controller noch die Möglichkeit, statt den Wert direkt zu setzen, den Wert per Fade über t zu setzen.
Ich habe mir wirklich lange den Kopf zerbrochen und überlegt, wie man ein Berechnungsmodell erweitern kann, damit 5 Kanäle wieder in HSV inklusive Kelvin Wert umgerechnet werden können. Es ist mit den reinen Werten einfach nicht möglich, ohne Gewisse Vorannahmen zu treffen, oder weitere Informationen zu haben.

Eigentlich denke ich, ich möchte den RAW Modus ganz unabhängig vom hsv Modus halten.

Genau so war es von meiner Seite aus gedacht - RAW und HSV funktionieren getrennt voneinander. Es gibt zwar die Möglichkeit nach einem HSV Wert die Ansteuerung der Kanäle (RAW) auszulesen, weil es eine Umrechnungsbasis gibt - dies gilt aber nicht in die andere Richtung.
Sprich wer einmal mit RAW anfängt, sollte vor der Benutzung mit HSV einen gültigen Wert für HSV als Startpunkt setzen - sonst wird es schlichtweg einfach nix 

[herrmannj]

Hallo mrpj

Einzig bietet der Controller noch die Möglichkeit, statt den Wert direkt zu setzen, den Wert per Fade über t zu setzen.

Ich bin sichtlich nicht up-to-date. Magst Du das kkurz erklären bitte ?

Sprich wer einmal mit RAW anfängt, sollte vor der Benutzung mit HSV einen gültigen Wert für HSV als Startpunkt setzen - sonst wird es schlichtweg einfach nix 

Dito, angenommen ich setzte ra ff,ff,ff,ff,ff,ff und für danach ein set hsv 0,100,0 aus. Was würde passieren (nicht im detail)
a: garnichts (Befehl geht ins nirvana)
b: irgendwas (unpredictable)

Danke vg
joerg

[mrpj]

Ich bin sichtlich nicht up-to-date. Magst Du das kkurz erklären bitte ?

Wie bei HSV kann der Controller bei RAW den neuen Wert "faden". Sprich mann kann von RAW(0,0,0,0,0) auf RAW(100,20,30,0,0) faden über Zeit t.
Hier verhält sich der Controller gleich zu HSV - nur werden keine HSV Werte berechnet, sondern eben die einzelnen Kanal Werte erhöht/verringert

(Der Wechsel von HSV -> RAW ist dabei möglich - da jeder HSV Wert einen Ausgangswert (RAW) erzeugt)

Dito, angenommen ich setzte ra ff,ff,ff,ff,ff,ff und für danach ein set hsv 0,100,0 aus. Was würde passieren (nicht im detail)
a: garnichts (Befehl geht ins nirvana)
b: irgendwas (unpredictable)

b 

Bzw. der Controller nimmt den letzten ihm genannten HSV Wert als Startpunkt für den HSV Fade (wenn keiner bekannt ist es HSV(0,0,0)).
Andernfalls empfiehlt es sich, zuerst einen HSV Wert ohne Übergang zu setzen (solid) und danach seinen Fade zu starten.
Oder direkt dem Controller den Befehl übergeben: Fade von HSV(X,Y,Z) zu HSV(A,B,C)

[pjakobs]

ich denke fast, es ist am Besten, wenn wir das Modul entweder als raw oder als hsv betreiben. Es gibt keinen sinnvollen Übergang zwischen den Modi und vermutlich sind es auch unterschiedliche Installationen, was also spricht dagegen, von vornherein entweder ein rgb oder ein hsv API anzubieten?
Viele der Funktionen im aktuellen hsv-Mode sind im raw-Mode so oder so hinfällig, set hue, sat, val, rotate ergeben kein definiertes Ergebnis, dim, on und off müssten ganz anders implementiert werden.
Ich denke, ein attr, das zwischen hsv und raw betrieb unterscheidet wäre eine ganz elegante Lösung.

pj

[RoBra81]

Hi,

eine Unterscheidung zwischen RAW und HSV mittels Attribut würde mir nicht gefallen: ich möchte den Controller vorrangig im HSV-Modus einsetzen, aber wenn ich mal richtig Licht brauche, wünsche ich mir per RAW die Möglichkeit, alles einzuschalten...

Ronny

[pjakobs]

@RoBra81 das wäre imho kein Widerspruch, denn Du könntest das attr ja setzen, der Controller würde dann den Modus wechseln (und z.B. einen vordefinierten hsv / rgbww Wert setzen) und gut is.
Natürlich würde das die entsprechenden Widgets stören, aber die sind so oder so nicht brauchbar, wenn Du raw Werte setzt.

pj

[RoBra81]

Ich denke aber, dass es nicht FHEM-Standard ist, ein Attribut zu setzen um etwas zu schalten...

[Icinger]

Man könnte beim Define angeben, ob es als "RAW" oder als "HSV"-Device werkeln soll.
Dann kann man parallel immer noch ein zweites device mit der selben Adresse anlegen als gegenpart dazu, oder?

lg, Stefan

[pjakobs]

@Icinger

hmm...
es gibt zwei Dinge, die ich da behandeln möchte:
1. in den beiden Modi gibt es unterschiedliche gültige Readings. Idealerweise sind nur die jeweils gültigen sichtbar
2. ein Wechsel von einem Modus in den anderen führt nicht in allen Fällen zu einem definierten Startpunkt wie vom @mrpj beschrieben (raw->hsv hat keine gültige Einstellung)

1. könnte man mit zwei unabhängigen Devices abbilden, aber 2.? Da wäre eine  Modusumschltunge ideal. Wobei das natürlich auch das Problem hat, dass ich die ungültigen Readings nicht einfach verschwinden lassen kann.