UPDATE 31.10.: Amazon Alexa - ioBroker Skill läuft aus ?

[AlCalzone]

@troya Bitte https://github.com/AlCalzone/ioBroker.zwave2/blob/master/docs/de/bei-problemen.md lesen - insbesondere ganz unten (da wo es um die Logs geht).

@Esmax666 Ich habe den Zusammenhang zwischen RAM und Geräten noch nicht betrachtet. Das hängt eher mit der Anzahl der Datenpunkte zusammen.

[wellknownasmax]

Hallo,
ich habe ein kleines Problem mit dem Danalock und dem Danapad.
Wenn die Tür abgeschlossen ist und ich von außen mit Danapad entriegele stürzt der Z-Wave2 Adapter ab.

Nach dem Neustart funktioniert alles wie vorher...

[Flopsi]

@AlCalzone

Wie oft werden diese Datenpunkten aktualisiert ?

Will mir anzeigen lassen wann die Geäte ausfallen, haben den Stecker gezogen nach 30 min immer noch erreichbar und alive.

[AlCalzone]

@flopsi sagte in Test Adapter Z-Wave 2 (v1.8.x):

Will mir anzeigen lassen wann die Geäte ausfallen

Die werden nur aktualisiert, wenn der Adapter Nachrichten an die Geräte sendet. Live-Update geht prinzipbedingt nicht.

[Flopsi]

@alcalzone

mist ....:)

[AlCalzone]

@wellknownasmax Kannst du das Logfile mal herunterladen und hier posten?

Und kannst du bitte mal eine ZWave-Logdatei erstellen, das Problem herbeiführen und ebenfalls hier posten?
==> https://github.com/AlCalzone/ioBroker.zwave2/blob/master/docs/de/bei-problemen.md#notwendige-informationen-für-ein-issue

[wellknownasmax]

@alcalzone

16:59:37.918 CNTRLR   [Node 013] [~] [Multilevel Switch] currentValue: 26 => 24         [Endpoint 0]
16:59:37.919 SERIAL » [ACK]                                                                   (0x06)
16:59:37.920 DRIVER « [Node 013] [REQ] [ApplicationCommand]
                      └─[MultilevelSwitchCCReport]
                          current value: 24
16:59:48.990 SERIAL « 0x010a00040011028407c100a0                                          (12 bytes)
16:59:48.991 SERIAL » [ACK]                                                                   (0x06)
16:59:48.991 DRIVER « [Node 017] [REQ] [ApplicationCommand]
                      └─[WakeUpCCWakeUpNotification]
16:59:48.992 CNTRLR « [Node 017] received wakeup notification
16:59:48.993 CNTRLR   [Node 017] The node is now awake.
16:59:49.993 CNTRLR » [Node 017] Sending node back to sleep...
16:59:50.000 SERIAL » 0x0109001311028408252877                                            (11 bytes)
16:59:50.001 DRIVER » [Node 017] [REQ] [SendData]
                      │ transmit options: 0x25
                      │ callback id:      40
                      └─[WakeUpCCNoMoreInformation]
16:59:50.003 SERIAL « [ACK]                                                                   (0x06)
16:59:50.009 SERIAL « 0x0104011301e8                                                       (6 bytes)
16:59:50.010 SERIAL » [ACK]                                                                   (0x06)
16:59:50.010 DRIVER « [RES] [SendData]
                        was sent: true
16:59:50.029 SERIAL « 0x011800132800000200c17f7f7f7f00000300000000030100001e              (26 bytes)
16:59:50.030 SERIAL » [ACK]                                                                   (0x06)
16:59:50.030 DRIVER « [REQ] [SendData]
                        callback id:     40
                        transmit status: OK
16:59:50.034 CNTRLR   [Node 017] The node is now asleep.
17:00:49.995 SERIAL « 0x010a00040012029840c300fa                                          (12 bytes)
17:00:49.997 SERIAL » [ACK]                                                                   (0x06)
17:00:49.998 DRIVER « [Node 018] [REQ] [ApplicationCommand]
                      └─[SecurityCCNonceGet]
17:00:50.010 SERIAL » 0x01110013120a9880c6f8737c0d7062240529db                            (19 bytes)
17:00:50.011 DRIVER » [Node 018] [REQ] [SendData]
                      │ transmit options: 0x05
                      │ callback id:      41
                      └─[SecurityCCNonceReport]
                          nonce: 0xc6f8737c0d706224
