[Neuer Adapter] hue-extended

[dslraser]

@Zefau
komisch, ist nur in meiner Wohnzimmer Gruppe so.....

[dslraser]

@Zefau
hat das was mit der laufenden Nummer zu tun ? Wohnzimmer ist Gruppe 1
(ich habe es manuell geändert, dann geht es natürlich)

[Zefau]

@dslraser sagte in [Neuer Adapter] hue-extended:

keine Rechte....(mit write false geht es halt nicht )

Ist mir auch aufgefallen. Der Fehler hat sich in den letzten Versionen eingeschlichen. Sollte natürlich auf true stehen. Behebe ich gerade.
Bzgl. der ID 1 werde ich das gerade mal testen.

[Zefau]

@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.

[Hiltex]

@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 und bri funktionieren ja, sodass es theoretisch kein grundsätzliches Problem sein dürfte.

[Zefau]

@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?

[dslraser]

@Zefau
ich habe nur HUE
sind 7 Lampen im Wohnzimmer (verschiedene)

[Zefau]

v0.5.0 auf Github und npm

• Added support for scenes (reorganized states and added trigger)
• Fixed action xy
• Reorganized states within tree state into action in case they are executable

Bitte beachten, dass die Zugangsdaten neu eingegeben werden müssen.

[Zefau]

@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?

[Hiltex]

@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.

[Zefau]

@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?

[Hiltex]

@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.

[Zefau]

@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?

[dslraser]

@Zefau
ich habe nur HUE Lampen, aber davon so einige Sorten.

[Zefau]

@dslraser Ok. Und das Problem besteht auch mit v0.5.0? Was steht im Log? Kannst du die Lampen der Gruppen einzeln erfolgreich schalten?

[dslraser]

@Zefau
die 0.5.0 habe ich noch nicht installiert/getestet

[dslraser]

@Zefau
die 0.5.0 startet bei mir gar nicht

host.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]

@dslraser siehe oben:

Bitte beachten, dass die Zugangsdaten neu eingegeben werden müssen.

[dslraser]

@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.

[AlCalzone]

@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 Endeffekt setState 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 und async/await nutzt. Also anstatt

for (...) {
    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.