Unterstützung von HSL Farbmodell

[smai]

Eugenius liesse sich sicher irgendwie implementieren, aber braucht man das wirklich? Für mich hat das Colorwheel schon zu viele Farben.
Nutzt du das für die Lichtsteuerung?

[Eugenius]

Ich nutze es noch nicht, weil ich es nicht habe
Es geht nicht um die Anzahl der Farben, sondern mehr um die Helligkeitseinstellung. Colorwheel kann das zwar indirekt auch, aber nicht so "genau" wie mit einem Schieber.
Aber gut, du hast Recht, zu viel ist auch nicht gut...

[smai]

Ich nutze es noch nicht, weil ich es nicht habe

Ja, klingt schlüssig

Da mich die Idee gereizt hat, habe ich deinen Wunsch trotzdem erfüllt und den mode 'slider' implementiert. Schau dir das im develop mal an.

[Eugenius]

Danke!
Ist das normal? Dimmer_sv2.9.PNG

{{ basic.color('Schlafzimmer.Licht.Bett.Dimmer.rgb', 'Schlafzimmer.Licht.Bett.RGB.R', 'Schlafzimmer.Licht.Bett.RGB.G', 'Schlafzimmer.Licht.Bett.RGB.B', 0, 255, 16, 15, 'slider') }}

Update:
es geht doch 20170302_082415.png



Ich war wohl schon im Halbschalf und mein RasPi ohne Cache konnte nicht so schnell auf die Farbänderung reagieren. Deswegen haben mich die schwarzen Balken irretiert.
Nur als Idee: evtl. Hue doch immer stehen lassen (also nicht schwarz anzeigen) als wäre die Helligkeit immer bei 100%? so kann man die Farbe immer sehen und auswählen und dann die Helleigkeit steuern?

[dafra]

Der Parameter zur Auswahl des Farbmodells (rgb, hsl, hsv) ist in develop committed.
Gleichzeitig habe ich noch die Möglichkeit geschaffen, die Werte in einem einzelnen Item vom Typ List zu übergeben anstatt in 3 separaten Items.

Ich muss man ganz dumm fragen: Gibt es irgendwo eine Doku, wie man das neue basic.color parametrieren muss? Also mit dem HSV modell? Bzw: Woher wusste Eugenius das?

[smai]

Die Doku ist integriert, einfach auf der Konfigurationsseite "Doku" bei den Pages auswählen.

[Eugenius]

Hi,

