Hi,
hier mal ganz kurz meine Lösung den Sleep Timer über den Adapter zu steuern.
Nicht schön, aber funktioniert 
Über die sleep_duration_sec, die ich mir aus dem UI angle, wird bestimmt, ob nach einer bestimmten Zeit abgeschalten wird, oder am Ende des aktuellen Track.
Danke und Kudos @oliverio
Quelle:
https://github.com/oweitman/ioBroker.squeezeboxrpc/issues/56
Hi!
Danke für den Adapter! Sehr nützlich! 
Wäre es möglich eine Option hinzuzufügen die es erlaubt, die Stundenpläne der nächsten Tage als JSON/Object in einen State zu schreiben?
Wäre es möglich eine Option hinzuzufügen die es erlaubt, die Stundenpläne der nächsten Tage als iCAL in einen State zu schreiben? (Oder gleich an den iCAL Adapter zu übergeben?)
Grüße
Hallo,
ich schaue gerade meine ganzen Scripte durch und versuche zu verbessern, was geht.
Könnt ihr mich bitte erleuchten, welche der beiden folgenden Herangehensweisen die bessere/korrekte ist?
oder
Ist es besser, nur einen Trigger zu haben, der im Fall des Auslösens ein if else durchkaut, oder setzt man lieber x Trigger?
dies ist nur ein sehr einfaches Bsp um den Sachverhalt zu schildern.
In konkreten Fällen können Trigger-Werte 10+ Unterscheidungen aufweisen. Es sind also einige else if abzuarbeiten.
Hi,
hier mal ganz kurz meine Lösung den Sleep Timer über den Adapter zu steuern.
Nicht schön, aber funktioniert
Über die sleep_duration_sec, die ich mir aus dem UI angle, wird bestimmt, ob nach einer bestimmten Zeit abgeschalten wird, oder am Ende des aktuellen Track.
Danke und Kudos @oliverio
Quelle:
https://github.com/oweitman/ioBroker.squeezeboxrpc/issues/56
@AlCalzone Update von 1.7.5 mit zwavejs 5.2.0 auf 1.7.7
Teil der Geräte (Node 3, Node 4 und Node 6) bekommen kein Interview mehr hin oder reagieren auch nach drei Versuchen nicht mehr.
Node 2 und 3 sind baugleich, aber nur noch 2 funktioniert.
@AlCalzone
So, nach dem Cache Löschen war immer wieder eine oder beide neu inkludierte Nodes nicht mehr erreichbar. Node 4 (die mit früheren Versionen gezickt hat und immer wieder dead war) war nur noch manchmal erreichbar/steuerbar, trotz dass sie auf alive stand.
Ich habe nun also alles noch mal platt gemacht (Stick, Nodes, Adapter, pipapo...)
Allerdings habe ich, bevor ich den Adapter auf den Stick losgelassen habe,
zwave-js (in der Version 5.2.2) komplett deinstalliert und die 5.2.0 installiert.
Danach habe ich wieder Node 2, 3 und 4 inkludiert. Und getestet: nach_install.zip
Alles problemlos. MultiLevel Steuerung funzt zuverlässig und sehr schnell. Für alle Nodes. Keine die rumzickt.
Nun habe ich den Cache gelöscht. Interviews sehr schnell. Alle Nodes erreichbar und steuerbar. Steuerung der Multilevel geht zackig. Kein Warten und irgendwann Schalten.
nach_cache_clear.zip
Ich könnte das Ganze noch mal mit zwave-js@5.2.1 testen, aber ich hab heute keinen Bock mehr Steckdosen aufzuschrauben 
Wenn du da aber noch mal ein Log brauchst, mach ich dir das gerne morgen.
Ich lass dass Setup jetzt erst mal so und schaue was passiert.
@AlCalzone
Ich habe nun alles platt gemacht und von NULL angefangen.
Also,
Ich konnte die Problem Nodes 2 und 3 sicher hinzufügen und im Anschluss auch konfigurieren und schalten. Zu sehen in Log.
Leider habe ich nur das Log und vergessen die Cache Dateien zu sichern.
zwave-1712.zip
Dann habe ich eine neue Node inkludiert, die nicht aufgetaucht ist. Deshalb habe ich Instanz neu gestartet und den Cache gelöscht.
Auf einmal funktioniert nur noch Node 3 und Node 2 behauptet wieder keine Secure zu können. Also selber Fehler wie zuvor. Nur jetzt nicht bei beiden, sondern nur einer Node.
neu.zip
@AlCalzone
hier das Log mit den Cache Dateien aus dem Backup: Nodes_aus_Cache.zip
Node 3 steuern über Multi- oder Binary Switch geht nicht.
Config übertragen (zwave2.0.Node_003.Configuration.maximumDimmingValue) scheint zu funktionieren. Wenn auch langsam. Wert steht ein paar Sekunden auf rot bevor Ack kommt.
Hier Log mit gelöschtem Cache: Cache_geloescht.zip
Dimmer nicht steuerbar und auch keine Config übertragbar.
Der Support sagt:
The secure modes in the z-wave are S0, S2 Authenticated and S2 unauthenticated. There was probably a gateway update that cause this as our devices are not updatable remotely.
Gibt es eine Möglichkeit mit zwave-js < 5.2. zu testen?
@AlCalzone Nur die Security anzuhängen hat nichts bewirkt.
Mit einem Backup der drei Cache Dateien sind die Nodes wieder alive und ready.
Sie lassen sich aber nicht steuern aus dem iobroker. Weder Multilevel- noch Binary-Switch.
Configuration lässt sich übertragen.
Habe den Support befragt.
Das es Probleme mit den Dimmern gibt, scheint aber nicht ganz neu:
https://community.openhab.org/t/status-updates-for-qubino-relays-dimmers-generally-do-not-work/32527/280
hi @AlCalzone!
Danke für dein Feedback!
Ich habe an dem ganzen z-wave Setup rein gar nichts verändert. Lediglich auf die 1.7.3 ge-updated.
Node 2 und 3 (https://support.qubino.com/support/solutions/articles/44001757253-qubino-din-dimmer) liefen bis vor wenigen Tagen noch tadellos.
Node 4 (https://support.qubino.com/support/solutions/articles/44001757250-qubino-flush-dimmer) ist in der Tat ein ähnliches Gerät.
Bis vor Kurzem sah das noch so aus:
20:51:24.933 CNTRLR « [Node 002] received response for protocol info:
basic device class: Static Controller
generic device class: Multilevel Switch
specific device class: Multilevel Power Switch
is a listening device: true
is frequent listening: false
is a routing device: true
is a secure device: unknown
is a beaming device: true
maximum baud rate: 40000 kbps
version: 4
20:51:25.295 CNTRLR « [Node 002] node info received
supported CCs:
· Z-Wave Plus Info
· Device Reset Locally
· Powerlevel
· Security
controlled CCs:
Irgend eine Idee, warum die beiden Nodes das auf einmal machen könnten?