17:00:50.014 SERIAL « [ACK]                                                                   (0x06)
17:00:50.019 SERIAL « 0x0104011301e8                                                       (6 bytes)
17:00:50.020 SERIAL » [ACK]                                                                   (0x06)
17:00:50.021 DRIVER « [RES] [SendData]
                        was sent: true
17:00:50.185 SERIAL « 0x011800132900001101c47f7f7f7f0001030f0000000201000007              (26 bytes)
17:00:50.186 SERIAL » [ACK]                                                                   (0x06)
17:00:50.186 DRIVER « [REQ] [SendData]
                        callback id:     41
                        transmit status: OK
17:00:50.313 SERIAL « 0x0125000400121d9881e1deb84cae0e94dad241faba87797f9d59fbc69e99edb65 (39 bytes)
                      7fcfb76c400f8
17:00:50.315 SERIAL » [ACK]                                                                   (0x06)
17:00:50.318 DRIVER « [Node 018] [REQ] [ApplicationCommand]
                      └─[SecurityCCCommandEncapsulation]
                        │ sequenced: false
                        └─[NotificationCCReport]
                            notification type:   Access Control
                            notification status: 255
                            notification event:  Keypad lock operation
17:00:50.456 SERIAL « 0x010a00040012029840c400fd                                          (12 bytes)
17:00:50.456 SERIAL » [ACK]                                                                   (0x06)
17:00:50.459 DRIVER « [Node 018] [REQ] [ApplicationCommand]
                      └─[SecurityCCNonceGet]
17:00:50.467 SERIAL » 0x01110013120a9880d6177db2dc4338f6052a8d                            (19 bytes)
17:00:50.468 DRIVER » [Node 018] [REQ] [SendData]
                      │ transmit options: 0x05
                      │ callback id:      42
                      └─[SecurityCCNonceReport]
                          nonce: 0xd6177db2dc4338f6
17:00:50.470 SERIAL « [ACK]                                                                   (0x06)
17:00:50.475 SERIAL « 0x0104011301e8                                                       (6 bytes)
17:00:50.475 SERIAL » [ACK]                                                                   (0x06)
17:00:50.476 DRIVER « [RES] [SendData]
                        was sent: true
17:00:50.607 SERIAL « 0x011800132a00000d01c47f7f7f7f0001030f0000000201000018              (26 bytes)
17:00:50.608 SERIAL » [ACK]                                                                   (0x06)
17:00:50.608 DRIVER « [REQ] [SendData]
                        callback id:     42
                        transmit status: OK
17:00:50.701 SERIAL « 0x0123000400121b9881dff663b9c1a0e9eddb2963a18708f083d61466ddc0eb6bb (37 bytes)
                      ed6c40007
17:00:50.702 SERIAL » [ACK]                                                                   (0x06)
17:00:50.703 CNTRLR   [Node 018] [~] [Door Lock] currentMode: 0 => 255                  [Endpoint 0]
17:00:50.704 CNTRLR   [Node 018] [~] [Door Lock] outsideHandlesCanOpenDoor: true,false, [Endpoint 0]
                      false,false => true,false,false,false
17:00:50.704 CNTRLR   [Node 018] [~] [Door Lock] insideHandlesCanOpenDoor: true,false,f [Endpoint 0]
                      alse,false => true,false,false,false
17:00:50.705 CNTRLR   [Node 018] [~] [Door Lock] latchStatus: "open" => "closed"        [Endpoint 0]
17:00:50.705 CNTRLR   [Node 018] [~] [Door Lock] boltStatus: "unlocked" => "locked"     [Endpoint 0]
17:00:50.706 CNTRLR   [Node 018] [~] [Door Lock] doorStatus: "open" => "closed"         [Endpoint 0]
17:00:50.707 DRIVER « [Node 018] [REQ] [ApplicationCommand]
                      └─[SecurityCCCommandEncapsulation]
                        │ sequenced: false
                        └─[DoorLockCCOperationReport]
                            current mode:           Secured
                            active outside handles: true, false, false, false
                            active inside handles:  true, false, false, false
                            latch status:           closed
                            bolt status:            locked
                            door status:            closed
17:01:23.630 SERIAL « 0x010a00040012029840c300fa                                          (12 bytes)
17:01:23.631 SERIAL » [ACK]                                                                   (0x06)
17:01:23.631 DRIVER « [Node 018] [REQ] [ApplicationCommand]
                      └─[SecurityCCNonceGet]
