NEWS
Test Adapter Z-Wave 2 (v1.8.x)
-
@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-issue16: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
-
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
-
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
-
Du bist einfach perfekt

-
@wellknownasmax Sollte in der nächsten Version gefixt sein. Bin grade noch an nem anderen Problem dran, danach kann ich releasen.
@alcalzone
funktioniert jetzt fehlerfrei!
Vielen Dank!! -
Hallo an alle,
ich hab mal ein kleines Problem.

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 -
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? -
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?@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. -
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) -
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:- 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. - 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?
- 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.
-
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:- 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. - 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?
@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
- 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.
-
@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
@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

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

-
Aktuelle Test Version 1.8.12 Veröffentlichungsdatum 23.02.2021 Github Link https://github.com/AlCalzone/ioBroker.zwave2 Ich habe in letzter Zeit viel hinter den Kulissen gewerkelt, in der nächsten Stunde folgt die neue Version 1.8.0 als Ergebnis dieser Bemühungen.
Changelog
- Konfigurationsdateien für Fibaro Keyfob (keine Sonderzeichen mehr) und Shenzhen Neo PD03Z verbessert
- Nicht-kritische Schritte während des Interviews von
Central Scene CC,Configuration CC V3+undAssociation Group Info CCwerden jetzt übersprungen, wenn das Gerät nicht oder falsch antwortet - Multi Channel Lifeline Associations werden nicht mehr automatisch erstellt, wenn das Gerät die
Multi Channel CCnicht unterstützt - dies sollte die Kompatibilität mit den meisten Qubino-Geräten beheben - Es wurde ein Problem behoben, bei dem das automatische Markieren von Geräten als schlafend unter bestimmten Umständen die serielle Kommunikation mit dem Controller durcheinander gebracht hat.
- Die Eigenschaft
targetValuefür dieBinary Switch,Multilevel SwitchundBasicCCs wird jetzt auch dann erzeugt, wenn sie keinen Wert hat. - Leere Benutzercodes werden jetzt auch als Zeichenketten statt als Buffer behandelt.
- Werte für Notification Events (einmalige Ereignisse) werden jetzt erstellt. Zuvor waren nur Notification-Variablen als States in ioBroker verfügbar
Zusammengefasst:
@gelberlemmy - Die letzten beiden Punkte sollten hoffentlich (ich kanns leider nicht testen) dein Keypad nutzbar machen
@Domoe - Dein Problem mit Node 035 sollte hiermit hoffentlich auch weg sein
Update v1.8.1 (ein Riesen-Patch):
- Der
targetValuevon Switch CCs wird nicht mehr gelöscht, wenn ein Report ohne Zielwert empfangen wird - Konfigurationsdatei für
Jasco ZW3010hinzugefügt - Konfigurationsdatei für
HeatIt Z-TRM3hinzugefügt - Konfigurationsdatei für
Eurotronic Air quality sensor (Luftgütesensor)hinzugefügt - Verbesserte Unterstützung für
Qubino Flush 2 Relay - Die Werte für
Multi Channel Association CC,Z-Wave+ CCundNode Naming and Location CCsind jetzt ausgeblendet Color Switch CC:Setzen des warmweißentargetValuefunktioniert jetzt- Debug-Meldungen, die die Größe der Logdatei unnötig erhöht haben, wurden entfernt
- Das Entfernen einer Node-Verknüpfung (ohne Endpunkt) führt nicht mehr zu einem Fehler, wenn sowohl Multi-Channel- als auch normale Verknüpfungen unterstützt werden.
- Bestimmte
Notification CC Reports werden jetzt korrekt dekodiert. - Unterstützung für
*.gbl-Firmware-Dateien und Aeotec-Updater-Executables, die eine Prüfsumme und ein TargetChip-Byte enthalten, wurde hinzugefügt. - Ein Problem wurde behoben, bei dem unter bestimmten Umständen einem Befehl die falsche Antwort zugeordnet werden konnte
- ... und einige weitere kleinere Bugfixes
Update v1.8.3:
- Konfigurations datei für Technisat Dimmer and series switch hinzugefügt
- Zustand für leere Batterie hat jetzt den Namen
Battery Level Low - Ein Fehler beim Abfragen von
Binary Sensorbehoben, durch den die falschen Sensortypen abgefragt wurden. Betroffene Geräte müssen ggf. neu interviewt werden. - Die Strategie zum erneuten Senden von Nachrichten wurde überarbeitet. Sobald ein Gerät den Empfang bestätigt, wird nun nicht mehr erneut gesendet und stattdessen bis zu 10s (statt 1,6s) auf die Antwort gewartet.
- Werte, die Ereignis-Charakter haben (wie
Central Scenes) werden nun automatisch nach 1 Sekunde geleert.
Update v1.8.5:
- Ein Crash und eine Ursache für Interview-Abbrüche wurde behoben
- Logfiles werden wieder erstellt
- Diverse Gerätekonfigurationen aktualisiert
Update v1.8.6:
Ne ganze Menge an Bugfixes und neuen Konfigurationsdateien. Details siehe https://github.com/zwave-js/node-zwave-js/blob/master/CHANGELOG.md#changelog
Update v1.8.7:
- Die Szenen-ID der
Scene Activation CCwird nun automatisch zurückgesetzt - Einen Fehler behoben, der bei der Konfiguration von Verknüpfungen auftreten konnte
- Zwei potentielle Absturzquellen behoben
- Die Werte des Root-Endpunkts einiger älterer Geräte werden nun korrekt aktualisiert
- Unterstützung für
Aeotec aerQ ZWA009-AUS/Kanada/Mexiko-Version hinzugefügt - Ungültige Optionswerte in vielen Konfigurationsdateien korrigiert
Update v1.8.9:
- Beschriftungen für die Meter CC wurden verbessert und sind nun eindeutig.
- Viele Konfigurationsdateien wurden hinzugefügt und aktualisiert
- Verbesserte Kompatibilität mit einigen Geräten, vor allem
ID Lock 150,Vision Security ZD2102-5,HomeSeer WD200+ currentValueund ähnliche Werte werden jetzt sofort aktualisiert, wenn ein set-type-Befehl erfolgreich ist. Die Verifizierung der Änderung erfolgt nach einer kurzen Verzögerung.
Update v1.8.10:
- Der Start sollte nun schneller sein, insbesondere wenn viele schlafende Geräte im Netzwerk vorhanden sind
- Ein Problem wurde behoben, bei dem Geräte fälschlicherweise als sicher angezeigt wurden. @gelberlemmy
- Verbesserte Unterstützung für Geräte, die diealte
Alarm CCverwenden - Verschiedene Verbesserungen für Zooz- und GE-Geräte
Update v1.8.11:
Thermostat Fan Mode CCundThermostat Fan State CCimplementiert- Mehrere Absturzursachen behoben
- Fehlerhafte Erkennung von sicher eingebundenen Nodes behoben
- Bestimmte
.hex-Firmwaredateien werden jetzt korrekt geparst - Unterstützung für
.bin-Firmwaredateien hinzugefügt - Eine Interviewschleife wurde behoben, wenn Geräte das Ende der Config-Parameterliste nicht korrekt anzeigen
- Schlafende Nodes werden nun sofort als bereit markiert, wenn sie bereits vollständig interviewed wurden
- Selbstständige Nachrichten werden nicht mehr vom Root-Endpunkt auf Endpunkt 1 abgebildet, wenn dieser Endpunkt die betreffende CC nicht unterstützt
- Tonnenweise neue und verbesserte Gerätekonfigurationsdateien
Update v1.8.12:
- Implementierung von "Scene Actuator Configuration CC" und "Scene Controller Configuration CC".
- Behebung eines Problems, bei dem schlafende Knoten die Sendewarteschlange blockieren konnten, wenn noch nicht bekannt ist, ob sie
Wake Up CCunterstützen - Absturz behoben, der beim Loggen einer Nachricht auftreten konnte, während der Treiber noch nicht bereit ist
- Es wurde ein Absturz behoben, der beim Versuch auftreten konnte, ein Gerät zu initialisieren, das nach der Inklusion nicht antwortet
- Der Zustand
stateinThermostat Fan Mode CCist jetzt schreibgeschützt - Konfigurationsparameter können jetzt eine Einheit haben
- Tonnenweise neue und verbesserte Gerätekonfigurationsdateien
- Selbstständige Reports werden nicht mehr fälschlicherweise allen Endpunkten zugeordnet
@alcalzone guten Morgen, nachdem bei einem Bewegungsmelder die Batterie für einen Tag leer war,
war dieser nach Austausch nicht mehr im Netz registriert. Da ich glücklicherweise mit Alias arbeite,
ja kein Thema. Neu anlernen und gut. Nun hat er eine andere Node Nr. bekommen. Auch kein Problem. Aber warm ist bei den Node Nr, so eine groß Lücke ? Ich habe dort keine Geräte mehr anlernen wollen, was dieses Verhalten erklären könnte. Wobei mich diese große Lücke jetzt nicht stört,
Aber was ist, wenn ich irgendwann das Maximum der Anzahlen erreiche ? Wie bekomme ich die bereits fehlenden Nummern wieder zurück ? Gibt es da einen Tipp ?Gruß André

