NEWS
Hue adapter
-
alle Kommandos haben funktioniert.
Noch ein Beispiel:
Body:
{ "ct_inc": 400, "transitiontime": 100 }
Ergebnis:
[ { "success": { "/lights/12/state/transitiontime": 100 } }, { "success": { "/lights/12/state/ct": 500 } } ]
-
komisch, über die node-hue-api bekomme ich es nicht hin
-
shit…
an der Version wird es nicht liegen, denke ich. Trotzdem mal zur Info:
"modelid": "BSB001", "swversion": "01024156", "apiversion": "1.8.0",
Klappt das denn bei Dir direkt über die API Webseite?
http://[bridge-ip]/debug/clip.html
-
Ja, das geht. Ich denke es liegt an der node-hue-api. Da muss ich mal weiter probieren und ggf. dort nachfragen.
Funktioniert denn außer den inc Werten alles bei dir?
-
Du meinst mit der Version von Github?
Die wollte ich jetzt installieren. Irgendetwas, auf das ich speziell achten muss?
-
Du meinst mit der Version von Github?
Die wollte ich jetzt installieren. Irgendetwas, auf das ich speziell achten muss? `
Genau, Version 0.4.0. Eigentlich gibt es nichts zu beachten, beim starten der Instanz sollten die neuen command-States hinzugefügt werden. bri_inc sollte funktionieren, die anderen inc Werte nicht. transitiontime geht bei mir! Es gibt natürlich relativ viele Kombinationen von on, bri, hue, ct, xy, rgb usw., ob es bei einigen Sonderfällen zu Problemen mit der aktuellen Implementierung kommt wäre interessant. Ein paar Fehler hatte ich schon gefunden und gefixt.
-
Habe mir die Files rüber kopiert und den Adapter neu gestartet upload/restart.
Kämpfe gerade damit, dass er nun nicht mehr startet:
iobroker 2015-08-03 17:54:20 error host.iobroker instance system.adapter.hue.0 terminated with code 8 (node.js: Cannot find module)
-
Ist jetzt gestartet.
In den Objekten ist nur der Datenpunkt command dazugekommen?
D.h. alle besprochenen Punkte muss ich darüber testen?
1526_uifrhi6f.txt -
Im iobroker Verzeichnis:
npm install https://github.com/pmant/ioBroker.hue/tarball/master iobroker upload hue
Läuft bei mir so durch und der Adapter lässt sich starten.
-
Ist jetzt gestartet.
In den Objekten ist nur der Datenpunkt command dazugekommen?
D.h. alle besprochenen Punkte muss ich darüber testen? `
Du kannst dort so was wie "{"bri_inc":100,"ct":369,"transitiontime":10}" machen. Ich glaube die gröbsten Fehler sind raus, evtl. gibt es ein paar Unstimmigkeiten, wenn "on", "bri" und rgb kombiniert werden, da sich diese gegenseitig verändern… -
-
bric_inc und transitiontime funktionieren.
-
sat, hue, bri, alert, effect in verschiedenen Kombinationen: OK
-
keine Überraschung: ct hat keinerlei Funktion bei einem Lightstripe (vielleicht kann man das abfangen und in hue/sat umwandeln)
-
sat_inc und hue_inc verursachen einen Fehler, s.u. (has no method 'sat_in')
-
r,g,b (keine hue Brige Funktion oder? Wird im Adapter umgerechnet?) funktionieren, wobei ich den Eindruck hatte, dass es einmal erst im zweiten Anlauf funktioniert hat (nicht Vollständig alle Variablen ausgeführt)
Alles in allem sieht es gut aus
Wie ist denn die Funktion im Adapter?
Die Daten werden erst auseinandergenommen, geprüft, wieder zusammengesetzt und dann in einem Rutsch per Put zur Bridge?
host-iobroker 2015-08-03 18:12:30 error instance system.adapter.hue.0 terminated with code 6 (uncaught exception) TypeError: 2015-08-03 18:12:30 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-08-03 18:12:30 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-08-03 18:12:30 error at Manager.ondecoded (/opt/iobroker/node_modules/iobroker.js-controller/node_modules/socket.io-client/lib/manager.js:301:8) TypeError: 2015-08-03 18:12:30 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-08-03 18:12:30 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-08-03 18:12:30 error at Socket.onpacket (/opt/iobroker/node_modules/iobroker.js-controller/node_modules/socket.io-client/lib/socket.js:220:12) TypeError: 2015-08-03 18:12:30 error at Socket.onack (/opt/iobroker/node_modules/iobroker.js-controller/node_modules/socket.io-client/lib/socket.js:295:6) TypeError: 2015-08-03 18:12:30 error at Socket. (/opt/iobroker/node_modules/iobroker.js-controller/lib/statesInMemClient.js:151:27) TypeError: 2015-08-03 18:12:30 error at /opt/iobroker/node_modules/iobroker.js-controller/lib/adapter.js:2331:60 TypeError: 2015-08-03 18:12:30 error at /opt/iobroker/node_modules/iobroker.hue/hue.js:243:37 TypeError: 2015-08-03 18:12:30 error Object [object Object] has no method 'sat_inc' uncaught 2015-08-03 18:12:30 error exception: Object [object Object] has no method 'sat_inc'
u.a. getestete Einstellungen:
"standard": {"ct":500,"bri":254,"effect":"none","alert":"none"}, // standard /warmweiss (2000k) - Standardfarbe der hue bei Power on "cool": {"ct":153,"bri":254}, // kaltweiss (6500k) "blue": {"hue":47125,"sat":254,"bri":254}, // blue - blau "red": {"hue":65535,"sat":254,"bri":254}, // red -rot "green": {"hue":25500,"sat":254,"bri":254}, // green -grün "on": {"on":true}, // on - schaltet die Gruppe ein "off": {"on":false}, // off - schaltet die Gruppe aus "effectColorloop": {"effect":"colorloop"}, // effectColorloop - effect Collor Loop ein "effectOff": {"effect":"none"}, // effectOff "alertOn": {"alert":"lselect"}, // alertOn - Intervall auf- und abblenden "alertOff": {"alert":"none"}, // alertOff "test2": { "hue": 24000, "sat": 254, "bri": 254, "effect": "none", "alert": "none" }, "test": {"r":0,"g":254,"b":0,"effect":"none","alert":"none"}
> Ich glaube die gröbsten Fehler sind raus, evtl. gibt es ein paar Unstimmigkeiten, wenn "on", "bri" und rgb kombiniert werden, da sich diese gegenseitig verändern…
Was macht denn die Bridge daraus?
Der Adapter versucht die unlogischen Angaben zu eliminieren, bevor sie an die Bridge gehen?
-
-
weitere Tests mit den bestehenden Scripten:
In einem Script erhalte ich nun einen 404er, der vorher nicht da war (Überlast?).
`for (i = 0; i < hueLichter.length; i++) { //setState(hueLichter[i] + ".colormode","ct"); setState(hueLichter[i] + ".hue", 14922); setState(hueLichter[i] + ".sat", 144); setState(hueLichter[i] + ".effect", "none"); setState(hueLichter[i] + ".alert", "none"); if(isTimeInRange('23:00:00', '05:00:00')) { // Nachts mit verringerter Helligkeit setState(hueLichter[i] + ".bri", 100); } else { setState(hueLichter[i] + ".bri", 254); // Tagsüber mit voller Helligkeit }` Erzeugt bei zwei Lampen, die geschaltet werden einen 404er. Dürfte kein Problem sein, da ich die ganzen setState() nun in ein setState() umbauen kann ;-) Dann bekomme ich noch einen: `~~[code]~~hue-0 2015-08-03 18:43:17 error error: Api Error: parameter, xy, is not modifiable. Device is set to off. hue-0 2015-08-03 18:43:17 error error: Api Error: parameter, xy, is not modifiable. Device is set to off.[/code]` Wobei ich in keinem Script mit [x,y] arbeite. Zeitlich passt der Fehler zu dem Fehler oben. Wie gesagt, ich sehe da kein Problem, da ich das Script ja nun umbauen kann. Ist nur ein Hinweis, dass die 404er vorher bei dem Script nie aufgetreten sind.[/i][/i][/i][/i][/i][/i][/i]
-
- keine Überraschung: ct hat keinerlei Funktion bei einem Lightstripe (vielleicht kann man das abfangen und in hue/sat umwandeln)
ct in hue/sat umrechnen ist mir bei Philips bisher nicht untergekommen, ohne genaue Vorgaben wie das gehen soll wäre das nur Raterei.
> - sat_inc und hue_inc verursachen einen Fehler, s.u. (has no method 'sat_in')Hast du per npm install installiert? Sieht so aus als hättest du noch eine alte Version der hue-node-api.
> - r,g,b (keine hue Brige Funktion oder? Wird im Adapter umgerechnet?) funktionieren, wobei ich den Eindruck hatte, dass es einmal erst im zweiten Anlauf funktioniert hat (nicht Vollständig alle Variablen ausgeführt)rgb wird in xy und bri umgerechnet, mit einem Algorithmus, der von Philips vorgegeben ist.
> Wie ist denn die Funktion im Adapter?
Die Daten werden erst auseinandergenommen, geprüft, wieder zusammengesetzt und dann in einem Rutsch per Put zur Bridge?
Die Werte werden auseinander genommen und nur unterstütze werden an die hue-node-api weitergeleitet. Diese spircht dann mit der Bridge. [https://github.com/peter-murray/node-hue-api](https://github.com/peter-murray/node-hue-api)
> Was macht denn die Bridge daraus?Der Adapter versucht die unlogischen Angaben zu eliminieren, bevor sie an die Bridge gehen?
Ja genau, z.B. wird bei "bri":0 auch immer "on":false hinzugefügt, da die Bridge normalerweise bei bri=0 nicht ausschaltet, sondern auf bri=5 geht. Durch das hinzufügen von on=false wird der Hue Adapter kompatibel zu anderen Dimmern, die nur über Helligkeit geregelt werden.
> Dann bekomme ich noch einen:hue-0 2015-08-03 18:43:17 error error: Api Error: parameter, xy, is not modifiable. Device is set to off. hue-0 2015-08-03 18:43:17 error error: Api Error: parameter, xy, is not modifiable. Device is set to off.
Wobei ich in keinem Script mit [x,y] arbeite. Zeitlich passt der Fehler zu dem Fehler oben.
Das wird dann an rgb liegen, das ja in xy umgerechnet wird. Aller Farbwerte können bei ausgeschalteter Lampe nicht geändert werden, das geht nur bei gleichzeitigem einschalten, weswegen eigentlich immer ein on=true mitgeschickt werden sollte. Bei welchem Befehl genau kam es zu dem Fehler (während die Lampe aus war)?
> Wie gesagt, ich sehe da kein Problem, da ich das Script ja nun umbauen kann. Ist nur ein Hinweis, dass die 404er vorher bei dem Script nie aufgetreten sind. `
Das mit den 404ern hatte ich noch nie, kann daher nicht viel dazu sagen. Ich bin mir auch nicht sicher wie schnell die Bridge beim Verarbeiten mehrerer Änderungen in einem put ist. - keine Überraschung: ct hat keinerlei Funktion bei einem Lightstripe (vielleicht kann man das abfangen und in hue/sat umwandeln)
-
> - ****sat_inc**** und ****hue_inc**** verursachen einen Fehler, s.u. (has no method 'sat_in')
Hast du per npm install installiert? Sieht so aus als hättest du noch eine alte Version der hue-node-api. `Mein Fehler. Ich habe die 0.4.0 jetzt noch einmal richtig installiert.
Wenn ich jetzt z.B. ein {"hue_inc":1000} oder ein {"sat_inc":50} durchführe (getestet am Lightstripe), bekomme ich im Log folgende Meldung:
hue-0 2015-08-03 20:06:29 info final lightState: {"bri":254,"on":true}
Die Helligkeit, Sättigung und der Farbwert ändern sich nicht. Getestet im ioBroker/admin/Zustände.
-
Die werden schon an die hue-node-api weitergeleitet, die Ausgabe zeigt aber nur Werte, welche zurück in die States geschrieben werden (bri,on) an. Das ist eigentlich nur eine Ausgabe zum debuggen und hat nichts damit zu tun, was an die api weitergegeben wird.
-
Ich glaube ich habe den Fehler gefunden, inc_ct klappt jetzt bei mir, der Rest sollte auch funktionieren.
-
Daumen hoch!
Super! funktioniert
hue_inc, sat_inc getestet
Wenn ich das richtig sehe, werden können Änderungen an hue/sat, ct, bri, usw. direkt in den Datenpunkten ausgelesen werden wenn sie über ioBroker erfolgen. Wenn sie über einen anderen Weg erfolgen, dann sind sie erst nach dem Polling richtig.
Wobei ich mir gerade nicht sicher bin, ob das Polling noch funktioniert. Die Werte, die bei einer Testlampe über .command geändert habe (heu/sat) haben sich auch nach über 30 Sekunden in den Datenpunkten (hue/sat) nicht aktualisiert. (sat über .command auf 60.000 im Datenpunkt bleibt die ganze Zeit der Ursprungsfarbwert 25.000 erhalten).
Ansonsten wäre es doch prima, wenn Änderungen über .command direkt in die Datenpunkte zur Anzeige einfliessen. Mit dem Risiko, dass die Werte bis zum Polling verfälscht sind, da z.B. auch über andere Wege, als iOBroker, die Werte verändert werden (ich glaube dafür könnte man dann das Acknowledge Flag verwenden?). D.h. man schreibt den Datenpunkt .sat, der Wert steht drin, über .command ebenso und über "sat_inc" als errechneter Wert dann ebenfalls.
Und würden die sat_inc, ct_inc, hue_inc, usw. nicht auch als Datenpunkte Sinn machen, z.B. für Änderungen über VIS ohne Javascript.
Ich habe es in diesem Thread schon mehrmals gemacht. Aber ich muss einfach noch einmal meine Freude ausdrücken, dass der hue Adapter nun verwendbar ist Top alles weitere ist Bonus
So am Ende des Posts steht hue in den Objekten und unter Zuständen immer noch auf 25.000, obwohl die Lampe im Wert 60.000 läuft. D.h. wohl, dass Polling funktioniert nicht?
-
Alle Änderungen über command außer den *_inc-Werten sollten direkt in die entsprechenden States gespeichert werden, funktioniert bei mir auch.
Da bri_inc schon im Adapter addiert wird funktioniert das hier auch direkt, als Ausgangswert wird dann aber natürlich der letzte ioBroker-Wert genommen. Wurde bri z.B. über die Hue App zwischenzeitlich (innerhalb eines Pollingintervals) geändert, wird das nicht berücksichtigt und mit dem alten bri Wert gerechnet.
Ich wollte ggf. die anderen inc-Werte ebenso im Adapter berechnen, dann wäre einfach die endgültigen Werte direkt in die entsprechenden States zu speichern. Dazu muss ich aber noch ausprobieren, welche Farbänderung "gewinnt", wenn mehrere Farbsysteme gleichzeitig geändert werden (hs, xy, ct).
Das Polling funktioniert bei mir ebenfalls, d.h. wenn ich z.B. per command {"hue_inc":100} ändere, wird nach spätestens 30 Sekunden der neue hue-Wert (alt+100) angezeigt. Allerdings glaube ich, dass nichts passiert wenn man über die erlaubten Maximalwerte hinaus ändert. Zudem sind Änderungen wie gesagt nur möglich wenn die Lampe an ist, wobei sie eigtl. ja mit eingeschaltet werden sollte.
Da du einen Strip hast:
Welcher Lampentyp wird in der Hue Bridge dafür angegeben und welche Datenpunkte? Bisher wird nur zwischen Extended color light (alle drei Farbsysteme) und Dimmable light (nur Brightness) unterschieden. Ich würde für jeden Typ gerne nur die tatsächlich vorhandenen Datenpunkte angeben.
305_anwesenheitssteuerung_080_marcj_knx.txt -
Alle Änderungen über command außer den *_inc-Werten sollten direkt in die entsprechenden States gespeichert werden, funktioniert bei mir auch. `
Das Polling funktioniert bei mir ebenfalls, d.h. wenn ich z.B. per command {"hue_inc":100} ändere, wird nach spätestens 30 Sekunden der neue hue-Wert (alt+100) angezeigt. Allerdings glaube ich, dass nichts passiert wenn man über die erlaubten Maximalwerte hinaus ändert. Zudem sind Änderungen wie gesagt nur möglich wenn die Lampe an ist, wobei sie eigtl. ja mit eingeschaltet werden sollte. `
Die direkte Rückmeldung in die Datenpunkte und das Polling sind bei mir nicht sauber. Ich habe jetzt einiges probiert. Wenn ich einen Wert über .command ändere, ändert sich der Datenpunkt in Zustände & Objekte nicht.
Das Polling funktioniert im Log. Wenn ich den Debug Level für hue einschaltete, sehe ich im Log alle 30 Sek. das Polling. Beim ersten Einschalten des Debug-Level wurden auch die Datenpunkte aktualisiert (wg. dem Restart des Adapters).
Danach habe ich sat über .command geändert (an der Lampe sichtbar). Der Datenpunkt hat seinen alten Wert behalten. Im Log taucht der neue Wert im Polling auf.In den Objekte und Zuständen bleibt aber der alte Wert. Erst ein Restart des Adapters sorgt dafür, dass die aktuellen Werte geschrieben werden (das war oben beim Einstellen des Debug Levels auch die Ursache).
Gibt es irgendetwas, was ich tun kann, um den "Fehler" einzugrenzen? Sehr komisch…
…
Dazu muss ich aber noch ausprobieren, welche Farbänderung "gewinnt", wenn mehrere Farbsysteme gleichzeitig geändert werden (hs, xy, ct). `
Laut Philips ist die Reihenfolge:
1.)[x,y]
vor
2.)ct
vor
3.) hue/sat
Da du einen Strip hast:
Welcher Lampentyp wird in der Hue Bridge dafür angegeben und welche Datenpunkte? Bisher wird nur zwischen Extended color light (alle drei Farbsysteme) und Dimmable light (nur Brightness) unterschieden. Ich würde für jeden Typ gerne nur die tatsächlich vorhandenen Datenpunkte angeben. `
"state": { "on": true, "bri": 95, "hue": 61202, "sat": 254, "effect": "none", "xy": [ 0.6223, 0.2622 ], "alert": "none", "colormode": "hs", "reachable": true }, "type": "Color light",
Wenn Du Dich als Developer anmeldest, bekommst Du unter http://www.developers.meethue.com/docum … ted-lights eine komplette Übersicht mit allen Infos, z.B. auch welcher Gamut von welchem Lampentyp verwendet wird.
Auszug der Lampentypen:
On/off light (ZigBee Device ID: 0x0000), supports groups, scenes and on/off control
Dimmable light (ZigBee Device ID: 0x0100), which supports groups, scenes, on/off and dimming.
Color temperature light (ZigBee Device ID: 0x0220), which supports groups, scenes, on/off, dimming, and setting of a color temperature.
Color light (ZigBee Device ID: 0x0200), which supports groups, scenes, on/off, dimming and color control (hue/saturation, enhanced hue, color loop and XY)
Extended Color light (ZigBee Device ID: 0x0210), same as Color light, but which supports additional setting of color temperature
The modelid identifies the hardware model of the light. The following table illustrates the Hue models which are currently available and can be identified.
*Note that the Living Color Lights (i.e. LLC006 and LLC007) can be identified, but are not officially supported as Friends of Hue Lights because they can not be commissioned the same way as Friends of Hue lights.
-
Vielleicht gibt es noch immer Probleme mit der Benennung der Lampen und es wird in falsche Ids geschrieben? Ich habe mal eine log ausgabe hinzugefügt, wenn die States nach Änderung gespeichert werden. Bei mir funktioniert wie gesagt sowohl das, als auch das Polling.
writing state "hue_bridge.Wohnzimmer.bri" : 244
Ansonsten werden jetzt auch hue_inc, sat_inc und ct_inc im Adapter berechnet und die entsprechenden Zielwerte direkt in die States gespeichert (wenn es denn geht).