Farbwerte umrechnen bzw. nutzen

Begonnen von 87insane, 14 Mai 2020, 10:09:09

Vorheriges Thema - Nächstes Thema

87insane

Hab mittlerweile gemerkt das die Werte, wie rgb usw nur gesendet werden, wenn auch der jeweilige Channel auf der FB als ON gekennzeichnet ist. Ist dieser OFF, gibt es nur die doofen Werte.
Sprich hue, brightness ohne Level usw..

Also musste ich mir selber helfen und wandel diese nun auch selber um über Userreadings.
_hex_color:hue:.* {Color::hsv2hex((ReadingsVal($name,"hue","0")),1,1)},
_brightness_pct:brightness:.* {sprintf("%00.0f",(ReadingsVal($name,"brightness","0")/2.55))},
_color_temp_pct:color_temp:.* {sprintf("%00.0f",((ReadingsVal($name,"color_temp","0")-153)/2.17))}


_hex_color wandelt die hue Farbe in Hex um und ist somit gegen meinen Shelly verwertbar.
_brightness_pct wandelt die werte 0-255 in Prozent um und lässt mich so meine Rollos steuern oder aber diesen Wert an Shellys usw weitergeben.
_color_temp_pct wandelt den Bereich 153-370 in Prozent um... Gleiches wie auch bei _brightness_pct.

Diese Werte kommen also auch wenn der Channel OFF ist und ich kann somit auf der FB mehrere Geräte steuern anstelle nur eines....

Beta-User

Ist ja nett, aber irgendwie "zu Fuß".

Warum packst du die Umwandlungslogik nicht in myUtils-Code? Dann wird genau dann ausgewertet, wenn du es auch wirklich brauchst... Oder gibst du das per "Einzelnotify" weiter?

Was die FB angeht, kenne ich diese spezielle nicht selbst, aber alle anderen mehrkanaligen MiLight-FB's, die ich habe, brauchen immer erst ein "ON", um die "Schaltebene" zu wechseln, sonst kommt der "brightness"...-Wert schlicht unter einem anderen Topic. Von daher verstehe ich die Logik hinter deiner Aussage mit den "mehrere Geräte" noch nicht ganz.
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: ZigBee2mqtt, MiLight@ESP-GW, BT@OpenMQTTGw | ZWave | SIGNALduino | MapleCUN | RHASSPY
svn: u.a Weekday-&RandomTimer, Twilight,  div. attrTemplate-files, MySensors

87insane

Ich weiß keinen besseren Weg. Sieht so aus das ja auch nur gewandelt wird, wenn jemand an der FB spielt.

Die FB sendet immer in dem Channel in dem sie ist. Wenn sie off oder on gesetzt wird in einer Zone, funkt sie dort auch. Da ich aber z.B. mit den unteren Tasten einfach andere Räume aktiviere, dabei aber die Zone absichtlich auf off stelle. Somit werden dann nur noch die normalen Werte aktualisiert. Deswegen habe ich mir die Umwandlung selber gebaut. So habe ich auch keine Nebeneffekte vom Hub. Ich habe da mittlerweile fast alles aus, was man bei Group state fields einstellen kann. Für meinen Zweck macht es so am meisten Sinn.

Ich habe mir die Zonen bisher als Decken-Licht (Zone 0), Rollo (Zone 1), LED Leuchten (Zone 2) eingestellt.
Damit ich aber nun nicht nur das wz Rollo steuern kann, habe ich zB eine der unteren Funktionstasten genommen und diese setzt dann in ein Reading zB wz_rollo anstelle von wz_rollo und ich kann dann dieses Rollo via Helligkeitsregler auf der FB in % steuern.

TomLee

Mit
jsonMap level:brightness
wird
_brightness_pct:brightness:.* {sprintf("%00.0f",(ReadingsVal($name,"brightness","0")/2.55))}
überflüssig.

Beta-User

Na ja, wenn ich das richtig verstanden habe, geht es weniger um den Namen, sondern eher darum, dass diese Umrechnung stattfindet.

@87insane:
Bei mir ist die für 255=>100 (bzw. =>99 für ZWave ;) ) hier drin: https://github.com/rejoe2/FHEM/blob/master/99_myUtils_MiLight.pm#L155.