-
@alcalzone guten Morgen, nachdem bei einem Bewegungsmelder die Batterie für einen Tag leer war,
war dieser nach Austausch nicht mehr im Netz registriert. Da ich glücklicherweise mit Alias arbeite,
ja kein Thema. Neu anlernen und gut. Nun hat er eine andere Node Nr. bekommen. Auch kein Problem. Aber warm ist bei den Node Nr, so eine groß Lücke ? Ich habe dort keine Geräte mehr anlernen wollen, was dieses Verhalten erklären könnte. Wobei mich diese große Lücke jetzt nicht stört,
Aber was ist, wenn ich irgendwann das Maximum der Anzahlen erreiche ? Wie bekomme ich die bereits fehlenden Nummern wieder zurück ? Gibt es da einen Tipp ?Gruß André

@gelberlemmy sagte in Test Adapter Z-Wave 2 (v1.8.x):
nachdem bei einem Bewegungsmelder die Batterie für einen Tag leer war,
war dieser nach Austausch nicht mehr im Netz registriertDas kann nicht sein. Da ist irgendwas anderes passiert, z.B. am Gerät zurückgesetzt.
Aber warm ist bei den Node Nr, so eine groß Lücke ? Ich habe dort keine Geräte mehr anlernen wollen, was dieses Verhalten erklären könnte.
Kann ich mir auch nicht. Hast du zufällig einen Stick, bei dem man auch am Stick per Knopfdruck Geräte selbst an- und ablernen kann?
Sehr mysteriös, aber ich fürchte ohne dass du zufällig ein Log laufen hattest, finden wir das nicht mehr raus.Aber was ist, wenn ich irgendwann das Maximum der Anzahlen erreiche ?
Dann fängt es bei der ersten freien Zahl wieder an. Du könntest den BWM noch 112 mal ab- und anlernen, dann hast du diesen Zustand erreicht

