NEWS
Test Adapter Z-Wave 2 (v1.7.x)
-
@EvilEls Hast du Node 2 und 3 sicher eingebunden? Irgendwas ist da komisch... Node 2 behauptet, er wäre ein
Multilevel Power Switch:21:30:42.991 CNTRLR « [Node 002] received response for protocol info: basic device class: Static Controller generic device class: Multilevel Switch specific device class: Multilevel Power Switch [...]behauptet dann aber, er unterstützt nur die folgenden 3 CCs:
21:30:43.319 CNTRLR « [Node 002] node info received supported CCs: · Z-Wave Plus Info · Device Reset Locally · Powerlevel controlled CCs:Aufgrund der ersten Aussage wird zu diesen noch die "Pflicht"-CC
Multilevel Switchergänzt, auf deren Interview vom Node aber keine Antwort kommt.
Node 4 (ein ähnliches Gerät?) gibt zusätzlich noch
Security CCals unterstützt an:21:30:43.493 CNTRLR « [Node 004] node info received supported CCs: · Z-Wave Plus Info · Device Reset Locally · Powerlevel · Securityund berichtet dort, dass
Multilevel Switch CCverschlüsselt unterstützt ist:21:30:44.615 DRIVER « [Node 004] [REQ] [ApplicationCommand] └─[SecurityCCCommandEncapsulation] │ sequenced: false └─[SecurityCCCommandsSupportedReport] reportsToFollow: 0 supportedCCs: · Version · Manufacturer Specific · All Switch · Binary Switch · Multilevel Switch · Meter · Notification · Association · Multi Channel Association · Association Group Information · Configuration controlledCCs: · Multilevel Switchhi @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: 420: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?
-
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: 420: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?
@EvilEls sagte in Test Adapter Z-Wave 2 (v1.7.x):
Irgend eine Idee, warum die beiden Nodes das auf einmal machen könnten?
Ne keinen Schimmer - aber anscheinend vergessen die auch gerne mal zu berichten, dass sie manche Dinge können... Eventuell lohnt es sich, mal beim Support nachzufragen.
Einen Workaround hätte ich - du solltest danach nur vermeiden, den Cache zu löschen, sonst gehts wieder von vorne los.- Adapter stoppen.
/opt/iobroker/iobroker-data/zwave2.0/cache/<deine-home-id>.jsonmit einem Editor öffnen
Die Datei enthält eine Struktur, die in etwa so aussieht:
{ "nodes": { "1": { "id": 1, ... }, "2": { "id": 2, ... "commandClasses": { ... } }, "3": { "id": 3, ... "commandClasses": { ... } } ... } }- Nach der Zeile mit
commandClassesvon Node 2 und 3 jeweils bitte folgendes einfügen:
"0x98": { "name": "Security", "endpoints": { "0": { "isSupported": true, "isControlled": false, "secure": true, "version": 1 } } },- Datei speichern, Adapter wieder starten.
Warum `sudo` böse ist: https://forum.iobroker.net/post/17109
-
@EvilEls sagte in Test Adapter Z-Wave 2 (v1.7.x):
Irgend eine Idee, warum die beiden Nodes das auf einmal machen könnten?
Ne keinen Schimmer - aber anscheinend vergessen die auch gerne mal zu berichten, dass sie manche Dinge können... Eventuell lohnt es sich, mal beim Support nachzufragen.
Einen Workaround hätte ich - du solltest danach nur vermeiden, den Cache zu löschen, sonst gehts wieder von vorne los.- Adapter stoppen.
/opt/iobroker/iobroker-data/zwave2.0/cache/<deine-home-id>.jsonmit einem Editor öffnen
Die Datei enthält eine Struktur, die in etwa so aussieht:
{ "nodes": { "1": { "id": 1, ... }, "2": { "id": 2, ... "commandClasses": { ... } }, "3": { "id": 3, ... "commandClasses": { ... } } ... } }- Nach der Zeile mit
commandClassesvon Node 2 und 3 jeweils bitte folgendes einfügen:
"0x98": { "name": "Security", "endpoints": { "0": { "isSupported": true, "isControlled": false, "secure": true, "version": 1 } } },- Datei speichern, Adapter wieder starten.
@AlCalzone Nur die Security anzuhängen hat nichts bewirkt.
Mit einem Backup der drei Cache Dateien sind die Nodes wiederaliveundready.
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 -
@AlCalzone Nur die Security anzuhängen hat nichts bewirkt.
Mit einem Backup der drei Cache Dateien sind die Nodes wiederaliveundready.
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@EvilEls sagte in Test Adapter Z-Wave 2 (v1.7.x):
Sie lassen sich aber nicht steuern aus dem iobroker. Weder Multilevel- noch Binary-Switch.
Configuration lässt sich übertragen.Kannste mir davon mal ein Log machen bitte? Und die Cache-Dateien vor dem Backup würde ich auch gerne sehen.
Warum `sudo` böse ist: https://forum.iobroker.net/post/17109
-
@EvilEls sagte in Test Adapter Z-Wave 2 (v1.7.x):
Sie lassen sich aber nicht steuern aus dem iobroker. Weder Multilevel- noch Binary-Switch.
Configuration lässt sich übertragen.Kannste mir davon mal ein Log machen bitte? Und die Cache-Dateien vor dem Backup würde ich auch gerne sehen.
@AlCalzone
hier das Log mit den Cache Dateien aus dem Backup: Nodes_aus_Cache.zipNode 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
hier das Log mit den Cache Dateien aus dem Backup: Nodes_aus_Cache.zipNode 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?
@EvilEls Ich glaube nicht, dass irgend eine andere Adapter-Version daran was ändert - die machen die gleichen Abfragen.
Mit den Cache-Dateien aus dem Backup wird zwar versucht, die Security CC zu interviewen, aber selbst darauf antwortet Node 3 nicht mehr. Ich würde den Support mal fragen, wie es sein kann, dass der Node überhaupt keine Security mehr unterstützt (und sonst auch nix).Falls sie sich selbst vergewissern wollen, das ist was der Node behauptet zu können:
14 bytes: 01 - Start of Frame 0c - 12 bytes follow 00 - type: Request 49 - function type: ApplicationUpdateRequest 84 - update type: NodeInfo_Received 03 - node ID 3 06 - 6 bytes follow 04 - basic device class: Static Controller 11 - generic device class: Multilevel Switch 01 - specific device class: Multilevel Power Switch 5e - CC supported: "Z-Wave Plus Info" 5a - CC supported: "Device Reset Locally" 73 - CC supported: "Powerlevel" 58 - checksumwährend es für Node 4 wie folgt aussieht:
15 bytes: 01 - Start of Frame 0d - 13 bytes follow (!) 00 - type: Request 49 - function type: ApplicationUpdateRequest 84 - update type: NodeInfo_Received 04 - node ID 4 07 - 7 bytes follow (!) 04 - basic device class: Static Controller 11 - generic device class: Multilevel Switch 01 - specific device class: Multilevel Power Switch 5e - CC supported: "Z-Wave Plus Info" 5a - CC supported: "Device Reset Locally" 73 - CC supported: "Powerlevel" 98 - CC supported: "Security S0" (!) c7 - checksumEs ist also eindeutig, dass Node 3 "vergessen" hat, dass er Security kann. Die Support-Aussage erscheint mir etwas abwimmelnd.
Falls du auf dieser Front nicht weiter kommst, bleibt dir wie ich fürchte nur noch eine Lösung:
- Gerät ablernen
- Gerät auf Auslieferungszustand zurücksetzen
- Gerät wieder anlernen
Warum `sudo` böse ist: https://forum.iobroker.net/post/17109
-
@EvilEls sagte in Test Adapter Z-Wave 2 (v1.7.x):
Sie lassen sich aber nicht steuern aus dem iobroker. Weder Multilevel- noch Binary-Switch.
Configuration lässt sich übertragen.Kannste mir davon mal ein Log machen bitte? Und die Cache-Dateien vor dem Backup würde ich auch gerne sehen.
@AlCalzone
Ich habe nun alles platt gemacht und von NULL angefangen.
Also,- Stick reset
- alle Nodes reset
- Adapter gelöscht
- 1.7.4. neu drauf
- neu inkludiert
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.zipDann 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 -
@EvilEls Ich glaube nicht, dass irgend eine andere Adapter-Version daran was ändert - die machen die gleichen Abfragen.
Mit den Cache-Dateien aus dem Backup wird zwar versucht, die Security CC zu interviewen, aber selbst darauf antwortet Node 3 nicht mehr. Ich würde den Support mal fragen, wie es sein kann, dass der Node überhaupt keine Security mehr unterstützt (und sonst auch nix).Falls sie sich selbst vergewissern wollen, das ist was der Node behauptet zu können:
14 bytes: 01 - Start of Frame 0c - 12 bytes follow 00 - type: Request 49 - function type: ApplicationUpdateRequest 84 - update type: NodeInfo_Received 03 - node ID 3 06 - 6 bytes follow 04 - basic device class: Static Controller 11 - generic device class: Multilevel Switch 01 - specific device class: Multilevel Power Switch 5e - CC supported: "Z-Wave Plus Info" 5a - CC supported: "Device Reset Locally" 73 - CC supported: "Powerlevel" 58 - checksumwährend es für Node 4 wie folgt aussieht:
15 bytes: 01 - Start of Frame 0d - 13 bytes follow (!) 00 - type: Request 49 - function type: ApplicationUpdateRequest 84 - update type: NodeInfo_Received 04 - node ID 4 07 - 7 bytes follow (!) 04 - basic device class: Static Controller 11 - generic device class: Multilevel Switch 01 - specific device class: Multilevel Power Switch 5e - CC supported: "Z-Wave Plus Info" 5a - CC supported: "Device Reset Locally" 73 - CC supported: "Powerlevel" 98 - CC supported: "Security S0" (!) c7 - checksumEs ist also eindeutig, dass Node 3 "vergessen" hat, dass er Security kann. Die Support-Aussage erscheint mir etwas abwimmelnd.
Falls du auf dieser Front nicht weiter kommst, bleibt dir wie ich fürchte nur noch eine Lösung:
- Gerät ablernen
- Gerät auf Auslieferungszustand zurücksetzen
- Gerät wieder anlernen
@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 wiederdeadwar) war nur noch manchmal erreichbar/steuerbar, trotz dass sie aufalivestand.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 Version5.2.2) komplett deinstalliert und die5.2.0installiert.
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.zipIch könnte das Ganze noch mal mit
zwave-js@5.2.1testen, 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,- Stick reset
- alle Nodes reset
- Adapter gelöscht
- 1.7.4. neu drauf
- neu inkludiert
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.zipDann 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@EvilEls sagte in Test Adapter Z-Wave 2 (v1.7.x):
Dann habe ich eine neue Node inkludiert, die nicht aufgetaucht ist. Deshalb habe ich Instanz neu gestartet und den Cache gelöscht.
@EvilEls sagte in Test Adapter Z-Wave 2 (v1.7.x):
Nun habe ich den Cache gelöscht.
Gefühlt löschst du sehr oft den Cache. Das löscht alle Informationen über alle Nodes und führt dazu, dass alle neu interviewt werden. Wenn dabei einer der Nodes entscheidet, dass er plötzlich keine Security CC mehr kann, stehst du wieder vor der Wand.
Wenn ein Node nach dem Einbinden nicht kommt, reicht es in der Regel, zu warten ihn zu wecken oder den Adapter neu zu starten.
-
Moin Moin zusammen,
ich habe vor kurzen das ABUS CFA3010 bekommen und dachte mir hey das kannste für den Abstellraum nehmen aber ich bekomme es einfach nicht eingebunden.Z-Wave 2 in IO installiert.
Hardware:
Z-Wave USB Stick (ZMEEUZB1)
Kann mir jemand helfen was ich hier falsch mache ? Falls noch was fehlt bitte bescheid geben. Ich danke euch.
Gruß
Rene -
Hat außer mir sonst noch jemand die Zipato RGB Bulb 2 im Einsatz? Sie wird im Z-Wave 2-Adapter nicht richtig eingebunden:
Die Datenpunkte scheinen - soweit ich das beurteilen kann - vollständig erzeugt, jedoch werden die Target-Values schreibgeschützt erstellt. Wenn ich das ändere, werden die Eingaben in die Current-Values übernommen, aber ohne dass die Lampe die Farbe ändert.
Ich kann also die Lampe dimmen, aber keine Farbe ändern.
Diesen Fehler habe ich übrigens mit der Version 1.5.1 und nun auch in der 1.7.5. -
Moin Moin zusammen,
ich habe vor kurzen das ABUS CFA3010 bekommen und dachte mir hey das kannste für den Abstellraum nehmen aber ich bekomme es einfach nicht eingebunden.Z-Wave 2 in IO installiert.
Hardware:
Z-Wave USB Stick (ZMEEUZB1)Kann mir jemand helfen was ich hier falsch mache ? Falls noch was fehlt bitte bescheid geben. Ich danke euch.
Gruß
Rene@gfrene sagte in Test Adapter Z-Wave 2 (v1.7.x):
Kann mir jemand helfen was ich hier falsch mache
Weck das Teil mal manuell auf. Wie das geht, sollte in der Anleitung stehen. Manche Geräte brauchen 1-2 Anläufe, bis das Interview fertig ist.
Falls das alles nicht hilft, wie hier beschrieben ein Log erstellen und posten.
@BausSH sagte in Test Adapter Z-Wave 2 (v1.7.x):
jedoch werden die Target-Values schreibgeschützt erstellt
Das dürfte eigentlich nicht sein. Zeig mir mal die ioBroker-Objektdefinition (auf Bleistift, dann auf Reiter "Raw").
-
Hallo,
habe folgendes Problem mit meiner Steinel RS LED D2 Z-Wave.
NODE_027
Sobald ich diese einschalte Spamt Sie so das Netzwerk voll, dass kaum noch andere Befehle durchkommen.Auszug iobroker Log
zwave2.1 2020-10-12 10:53:07.141 debug (22492) Node 15: metadata updated: airTemperature zwave2.1 2020-10-12 10:53:07.084 debug (22492) Node 15: value updated: overrideState => Unused zwave2.1 2020-10-12 10:53:07.083 debug (22492) Node 15: value updated: overrideType => 0 zwave2.1 2020-10-12 10:53:07.026 debug (22492) Node 15: value updated: setpoint_heating => 4 zwave2.1 2020-10-12 10:53:06.977 debug (22492) Node 15: value updated: isLow => true zwave2.1 2020-10-12 10:53:06.973 debug (22492) Node 15: value updated: level => 0 zwave2.1 2020-10-12 10:51:01.941 debug (22492) Node 27: value updated: currentValue => false zwave2.1 2020-10-12 10:51:01.920 debug (22492) Node 27: value updated: currentValue => false zwave2.1 2020-10-12 10:51:01.899 debug (22492) Node 27: value updated: currentValue => false zwave2.1 2020-10-12 10:51:01.874 debug (22492) Node 27: value updated: currentValue => false zwave2.1 2020-10-12 10:51:01.854 debug (22492) Node 27: value updated: currentValue => false zwave2.1 2020-10-12 10:51:01.834 debug (22492) Node 27: value updated: currentValue => false zwave2.1 2020-10-12 10:51:01.813 debug (22492) Node 27: value updated: currentValue => false zwave2.1 2020-10-12 10:51:01.791 debug (22492) Node 27: value updated: currentValue => false zwave2.1 2020-10-12 10:51:01.771 debug (22492) Node 27: value updated: currentValue => false zwave2.1 2020-10-12 10:51:01.750 debug (22492) Node 27: value updated: currentValue => false zwave2.1 2020-10-12 10:51:01.729 debug (22492) Node 27: value updated: currentValue => false zwave2.1 2020-10-12 10:51:01.708 debug (22492) Node 27: value updated: currentValue => false zwave2.1 2020-10-12 10:51:01.686 debug (22492) Node 27: value updated: currentValue => false zwave2.1 2020-10-12 10:51:01.667 debug (22492) Node 27: value updated: currentValue => false zwave2.1 2020-10-12 10:51:01.645 debug (22492) Node 27: value updated: currentValue => false zwave2.1 2020-10-12 10:51:01.623 debug (22492) Node 27: value updated: currentValue => false zwave2.1 2020-10-12 10:51:01.603 debug (22492) Node 27: value updated: currentValue => false zwave2.1 2020-10-12 10:51:01.581 debug (22492) Node 27: value updated: currentValue => false zwave2.1 2020-10-12 10:51:01.561 debug (22492) Node 27: value updated: currentValue => false zwave2.1 2020-10-12 10:51:01.540 debug (22492) Node 27: value updated: currentValue => false zwave2.1 2020-10-12 10:51:01.519 debug (22492) Node 27: value updated: currentValue => false zwave2.1 2020-10-12 10:51:01.498 debug (22492) Node 27: value updated: currentValue => false zwave2.1 2020-10-12 10:51:01.477 debug (22492) Node 27: value updated: currentValue => false zwave2.1 2020-10-12 10:51:01.456 debug (22492) Node 27: value updated: currentValue => false zwave2.1 2020-10-12 10:51:01.435 debug (22492) Node 27: value updated: currentValue => false zwave2.1 2020-10-12 10:51:01.414 debug (22492) Node 27: value updated: currentValue => false zwave2.1 2020-10-12 10:51:01.393 debug (22492) Node 27: value updated: currentValue => false zwave2.1 2020-10-12 10:51:01.373 debug (22492) Node 27: value updated: currentValue => false zwave2.1 2020-10-12 10:51:01.352 debug (22492) Node 27: value updated: currentValue => false zwave2.1 2020-10-12 10:51:01.330 debug (22492) Node 27: value updated: currentValue => false zwave2.1 2020-10-12 10:51:01.310 debug (22492) Node 27: value updated: currentValue => false zwave2.1 2020-10-12 10:51:01.289 debug (22492) Node 27: value updated: currentValue => false zwave2.1 2020-10-12 10:51:01.268 debug (22492) Node 27: value updated: currentValue => false zwave2.1 2020-10-12 10:51:01.247 debug (22492) Node 27: value updated: currentValue => false zwave2.1 2020-10-12 10:51:01.226 debug (22492) Node 27: value updated: currentValue => false zwave2.1 2020-10-12 10:51:01.205 debug (22492) Node 27: value updated: currentValue => false zwave2.1 2020-10-12 10:51:01.184 debug (22492) Node 27: value updated: currentValue => false zwave2.1 2020-10-12 10:51:01.162 debug (22492) Node 27: value updated: currentValue => false zwave2.1 2020-10-12 10:51:01.142 debug (22492) Node 27: value updated: currentValue => false zwave2.1 2020-10-12 10:51:01.122 debug (22492) Node 27: value updated: currentValue => false zwave2.1 2020-10-12 10:51:01.100 debug (22492) Node 27: value updated: currentValue => false zwave2.1 2020-10-12 10:51:01.078 debug (22492) Node 27: value updated: currentValue => false zwave2.1 2020-10-12 10:51:01.059 debug (22492) Node 27: value updated: currentValue => falseLog Dateien Anbei
201012 Steinel RS LED D2 Harry94.rar
Vielen Dank schonmal
-
@gfrene sagte in Test Adapter Z-Wave 2 (v1.7.x):
Kann mir jemand helfen was ich hier falsch mache
Weck das Teil mal manuell auf. Wie das geht, sollte in der Anleitung stehen. Manche Geräte brauchen 1-2 Anläufe, bis das Interview fertig ist.
Falls das alles nicht hilft, wie hier beschrieben ein Log erstellen und posten.
@BausSH sagte in Test Adapter Z-Wave 2 (v1.7.x):
jedoch werden die Target-Values schreibgeschützt erstellt
Das dürfte eigentlich nicht sein. Zeig mir mal die ioBroker-Objektdefinition (auf Bleistift, dann auf Reiter "Raw").
@AlCalzone
Hier ist die Anzeige vom target-Value (blue):{ "from": "system.adapter.zwave2.0", "user": "system.user.admin", "ts": 1602513248918, "common": { "name": "Target value (Blue)", "role": "value", "desc": "The target value of the Blue color.", "type": "number", "min": 0, "max": 255, "read": true, "write": false }, "native": { "nodeId": 9, "valueId": { "commandClass": 51, "endpoint": 0, "property": "targetColor", "propertyKey": 4 } }, "acl": { "object": 1638, "owner": "system.user.admin", "ownerGroup": "system.group.administrator", "state": 1638 }, "_id": "zwave2.0.Node_009.Color_Switch.targetColor_blue", "type": "state" } -
@AlCalzone
Hier ist die Anzeige vom target-Value (blue):{ "from": "system.adapter.zwave2.0", "user": "system.user.admin", "ts": 1602513248918, "common": { "name": "Target value (Blue)", "role": "value", "desc": "The target value of the Blue color.", "type": "number", "min": 0, "max": 255, "read": true, "write": false }, "native": { "nodeId": 9, "valueId": { "commandClass": 51, "endpoint": 0, "property": "targetColor", "propertyKey": 4 } }, "acl": { "object": 1638, "owner": "system.user.admin", "ownerGroup": "system.group.administrator", "state": 1638 }, "_id": "zwave2.0.Node_009.Color_Switch.targetColor_blue", "type": "state" }@BausSH sagte in Test Adapter Z-Wave 2 (v1.7.x):
"read": true, "write": falseWhoops! :sweat:
DieColor Switch CChat jemand anders implementiert, das ist mir beim Review wohl durch die Lappen gegangen. Issue ist erstellt --> https://github.com/AlCalzone/node-zwave-js/issues/1038@Harry94 das is ja übel - das ganze Log besteht aus fast nix anderem... Scheint loszugehen nachdem das Interview abgeschlossen ist:
10:49:08.569 CNTRLR [Node 027] treating BasicCC Set as a report 10:49:08.569 CNTRLR [Node 027] [~] [Binary Switch] currentValue: false => false [Endpoint 0] 10:49:08.587 SERIAL « 0x010d0004001b07600d0201200100a5 (15 bytes) 10:49:08.588 SERIAL » [ACK] (0x06) 10:49:08.589 DRIVER « [Node 027] [REQ] [ApplicationCommand] └─[MultiChannelCCCommandEncapsulation] │ source: 2 │ destination: 1 └─[BasicCCSet] target value: 0 10:49:08.591 CNTRLR [Node 027] treating BasicCC Set as a report 10:49:08.591 CNTRLR [Node 027] [~] [Binary Switch] currentValue: false => false [Endpoint 0] 10:49:08.608 SERIAL « 0x010d0004001b07600d0201200100a5 (15 bytes) 10:49:08.609 SERIAL » [ACK] (0x06) 10:49:08.609 DRIVER « [Node 027] [REQ] [ApplicationCommand] └─[MultiChannelCCCommandEncapsulation] │ source: 2 │ destination: 1 └─[BasicCCSet] target value: 0 10:49:08.612 CNTRLR [Node 027] treating BasicCC Set as a report 10:49:08.612 CNTRLR [Node 027] [~] [Binary Switch] currentValue: false => false [Endpoint 0] 10:49:08.629 SERIAL « 0x010d0004001b07600d0201200100a5 (15 bytes) 10:49:08.629 SERIAL » [ACK] (0x06) 10:49:08.630 DRIVER « [Node 027] [REQ] [ApplicationCommand] └─[MultiChannelCCCommandEncapsulation] │ source: 2 │ destination: 1 └─[BasicCCSet] target value: 0 10:49:08.631 CNTRLR [Node 027] treating BasicCC Set as a report 10:49:08.631 CNTRLR [Node 027] [~] [Binary Switch] currentValue: false => false [Endpoint 0] 10:49:08.650 SERIAL « 0x010d0004001b07600d0201200100a5 (15 bytes) 10:49:08.650 SERIAL » [ACK] (0x06) 10:49:08.651 DRIVER « [Node 027] [REQ] [ApplicationCommand] └─[MultiChannelCCCommandEncapsulation] │ source: 2 │ destination: 1 └─[BasicCCSet] target value: 0 10:49:08.653 CNTRLR [Node 027] treating BasicCC Set as a report 10:49:08.653 CNTRLR [Node 027] [~] [Binary Switch] currentValue: false => false [Endpoint 0] 10:49:08.671 SERIAL « 0x010d0004001b07600d0201200100a5 (15 bytes) 10:49:08.672 SERIAL » [ACK] (0x06) 10:49:08.672 DRIVER « [Node 027] [REQ] [ApplicationCommand] └─[MultiChannelCCCommandEncapsulation] │ source: 2 │ destination: 1 └─[BasicCCSet] target value: 0 ... ca. 7000 times more...Würde sich ggf. lohnen beim Hersteller nachzufragen, was da faul ist.
-
@AlCalzone Sorry konnte letzte Woche leider nicht testen.
Nun aber auch mit der neuen Version hat er kein Value in Notifiation (hier smokeAlarm_sensorStatus).
Anbei der Log geht um die Nodes 33-39
Danke und Gruß
-
@BausSH sagte in Test Adapter Z-Wave 2 (v1.7.x):
"read": true, "write": falseWhoops! :sweat:
DieColor Switch CChat jemand anders implementiert, das ist mir beim Review wohl durch die Lappen gegangen. Issue ist erstellt --> https://github.com/AlCalzone/node-zwave-js/issues/1038@Harry94 das is ja übel - das ganze Log besteht aus fast nix anderem... Scheint loszugehen nachdem das Interview abgeschlossen ist:
10:49:08.569 CNTRLR [Node 027] treating BasicCC Set as a report 10:49:08.569 CNTRLR [Node 027] [~] [Binary Switch] currentValue: false => false [Endpoint 0] 10:49:08.587 SERIAL « 0x010d0004001b07600d0201200100a5 (15 bytes) 10:49:08.588 SERIAL » [ACK] (0x06) 10:49:08.589 DRIVER « [Node 027] [REQ] [ApplicationCommand] └─[MultiChannelCCCommandEncapsulation] │ source: 2 │ destination: 1 └─[BasicCCSet] target value: 0 10:49:08.591 CNTRLR [Node 027] treating BasicCC Set as a report 10:49:08.591 CNTRLR [Node 027] [~] [Binary Switch] currentValue: false => false [Endpoint 0] 10:49:08.608 SERIAL « 0x010d0004001b07600d0201200100a5 (15 bytes) 10:49:08.609 SERIAL » [ACK] (0x06) 10:49:08.609 DRIVER « [Node 027] [REQ] [ApplicationCommand] └─[MultiChannelCCCommandEncapsulation] │ source: 2 │ destination: 1 └─[BasicCCSet] target value: 0 10:49:08.612 CNTRLR [Node 027] treating BasicCC Set as a report 10:49:08.612 CNTRLR [Node 027] [~] [Binary Switch] currentValue: false => false [Endpoint 0] 10:49:08.629 SERIAL « 0x010d0004001b07600d0201200100a5 (15 bytes) 10:49:08.629 SERIAL » [ACK] (0x06) 10:49:08.630 DRIVER « [Node 027] [REQ] [ApplicationCommand] └─[MultiChannelCCCommandEncapsulation] │ source: 2 │ destination: 1 └─[BasicCCSet] target value: 0 10:49:08.631 CNTRLR [Node 027] treating BasicCC Set as a report 10:49:08.631 CNTRLR [Node 027] [~] [Binary Switch] currentValue: false => false [Endpoint 0] 10:49:08.650 SERIAL « 0x010d0004001b07600d0201200100a5 (15 bytes) 10:49:08.650 SERIAL » [ACK] (0x06) 10:49:08.651 DRIVER « [Node 027] [REQ] [ApplicationCommand] └─[MultiChannelCCCommandEncapsulation] │ source: 2 │ destination: 1 └─[BasicCCSet] target value: 0 10:49:08.653 CNTRLR [Node 027] treating BasicCC Set as a report 10:49:08.653 CNTRLR [Node 027] [~] [Binary Switch] currentValue: false => false [Endpoint 0] 10:49:08.671 SERIAL « 0x010d0004001b07600d0201200100a5 (15 bytes) 10:49:08.672 SERIAL » [ACK] (0x06) 10:49:08.672 DRIVER « [Node 027] [REQ] [ApplicationCommand] └─[MultiChannelCCCommandEncapsulation] │ source: 2 │ destination: 1 └─[BasicCCSet] target value: 0 ... ca. 7000 times more...Würde sich ggf. lohnen beim Hersteller nachzufragen, was da faul ist.
@AlCalzone said in Test Adapter Z-Wave 2 (v1.7.x):
Issue ist erstellt
Vielen Dank. Allerdings ist der Schreibschutz in den Datenpunkten "nur" kosmetischer Natur. Ich kann das ändern, dann werden die Daten auch in die Current-Values übernommen. Nur die Lampe tut nichts. Sie bleibt weiß.
Oder wird das auch mit Änderung des Schreibschutzes behoben? Dann ist das natürlich erledigt.
Support us
484
Online32.4k
Benutzer81.5k
Themen1.3m
Beiträge