HUEDevice - set rgb funktioniert nicht

ares · 19 März 2016, 15:03:46

Ich folgende Komponenten neu in fhem eingebunden:

Philips hue bridge 2015
swversion 01031131
apiversion 1.12.0
Hue LightStrips Plus (LST002)
swversion 66016151
NAME HUEDevice3

Farbe auf rot setzen funktioniert:

set HUEDevice3 rgb FF0000

Farbe auf blau setzen funktioniert:

set HUEDevice3 rgb 0000FF

Farbei auf grün setzen ändert die Farbe nicht, die HueBridge meldet aber invalid value, -0.7836, for parameter, xy

Code Auswählen

set HUEDevice3 rgb 00FF00

Auch andere Werte verursachen Probleme invalid value, -0.3212, for parameter, xy

Code Auswählen

set HUEDevice3 rgb 11FF11

Hat jemand eine Idee, was bei mir falsch läuft?

VG
Manfred

justme1968 · 19 März 2016, 15:21:35

je nach leuchtmittel können manche farben nicht dargestellt werden. das betrifft vor allem reine rgb farbtöne. im modul gibt es noch keine prüfung darauf.

verwende etwas abgetönte farben.

zum einstellen ist der hue parameter und hue slider besser geeignet.

gruss
andre

ares · 19 März 2016, 15:24:06

Hallo andre,

vielen Dank für die schnelle Rückmeldung, jetzt muss ich wenigstens nicht weiter suchen.
Das manuelle setzen war nur ein Test, die Farben sollen eigentlich über smartVisu geändert werden. Leider habe ich dort keine andere Möglichkeit gefunden.

Vielen Dank
Manfred

Physiker · 19 März 2016, 21:37:24

Verwende seit Anfang des Jahres Lightify/HueDevice mit mehreren Lampen. Es lief problemlos. Seit einem Update von FHEM (neue Lightify-Version vom 23. Jan.) funktioniert die Farbeinstellung über rgb (z.B. "set SZ_Lampe rgb ff0202") nicht mehr. Alle anderen Funktionen (on/off/hue/pct) laufen OK.

Im Log-File sieht man, dass der rgb-Wert wohl NICHT gesetzt wird:
2016.03.19 19:33:19 5: Cmd: >set SZ_Lampe rgb 0303fe<
2016.03.19 19:33:19 4: Osram: sending:14000036670000009B6DDA0000261884000000ff0200
2016.03.19 19:33:19 4: parse status message for SZ_Lampe
2016.03.19 19:33:19 5: Triggering SZ_Lampe (5 changes)
2016.03.19 19:33:19 5: Notify loop for SZ_Lampe bri: 0
2016.03.19 19:33:19 5: Triggering SZ_Lampe (1 changes)
2016.03.19 19:33:19 5: Notify loop for SZ_Lampe rgb: 000000
2016.03.19 19:33:19 4: Osram: enque:13 00 00 00 00 01

Dagegen findet man im Log-File das korrekte Setzen des rgb-Wert, wenn der Befehl hue verwendet wird:
2016.03.19 19:32:54 5: Cmd: >set SZ_Lampe hue 0<
2016.03.19 19:32:54 4: Osram: sending:14000036650000009B6DDA0000261884ff0202ff0200
2016.03.19 19:32:54 4: parse status message for SZ_Lampe
2016.03.19 19:32:54 5: Triggering SZ_Lampe (1 changes)
2016.03.19 19:32:54 5: Notify loop for SZ_Lampe hue: 0
2016.03.19 19:32:54 5: Triggering SZ_Lampe (1 changes)
2016.03.19 19:32:54 5: Notify loop for SZ_Lampe rgb: ff0202
2016.03.19 19:32:54 4: Osram: enque:13 00 00 00 00 01

Ist die ein Update-Problem von 30_LIGHTIFY.pm oder mache ich etwas falsch?

ares · 20 März 2016, 10:39:58

Hallo andre,

Zitat von: justme1968 am 19 März 2016, 15:21:35
im modul gibt es noch keine prüfung darauf

Ich habe im Modul 31_HUEDevice.pm noch vier Zeilen ergänzt und mit ares markiert:

Code Auswählen

      # calculation from http://www.everyhue.com/vanilla/discussion/94/rgb-to-xy-or-hue-sat-values/p1

      my $X =  1.076450 * $r - 0.237662 * $g + 0.161212 * $b;
      my $Y =  0.410964 * $r + 0.554342 * $g + 0.034694 * $b;
      my $Z = -0.010954 * $r - 0.013389 * $g + 1.024343 * $b;
      #Log3 $name, 3, "rgb: ". $r . " " . $g ." ". $b;
      #Log3 $name, 3, "XYZ: ". $X . " " . $Y ." ". $Y;

      if( $X != 0
          || $Y != 0
          || $Z != 0 ) {
        my $x = $X / ($X + $Y + $Z);
        my $y = $Y / ($X + $Y + $Z);
        #Log3 $name, 3, "xyY:". $x . " " . $y ." ". $Y;

        $Y = 1 if( $Y > 1 );

        #--------- ares ---------
        $x = 0 if( $x < 0);
        $x = 1 if( $x > 1);
        $y = 0 if( $y < 0);
        $y = 1 if( $y > 1);
        #--------- ares ---------

        my $bri  = maxNum($r,$g,$b);
        #my $bri  = $Y;

        $obj->{'on'}  = JSON::true;
        $obj->{'xy'}  = [0+$x, 0+$y];
        $obj->{'bri'}  = int(254*$bri);

Eventuell kannst Du die Änderung ja in künftige Versionen mit aufnehmen.

Danke
Manrfed

justme1968 · 20 März 2016, 10:56:06

hallo manfred,

das würde die negativen werte abfangen. ich baue es ein, aber das macht nur zum teil was du möchtest. zum einen verfälscht es die fragen und zu anderen ist die form des erlaubten farbraumes anhängig von jeweiligen leuchtmittel ein dreieck und kein quadrat. d.h. es gibt auch unterhalb von 1 viele nicht erlaubte werte.

aber deine fehler sollten zumindest weg sein.

gruss
andre

ares · 20 März 2016, 15:14:28

Hallo andre,

die API versucht automatisch, Werte zwischen 0 und 1 an das mögliche Dreieck anzupassen. Negative Werte und Werte größer 1 erzeugen jedoch den beschriebenen Fehler. Für mich ist in smartVisu eine "ähnliche" Farbe besser als gar keine Farbänderung.

ZitatIf an xy value outside of bulbs relevant Gamut triangle is chosen, it will produce the closest color it can make.

Quelle: http://www.developers.meethue.com/documentation/core-concepts

Danke
Manfred

justme1968 · 20 März 2016, 15:34:24

jein... leider ist es nicht ganz so einfach.

in dem verlinkten artikel ist mit api das iOS (oder android) sdk gemeint. wenn man die bridge auf json api ebene ansteuert muss man sich selber darum kümmern die nächst gelegene farbe zu suchen. wenn man einen wert ausserhalb des möglichen farbraumes wählt wie z.b. 1,1 wird der wert angenommen und man bekommet keine rückmeldung das der punkt ausserhalb des möglichen farbraumes ist. irgendwann später bekommt man eventuell eine rückmeldung mit der tatsächlichen farbe.

die berechnung selber zu machen ist zwar im prinzip einfach... aber die von phillips veröffentlichten daten zum farbraum scheinen nicht zu stimmen. wenn man die veröffentlichten paramter zur umwandlung aus dem rgb raum nimmt stimmen die farben nicht. das problem haben auch noch andere bemerkt. die routine die im hue modul verwendet wird nimmt komplett andere parameter bei denen die farben halbwegs stimmen, das korrekte schneiden mit dem farbraum dreieck funktioniert damit aber nicht.

wie gesagt: ich habe das cliping auf 0..1 eingebaut.

gruss
andre

ps: die quellen kenne ich. sonst gäbe es das modul nicht

Skell · 04 Dezember 2018, 12:14:53

Moin,

ich möchte mich hier mal mit einem ähnlichen Problem melden, ohne einen neuen Thread aufmachen zu müssen.

Ich habe mit einem DOIF eine Lichtschleife laufen die durch einen Bewegungssensor für eine bestimmte Zeit unterbrochen wird um eine bestimmte Farbe einzuschalten.

Leider schaltet er die falsche Farbe ein.

Meine DEF:

Code Auswählen


( 
	[WZ_Bewegung:state] eq "motion" and
	[?Light_Status:twilight_weather] > 66	
)
		(
		set FL_Stern_Licht effect none,
		set FL_Stern_Licht bri 254,
		set FL_Stern_Licht sat 254,
		set FL_Stern_Licht rgb ffb371,
		set FL_Stern_Licht rgb ffb371
		)
	
DOELSEIF 
(( 
	[FL_Bewegung:state] eq "nomotion" and
	[{sunset}-{sunrise}] and 
	[HomeStatus:STATE] ne "4"		
))
	
		(
		set FL_Stern_Licht bri 200,
		set FL_Stern_Licht sat 200,
		set FL_Stern_Licht effect colorloop
		)	
		
DOELSE
(	
		set FL_Stern_Licht off
)

Die Readings:

bri		254
colormode		hs
ct		337 (2967K)
effect		none
hue		65523
onoff		1
pct		100
reachable		1
rgb		ff0000
sat		254
state		on
xy		0.4399,0.3657

Wenn ich die RGB Zeile nur einmal drin stehen habe, schaltet er immer auf rot. Dadurch das ich die derzeit zwei mal drin stehen habe, schaltet er auf eine "ähnliche" Farbe ffb371 über ff0000. Manchmal schaltet er jedoch trotzdem nur auf ff0000.
Mit ähnlich meine ich, dass die Farbe anders ist als sie sein sollte, es steht aber zumindest FFB371 drin in FHEM. Vermute einfach mal das es noch eine Einstellung der Sättigung und Kelvin zahl ist.

Hauptproblem ist, dass er nicht direkt auf die Farbe sondern entweder nach oder über FF0000 springt wenn ich die Zeile zwei mal drin stehen habe, was auch sichtbar ist und nervt.

Jemand eine Idee woran es liegt und wie man das lösen kann, dass er sofort auf die gewünschte und richtige Farbe springt?

Gruß

justme1968 · 04 Dezember 2018, 12:25:04

bri, sat (und hue) mit RGB zu kombinieren ist nicht sinnvoll.

bitte schau mal im wiki wie das mit den farbmodellen funktioniert. und dann entscheide dich für eines.

entweder bri, sat, hue oder xy oder rgb. wobei rgb intern nach hsv umgerechnet wird.

wenn du ohne transition time schaltest wird immer zur ziel farbe hin geblendet.

Skell · 04 Dezember 2018, 14:05:43

Zitat von: justme1968 am 04 Dezember 2018, 12:25:04
bri, sat (und hue) mit RGB zu kombinieren ist nicht sinnvoll.

bitte schau mal im wiki wie das mit den farbmodellen funktioniert. und dann entscheide dich für eines.

entweder bri, sat, hue oder xy oder rgb. wobei rgb intern nach hsv umgerechnet wird.

wenn du ohne transition time schaltest wird immer zur ziel farbe hin geblendet.

Danke für den input, darauf habe ich bisher nicht geachtet.

Hab es nun in

Code Auswählen


		set FL_U_Stern_Licht effect none, 
		set FL_U_Stern_Licht hue 14743 : sat 254 : bri 254 : transitiontime 2

umgeändert.

Hat nun die Farbe wie ich es haben will. Interessanterweise wird es in FHEM als grün angezeigt obwohl es eher gelblich/orange ist