-
@gelberlemmy sagte in Test Adapter Z-Wave 2 (v1.8.x):
nachdem bei einem Bewegungsmelder die Batterie für einen Tag leer war,
war dieser nach Austausch nicht mehr im Netz registriertDas kann nicht sein. Da ist irgendwas anderes passiert, z.B. am Gerät zurückgesetzt.
Aber warm ist bei den Node Nr, so eine groß Lücke ? Ich habe dort keine Geräte mehr anlernen wollen, was dieses Verhalten erklären könnte.
Kann ich mir auch nicht. Hast du zufällig einen Stick, bei dem man auch am Stick per Knopfdruck Geräte selbst an- und ablernen kann?
Sehr mysteriös, aber ich fürchte ohne dass du zufällig ein Log laufen hattest, finden wir das nicht mehr raus.Aber was ist, wenn ich irgendwann das Maximum der Anzahlen erreiche ?
Dann fängt es bei der ersten freien Zahl wieder an. Du könntest den BWM noch 112 mal ab- und anlernen, dann hast du diesen Zustand erreicht

@alcalzone sagte in Test Adapter Z-Wave 2 (v1.8.x):
@gelberlemmy sagte in Test Adapter Z-Wave 2 (v1.8.x):
nachdem bei einem Bewegungsmelder die Batterie für einen Tag leer war,
war dieser nach Austausch nicht mehr im Netz registriertDas kann nicht sein. Da ist irgendwas anderes passiert, z.B. am Gerät zurückgesetzt.
Aber warm ist bei den Node Nr, so eine groß Lücke ? Ich habe dort keine Geräte mehr anlernen wollen, was dieses Verhalten erklären könnte.
Kann ich mir auch nicht. Hast du zufällig einen Stick, bei dem man auch am Stick per Knopfdruck Geräte selbst an- und ablernen kann?
Sehr mysteriös, aber ich fürchte ohne dass du zufällig ein Log laufen hattest, finden wir das nicht mehr raus.Aber was ist, wenn ich irgendwann das Maximum der Anzahlen erreiche ?
Dann fängt es bei der ersten freien Zahl wieder an. Du könntest den BWM noch 112 mal ab- und anlernen, dann hast du diesen Zustand erreicht

