IoBroker.Hue mit Hue Bridge 2
-
Hallo zusammen,
nachdem ich mir ebenfalls den Luxus einer Hue gegönnt habe, bin ich gestern bereits auf die ersten Probleme mit dem entsprechenden Adapter gestoßen.
Die Einrichtung funktioniert soweit gut, jedoch kann ich über die RGB Felder der einzelnen Geräte (bzw. bei mir ist es aktuell nur 1) keine Farbwerte ändern, auch das Anbinden des Farbselectors in VIS bringt da keine Abhilfe. Immer, wenn einer der Werte geändert wird, springen alle RGB Werte, auch der den ich gerade geändert habe wirr herum. Selbstverständlich auch dann, wenn ich in den entsprechenden Farbbereichen bleibe.
So habe ich z.B. versucht nur die Rotwerte zu ändern, es scheitert aber bereits daran GB jeweils auf 0 zu setzen. Es scheint, als würde die Umrechnung nicht korrekt funktionieren.
Nachdem ich mir den Adapter angeschaut habe, habe ich gesehen, dass dieser noch eine alte Version der Hue-Lib verwendet, für die es bereits ein Update gibt, die auch einige selbst geschriebene Funktionen überflüssig macht.
Wird an dem Adapter noch aktiv entwickelt oder funktioniert dieser nur mit der 1. Version der Bridge?
Danke
-
Der Adapter funktioniert bei mir hervorragend an der hue Bridge 2.
schau mir dein Thema mal heute Abend an
Gesendet von iPhone mit Tapatalk
-
Keine Probleme hier, ich kann die RGB Werte einzeln ändern, wobei er dann nicht den eingegebenen Wert annimmt, sondern den tatsächlich nächst möglichen Wert. Colormode sollte gleichzeitig auf "xy" springen sobald ein RGB-Wert geändert wird.
Was steht bei dir im Log (final lightState)?
-
Als kleines Beispiel… Setze ich z.B. Cyan als Farbe (aus der API Dokumentation http://www.developers.meethue.com/docum ... -xy-values [0.2858,0.2747]) sollte dies (zumindest Ansatzweise) RGB 0,255,255 sein. Gesendet wird aber (obwohl ich nur diesen Wert geändert habe) final lightState: {"bri":254,"on":true,"xy":"0.2863962948051272,0.2746018816167392","r":206,"g":207,"b":254,"colormode":"xy","level":100}
Ich bekomme auch z.B. kein reines Grün hin (sofern der Farbraum das eben zulässt. Setze ich nur G auf 255 (vorher ist der State auf off und damit alle Werte 0), wird folgendes Kommando gesendet
final lightState: {"bri":254,"on":true,"xy":"0.408,0.517","r":234,"g":254,"b":69,"colormode":"xy","level":100}
Vielleicht verstehe ich den Adapter auch einfach nur nicht richtig oder steh sonst irgendwie auf der Leitung!?
Dank euch
P.S: beim Restarten des Adapters erhalte ich auch 2 Warnings
hue.0 2016-05-11 14:49:57 warn hue.0 setObject Philips_hue.All.lights (type=state) property common.type missing!
hue.0 2016-05-11 14:49:57 warn hue.0 setObject Philips_hue.All.lights (type=state) property common.role missing!
-
Hue kann eben kein RGB und es gibt einen Algorithmus der aus dem RGB-Wert den nächst möglichen Wert sucht.
Kannst du denn mit der Hue-App ein grüneres Grün machen?
> final lightState: {"bri":254,"on":true,"xy":"0.408,0.517","r":234,"g":254,"b":69,"colormode":"xy","level":100}
Der Wert ist doch exakt der selbe wie auf der von dir verlinkten Seite für Grün: [0.408,0.517]RGB Werte in leuchtende Farben (Lampen) umzurechnen ist ohnehin nur begrenzt sinnvoll, bei Hue ist der Farbraum nochmal spezieller. Wenn du bestimmte Farben haben willst dann versuch sie über die Hue App zu bekommen und lies die xy-Werte dann aus den Datenpunkten in ioBroker aus.
-
Was mich eben wundert ist, dass die RGB Werte in der Übersicht auf total absurde Werte springen, wodurch der ColorPicker (da dieser ja nur RGB kennt) ebenfalls spinnt und im nächsten Moment die Farbe des Pickers gar nicht mehr mit der eigentlichen übereinstimmt. Daher spinnt meine Lampe stets, wenn ich über den Picker eine entsprechende Farbe wähle.
RGB 234,254,69 ist ein grelles gelb anstatt ein sattes grün, also aus RGB 0,255,0 eben 234,254,69 wird. Die beiden Farben sind ja nicht mal ansatzweise ähnlich, selbst wenn die XY-Koordinaten stimmen. Es muss also irgendwo einen Rechenfehler geben!
Die aktualisierte Lib bietet hier entsprechende Umrechnungsfunktionen an, so dass diese der Adapter nicht selbst berechnen muss (https://github.com/peter-murray/node-hue-api).
-
Was mich eben wundert ist, dass die RGB Werte in der Übersicht auf total absurde Werte springen, wodurch der ColorPicker (da dieser ja nur RGB kennt) ebenfalls spinnt und im nächsten Moment die Farbe des Pickers gar nicht mehr mit der eigentlichen übereinstimmt. Daher spinnt meine Lampe stets, wenn ich über den Picker eine entsprechende Farbe wähle.
RGB 234,254,69 ist ein grelles gelb anstatt ein sattes grün, also aus RGB 0,255,0 eben 234,254,69 wird. Die beiden Farben sind ja nicht mal ansatzweise ähnlich, selbst wenn die XY-Koordinaten stimmen. Es muss also irgendwo einen Rechenfehler geben!
Die aktualisierte Lib bietet hier entsprechende Umrechnungsfunktionen an, so dass diese der Adapter nicht selbst berechnen muss (https://github.com/peter-murray/node-hue-api). `
Du scheinst nicht verstanden zu haben:
Die HUE Lampen können weder RGB Werte verarbeiten noch können sie überhaupt Grün richtig darstellen. Der Adapter rechnet RGB in XY um, genau auf die von Phillips vorgegebene Art und sendet diesen XY-Wert, den HUE versteht, an die Bridge. Dazu gehört auch, dass aus Grün dieses komische Gelb wird, genau wie in der Tabelle auch. Der XY-Wert wird dann wieder rückwärts in einen RGB-Wert umgerechnet der dem XY-Wert am nähesten kommt.
Also: Es wird NIE ein RGB-Wert an die Bridge gesendet, node-hue-api rechnet RGB ebenso um bevor es als XY an die Bridge gesendet wird, allerdings gab es die Funktion noch nicht als der Adapter enstanden ist und später hatte sie in der node-hue-api nicht richtig funktioniert. Ob sie mittlerweile funktioniert weiß ich nicht.
Solltest du bessere Funktionen zur Umrechnung RGB -> XY kennen kannst du gerne einen Pull-Request machen, aber ich bezweifle dass die HUE dadurch grüner leuchten wird :lol:
-
Verstanden habe ich das schon
Allerdings ist grün grün, wenn ich die Farbe über die Hue-App ändere (natürlich im Rahmen des Darstellbaren)
Auf dein Angebot komme ich gerne zurück.
Auch wenns Offtopic ist, für den Harmony-Adapter habe ich das gerade getan, da dieser immer wieder die Verbindung verloren hat, bzw. keine Steuerbefehle mehr angenommen hat. MIt dem Update läuft bei mir seit 3 Tagen alles rund.
Gerne schaue ich mir auch den Hue-Adapter an
-
Welche Lampe nutzt du bei Hue? Ich habe nur Gamut B (aus der Tabelle) implementiert, habe auch leider keine anderen Lampen zum testen. Der Lightstrip+ nutzt Gamut C und kann wohl grün besser darstellen. Ich habe schon angefangen Gamut C zu implementieren, wie gesagt hilft das aber nur bei Lightstrip+ und noch einer anderen Lampe, siehe http://www.developers.meethue.com/docum … ted-lights.
Hattest du schon den Harmony Adapter von Github? Da war schon ein Verbindungsfehler gefixt (ohne Update auf die neue lib).
Alle Abbrüche die ich seit dem noch hatte waren wegen dem schlechten Wifi des Hubs, der Adapter hat sich dann aber selbstständig neu verbunden.
Ich werde deine Änderung trotzdem mal testen und übernehmen, wollte schon länger auf die neue Lib updaten, danke.
-
Welches Gamut verwendet wird, kann ich dir leider im Moment nicht sagen, da ich nicht weiß, wo ich das nachlesen kann.
Ich habe im Moment die Osram Gardenspots angemeldet (auch wenn diese einen noch kleineren Farbraum haben). (http://www.amazon.de/Gartenleuchte-LIGH … 00JDJC03Y/). Die Sprünge habe ich aber auch, wenn die die Spots ausstecke (ich habe erst vermutet, dass die Bridge die Werte zerschießt).
Wenn ich übers Wochenende Zeit habe, kann ich aber gerne mal schauen, ob ich den Adapter an die 2er Version der Lib angepasst bekomme.
Problem mit der Harmony war, dass diese zwar augenscheinlich eine Verbindung hatte, aber eben keine Befehle angenommen und keine Statusupdates mehr bekommen hat. Das ganze trat erst nach 1-2 Tagen auf, auch ohne das im Log ein Verbindungsverlust vermerkt war. Seit dem Lib-Update läuft alles Rund
-
Welches Gamut verwendet wird, kann ich dir leider im Moment nicht sagen, da ich nicht weiß, wo ich das nachlesen kann.
Ich habe im Moment die Osram Gardenspots angemeldet (auch wenn diese einen noch kleineren Farbraum haben). (http://www.amazon.de/Gartenleuchte-LIGH … 00JDJC03Y/). Die Sprünge habe ich aber auch, wenn die die Spots ausstecke (ich habe erst vermutet, dass die Bridge die Werte zerschießt). `
Beschreib mal diese Sprünge genauer, wenn du meinst du stellst grün ein und es wird hell-gelb-grün dann ist das leider normal.Problem mit der Harmony war, dass diese zwar augenscheinlich eine Verbindung hatte, aber eben keine Befehle angenommen und keine Statusupdates mehr bekommen hat. Das ganze trat erst nach 1-2 Tagen auf, auch ohne das im Log ein Verbindungsverlust vermerkt war. Seit dem Lib-Update läuft alles Rund `
Probier einfach die mal die Adapterversion aus dem git zu installieren:
https://github.com/Pmant/ioBroker.harmony
Mehr dazu hier:
-
Ich habe mal auf Tonic ein kleines Testscript erstellt.
Das Problem scheint wirklich am GAMMUT zu liegen. Anscheinend wertet die Hue-App diesen aus, wodurch Grün auch wirklich Grün und nicht Gelb ist. Die 2er Lib bietet hier allerdings auch die Möglichkeit aus diese direkt vom Device auszulesen.
Das erklärt aber so einiges
-
https://github.com/peter-murray/node-hu … api/rgb.js
Es wird Gamut A und Gamut B unterstützt, leider keine Gamut C (Lightstrip+). Alternativ wird auf Defaultwerte zurückgegriffen, was vermutlich bei dir der Fall ist:
defaultLimits = { red: new XY(1.0, 0), green: new XY(0.0, 1.0), blue: new XY(0.0, 0.0) }Welches Modell wird für deine Lampe im HUE-System angegeben? Diese wird im Oberdatenpunkt einer Lampe gespeichert:
Im Objekte-Tab auf das Zahnrädchen bei deiner Lampe und dann unter native -> modelid.
-
Mein Objekt sieht aktuell so aus
{ "common": { "name": "Philips_hue.Gartenleuchte", "role": "light.color" }, "native": { "id": "1", "type": "Color light", "name": "Gartenleuchte", "modelid": "Gardenspot RGB", "swversion": "V1.03.20" }, "acl": { "object": 1638, "owner": "system.user.admin", "ownerGroup": "system.group.administrator" }, "_id": "hue.0.Philips_hue.Gartenleuchte", "type": "channel" } -
Teste mal bitte die neue Version von Github:
https://github.com/Pmant/ioBroker.hue
Das Verhalten sollte jetzt ähnlich der neuen API plus support für Gamut C sein.
In deinem Fall sollte die default Gamut genutzt werden.
-
Danke, werde ich heute Abend mit den Spots testen und dir dann Feedback geben
-
Kurze Rückmeldung, bis jetzt sieht alles gut aus!
Danke für den Patch und die Hilfe