Verstehe ehrlich gesagt nicht, warum du das Rad neu erfindest und nicht das vielleicht unvollständige Rad aus den obigen myUtils verbesserst bzw. weitere Anwendungsszenarien dazupackst.

Wenn mehr Leute das nutzen, kann ich den Code gerne nach contrib packen und als "add-on" zu dem Fernbedienungs-attrTemplate verteilen (analog zu dem, was wir bei ebus auch machen)! Ich will mich im Moment allerdings nicht mit den Untiefen des Codes auseinandersetzen, sondern bitte dann um vollständige Zuarbeit incl. commandref! Das "Original" war nur mal entstanden für die Dinge, die ich selbst brauchte.

Da es durchaus Leute geben kann, die das "neben" den bekannten direkten Steuerungsmöglichkeiten für Leuchtmittel haben wollen, halte ich allerdings das Wegfiltern von Events/Sendedaten für nicht zielführend.
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: ZigBee2mqtt, MiLight@ESP-GW, BT@OpenMQTTGw | ZWave | SIGNALduino | MapleCUN | RHASSPY
svn: u.a Weekday-&RandomTimer, Twilight,  div. attrTemplate-files, MySensors

TomLee

Achso, verstehe, jetzt erst, du hast noch gar kein level Reading 0-255  ;), dann einfach in den Einstellungen auch anklicken. Das brightness Reading hat man immer auch wenn man es nicht anwählt.
Dann brauchst auch kein jsonMap das ist klar.

TomLee

Sry, habs mir jetzt nochmal angeschaut.

brightness liefert Werte von 0-255, level 0-100, mit dem jsonMap landet level in brightness, wie hier gewünscht oder nicht? ein brightness-Reading von 0-100.

Zum Verständnis die Readings ohne jsonmap:

setstate MQTT2_Mi_Wecklicht ON
setstate MQTT2_Mi_Wecklicht 2020-05-15 14:12:30 Test2 FF6600
setstate MQTT2_Mi_Wecklicht 2020-05-15 14:12:30 brightness 255
setstate MQTT2_Mi_Wecklicht 2020-05-15 14:12:30 bulb_mode color
setstate MQTT2_Mi_Wecklicht 2020-05-14 15:40:13 color #FF6600
setstate MQTT2_Mi_Wecklicht 2020-05-15 14:12:30 color_b 0
setstate MQTT2_Mi_Wecklicht 2020-05-15 14:12:30 color_g 102
setstate MQTT2_Mi_Wecklicht 2020-05-15 14:12:30 color_r 255
setstate MQTT2_Mi_Wecklicht 2020-04-23 19:39:05 command set_white
setstate MQTT2_Mi_Wecklicht 2020-05-15 14:12:30 device_id 36182
setstate MQTT2_Mi_Wecklicht 2020-05-15 14:12:30 device_type rgbw
setstate MQTT2_Mi_Wecklicht 2020-05-12 22:50:45 effect white_mode
setstate MQTT2_Mi_Wecklicht 2020-03-16 14:18:09 group_id 1
setstate MQTT2_Mi_Wecklicht 2020-05-15 14:12:30 hue 24
setstate MQTT2_Mi_Wecklicht 2020-05-15 14:12:30 level 100
setstate MQTT2_Mi_Wecklicht 2020-03-21 18:41:51 on_transition set 93
setstate MQTT2_Mi_Wecklicht 2020-05-15 14:12:30 rgb FF6600
setstate MQTT2_Mi_Wecklicht 2020-05-15 14:12:30 state ON
setstate MQTT2_Mi_Wecklicht 2020-05-15 14:12:30 status ON
setstate MQTT2_Mi_Wecklicht 2020-03-24 18:44:47 sun set
setstate MQTT2_Mi_Wecklicht 2020-05-15 14:12:30 test 8EFF00

Beta-User

Sry, leider ist der ganze Thread hier etwas aus dem Zusammenhang gerissen:

Es geht darum, eine bestimmte Fernbedienung (hier: die mit 7 Kanälen (GLEPTO ?)) dazu zu verwenden, ganz andere Geräte zu steuern. In dem Zusammenhang will 87insane eben erst in dem "Zwischendevice" einen 0-100-level-Wert haben, obwohl er das nur als brightness bekommt (der hub kann auch 100-er Werte senden, afaik).

MMn. ist aber das Bilden dieser Zwischenwerte unnötig.