Du wirst es mir nicht glauben, aber ich habe einen Log

Also ich habe einmal geschaut, das Gerät ist nicht zurückgesetzt, Dort sind noch die geänderten Einstellungen von mir enthalten. Nein ich habe keinen Taster auf dem Stick.
Hmmm.. Schicke Dir einmal den Log. Das Gerät war früher Node 073.Habe aber gesehen, hatte den Node 073 vor neu anlernen nicht gelöscht....:female-police-officer:
Gruß André
-
@alcalzone sagte in Test Adapter Z-Wave 2 (v1.8.x):
@gelberlemmy sagte in Test Adapter Z-Wave 2 (v1.8.x):
nachdem bei einem Bewegungsmelder die Batterie für einen Tag leer war,
war dieser nach Austausch nicht mehr im Netz registriertDas kann nicht sein. Da ist irgendwas anderes passiert, z.B. am Gerät zurückgesetzt.
Aber warm ist bei den Node Nr, so eine groß Lücke ? Ich habe dort keine Geräte mehr anlernen wollen, was dieses Verhalten erklären könnte.
Kann ich mir auch nicht. Hast du zufällig einen Stick, bei dem man auch am Stick per Knopfdruck Geräte selbst an- und ablernen kann?
Sehr mysteriös, aber ich fürchte ohne dass du zufällig ein Log laufen hattest, finden wir das nicht mehr raus.Aber was ist, wenn ich irgendwann das Maximum der Anzahlen erreiche ?
Dann fängt es bei der ersten freien Zahl wieder an. Du könntest den BWM noch 112 mal ab- und anlernen, dann hast du diesen Zustand erreicht

Du wirst es mir nicht glauben, aber ich habe einen Log

Also ich habe einmal geschaut, das Gerät ist nicht zurückgesetzt, Dort sind noch die geänderten Einstellungen von mir enthalten. Nein ich habe keinen Taster auf dem Stick.
Hmmm.. Schicke Dir einmal den Log. Das Gerät war früher Node 073.Habe aber gesehen, hatte den Node 073 vor neu anlernen nicht gelöscht....:female-police-officer:
Gruß André
Um 7:21 (ich weiß nicht welcher Tag) hast du Ausgefallenes Gerät entfernen geklickt. Daraufhin wurde Node 73 aus dem Netzwerk entfernt (Logzeile 111210).
07:21:21.919 DRIVER » [REQ] [RemoveFailedNode] payload: 0x496bNode 121 scheint aber schon wesentlich länger Teil des Netzwerks zu sein (Logzeile 7288) - zumindest glaubt er das. Der Controller (Stick) kennt ihn nicht. Entweder ist das ein anderer, oder Node 73 ist eigentlich schon ewig 121 ohne dass du ihn je angelernt hast...

21:42:28.489 DRIVER « [Node 121] [REQ] [ApplicationCommand] └─[WakeUpCCWakeUpNotification] 21:42:28.491 DRIVER the node is unknown or not initialized yet, discarding...In Zeile 108249 hast du ihn dann eingelernt, wobei er die von ihm genutzte ID behalten hat:
07:16:52.480 CNTRLR finished adding node 121:Ich weiß zwar nicht, warum der überhaupt glaubt, Teil des Netzwerks zu sein, wenn der Stick ihn nicht kennt. Aber das erklärt zumindest den ID-Sprung.
-
Hallo,
ich haette eine Frage zu meinen Fibaro Motion Sensor Fibargroup FGMS001 , wenn ich die Konfiguration aendern will bekomme ich
does not support the Command Class Configuration!
Dh ich kann die LED nicht abdrehen oder dergleichen.
Koennt Ihr bitte einen Tipp geben wo ich den Fehler suchen koennte.
Vielen Dank -
Hallo,
ich haette eine Frage zu meinen Fibaro Motion Sensor Fibargroup FGMS001 , wenn ich die Konfiguration aendern will bekomme ich
does not support the Command Class Configuration!
Dh ich kann die LED nicht abdrehen oder dergleichen.
Koennt Ihr bitte einen Tipp geben wo ich den Fehler suchen koennte.
Vielen Dank