[Gelöst] MQTT für WLED, rgb reading mit # klappt nicht

Begonnen von stefanru, 22 März 2019, 21:16:26

Vorheriges Thema - Nächstes Thema

justme1968

hue, tradfri, alexa-fhem, homebridge-fhem, LightScene, readingsGroup, ...

https://github.com/sponsors/justme-1968

Beta-User

Danke für's fixen  :) .

@stefanru:
Soll dann in das template jetzt die HSV-Variante rein?

@justme1968:
Gäbe es die Option, sich noch einen reinen RGB-Slider zu wünschen? Wäre vermutlich zukünftig noch für  ein paar Geräte interessant, die RGB und PCT/brightness getrennt verwalten und in FHEMWEB dann für beides slider-widgets vertragen würden. (Das hier ist für MQTT-Gerät m.E. nicht ungewöhnlich)  (Oder übersehe ich mal wieder was?)
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

justme1968

naja... ein rgb wert der nicht die helligkeit beeinflusst gibt es erst mal nicht. die helligkeit ist hier implizit immer mit drin.

rgb über einen einzigen slider geht nicht.

das wäre dann hue.

aber zusätzlich zum colorpicker für die farbe noch einen slider für die helligkeit anzuzeigen geht doch jetzt schon.

oder verstehe ich etwas falsch?
hue, tradfri, alexa-fhem, homebridge-fhem, LightScene, readingsGroup, ...

https://github.com/sponsors/justme-1968

Beta-User

#33
Das mit der Helligkeit ist richtig ??? , Kopfkratz .

Worum es geht: In der Regel will man für farbige Leuchten zwei bzw. drei slider haben; zwei, wenn man Farbe und Helligkeit einstellen kann hat, drei, wenn man zusätzlich eine ct-Option hat.

Hier hat man einen separaten Slider für die Helligkeit, was demnach benötigt würde, wäre einer, der (auf derselben Helligkeitsstufe, die grade gilt) einen RGB-Wert liefert. Der HUE-Slider macht ja einen Zahlenwert, oder liege ich da falsch? Daher kann man den für diejenigen Geräte nicht verwenden, die den HUE-Wert nicht "verstehen".
(Für sowas wäre dann nur die Frage, wo der Slider den aktuellen Helligkeitswert hernimmt, und welche Skalierung für den gilt (100% oder 0-255); könnte man durch weitere Argumente lösen? EDIT: Oder den vorherigen RGB-Wert auswerten?)
Die Alternative wäre, den HUE-Slider anzubieten, und eine der Funktionen aus Color zu nutzen, um den Wert vor dem Senden zu beeinflussen; dann wird aber der Informationsfluss rückwärts gestört, weil was anderes zurückkommt, als gesendet wurde.
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

justme1968

wenn das device ein set kommando nur für die helligkeit hat -> einfach den hier: https://wiki.fhem.de/wiki/Color#Helligkeit verwenden.

wenn das device keinen eigenes set kommando hat und nur rgb kann -> den colorpicker im rgb oder hsv mode nutzen. da gibt es jeweils einen slider der nur die helligkeitsstufe komponente ändert.