ich bin von dem Widget begeistert! Klasse Arbeit! Vielen dank.
Ich muss aber doch leider eine Bug melden.
Uns zwar, ich wähle eine belibige Farbe, z.B. grün. (Saturation und Helligkeit <> 0)
Dann stelle ich die Helligkeit auf 0.
Alle Slider springen auf 0:
2017-03-03 08_44_07-YOUR NAME [smartVISU].png
warum auch immer wird Helligkeitslider in blau angezeigt (eigentlich egal welche Farbe davor war).
Dann Stelle ich die Helligkeit auf nicht gleich 0. (Ich gehe davon aus dass es grün sein sollte, weil ich es vorher hatte oder zumindest blau, weil so angezeigt wird. Aber nein, es ist dann rot (bzw. sogar weiß), weil der Hue-Slider auf 0 steht:
2017-03-03 08_44_41-YOUR NAME [smartVISU].png

Vorschlag:
Hue Slider-Hintergrund fest auf 100% Hellegikeit und 100% Saturation einstellen. Dann sieht man immer die Farbe.
Bei der Helligkeit = 0 Hue und Saturation nicht auf 0 stellen (warum is das so eigentlich?)

[smai]

Gerne!

Wenn die Helligkeit auf 0 gestellt wird und man RGB als mode hat, wird rgb(0,0,0) an das Backend gesendet. Dieses schickt das dann als Status zurück und die Visu konvertiert rgb(0,0,0) zu hsv(0,0,0).

Weshalb das blau da erscheint, versteh ich grad auch nicht. Muss ich genauer anschauen.

Ich müsste wohl den zuletzt eingestellten hue und Sättigung zwischenspeichern und wenn rgb(0,0,0) bzw. r==g==b kommt diese wieder verwenden. Das klappt natürlich nur, solange die Seite nicht neu geladen wird.

[Eugenius]

Ach, ok, jetzt verstehe ich warum die Slider auf 0 gehen... hm...
Andere Idee: wenn rgb modus, dann ist es klar, dass aus rgb(0,0,0) hsv(0,0,0) gebildet wird. aber wenn hsv-modus, dann soll eigentlich hsv(x,x,0) bleiben, nicht wahr? Und somit könnte man zu der alten Farbe wieder zurückkehren...

P.S. aber Hue-Hintergrund würde ich trotzdem nicht verändern

[smai]

Die verschiedenen Farbmodelle treiben mich noch in den Wahnsinn

Ich habe noch ein weiteres Problem festgestellt:
Items werden immer einzeln ans Backend gesendet. Wenn ich als Modell RGB habe einen der HSV-Slider verändere, wird zuerst Rot gesendet, dann Grün, dann Blau.
Das Führt aber auch dazu, dass ich vom Backend dann zuerst in kurzen Abständen zwei falsche Gesamtfarben zurückkriege und diese auch an die echte Lampe im Haus gesendet werden. Erst die dritte Nachricht ist dann eigentlich richtig.

Dies führt auch dazu, dass die Slider wild umherhüpfen und dass meine Idee von oben nicht so einfach umzusetzen ist, weil ich gar nicht so genau weiss, welches die zuletzt empfangene korrekte Farbe war.

Ich muss das irgendwie abfangen und die falschen Farben ignorieren, mal nachdenken...

[dafra]

Ich bin mir nicht sicher, ob das Problem wirklich neu ist. Bislang (=smartVISU 2.8) war es auch schon so, dass wenn ich die Farbe meiner HUEs über die VISU ändere, die HUEs nicht direkt auf die Zielfarbe gehen, sonder erst "rumeiern", bis sie die richtige Farbe dann treffen.

Items werden immer einzeln ans Backend gesendet. Wenn ich als Modell RGB habe einen der HSV-Slider verändere, wird zuerst Rot gesendet, dann Grün, dann Blau.

Das wäre vermutlich die Erklärung.

Gruß, Daniel

[Eugenius]

Ich habe das so gelöst, dass ich in einer Logik alle drei Farben "sammle" und dann als dpt 232.000 an dimmer sende. Aber das problem war, dass eibd nicht so schnell die drei telegramme senden konnte und immer wieder eine Farbe verloren ging...

[Onkelandy]

Danke für das tolle Widget! Mir ist aufgefallen, dass wenn man 'slider', 'hsv' definiert, die Slider dann plötzlich RGB steuern. Ein 'slider' ohne weiteres Element danach führt zum erwarteten Ergebnis. Ein 'hsl' hinter Slider führt dazu, dass alles wild hin und her springt. Das wird aber vermutlich auch daran liegen, dass ich normale RGB -Helligkeitswerte anspreche.

Eine Beschrifung der Slider wäre noch cool.. also HSV oder RGB vor den einzelnen Slidern..?

[Onkelandy]

Noch eine andere Frage.. wie viel Aufwand wäre es, was Ähnliches für Farbtemperatur zu basteln? Also warm- und kaltweiß, ohne Farbe.
Da bei vielen LED-Stripes das kaltweiß durch alle 3 Farben erzeugt wird, wäre natürlich genial, mehrere Items pro Farbtemp zu definieren.

Ist der warm/kalt-Regler ganz bei kalt und die Intensität auf 100%, dann leuchten nur die als kalt definierten LEDs, ist der Regler in der Mitte, dröhnen kalt und warm zu 100%

[smai]

Ich habe nun in HSL noch einen Bug gefixt, da wurde eine Umrechnung falsch gemacht und deshalb wurde irgend eine andere Farbe angezeigt.

Das kurzfristige herumhüpfen des Sliders konnte ich zumindest bei Bedienung des Sliders selbst verhindern. Wird die Farbe vom Backend empfangen oder durch ein anderes Widget geändert, kann es aber immer noch vorkommen.
Leider sehe ich auch keine Möglichkeit, dies zu ändern, weil die I/O-Treiber keine Transaction oder sowas vorsehen, damit alle 3 Werte gemeinsam behandelt werden.

Da ich selbst keine RGB-Beleuchtung habe, könnt ihr das evtl. nochmal testen?


KW/WW ist schon länger geplant. Ich hatte nur noch gewartet, welche KO MDT in ihren neuen Controllern dazu verwendet. Dies ist ja jetzt bekannt, deshalb steht einer Implementierung nichts mehr im Wege.
Ich werde wohl sowas wie device.dimmer bauen mit einem zweiten Slider für die Temperatur. Für diesen kann ein Item sowie Minimal- und Maximalwert definiert werden.
Damit kann man beide MDT-Varianten verwenden, entweder die absolute Farbtemperatur (z.B. mit min=2500, max=4000) oder den prozentualen Anteil an kaltem Licht (min=0, max=100). Zweiteres funktioniert auch mit dem enertex-Dimmer.

Onkelandy um deine Idee mit der Mischung per RGB zu realisieren, müsste man wahrscheinlich noch die RGB-Werte für KW und für WW definieren können und die Zwischenschritte dann interpolieren.
Evtl. will man dazu noch die Helligkeit stabilisieren, wie dies bei den neuen TW-Controllern gemacht wird. Also dass in der Mitte eben nicht beide auf 100% stehe sondern auf 50%.
Ehrlich gesagt ist mir das etwas zu viel Logik für die sV. Vielleicht wäre ein SHNG-Plugin sinnvoller, welches dann mit dem Prozentwert aus der Visu die RGB entsprechend ansteuert. Was meinst du?