Hue adapter
-
So, Gruppen sind drin, kannst du es mal Testen? Ich habe es nur mit einer Testgruppe probiert, da ich bisher keine Gruppen nutze.
https://github.com/Pmant/ioBroker.hue
Ebenfalls sollten keine Channels mehr erstellt werden, wenn es doppelte Namen geben würde. Wenn zwei Lampen mit den Namen "Lampe 1" und "Lampe_1" in Hue existieren wird "Lampe_1" nicht erstellt, da in ioBroker beide den selben Namen "Lampe_1" hätten. Gleiches gilt für Gruppen sowie Gruppen, welche den gleichen Namen wie eine Lampe haben. Beides habe ich aber bisher nicht getestet :roll: , theoretisch sollte die Lampe/Gruppe nicht erstellt werden und im Log eine Warnung erscheinen.
-
Wow… das ist ja eine Geschwindigkeit!
Das Teste ich sofort, sobald ich wieder in der Reichweite meiner Bridge bin
Ich werde selbst die Gruppen aus hue nicht verwenden, da ich das Gefühl habe, dass ich mit in ioBroker definierten Gruppen flexibler bin und nicht in zwei Apps pflegen muss. Testen werde ich es aber so schnell wie möglich :).
Vielleicht muss ich aber auch noch umdenken, wenn die selbst definierte Gruppen zu viel Traffic erzeugen
Klasse Arbeit!
-
So, Gruppen sind drin, kannst du es mal Testen? Ich habe es nur mit einer Testgruppe probiert, da ich bisher keine Gruppen nutze.
https://github.com/Pmant/ioBroker.hue
Ebenfalls sollten keine Channels mehr erstellt werden, wenn es doppelte Namen geben würde. Wenn zwei Lampen mit den Namen "Lampe 1" und "Lampe_1" in Hue existieren wird "Lampe_1" nicht erstellt, da in ioBroker beide den selben Namen "Lampe_1" hätten. Gleiches gilt für Gruppen sowie Gruppen, welche den gleichen Namen wie eine Lampe haben. Beides habe ich aber bisher nicht getestet :roll: , theoretisch sollte die Lampe/Gruppe nicht erstellt werden und im Log eine Warnung erscheinen. `
Gruppen funktionieren! Top!
Ich hatte kurz überlegt, ob es sinnvoll wäre, im Adapter eine weitere Ebene für die Datenpunkte einzufügen, wie z.B.:
hue.0.Philips_hue****.lamp****.xxxxx
hue.0.Philips_hue****.lightGroup****.xxxxx
Das Problem mit den doppelten Bezeichnungen für eine Gruppe, bzw. Lampe wäre dann vom Tisch.
Auf der Anderen Seite kann das so der User selbst steuern.
Klasse Arbeit!
-
Weiß jetzt nicht ob das dein Part ist "Pman" aber wenn ich den Colorpicker für die Hue nutze, wird bei Farbänderung die Helligkeit immer auf 1% gesetzt.
Ändere ich die Farben über "hue" bleibt die Helligkeit bestehen. Kannst du das ändern oder ist das ein Problem vom Colorpicker? Oder ist es sogar so gewollt?
-
Hallo pman,
> Dann bin ich ja froh, dass ich das ganze nicht nur für mich selber mache :DMachst du definitiv nicht :idea: und auch wenn ich absolut nicht programmieren kann, so klinke ich mich an dieser Stelle mal ein. Ich habe bei mir nämlich 15 hue leuchten plus eine Osram lightyfy rgb Stripe im Einsatz. Das Ganze wird über vier Gruppen gesteuert. Ich sag das auch nur, damit, falls ich mal etwas testen soll, das testequipment klar ist.
Ansonsten finde ich die ganze Diskussion gerade extrem spannend. Zumal die gruppensteuerung etwas ist, was ich mir schon seit ccu.io Zeiten wünsche.
In der ccu2 hab ich das über ein Script gelöst.
Also, weiter so.
Ich werd den neuesten Adapter mit Gruppenfunktionen jetzt gleich auch mal einspielen.
Gruß
Bernhard
-
Und es ward Licht,
Will sagen. Alle Gruppen korrekt erkannt und da..
Jetzt muss ich ans testen gehen.
Auf jeden Fall erstmal Danke dafür.
Gruß
Bernhard
305_heizungsscript_090_04.txt -
Weiß jetzt nicht ob das dein Part ist "Pman" aber wenn ich den Colorpicker für die Hue nutze, wird bei Farbänderung die Helligkeit immer auf 1% gesetzt.
Ändere ich die Farben über "hue" bleibt die Helligkeit bestehen. Kannst du das ändern oder ist das ein Problem vom Colorpicker? Oder ist es sogar so gewollt? `
Ich habe das bis jetzt nur mit dem popup colorpicker getestet, da gilt: rechts Farbe wählen, dann links im Quadrat oben für hell und unten für dunkel. Rechts für volle Farbe, links für grau (weiß). Das hat für mich so weit ganz gut funktioniert.Grundsätzlich wird derzeit die Helligkeit immer auf den höchsten Einzelwert von r,g und b gestellt. 255,255,255 wäre also weiß mit voller Helligkeit. 10,0,0 ware rot mit Helligkeit 10.
-
Hmm ok, bei mir funktioniert es nicht. Egal was ich anwähle und egal welcher Colorpicker, die Helligkeit wird immer auf 1% gesetzt.
Also, Lampe eingeschaltet, Helligkeit voll aufgedreht, Colorpicker geöffnet, Farbe angewählt (so wie du es beschrieben hast), dann bei dem Popup Colorpicker auf Auswählen und zack, Helligkeit wieder auf 1%
-
Devider auf 1?
-
Nee, steht auf 255
-
Nee, steht auf 255 `
Kannst du dein Widget hier posten (Exportieren) ? -
Na klar:
[{"tpl":"tplRGBFarbtastic","data":{"visibility-cond":"==","visibility-val":1,"divisor":"255","views":null,"name":"PickerView","blue-oid":"hue.0.Philips_hue.Hue_Lamp_Wohnzimmer.b","green-oid":"hue.0.Philips_hue.Hue_Lamp_Wohnzimmer.g","red-oid":"hue.0.Philips_hue.Hue_Lamp_Wohnzimmer.r"},"style":{"left":"33px","top":"52px","width":"202px","height":"200px"},"widgetSet":"colorpicker"}]Das Widget öffne ich mit einem "Metro - Tile Dialog"
[{"tpl":"tplMetroTileDialog","data":{"visibility-cond":"==","visibility-val":1,"hover":"true","transform":"true","bg_class":"bg-black","icon_class":"","icon_badge":"","badge_bg_class":"","brand_bg_class":"","dialog_draggable":"true","dialog_icon_class":"","icon_src":"/vis-colorpicker.admin/colorpicker.png","dialog_width":"350","dialog_height":"430","dialog_flat":true,"dialog_title":"Colorpicker Wohnzimmer","icon_width":"90","icon_height":"90","icon_top":"62","icon_left":"62","contains_view":"Picker_Wohnzimmer"},"style":{"left":"745px","top":"241px","width":"49px","height":"49px"},"widgetSet":"metro"}]Übrigens kleine Info an Bleufox, wo wir gerade bei den Dialog Widgets sind. Mit dem "Metro - Tile Dialog" Widget kann ich den Dialog in Chrome mit "X" wieder schließen. Nutze ich aber "container - HTML - view in jqui Dialog" kann ich den Dialog in Chrome (zumindest auf meinen Android Geräten) nicht mehr schließen. Am Windows PC und Windows Tablet geht es, auch mit Firefox geht es auf dem Android Tablet.
-
Genau, sobald ich die Gruppenfunktion implementiert habe ist das ändern eines Wertes in der Gruppe nur ein Befehl. `
Wie schon geschrieben, funktioniert das mit den Gruppen prima.
Komischerweise erhalte ich bei einer Gruppe den Fehler 404. Wenn ich die Lampen der Gruppe einzeln ansteuere (gleiche Kommandofrequenz, bei den einzelnen Lampen die doppelte Anzahl von Kommandos, da zwei Lampen in der Gruppe sind). Normalerweise hätte ich jetzt gedacht, dass das Ansteuern über die hue Gruppe der bessere Weg sei.
Wenn es dann noch (wie auch immer) möglich wird mehrere Datenpunkte gleichzeitig zu ändern sollte es nur noch ein Befehl sein, der auch in einem Schritt an die Bridge geht. `
Hattest Du da noch was unternommen?
Vom Kommando zur Bridge dürfte es der einfachste Weg sein, da die Bridge so etwas: {"hue":47125,"sat":254,"bri":254} als ein Kommando akzeptiert. Die Frage ist nur, ob es die "Middleware" vom Adapter es unterstützt.
Ich wünsche mir immer noch einen Datenpunkt, in dem ich {"hue":47125,"sat":254,"bri":254} schreiben kann, was dann als Put an die Bridge geht
Ohne diesen Datenpunkt sind größere dynamische Szenen problematisch.
-
im Body können noch weitere Argumente stehen:
transitiontime, bri_inc, sat_inc, hue_inc, ct_inc finde ich interessant.
transitiontime uint16 The duration of the transition from the light’s current state to the new state. This is given as a multiple of 100ms and defaults to 4 (400ms). For example, setting transistiontime:10 will make the transition last 1 second. Optional
bri_inc -254 to 254 As of 1.7. Increments or decrements the value of the brightness. bri_inc is ignored if the bri attribute is provided. Any ongoing bri transition is stopped. Setting a value of 0 also stops any ongoing transition. The bridge will return the bri value after the increment is performed. Optional
sat_inc -254 to 254 As of 1.7. Increments or decrements the value of the sat. sat_inc is ignored if the sat attribute is provided. Any ongoing sat transition is stopped. Setting a value of 0 also stops any ongoing transition. The bridge will return the sat value after the increment is performed. Optional
hue_inc -65534 to 65534 As of 1.7. Increments or decrements the value of the hue. hue_inc is ignored if the hue attribute is provided. Any ongoing color transition is stopped. Setting a value of 0 also stops any ongoing transition. The bridge will return the hue value after the increment is performed.
Note if the resulting values are < 0 or > 65535 the result is wrapped. For example:
{"hue_inc": 1}
on a hue value of 65535 results in a hue of 0.
{"hue_inc": -2}
on a hue value of 0 results in a hue of 65534.
Optional
ct_inc -65534 to 65534 As of 1.7. Increments or decrements the value of the ct. ct_inc is ignored if the ct attribute is provided. Any ongoing color transition is stopped. Setting a value of 0 also stops any ongoing transition. The bridge will return the ct value after the increment is performed. Optional
xy_inc -0.5 to 0.5 As of 1.7. Increments or decrements the value of the xy. xy_inc is ignored if the xy attribute is provided. Any ongoing color transition is stopped. Setting a value of 0 also stops any ongoing transition. Will stop at it's gamut boundaries. The bridge will return the xy value after the increment is performed. Optional
-
Bin seit gestern wieder zu Hause und werde im Laufe der Woche den Sammelzustand implementieren.
Das ganze einfach an die Bridge weiterleiten kann die node-hue-api glaube ich nicht, ich halte es aber ohnehin für sinnvoller die Eingabe auszuwerten bevor sie weitergeleitet wird um fehlerhafte Eingaben direkt abzufangen.
-
cool
d.h. auswerten, ggf. korrigieren und dann in einem Rutsch zur Bridge?
Gesendet von iPhone mit Tapatalk
-
ct_inc verstehe ich nicht. ct kann Werte von 153 bis 500 haben, ct_inc aber bis 65534?
Ich lasse xy_inc und ct_inc erstmal weg, da mir die Wirkungsweise nicht klar ist.
bri_inc wird im Adapter zu bri verarbeitet (da Farbänderungen teilweise bri schon verändern), aber nur wenn bri nicht angegeben wurde.
sat_inc und hue_inc werden an die node-hue-api weitergegeben.
-
ct_inc verstehe ich nicht. ct kann Werte von 153 bis 500 haben, ct_inc aber bis 65534? `
Ja, das ist mir auch aufgefallen. Ich habe es für mich als Fehler in der hue Doku verbucht.
Der alte hue Adapter für die ccu.io hatte die Datenpunkte wohl drin. Zu mindestens kann man davon ausgehen, aus dem Code-Beispiel hier:
-
Ich mache ct_inc mal rein ohne die Werte zu begrenzen, dann müssen wir mal testen was passiert wenn man +100 oder +65000 eingibt.
-
die hue-node-api kann die inc-werte seit 1.1.0, allerdings reagiert die Lampe nicht bisher nicht, wenn ich die entsprechenden Funktionen nutze. bri_inc funktioniert, da dieser Wert ja im Adapter selber verarbeitet wird.
