Hue adapter

[Pman]

Das hatte ich auch noch nicht, ich nutze effect und alert allerdings auch nicht.

EDIT:

ich glaube ich habe den Fehler gefunden, der müsste auftreten, wenn man effect auf none setzt während die Lampe aus ist.

habe die Änderung auf github gepusht.

[ruhr70]

Danke! Du bist ja schneller als die Feuerwehr.

[Bluefox]

Ich sehe noch keinen Pullrequest

[ruhr70]

Hier bin ich noch auf einen Fehler gestossen. Der Auslöser dürfte ggf. bei mir gelegen haben. Aber vielleicht kann man das im Adapter abfangen.

host-iobroker	2015-07-26 16:58:02	error	instance system.adapter.hue.0 terminated with code 6 (uncaught exception)
hue-0	2015-07-26 16:58:02	info	terminating
TypeError:	2015-07-26 16:58:01	error	at Decoder.Emitter.emit (/opt/iobroker/node_modules/iobroker.js-controller/node_modules/socket.io-client/node_modules/component-emitter/index.js:134:20)
TypeError:	2015-07-26 16:58:01	error	at Decoder. (/opt/iobroker/node_modules/iobroker.js-controller/node_modules/socket.io-client/node_modules/component-bind/index.js:21:15)
TypeError:	2015-07-26 16:58:01	error	at Manager.ondecoded (/opt/iobroker/node_modules/iobroker.js-controller/node_modules/socket.io-client/lib/manager.js:301:8)
TypeError:	2015-07-26 16:58:01	error	at Manager.Emitter.emit (/opt/iobroker/node_modules/iobroker.js-controller/node_modules/socket.io-client/node_modules/component-emitter/index.js:134:20)
TypeError:	2015-07-26 16:58:01	error	at Manager. (/opt/iobroker/node_modules/iobroker.js-controller/node_modules/socket.io-client/node_modules/component-bind/index.js:21:15)
TypeError:	2015-07-26 16:58:01	error	at Socket.onpacket (/opt/iobroker/node_modules/iobroker.js-controller/node_modules/socket.io-client/lib/socket.js:220:12)
TypeError:	2015-07-26 16:58:01	error	at Socket.onack (/opt/iobroker/node_modules/iobroker.js-controller/node_modules/socket.io-client/lib/socket.js:295:6)
TypeError:	2015-07-26 16:58:01	error	at Socket. (/opt/iobroker/node_modules/iobroker.js-controller/lib/statesInMemClient.js:151:27)
TypeError:	2015-07-26 16:58:01	error	at /opt/iobroker/node_modules/iobroker.js-controller/lib/adapter.js:2331:60
TypeError:	2015-07-26 16:58:01	error	at /opt/iobroker/node_modules/iobroker.hue/hue.js:108:28
TypeError:	2015-07-26 16:58:01	error	Object 0.2126,0.0799 has no method 'split'
uncaught	2015-07-26 16:58:01	error	exception: Object 0.2126,0.0799 has no method 'split'

[Pman]

Der Fehler liegt schon im Adapter denk ich, das direkte ändern von xy funktioniert noch nicht richtig. Das muss ich mir die Tage nochmal in ruhe angucken. Im Moment versuche ich vis wieder ans laufen zu bekommen

[ruhr70]

Eine Anmerkung noch.

Du hattest eingestellt, dass bei Änderung der Farbe die Lampe auch auf "on" und voller Helligkeit geschaltet wird.

Die Idee ist gut

Und ein zweischneidiges Schwert…

Wenn eine Lampe z.B. im Zustand blau ausgeschaltet wurde, kann man so die neue Farbe (z.B. weiß) nicht vorher setzen und dann erst einschalten. Zu mindestens bei mir im Test verhielt sich das wie folgt:

• Lampe im Zustand blau ausgeschaltet

• Lampenfarbe auf weiß gesetzt

• Lampe geht an, blitz kurz mit der alten Farbe blau auf und geht dann auf weiß

Ist nur ein Schönheitsfehler...

Könnte man nicht einen zusätzlichen Datenpunkt aufmachen, an dem man "ganze Kommandos" schicken kann, wie z.b.:

{"hue":14000, "sat":170, "on":"true", "bri":200}

Die dann in einem Kommando vom Adapter an die Bridge übergeben werden.

Die hue Schnittstelle verarbeitet das doch genau so, oder?

Am Beispiel für ein Kommando an eine Gruppe:

Address	http://<bridge ip/address="">/api/<username>/groups/0/action
Body	{"on":true,"bri":255,"sat":255,"hue":0}
Method	PUT</username></bridge>

[Pman]

Der Adapter nutzt die hue-node-api. Was im Log am Ende als final ausgegeben wird ist genau das, was in einem Schritt an die node-api übergeben wird. Wie genau diese das an Hue weiterleitet kann ich nicht sagen, das müsste man mal sniffen. Auf jeden Fall lässt die node-api nicht zu, dass man Farben überhaupt ändert während eine Lampe aus ist, deswegen habe ich es so umgesetzt, dass dann immer on=true mit übergeben wird.

Du könntest natürlich in deinem Skript und beim ausschalten auf weiß wechseln. Hast du mal geguckt wie es ist wenn man von der offiziellen Hue App von Blau auf aus auf weiß schaltet?

[ruhr70]

Ob da jetzt was blitzt oder nicht, stört mich persönlich nicht unbedingt.

Das zu klären finde ich schon interessant

@Pman:

