[Neuer Adapter] hue-extended
-
@Hiltex
xysollte in v0.5.0 nun funktionieren. Dies ging bei mir auch nicht. Der Rest funktioniert bei mir, insofern weiß ich leider nicht, wie ich dir weiterhelfen kann. Mit dem hue Adapter ging es bei dir ja, nur bei meinem Adapter nicht mehr, richtig?EDIT: sehe gerade, dass es bei dir Lampen von innr sind, keine Philips?
@Zefau richtig- innr-Lampen. Und ich habe vorhin mal ganz kurz mit der API herumgespielt. Auch da führt ein hue-Wert nicht zum Farbwechsel.
Das Ganze scheint auch bei OpenHAB ein Thema zu sein, weil die TRÅDFRI-Lampen offensichtlich nur XY unterstützen. Eventuell ist das ja bei den innr-Lampen das gleiche?
Jedes Mal, wenn ich die Lampen mit der hue App steuere stehen die danach im XY Modus. Das scheint also die bevorzugte Variante von Philips zu sein. Aber HomeKit macht offensichtlich nur hue.
Blog: indibit.de
-
@Zefau richtig- innr-Lampen. Und ich habe vorhin mal ganz kurz mit der API herumgespielt. Auch da führt ein hue-Wert nicht zum Farbwechsel.
Das Ganze scheint auch bei OpenHAB ein Thema zu sein, weil die TRÅDFRI-Lampen offensichtlich nur XY unterstützen. Eventuell ist das ja bei den innr-Lampen das gleiche?
Jedes Mal, wenn ich die Lampen mit der hue App steuere stehen die danach im XY Modus. Das scheint also die bevorzugte Variante von Philips zu sein. Aber HomeKit macht offensichtlich nur hue.
-
@Hiltex Also in deinem speziellen Fall ist ein Skript notwendig, dass den hue Wert von Homekit annimmt, diesen in xy umrechnet und an den hue-extended Adapter schickt?
@Zefau könnte gut sein. Ich hatte ja eingangs geschrieben, dass das meine ersten hue-Lampen sind, insofern fehlt mir auch ein wenig die Erfahrung, wie das mit anderen „kompatiblen“ Leuchtmitteln aussieht. Aber vielleicht hast du ja Lust, so eine Konvertierung einstellbar im Adapter zu hinterlegen?
Das könnte eventuell so aussehen, dass man in den Adapatereinstellungen die Zahlen der Lampen einträgt, die nur per XY gesteuert werden können. An der Stelle würde dann die Umrechnung greifen.
-
@dslraser Besteht das Problem bei dir noch mit der Wohnzimmer-Gruppe? Ist es ggf. derselbe Fehler wie bei Hiltex? Also Lampen, die die States nicht unterstützen? Hast du mal
xyprobiert?@Zefau
ich habe nur HUE Lampen, aber davon so einige Sorten. -
@dslraser Ok. Und das Problem besteht auch mit v0.5.0? Was steht im Log? Kannst du die Lampen der Gruppen einzeln erfolgreich schalten?
@Zefau
die 0.5.0 habe ich noch nicht installiert/getestet -
@dslraser Ok. Und das Problem besteht auch mit v0.5.0? Was steht im Log? Kannst du die Lampen der Gruppen einzeln erfolgreich schalten?
@Zefau
die 0.5.0 startet bei mir gar nichthost.ioBroker 2019-08-12 21:11:50.647 info Do not restart adapter system.adapter.hue-extended.0 because desired by instance host.ioBroker 2019-08-12 21:11:50.647 error instance system.adapter.hue-extended.0 terminated by request of the instance itself and will not be restarted, before user restarts it. -
@Zefau
die 0.5.0 startet bei mir gar nichthost.ioBroker 2019-08-12 21:11:50.647 info Do not restart adapter system.adapter.hue-extended.0 because desired by instance host.ioBroker 2019-08-12 21:11:50.647 error instance system.adapter.hue-extended.0 terminated by request of the instance itself and will not be restarted, before user restarts it. -
@Zefau
was meinst Du ? Ich hatte sogar die Instanz deinstalliert und eine neue angelegt (die Instanz wurde beim Update auf 0.5.0 nicht upgedatet, da stand installiert 0 (die alte war aber noch da)
In der leeren Instanz waren auch keine Zugangsdaten drinn, die mußte ich neu eingeben. -
@Zefau Ich habe mal einen kurzen Blick auf deinen Quellcode geworfen. Für mich scheint es so, dass die Stabilitätsprobleme daher kommen, dass du auf einen Schlag eine große Menge an Datenpunkten erstellst und befüllst. Dieser Prozess läuft bei deinem Adapter nicht sequentiell, sondern parallel ab und zwingt ioBroker in die Knie bzw. überfüllt den Call Stack.
https://github.com/Zefau/ioBroker.hue-extended/blob/master/hue-extended.js#L332
Hier wird im EndeffektsetStatein einer Schleife aufgerufen, ohne darauf zu warten, dass der vorherige Befehl abgeschlossen ist.Du kannst das Ganze relativ elegant lösen, indem du auf die
...Async-Methoden der Adapter-Klasse zurück greifst undasync/awaitnutzt. Also anstattfor (...) { adapter.setState(id, val); }was eine große Anzahl an States parallel befüllen will, kannst du folgendes nutzen:
for (...) { await adapter.setStateAsync(id, val); }was die States schön der Reihe nacheinander schreibt.
-
@Hiltex Also in deinem speziellen Fall ist ein Skript notwendig, dass den hue Wert von Homekit annimmt, diesen in xy umrechnet und an den hue-extended Adapter schickt?
@Zefau sagte in [Neuer Adapter] hue-extended:
@Hiltex Also in deinem speziellen Fall ist ein Skript notwendig, dass den hue Wert von Homekit annimmt, diesen in xy umrechnet und an den hue-extended Adapter schickt?
Wie sich herausgestellt hat ist mein Fall garnicht so speziell. Ich habe den Support von innr angeschrieben und folgende Antwort bekommen:
Von: Innr Servicedesk service@innr.com
Betreff: Aw: Steuerung im hue-Modus nicht möglich?
Datum: 13. August 2019 um 16:29:50 MESZ
An: xxxxxx@xxxxxx.com
Antwort an: Innr Servicedesk service@innr.comHallo Sebastian,
Ich habe gerade mit unserem technischen Spezialisten gesprochen und er sagte mir, dass fortgeschrittene Farbtonparameter von den Innr Lampe nicht unterstützt werden.
Ich hoffe, das beantwortet Ihre Frage.
Mit freundlichen Grüßen,
Ajay Mahabir
Innr ServicedeskIch bin also nicht alleine betroffen, sondern jeder, der innr-lampen an der hue-Bridge betreibt. Gleiches gilt offensichtlich auch für Tradfri-Lampen.
Ich wäre dir super dankbar, wenn du das im Adapter irgendwie berücksichtigen könntest.
Bei OpenHAB wird das mit Tradfri diskutiert und weiter unten im Thread gibt es auch Bash-Script für die Umrechnung von RGB nach XY. Vielleicht kannst du ja darauf aufbauen.
https://community.openhab.org/t/ikea-tradfri-color-changing-bulb-on-hue-bridge-no-control-of-colors/35413/54Weitere Erläuterungen und Formeln zur Umrechnung auf Github:
https://gist.github.com/popcorn245/30afa0f98eea1c2fd34dBlog: indibit.de
-
@Zefau Ich habe mal einen kurzen Blick auf deinen Quellcode geworfen. Für mich scheint es so, dass die Stabilitätsprobleme daher kommen, dass du auf einen Schlag eine große Menge an Datenpunkten erstellst und befüllst. Dieser Prozess läuft bei deinem Adapter nicht sequentiell, sondern parallel ab und zwingt ioBroker in die Knie bzw. überfüllt den Call Stack.
https://github.com/Zefau/ioBroker.hue-extended/blob/master/hue-extended.js#L332
Hier wird im EndeffektsetStatein einer Schleife aufgerufen, ohne darauf zu warten, dass der vorherige Befehl abgeschlossen ist.Du kannst das Ganze relativ elegant lösen, indem du auf die
...Async-Methoden der Adapter-Klasse zurück greifst undasync/awaitnutzt. Also anstattfor (...) { adapter.setState(id, val); }was eine große Anzahl an States parallel befüllen will, kannst du folgendes nutzen:
for (...) { await adapter.setStateAsync(id, val); }was die States schön der Reihe nacheinander schreibt.
@AlCalzone Danke für den Hinweis. Wusste gar nicht, dass die Funktionen
async/awaitunterstützen.Habe es aber anders gelöst. Die aktuelle Version (die noch nicht online ist), werden die States beim Adapter-Start in ein Array geladen und dann nur aktualisiert, wenn diese den Wert verändert haben. Insofern reduzieren sich die eigentlich Schreibvorgänge drastisch.
Würde insgesamt gerne die mögliche Performance nutzen, wenn es möglich ist, und nicht künstlich ausbremsen. Ich hatte Zwischendurch auch eine Variante mit
setTimeout( .. , 0), aber im Gegensatz dazu wirdasync/awaitwohl schneller sein.Meine Adapter: https://zefau.github.io/iobroker/
-
@AlCalzone Danke für den Hinweis. Wusste gar nicht, dass die Funktionen
async/awaitunterstützen.Habe es aber anders gelöst. Die aktuelle Version (die noch nicht online ist), werden die States beim Adapter-Start in ein Array geladen und dann nur aktualisiert, wenn diese den Wert verändert haben. Insofern reduzieren sich die eigentlich Schreibvorgänge drastisch.
Würde insgesamt gerne die mögliche Performance nutzen, wenn es möglich ist, und nicht künstlich ausbremsen. Ich hatte Zwischendurch auch eine Variante mit
setTimeout( .. , 0), aber im Gegensatz dazu wirdasync/awaitwohl schneller sein.@Zefau
setTimeout(..., 0)hat ein ähnliches Problem wie ohne Timeout. Die Callbacks mit Timeout 0 müsten alle im gleichen Moment aufgerufen werden - die Last ist dann nur in den nächsten Event-Loop-Zyklus verschoben.Warum `sudo` böse ist: https://forum.iobroker.net/post/17109
-
@Zefau
setTimeout(..., 0)hat ein ähnliches Problem wie ohne Timeout. Die Callbacks mit Timeout 0 müsten alle im gleichen Moment aufgerufen werden - die Last ist dann nur in den nächsten Event-Loop-Zyklus verschoben.@AlCalzone alles klar, danke für die Hinweise. Ich werde bei mir mal die
await/asyncVariante durchprobieren. -
v0.6.0 auf Github und npm
- Implemented queue for any applied actions
- Implemented user creation in interface configuration (admin panel)
- Added additional actions for color spaces
rgb,hsv,cmyk,xyzandhex
Bitte nach der Installation via
iobroker url https://github.com/Zefau/ioBroker.hue-extendedunbedingt
iobroker upload hue-extended -
@Zefau sagte in [Neuer Adapter] hue-extended:
@Hiltex Also in deinem speziellen Fall ist ein Skript notwendig, dass den hue Wert von Homekit annimmt, diesen in xy umrechnet und an den hue-extended Adapter schickt?
Wie sich herausgestellt hat ist mein Fall garnicht so speziell. Ich habe den Support von innr angeschrieben und folgende Antwort bekommen:
Von: Innr Servicedesk service@innr.com
Betreff: Aw: Steuerung im hue-Modus nicht möglich?
Datum: 13. August 2019 um 16:29:50 MESZ
An: xxxxxx@xxxxxx.com
Antwort an: Innr Servicedesk service@innr.comHallo Sebastian,
Ich habe gerade mit unserem technischen Spezialisten gesprochen und er sagte mir, dass fortgeschrittene Farbtonparameter von den Innr Lampe nicht unterstützt werden.
Ich hoffe, das beantwortet Ihre Frage.
Mit freundlichen Grüßen,
Ajay Mahabir
Innr ServicedeskIch bin also nicht alleine betroffen, sondern jeder, der innr-lampen an der hue-Bridge betreibt. Gleiches gilt offensichtlich auch für Tradfri-Lampen.
Ich wäre dir super dankbar, wenn du das im Adapter irgendwie berücksichtigen könntest.
Bei OpenHAB wird das mit Tradfri diskutiert und weiter unten im Thread gibt es auch Bash-Script für die Umrechnung von RGB nach XY. Vielleicht kannst du ja darauf aufbauen.
https://community.openhab.org/t/ikea-tradfri-color-changing-bulb-on-hue-bridge-no-control-of-colors/35413/54Weitere Erläuterungen und Formeln zur Umrechnung auf Github:
https://gist.github.com/popcorn245/30afa0f98eea1c2fd34d@Hiltex habe in der aktuellen Version v0.6.0 eine Option in den Adapter-Einstellungen hinzugefügt, die bei nicht-Philips Lampen den
huestate inxyumrechnet. Die Umrechnung basiert auf der node-hue-api, die auch der hue Adapter nutzt. Allerdings ist die Umrechnung insgesamt nicht vollständig präzise, weshalb es zu Abweichungen kommen kann. -
@Zefau
was meinst Du ? Ich hatte sogar die Instanz deinstalliert und eine neue angelegt (die Instanz wurde beim Update auf 0.5.0 nicht upgedatet, da stand installiert 0 (die alte war aber noch da)
In der leeren Instanz waren auch keine Zugangsdaten drinn, die mußte ich neu eingeben. -
@Zefau
morgen probiere ich es -
@Hiltex habe in der aktuellen Version v0.6.0 eine Option in den Adapter-Einstellungen hinzugefügt, die bei nicht-Philips Lampen den
huestate inxyumrechnet. Die Umrechnung basiert auf der node-hue-api, die auch der hue Adapter nutzt. Allerdings ist die Umrechnung insgesamt nicht vollständig präzise, weshalb es zu Abweichungen kommen kann.
Support us
544
Online32.7k
Users82.4k
Topics1.3m
Posts