wenn du noch etwas anderes meinst -> bitte noch mal beschrieben :(.


der dritte slider im rgb mode ist nicht für die farbtemperatur sonder für die sättigung. schau mal hier: https://wiki.fhem.de/wiki/Hue#Grundlagen_-_Farbmodelle. das mischen von komponenten aus unterschiedlichen farbmodellen ist normalerweise nicht sinnvoll.


der slider für die farbtemperatur ist noch mal etwas anderes: https://wiki.fhem.de/wiki/Color#Farbtemperatur.

es gibt devices die automatisch den weiss anteil mit steuern wenn man eine farbe setzt und die automatisch in einen nur weiss modus wechseln wenn man die farbtemperatur explizit setzt (fast alle zigbee devices mit ausnahme der de geräte mit neurer firmware). hier kann man im frontend den colorpicker und den ct slider anzeigen aber beide beeinflussen sich automatisch gegenseitig durch die rückmeldung vom device.

und es gibt devices bei denen beides völlig getrennt ist. hier kann man beides anzeigen und getrennt voneinander bedienen.
hue, tradfri, alexa-fhem, homebridge-fhem, LightScene, readingsGroup, ...

https://github.com/sponsors/justme-1968

Beta-User

Na ja, was stefanru gerne haben wollte, ist nach meinem Verständnis ein Device, das in etwa so aussieht bzw. sich so steuern läßt:

defmod dummy_test dummy
attr dummy_test readingList brightness rgb
attr dummy_test setList brightness:colorpicker,BRI,0,15,255 rgb:colorpicker,HUE,0,1,359
attr dummy_test webCmd brightness:rgb

Aber der HUE-Slider liefert leider eben Zahlenwerte, die man nicht sinnvoll an das konkrete Device via MQTT versenden kann, denn das mag ausschließlich RGB-Werte im RRGGBB-Format. Das sollte der Slider liefern...

Dass es andere Widgets gibt, die das hergeben, ist klar, aber der Mechanismus mit dem Aufklappen vom RGB-Widget ist nicht sooo schön, wenn man daneben sowieso einen Slider für die Helligkeit hat.

Sorry für die Ungenauigkeit, was die anderen Optionen/Begrifflichkeiten betr. Farbe usw. angeht. Es geht einfach nur darum, (genau nur) das anzuzeigen, was dann auch das (Ziel-) Device versteht/verarbeiten kann. Hier ist das eben nur brightness und rgb.

Hoffe, das ist nun etwas klarer?
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

justme1968

wenn du den colorpicker im HSV mode verendest klappt nichts auf. die drei regler sind immer sichtbar.

das problem ist: ein oder zwei regler sind nicht genug um eine farbe im rgb oder hsv raum zu bestimmen. es sind drei komponenten nötig. d.h. um rgb einzustellen reicht ein regler nicht.

#FF0000 und #FFFFFF und #FF9999 sind auf hue ebene alles die gleiche farbe. reines rot. und haben alle 100% helligkeit. sie unterscheiden sich nur in der sättigung die du als dritten regler unterschlagen hast.

auch wenn das device nur rgb und helligkeit kann brauchst du im gui alle drei regler um alle möglichen farben einzustellen. genau dafür ist der HSV mode vom colorpicker da.
hue, tradfri, alexa-fhem, homebridge-fhem, LightScene, readingsGroup, ...

https://github.com/sponsors/justme-1968

stefanru

Hi Beta-User,

ich denke den Hue Slider hätte ich dann lieber.

@justme:
Sieh dir mal den Anhang an.
So sieht so ein Device dann in der Übersicht aus.

Die vorne sind die HUE, der hinten ist das Brightness-Reading des Devices, wobei Brightness von 0 - 255 geht.
Irgendwie ist die Helligkeit doch jetzt 2 mal vorhanden.
Einmal im Hue von 0 - 100 und einmal im Brightness-Reading von 0 - 255.

Nochmal vielen Dank für eure Hilfe.

Gruß,
Stefan

justme1968

wenn du nur eins von beiden willst darfst du in deinem webCmd auch nur eins von beiden einbauen.
hue, tradfri, alexa-fhem, homebridge-fhem, LightScene, readingsGroup, ...

https://github.com/sponsors/justme-1968

Beta-User

@justme1968: Danke nochmal für die Infos.

@stefanru:
Läßt sich das Device denn über den HSV (? nicht HUE, oder?) -Slider auch Helligkeitsmäßig gut bedienen? Der mittlere slider sollte auch irgendwelche Auswirkungen auf das Device haben? Dann würde ich (nur) den in webCmd anbieten, doppeln macht keinen Sinn.

Wenn einer der slider funktionslos sein sollte, dann bleiben wir beim aktuellen Stand.
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

stefanru

Hi,

ich glaub ich hab das nicht so gut ausgedrückt.
Der vordere ist HSV und alles funktioniert, der hintere ist Brightness, auch diese funktioniert.

Ist Brightness 0, kann ich an HSV drehen wie ich will es tut sich nichts.
Hat Brightness einen Wert größer 0 kann ich HSV benutzen.
Auch den unteren der drei Slider von HSV der ja auch von Schwarz bis volle Farbe geht.
Ich kann also mit dem unteren vom HSV Slider die Helligkeit von 0 bis 100 einstellen, wobei 100 maximal die Helligkeit von Brightness haben kann.

Bsp: Brightness 50.
Unterer HSV Slider ist bei 0 aus und bei 100 hat die Lampe eine Brightness von 50.

Ein Problem hat der HSV Slider aber.
Slide ich den unteren Slider wirklich auf 0 wird RGB 000000.
Das heißt alle Slider in HSV gehen auf Anfangsposition.
Farbe und Sättigung ändern sich also plötzlich.
Bin mir nicht sicher woran das liegt.
Ich denke aber dass der HSV Slider wenn der untere Slider auf 0 steht alles auf 0 setzt.
Somit geht die Farbe und Sättigung verloren.

Ich würde den HSV Slider gern behalten.
Ist irgendwie besser zu bedienen als die RGB Auswahl.
Außerdem hat RGB ja das selbe. Man kann von oben nach unten auch immer dunkler werden.
Extremfall also eine schwarze Farbe und die LED ist aus obwohl Brightness auf 255 steht.

Ich denke wir sollten HSV nehmen.
Das einzige Problem ist wenn man den unteren HSV Slider auf 0 stellt.
Vielleicht kann justme was dazu sagen?

Gruß,
Stefan

justme1968

jedes farbmodell hat gewisse nachteile. bei hsv geht bei sättigung 0 oder helligkeit 0 die farbe 'verloren'. bei rgb kann man nicht einfach durch die farben scrollen.

wenn man die farmodelle auch noch kombinieren muss weil in einem die einstellung einfacher geht, dieses aber vom device nicht direkt unterstützt wird verstärken sie die probleme gegenseitig.

d.h. für hsv: wenn man die helligkeit auf 0 dreht gehen bei der hin- und rückrechnung über rgb die beiden anderen kanäle verloren weil sich aus rgb 000000 nichts mehr rekonstruieren lässt. ähnliches gilt für ffffff d.h. weiß.

bei einem device das direkt in hsv arbeitet würde das nicht passieren weil nicht hin und her gerechnet werden muss und im device bzw. reading die original werte erhalten bleiben.
hue, tradfri, alexa-fhem, homebridge-fhem, LightScene, readingsGroup, ...

https://github.com/sponsors/justme-1968

stefanru

Ah ok, danke für die Erklärung.

Hmm, dann fällt es mir schwer zu sagen ob HSV oder RGB für die WLED.
Sie hat nur ein RGB und ein Brightness reading.
Dann wäre wohl RGB das korrekte.

Gruß,
Stefan

Beta-User

Dann lassen wir das im template wie es ist. Zumindest die Beschreibung verweist nach hierher, ggf. bzw. bei Gelegenheit nehme ich noch einen comment dazu auf, dass man es auch danach noch wiederfindet, wenn man sich intensiver mit seinem device beschäftigt.

Finde es besser, man hat eine etwas "umständliche" Bedienung (@justme1968: das ist ausdrücklich keine Kritik, die Hintergründe, warum das so sein muss, hast du ja nochmal ausführlich dargelegt) wie irritierende Verhaltensweisen bei einem "mißbrauchten" widget.

(@stefanru: Du kannst das bei dir ja trotzdem so lassen; du kennst ja die Einschränkungen, und wenn du ein paar "Farb-Buttons" dazupackst, die rgb liefern, ist das auch einfach zu überspielen...).
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

stefanru

Hi,

nein das passt. Ich denke ich nehme dann auch RGB. Ich benutze das FHEM WebUI eh fast nicht zum steuern.
Läuft alles automatisiert mit Bewegungsmelder usw.

Also alles super.

Vielen dank nochmal!

Gruß,
Stefan