LIchtbaustein Lumitech Ausgang per MQTT zu Philips HUE über Zigbee2mqtt
Hab jetzt mal auf die Schnelle gesucht aber nix gefunden.
Hat das hier schon mal jemand sauber umgesetzt also so, das sowohl über die Warmweiss/Kaltweis Einstellung als auch die Farbrad Einstellung genutzt werden kann.
Also Lichtbaustein an einem Lumitech DMX Ausgang raus, dann über Formel, Status.... in zu Virtuellen Ausgänge für Loxberry MQTT
Die reine TW (Kalt/Warmweiss) Variante hab ich schon lange mehrfach in Verwendung, jetzt wollte ich für eine Lampe welche auch Farbe kann das gnaze mit dem Farbrad erweitern und scheitere auf die Schnelle kläglich.
Mein naiver Ansatz war, das ich einfach abhängig vom Lumitech Status (TW oder RGB) zwischen der Helligkeit+Kelvin Ausgabe und der RGB Ausgabe zu MQTT umschalte.
Hier gibt es jedoch Probleme, zum einen reichen Philips die reinen RGB Werte nicht hier muss zusätzlich auch die Helligkeit mit übergeben werden, (WTF die ist doch schon in den RGB Werten enthalten !!!)
Hier müsste man nun die Helligkeit erst mal wieder aus den RGb Werten zusätzlich berechnen. OK das ließe sich wohl machen, jetzt kommt aber ein weiteres Problem hinzu, obwohl ich im TW Modus die Ausgabe des Steuerstrings für MQTT über einen Statusbaustein "gate" wird über den VA eine Ausgabe auch dann gemacht wenn ich nur TW verstelle.
Ich habs bisher nicht begriffen wie das zustande kommt aber somit funktioniert keine TW Steuerung mehr.
Bin aktuell etwas ratlos.
Ideen ?
EDIT:
Ich glaub ich hab jetzt erst mal ne Lösung gefunden auch wenn die extrem aufwändig erscheint.
1. erst ma wird ausgewertet ob der Lumitech Wert TW oder RGB ist, abhängig davon werden Kelvin und Helligkeit berechnet und über MQTT gesendet oder aber es wird der RGBWert in einzelnen Werte zerlegt diese dann in HSV umgerechnet und dann per MQTT gesendet.
Das Problem mit dem ständigen überschreiben des TW Werts durch die RGB bzw nun HSV Ausgang hab ich durch eine Einschaltverzögerung gelöst welche das "Gate" Signal auf I4 der Status Bausteins erzeugt, also erst wenn für 0,1 Sekunde eine 1 anliegt dann gibt der Status was raus.
Warum es das brauch liegt vermutlich am Lumitech Ausgang welcher obwohl die TW Auswahl in der UI nicht verlassen wird immer mal wieder RGB Werte ausgibt.
Ein wildes Gebastel aber was elegantes ist mir nicht eingefallen. (Sch.... Philips HUE, wer lässt sich RGB Werte geben wo dann die Helligkeit ignoriert wird ???)
verwendet Formeln:
1) Rot aus Lumitech RGB Wert:
2) Grün aus Lumitech RGB Wert:
3) Blau aus Lumitech RGB Wert:
4) Helligkeit aus Lumitech TW Wert:
5) Kelvin aus Lumitech TW Wert:
6) HSV "H" Wert aus RGB Werten berechnen
7) HSV "S" Wert aus RGB Werten berechnen
8) HSV "V" Wert aus RGB Werten berechnen
Status Baustein Text (RGB zu HSV):
Status Baustein Text (RGB + Helligkeit):
Analog Min/Max Begrenzer:
Skalierer:
Einschaltverzögerung:
Version mit RGB zu HSV
EDIT 2:
Ich hab ne weitere Version mit RGB und Helligkeit also ohne den Umweg über die HSV Wandlung hinbekommen.
Der Trick war der getrennte Helligkeits Ausgang zu MQTT auch für RGB welcher nun zwischen TW und RGB gemultiplext wird und somit das Umschalttiming (bzw. die Sendereihenfolge von "Kelvin + Helligkeit" und "Helligkeit + RGB" für die MQTT Ausgabe passt.
Auch die TW/RGB Erkennung des Lumitech Ausgangs über den Limiter und das Vergleichen ob der Limiter zugeschlagen hat gibt ein Problem, hier kommt es wohl durch Laufzeitunterschiede zu Fehlern und mehrfach Trigger (das war in früheren Loxone Config/Firmware Versionen noch nicht der Fall) ich hab hier deshalb nun auf einen simplen Vergleicher Baustein gesetzt.
Version mir RGB und Helligkeit:
Hab jetzt mal auf die Schnelle gesucht aber nix gefunden.
Hat das hier schon mal jemand sauber umgesetzt also so, das sowohl über die Warmweiss/Kaltweis Einstellung als auch die Farbrad Einstellung genutzt werden kann.
Also Lichtbaustein an einem Lumitech DMX Ausgang raus, dann über Formel, Status.... in zu Virtuellen Ausgänge für Loxberry MQTT
Die reine TW (Kalt/Warmweiss) Variante hab ich schon lange mehrfach in Verwendung, jetzt wollte ich für eine Lampe welche auch Farbe kann das gnaze mit dem Farbrad erweitern und scheitere auf die Schnelle kläglich.
Mein naiver Ansatz war, das ich einfach abhängig vom Lumitech Status (TW oder RGB) zwischen der Helligkeit+Kelvin Ausgabe und der RGB Ausgabe zu MQTT umschalte.
Hier gibt es jedoch Probleme, zum einen reichen Philips die reinen RGB Werte nicht hier muss zusätzlich auch die Helligkeit mit übergeben werden, (WTF die ist doch schon in den RGB Werten enthalten !!!)
Hier müsste man nun die Helligkeit erst mal wieder aus den RGb Werten zusätzlich berechnen. OK das ließe sich wohl machen, jetzt kommt aber ein weiteres Problem hinzu, obwohl ich im TW Modus die Ausgabe des Steuerstrings für MQTT über einen Statusbaustein "gate" wird über den VA eine Ausgabe auch dann gemacht wenn ich nur TW verstelle.
Ich habs bisher nicht begriffen wie das zustande kommt aber somit funktioniert keine TW Steuerung mehr.
Bin aktuell etwas ratlos.
Ideen ?
EDIT:
Ich glaub ich hab jetzt erst mal ne Lösung gefunden auch wenn die extrem aufwändig erscheint.
1. erst ma wird ausgewertet ob der Lumitech Wert TW oder RGB ist, abhängig davon werden Kelvin und Helligkeit berechnet und über MQTT gesendet oder aber es wird der RGBWert in einzelnen Werte zerlegt diese dann in HSV umgerechnet und dann per MQTT gesendet.
Das Problem mit dem ständigen überschreiben des TW Werts durch die RGB bzw nun HSV Ausgang hab ich durch eine Einschaltverzögerung gelöst welche das "Gate" Signal auf I4 der Status Bausteins erzeugt, also erst wenn für 0,1 Sekunde eine 1 anliegt dann gibt der Status was raus.
Warum es das brauch liegt vermutlich am Lumitech Ausgang welcher obwohl die TW Auswahl in der UI nicht verlassen wird immer mal wieder RGB Werte ausgibt.
Ein wildes Gebastel aber was elegantes ist mir nicht eingefallen. (Sch.... Philips HUE, wer lässt sich RGB Werte geben wo dann die Helligkeit ignoriert wird ???)
verwendet Formeln:
1) Rot aus Lumitech RGB Wert:
Code:
I1 - (INT(I1/1000000)*1000000) - (INT((I1-INT(I1/1000000)*1000000)/1000)*1000)
Code:
INT((I1-INT(I1/1000000)*1000000)/1000)
Code:
INT(I1/1000000)
Code:
int(Int((I1-200000000)/10000)*2,55)
Code:
(((I1-200000000)/10000)-(Int((I1-200000000)/10000)))*10000
Code:
(ARCTAN(SQRT(3)*(I2-I3)/((2*I1-I3-I2)+1-SIGN(ABS(2*I1-I3-I2))))*SIGN(ABS((2*I1-I3-I2)))/PI+((SIGN((2*I1-I3-I2))-1)/2*SIGN(I3-I2-0,001)+(1-SIGN(SIGN(I2-I3)+1))*2)*SIGN(ABS(2*I1-I3-I2)+ABS(I2-I3)))*180
Code:
(I2-I1)/I2*100
Code:
I1/2,55
Code:
zigbee2mqtt/HUERGBTEST/set {"color": {"h":<v1>,"s":<v2>,"v":<v3>}}
Code:
zigbee2mqtt/HUERGBTEST/set {"color": {"r":<v1>,"g":<v2>,"b":<v3>}}
Analog Min/Max Begrenzer:
Code:
200002700 - 201006500
Code:
2700 -> 500 6500 -> 150
Code:
0,1s "invertierter Eingang"
EDIT 2:
Ich hab ne weitere Version mit RGB und Helligkeit also ohne den Umweg über die HSV Wandlung hinbekommen.
Der Trick war der getrennte Helligkeits Ausgang zu MQTT auch für RGB welcher nun zwischen TW und RGB gemultiplext wird und somit das Umschalttiming (bzw. die Sendereihenfolge von "Kelvin + Helligkeit" und "Helligkeit + RGB" für die MQTT Ausgabe passt.
Auch die TW/RGB Erkennung des Lumitech Ausgangs über den Limiter und das Vergleichen ob der Limiter zugeschlagen hat gibt ein Problem, hier kommt es wohl durch Laufzeitunterschiede zu Fehlern und mehrfach Trigger (das war in früheren Loxone Config/Firmware Versionen noch nicht der Fall) ich hab hier deshalb nun auf einen simplen Vergleicher Baustein gesetzt.
Version mir RGB und Helligkeit: