Da ich etwas angepasst habe ich ich aktuell noch nicht den Problem verstehe vielleicht schon. Aber wenn ein Fehler enthalten ist, würde ich ihn in Groups fixen und dann später nach master ziehen.
Ich habe mal eine Frage an euch bzgl. der Farbtemperatur und dem Wert der Übergabe.
Möglichkeit 1)
Ihr übergebt und erhaltet den Wert wie die API in Erwartet in der Einheit „Mirek“. Sprich der Wertebereich wäre 500-153.
Möglichkeit 2)
Ihr übergebt und erhaltet den Wert zwischen 0-255 und ich rechne ihn in Mirek um. (im branch groups aktuell default)
Möglichkeit 3)
Ihr übergebt und erhaltet den Wert in Kelvin und ich rechne ihn in Mirek um. (ungern)
Aktuell schwanke ich zwischen Möglichkeit 1 und 2. Bei Möglichkeit 1 brauche ich keine Umrechnung vorzunehmen, wodurch auch keine Umrechnungsungenauigkeiten entstehen.
Möglichkeit 2 ist halt einfacher umzusetzen, da die Schieberegler für den Wertebereich 0-255 bereits vorhanden sind.
Wie seht Ihr das?
Ich lag am Wochenende ,it Grippe flach, deshalb jetzt erst die Antwort.
Ich vermute das kommt von meinem in der Bridge eingebundenen Osram Plugg. Der kann nur ein oder aus 
Auf vielen erhältlichen Leuchtmitteln wird mittlerweile die Farbtemperatur in Kelvin angegeben.
Wenn man im Internet nach „Farbtemperatur Einheit“ sucht, wird in der Mehrheit der Treffer Kelvin als Einheit für die Farbtemperatur angegeben.
Um die Abstimmung der Hue-Leuchten mit anderen Leuchtmitteln oder anderen Beleuchtungssystemen nicht unnötig zu erschweren, halte ich es für sinnvoll, die Farbtemperatur, wie üblich, in Kelvin anzugeben und angezeigt zu bekommen.
Gruß
Ralla
P.S.
Bei der Gelegenheit: „Danke für das Modul“.
Hm, Möglichkeit 1 finde ich am unpraktischsten, wenn ich hier einen bestimmt wert erzielen möchte muss erst mal kompliziert umgerechnet werden.
Also ehrlich gesagt fände ich die Möglichkeit mit Kelvin auch am praktikabelsten.
Die Möglichkeit einen Kelvin wert per App einzustellen fande ich auch als einzige Option bei den Osram Lightify sehr gut, würde ich mir in der hue App auch wünschen…oder am besten noch per IPS ;)
Aber mal sehen was die anderen sagen.
Naja, die Kelvinangabe würde man ja nur bei Scripten angeben. In der App selber arbeiten ich ja immer mit Slidern. Da der Wertebereich immer gleich ist (500 bis 153), ergibt das 347 verschiedene Einstellmöglichkeiten.
Würde ich nun in Kelvin arbeiten, hätte ich aber 4500 Einstellmöglichkeiten (2000-6500 Kelvin) die ich auf 347 Möglichkeiten umrechnen müsste. Dass ergibt, wie mehr ich jetzt drüber nachdenke, keinen Sinn. Wegen dem Umrechnen präferiere ich mehr zur Variante 1, da man nur so alle Einstellmöglichkeiten abbilden kann.
Im Branch „groups“ ist nun die Variante mit Mired enthalten.
Das habe ich sogar vermutet und sollte mit der neuen Version aus dem Group-Branch nun gehen.
Und wenn ich nun 2600K einstellen möchte (per script), errechne ich das wie?
Die Formel ist
1000000/2600 = 384,6153846154
Wie man hier schon sehen kann ist der Wert ungerade und du musst ihn Runden.
Also würdest du 385 übergeben.
Selbst 6500 Kelvin ergeben 153,846153846153846 aber die Range geht nur bis 153 somit muss hier sogar abgerundet werden.
Ich habe soeben den Gruppensupport nach Master geschoben!
Mit dem Support für Gruppen wurden auch die Wertebereich für SetValues aktualisiert. Ihr müsste vorhanden Scripte anpassen. Der Wertebereich für Helligkeit und Sättigung bei Set und Get Funktionen liegt jetzt bei 0-255. Die Farbtemperatur liegt nun zwischne 500 und 153 (mired)
Würde ich nun in Kelvin arbeiten, hätte ich aber 4500 Einstellmöglichkeiten (2000-6500 Kelvin) die ich auf 347 Möglichkeiten umrechnen müsste. Dass ergibt, wie mehr ich jetzt drüber nachdenke, keinen Sinn. Wegen dem Umrechnen präferiere ich mehr zur Variante 1, da man nur so alle Einstellmöglichkeiten abbilden kann.
Warum das?
Wenn man für den Slider eine Schrittweite von 4500/(347-1) also gerundet 13 wählt, ergeben sich doch auch nur 347 mögliche Werte.
Okay der maximale Wert betrüge nur 6498 statt 6500, aber wer erkennt den Unterschied?
Der Ansatz von IP-Symcon ist es doch hersteller- und systemübergreifend zu arbeiten. Daher sollte man, meiner Meinung nach, auch allgemein übliche Einheiten für die Darstellung von Einstellwerten verwenden.
Wäre das nicht sinnvoll?
Gruß
Ralla
So, ich habe gerade mal etwas herumgespielt. Mit dem linearen Slider lässt sich das nicht vernünftig abbilden. Der läßt auch nur 100 verschiedene Einstellwerte zu. Vielleicht funktioniert es mit der Wertauswahl.
Wobei mir einhundert verschiedene Einstellwerte ausreichen würden, solange die Einheit stimmt.
Ach, ich sehe gerade die Entscheidung ist wohl schon gefallen.
Dies ist natürlich dein gutes Recht und ich will mich auch nicht beschweren.
Aber, warum fragst du dann?
Gruß
Ralla
So, gerade erst zum testen gekommen, aber ich kann immer noch kein array übergeben 
Identischer Fehler, alle Instanzen gehen auf Fehler, nix passiert…
HUE_SetValues($lightID, array('COLOR_TEMPERATURE' => "365", 'BRIGHTNESS' => "179"));
Im Log steht jetzt:
22.12.2016 19:07:41*| HUE_Bridge*| stdClass Object
(
[type] => 7
[address] => /lights/1/state/bri
[description] => invalid value, 179 ,, for parameter, bri
)
Ich habe das gerade mal getestet. Der Fehler ist das du die Zahl als String übergeben hast. Außerdem muss man STATE=true mitgeben, sonst jammert er wenn die Lampe aus ist.
HUE_SetValues(24523 /*[System\Philips Hue\Lampen\Die Lampe]*/, array('STATE' => true, 'COLOR_TEMPERATURE' => 365, 'BRIGHTNESS' => 179));
TODO: An mich selber: Werte per CAST umwandeln 
Weil ich zum Zeitpunkt der Frage, noch nicht die Konsequenz gesehen habe bzgl. der Umrechnung. Und ich muss die Werte zischen Kelvin und Mired in in beide Richtungen umrechnen können ohne das es durch Rundungsfehler zu verschiedenen Ergebnissen kommt. Außerdem in Schritten zu springen ist ach unsauber vor allem auf der API.
Hier würde jemand dann 6500 übergeben würde der Wert niemals stehen bleiben und das Verursacht noch viel mehr Verwirrung.
Somit bleibt die Frage nur: Slider (0-255) oder Miredeingabe welche immer 100% genau ist. Ein weiterer Vorteil von Mired ist, das ich dann in der Auswahl 3 Werte (als Fav) speichern kann. Und ich jeden Umrechnungsfehler vermeide.
Mir ist noch aufgefallen das die Gruppen nicht aktualisiert werden…
Habe ich integriert!
Danke, passt nun.
Allerdings muss ich zugeben, dass ich mit der Mired Angabe zur Farbtemperatur auch unzufrieden bin. Gerade für die visualisierung, da kann echt keiner was mit anfangen, an die Kelvin Angabe hat man sich mittlerweile gewöhnt.
Kann man da wohl doch noch mal was ändern?!
Solange ich keine Formel habe, welche in beide Richtungen funktioniert ohne Rundungsfehler - nein.
Alternativ müssten die Jungs von Symcon einen Regler einbauen, welcher zwar von 500-153 arbeitet, aber die Zahl vor der Anzeige durch eine „Anzeige“-Funktion schickt. Dann könnte man die Anzeige dynamisch berechnen ohne den zugrunde liegenden Werte zu errechnen.
Hm, ok. Alternativ würde mir auch ein whitelight-slider gefallen.
Also komplett ohne Werte, nur eine Optische Darstellung der Farbtemperatur.
Müsste aber wohl auch durch IPS geliefert werden!?