NEWS
[Neuer Adapter] hue-extended
-
@Zefau sagte in [Neuer Adapter] hue-extended:
@Hiltex sagte in [Neuer Adapter] hue-extended:
Weil mir nicht ganz klar war, wie man den Adapter an die Bridge anlernt habe ich einfach den Benutzer aus dem anderen Hue-Adapter genommen und den anderen Adapter gestoppt.
Habe ich auch so gemacht. Kann daran nicht liegen. Ich werde das bei mir gleich nochmal im Detail testen.
Ich würde auch sagen, dass es daran nicht liegen kann.
level
undbri
funktionieren ja, sodass es theoretisch kein grundsätzliches Problem sein dürfte. -
@dslraser sagte in [Neuer Adapter] hue-extended:
hat das was mit der laufenden Nummer zu tun ? Wohnzimmer ist Gruppe 1
Hat nichts mit der laufenden Nummer zu tun. Bei mir funktioniert der erste Index.
Wie ist die Gruppe zusammengesetzt? Wie viele und welche Lampen? Alle von Philips? RGB support? -
@Zefau
ich habe nur HUE
sind 7 Lampen im Wohnzimmer (verschiedene)
-
v0.5.0 auf Github und npm
- Added support for scenes (reorganized states and added trigger)
- Fixed action
xy
- Reorganized states within tree
state
intoaction
in case they are executable
Bitte beachten, dass die Zugangsdaten neu eingegeben werden müssen.
-
@Hiltex
xy
sollte 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.
-
@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
xy
probiert? -
@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 -
@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.
-
@dslraser siehe oben:
Bitte beachten, dass die Zugangsdaten neu eingegeben werden müssen.
-
@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 EndeffektsetState
in 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/await
nutzt. 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.
-
@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 -
@AlCalzone Danke für den Hinweis. Wusste gar nicht, dass die Funktionen
async
/await
unterstü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
/await
wohl 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. -
@AlCalzone alles klar, danke für die Hinweise. Ich werde bei mir mal die
await
/async
Variante durchprobieren.