17:01:23.637 SERIAL » 0x01110013120a98805b9aa75aa55d67bd052bcd                            (19 bytes)
17:01:23.638 DRIVER » [Node 018] [REQ] [SendData]
                      │ transmit options: 0x05
                      │ callback id:      43
                      └─[SecurityCCNonceReport]
                          nonce: 0x5b9aa75aa55d67bd
17:01:23.640 SERIAL « [ACK]                                                                   (0x06)
17:01:23.646 SERIAL « 0x0104011301e8                                                       (6 bytes)
17:01:23.646 SERIAL » [ACK]                                                                   (0x06)
17:01:23.647 DRIVER « [RES] [SendData]
                        was sent: true
17:01:23.770 SERIAL « 0x011800132b00000c01c47f7f7f7f0001030f0000000201000018              (26 bytes)
17:01:23.770 SERIAL » [ACK]                                                                   (0x06)
17:01:23.771 DRIVER « [REQ] [SendData]
                        callback id:     43
                        transmit status: OK
17:01:23.897 SERIAL « 0x012d00040012259881a8a4d273dbd4b29918e39697599383ac38dfc6596743940 (47 bytes)
                      ee3625b56a3cf7a98279721c400ff
17:01:23.898 SERIAL » [ACK]                                                                   (0x06)
17:01:23.902 CNTRLR   [Node 018] [~] [User Code] userIdStatus[2]: 1 => 1                [Endpoint 0]
17:01:23.903 CNTRLR   [Node 018] [~] [User Code] userCode[2]: "5397" => "5397"          [Endpoint 0]
17:01:23.904 DRIVER « [Node 018] [REQ] [ApplicationCommand]
                      └─[SecurityCCCommandEncapsulation]
                        │ sequenced: false
                        └─[NotificationCCReport]
                            notification type:   Access Control
                            notification status: 255
                            notification event:  Keypad unlock operation
                            event parameters:    [object Object]
17:01:23.955 DRIVER   destroying driver instance...

Node ID des Danalock ist 018

[AlCalzone]

@wellknownasmax Super, danke! Jetzt bräuchte ich noch deinen Netzwerkschlüssel. Kannst du mir per PN schicken.

[AlCalzone]

@wellknownasmax Sollte in der nächsten Version gefixt sein. Bin grade noch an nem anderen Problem dran, danach kann ich releasen.

[AlCalzone]

1.8.11 auf dem Weg - Changelog oben!

[Rolf_KA]

@alcalzone

Du bist einfach perfekt :ok_hand: :relaxed:

[wellknownasmax]

@alcalzone
funktioniert jetzt fehlerfrei!
Vielen Dank!!

[Schlumpf]

Hallo an alle,

ich hab mal ein kleines Problem. :joy:

Warscheinlich wurde es schon irgendwo beantwortet oder es ist selbsterklähren und ich komm nur einfach nicht drauf. Ich habe bei mir mehrere Fibaro Rauchmelder und diese in ein Skript eingebunden. Gestern, nachdem ich mal ein "Netzwerk heilen" durchlaufen ließ, sind diese Skripte ausgelöst worden.

Bisher haben ich mich als Auslöser auf den Parameter zwave2.0.Node_013.Notification.smokeAlarm_alarmStatus gestützt und hier die abfrage auf "= 0" aufgebaut. Scheinbar hat sich der Wert der hier geschrieben wird geändert oder ich habe, warum auch immer, hier eine falsche annahme getroffen und das ganze falsch abgefragt.

Meine Frage: Wo und wie wird mir denn ein Rauchmelderalarm angezeigt bzw. wo rufe ich diesen ab?

Gruß
Jan

[Troya]

Nabend in die Runde,
Ich muss nochmal mit den currentvalue und targetvalue nerven. Ich meine die sollten doch mittlerweile ohne den Haken in den Optionen den gleichen Status behalten, aber bei mir ist das immernoch nicht der Fall.
Z. B. Bei meinem erneut frisch inkludiertem Asus Schloss, aber auch bei einem vor langen inkludierten Fibaro FGS223:
Schalte ich per Hand den Lichtschalter ein, wird der currentvalue Wert auf ON gesetzt, der targetvalue Wert bleibt aber bei OFF.
Oder soll das so sein, dass quasi der currentvalue den Hardware Zustand zeigt und der targetvalue den Software Zustand?