Vielleicht noch zum allgemeinen Verständnis dieser bereits verlinkten myUtils:
Man nimmt die FB und legt für jeden Kanal (hier 0-7) ein MQTT2_DEVICE an. Da wir uns - im Unterschied zu normalen Lampen - nicht für den Gesamtzustand interessieren, wird alles direkt verworfen, was im "states"-Zweig kommt, es interessieren nur "updates" (dafür gibt es ein attrTemplate!).
Jetzt kann man für jedes dieser 7 "Kanaldevices" ein notify anlegen, das dann jeden Event (bzw. eine Auswahl der Events) an dem Kanaldevice abgreift und an eine bestimmte myUtils-sub weiterreicht.

Welche sub die richtige ist, bestimmt sich nach dem Zieldevice. Das wird mit in die sub übergeben, zusammen mit dem Event. Die sub leitet dann eben eine Aktion für das übergebene Zieldevice ab, that's all. Die Schwierigkeit die 87insane jetzt haben dürfte: Ich habe nur eine Funktion integriert, die eingehende CCT-Messages in RGBW-Anweisungen "umwandelt", dabei aber innerhalb der 0-255-Skala bleibt.

Lösungsmöglichkeit:
Einen weiteren (optionalen Parameter) einführen, aus dem sich ergibt, ob das Zieldevice "pct" spricht (=umrechnen, Command=pct) oder "brightness" (keine Umrechnung, Command=brightness).
Dabei muß aber das "Kanaldevice" gar nicht wissen, was das eigentliche Zieldevice "spricht" und daher eigentlich auch keinen Rechenwert vorhalten...

Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: ZigBee2mqtt, MiLight@ESP-GW, BT@OpenMQTTGw | ZWave | SIGNALduino | MapleCUN | RHASSPY
svn: u.a Weekday-&RandomTimer, Twilight,  div. attrTemplate-files, MySensors

87insane

@TomLee:
level wird NUR gesetzt wenn die entsprechende Zone auf ON steht. brightness kommt aber auch wenn die Zone off ist. Deswegen MUSS ich selber rechnen. Ich habe eine FB. Auf dieser steuere ich z.B. Rollos via dem Helligkeitsregler. Das mache ich dann in Prozent da ich es auch so direkt dem Rollo übergeben kann. Unten auf der FB sind Taste wie Mode, Speed_up usw. Diese nutze ich um mir ein anderes Rollo zu wählen.
Beispiel: Die FB liegt IMMER im WZ. Deswegen ist der erste Knopf jeder Zone auch einer Funktion im WZ zugeordnet. Will ich nun aber Licht, Rollo oder so im z.B AZ steuern setze ich mir mit Tastendruck auf z.B. Mode ein Reading mit dem Wert des zu steuernden Raumes. Da jede Zone aber ein ON und OFF hat, was ich direkt auch zum ein und ausschalten des ersten Gerätes nutze, muss ich also im OFF Zustand der Zone, selber um rechnen. Im Zustand OFF einer Zone, kommen die Grund Daten wie brightness trotzdem in der Zone an und ich kann sie also verwerten.

@Beta-User: Ich habe NICHTS in meiner Utils. Ich habe bis heute nicht verstanden wofür auch. Habe mich aber auch nie groß damit auseinander gesetzt, da ich keine Vorteile kenne. Ich weiß nichts von dem bereits existierenden Rad, weswegen ich ja hier fragte.
Mein Szenario ist schon sehr speziell aber ich glaube das es viele Personen nutzen könnten, da wohl der ein oder andere User auch eine FB nutzen wollen würde mit solchen "Hey Arnold" Funktionen.

Wen es interessiert... Ich liefere natürlich auch alle Infos am Ende.
Bei mir geht bisher Rollo (Helligkeits Schiebregler auf FB wird in % an gewähltes Rollo weiter gegeben), LED (RGB, Helligkeit, Farbtemperatur oder ww/cw, Effekte), Deckenlicht Steuerung (An / Aus, wer dimmen wollen würde, geht natürlich auch. Hab nur keine solcher Leuchten). Zu steuernder Raum ist wählbar.

Beta-User

Das mit dem Rad:

https://wiki.fhem.de/wiki/MQTT2-Module_-_Praxisbeispiele#Fernbedienung_als_Input-Device_nutzen