Der Adapter nutzt die hue-node-api. Was im Log am Ende als final ausgegeben wird ist genau das, was in einem Schritt an die node-api übergeben wird. Wie genau diese das an Hue weiterleitet kann ich nicht sagen, das müsste man mal sniffen. Auf jeden Fall lässt die node-api nicht zu, dass man Farben überhaupt ändert während eine Lampe aus ist, deswegen habe ich es so umgesetzt, dass dann immer on=true mit übergeben wird.

Du könntest natürlich in deinem Skript und beim ausschalten auf weiß wechseln. Hast du mal geguckt wie es ist wenn man von der offiziellen Hue App von Blau auf aus auf weiß schaltet? `

Wenn ich in der hue App am iPad eine Szene ausschalte und eine nächste Szene einschalte, dann wird auf diese Szene schnell aufgeblendet, ohne dass da etwas aufblitzt.

@Pman:

Der Adapter nutzt die hue-node-api. Was im Log am Ende als final ausgegeben wird ist genau das, was in einem Schritt an die node-api übergeben wird. `

Das verstehe ich nicht.

Ich kann in ioBroker immer nur einen Datenpunkt nacheinander ändern. D.h., für ein Kommando, z.B: hue:14000, sat:100, bri:100 muss der Adapter statt nur einem Kommando, drei Kommandos schicken, in der Reihenfolge, wie Sie über die geänderten Datenpunkte beim Adapter ankommen.

Die Bridge selbst könnte es in einem Kommando verarbeiten.

Wie die hue-node-api arbeitet weiß ich natürlich nicht. Eine Vermutung wäre, dass Sie Farben ändern in einem Kommando, inkl. "on", zulässt.

Mit der jetzigen Lösung würde folgendes passieren:

• Lampe ist aus, bri 0

• ich stelle hue: auf 14000

• lampe geht an mit bri auf 254 und der bisher eingestellten Saturation

• ich stelle Sat auf 100

• ich will eigentlich bri auf 100 haben und ändere den 2. Datenpunkt

• bri wird auf 100 gesetzt

Wenn man das in eine Kommando schicken könnte, würde die Lampe an gehen, direkt mit der Helligkeit 0 und Sat: 100.

• Lampe aus

• Lampe an, mit: hue = 14000, sat = 100, bri = 100

Oder bin ich da auf dem Holzweg?

Die Funktion, wie sie jetzt sind (einzelne Datenpunkte), finde ich ebenfalls richtig wichtig

So kann man z.B. mal eben schnell die Helligkeit unabhängig von den anderen Einstellungen ändern.

[Pman]

Die Datenpunkte wie sei jetzt sind kommen so direkt von der Hue Api, wo man sie mit einem PUT Befehl allerdings wie du schon richtig schreibst gemeinsam ändern kann. Bei ioBroker kann man in einem Befehl (so weit ich weiß) immer nur einen State gleichzeitig ändern. Das wäre eher eine Frage an Bluefox, ob man evtl. eine zu stateChange ähnliche Funktion implementieren könnte, in der mehrere States gleichzeitig geändert werden können. Das würde immer dann Sinn machen, wenn ein Gerät auch mehrere Änderungen in einem Befehl ändern kann.

[ruhr70]

Würde es nicht reichen, wenn es einen Datenpunkt vom Typ String geben würde in dem man solche Werte ablegen kann {"on":true,"bri":255,"sat":255,"hue":0}, die der Adapter dann als Put an die Bridge schickt?

[Pman]

Wäre auf jeden Fall möglich, wäre aber eher ein Workaround für das Problem. Dazu kommt noch, dass das ändern eines solchen States ja erstmal eine eigene Logik erfordert, der String müsste ja erstmal innerhalb eines Skriptes erstellt werden. Es wäre universeller verwendbar wenn man die States analog zu setState gemeinsam ändern könnte.

[ruhr70]

ich habe noch ein bisschen getestet.

Der Fehler:

hue-0	2015-07-28 07:11:19	error	error: Api Error: Internal error, 404

kommt immer, wenn man bei einer Lampe zu schnell die Farben hintereinander ändert.

So um die 100-200ms dürfte der kritische Punkt sein.

Das kann man im Script wunderbar umgehen.

Ansonsten muss ich noch einmal meine Begeisterung äußern, dass der Adapter nun funktioniert. Danke noch einmal. Endlich bekommt hue daheim wieder einen Sinn

[Pman]

Dann bin ich ja froh, dass ich das ganze nicht nur für mich selber mache

Ich habe irgendwo gelesen, dass die Bridge nicht mehr als maximal 10 Befehle pro Sekunde verkraftet, das wäre alle 100ms einer. Die Bridge ist leider nicht sehr leistungsfähig.

[ruhr70]

ich hoffe es sind nicht Befehle, sonst sind wir wieder beim Thema von gestern.

Das Ändern von fünf Lampen in einer Gruppe würde ja schon 15 Befehle bedeuten, wenn man sat, hue und bri ändert und nicht die hue Gruppenfunktion nutzen kann.

Das zusammenfassen auf einen Post würde fünf Befehle bedeuten.

die Hue Gruppenfunktion, die ich nicht unbedingt nutzen möchte, einen Befehl

sorry, der Post wurde diktiert

Gesendet von iPhone mit Tapatalk

[Pman]

Genau, sobald ich die Gruppenfunktion implementiert habe ist das ändern eines Wertes in der Gruppe nur ein Befehl. 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.

[Pman]

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.

[ruhr70]

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!

[ruhr70]

@Pman:

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!

[coyote]

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?

[Heinzelmaennchen]

Hallo pman,

> Dann bin ich ja froh, dass ich das ganze nicht nur für mich selber mache :D

Machst 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