[AlCalzone]

@troya sagte in Test Adapter Z-Wave 2 (v1.8.x):

Ich meine die sollten doch mittlerweile ohne den Haken in den Optionen den gleichen Status behalten, aber bei mir ist das immernoch nicht der Fall.

Wie kommst du drauf, dass sich da was geändert hat?

An sich heißt currentValue "hier bin ich" und targetValue "hier will ich hin".
Wenn Geräte den targetValue nicht berichten, was vor allem ältere Geräte tun, dann kann der Wert in ioBroker nicht aktualisiert werden. Dafür ist die Option da.

[AlCalzone]

Version 1.8.12 ist auf dem Weg - kurzer Changelog wieder oben.

Die detaillierte (englische) Liste findet sich hier - manches davon trifft aber nicht direkt auf den Adapter zu:
https://github.com/zwave-js/node-zwave-js/blob/master/CHANGELOG.md (6.4.0 und 6.5.0)

[Zuki]

Ich habe letztens meine ioBroker Instanz von einem Synology Docker zu einer Proxmox VM umgezogen. Mit Backup und Restore kein Problem. Allerdings lies sich per Z-Wave 2 Adapter danach keine Geräte mehr steuern. Nicht so wild, ich habe nicht so viele Z-Wave Geräte. Also alle vom Aeon Z-Stick entkoppelt und neu gekoppelt. Leider keine Änderung. Also habe ich den Z-Stick und alle Geräte resettet um quasi wieder bei Null anzufangen.
Jetzt habe ich aber zwei Probleme die im Docker nicht auftraten:

1. Meine Schalter und die Fibaro Zwischenstecker funktionieren einwandfrei. Nur zum Fibaro Rollershutter 2 der die Projektorleinwand steuert lässt sich keine Verbindung mehr aufbauen. Ich kann den Aktor normal anlernen aber der Gerätetyp wird von Z-Wave Adapter auch nach längerer Wartezeit nicht erkannt. Der Log zeigt folgendes, und zwar durchgehend. Node 5 ist dabei natürlich der Rolladenaktor.
   
   Wie gesagt, die anderen Geräte funktionieren.
2. Problem: Das Anlernen (egal ob verschlüsselt oder unverschlüsselt) lässt sich nicht mehr vom Adapter aus starten. Somit musste ich aller Geräte per Hardwarebutton auf dem Z-Stick anlernen. Was natürlich unverschlüsselt stattfindet...
   Wenn ich den Stick per Adapter in den Anlernmodus schalte, findet einfach kein Paring statt.

Hat jemand Tipps für mich was falsch laufen könnte?

[AlCalzone]

@zuki sagte in Test Adapter Z-Wave 2 (v1.8.x):

Der Log zeigt folgendes, und zwar durchgehend.

Die Verbindung bzw. Route zu/von Node 5 ist schlecht - versuch es mal mit Netzwerk heilen. Hast du beim Umzug die physische Position des Sticks geändert?

@zuki sagte in Test Adapter Z-Wave 2 (v1.8.x):

Wenn ich den Stick per Adapter in den Anlernmodus schalte, findet einfach kein Paring statt.

Hast du Logs? ==> https://github.com/AlCalzone/ioBroker.zwave2/blob/master/docs/de/bei-problemen.md#notwendige-informationen-für-ein-issue

[Zuki]

@alcalzone Danke für die Hilfe.

Ich habe noch einen zusätzlichen Z-Wave Zwischenstecker installiert. Das scheint das Netz so stabilisiert zu haben das nun alles funktioniert. Danke für den Tipp.

Dabei habe ich auch nochmal den Z-Wave stick ausgesteckt, resettet und in einen anderen USB Port gesteckt. Keine Ahnung was nun geholfen hat aber nun funktioniert auch das Anlernen wieder :+1:

[Thomas Jansen]

@AlCalzone Huhu, ich habe mein Zwave Netzwerk jetzt komplett auf Deinen Adapter umgestellt. Ein Aktor jedoch ist unter dem alten Zwave Adapter funktionsfähig mit Datenpunkten, in Deinem Adapter jedoch findet er nur einige wenige. Es handelt sich um die Zwave Innensirene von VISION. Kennst Du die? Ich bekomme keinen Datenpunkt bezüglich der Auslösung auch nicht um den Alarm zurückzustellen?

HAT SICH ERLEDIGT GEFUNDEN!!! MEIN FEHLER!!! ;)