Da steht schon eine ganze Zeitlang ein Link:
Zitat von: Beta-User am 09 September 2019, 15:28:47
Zwischenstand:

       
  • die Basisfunktionen meines MPD lassen sich steuern (über Kanal 0, damit die on/off-Tasten besser zugänglich sind)
  • 2 MiLight-Bulbs mit V5-Protokoll gehen vollständig (indirekt) mit der V6-remote zu steuern
  • derselbe Code kann genutzt werden, um dimmbare HUEDevice's zu steuern (Farbe/Farbtemp: geht (Farbe: eventuell) noch nicht, weiß noch nicht, ob ich Farbtemperatur überhaupt brauche)
  • Die Deckenlichter im Wohnzimmer (2*2 on/off Kanäle) belegen eine Steuerungsebene (in der Praxis: zwei ZWave switches), derzeit genutzt: 6 Tasten dieser Ebene. Mal schauen, ob ich da noch Szenen auf die verbleibenden 3 Slider legen will - mind. die Hellighkeits- und Saturation-Slider scheinen ziemlich exakt zu funktionieren, da sollten je 5 "virtuelle" Tasten möglich sein...
  • und zu guter letzt: Zwei Rolläden (CUL_HM) und eine Jalousie (ZWave FGR-223, incl. Lamellenstallung 8) ) folgen auch der FB.
Einziges "Manko": Man muß teilweise die (on) Tasten (gewollt!) doppelt drücken, damit nicht das Aktivieren einer Belegungsebene gleich eventuell unbeabsichtigte Folgen in der Realität hat.

Soweit also erst mal: volle Zufriedenheit 8) , coole Sache. Auch die Reichweite ist für meine Zwecke völlig ausreichend (vergleichbar mit der WLAN-Ausleuchtung).
Du hast jetzt nur den link auf meine PBP-aktualisierte Fassung erhalten, aber inhaltlich ist das immer noch aktuell.

Die Vorteile der myUtils-Variante sind:
- Du hast nicht jedes Mal eine DEF-Änderung, wenn du am Code schraubst. myUtils in FHEMWEB bearbeiten, dort speichern, testen => kein Problem.
- Es ist etwas universeller gemacht und nicht zu hart mit einer bestimmten Art Zieldevice "verbandelt": ZWave-Rollo-Aktoren brauchen etwas andere Commands als HomeMatic, aber der Code weiß, mit wem er es zu tun hat und macht den Rest automatisch...
- Man kann es daher sehr gut teilen, ohne dass jeder wieder selbst von Grund auf am Rad feilen muß.

Aber wenn du eine andere gute Lösung hast: Auch interessant; ich habe das damals so zusammengeschustert, dass es für mich Sinn macht, aber das will nicht viel heißen...
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: ZigBee2mqtt, MiLight@ESP-GW, BT@OpenMQTTGw | ZWave | SIGNALduino | MapleCUN | RHASSPY
svn: u.a Weekday-&RandomTimer, Twilight,  div. attrTemplate-files, MySensors

87insane

Hab bei mir alles fertig nur keine Lust auf pc heute. Hab alles drin wie ich wollte. Damit das auch Anfänger hinbekommen habe ich das ganze mit mswitch gelöst. Gleiches geht natürlich auch mit notify, doif usw. Was ich für die FB so interessant finde ist das ich in mswitch, mit klicken was anpassen könnte. Ist also eine wunderbare Verwaltungs Übersicht für sowas.

Habe das auch über aktivierte Ebenen gestaltet. Ebene 0 = decken Lichter. Ebene 1 = Rollos, Ebene 2 LED Lichter. Hab zb die Mode, speedup Button missbraucht um innerhalb einer Ebene zb ein anderes Rollo oder Licht zu wählen.

Liefere das alles noch nach. Fummel gerade ein wenig an IKEA u zigbee2mqtt rum. Aber auch nur am handy aktuell.

Beta-User

Nun ja, da MSwitch nicht mehr via svn verfügbar ist, wäre das dann keine Lösung mehr, die ich via svn verteilen werde. Bin trotzdem mal gespannt, was da rausgekommen ist (auch wenn ich mit MSwitch gar keine Erfahrung habe).
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: ZigBee2mqtt, MiLight@ESP-GW, BT@OpenMQTTGw | ZWave | SIGNALduino | MapleCUN | RHASSPY
svn: u.a Weekday-&RandomTimer, Twilight,  div. attrTemplate-files, MySensors