Seite drucken - UZB1 Stick: Lizenz schaltet AES Security frei?

Titel: UZB1 Stick: Lizenz schaltet AES Security frei?
Beitrag von: buspirat am 18 November 2016, 13:37:11

Hallo Zusammen,

ich betreibe momentan einen Zwave.me UZB1 USB-Stick als Zwave-Controller (https://www.z-wave.me/index.php?id=28)
Im Auslieferungszustand bietet dieser leider keine SECURITY Class für die AES-128 Verschlüsselung.

Jetzt kann man eine "Z-Way" Lizenz für diesen Stick kaufen (https://www.z-wave.me/index.php?id=41), die teurer als der ursprüngliche Stick ist. In irgendeinem Forum hatte ich gelesen, daß dies auch die SECURITY class freischalten soll.

Stimmt das? Hat jemand damit Erfahrung?

Oder kann man die AES-128 Verschlüsselung auch rein über FHEM softwaremäßig abwickeln?

Ich habe vor knapp einer Woche die Frage nach der SECURITY class an den Zwave.me Support gestellt, jedoch keine Antwort erhalten :( Dabei will ich bei der Firma etwas kaufen...

Viele Grüße
Thomas

Titel: Antw:UZB1 Stick: Lizenz schaltet AES Security frei?
Beitrag von: rudolfkoenig am 18 November 2016, 13:42:19

ZitatIm Auslieferungszustand bietet dieser leider keine SECURITY Class für die AES-128 Verschlüsselung.

Wie hast du das festgestellt? Meins funktioniert mit SECURITY, und ch habe Z-Way noch nie gesehen.

Titel: Antw:UZB1 Stick: Lizenz schaltet AES Security frei?
Beitrag von: krikan am 18 November 2016, 13:46:12

Meins auch.

Titel: Antw:UZB1 Stick: Lizenz schaltet AES Security frei?
Beitrag von: A.Harrenberg am 18 November 2016, 14:45:19

Hi,

SECURITY ist eine Befehlsklasse wie jede andere auch und ist in fhem implementiert. Der Stick muss dazu rein gar nichts machen, SECURITY geht mit jedem Stick...

Um SECURITY mit fhem zu nutzen muss man allerdings das Perl-Modul zur Verschlüsselung installieren, einen Netzwerkschlüssel definieren und die Geräte dann auch explizit mit Security einbinden (addnode mit onSec oder onNwSec ausführen). Teilweise muss dann am Gerät auch noch eine andere Taste oder Tastenkombination ausgewählt werden als bei einer normalen Inklusion.

Gruß,
Andreas.

Titel: Antw:UZB1 Stick: Lizenz schaltet AES Security frei?
Beitrag von: buspirat am 19 November 2016, 11:35:49

Zitat von: A.Harrenberg am 18 November 2016, 14:45:19
Um SECURITY mit fhem zu nutzen muss man allerdings das Perl-Modul zur Verschlüsselung installieren, einen Netzwerkschlüssel definieren und die Geräte dann auch explizit mit Security einbinden

Danke für die Antworten.

Das perl-Crypt-Rijndael Modul war installiert. Das 'networkKey' Attribut zum Testen sah so aus:

Code Auswählen


529105e7cf66bf3e94c42737e3b51129

Einen Kaltstart des Systems hatte ich auch ausprobiert.

Ich bin ursprünglich davon ausgegangen, daß 'SECURITY' unter den Capabilities des Controllers auftauchen muss. Ist natürlich Käse, wenn es eine Command Class ist :)

Werde es morgen erneut mit einem anderen Gerät ausprobieren. Ursprünglich hatte ich die KFOB-C Fernbedienung genommen, vielleicht ist die Devolo Steckdose kooperativer.

Sieht man in der FHEM Logdatei beim Start, ob SECURITY korrekt initialisiert wird?
Nicht das es nachher an irgendeinem Tippfehler lag.

Titel: Antw:UZB1 Stick: Lizenz schaltet AES Security frei?
Beitrag von: A.Harrenberg am 19 November 2016, 12:00:33

Hi,

Zitat von: buspirat am 19 November 2016, 11:35:49
Werde es morgen erneut mit einem anderen Gerät ausprobieren. Ursprünglich hatte ich die KFOB-C Fernbedienung genommen, vielleicht ist die Devolo Steckdose kooperativer.

Sieht man in der FHEM Logdatei beim Start, ob SECURITY korrekt initialisiert wird?
Nicht das es nachher an irgendeinem Tippfehler lag.

es gibt nur Fehlermeldungen im Log wenn bei der Inklusion was schief läuft, dann würde fhem meckern wenn das Modul nicht installiert ist oder der Networkkey nicht da ist. Im Device selbst gibt es nach der Inklusion ein Reading SECURITY das im Erfolgsfall auf ENABLED steht, anonsten sollte dort auch ein kleiner Hinweis auftauchen was schief gegangen ist.

Gruß,
Andreas.

Titel: Antw:UZB1 Stick: Lizenz schaltet AES Security frei?
Beitrag von: buspirat am 20 November 2016, 13:17:08

Ok, wenn man weiß das es funktionieren müsste, dann bleibt man hartnäckiger.
Nachdem ich die KFOB-C Fernbedienung zweimal eingebunden hatte, hat sie sich auch im SECURITY Modus eingefügt :)

Vor den Versuchen habe ich ein FHEM update gefahren. Folgender kleiner Bug ist mir aufgefallen:

Code Auswählen


2016.11.20 13:09:45 5: ZWDongle_0 dispatch 0004001e0a9880f10d28f06f3401a4
2016.11.20 13:09:45 4: CMD:APPLICATION_COMMAND_HANDLER ID:1e ARG:0a9880f10d28f06f3401a4 CB:00
2016.11.20 13:09:45 1: ZWave_SENSOR_NOTIFICATION_30: no stored commands in Internal secMsg found
2016.11.20 13:09:45 1: PERL WARNING: Use of uninitialized value $getSecMsg in split at ./FHEM/10_ZWave.pm line 3424.
2016.11.20 13:09:45 1: ZWave_SENSOR_NOTIFICATION_30: Error, nonce reveived but no stored command for encryption found
2016.11.20 13:09:45 4: ZWDongle_Read ZWDongle_0: CAN received
2016.11.20 13:09:45 4: ZWDongle_Read ZWDongle_0: rcvd 0004001e0a9880b8c5dd453a51c51b (request APPLICATION_COMMAND_HANDLER), sending ACK

"Use of uninitialized value $getSecMsg in split at ./FHEM/10_ZWave.pm line 3424."

Titel: Antw:UZB1 Stick: Lizenz schaltet AES Security frei?
Beitrag von: buspirat am 20 November 2016, 13:25:25

Einen "Philio Technology Corporation PST02-A 4 in 1 Multi-Sensor" habe ich auch mit SECURITY eingebunden.

Allerdings scheint mir die Kommunikation gestört zu sein. Löse ich den Fenstersensor aus, dann folgen bildschirmweise Funktelegramme:

Code Auswählen


2016.11.20 13:18:24 4: ZWDongle_Read ZWDongle_0: rcvd 0004001e029840 (request APPLICATION_COMMAND_HANDLER), sending ACK
2016.11.20 13:18:24 5: SW: 06
2016.11.20 13:18:24 5: ZWDongle_0 dispatch 0004001e029840
2016.11.20 13:18:24 4: CMD:APPLICATION_COMMAND_HANDLER ID:1e ARG:029840 CB:00
2016.11.20 13:18:24 5: ZWDongle_Write 00131e0a988061ad43b5cfc923712501 (ee557686)
2016.11.20 13:18:24 5: SW: 011100131e0a988061ad43b5cfc923712501bb
2016.11.20 13:18:24 5: ACK received, WaitForAck=>2 for 011100131e0a988061ad43b5cfc923712501bb
2016.11.20 13:18:24 4: ZWDongle_Read ZWDongle_0: rcvd 011301 (answer ZW_SEND_DATA), sending ACK
2016.11.20 13:18:24 5: SW: 06
2016.11.20 13:18:24 5: ZWDongle_0 dispatch 011301
2016.11.20 13:18:24 4: ZWDongle_Read ZWDongle_0: rcvd 001301000002 (request ZW_SEND_DATA), sending ACK
2016.11.20 13:18:24 5: SW: 06
2016.11.20 13:18:24 5: device ack reveived, removing 011100131e0a988061ad43b5cfc923712501bb from dongle sendstack
2016.11.20 13:18:24 5: ZWDongle_0 dispatch 001301000002
2016.11.20 13:18:24 4: CMD:ZW_SEND_DATA ID:00 ARG:0002 CB:01
2016.11.20 13:18:24 4: ZWDongle_0 transmit OK for CB 01, target ZWave_SENSOR_NOTIFICATION_30
2016.11.20 13:18:24 4: ZWDongle_Read ZWDongle_0: rcvd 0004001e1a9881d4fc4652dac0fe157513fcd5a5de7c6138bc9804ed7877a8 (request APPLICATION_COMMAND_HANDLER), sending ACK
2016.11.20 13:18:24 5: SW: 06
2016.11.20 13:18:24 5: ZWDongle_0 dispatch 0004001e1a9881d4fc4652dac0fe157513fcd5a5de7c6138bc9804ed7877a8
2016.11.20 13:18:24 4: CMD:APPLICATION_COMMAND_HANDLER ID:1e ARG:1a9881d4fc4652dac0fe157513fcd5a5de7c6138bc9804ed7877a8 CB:00
2016.11.20 13:18:24 4: CMD:APPLICATION_COMMAND_HANDLER ID:1e ARG:063105012200cd CB:00
2016.11.20 13:18:24 4: ZWDongle_Read ZWDongle_0: rcvd 0004001e029840 (request APPLICATION_COMMAND_HANDLER), sending ACK
2016.11.20 13:18:24 5: SW: 06
2016.11.20 13:18:24 5: ZWDongle_0 dispatch 0004001e029840
2016.11.20 13:18:24 4: CMD:APPLICATION_COMMAND_HANDLER ID:1e ARG:029840 CB:00
2016.11.20 13:18:24 5: ZWDongle_Write 00131e0a9880a3583c75a7b367c12502 (ee557686)
2016.11.20 13:18:24 5: SW: 011100131e0a9880a3583c75a7b367c12502d6
2016.11.20 13:18:24 5: ACK received, WaitForAck=>2 for 011100131e0a9880a3583c75a7b367c12502d6
2016.11.20 13:18:24 4: ZWDongle_Read ZWDongle_0: rcvd 011301 (answer ZW_SEND_DATA), sending ACK
2016.11.20 13:18:24 5: SW: 06
2016.11.20 13:18:24 5: ZWDongle_0 dispatch 011301
2016.11.20 13:18:24 4: ZWDongle_Read ZWDongle_0: rcvd 001302000002 (request ZW_SEND_DATA), sending ACK
2016.11.20 13:18:24 5: SW: 06
2016.11.20 13:18:24 5: device ack reveived, removing 011100131e0a9880a3583c75a7b367c12502d6 from dongle sendstack
2016.11.20 13:18:24 5: ZWDongle_0 dispatch 001302000002
2016.11.20 13:18:24 4: CMD:ZW_SEND_DATA ID:00 ARG:0002 CB:02
2016.11.20 13:18:24 4: ZWDongle_0 transmit OK for CB 02, target ZWave_SENSOR_NOTIFICATION_30
2016.11.20 13:18:24 4: ZWDongle_Read ZWDongle_0: rcvd 0004001e199881fac741dbb309a25b21148afda565a34207f5f0d04bcdf4 (request APPLICATION_COMMAND_HANDLER), sending ACK
2016.11.20 13:18:24 5: SW: 06
2016.11.20 13:18:24 5: ZWDongle_0 dispatch 0004001e199881fac741dbb309a25b21148afda565a34207f5f0d04bcdf4
2016.11.20 13:18:24 4: CMD:APPLICATION_COMMAND_HANDLER ID:1e ARG:199881fac741dbb309a25b21148afda565a34207f5f0d04bcdf4 CB:00
2016.11.20 13:18:24 4: CMD:APPLICATION_COMMAND_HANDLER ID:1e ARG:05310503012c CB:00
2016.11.20 13:18:24 4: ZWDongle_Read ZWDongle_0: rcvd 0004001e029840 (request APPLICATION_COMMAND_HANDLER), sending ACK
2016.11.20 13:18:24 5: SW: 06
2016.11.20 13:18:24 5: ZWDongle_0 dispatch 0004001e029840
2016.11.20 13:18:24 4: CMD:APPLICATION_COMMAND_HANDLER ID:1e ARG:029840 CB:00
2016.11.20 13:18:24 5: ZWDongle_Write 00131e0a9880bab3f3563bda55012503 (ee557686)
2016.11.20 13:18:24 5: SW: 011100131e0a9880bab3f3563bda55012503ce
2016.11.20 13:18:24 5: ACK received, WaitForAck=>2 for 011100131e0a9880bab3f3563bda55012503ce
2016.11.20 13:18:24 4: ZWDongle_Read ZWDongle_0: rcvd 011301 (answer ZW_SEND_DATA), sending ACK
2016.11.20 13:18:24 5: SW: 06
2016.11.20 13:18:24 5: ZWDongle_0 dispatch 011301
2016.11.20 13:18:24 4: ZWDongle_Read ZWDongle_0: rcvd 001303000002 (request ZW_SEND_DATA), sending ACK
2016.11.20 13:18:24 5: SW: 06
2016.11.20 13:18:24 5: device ack reveived, removing 011100131e0a9880bab3f3563bda55012503ce from dongle sendstack
2016.11.20 13:18:24 5: ZWDongle_0 dispatch 001303000002
2016.11.20 13:18:24 4: CMD:ZW_SEND_DATA ID:00 ARG:0002 CB:03
2016.11.20 13:18:24 4: ZWDongle_0 transmit OK for CB 03, target ZWave_SENSOR_NOTIFICATION_30
2016.11.20 13:18:24 4: ZWDongle_Read ZWDongle_0: rcvd 0004001e1a98819f867168c4e3657dff09c73b82f2dbbafed0f13510c89748 (request APPLICATION_COMMAND_HANDLER), sending ACK
2016.11.20 13:18:24 5: SW: 06
2016.11.20 13:18:24 5: ZWDongle_0 dispatch 0004001e1a98819f867168c4e3657dff09c73b82f2dbbafed0f13510c89748
2016.11.20 13:18:24 4: CMD:APPLICATION_COMMAND_HANDLER ID:1e ARG:1a98819f867168c4e3657dff09c73b82f2dbbafed0f13510c89748 CB:00
2016.11.20 13:18:24 4: CMD:APPLICATION_COMMAND_HANDLER ID:1e ARG:063105012200c8 CB:00
2016.11.20 13:18:24 4: ZWDongle_Read ZWDongle_0: rcvd 0004001e029840 (request APPLICATION_COMMAND_HANDLER), sending ACK
2016.11.20 13:18:24 5: SW: 06
2016.11.20 13:18:24 5: ZWDongle_0 dispatch 0004001e029840
2016.11.20 13:18:24 4: CMD:APPLICATION_COMMAND_HANDLER ID:1e ARG:029840 CB:00
2016.11.20 13:18:24 5: ZWDongle_Write 00131e0a9880af7beb44bef01c8d2504 (ee557686)
2016.11.20 13:18:24 5: SW: 011100131e0a9880af7beb44bef01c8d250474
2016.11.20 13:18:24 5: ACK received, WaitForAck=>2 for 011100131e0a9880af7beb44bef01c8d250474
2016.11.20 13:18:24 4: ZWDongle_Read ZWDongle_0: rcvd 011301 (answer ZW_SEND_DATA), sending ACK
2016.11.20 13:18:24 5: SW: 06
2016.11.20 13:18:24 5: ZWDongle_0 dispatch 011301
2016.11.20 13:18:24 4: ZWDongle_Read ZWDongle_0: rcvd 001304000002 (request ZW_SEND_DATA), sending ACK
2016.11.20 13:18:24 5: SW: 06
2016.11.20 13:18:24 5: device ack reveived, removing 011100131e0a9880af7beb44bef01c8d250474 from dongle sendstack
2016.11.20 13:18:24 5: ZWDongle_0 dispatch 001304000002
2016.11.20 13:18:24 4: CMD:ZW_SEND_DATA ID:00 ARG:0002 CB:04
2016.11.20 13:18:24 4: ZWDongle_0 transmit OK for CB 04, target ZWave_SENSOR_NOTIFICATION_30
2016.11.20 13:18:24 4: ZWDongle_Read ZWDongle_0: rcvd 0004001e17988173c89261e298601be519eb57af47cd7f2ac1091fce (request APPLICATION_COMMAND_HANDLER), sending ACK
2016.11.20 13:18:24 5: SW: 06
2016.11.20 13:18:24 5: ZWDongle_0 dispatch 0004001e17988173c89261e298601be519eb57af47cd7f2ac1091fce
2016.11.20 13:18:24 4: CMD:APPLICATION_COMMAND_HANDLER ID:1e ARG:17988173c89261e298601be519eb57af47cd7f2ac1091fce CB:00
2016.11.20 13:18:24 4: CMD:APPLICATION_COMMAND_HANDLER ID:1e ARG:03800364 CB:00
2016.11.20 13:18:24 4: ZWDongle_Read ZWDongle_0: rcvd 0004001e029840 (request APPLICATION_COMMAND_HANDLER), sending ACK
2016.11.20 13:18:24 5: SW: 06
2016.11.20 13:18:24 5: ZWDongle_0 dispatch 0004001e029840
2016.11.20 13:18:24 4: CMD:APPLICATION_COMMAND_HANDLER ID:1e ARG:029840 CB:00
2016.11.20 13:18:24 5: ZWDongle_Write 00131e0a98804b6b3630d74a43992505 (ee557686)
2016.11.20 13:18:24 5: SW: 011100131e0a98804b6b3630d74a43992505b0
2016.11.20 13:18:24 5: ACK received, WaitForAck=>2 for 011100131e0a98804b6b3630d74a43992505b0
2016.11.20 13:18:24 4: ZWDongle_Read ZWDongle_0: rcvd 011301 (answer ZW_SEND_DATA), sending ACK
2016.11.20 13:18:24 5: SW: 06
2016.11.20 13:18:24 5: ZWDongle_0 dispatch 011301
2016.11.20 13:18:24 4: ZWDongle_Read ZWDongle_0: rcvd 001305000003 (request ZW_SEND_DATA), sending ACK
2016.11.20 13:18:24 5: SW: 06
2016.11.20 13:18:24 5: device ack reveived, removing 011100131e0a98804b6b3630d74a43992505b0 from dongle sendstack
2016.11.20 13:18:24 5: ZWDongle_0 dispatch 001305000003
2016.11.20 13:18:24 4: CMD:ZW_SEND_DATA ID:00 ARG:0003 CB:05
2016.11.20 13:18:24 4: ZWDongle_0 transmit OK for CB 05, target ZWave_SENSOR_NOTIFICATION_30
2016.11.20 13:18:24 4: ZWDongle_Read ZWDongle_0: rcvd 0004001e1d988112222e56bbaaacfc19d30d4fcaea7cd1d70e4b3583c0bb9f8d318a (request APPLICATION_COMMAND_HANDLER), sending ACK
2016.11.20 13:18:24 5: SW: 06
2016.11.20 13:18:24 5: ZWDongle_0 dispatch 0004001e1d988112222e56bbaaacfc19d30d4fcaea7cd1d70e4b3583c0bb9f8d318a
2016.11.20 13:18:24 4: CMD:APPLICATION_COMMAND_HANDLER ID:1e ARG:1d988112222e56bbaaacfc19d30d4fcaea7cd1d70e4b3583c0bb9f8d318a CB:00
2016.11.20 13:18:24 4: CMD:APPLICATION_COMMAND_HANDLER ID:1e ARG:097105000000ff070800 CB:00
2016.11.20 13:18:24 4: ZWDongle_Read ZWDongle_0: rcvd 0004001e029840 (request APPLICATION_COMMAND_HANDLER), sending ACK
2016.11.20 13:18:24 5: SW: 06
2016.11.20 13:18:24 5: ZWDongle_0 dispatch 0004001e029840
2016.11.20 13:18:24 4: CMD:APPLICATION_COMMAND_HANDLER ID:1e ARG:029840 CB:00
2016.11.20 13:18:24 5: ZWDongle_Write 00131e0a9880a81ddfdc699804642506 (ee557686)
2016.11.20 13:18:24 5: SW: 011100131e0a9880a81ddfdc699804642506f5
2016.11.20 13:18:24 5: ACK received, WaitForAck=>2 for 011100131e0a9880a81ddfdc699804642506f5
2016.11.20 13:18:24 4: ZWDongle_Read ZWDongle_0: rcvd 011301 (answer ZW_SEND_DATA), sending ACK
2016.11.20 13:18:24 5: SW: 06
2016.11.20 13:18:24 5: ZWDongle_0 dispatch 011301
2016.11.20 13:18:24 4: ZWDongle_Read ZWDongle_0: rcvd 001306000003 (request ZW_SEND_DATA), sending ACK
2016.11.20 13:18:24 5: SW: 06
2016.11.20 13:18:24 5: device ack reveived, removing 011100131e0a9880a81ddfdc699804642506f5 from dongle sendstack
2016.11.20 13:18:24 5: ZWDongle_0 dispatch 001306000003
2016.11.20 13:18:24 4: CMD:ZW_SEND_DATA ID:00 ARG:0003 CB:06
2016.11.20 13:18:24 4: ZWDongle_0 transmit OK for CB 06, target ZWave_SENSOR_NOTIFICATION_30
2016.11.20 13:18:24 4: ZWDongle_Read ZWDongle_0: rcvd 0004001e199881a885e8d8699aa7284689d9d9d5fea8bce1aa6cf312c77f (request APPLICATION_COMMAND_HANDLER), sending ACK
2016.11.20 13:18:24 5: SW: 06
2016.11.20 13:18:24 5: ZWDongle_0 dispatch 0004001e199881a885e8d8699aa7284689d9d9d5fea8bce1aa6cf312c77f
2016.11.20 13:18:24 4: CMD:APPLICATION_COMMAND_HANDLER ID:1e ARG:199881a885e8d8699aa7284689d9d9d5fea8bce1aa6cf312c77f CB:00
2016.11.20 13:18:24 4: CMD:APPLICATION_COMMAND_HANDLER ID:1e ARG:05310503012c CB:00
2016.11.20 13:18:24 4: ZWDongle_Read ZWDongle_0: rcvd 0004001e029840 (request APPLICATION_COMMAND_HANDLER), sending ACK
2016.11.20 13:18:24 5: SW: 06
2016.11.20 13:18:24 5: ZWDongle_0 dispatch 0004001e029840
2016.11.20 13:18:24 4: CMD:APPLICATION_COMMAND_HANDLER ID:1e ARG:029840 CB:00
2016.11.20 13:18:24 5: ZWDongle_Write 00131e0a9880dc9f78d227bb659c2507 (ee557686)
2016.11.20 13:18:24 5: SW: 011100131e0a9880dc9f78d227bb659c25075f
2016.11.20 13:18:24 5: ACK received, WaitForAck=>2 for 011100131e0a9880dc9f78d227bb659c25075f
2016.11.20 13:18:24 4: ZWDongle_Read ZWDongle_0: rcvd 011301 (answer ZW_SEND_DATA), sending ACK
2016.11.20 13:18:24 5: SW: 06
2016.11.20 13:18:24 5: ZWDongle_0 dispatch 011301
2016.11.20 13:18:24 4: ZWDongle_Read ZWDongle_0: rcvd 001307000003 (request ZW_SEND_DATA), sending ACK
2016.11.20 13:18:24 5: SW: 06
2016.11.20 13:18:24 5: device ack reveived, removing 011100131e0a9880dc9f78d227bb659c25075f from dongle sendstack
2016.11.20 13:18:24 5: ZWDongle_0 dispatch 001307000003
2016.11.20 13:18:24 4: CMD:ZW_SEND_DATA ID:00 ARG:0003 CB:07
2016.11.20 13:18:24 4: ZWDongle_0 transmit OK for CB 07, target ZWave_SENSOR_NOTIFICATION_30
2016.11.20 13:18:24 4: ZWDongle_Read ZWDongle_0: rcvd 0004001e1a98819c6a0951dfefd3868ff315a3322390dce32c7630d232dd1b (request APPLICATION_COMMAND_HANDLER), sending ACK
2016.11.20 13:18:24 5: SW: 06
2016.11.20 13:18:24 5: ZWDongle_0 dispatch 0004001e1a98819c6a0951dfefd3868ff315a3322390dce32c7630d232dd1b
2016.11.20 13:18:24 4: CMD:APPLICATION_COMMAND_HANDLER ID:1e ARG:1a98819c6a0951dfefd3868ff315a3322390dce32c7630d232dd1b CB:00
2016.11.20 13:18:24 4: CMD:APPLICATION_COMMAND_HANDLER ID:1e ARG:063105012200c8 CB:00
2016.11.20 13:18:24 4: ZWDongle_Read ZWDongle_0: rcvd 0004001e029840 (request APPLICATION_COMMAND_HANDLER), sending ACK
2016.11.20 13:18:24 5: SW: 06
2016.11.20 13:18:24 5: ZWDongle_0 dispatch 0004001e029840
2016.11.20 13:18:24 4: CMD:APPLICATION_COMMAND_HANDLER ID:1e ARG:029840 CB:00
2016.11.20 13:18:24 5: ZWDongle_Write 00131e0a9880ba8bc9baab2910072508 (ee557686)
2016.11.20 13:18:24 5: SW: 011100131e0a9880ba8bc9baab29100725080b
2016.11.20 13:18:24 5: ACK received, WaitForAck=>2 for 011100131e0a9880ba8bc9baab29100725080b
2016.11.20 13:18:24 4: ZWDongle_Read ZWDongle_0: rcvd 011301 (answer ZW_SEND_DATA), sending ACK
2016.11.20 13:18:24 5: SW: 06
2016.11.20 13:18:24 5: ZWDongle_0 dispatch 011301
2016.11.20 13:18:24 4: ZWDongle_Read ZWDongle_0: rcvd 001308000002 (request ZW_SEND_DATA), sending ACK
2016.11.20 13:18:24 5: SW: 06
2016.11.20 13:18:24 5: device ack reveived, removing 011100131e0a9880ba8bc9baab29100725080b from dongle sendstack
2016.11.20 13:18:24 5: ZWDongle_0 dispatch 001308000002
2016.11.20 13:18:24 4: CMD:ZW_SEND_DATA ID:00 ARG:0002 CB:08
2016.11.20 13:18:24 4: ZWDongle_0 transmit OK for CB 08, target ZWave_SENSOR_NOTIFICATION_30
2016.11.20 13:18:24 4: ZWDongle_Read ZWDongle_0: rcvd 0004001e17988144ed6b1e6242a30f9d879b52ba838fb9fc62366e64 (request APPLICATION_COMMAND_HANDLER), sending ACK
2016.11.20 13:18:24 5: SW: 06
2016.11.20 13:18:24 5: ZWDongle_0 dispatch 0004001e17988144ed6b1e6242a30f9d879b52ba838fb9fc62366e64
2016.11.20 13:18:24 4: CMD:APPLICATION_COMMAND_HANDLER ID:1e ARG:17988144ed6b1e6242a30f9d879b52ba838fb9fc62366e64 CB:00
2016.11.20 13:18:24 4: CMD:APPLICATION_COMMAND_HANDLER ID:1e ARG:03800364 CB:00
2016.11.20 13:18:25 4: ZWDongle_Read ZWDongle_0: rcvd 0004001e029840 (request APPLICATION_COMMAND_HANDLER), sending ACK
2016.11.20 13:18:25 5: SW: 06
2016.11.20 13:18:25 5: ZWDongle_0 dispatch 0004001e029840
2016.11.20 13:18:25 4: CMD:APPLICATION_COMMAND_HANDLER ID:1e ARG:029840 CB:00
2016.11.20 13:18:25 5: ZWDongle_Write 00131e0a9880520344711440e40c2509 (ee557686)
2016.11.20 13:18:25 5: SW: 011100131e0a9880520344711440e40c250905
2016.11.20 13:18:25 5: ACK received, WaitForAck=>2 for 011100131e0a9880520344711440e40c250905
2016.11.20 13:18:25 4: ZWDongle_Read ZWDongle_0: rcvd 011301 (answer ZW_SEND_DATA), sending ACK
2016.11.20 13:18:25 5: SW: 06
2016.11.20 13:18:25 5: ZWDongle_0 dispatch 011301
2016.11.20 13:18:25 4: ZWDongle_Read ZWDongle_0: rcvd 001309000002 (request ZW_SEND_DATA), sending ACK
2016.11.20 13:18:25 5: SW: 06
2016.11.20 13:18:25 5: device ack reveived, removing 011100131e0a9880520344711440e40c250905 from dongle sendstack
2016.11.20 13:18:25 5: ZWDongle_0 dispatch 001309000002
2016.11.20 13:18:25 4: CMD:ZW_SEND_DATA ID:00 ARG:0002 CB:09
2016.11.20 13:18:25 4: ZWDongle_0 transmit OK for CB 09, target ZWave_SENSOR_NOTIFICATION_30
2016.11.20 13:18:25 4: ZWDongle_Read ZWDongle_0: rcvd 0004001e1d9881f34f5200e0328fdc45b33e0f040e742d8d1452068d8c05eca85a97 (request APPLICATION_COMMAND_HANDLER), sending ACK
2016.11.20 13:18:25 5: SW: 06
2016.11.20 13:18:25 5: ZWDongle_0 dispatch 0004001e1d9881f34f5200e0328fdc45b33e0f040e742d8d1452068d8c05eca85a97
2016.11.20 13:18:25 4: CMD:APPLICATION_COMMAND_HANDLER ID:1e ARG:1d9881f34f5200e0328fdc45b33e0f040e742d8d1452068d8c05eca85a97 CB:00
2016.11.20 13:18:25 4: CMD:APPLICATION_COMMAND_HANDLER ID:1e ARG:097105000000ff061600 CB:00
2016.11.20 13:18:25 4: ZWDongle_Read ZWDongle_0: rcvd 0004001e029840 (request APPLICATION_COMMAND_HANDLER), sending ACK
2016.11.20 13:18:25 5: SW: 06
2016.11.20 13:18:25 5: ZWDongle_0 dispatch 0004001e029840
2016.11.20 13:18:25 4: CMD:APPLICATION_COMMAND_HANDLER ID:1e ARG:029840 CB:00
2016.11.20 13:18:25 5: ZWDongle_Write 00131e0a9880f75d20272dc6f55e250a (ee557686)
2016.11.20 13:18:25 5: SW: 011100131e0a9880f75d20272dc6f55e250a33
2016.11.20 13:18:25 5: ACK received, WaitForAck=>2 for 011100131e0a9880f75d20272dc6f55e250a33
2016.11.20 13:18:25 4: ZWDongle_Read ZWDongle_0: rcvd 011301 (answer ZW_SEND_DATA), sending ACK
2016.11.20 13:18:25 5: SW: 06
2016.11.20 13:18:25 5: ZWDongle_0 dispatch 011301
2016.11.20 13:18:25 4: ZWDongle_Read ZWDongle_0: rcvd 00130a000002 (request ZW_SEND_DATA), sending ACK
2016.11.20 13:18:25 5: SW: 06
2016.11.20 13:18:25 5: device ack reveived, removing 011100131e0a9880f75d20272dc6f55e250a33 from dongle sendstack
2016.11.20 13:18:25 5: ZWDongle_0 dispatch 00130a000002
2016.11.20 13:18:25 4: CMD:ZW_SEND_DATA ID:00 ARG:0002 CB:0a
2016.11.20 13:18:25 4: ZWDongle_0 transmit OK for CB 0a, target ZWave_SENSOR_NOTIFICATION_30
2016.11.20 13:18:25 4: ZWDongle_Read ZWDongle_0: rcvd 0004001e199881c0c9051ccbf46ea7ce5f3f7302b4f72cd90eb9c3076062 (request APPLICATION_COMMAND_HANDLER), sending ACK
2016.11.20 13:18:25 5: SW: 06
2016.11.20 13:18:25 5: ZWDongle_0 dispatch 0004001e199881c0c9051ccbf46ea7ce5f3f7302b4f72cd90eb9c3076062
2016.11.20 13:18:25 4: CMD:APPLICATION_COMMAND_HANDLER ID:1e ARG:199881c0c9051ccbf46ea7ce5f3f7302b4f72cd90eb9c3076062 CB:00
2016.11.20 13:18:25 4: CMD:APPLICATION_COMMAND_HANDLER ID:1e ARG:05310503012c CB:00
2016.11.20 13:18:25 4: ZWDongle_Read ZWDongle_0: rcvd 0004001e029840 (request APPLICATION_COMMAND_HANDLER), sending ACK
2016.11.20 13:18:25 5: SW: 06
2016.11.20 13:18:25 5: ZWDongle_0 dispatch 0004001e029840
2016.11.20 13:18:25 4: CMD:APPLICATION_COMMAND_HANDLER ID:1e ARG:029840 CB:00
2016.11.20 13:18:25 5: ZWDongle_Write 00131e0a9880c32cd3d5ec2cb185250b (ee557686)
2016.11.20 13:18:25 5: SW: 011100131e0a9880c32cd3d5ec2cb185250bc2
2016.11.20 13:18:25 5: ACK received, WaitForAck=>2 for 011100131e0a9880c32cd3d5ec2cb185250bc2
2016.11.20 13:18:25 4: ZWDongle_Read ZWDongle_0: rcvd 011301 (answer ZW_SEND_DATA), sending ACK
2016.11.20 13:18:25 5: SW: 06
2016.11.20 13:18:25 5: ZWDongle_0 dispatch 011301
2016.11.20 13:18:25 4: ZWDongle_Read ZWDongle_0: rcvd 00130b000002 (request ZW_SEND_DATA), sending ACK
2016.11.20 13:18:25 5: SW: 06
2016.11.20 13:18:25 5: device ack reveived, removing 011100131e0a9880c32cd3d5ec2cb185250bc2 from dongle sendstack
2016.11.20 13:18:25 5: ZWDongle_0 dispatch 00130b000002
2016.11.20 13:18:25 4: CMD:ZW_SEND_DATA ID:00 ARG:0002 CB:0b
2016.11.20 13:18:25 4: ZWDongle_0 transmit OK for CB 0b, target ZWave_SENSOR_NOTIFICATION_30
2016.11.20 13:18:25 4: ZWDongle_Read ZWDongle_0: rcvd 0004001e1a9881d33f571dfbb700dcb9a27fd317a30bc353c87d6a78592084 (request APPLICATION_COMMAND_HANDLER), sending ACK
2016.11.20 13:18:25 5: SW: 06
2016.11.20 13:18:25 5: ZWDongle_0 dispatch 0004001e1a9881d33f571dfbb700dcb9a27fd317a30bc353c87d6a78592084
2016.11.20 13:18:25 4: CMD:APPLICATION_COMMAND_HANDLER ID:1e ARG:1a9881d33f571dfbb700dcb9a27fd317a30bc353c87d6a78592084 CB:00
2016.11.20 13:18:25 4: CMD:APPLICATION_COMMAND_HANDLER ID:1e ARG:063105012200c8 CB:00
2016.11.20 13:18:25 4: ZWDongle_Read ZWDongle_0: rcvd 0004001e029840 (request APPLICATION_COMMAND_HANDLER), sending ACK
2016.11.20 13:18:25 5: SW: 06
2016.11.20 13:18:25 5: ZWDongle_0 dispatch 0004001e029840
2016.11.20 13:18:25 4: CMD:APPLICATION_COMMAND_HANDLER ID:1e ARG:029840 CB:00
2016.11.20 13:18:25 5: ZWDongle_Write 00131e0a988039fed309c359dd63250c (ee557686)
2016.11.20 13:18:25 5: SW: 011100131e0a988039fed309c359dd63250ce1
2016.11.20 13:18:25 5: ACK received, WaitForAck=>2 for 011100131e0a988039fed309c359dd63250ce1
2016.11.20 13:18:25 4: ZWDongle_Read ZWDongle_0: rcvd 011301 (answer ZW_SEND_DATA), sending ACK
2016.11.20 13:18:25 5: SW: 06
2016.11.20 13:18:25 5: ZWDongle_0 dispatch 011301
2016.11.20 13:18:25 4: ZWDongle_Read ZWDongle_0: rcvd 00130c000002 (request ZW_SEND_DATA), sending ACK
2016.11.20 13:18:25 5: SW: 06
2016.11.20 13:18:25 5: device ack reveived, removing 011100131e0a988039fed309c359dd63250ce1 from dongle sendstack
2016.11.20 13:18:25 5: ZWDongle_0 dispatch 00130c000002
2016.11.20 13:18:25 4: CMD:ZW_SEND_DATA ID:00 ARG:0002 CB:0c
2016.11.20 13:18:25 4: ZWDongle_0 transmit OK for CB 0c, target ZWave_SENSOR_NOTIFICATION_30
2016.11.20 13:18:25 4: ZWDongle_Read ZWDongle_0: rcvd 0004001e1798819a586213e2bef6458137e7a7399d12c373fc2aa401 (request APPLICATION_COMMAND_HANDLER), sending ACK
2016.11.20 13:18:25 5: SW: 06
2016.11.20 13:18:25 5: ZWDongle_0 dispatch 0004001e1798819a586213e2bef6458137e7a7399d12c373fc2aa401
2016.11.20 13:18:25 4: CMD:APPLICATION_COMMAND_HANDLER ID:1e ARG:1798819a586213e2bef6458137e7a7399d12c373fc2aa401 CB:00
2016.11.20 13:18:25 4: CMD:APPLICATION_COMMAND_HANDLER ID:1e ARG:03800364 CB:00
2016.11.20 13:18:25 4: ZWDongle_Read ZWDongle_0: rcvd 0004001e029840 (request APPLICATION_COMMAND_HANDLER), sending ACK
2016.11.20 13:18:25 5: SW: 06
2016.11.20 13:18:25 5: ZWDongle_0 dispatch 0004001e029840
2016.11.20 13:18:25 4: CMD:APPLICATION_COMMAND_HANDLER ID:1e ARG:029840 CB:00
2016.11.20 13:18:25 5: ZWDongle_Write 00131e0a9880746a83e68550f31f250d (ee557686)
2016.11.20 13:18:25 5: SW: 011100131e0a9880746a83e68550f31f250d9b
2016.11.20 13:18:25 5: ACK received, WaitForAck=>2 for 011100131e0a9880746a83e68550f31f250d9b
2016.11.20 13:18:25 4: ZWDongle_Read ZWDongle_0: rcvd 011301 (answer ZW_SEND_DATA), sending ACK
2016.11.20 13:18:25 5: SW: 06
2016.11.20 13:18:25 5: ZWDongle_0 dispatch 011301
2016.11.20 13:18:25 4: ZWDongle_Read ZWDongle_0: rcvd 00130d000002 (request ZW_SEND_DATA), sending ACK
2016.11.20 13:18:25 5: SW: 06
2016.11.20 13:18:25 5: device ack reveived, removing 011100131e0a9880746a83e68550f31f250d9b from dongle sendstack
2016.11.20 13:18:25 5: ZWDongle_0 dispatch 00130d000002
2016.11.20 13:18:25 4: CMD:ZW_SEND_DATA ID:00 ARG:0002 CB:0d
2016.11.20 13:18:25 4: ZWDongle_0 transmit OK for CB 0d, target ZWave_SENSOR_NOTIFICATION_30
2016.11.20 13:18:25 4: ZWDongle_Read ZWDongle_0: rcvd 0004001e1d98817350bc1becf86d882b17cbfbc2ce31fc9a86743a20409611b0cdcb (request APPLICATION_COMMAND_HANDLER), sending ACK
2016.11.20 13:18:25 5: SW: 06
2016.11.20 13:18:25 5: ZWDongle_0 dispatch 0004001e1d98817350bc1becf86d882b17cbfbc2ce31fc9a86743a20409611b0cdcb
2016.11.20 13:18:25 4: CMD:APPLICATION_COMMAND_HANDLER ID:1e ARG:1d98817350bc1becf86d882b17cbfbc2ce31fc9a86743a20409611b0cdcb CB:00
2016.11.20 13:18:25 4: CMD:APPLICATION_COMMAND_HANDLER ID:1e ARG:097105000000ff061700 CB:00
2016.11.20 13:18:25 4: ZWDongle_Read ZWDongle_0: rcvd 0004001e029840 (request APPLICATION_COMMAND_HANDLER), sending ACK
2016.11.20 13:18:25 5: SW: 06
2016.11.20 13:18:25 5: ZWDongle_0 dispatch 0004001e029840
2016.11.20 13:18:25 4: CMD:APPLICATION_COMMAND_HANDLER ID:1e ARG:029840 CB:00
2016.11.20 13:18:25 5: ZWDongle_Write 00131e0a98807ff570aee1a69829250e (ee557686)
2016.11.20 13:18:25 5: SW: 011100131e0a98807ff570aee1a69829250e78
2016.11.20 13:18:25 5: ACK received, WaitForAck=>2 for 011100131e0a98807ff570aee1a69829250e78
2016.11.20 13:18:25 4: ZWDongle_Read ZWDongle_0: rcvd 011301 (answer ZW_SEND_DATA), sending ACK
2016.11.20 13:18:25 5: SW: 06
2016.11.20 13:18:25 5: ZWDongle_0 dispatch 011301
2016.11.20 13:18:25 4: ZWDongle_Read ZWDongle_0: rcvd 00130e000002 (request ZW_SEND_DATA), sending ACK
2016.11.20 13:18:25 5: SW: 06
2016.11.20 13:18:25 5: device ack reveived, removing 011100131e0a98807ff570aee1a69829250e78 from dongle sendstack
2016.11.20 13:18:25 5: ZWDongle_0 dispatch 00130e000002
2016.11.20 13:18:25 4: CMD:ZW_SEND_DATA ID:00 ARG:0002 CB:0e
2016.11.20 13:18:25 4: ZWDongle_0 transmit OK for CB 0e, target ZWave_SENSOR_NOTIFICATION_30
2016.11.20 13:18:25 4: ZWDongle_Read ZWDongle_0: rcvd 0004001e199881de48082ffac472a761103e6248787fa5756a309e38fcce (request APPLICATION_COMMAND_HANDLER), sending ACK
2016.11.20 13:18:25 5: SW: 06
2016.11.20 13:18:25 5: ZWDongle_0 dispatch 0004001e199881de48082ffac472a761103e6248787fa5756a309e38fcce
2016.11.20 13:18:25 4: CMD:APPLICATION_COMMAND_HANDLER ID:1e ARG:199881de48082ffac472a761103e6248787fa5756a309e38fcce CB:00
2016.11.20 13:18:25 4: CMD:APPLICATION_COMMAND_HANDLER ID:1e ARG:05310503012c CB:00
2016.11.20 13:18:25 4: ZWDongle_Read ZWDongle_0: rcvd 0004001e029840 (request APPLICATION_COMMAND_HANDLER), sending ACK
2016.11.20 13:18:25 5: SW: 06
2016.11.20 13:18:25 5: ZWDongle_0 dispatch 0004001e029840
2016.11.20 13:18:25 4: CMD:APPLICATION_COMMAND_HANDLER ID:1e ARG:029840 CB:00
2016.11.20 13:18:25 5: ZWDongle_Write 00131e0a9880e0faf5dc4a7cc0fb250f (ee557686)
2016.11.20 13:18:25 5: SW: 011100131e0a9880e0faf5dc4a7cc0fb250fe5
2016.11.20 13:18:25 5: ACK received, WaitForAck=>2 for 011100131e0a9880e0faf5dc4a7cc0fb250fe5
2016.11.20 13:18:25 4: ZWDongle_Read ZWDongle_0: rcvd 011301 (answer ZW_SEND_DATA), sending ACK
2016.11.20 13:18:25 5: SW: 06
2016.11.20 13:18:25 5: ZWDongle_0 dispatch 011301
2016.11.20 13:18:25 4: ZWDongle_Read ZWDongle_0: rcvd 00130f000002 (request ZW_SEND_DATA), sending ACK
2016.11.20 13:18:25 5: SW: 06
2016.11.20 13:18:25 5: device ack reveived, removing 011100131e0a9880e0faf5dc4a7cc0fb250fe5 from dongle sendstack
2016.11.20 13:18:25 5: ZWDongle_0 dispatch 00130f000002
2016.11.20 13:18:25 4: CMD:ZW_SEND_DATA ID:00 ARG:0002 CB:0f
2016.11.20 13:18:25 4: ZWDongle_0 transmit OK for CB 0f, target ZWave_SENSOR_NOTIFICATION_30
2016.11.20 13:18:25 4: ZWDongle_Read ZWDongle_0: rcvd 0004001e1a98815712eba201ccff93e5c3ac12d1f2e1e02ddc927f18f5bcd1 (request APPLICATION_COMMAND_HANDLER), sending ACK
2016.11.20 13:18:25 5: SW: 06
2016.11.20 13:18:25 5: ZWDongle_0 dispatch 0004001e1a98815712eba201ccff93e5c3ac12d1f2e1e02ddc927f18f5bcd1
2016.11.20 13:18:25 4: CMD:APPLICATION_COMMAND_HANDLER ID:1e ARG:1a98815712eba201ccff93e5c3ac12d1f2e1e02ddc927f18f5bcd1 CB:00
2016.11.20 13:18:25 4: CMD:APPLICATION_COMMAND_HANDLER ID:1e ARG:063105012200c8 CB:00
2016.11.20 13:18:25 4: ZWDongle_Read ZWDongle_0: rcvd 0004001e029840 (request APPLICATION_COMMAND_HANDLER), sending ACK
2016.11.20 13:18:25 5: SW: 06
2016.11.20 13:18:25 5: ZWDongle_0 dispatch 0004001e029840
2016.11.20 13:18:25 4: CMD:APPLICATION_COMMAND_HANDLER ID:1e ARG:029840 CB:00
2016.11.20 13:18:25 5: ZWDongle_Write 00131e0a988000efcc29f7b5577a2510 (ee557686)
2016.11.20 13:18:25 5: SW: 011100131e0a988000efcc29f7b5577a2510a1
2016.11.20 13:18:25 5: ACK received, WaitForAck=>2 for 011100131e0a988000efcc29f7b5577a2510a1
2016.11.20 13:18:25 4: ZWDongle_Read ZWDongle_0: rcvd 011301 (answer ZW_SEND_DATA), sending ACK
2016.11.20 13:18:25 5: SW: 06
2016.11.20 13:18:25 5: ZWDongle_0 dispatch 011301
2016.11.20 13:18:25 4: ZWDongle_Read ZWDongle_0: rcvd 001310000002 (request ZW_SEND_DATA), sending ACK
2016.11.20 13:18:25 5: SW: 06
2016.11.20 13:18:25 5: device ack reveived, removing 011100131e0a988000efcc29f7b5577a2510a1 from dongle sendstack
2016.11.20 13:18:25 5: ZWDongle_0 dispatch 001310000002
2016.11.20 13:18:25 4: CMD:ZW_SEND_DATA ID:00 ARG:0002 CB:10
2016.11.20 13:18:25 4: ZWDongle_0 transmit OK for CB 10, target ZWave_SENSOR_NOTIFICATION_30
2016.11.20 13:18:32 3: ZWave_SENSOR_NOTIFICATION_30: secStart older than 6 seconds detected, secUnlock will call Zwave_secEnd

Ohne SECURITY hat der Sensor eigentlich nur ein Telegramm geschickt.
Es kann sein, daß die Bewegungs-Erkennung oben auch noch ein Telegramm ausgelöst hat, jedoch kommt mir die Menge an Funktelegrammen zuviel vor.

Die Meldung

Code Auswählen


2016.11.20 13:18:32 3: ZWave_SENSOR_NOTIFICATION_30: secStart older than 6 seconds detected, secUnlock will call Zwave_secEnd

sehe ich immer wieder.

Das hier kommt auch manchmal

Code Auswählen


2016.11.20 13:18:35 1: ZWave_SENSOR_NOTIFICATION_30: secDecrypt: Authentification code not verified, command 7abe14ad6c08 will be dropped!

Hmm?

Titel: Antw:UZB1 Stick: Lizenz schaltet AES Security frei?
Beitrag von: buspirat am 20 November 2016, 13:45:59

Nach einem Neustart + Device nochmal exkludiert und inkludiert scheint alles ok zu sein.
Es kommen auch keine Fehlermeldungen mehr.

Die Anzahl der Logmeldungen im SECURITY Modus sind fast 3x soviele wie im unverschlüsselten Modus. Schaut man sich die Logdatei live mit "tail -f " an, dann merkt man deutlich die erhöhte Latenz, die durch die aufwändigere Kommunikation entsteht.

Werde es jetzt erstmal so laufen lassen. Vielen Dank nochmal für die Hilfe!

Titel: Antw:UZB1 Stick: Lizenz schaltet AES Security frei?
Beitrag von: rudolfkoenig am 20 November 2016, 13:47:49

ZitatPERL WARNING: Use of uninitialized value $getSecMsg in split at ./FHEM/10_ZWave.pm line 3424.

Habs gefixt.

Titel: Antw:UZB1 Stick: Lizenz schaltet AES Security frei?
Beitrag von: buspirat am 20 November 2016, 14:20:41

Die sichere Kommunikation mit dem Philio PST02-A Sensor ist leider wieder abgesoffen:

Code Auswählen


2016.11.20 14:07:20 1: Sensor_Haustuere: secDecrypt: Authentification code not verified, command 163c64 will be dropped!
2016.11.20 14:07:20 1: Sensor_Haustuere: first frame of message (sequence 06) for decryption not found!
2016.11.20 14:07:20 1: Sensor_Haustuere: secDecrypt: Authentification code not verified, command c5b49fa55cc1b686a9 will be dropped!
2016.11.20 14:07:20 1: Sensor_Haustuere: first frame of message (sequence 05) for decryption not found!
2016.11.20 14:07:20 1: Sensor_Haustuere: secDecrypt: Authentification code not verified, command d80c8f0822 will be dropped!
2016.11.20 14:07:20 1: Sensor_Haustuere: secDecrypt: Authentification code not verified, command d8193bffb8f5 will be dropped!
2016.11.20 14:07:25 2: ZWDongle_0 transmit NO_ACK for CB 2e, target Sensor_Haustuere
2016.11.20 14:07:48 3: Sensor_Haustuere: secStart older than 6 seconds detected, secUnlock will call Zwave_secEnd
2016.11.20 14:07:57 3: Sensor_Haustuere: secStart older than 6 seconds detected, secUnlock will call Zwave_secEnd
2016.11.20 14:09:53 3: Sensor_Haustuere: secStart older than 6 seconds detected, secUnlock will call Zwave_secEnd
2016.11.20 14:10:51 3: Sensor_Haustuere: secStart older than 6 seconds detected, secUnlock will call Zwave_secEnd
2016.11.20 14:11:11 3: Sensor_Haustuere: secStart older than 6 seconds detected, secUnlock will call Zwave_secEnd
2016.11.20 14:11:19 3: Sensor_Haustuere: secStart older than 6 seconds detected, secUnlock will call Zwave_secEnd
2016.11.20 14:11:27 3: Sensor_Haustuere: secStart older than 6 seconds detected, secUnlock will call Zwave_secEnd
2016.11.20 14:11:35 3: Sensor_Haustuere: secStart older than 6 seconds detected, secUnlock will call Zwave_secEnd
2016.11.20 14:11:43 3: Sensor_Haustuere: secStart older than 6 seconds detected, secUnlock will call Zwave_secEnd
2016.11.20 14:11:51 3: Sensor_Haustuere: secStart older than 6 seconds detected, secUnlock will call Zwave_secEnd

*** leider hier erst das Verbose-Logging wieder auf 5 gestellt ***

2016.11.20 14:12:30 4: ZWDongle_Read ZWDongle_0: rcvd 00040020029840 (request APPLICATION_COMMAND_HANDLER), sending ACK
2016.11.20 14:12:30 5: SW: 06
2016.11.20 14:12:30 5: ZWDongle_0 dispatch 00040020029840
2016.11.20 14:12:30 4: CMD:APPLICATION_COMMAND_HANDLER ID:20 ARG:029840 CB:00
2016.11.20 14:12:37 3: Sensor_Haustuere: secStart older than 6 seconds detected, secUnlock will call Zwave_secEnd
2016.11.20 14:12:38 4: ZWDongle_Read ZWDongle_0: rcvd 00040020029840 (request APPLICATION_COMMAND_HANDLER), sending ACK
2016.11.20 14:12:38 5: SW: 06
2016.11.20 14:12:38 5: ZWDongle_0 dispatch 00040020029840
2016.11.20 14:12:38 4: CMD:APPLICATION_COMMAND_HANDLER ID:20 ARG:029840 CB:00
2016.11.20 14:12:45 3: Sensor_Haustuere: secStart older than 6 seconds detected, secUnlock will call Zwave_secEnd
2016.11.20 14:12:46 4: ZWDongle_Read ZWDongle_0: rcvd 00040020029840 (request APPLICATION_COMMAND_HANDLER), sending ACK
2016.11.20 14:12:46 5: SW: 06
2016.11.20 14:12:46 5: ZWDongle_0 dispatch 00040020029840
2016.11.20 14:12:46 4: CMD:APPLICATION_COMMAND_HANDLER ID:20 ARG:029840 CB:00
2016.11.20 14:12:53 3: Sensor_Haustuere: secStart older than 6 seconds detected, secUnlock will call Zwave_secEnd
2016.11.20 14:12:54 4: ZWDongle_Read ZWDongle_0: rcvd 00040020029840 (request APPLICATION_COMMAND_HANDLER), sending ACK
2016.11.20 14:12:54 5: SW: 06
2016.11.20 14:12:54 5: ZWDongle_0 dispatch 00040020029840
2016.11.20 14:12:54 4: CMD:APPLICATION_COMMAND_HANDLER ID:20 ARG:029840 CB:00
2016.11.20 14:12:54 4: ZWDongle_Read ZWDongle_0: rcvd 00040020029840 (request APPLICATION_COMMAND_HANDLER), sending ACK
2016.11.20 14:12:54 5: SW: 06
2016.11.20 14:12:54 5: ZWDongle_0 dispatch 00040020029840
2016.11.20 14:12:54 4: CMD:APPLICATION_COMMAND_HANDLER ID:20 ARG:029840 CB:00
2016.11.20 14:13:01 3: Sensor_Haustuere: secStart older than 6 seconds detected, secUnlock will call Zwave_secEnd
2016.11.20 14:13:02 4: ZWDongle_Read ZWDongle_0: rcvd 00040020029840 (request APPLICATION_COMMAND_HANDLER), sending ACK
2016.11.20 14:13:02 5: SW: 06
2016.11.20 14:13:02 5: ZWDongle_0 dispatch 00040020029840
2016.11.20 14:13:02 4: CMD:APPLICATION_COMMAND_HANDLER ID:20 ARG:029840 CB:00
2016.11.20 14:13:09 3: Sensor_Haustuere: secStart older than 6 seconds detected, secUnlock will call Zwave_secEnd
2016.11.20 14:13:10 4: ZWDongle_Read ZWDongle_0: rcvd 00040020029840 (request APPLICATION_COMMAND_HANDLER), sending ACK
2016.11.20 14:13:10 5: SW: 06
2016.11.20 14:13:10 5: ZWDongle_0 dispatch 00040020029840
2016.11.20 14:13:10 4: CMD:APPLICATION_COMMAND_HANDLER ID:20 ARG:029840 CB:00
2016.11.20 14:13:17 3: Sensor_Haustuere: secStart older than 6 seconds detected, secUnlock will call Zwave_secEnd
2016.11.20 14:14:38 4: ZWDongle_Read ZWDongle_0: rcvd 00040020029840 (request APPLICATION_COMMAND_HANDLER), sending ACK
2016.11.20 14:14:38 5: SW: 06
2016.11.20 14:14:38 5: ZWDongle_0 dispatch 00040020029840
2016.11.20 14:14:38 4: CMD:APPLICATION_COMMAND_HANDLER ID:20 ARG:029840 CB:00
2016.11.20 14:14:45 3: Sensor_Haustuere: secStart older than 6 seconds detected, secUnlock will call Zwave_secEnd
2016.11.20 14:16:25 4: ZWDongle_Read ZWDongle_0: rcvd 000400040a8f0101063105012200a5 (request APPLICATION_COMMAND_HANDLER), sending ACK
2016.11.20 14:16:25 5: SW: 06
2016.11.20 14:16:25 5: ZWDongle_0 dispatch 000400040a8f0101063105012200a5
2016.11.20 14:16:25 4: CMD:APPLICATION_COMMAND_HANDLER ID:04 ARG:0a8f0101063105012200a5 CB:00

die "secStart older than 6 seconds detected, secUnlock will call Zwave_secEnd" Meldung läuft in einer Schleife.

Erst nach einem FHEM Neustart funktioniert die Kommunikation wieder. Ich lasse jetzt das VERBOSE auf fünf gestellt.

Titel: Antw:UZB1 Stick: Lizenz schaltet AES Security frei?
Beitrag von: A.Harrenberg am 20 November 2016, 19:29:57

Hi,

irgendwas läuft da grundlegend aus dem Ruder...

Ich schaue mir das in den nächsten Tagen mal an. Ohne jetzt reingeschaut habe vermute ich das eine Nachricht verlorengeht und dann die Kommunikation aus dem Tritt kommt. Dachte eigentlich das dies nicht mehr so auftreten sollte...

Gruß,
Andreas.

Titel: Antw:UZB1 Stick: Lizenz schaltet AES Security frei?
Beitrag von: buspirat am 20 November 2016, 21:55:44

Zitat von: A.Harrenberg am 20 November 2016, 19:29:57
Ohne jetzt reingeschaut habe vermute ich das eine Nachricht verlorengeht und dann die Kommunikation aus dem Tritt kommt.

so sieht mir das auch aus, stets nach dem ersten "transmit NO_ACK" geht es schief und erholt sich nicht mehr.

Per Zufall habe ich mehrere Themen a la "Z-Wave SendStack" hier im Forum durchgelesen. Das Fehlerbild scheint recht ähnlich zu sein. Eigentlich wollte ich wissen, wie man die Anzeige des ausstehenden Sendstacks in der Weboberfläche aktiviert, daß hatte ich auf irgendwelchen Screenshots gesehen :D

Ich glaube ich kann das Problem provizieren: Die KFOB-C Fernbedienung ist auch mit SECURITY eingebunden. Drücke ich dort ein paar Tasten und löse anschließend den Bewegungsmelder aus, dann ging es bisher recht verlässlich schief. Als ob da irgendwie die Nachrichten der beiden SECURITY-Devices durcheinander kommen oder ähnliches.

Der Sensor ist jetzt erstmal wieder ohne SECURITY eingebunden, damit er überhaupt läuft.
Bei Bedarf kann ich gerne Debug-Code ausprobieren.

Titel: Antw:UZB1 Stick: Lizenz schaltet AES Security frei?
Beitrag von: A.Harrenberg am 21 November 2016, 08:07:13

Hi,

Zitat von: buspirat am 20 November 2016, 21:55:44
Eigentlich wollte ich wissen, wie man die Anzeige des ausstehenden Sendstacks in der Weboberfläche aktiviert, daß hatte ich auf irgendwelchen Screenshots gesehen :D

einfach ein "list" von dem Device machen, bei Dir also z.B. "list Sensor_Haustuere" ;)

Zitat von: buspirat am 20 November 2016, 21:55:44
Ich glaube ich kann das Problem provizieren: Die KFOB-C Fernbedienung ist auch mit SECURITY eingebunden. Drücke ich dort ein paar Tasten und löse anschließend den Bewegungsmelder aus, dann ging es bisher recht verlässlich schief. Als ob da irgendwie die Nachrichten der beiden SECURITY-Devices durcheinander kommen oder ähnliches.

Hast Du denn ein Logfile in dem sowas (mit Loglevel 5) "drin" ist? Dann müsste ich das mal durchackern und sehen an welcher Stelle oder welchen Bedingungen das schief läuft. Wenn das reproduzierbar passiert wenn Du beide Geräte quasi gleichzeitig nutzt ist das "interessant", da jedes Gerät eigentlich seinen eigenen Stack hat und daher unabhängig oder unbeeinflußt von anderen Geräten sein sollte.

Zitat von: buspirat am 20 November 2016, 21:55:44
Der Sensor ist jetzt erstmal wieder ohne SECURITY eingebunden, damit er überhaupt läuft.
Bei Bedarf kann ich gerne Debug-Code ausprobieren.

Falls Du ein Logfile zur Verfügung stellen kannst schaue ich mir das an, sollte dann noch Klärungsbedarf sein oder weitere Tests dann melde ich mich noch mal.

Gruß,
Andreas.

Titel: Antw:UZB1 Stick: Lizenz schaltet AES Security frei?
Beitrag von: buspirat am 21 November 2016, 23:39:35

Zitat von: A.Harrenberg am 21 November 2016, 08:07:13
Hast Du denn ein Logfile in dem sowas (mit Loglevel 5) "drin" ist? Dann müsste ich das mal durchackern und sehen an welcher Stelle oder welchen Bedingungen das schief läuft.

ich werde versuchen eine reduzierte Logdatei zu erstellen. Habe gerade testweise alle Funksender deaktiviert an die ich einfach ran kam, damit die Logdatei möglichst sauber ist.

Hier ein Log von einer Inklusion mit SECURITY:

Code Auswählen


2016.11.21 23:25:59 4: ZWDongle *** set ZWDongle_0 addNode onSec
2016.11.21 23:25:59 5: ZWDongle_Write 004a8103 ()
2016.11.21 23:25:59 5: SW: 0105004a810332
2016.11.21 23:25:59 5: ACK received, removing 0105004a810332 from dongle sendstack
2016.11.21 23:25:59 4: ZWDongle_Read ZWDongle_0: rcvd 004a03010000 (request ZW_ADD_NODE_TO_NETWORK), sending ACK
2016.11.21 23:25:59 5: SW: 06
2016.11.21 23:25:59 5: ZWDongle_0 dispatch 004a03010000
2016.11.21 23:25:59 4: CMD:ZW_ADD_NODE_TO_NETWORK ID:01 ARG:0000 CB:03
2016.11.21 23:25:59 4: ZWDongle_0 ZW_ADD_NODE_TO_NETWORK learnReady
2016.11.21 23:26:01 4: ZWDongle_Read ZWDongle_0: rcvd 004a03020000 (request ZW_ADD_NODE_TO_NETWORK), sending ACK
2016.11.21 23:26:01 5: SW: 06
2016.11.21 23:26:01 5: ZWDongle_0 dispatch 004a03020000
2016.11.21 23:26:01 4: CMD:ZW_ADD_NODE_TO_NETWORK ID:02 ARG:0000 CB:03
2016.11.21 23:26:01 4: ZWDongle_0 ZW_ADD_NODE_TO_NETWORK nodeFound
2016.11.21 23:26:01 4: ZWDongle_Read ZWDongle_0: rcvd 004a030322150407015e80718570728630318459735a8f987aef20 (request ZW_ADD_NODE_TO_NETWORK), sending ACK
2016.11.21 23:26:01 5: SW: 06
2016.11.21 23:26:01 5: ZWDongle_0 dispatch 004a030322150407015e80718570728630318459735a8f987aef20
2016.11.21 23:26:01 4: CMD:ZW_ADD_NODE_TO_NETWORK ID:03 ARG:22150407015e80718570728630318459735a8f987aef20 CB:03
2016.11.21 23:26:01 2: autocreate: define ZWave_SENSOR_NOTIFICATION_34 ZWave ee557686 34 5e80718570728630318459735a8f987aef20
2016.11.21 23:26:01 2: autocreate: define FileLog_ZWave_SENSOR_NOTIFICATION_34 FileLog ./log/ZWave_SENSOR_NOTIFICATION_34-%Y.log ZWave_SENSOR_NOTIFICATION_34
2016.11.21 23:26:02 4: ZWDongle_Read ZWDongle_0: rcvd 004a03052200 (request ZW_ADD_NODE_TO_NETWORK), sending ACK
2016.11.21 23:26:02 5: SW: 06
2016.11.21 23:26:02 5: ZWDongle_0 dispatch 004a03052200
2016.11.21 23:26:02 4: CMD:ZW_ADD_NODE_TO_NETWORK ID:05 ARG:2200 CB:03
2016.11.21 23:26:02 4: ZWDongle *** set ZWDongle_0 addNode off
2016.11.21 23:26:02 5: ZWDongle_Write 004a0504 ()
2016.11.21 23:26:02 5: SW: 0105004a0504b1
2016.11.21 23:26:02 2: ZWAVE Starting secure init for ZWave_SENSOR_NOTIFICATION_34
2016.11.21 23:26:02 5: ZWDongle_Write 001322039804002502 (ee557686)
2016.11.21 23:26:02 5: ACK received, removing 0105004a0504b1 from dongle sendstack
2016.11.21 23:26:02 5: SW: 010a0013220398040025027c
2016.11.21 23:26:02 5: ACK received, WaitForAck=>2 for 010a0013220398040025027c
2016.11.21 23:26:02 4: ZWDongle_Read ZWDongle_0: rcvd 011301 (answer ZW_SEND_DATA), sending ACK
2016.11.21 23:26:02 5: SW: 06
2016.11.21 23:26:02 5: ZWDongle_0 dispatch 011301
2016.11.21 23:26:02 4: ZWDongle_Read ZWDongle_0: rcvd 001302000003 (request ZW_SEND_DATA), sending ACK
2016.11.21 23:26:02 5: SW: 06
2016.11.21 23:26:02 5: device ack reveived, removing 010a0013220398040025027c from dongle sendstack
2016.11.21 23:26:02 5: ZWDongle_0 dispatch 001302000003
2016.11.21 23:26:02 4: CMD:ZW_SEND_DATA ID:00 ARG:0003 CB:02
2016.11.21 23:26:02 4: ZWDongle_0 transmit OK for CB 02, target ZWave_SENSOR_NOTIFICATION_34
2016.11.21 23:26:02 4: ZWDongle_Read ZWDongle_0: rcvd 004a04062200 (request ZW_ADD_NODE_TO_NETWORK), sending ACK
2016.11.21 23:26:02 5: SW: 06
2016.11.21 23:26:02 5: ZWDongle_0 dispatch 004a04062200
2016.11.21 23:26:02 4: CMD:ZW_ADD_NODE_TO_NETWORK ID:06 ARG:2200 CB:04
2016.11.21 23:26:02 4: ZWDongle_0 ZW_ADD_NODE_TO_NETWORK done
2016.11.21 23:26:04 4: ZWDongle_Read ZWDongle_0: rcvd 0004002203980500 (request APPLICATION_COMMAND_HANDLER), sending ACK
2016.11.21 23:26:04 5: SW: 06
2016.11.21 23:26:04 5: ZWDongle_0 dispatch 0004002203980500
2016.11.21 23:26:04 4: CMD:APPLICATION_COMMAND_HANDLER ID:22 ARG:03980500 CB:00
2016.11.21 23:26:04 5: ZWDongle_Write 0013220298402503 (ee557686)
2016.11.21 23:26:04 5: SW: 010900132202984025033b
2016.11.21 23:26:04 5: ACK received, WaitForAck=>2 for 010900132202984025033b
2016.11.21 23:26:04 4: ZWDongle_Read ZWDongle_0: rcvd 011301 (answer ZW_SEND_DATA), sending ACK
2016.11.21 23:26:04 5: SW: 06
2016.11.21 23:26:04 5: ZWDongle_0 dispatch 011301
2016.11.21 23:26:04 4: ZWDongle_Read ZWDongle_0: rcvd 001303000002 (request ZW_SEND_DATA), sending ACK
2016.11.21 23:26:04 5: SW: 06
2016.11.21 23:26:04 5: device ack reveived, removing 010900132202984025033b from dongle sendstack
2016.11.21 23:26:04 5: ZWDongle_0 dispatch 001303000002
2016.11.21 23:26:04 4: CMD:ZW_SEND_DATA ID:00 ARG:0002 CB:03
2016.11.21 23:26:04 4: ZWDongle_0 transmit OK for CB 03, target ZWave_SENSOR_NOTIFICATION_34
2016.11.21 23:26:04 4: ZWDongle_Read ZWDongle_0: rcvd 0004002203980500 (request APPLICATION_COMMAND_HANDLER), sending ACK
2016.11.21 23:26:04 5: SW: 06
2016.11.21 23:26:04 5: ZWDongle_0 dispatch 0004002203980500
2016.11.21 23:26:04 4: CMD:APPLICATION_COMMAND_HANDLER ID:22 ARG:03980500 CB:00
2016.11.21 23:26:04 4: ZWDongle_Read ZWDongle_0: rcvd 000400220a9880322b58661baa175e (request APPLICATION_COMMAND_HANDLER), sending ACK
2016.11.21 23:26:04 5: SW: 06
2016.11.21 23:26:04 5: ZWDongle_0 dispatch 000400220a9880322b58661baa175e
2016.11.21 23:26:04 4: CMD:APPLICATION_COMMAND_HANDLER ID:22 ARG:0a9880322b58661baa175e CB:00
2016.11.21 23:26:04 5: ZWDongle_Write 0013222698817a5990b3358a5f6697bd8d0afbefe1265bfab34c02eed72447fe6732d0281d966862a0fb2504 (ee557686)
2016.11.21 23:26:04 5: SW: 012d0013222698817a5990b3358a5f6697bd8d0afbefe1265bfab34c02eed72447fe6732d0281d966862a0fb25048a
2016.11.21 23:26:04 5: ACK received, WaitForAck=>2 for 012d0013222698817a5990b3358a5f6697bd8d0afbefe1265bfab34c02eed72447fe6732d0281d966862a0fb25048a
2016.11.21 23:26:04 4: ZWDongle_Read ZWDongle_0: rcvd 011301 (answer ZW_SEND_DATA), sending ACK
2016.11.21 23:26:04 5: SW: 06
2016.11.21 23:26:04 5: ZWDongle_0 dispatch 011301
2016.11.21 23:26:04 4: ZWDongle_Read ZWDongle_0: rcvd 001304000003 (request ZW_SEND_DATA), sending ACK
2016.11.21 23:26:04 5: SW: 06
2016.11.21 23:26:04 5: device ack reveived, removing 012d0013222698817a5990b3358a5f6697bd8d0afbefe1265bfab34c02eed72447fe6732d0281d966862a0fb25048a from dongle sendstack
2016.11.21 23:26:04 5: ZWDongle_0 dispatch 001304000003
2016.11.21 23:26:04 4: CMD:ZW_SEND_DATA ID:00 ARG:0003 CB:04
2016.11.21 23:26:04 4: ZWDongle_0 transmit OK for CB 04, target ZWave_SENSOR_NOTIFICATION_34
2016.11.21 23:26:04 4: ZWDongle_Read ZWDongle_0: rcvd 00040022029840 (request APPLICATION_COMMAND_HANDLER), sending ACK
2016.11.21 23:26:04 5: SW: 06
2016.11.21 23:26:04 5: ZWDongle_0 dispatch 00040022029840
2016.11.21 23:26:04 4: CMD:APPLICATION_COMMAND_HANDLER ID:22 ARG:029840 CB:00
2016.11.21 23:26:04 5: ZWDongle_Write 0013220a98809f8c26b4238c72a42505 (ee557686)
2016.11.21 23:26:04 5: SW: 01110013220a98809f8c26b4238c72a4250515
2016.11.21 23:26:04 5: ACK received, WaitForAck=>2 for 01110013220a98809f8c26b4238c72a4250515
2016.11.21 23:26:04 4: ZWDongle_Read ZWDongle_0: rcvd 011301 (answer ZW_SEND_DATA), sending ACK
2016.11.21 23:26:04 5: SW: 06
2016.11.21 23:26:04 5: ZWDongle_0 dispatch 011301
2016.11.21 23:26:04 4: ZWDongle_Read ZWDongle_0: rcvd 001305000003 (request ZW_SEND_DATA), sending ACK
2016.11.21 23:26:04 5: SW: 06
2016.11.21 23:26:04 5: device ack reveived, removing 01110013220a98809f8c26b4238c72a4250515 from dongle sendstack
2016.11.21 23:26:04 5: ZWDongle_0 dispatch 001305000003
2016.11.21 23:26:04 4: CMD:ZW_SEND_DATA ID:00 ARG:0003 CB:05
2016.11.21 23:26:04 4: ZWDongle_0 transmit OK for CB 05, target ZWave_SENSOR_NOTIFICATION_34
2016.11.21 23:26:04 4: ZWDongle_Read ZWDongle_0: rcvd 0004002216988193d3860044fba0669f2a569fbe161d896d15f31d (request APPLICATION_COMMAND_HANDLER), sending ACK
2016.11.21 23:26:04 5: SW: 06
2016.11.21 23:26:04 5: ZWDongle_0 dispatch 0004002216988193d3860044fba0669f2a569fbe161d896d15f31d
2016.11.21 23:26:04 4: CMD:APPLICATION_COMMAND_HANDLER ID:22 ARG:16988193d3860044fba0669f2a569fbe161d896d15f31d CB:00
2016.11.21 23:26:04 4: CMD:APPLICATION_COMMAND_HANDLER ID:22 ARG:029807 CB:00
2016.11.21 23:26:04 3: ZWave_SENSOR_NOTIFICATION_34: SECURITY enabled, networkkey was verified
2016.11.21 23:26:04 3: ZWave set ZWave_SENSOR_NOTIFICATION_34 secSupportedReport 
2016.11.21 23:26:04 5: ZWDongle_Write 0013220298402507 (ee557686)
2016.11.21 23:26:04 5: SW: 010900132202984025073f
2016.11.21 23:26:04 5: ACK received, WaitForAck=>2 for 010900132202984025073f
2016.11.21 23:26:04 4: ZWDongle_Read ZWDongle_0: rcvd 011301 (answer ZW_SEND_DATA), sending ACK
2016.11.21 23:26:04 5: SW: 06
2016.11.21 23:26:04 5: ZWDongle_0 dispatch 011301
2016.11.21 23:26:04 4: ZWDongle_Read ZWDongle_0: rcvd 001307000002 (request ZW_SEND_DATA), sending ACK
2016.11.21 23:26:04 5: SW: 06
2016.11.21 23:26:04 5: device ack reveived, removing 010900132202984025073f from dongle sendstack
2016.11.21 23:26:04 5: ZWDongle_0 dispatch 001307000002
2016.11.21 23:26:04 4: CMD:ZW_SEND_DATA ID:00 ARG:0002 CB:07
2016.11.21 23:26:04 4: ZWDongle_0 transmit OK for CB 07, target ZWave_SENSOR_NOTIFICATION_34
2016.11.21 23:26:04 4: ZWDongle_Read ZWDongle_0: rcvd 000400220a9880cc0b5c8503c2c47a (request APPLICATION_COMMAND_HANDLER), sending ACK
2016.11.21 23:26:04 5: SW: 06
2016.11.21 23:26:04 5: ZWDongle_0 dispatch 000400220a9880cc0b5c8503c2c47a
2016.11.21 23:26:04 4: CMD:APPLICATION_COMMAND_HANDLER ID:22 ARG:0a9880cc0b5c8503c2c47a CB:00
2016.11.21 23:26:04 5: ZWDongle_Write 001322169881de0390184d90437309357ccc1827cbc82dcea7582508 (ee557686)
2016.11.21 23:26:04 5: SW: 011d001322169881de0390184d90437309357ccc1827cbc82dcea7582508e5
2016.11.21 23:26:04 5: ACK received, WaitForAck=>2 for 011d001322169881de0390184d90437309357ccc1827cbc82dcea7582508e5
2016.11.21 23:26:04 4: ZWDongle_Read ZWDongle_0: rcvd 011301 (answer ZW_SEND_DATA), sending ACK
2016.11.21 23:26:04 5: SW: 06
2016.11.21 23:26:04 5: ZWDongle_0 dispatch 011301
2016.11.21 23:26:04 4: ZWDongle_Read ZWDongle_0: rcvd 001308000002 (request ZW_SEND_DATA), sending ACK
2016.11.21 23:26:04 5: SW: 06
2016.11.21 23:26:04 5: device ack reveived, removing 011d001322169881de0390184d90437309357ccc1827cbc82dcea7582508e5 from dongle sendstack
2016.11.21 23:26:04 5: ZWDongle_0 dispatch 001308000002
2016.11.21 23:26:04 4: CMD:ZW_SEND_DATA ID:00 ARG:0002 CB:08
2016.11.21 23:26:04 4: ZWDongle_0 transmit OK for CB 08, target ZWave_SENSOR_NOTIFICATION_34
2016.11.21 23:26:04 4: ZWDongle_Read ZWDongle_0: rcvd 00040022029840 (request APPLICATION_COMMAND_HANDLER), sending ACK
2016.11.21 23:26:04 5: SW: 06
2016.11.21 23:26:04 5: ZWDongle_0 dispatch 00040022029840
2016.11.21 23:26:04 4: CMD:APPLICATION_COMMAND_HANDLER ID:22 ARG:029840 CB:00
2016.11.21 23:26:04 5: ZWDongle_Write 0013220a98802f688ed1359d6f152509 (ee557686)
2016.11.21 23:26:04 5: SW: 01110013220a98802f688ed1359d6f1525092b
2016.11.21 23:26:04 5: ACK received, WaitForAck=>2 for 01110013220a98802f688ed1359d6f1525092b
2016.11.21 23:26:04 4: ZWDongle_Read ZWDongle_0: rcvd 011301 (answer ZW_SEND_DATA), sending ACK
2016.11.21 23:26:04 5: SW: 06
2016.11.21 23:26:04 5: ZWDongle_0 dispatch 011301
2016.11.21 23:26:04 4: ZWDongle_Read ZWDongle_0: rcvd 001309000003 (request ZW_SEND_DATA), sending ACK
2016.11.21 23:26:04 5: SW: 06
2016.11.21 23:26:04 5: device ack reveived, removing 01110013220a98802f688ed1359d6f1525092b from dongle sendstack
2016.11.21 23:26:04 5: ZWDongle_0 dispatch 001309000003
2016.11.21 23:26:04 4: CMD:ZW_SEND_DATA ID:00 ARG:0003 CB:09
2016.11.21 23:26:04 4: ZWDongle_0 transmit OK for CB 09, target ZWave_SENSOR_NOTIFICATION_34
2016.11.21 23:26:04 4: ZWDongle_Read ZWDongle_0: rcvd 000400221f98817f88f327dd37df553c07c93c9df78dcb2d21aea92fdd62c7d89550a640 (request APPLICATION_COMMAND_HANDLER), sending ACK
2016.11.21 23:26:04 5: SW: 06
2016.11.21 23:26:04 5: ZWDongle_0 dispatch 000400221f98817f88f327dd37df553c07c93c9df78dcb2d21aea92fdd62c7d89550a640
2016.11.21 23:26:04 4: CMD:APPLICATION_COMMAND_HANDLER ID:22 ARG:1f98817f88f327dd37df553c07c93c9df78dcb2d21aea92fdd62c7d89550a640 CB:00
2016.11.21 23:26:04 4: CMD:APPLICATION_COMMAND_HANDLER ID:22 ARG:0b98030080718570303184ef CB:00
2016.11.21 23:26:04 1: ZWAVE INIT: get ZWave_SENSOR_NOTIFICATION_34 versionClassAll: Secure operation in progress, executing in background
2016.11.21 23:26:04 1: ZWAVE INIT: get ZWave_SENSOR_NOTIFICATION_34 model: Secure operation in progress, executing in background
2016.11.21 23:26:04 3: ZWave get ZWave_SENSOR_NOTIFICATION_34 versionClass ALARM
2016.11.21 23:26:04 5: ZWDongle_Write 00132203861371250a (ee557686)
2016.11.21 23:26:04 5: SW: 010a00132203861371250a0c
2016.11.21 23:26:04 3: ZWave get ZWave_SENSOR_NOTIFICATION_34 versionClass ASSOCIATION
2016.11.21 23:26:04 3: ZWave get ZWave_SENSOR_NOTIFICATION_34 versionClass ASSOCIATION_GRP_INFO
2016.11.21 23:26:04 3: ZWave get ZWave_SENSOR_NOTIFICATION_34 versionClass BASIC
2016.11.21 23:26:04 3: ZWave get ZWave_SENSOR_NOTIFICATION_34 versionClass BATTERY
2016.11.21 23:26:04 3: ZWave get ZWave_SENSOR_NOTIFICATION_34 versionClass CONFIGURATION
2016.11.21 23:26:04 3: ZWave get ZWave_SENSOR_NOTIFICATION_34 versionClass DEVICE_RESET_LOCALLY
2016.11.21 23:26:04 3: ZWave get ZWave_SENSOR_NOTIFICATION_34 versionClass FIRMWARE_UPDATE_MD
2016.11.21 23:26:04 3: ZWave get ZWave_SENSOR_NOTIFICATION_34 versionClass MANUFACTURER_SPECIFIC
2016.11.21 23:26:04 3: ZWave get ZWave_SENSOR_NOTIFICATION_34 versionClass MULTI_CMD
2016.11.21 23:26:04 3: ZWave get ZWave_SENSOR_NOTIFICATION_34 versionClass POWERLEVEL
2016.11.21 23:26:04 3: ZWave get ZWave_SENSOR_NOTIFICATION_34 versionClass SECURITY
2016.11.21 23:26:04 3: ZWave get ZWave_SENSOR_NOTIFICATION_34 versionClass SENSOR_BINARY
2016.11.21 23:26:04 3: ZWave get ZWave_SENSOR_NOTIFICATION_34 versionClass SENSOR_MULTILEVEL
2016.11.21 23:26:04 3: ZWave get ZWave_SENSOR_NOTIFICATION_34 versionClass VERSION
2016.11.21 23:26:04 3: ZWave get ZWave_SENSOR_NOTIFICATION_34 versionClass WAKE_UP
2016.11.21 23:26:04 3: ZWave get ZWave_SENSOR_NOTIFICATION_34 versionClass ZWAVEPLUS_INFO
2016.11.21 23:26:04 3: ZWave set ZWave_SENSOR_NOTIFICATION_34 associationAdd 1 1
2016.11.21 23:26:04 5: ZWDongle_Write 00132203861385250b (ee557686)
2016.11.21 23:26:04 5: ACK received, WaitForAck=>2 for 010a00132203861371250a0c
2016.11.21 23:26:04 4: ZWDongle_Read ZWDongle_0: rcvd 011301 (answer ZW_SEND_DATA), sending ACK
2016.11.21 23:26:04 5: SW: 06
2016.11.21 23:26:04 5: ZWDongle_0 dispatch 011301
2016.11.21 23:26:04 4: ZWDongle_Read ZWDongle_0: rcvd 00130a000002 (request ZW_SEND_DATA), sending ACK
2016.11.21 23:26:04 5: SW: 06
2016.11.21 23:26:04 5: device ack reveived, removing 010a00132203861371250a0c from dongle sendstack
2016.11.21 23:26:04 5: ZWDongle_0 dispatch 00130a000002
2016.11.21 23:26:04 4: CMD:ZW_SEND_DATA ID:00 ARG:0002 CB:0a
2016.11.21 23:26:04 4: ZWDongle_0 transmit OK for CB 0a, target ZWave_SENSOR_NOTIFICATION_34
2016.11.21 23:26:04 5: SW: 010a00132203861385250bf9
2016.11.21 23:26:04 4: ZWDongle_Read ZWDongle_0: rcvd 000400220486147104 (request APPLICATION_COMMAND_HANDLER), sending ACK
2016.11.21 23:26:04 5: SW: 06
2016.11.21 23:26:04 5: ZWDongle_0 dispatch 000400220486147104
2016.11.21 23:26:04 4: CMD:APPLICATION_COMMAND_HANDLER ID:22 ARG:0486147104 CB:00
2016.11.21 23:26:04 5: ZWDongle_Write 00132203861359250c (ee557686)
2016.11.21 23:26:04 4: ZWDongle_Read ZWDongle_0: CAN received
2016.11.21 23:26:05 2: ZWDongle_ProcessSendStack: no ACK, resending message 010a00132203861385250bf9
2016.11.21 23:26:05 5: SW: 010a00132203861385250bf9
2016.11.21 23:26:05 5: ACK received, WaitForAck=>2 for 010a00132203861385250bf9
2016.11.21 23:26:05 4: ZWDongle_Read ZWDongle_0: rcvd 011301 (answer ZW_SEND_DATA), sending ACK
2016.11.21 23:26:05 5: SW: 06
2016.11.21 23:26:05 5: ZWDongle_0 dispatch 011301
2016.11.21 23:26:05 4: ZWDongle_Read ZWDongle_0: rcvd 00130b000002 (request ZW_SEND_DATA), sending ACK
2016.11.21 23:26:05 5: SW: 06
2016.11.21 23:26:05 5: device ack reveived, removing 010a00132203861385250bf9 from dongle sendstack
2016.11.21 23:26:05 5: ZWDongle_0 dispatch 00130b000002
2016.11.21 23:26:05 4: CMD:ZW_SEND_DATA ID:00 ARG:0002 CB:0b
2016.11.21 23:26:05 4: ZWDongle_0 transmit OK for CB 0b, target ZWave_SENSOR_NOTIFICATION_34
2016.11.21 23:26:05 5: SW: 010a00132203861359250c22
2016.11.21 23:26:05 4: ZWDongle_Read ZWDongle_0: rcvd 000400220486148502 (request APPLICATION_COMMAND_HANDLER), sending ACK
2016.11.21 23:26:05 5: SW: 06
2016.11.21 23:26:05 5: ZWDongle_0 dispatch 000400220486148502
2016.11.21 23:26:05 4: CMD:APPLICATION_COMMAND_HANDLER ID:22 ARG:0486148502 CB:00
2016.11.21 23:26:05 5: ZWDongle_Write 00132203861320250d (ee557686)
2016.11.21 23:26:05 4: ZWDongle_Read ZWDongle_0: CAN received
2016.11.21 23:26:06 2: ZWDongle_ProcessSendStack: no ACK, resending message 010a00132203861359250c22
2016.11.21 23:26:06 5: SW: 010a00132203861359250c22
2016.11.21 23:26:06 5: ACK received, WaitForAck=>2 for 010a00132203861359250c22
2016.11.21 23:26:06 4: ZWDongle_Read ZWDongle_0: rcvd 011301 (answer ZW_SEND_DATA), sending ACK
2016.11.21 23:26:06 5: SW: 06
2016.11.21 23:26:06 5: ZWDongle_0 dispatch 011301
2016.11.21 23:26:06 4: ZWDongle_Read ZWDongle_0: rcvd 00130c000002 (request ZW_SEND_DATA), sending ACK
2016.11.21 23:26:06 5: SW: 06
2016.11.21 23:26:06 5: device ack reveived, removing 010a00132203861359250c22 from dongle sendstack
2016.11.21 23:26:06 5: ZWDongle_0 dispatch 00130c000002
2016.11.21 23:26:06 4: CMD:ZW_SEND_DATA ID:00 ARG:0002 CB:0c
2016.11.21 23:26:06 4: ZWDongle_0 transmit OK for CB 0c, target ZWave_SENSOR_NOTIFICATION_34
2016.11.21 23:26:06 5: SW: 010a00132203861320250d5a
2016.11.21 23:26:06 4: ZWDongle_Read ZWDongle_0: rcvd 000400220486145901 (request APPLICATION_COMMAND_HANDLER), sending ACK
2016.11.21 23:26:06 5: SW: 06
2016.11.21 23:26:06 5: ZWDongle_0 dispatch 000400220486145901
2016.11.21 23:26:06 4: CMD:APPLICATION_COMMAND_HANDLER ID:22 ARG:0486145901 CB:00
2016.11.21 23:26:06 5: ZWDongle_Write 00132203861380250e (ee557686)
2016.11.21 23:26:06 4: ZWDongle_Read ZWDongle_0: CAN received
2016.11.21 23:26:07 2: ZWDongle_ProcessSendStack: no ACK, resending message 010a00132203861320250d5a
2016.11.21 23:26:07 5: SW: 010a00132203861320250d5a
2016.11.21 23:26:07 5: ACK received, WaitForAck=>2 for 010a00132203861320250d5a
2016.11.21 23:26:07 4: ZWDongle_Read ZWDongle_0: rcvd 011301 (answer ZW_SEND_DATA), sending ACK
2016.11.21 23:26:07 5: SW: 06
2016.11.21 23:26:07 5: ZWDongle_0 dispatch 011301
2016.11.21 23:26:07 4: ZWDongle_Read ZWDongle_0: rcvd 00130d000002 (request ZW_SEND_DATA), sending ACK
2016.11.21 23:26:07 5: SW: 06
2016.11.21 23:26:07 5: device ack reveived, removing 010a00132203861320250d5a from dongle sendstack
2016.11.21 23:26:07 5: ZWDongle_0 dispatch 00130d000002
2016.11.21 23:26:07 4: CMD:ZW_SEND_DATA ID:00 ARG:0002 CB:0d
2016.11.21 23:26:07 4: ZWDongle_0 transmit OK for CB 0d, target ZWave_SENSOR_NOTIFICATION_34
2016.11.21 23:26:07 5: SW: 010a00132203861380250ef9
2016.11.21 23:26:07 4: ZWDongle_Read ZWDongle_0: rcvd 000400220486142000 (request APPLICATION_COMMAND_HANDLER), sending ACK
2016.11.21 23:26:07 5: SW: 06
2016.11.21 23:26:07 5: ZWDongle_0 dispatch 000400220486142000
2016.11.21 23:26:07 4: CMD:APPLICATION_COMMAND_HANDLER ID:22 ARG:0486142000 CB:00
2016.11.21 23:26:07 5: ZWDongle_Write 00132203861370250f (ee557686)
2016.11.21 23:26:07 4: ZWDongle_Read ZWDongle_0: CAN received
2016.11.21 23:26:08 2: ZWDongle_ProcessSendStack: no ACK, resending message 010a00132203861380250ef9
2016.11.21 23:26:08 5: SW: 010a00132203861380250ef9
2016.11.21 23:26:08 5: ACK received, WaitForAck=>2 for 010a00132203861380250ef9
2016.11.21 23:26:08 4: ZWDongle_Read ZWDongle_0: rcvd 011301 (answer ZW_SEND_DATA), sending ACK
2016.11.21 23:26:08 5: SW: 06
2016.11.21 23:26:08 5: ZWDongle_0 dispatch 011301
2016.11.21 23:26:08 4: ZWDongle_Read ZWDongle_0: rcvd 00130e000002 (request ZW_SEND_DATA), sending ACK
2016.11.21 23:26:08 5: SW: 06
2016.11.21 23:26:08 5: device ack reveived, removing 010a00132203861380250ef9 from dongle sendstack
2016.11.21 23:26:08 5: ZWDongle_0 dispatch 00130e000002
2016.11.21 23:26:08 4: CMD:ZW_SEND_DATA ID:00 ARG:0002 CB:0e
2016.11.21 23:26:08 4: ZWDongle_0 transmit OK for CB 0e, target ZWave_SENSOR_NOTIFICATION_34
2016.11.21 23:26:08 5: SW: 010a00132203861370250f08
2016.11.21 23:26:08 4: ZWDongle_Read ZWDongle_0: rcvd 000400220486148001 (request APPLICATION_COMMAND_HANDLER), sending ACK
2016.11.21 23:26:08 5: SW: 06
2016.11.21 23:26:08 5: ZWDongle_0 dispatch 000400220486148001
2016.11.21 23:26:08 4: CMD:APPLICATION_COMMAND_HANDLER ID:22 ARG:0486148001 CB:00
2016.11.21 23:26:08 5: ZWDongle_Write 0013220386135a2510 (ee557686)
2016.11.21 23:26:08 4: ZWDongle_Read ZWDongle_0: CAN received
2016.11.21 23:26:09 2: ZWDongle_ProcessSendStack: no ACK, resending message 010a00132203861370250f08
2016.11.21 23:26:09 5: SW: 010a00132203861370250f08
2016.11.21 23:26:09 5: ACK received, WaitForAck=>2 for 010a00132203861370250f08
2016.11.21 23:26:09 4: ZWDongle_Read ZWDongle_0: rcvd 011301 (answer ZW_SEND_DATA), sending ACK
2016.11.21 23:26:09 5: SW: 06
2016.11.21 23:26:09 5: ZWDongle_0 dispatch 011301
2016.11.21 23:26:09 4: ZWDongle_Read ZWDongle_0: rcvd 00130f000002 (request ZW_SEND_DATA), sending ACK
2016.11.21 23:26:09 5: SW: 06
2016.11.21 23:26:09 5: device ack reveived, removing 010a00132203861370250f08 from dongle sendstack
2016.11.21 23:26:09 5: ZWDongle_0 dispatch 00130f000002
2016.11.21 23:26:09 4: CMD:ZW_SEND_DATA ID:00 ARG:0002 CB:0f
2016.11.21 23:26:09 4: ZWDongle_0 transmit OK for CB 0f, target ZWave_SENSOR_NOTIFICATION_34
2016.11.21 23:26:09 5: SW: 010a0013220386135a25103d
2016.11.21 23:26:09 4: ZWDongle_Read ZWDongle_0: rcvd 000400220486147001 (request APPLICATION_COMMAND_HANDLER), sending ACK
2016.11.21 23:26:09 5: SW: 06
2016.11.21 23:26:09 5: ZWDongle_0 dispatch 000400220486147001
2016.11.21 23:26:09 4: CMD:APPLICATION_COMMAND_HANDLER ID:22 ARG:0486147001 CB:00
2016.11.21 23:26:09 5: ZWDongle_Write 0013220386137a2511 (ee557686)
2016.11.21 23:26:09 4: ZWDongle_Read ZWDongle_0: CAN received
2016.11.21 23:26:10 2: ZWDongle_ProcessSendStack: no ACK, resending message 010a0013220386135a25103d
2016.11.21 23:26:10 5: SW: 010a0013220386135a25103d
2016.11.21 23:26:10 5: ACK received, WaitForAck=>2 for 010a0013220386135a25103d
2016.11.21 23:26:10 4: ZWDongle_Read ZWDongle_0: rcvd 011301 (answer ZW_SEND_DATA), sending ACK
2016.11.21 23:26:10 5: SW: 06
2016.11.21 23:26:10 5: ZWDongle_0 dispatch 011301
2016.11.21 23:26:10 4: ZWDongle_Read ZWDongle_0: rcvd 001310000002 (request ZW_SEND_DATA), sending ACK
2016.11.21 23:26:10 5: SW: 06
2016.11.21 23:26:10 5: device ack reveived, removing 010a0013220386135a25103d from dongle sendstack
2016.11.21 23:26:10 5: ZWDongle_0 dispatch 001310000002
2016.11.21 23:26:10 4: CMD:ZW_SEND_DATA ID:00 ARG:0002 CB:10
2016.11.21 23:26:10 4: ZWDongle_0 transmit OK for CB 10, target ZWave_SENSOR_NOTIFICATION_34
2016.11.21 23:26:10 5: SW: 010a0013220386137a25111c
2016.11.21 23:26:10 4: ZWDongle_Read ZWDongle_0: rcvd 000400220486145a01 (request APPLICATION_COMMAND_HANDLER), sending ACK
2016.11.21 23:26:10 5: SW: 06
2016.11.21 23:26:10 5: ZWDongle_0 dispatch 000400220486145a01
2016.11.21 23:26:10 4: CMD:APPLICATION_COMMAND_HANDLER ID:22 ARG:0486145a01 CB:00
2016.11.21 23:26:10 5: ZWDongle_Write 001322038613722512 (ee557686)
2016.11.21 23:26:10 4: ZWDongle_Read ZWDongle_0: CAN received
2016.11.21 23:26:11 3: ZWave_SENSOR_NOTIFICATION_34: secStart older than 6 seconds detected, secUnlock will call Zwave_secEnd
2016.11.21 23:26:11 3: ZWave set ZWave_SENSOR_NOTIFICATION_34 wakeupInterval 86400 1
2016.11.21 23:26:11 2: ZWDongle_ProcessSendStack: no ACK, resending message 010a0013220386137a25111c
2016.11.21 23:26:11 5: SW: 010a0013220386137a25111c
2016.11.21 23:26:11 5: ACK received, WaitForAck=>2 for 010a0013220386137a25111c
2016.11.21 23:26:11 4: ZWDongle_Read ZWDongle_0: rcvd 011301 (answer ZW_SEND_DATA), sending ACK
2016.11.21 23:26:11 5: SW: 06
2016.11.21 23:26:11 5: ZWDongle_0 dispatch 011301
2016.11.21 23:26:11 4: ZWDongle_Read ZWDongle_0: rcvd 001311000002 (request ZW_SEND_DATA), sending ACK
2016.11.21 23:26:11 5: SW: 06
2016.11.21 23:26:11 5: device ack reveived, removing 010a0013220386137a25111c from dongle sendstack
2016.11.21 23:26:11 5: ZWDongle_0 dispatch 001311000002
2016.11.21 23:26:11 4: CMD:ZW_SEND_DATA ID:00 ARG:0002 CB:11
2016.11.21 23:26:11 4: ZWDongle_0 transmit OK for CB 11, target ZWave_SENSOR_NOTIFICATION_34
2016.11.21 23:26:11 5: SW: 010a00132203861372251217
2016.11.21 23:26:11 4: ZWDongle_Read ZWDongle_0: rcvd 000400220486147a02 (request APPLICATION_COMMAND_HANDLER), sending ACK
2016.11.21 23:26:11 5: SW: 06
2016.11.21 23:26:11 5: ZWDongle_0 dispatch 000400220486147a02
2016.11.21 23:26:11 4: CMD:APPLICATION_COMMAND_HANDLER ID:22 ARG:0486147a02 CB:00
2016.11.21 23:26:11 5: ZWDongle_Write 0013220386138f2513 (ee557686)
2016.11.21 23:26:11 4: ZWDongle_Read ZWDongle_0: CAN received
2016.11.21 23:26:12 2: ZWDongle_ProcessSendStack: no ACK, resending message 010a00132203861372251217
2016.11.21 23:26:12 5: SW: 010a00132203861372251217
2016.11.21 23:26:12 5: ACK received, WaitForAck=>2 for 010a00132203861372251217
2016.11.21 23:26:12 4: ZWDongle_Read ZWDongle_0: rcvd 011301 (answer ZW_SEND_DATA), sending ACK
2016.11.21 23:26:12 5: SW: 06
2016.11.21 23:26:12 5: ZWDongle_0 dispatch 011301
2016.11.21 23:26:12 4: ZWDongle_Read ZWDongle_0: rcvd 001312000003 (request ZW_SEND_DATA), sending ACK
2016.11.21 23:26:12 5: SW: 06
2016.11.21 23:26:12 5: device ack reveived, removing 010a00132203861372251217 from dongle sendstack
2016.11.21 23:26:12 5: ZWDongle_0 dispatch 001312000003
2016.11.21 23:26:12 4: CMD:ZW_SEND_DATA ID:00 ARG:0003 CB:12
2016.11.21 23:26:12 4: ZWDongle_0 transmit OK for CB 12, target ZWave_SENSOR_NOTIFICATION_34
2016.11.21 23:26:12 5: SW: 010a0013220386138f2513eb
2016.11.21 23:26:12 4: ZWDongle_Read ZWDongle_0: rcvd 000400220486147202 (request APPLICATION_COMMAND_HANDLER), sending ACK
2016.11.21 23:26:12 5: SW: 06
2016.11.21 23:26:12 5: ZWDongle_0 dispatch 000400220486147202
2016.11.21 23:26:12 4: CMD:APPLICATION_COMMAND_HANDLER ID:22 ARG:0486147202 CB:00
2016.11.21 23:26:12 5: ZWDongle_Write 001322038613732514 (ee557686)
2016.11.21 23:26:12 4: ZWDongle_Read ZWDongle_0: CAN received
2016.11.21 23:26:13 2: ZWDongle_ProcessSendStack: no ACK, resending message 010a0013220386138f2513eb
2016.11.21 23:26:13 5: SW: 010a0013220386138f2513eb
2016.11.21 23:26:13 5: ACK received, WaitForAck=>2 for 010a0013220386138f2513eb
2016.11.21 23:26:13 4: ZWDongle_Read ZWDongle_0: rcvd 011301 (answer ZW_SEND_DATA), sending ACK
2016.11.21 23:26:13 5: SW: 06
2016.11.21 23:26:13 5: ZWDongle_0 dispatch 011301
2016.11.21 23:26:13 4: ZWDongle_Read ZWDongle_0: rcvd 001313000002 (request ZW_SEND_DATA), sending ACK
2016.11.21 23:26:13 5: SW: 06
2016.11.21 23:26:13 5: device ack reveived, removing 010a0013220386138f2513eb from dongle sendstack
2016.11.21 23:26:13 5: ZWDongle_0 dispatch 001313000002
2016.11.21 23:26:13 4: CMD:ZW_SEND_DATA ID:00 ARG:0002 CB:13
2016.11.21 23:26:13 4: ZWDongle_0 transmit OK for CB 13, target ZWave_SENSOR_NOTIFICATION_34
2016.11.21 23:26:13 5: SW: 010a00132203861373251410
2016.11.21 23:26:13 4: ZWDongle_Read ZWDongle_0: rcvd 000400220486148f01 (request APPLICATION_COMMAND_HANDLER), sending ACK
2016.11.21 23:26:13 5: SW: 06
2016.11.21 23:26:13 5: ZWDongle_0 dispatch 000400220486148f01
2016.11.21 23:26:13 4: CMD:APPLICATION_COMMAND_HANDLER ID:22 ARG:0486148f01 CB:00
2016.11.21 23:26:13 5: ZWDongle_Write 001322038613982515 (ee557686)
2016.11.21 23:26:13 4: ZWDongle_Read ZWDongle_0: CAN received
2016.11.21 23:26:14 2: ZWDongle_ProcessSendStack: no ACK, resending message 010a00132203861373251410
2016.11.21 23:26:14 5: SW: 010a00132203861373251410
2016.11.21 23:26:14 5: ACK received, WaitForAck=>2 for 010a00132203861373251410
2016.11.21 23:26:14 4: ZWDongle_Read ZWDongle_0: rcvd 011301 (answer ZW_SEND_DATA), sending ACK
2016.11.21 23:26:14 5: SW: 06
2016.11.21 23:26:14 5: ZWDongle_0 dispatch 011301
2016.11.21 23:26:14 4: ZWDongle_Read ZWDongle_0: rcvd 001314000002 (request ZW_SEND_DATA), sending ACK
2016.11.21 23:26:14 5: SW: 06
2016.11.21 23:26:14 5: device ack reveived, removing 010a00132203861373251410 from dongle sendstack
2016.11.21 23:26:14 5: ZWDongle_0 dispatch 001314000002
2016.11.21 23:26:14 4: CMD:ZW_SEND_DATA ID:00 ARG:0002 CB:14
2016.11.21 23:26:14 4: ZWDongle_0 transmit OK for CB 14, target ZWave_SENSOR_NOTIFICATION_34
2016.11.21 23:26:14 5: SW: 010a001322038613982515fa
2016.11.21 23:26:14 4: ZWDongle_Read ZWDongle_0: rcvd 000400220486147301 (request APPLICATION_COMMAND_HANDLER), sending ACK
2016.11.21 23:26:14 5: SW: 06
2016.11.21 23:26:14 5: ZWDongle_0 dispatch 000400220486147301
2016.11.21 23:26:14 4: CMD:APPLICATION_COMMAND_HANDLER ID:22 ARG:0486147301 CB:00
2016.11.21 23:26:14 5: ZWDongle_Write 001322038613302516 (ee557686)
2016.11.21 23:26:14 4: ZWDongle_Read ZWDongle_0: CAN received
2016.11.21 23:26:15 2: ZWDongle_ProcessSendStack: no ACK, resending message 010a001322038613982515fa
2016.11.21 23:26:15 5: SW: 010a001322038613982515fa
2016.11.21 23:26:15 5: ACK received, WaitForAck=>2 for 010a001322038613982515fa
2016.11.21 23:26:15 4: ZWDongle_Read ZWDongle_0: rcvd 011301 (answer ZW_SEND_DATA), sending ACK
2016.11.21 23:26:15 5: SW: 06
2016.11.21 23:26:15 5: ZWDongle_0 dispatch 011301
2016.11.21 23:26:15 4: ZWDongle_Read ZWDongle_0: rcvd 001315000003 (request ZW_SEND_DATA), sending ACK
2016.11.21 23:26:16 5: SW: 06
2016.11.21 23:26:16 5: device ack reveived, removing 010a001322038613982515fa from dongle sendstack
2016.11.21 23:26:16 5: ZWDongle_0 dispatch 001315000003
2016.11.21 23:26:16 4: CMD:ZW_SEND_DATA ID:00 ARG:0003 CB:15
2016.11.21 23:26:16 4: ZWDongle_0 transmit OK for CB 15, target ZWave_SENSOR_NOTIFICATION_34
2016.11.21 23:26:16 5: SW: 010a00132203861330251651
2016.11.21 23:26:16 4: ZWDongle_Read ZWDongle_0: rcvd 000400220486149801 (request APPLICATION_COMMAND_HANDLER), sending ACK
2016.11.21 23:26:16 5: SW: 06
2016.11.21 23:26:16 5: ZWDongle_0 dispatch 000400220486149801
2016.11.21 23:26:16 4: CMD:APPLICATION_COMMAND_HANDLER ID:22 ARG:0486149801 CB:00
2016.11.21 23:26:16 5: ZWDongle_Write 001322038613312517 (ee557686)
2016.11.21 23:26:16 4: ZWDongle_Read ZWDongle_0: CAN received
2016.11.21 23:26:17 2: ZWDongle_ProcessSendStack: no ACK, resending message 010a00132203861330251651
2016.11.21 23:26:17 5: SW: 010a00132203861330251651
2016.11.21 23:26:17 5: ACK received, WaitForAck=>2 for 010a00132203861330251651
2016.11.21 23:26:17 4: ZWDongle_Read ZWDongle_0: rcvd 011301 (answer ZW_SEND_DATA), sending ACK
2016.11.21 23:26:17 5: SW: 06
2016.11.21 23:26:17 5: ZWDongle_0 dispatch 011301
2016.11.21 23:26:17 4: ZWDongle_Read ZWDongle_0: rcvd 001316000002 (request ZW_SEND_DATA), sending ACK
2016.11.21 23:26:17 5: SW: 06
2016.11.21 23:26:17 5: device ack reveived, removing 010a00132203861330251651 from dongle sendstack
2016.11.21 23:26:17 5: ZWDongle_0 dispatch 001316000002
2016.11.21 23:26:17 4: CMD:ZW_SEND_DATA ID:00 ARG:0002 CB:16
2016.11.21 23:26:17 4: ZWDongle_0 transmit OK for CB 16, target ZWave_SENSOR_NOTIFICATION_34
2016.11.21 23:26:17 5: SW: 010a00132203861331251751
2016.11.21 23:26:17 4: ZWDongle_Read ZWDongle_0: rcvd 000400220486143002 (request APPLICATION_COMMAND_HANDLER), sending ACK
2016.11.21 23:26:17 5: SW: 06
2016.11.21 23:26:17 5: ZWDongle_0 dispatch 000400220486143002
2016.11.21 23:26:17 4: CMD:APPLICATION_COMMAND_HANDLER ID:22 ARG:0486143002 CB:00
2016.11.21 23:26:17 5: ZWDongle_Write 001322038613862518 (ee557686)
2016.11.21 23:26:17 4: ZWDongle_Read ZWDongle_0: CAN received
2016.11.21 23:26:18 2: ZWDongle_ProcessSendStack: no ACK, resending message 010a00132203861331251751
2016.11.21 23:26:18 5: SW: 010a00132203861331251751
2016.11.21 23:26:18 5: ACK received, WaitForAck=>2 for 010a00132203861331251751
2016.11.21 23:26:18 4: ZWDongle_Read ZWDongle_0: rcvd 011301 (answer ZW_SEND_DATA), sending ACK
2016.11.21 23:26:18 5: SW: 06
2016.11.21 23:26:18 5: ZWDongle_0 dispatch 011301
2016.11.21 23:26:18 4: ZWDongle_Read ZWDongle_0: rcvd 001317000002 (request ZW_SEND_DATA), sending ACK
2016.11.21 23:26:18 5: SW: 06
2016.11.21 23:26:18 5: device ack reveived, removing 010a00132203861331251751 from dongle sendstack
2016.11.21 23:26:18 5: ZWDongle_0 dispatch 001317000002
2016.11.21 23:26:18 4: CMD:ZW_SEND_DATA ID:00 ARG:0002 CB:17
2016.11.21 23:26:18 4: ZWDongle_0 transmit OK for CB 17, target ZWave_SENSOR_NOTIFICATION_34
2016.11.21 23:26:18 5: SW: 010a001322038613862518e9
2016.11.21 23:26:18 4: ZWDongle_Read ZWDongle_0: rcvd 000400220486143105 (request APPLICATION_COMMAND_HANDLER), sending ACK
2016.11.21 23:26:18 5: SW: 06
2016.11.21 23:26:18 5: ZWDongle_0 dispatch 000400220486143105
2016.11.21 23:26:18 4: CMD:APPLICATION_COMMAND_HANDLER ID:22 ARG:0486143105 CB:00
2016.11.21 23:26:18 5: ZWDongle_Write 001322038613842519 (ee557686)
2016.11.21 23:26:18 4: ZWDongle_Read ZWDongle_0: CAN received
2016.11.21 23:26:18 3: ZWave_SENSOR_NOTIFICATION_34: secStart older than 6 seconds detected, secUnlock will call Zwave_secEnd
2016.11.21 23:26:18 3: ZWave get ZWave_SENSOR_NOTIFICATION_34 model 
2016.11.21 23:26:19 2: ZWDongle_ProcessSendStack: no ACK, resending message 010a001322038613862518e9
2016.11.21 23:26:19 5: SW: 010a001322038613862518e9
2016.11.21 23:26:19 5: ACK received, WaitForAck=>2 for 010a001322038613862518e9
2016.11.21 23:26:19 4: ZWDongle_Read ZWDongle_0: rcvd 011301 (answer ZW_SEND_DATA), sending ACK
2016.11.21 23:26:19 5: SW: 06
2016.11.21 23:26:19 5: ZWDongle_0 dispatch 011301
2016.11.21 23:26:19 4: ZWDongle_Read ZWDongle_0: rcvd 001318000002 (request ZW_SEND_DATA), sending ACK
2016.11.21 23:26:19 5: SW: 06
2016.11.21 23:26:19 5: device ack reveived, removing 010a001322038613862518e9 from dongle sendstack
2016.11.21 23:26:19 5: ZWDongle_0 dispatch 001318000002
2016.11.21 23:26:19 4: CMD:ZW_SEND_DATA ID:00 ARG:0002 CB:18
2016.11.21 23:26:19 4: ZWDongle_0 transmit OK for CB 18, target ZWave_SENSOR_NOTIFICATION_34
2016.11.21 23:26:19 5: SW: 010a001322038613842519ea
2016.11.21 23:26:19 4: ZWDongle_Read ZWDongle_0: rcvd 000400220486148602 (request APPLICATION_COMMAND_HANDLER), sending ACK
2016.11.21 23:26:19 5: SW: 06
2016.11.21 23:26:19 5: ZWDongle_0 dispatch 000400220486148602
2016.11.21 23:26:19 4: CMD:APPLICATION_COMMAND_HANDLER ID:22 ARG:0486148602 CB:00
2016.11.21 23:26:19 5: ZWDongle_Write 0013220386135e251a (ee557686)
2016.11.21 23:26:19 4: ZWDongle_Read ZWDongle_0: CAN received
2016.11.21 23:26:20 2: ZWDongle_ProcessSendStack: no ACK, resending message 010a001322038613842519ea
2016.11.21 23:26:20 5: SW: 010a001322038613842519ea
2016.11.21 23:26:20 5: ACK received, WaitForAck=>2 for 010a001322038613842519ea
2016.11.21 23:26:20 4: ZWDongle_Read ZWDongle_0: rcvd 011301 (answer ZW_SEND_DATA), sending ACK
2016.11.21 23:26:20 5: SW: 06
2016.11.21 23:26:20 5: ZWDongle_0 dispatch 011301
2016.11.21 23:26:20 4: ZWDongle_Read ZWDongle_0: rcvd 001319000002 (request ZW_SEND_DATA), sending ACK
2016.11.21 23:26:20 5: SW: 06
2016.11.21 23:26:20 5: device ack reveived, removing 010a001322038613842519ea from dongle sendstack
2016.11.21 23:26:20 5: ZWDongle_0 dispatch 001319000002
2016.11.21 23:26:20 4: CMD:ZW_SEND_DATA ID:00 ARG:0002 CB:19
2016.11.21 23:26:20 4: ZWDongle_0 transmit OK for CB 19, target ZWave_SENSOR_NOTIFICATION_34
2016.11.21 23:26:20 5: SW: 010a0013220386135e251a33
2016.11.21 23:26:20 4: ZWDongle_Read ZWDongle_0: rcvd 000400220486148402 (request APPLICATION_COMMAND_HANDLER), sending ACK
2016.11.21 23:26:20 5: SW: 06
2016.11.21 23:26:20 5: ZWDongle_0 dispatch 000400220486148402
2016.11.21 23:26:20 4: CMD:APPLICATION_COMMAND_HANDLER ID:22 ARG:0486148402 CB:00
2016.11.21 23:26:20 5: ZWDongle_Write 001322029840251c (ee557686)
2016.11.21 23:26:20 4: ZWDongle_Read ZWDongle_0: CAN received
2016.11.21 23:26:21 2: ZWDongle_ProcessSendStack: no ACK, resending message 010a0013220386135e251a33
2016.11.21 23:26:21 5: SW: 010a0013220386135e251a33
2016.11.21 23:26:21 5: ACK received, WaitForAck=>2 for 010a0013220386135e251a33
2016.11.21 23:26:21 4: ZWDongle_Read ZWDongle_0: rcvd 011301 (answer ZW_SEND_DATA), sending ACK
2016.11.21 23:26:21 5: SW: 06
2016.11.21 23:26:21 5: ZWDongle_0 dispatch 011301
2016.11.21 23:26:21 4: ZWDongle_Read ZWDongle_0: rcvd 00131a000002 (request ZW_SEND_DATA), sending ACK
2016.11.21 23:26:21 5: SW: 06
2016.11.21 23:26:21 5: device ack reveived, removing 010a0013220386135e251a33 from dongle sendstack
2016.11.21 23:26:21 5: ZWDongle_0 dispatch 00131a000002
2016.11.21 23:26:21 4: CMD:ZW_SEND_DATA ID:00 ARG:0002 CB:1a
2016.11.21 23:26:21 4: ZWDongle_0 transmit OK for CB 1a, target ZWave_SENSOR_NOTIFICATION_34
2016.11.21 23:26:21 5: SW: 0109001322029840251c24
2016.11.21 23:26:21 4: ZWDongle_Read ZWDongle_0: rcvd 000400220486145e02 (request APPLICATION_COMMAND_HANDLER), sending ACK
2016.11.21 23:26:21 5: SW: 06
2016.11.21 23:26:21 5: ZWDongle_0 dispatch 000400220486145e02
2016.11.21 23:26:21 4: CMD:APPLICATION_COMMAND_HANDLER ID:22 ARG:0486145e02 CB:00
2016.11.21 23:26:21 5: ZWDongle_Write 001322029840251e (ee557686)
2016.11.21 23:26:21 4: ZWDongle_Read ZWDongle_0: CAN received
2016.11.21 23:26:22 2: ZWDongle_ProcessSendStack: no ACK, resending message 0109001322029840251c24
2016.11.21 23:26:22 5: SW: 0109001322029840251c24
2016.11.21 23:26:22 5: ACK received, WaitForAck=>2 for 0109001322029840251c24
2016.11.21 23:26:22 4: ZWDongle_Read ZWDongle_0: rcvd 011301 (answer ZW_SEND_DATA), sending ACK
2016.11.21 23:26:22 5: SW: 06
2016.11.21 23:26:22 5: ZWDongle_0 dispatch 011301
2016.11.21 23:26:22 4: ZWDongle_Read ZWDongle_0: rcvd 00131c000003 (request ZW_SEND_DATA), sending ACK
2016.11.21 23:26:22 5: SW: 06
2016.11.21 23:26:22 5: device ack reveived, removing 0109001322029840251c24 from dongle sendstack
2016.11.21 23:26:22 5: ZWDongle_0 dispatch 00131c000003
2016.11.21 23:26:22 4: CMD:ZW_SEND_DATA ID:00 ARG:0003 CB:1c
2016.11.21 23:26:22 4: ZWDongle_0 transmit OK for CB 1c, target ZWave_SENSOR_NOTIFICATION_34
2016.11.21 23:26:22 5: SW: 0109001322029840251e26
2016.11.21 23:26:22 4: ZWDongle_Read ZWDongle_0: rcvd 000400220a9880253058d1178f8eca (request APPLICATION_COMMAND_HANDLER), sending ACK
2016.11.21 23:26:22 5: SW: 06
2016.11.21 23:26:22 5: ZWDongle_0 dispatch 000400220a9880253058d1178f8eca
2016.11.21 23:26:22 4: CMD:APPLICATION_COMMAND_HANDLER ID:22 ARG:0a9880253058d1178f8eca CB:00
2016.11.21 23:26:22 5: ZWDongle_Write 001322027204251f (ee557686)
2016.11.21 23:26:22 4: ZWDongle_Read ZWDongle_0: CAN received
2016.11.21 23:26:23 2: ZWDongle_ProcessSendStack: no ACK, resending message 0109001322029840251e26
2016.11.21 23:26:23 5: SW: 0109001322029840251e26
2016.11.21 23:26:23 5: ACK received, WaitForAck=>2 for 0109001322029840251e26
2016.11.21 23:26:23 4: ZWDongle_Read ZWDongle_0: rcvd 011301 (answer ZW_SEND_DATA), sending ACK
2016.11.21 23:26:23 5: SW: 06
2016.11.21 23:26:23 5: ZWDongle_0 dispatch 011301
2016.11.21 23:26:23 4: ZWDongle_Read ZWDongle_0: rcvd 00131e000003 (request ZW_SEND_DATA), sending ACK
2016.11.21 23:26:23 5: SW: 06
2016.11.21 23:26:23 5: device ack reveived, removing 0109001322029840251e26 from dongle sendstack
2016.11.21 23:26:23 5: ZWDongle_0 dispatch 00131e000003
2016.11.21 23:26:23 4: CMD:ZW_SEND_DATA ID:00 ARG:0003 CB:1e
2016.11.21 23:26:23 4: ZWDongle_0 transmit OK for CB 1e, target ZWave_SENSOR_NOTIFICATION_34
2016.11.21 23:26:23 5: SW: 0109001322027204251f89
2016.11.21 23:26:23 4: ZWDongle_Read ZWDongle_0: rcvd 000400220a988072e05e9ed8c6b35c (request APPLICATION_COMMAND_HANDLER), sending ACK
2016.11.21 23:26:23 5: SW: 06
2016.11.21 23:26:23 5: ZWDongle_0 dispatch 000400220a988072e05e9ed8c6b35c
2016.11.21 23:26:23 4: CMD:APPLICATION_COMMAND_HANDLER ID:22 ARG:0a988072e05e9ed8c6b35c CB:00
2016.11.21 23:26:23 5: ZWDongle_Write 00132218988106e5977851ddeb17e31750424425ae076d71ce1d64182520 (ee557686)
2016.11.21 23:26:23 4: ZWDongle_Read ZWDongle_0: CAN received
2016.11.21 23:26:24 2: ZWDongle_ProcessSendStack: no ACK, resending message 0109001322027204251f89
2016.11.21 23:26:24 5: SW: 0109001322027204251f89
2016.11.21 23:26:24 5: ACK received, WaitForAck=>2 for 0109001322027204251f89
2016.11.21 23:26:24 4: ZWDongle_Read ZWDongle_0: rcvd 011301 (answer ZW_SEND_DATA), sending ACK
2016.11.21 23:26:24 5: SW: 06
2016.11.21 23:26:24 5: ZWDongle_0 dispatch 011301
2016.11.21 23:26:24 4: ZWDongle_Read ZWDongle_0: rcvd 00131f000002 (request ZW_SEND_DATA), sending ACK
2016.11.21 23:26:24 5: SW: 06
2016.11.21 23:26:24 5: device ack reveived, removing 0109001322027204251f89 from dongle sendstack
2016.11.21 23:26:24 5: ZWDongle_0 dispatch 00131f000002
2016.11.21 23:26:24 4: CMD:ZW_SEND_DATA ID:00 ARG:0002 CB:1f
2016.11.21 23:26:24 4: ZWDongle_0 transmit OK for CB 1f, target ZWave_SENSOR_NOTIFICATION_34
2016.11.21 23:26:24 5: SW: 011f00132218988106e5977851ddeb17e31750424425ae076d71ce1d6418252034
2016.11.21 23:26:24 4: ZWDongle_Read ZWDongle_0: rcvd 00040022087205013c0002000c (request APPLICATION_COMMAND_HANDLER), sending ACK
2016.11.21 23:26:24 5: SW: 06
2016.11.21 23:26:24 5: ZWDongle_0 dispatch 00040022087205013c0002000c
2016.11.21 23:26:24 4: CMD:APPLICATION_COMMAND_HANDLER ID:22 ARG:087205013c0002000c CB:00
2016.11.21 23:26:26 3: ZWave got config for philio/pst02.xml from ./FHEM/lib/openzwave_deviceconfig.xml.gz
2016.11.21 23:26:26 5: ZWDongle_Write 0013221a98810f2b91d948c1f585f9e3cfc3eef40972bf4d59c1f7a573942521 (ee557686)
2016.11.21 23:26:26 2: ZWDongle_ProcessSendStack: no ACK, resending message 011f00132218988106e5977851ddeb17e31750424425ae076d71ce1d6418252034
2016.11.21 23:26:26 5: SW: 011f00132218988106e5977851ddeb17e31750424425ae076d71ce1d6418252034
2016.11.21 23:26:26 4: ZWDongle_Read ZWDongle_0: CAN received
2016.11.21 23:26:26 5: ACK received, WaitForAck=>2 for 011f00132218988106e5977851ddeb17e31750424425ae076d71ce1d6418252034
2016.11.21 23:26:26 4: ZWDongle_Read ZWDongle_0: rcvd 011301 (answer ZW_SEND_DATA), sending ACK
2016.11.21 23:26:26 5: SW: 06
2016.11.21 23:26:26 5: ZWDongle_0 dispatch 011301
2016.11.21 23:26:26 4: ZWDongle_Read ZWDongle_0: rcvd 001320000002 (request ZW_SEND_DATA), sending ACK
2016.11.21 23:26:26 5: SW: 06
2016.11.21 23:26:26 5: device ack reveived, removing 011f00132218988106e5977851ddeb17e31750424425ae076d71ce1d6418252034 from dongle sendstack
2016.11.21 23:26:26 5: ZWDongle_0 dispatch 001320000002
2016.11.21 23:26:26 4: CMD:ZW_SEND_DATA ID:00 ARG:0002 CB:20
2016.11.21 23:26:26 4: ZWDongle_0 transmit OK for CB 20, target ZWave_SENSOR_NOTIFICATION_34
2016.11.21 23:26:26 5: SW: 01210013221a98810f2b91d948c1f585f9e3cfc3eef40972bf4d59c1f7a573942521d5
2016.11.21 23:26:26 5: ACK received, WaitForAck=>2 for 01210013221a98810f2b91d948c1f585f9e3cfc3eef40972bf4d59c1f7a573942521d5
2016.11.21 23:26:26 4: ZWDongle_Read ZWDongle_0: rcvd 011301 (answer ZW_SEND_DATA), sending ACK
2016.11.21 23:26:26 5: SW: 06
2016.11.21 23:26:26 5: ZWDongle_0 dispatch 011301
2016.11.21 23:26:26 4: ZWDongle_Read ZWDongle_0: rcvd 001321000004 (request ZW_SEND_DATA), sending ACK
2016.11.21 23:26:26 5: SW: 06
2016.11.21 23:26:26 5: device ack reveived, removing 01210013221a98810f2b91d948c1f585f9e3cfc3eef40972bf4d59c1f7a573942521d5 from dongle sendstack
2016.11.21 23:26:26 5: ZWDongle_0 dispatch 001321000004
2016.11.21 23:26:26 4: CMD:ZW_SEND_DATA ID:00 ARG:0004 CB:21
2016.11.21 23:26:26 4: ZWDongle_0 transmit OK for CB 21, target ZWave_SENSOR_NOTIFICATION_34
2016.11.21 23:26:28 5: ZWDongle_Write 0013220284082522 (ee557686)
2016.11.21 23:26:28 5: SW: 010900132202840825224e
2016.11.21 23:26:28 5: ACK received, WaitForAck=>2 for 010900132202840825224e
2016.11.21 23:26:28 4: ZWDongle_Read ZWDongle_0: rcvd 011301 (answer ZW_SEND_DATA), sending ACK
2016.11.21 23:26:28 5: SW: 06
2016.11.21 23:26:28 5: ZWDongle_0 dispatch 011301
2016.11.21 23:26:28 4: ZWDongle_Read ZWDongle_0: rcvd 001322000002 (request ZW_SEND_DATA), sending ACK
2016.11.21 23:26:28 5: SW: 06
2016.11.21 23:26:28 5: device ack reveived, removing 010900132202840825224e from dongle sendstack
2016.11.21 23:26:28 5: ZWDongle_0 dispatch 001322000002
2016.11.21 23:26:28 4: CMD:ZW_SEND_DATA ID:00 ARG:0002 CB:22
2016.11.21 23:26:28 4: ZWDongle_0 transmit OK for CB 22, target ZWave_SENSOR_NOTIFICATION_34
2016.11.21 23:26:35 4: ZWDongle_Read ZWDongle_0: rcvd 00040022029840 (request APPLICATION_COMMAND_HANDLER), sending ACK
2016.11.21 23:26:35 5: SW: 06
2016.11.21 23:26:35 5: ZWDongle_0 dispatch 00040022029840
2016.11.21 23:26:35 4: CMD:APPLICATION_COMMAND_HANDLER ID:22 ARG:029840 CB:00
2016.11.21 23:26:35 5: ZWDongle_Write 0013220a988091a83f3078b23fd22523 (ee557686)
2016.11.21 23:26:35 5: SW: 01110013220a988091a83f3078b23fd22523da
2016.11.21 23:26:35 5: ACK received, WaitForAck=>2 for 01110013220a988091a83f3078b23fd22523da
2016.11.21 23:26:35 4: ZWDongle_Read ZWDongle_0: rcvd 011301 (answer ZW_SEND_DATA), sending ACK
2016.11.21 23:26:35 5: SW: 06
2016.11.21 23:26:35 5: ZWDongle_0 dispatch 011301
2016.11.21 23:26:35 4: ZWDongle_Read ZWDongle_0: rcvd 001323000002 (request ZW_SEND_DATA), sending ACK
2016.11.21 23:26:35 5: SW: 06
2016.11.21 23:26:35 5: device ack reveived, removing 01110013220a988091a83f3078b23fd22523da from dongle sendstack
2016.11.21 23:26:35 5: ZWDongle_0 dispatch 001323000002
2016.11.21 23:26:35 4: CMD:ZW_SEND_DATA ID:00 ARG:0002 CB:23
2016.11.21 23:26:35 4: ZWDongle_0 transmit OK for CB 23, target ZWave_SENSOR_NOTIFICATION_34
2016.11.21 23:26:35 4: ZWDongle_Read ZWDongle_0: rcvd 000400221798817802eff964268c407f9cd46b91eafd5cb0dded25cd (request APPLICATION_COMMAND_HANDLER), sending ACK
2016.11.21 23:26:35 5: SW: 06
2016.11.21 23:26:35 5: ZWDongle_0 dispatch 000400221798817802eff964268c407f9cd46b91eafd5cb0dded25cd
2016.11.21 23:26:35 4: CMD:APPLICATION_COMMAND_HANDLER ID:22 ARG:1798817802eff964268c407f9cd46b91eafd5cb0dded25cd CB:00
2016.11.21 23:26:35 4: CMD:APPLICATION_COMMAND_HANDLER ID:22 ARG:03800364 CB:00
2016.11.21 23:26:35 4: ZWDongle_Read ZWDongle_0: rcvd 00040022029840 (request APPLICATION_COMMAND_HANDLER), sending ACK
2016.11.21 23:26:35 5: SW: 06
2016.11.21 23:26:35 5: ZWDongle_0 dispatch 00040022029840
2016.11.21 23:26:35 4: CMD:APPLICATION_COMMAND_HANDLER ID:22 ARG:029840 CB:00
2016.11.21 23:26:35 5: ZWDongle_Write 0013220a988064c5394285e3618a2524 (ee557686)
2016.11.21 23:26:35 5: SW: 01110013220a988064c5394285e3618a25249b
2016.11.21 23:26:35 5: ACK received, WaitForAck=>2 for 01110013220a988064c5394285e3618a25249b
2016.11.21 23:26:35 4: ZWDongle_Read ZWDongle_0: rcvd 011301 (answer ZW_SEND_DATA), sending ACK
2016.11.21 23:26:35 5: SW: 06
2016.11.21 23:26:35 5: ZWDongle_0 dispatch 011301
2016.11.21 23:26:35 4: ZWDongle_Read ZWDongle_0: rcvd 001324000003 (request ZW_SEND_DATA), sending ACK
2016.11.21 23:26:35 5: SW: 06
2016.11.21 23:26:35 5: device ack reveived, removing 01110013220a988064c5394285e3618a25249b from dongle sendstack
2016.11.21 23:26:35 5: ZWDongle_0 dispatch 001324000003
2016.11.21 23:26:35 4: CMD:ZW_SEND_DATA ID:00 ARG:0003 CB:24
2016.11.21 23:26:35 4: ZWDongle_0 transmit OK for CB 24, target ZWave_SENSOR_NOTIFICATION_34
2016.11.21 23:26:35 4: ZWDongle_Read ZWDongle_0: rcvd 000400221d9881492f6d0ae0742be0be0ea29f04e07040704e642547495c938d8d58 (request APPLICATION_COMMAND_HANDLER), sending ACK
2016.11.21 23:26:35 5: SW: 06
2016.11.21 23:26:35 5: ZWDongle_0 dispatch 000400221d9881492f6d0ae0742be0be0ea29f04e07040704e642547495c938d8d58
2016.11.21 23:26:35 4: CMD:APPLICATION_COMMAND_HANDLER ID:22 ARG:1d9881492f6d0ae0742be0be0ea29f04e07040704e642547495c938d8d58 CB:00
2016.11.21 23:26:35 4: CMD:APPLICATION_COMMAND_HANDLER ID:22 ARG:097105000000ff070800 CB:00
2016.11.21 23:26:35 4: ZWDongle_Read ZWDongle_0: rcvd 00040022029840 (request APPLICATION_COMMAND_HANDLER), sending ACK
2016.11.21 23:26:35 5: SW: 06
2016.11.21 23:26:35 5: ZWDongle_0 dispatch 00040022029840
2016.11.21 23:26:35 4: CMD:APPLICATION_COMMAND_HANDLER ID:22 ARG:029840 CB:00
2016.11.21 23:26:35 5: ZWDongle_Write 0013220a988022843cb6e88075572525 (ee557686)
2016.11.21 23:26:35 5: SW: 01110013220a988022843cb6e88075572525ab
2016.11.21 23:26:35 5: ACK received, WaitForAck=>2 for 01110013220a988022843cb6e88075572525ab
2016.11.21 23:26:35 4: ZWDongle_Read ZWDongle_0: rcvd 011301 (answer ZW_SEND_DATA), sending ACK
2016.11.21 23:26:35 5: SW: 06
2016.11.21 23:26:35 5: ZWDongle_0 dispatch 011301
2016.11.21 23:26:35 4: ZWDongle_Read ZWDongle_0: rcvd 001325000003 (request ZW_SEND_DATA), sending ACK
2016.11.21 23:26:35 5: SW: 06
2016.11.21 23:26:35 5: device ack reveived, removing 01110013220a988022843cb6e88075572525ab from dongle sendstack
2016.11.21 23:26:35 5: ZWDongle_0 dispatch 001325000003
2016.11.21 23:26:35 4: CMD:ZW_SEND_DATA ID:00 ARG:0003 CB:25
2016.11.21 23:26:35 4: ZWDongle_0 transmit OK for CB 25, target ZWave_SENSOR_NOTIFICATION_34
2016.11.21 23:26:35 4: ZWDongle_Read ZWDongle_0: rcvd 00040022199881a1568f771bc62844d4c0e7bc7db722d4968f05345971e8 (request APPLICATION_COMMAND_HANDLER), sending ACK
2016.11.21 23:26:35 5: SW: 06
2016.11.21 23:26:35 5: ZWDongle_0 dispatch 00040022199881a1568f771bc62844d4c0e7bc7db722d4968f05345971e8
2016.11.21 23:26:35 4: CMD:APPLICATION_COMMAND_HANDLER ID:22 ARG:199881a1568f771bc62844d4c0e7bc7db722d4968f05345971e8 CB:00
2016.11.21 23:26:35 4: CMD:APPLICATION_COMMAND_HANDLER ID:22 ARG:053105030110 CB:00
2016.11.21 23:26:35 4: ZWDongle_Read ZWDongle_0: rcvd 00040022029840 (request APPLICATION_COMMAND_HANDLER), sending ACK
2016.11.21 23:26:35 5: SW: 06
2016.11.21 23:26:35 5: ZWDongle_0 dispatch 00040022029840
2016.11.21 23:26:35 4: CMD:APPLICATION_COMMAND_HANDLER ID:22 ARG:029840 CB:00
2016.11.21 23:26:35 5: ZWDongle_Write 0013220a9880645195fc8996b2b72526 (ee557686)
2016.11.21 23:26:35 5: SW: 01110013220a9880645195fc8996b2b7252688
2016.11.21 23:26:35 5: ACK received, WaitForAck=>2 for 01110013220a9880645195fc8996b2b7252688
2016.11.21 23:26:36 4: ZWDongle_Read ZWDongle_0: rcvd 011301 (answer ZW_SEND_DATA), sending ACK
2016.11.21 23:26:36 5: SW: 06
2016.11.21 23:26:36 5: ZWDongle_0 dispatch 011301
2016.11.21 23:26:36 4: ZWDongle_Read ZWDongle_0: rcvd 001326000003 (request ZW_SEND_DATA), sending ACK
2016.11.21 23:26:36 5: SW: 06
2016.11.21 23:26:36 5: device ack reveived, removing 01110013220a9880645195fc8996b2b7252688 from dongle sendstack
2016.11.21 23:26:36 5: ZWDongle_0 dispatch 001326000003
2016.11.21 23:26:36 4: CMD:ZW_SEND_DATA ID:00 ARG:0003 CB:26
2016.11.21 23:26:36 4: ZWDongle_0 transmit OK for CB 26, target ZWave_SENSOR_NOTIFICATION_34
2016.11.21 23:26:36 4: ZWDongle_Read ZWDongle_0: rcvd 000400221a98811def12325d9fb457a13212b79a3a24643c3bbc56f1ee8c73 (request APPLICATION_COMMAND_HANDLER), sending ACK
2016.11.21 23:26:36 5: SW: 06
2016.11.21 23:26:36 5: ZWDongle_0 dispatch 000400221a98811def12325d9fb457a13212b79a3a24643c3bbc56f1ee8c73
2016.11.21 23:26:36 4: CMD:APPLICATION_COMMAND_HANDLER ID:22 ARG:1a98811def12325d9fb457a13212b79a3a24643c3bbc56f1ee8c73 CB:00
2016.11.21 23:26:36 4: CMD:APPLICATION_COMMAND_HANDLER ID:22 ARG:063105012200c8 CB:00

Was hier auffällt ist, daß relativ häufig bereits ACKs verloren ("ZWDongle_ProcessSendStack: no ACK, resending message") gehen und dann ein Retransmit stattfindet.

Titel: Antw:UZB1 Stick: Lizenz schaltet AES Security frei?
Beitrag von: buspirat am 21 November 2016, 23:45:04

Nochmal die gleiche Inklusion (nach erfolgreicher Exklusion):

Code Auswählen


2016.11.21 23:37:00 4: ZWDongle *** set ZWDongle_0 addNode onSec
2016.11.21 23:37:00 5: ZWDongle_Write 004a8106 ()
2016.11.21 23:37:00 5: SW: 0105004a810637
2016.11.21 23:37:00 5: ACK received, removing 0105004a810637 from dongle sendstack
2016.11.21 23:37:00 4: ZWDongle_Read ZWDongle_0: rcvd 004a06010000 (request ZW_ADD_NODE_TO_NETWORK), sending ACK
2016.11.21 23:37:00 5: SW: 06
2016.11.21 23:37:00 5: ZWDongle_0 dispatch 004a06010000
2016.11.21 23:37:00 4: CMD:ZW_ADD_NODE_TO_NETWORK ID:01 ARG:0000 CB:06
2016.11.21 23:37:00 4: ZWDongle_0 ZW_ADD_NODE_TO_NETWORK learnReady
2016.11.21 23:37:02 4: ZWDongle_Read ZWDongle_0: rcvd 004a06020000 (request ZW_ADD_NODE_TO_NETWORK), sending ACK
2016.11.21 23:37:02 5: SW: 06
2016.11.21 23:37:02 5: ZWDongle_0 dispatch 004a06020000
2016.11.21 23:37:02 4: CMD:ZW_ADD_NODE_TO_NETWORK ID:02 ARG:0000 CB:06
2016.11.21 23:37:02 4: ZWDongle_0 ZW_ADD_NODE_TO_NETWORK nodeFound
2016.11.21 23:37:02 4: ZWDongle_Read ZWDongle_0: rcvd 004a060323150407015e80718570728630318459735a8f987aef20 (request ZW_ADD_NODE_TO_NETWORK), sending ACK
2016.11.21 23:37:02 5: SW: 06
2016.11.21 23:37:02 5: ZWDongle_0 dispatch 004a060323150407015e80718570728630318459735a8f987aef20
2016.11.21 23:37:02 4: CMD:ZW_ADD_NODE_TO_NETWORK ID:03 ARG:23150407015e80718570728630318459735a8f987aef20 CB:06
2016.11.21 23:37:02 2: autocreate: define ZWave_SENSOR_NOTIFICATION_35 ZWave ee557686 35 5e80718570728630318459735a8f987aef20
2016.11.21 23:37:02 2: autocreate: define FileLog_ZWave_SENSOR_NOTIFICATION_35 FileLog ./log/ZWave_SENSOR_NOTIFICATION_35-%Y.log ZWave_SENSOR_NOTIFICATION_35
2016.11.21 23:37:03 4: ZWDongle_Read ZWDongle_0: rcvd 004a06052300 (request ZW_ADD_NODE_TO_NETWORK), sending ACK
2016.11.21 23:37:03 5: SW: 06
2016.11.21 23:37:03 5: ZWDongle_0 dispatch 004a06052300
2016.11.21 23:37:03 4: CMD:ZW_ADD_NODE_TO_NETWORK ID:05 ARG:2300 CB:06
2016.11.21 23:37:03 4: ZWDongle *** set ZWDongle_0 addNode off
2016.11.21 23:37:03 5: ZWDongle_Write 004a0507 ()
2016.11.21 23:37:03 5: SW: 0105004a0507b2
2016.11.21 23:37:03 2: ZWAVE Starting secure init for ZWave_SENSOR_NOTIFICATION_35
2016.11.21 23:37:03 5: ZWDongle_Write 00132303980400252e (ee557686)
2016.11.21 23:37:03 5: ACK received, removing 0105004a0507b2 from dongle sendstack
2016.11.21 23:37:03 5: SW: 010a00132303980400252e51
2016.11.21 23:37:03 5: ACK received, WaitForAck=>2 for 010a00132303980400252e51
2016.11.21 23:37:03 4: ZWDongle_Read ZWDongle_0: rcvd 011301 (answer ZW_SEND_DATA), sending ACK
2016.11.21 23:37:03 5: SW: 06
2016.11.21 23:37:03 5: ZWDongle_0 dispatch 011301
2016.11.21 23:37:03 4: ZWDongle_Read ZWDongle_0: rcvd 00132e000002 (request ZW_SEND_DATA), sending ACK
2016.11.21 23:37:03 5: SW: 06
2016.11.21 23:37:03 5: device ack reveived, removing 010a00132303980400252e51 from dongle sendstack
2016.11.21 23:37:03 5: ZWDongle_0 dispatch 00132e000002
2016.11.21 23:37:03 4: CMD:ZW_SEND_DATA ID:00 ARG:0002 CB:2e
2016.11.21 23:37:03 4: ZWDongle_0 transmit OK for CB 2e, target ZWave_SENSOR_NOTIFICATION_35
2016.11.21 23:37:03 4: ZWDongle_Read ZWDongle_0: rcvd 004a07062300 (request ZW_ADD_NODE_TO_NETWORK), sending ACK
2016.11.21 23:37:03 5: SW: 06
2016.11.21 23:37:03 5: ZWDongle_0 dispatch 004a07062300
2016.11.21 23:37:03 4: CMD:ZW_ADD_NODE_TO_NETWORK ID:06 ARG:2300 CB:07
2016.11.21 23:37:03 4: ZWDongle_0 ZW_ADD_NODE_TO_NETWORK done
2016.11.21 23:37:05 4: ZWDongle_Read ZWDongle_0: rcvd 0004002303980500 (request APPLICATION_COMMAND_HANDLER), sending ACK
2016.11.21 23:37:05 5: SW: 06
2016.11.21 23:37:05 5: ZWDongle_0 dispatch 0004002303980500
2016.11.21 23:37:05 4: CMD:APPLICATION_COMMAND_HANDLER ID:23 ARG:03980500 CB:00
2016.11.21 23:37:05 5: ZWDongle_Write 001323029840252f (ee557686)
2016.11.21 23:37:05 5: SW: 0109001323029840252f16
2016.11.21 23:37:05 5: ACK received, WaitForAck=>2 for 0109001323029840252f16
2016.11.21 23:37:05 4: ZWDongle_Read ZWDongle_0: rcvd 011301 (answer ZW_SEND_DATA), sending ACK
2016.11.21 23:37:05 5: SW: 06
2016.11.21 23:37:05 5: ZWDongle_0 dispatch 011301
2016.11.21 23:37:05 4: ZWDongle_Read ZWDongle_0: rcvd 00132f000003 (request ZW_SEND_DATA), sending ACK
2016.11.21 23:37:05 5: SW: 06
2016.11.21 23:37:05 5: device ack reveived, removing 0109001323029840252f16 from dongle sendstack
2016.11.21 23:37:05 5: ZWDongle_0 dispatch 00132f000003
2016.11.21 23:37:05 4: CMD:ZW_SEND_DATA ID:00 ARG:0003 CB:2f
2016.11.21 23:37:05 4: ZWDongle_0 transmit OK for CB 2f, target ZWave_SENSOR_NOTIFICATION_35
2016.11.21 23:37:05 4: ZWDongle_Read ZWDongle_0: rcvd 000400230a98809fa6bf7fbd499428 (request APPLICATION_COMMAND_HANDLER), sending ACK
2016.11.21 23:37:05 5: SW: 06
2016.11.21 23:37:05 5: ZWDongle_0 dispatch 000400230a98809fa6bf7fbd499428
2016.11.21 23:37:05 4: CMD:APPLICATION_COMMAND_HANDLER ID:23 ARG:0a98809fa6bf7fbd499428 CB:00
2016.11.21 23:37:05 5: ZWDongle_Write 00132326988177832145cd8686c018c4673a611f7c713f43298986d06629e14d729f719169345130566e2530 (ee557686)
2016.11.21 23:37:05 5: SW: 012d00132326988177832145cd8686c018c4673a611f7c713f43298986d06629e14d729f719169345130566e2530c7
2016.11.21 23:37:05 5: ACK received, WaitForAck=>2 for 012d00132326988177832145cd8686c018c4673a611f7c713f43298986d06629e14d729f719169345130566e2530c7
2016.11.21 23:37:05 4: ZWDongle_Read ZWDongle_0: rcvd 011301 (answer ZW_SEND_DATA), sending ACK
2016.11.21 23:37:05 5: SW: 06
2016.11.21 23:37:05 5: ZWDongle_0 dispatch 011301
2016.11.21 23:37:05 4: ZWDongle_Read ZWDongle_0: rcvd 001330000003 (request ZW_SEND_DATA), sending ACK
2016.11.21 23:37:05 5: SW: 06
2016.11.21 23:37:05 5: device ack reveived, removing 012d00132326988177832145cd8686c018c4673a611f7c713f43298986d06629e14d729f719169345130566e2530c7 from dongle sendstack
2016.11.21 23:37:05 5: ZWDongle_0 dispatch 001330000003
2016.11.21 23:37:05 4: CMD:ZW_SEND_DATA ID:00 ARG:0003 CB:30
2016.11.21 23:37:05 4: ZWDongle_0 transmit OK for CB 30, target ZWave_SENSOR_NOTIFICATION_35
2016.11.21 23:37:05 4: ZWDongle_Read ZWDongle_0: rcvd 00040023029840 (request APPLICATION_COMMAND_HANDLER), sending ACK
2016.11.21 23:37:05 5: SW: 06
2016.11.21 23:37:05 5: ZWDongle_0 dispatch 00040023029840
2016.11.21 23:37:05 4: CMD:APPLICATION_COMMAND_HANDLER ID:23 ARG:029840 CB:00
2016.11.21 23:37:05 5: ZWDongle_Write 0013230a988055c5702ac702b4232531 (ee557686)
2016.11.21 23:37:05 5: SW: 01110013230a988055c5702ac702b423253140
2016.11.21 23:37:05 5: ACK received, WaitForAck=>2 for 01110013230a988055c5702ac702b423253140
2016.11.21 23:37:05 4: ZWDongle_Read ZWDongle_0: rcvd 011301 (answer ZW_SEND_DATA), sending ACK
2016.11.21 23:37:05 5: SW: 06
2016.11.21 23:37:05 5: ZWDongle_0 dispatch 011301
2016.11.21 23:37:05 4: ZWDongle_Read ZWDongle_0: rcvd 001331000003 (request ZW_SEND_DATA), sending ACK
2016.11.21 23:37:05 5: SW: 06
2016.11.21 23:37:05 5: device ack reveived, removing 01110013230a988055c5702ac702b423253140 from dongle sendstack
2016.11.21 23:37:05 5: ZWDongle_0 dispatch 001331000003
2016.11.21 23:37:05 4: CMD:ZW_SEND_DATA ID:00 ARG:0003 CB:31
2016.11.21 23:37:05 4: ZWDongle_0 transmit OK for CB 31, target ZWave_SENSOR_NOTIFICATION_35
2016.11.21 23:37:05 4: ZWDongle_Read ZWDongle_0: rcvd 00040023169881523640904a1af5cf1670cc553699e0e1f7ebd3f5 (request APPLICATION_COMMAND_HANDLER), sending ACK
2016.11.21 23:37:05 5: SW: 06
2016.11.21 23:37:05 5: ZWDongle_0 dispatch 00040023169881523640904a1af5cf1670cc553699e0e1f7ebd3f5
2016.11.21 23:37:05 4: CMD:APPLICATION_COMMAND_HANDLER ID:23 ARG:169881523640904a1af5cf1670cc553699e0e1f7ebd3f5 CB:00
2016.11.21 23:37:05 4: CMD:APPLICATION_COMMAND_HANDLER ID:23 ARG:029807 CB:00
2016.11.21 23:37:05 3: ZWave_SENSOR_NOTIFICATION_35: SECURITY enabled, networkkey was verified
2016.11.21 23:37:05 3: ZWave set ZWave_SENSOR_NOTIFICATION_35 secSupportedReport 
2016.11.21 23:37:05 5: ZWDongle_Write 0013230298402533 (ee557686)
2016.11.21 23:37:05 5: SW: 010900132302984025330a
2016.11.21 23:37:05 5: ACK received, WaitForAck=>2 for 010900132302984025330a
2016.11.21 23:37:05 4: ZWDongle_Read ZWDongle_0: rcvd 011301 (answer ZW_SEND_DATA), sending ACK
2016.11.21 23:37:05 5: SW: 06
2016.11.21 23:37:05 5: ZWDongle_0 dispatch 011301
2016.11.21 23:37:05 4: ZWDongle_Read ZWDongle_0: rcvd 001333000002 (request ZW_SEND_DATA), sending ACK
2016.11.21 23:37:05 5: SW: 06
2016.11.21 23:37:05 5: device ack reveived, removing 010900132302984025330a from dongle sendstack
2016.11.21 23:37:05 5: ZWDongle_0 dispatch 001333000002
2016.11.21 23:37:05 4: CMD:ZW_SEND_DATA ID:00 ARG:0002 CB:33
2016.11.21 23:37:05 4: ZWDongle_0 transmit OK for CB 33, target ZWave_SENSOR_NOTIFICATION_35
2016.11.21 23:37:05 4: ZWDongle_Read ZWDongle_0: rcvd 000400230a98806c3ae966b4f41228 (request APPLICATION_COMMAND_HANDLER), sending ACK
2016.11.21 23:37:05 5: SW: 06
2016.11.21 23:37:05 5: ZWDongle_0 dispatch 000400230a98806c3ae966b4f41228
2016.11.21 23:37:05 4: CMD:APPLICATION_COMMAND_HANDLER ID:23 ARG:0a98806c3ae966b4f41228 CB:00
2016.11.21 23:37:05 5: ZWDongle_Write 001323169881bef00db075591748ae1d926c3af3a1826ee0f73c2534 (ee557686)
2016.11.21 23:37:05 5: SW: 011d001323169881bef00db075591748ae1d926c3af3a1826ee0f73c2534ae
2016.11.21 23:37:05 5: ACK received, WaitForAck=>2 for 011d001323169881bef00db075591748ae1d926c3af3a1826ee0f73c2534ae
2016.11.21 23:37:05 4: ZWDongle_Read ZWDongle_0: rcvd 011301 (answer ZW_SEND_DATA), sending ACK
2016.11.21 23:37:05 5: SW: 06
2016.11.21 23:37:05 5: ZWDongle_0 dispatch 011301
2016.11.21 23:37:05 4: ZWDongle_Read ZWDongle_0: rcvd 001334000002 (request ZW_SEND_DATA), sending ACK
2016.11.21 23:37:05 5: SW: 06
2016.11.21 23:37:05 5: device ack reveived, removing 011d001323169881bef00db075591748ae1d926c3af3a1826ee0f73c2534ae from dongle sendstack
2016.11.21 23:37:05 5: ZWDongle_0 dispatch 001334000002
2016.11.21 23:37:05 4: CMD:ZW_SEND_DATA ID:00 ARG:0002 CB:34
2016.11.21 23:37:05 4: ZWDongle_0 transmit OK for CB 34, target ZWave_SENSOR_NOTIFICATION_35
2016.11.21 23:37:05 4: ZWDongle_Read ZWDongle_0: rcvd 00040023029840 (request APPLICATION_COMMAND_HANDLER), sending ACK
2016.11.21 23:37:05 5: SW: 06
2016.11.21 23:37:05 5: ZWDongle_0 dispatch 00040023029840
2016.11.21 23:37:05 4: CMD:APPLICATION_COMMAND_HANDLER ID:23 ARG:029840 CB:00
2016.11.21 23:37:05 5: ZWDongle_Write 0013230a9880db2c864f453bd1d22535 (ee557686)
2016.11.21 23:37:05 5: SW: 01110013230a9880db2c864f453bd1d225359f
2016.11.21 23:37:05 5: ACK received, WaitForAck=>2 for 01110013230a9880db2c864f453bd1d225359f
2016.11.21 23:37:05 4: ZWDongle_Read ZWDongle_0: rcvd 011301 (answer ZW_SEND_DATA), sending ACK
2016.11.21 23:37:05 5: SW: 06
2016.11.21 23:37:05 5: ZWDongle_0 dispatch 011301
2016.11.21 23:37:05 4: ZWDongle_Read ZWDongle_0: rcvd 001335000002 (request ZW_SEND_DATA), sending ACK
2016.11.21 23:37:05 5: SW: 06
2016.11.21 23:37:05 5: device ack reveived, removing 01110013230a9880db2c864f453bd1d225359f from dongle sendstack
2016.11.21 23:37:05 5: ZWDongle_0 dispatch 001335000002
2016.11.21 23:37:05 4: CMD:ZW_SEND_DATA ID:00 ARG:0002 CB:35
2016.11.21 23:37:05 4: ZWDongle_0 transmit OK for CB 35, target ZWave_SENSOR_NOTIFICATION_35
2016.11.21 23:37:05 4: ZWDongle_Read ZWDongle_0: rcvd 00040023029840 (request APPLICATION_COMMAND_HANDLER), sending ACK
2016.11.21 23:37:05 5: SW: 06
2016.11.21 23:37:05 5: ZWDongle_0 dispatch 00040023029840
2016.11.21 23:37:05 4: CMD:APPLICATION_COMMAND_HANDLER ID:23 ARG:029840 CB:00
2016.11.21 23:37:05 5: ZWDongle_Write 0013230a98809fcf2f6c85e6c9c02536 (ee557686)
2016.11.21 23:37:05 5: SW: 01110013230a98809fcf2f6c85e6c9c02536a6
2016.11.21 23:37:05 5: ACK received, WaitForAck=>2 for 01110013230a98809fcf2f6c85e6c9c02536a6
2016.11.21 23:37:05 4: ZWDongle_Read ZWDongle_0: rcvd 011301 (answer ZW_SEND_DATA), sending ACK
2016.11.21 23:37:05 5: SW: 06
2016.11.21 23:37:05 5: ZWDongle_0 dispatch 011301
2016.11.21 23:37:05 4: ZWDongle_Read ZWDongle_0: rcvd 000400231f9881d7bf76a3931f22337c7132429caba9cd1b8f4ee1db6c72af277d36925e (request APPLICATION_COMMAND_HANDLER), sending ACK
2016.11.21 23:37:05 5: SW: 06
2016.11.21 23:37:05 5: ZWDongle_0 dispatch 000400231f9881d7bf76a3931f22337c7132429caba9cd1b8f4ee1db6c72af277d36925e
2016.11.21 23:37:05 4: CMD:APPLICATION_COMMAND_HANDLER ID:23 ARG:1f9881d7bf76a3931f22337c7132429caba9cd1b8f4ee1db6c72af277d36925e CB:00
2016.11.21 23:37:05 1: ZWave_SENSOR_NOTIFICATION_35: secDecrypt: Authentification code not verified, command 34a4d6ef2113e3d00d67f6 will be dropped!
2016.11.21 23:37:05 4: ZWDongle_Read ZWDongle_0: rcvd 001336000003 (request ZW_SEND_DATA), sending ACK
2016.11.21 23:37:05 5: SW: 06
2016.11.21 23:37:05 5: device ack reveived, removing 01110013230a98809fcf2f6c85e6c9c02536a6 from dongle sendstack
2016.11.21 23:37:05 5: ZWDongle_0 dispatch 001336000003
2016.11.21 23:37:05 4: CMD:ZW_SEND_DATA ID:00 ARG:0003 CB:36
2016.11.21 23:37:05 4: ZWDongle_0 transmit OK for CB 36, target ZWave_SENSOR_NOTIFICATION_35
2016.11.21 23:37:07 5: ZWDongle_Write 0013230284082537 (ee557686)
2016.11.21 23:37:07 5: SW: 010900132302840825375a
2016.11.21 23:37:07 5: ACK received, WaitForAck=>2 for 010900132302840825375a
2016.11.21 23:37:07 4: ZWDongle_Read ZWDongle_0: rcvd 011301 (answer ZW_SEND_DATA), sending ACK
2016.11.21 23:37:07 5: SW: 06
2016.11.21 23:37:07 5: ZWDongle_0 dispatch 011301
2016.11.21 23:37:07 4: ZWDongle_Read ZWDongle_0: rcvd 001337000002 (request ZW_SEND_DATA), sending ACK
2016.11.21 23:37:07 5: SW: 06
2016.11.21 23:37:07 5: device ack reveived, removing 010900132302840825375a from dongle sendstack
2016.11.21 23:37:07 5: ZWDongle_0 dispatch 001337000002
2016.11.21 23:37:07 4: CMD:ZW_SEND_DATA ID:00 ARG:0002 CB:37
2016.11.21 23:37:07 4: ZWDongle_0 transmit OK for CB 37, target ZWave_SENSOR_NOTIFICATION_35

Hier fällt auf:
"2016.11.21 23:37:05 1: ZWave_SENSOR_NOTIFICATION_35: secDecrypt: Authentification code not verified, command 34a4d6ef2113e3d00d67f6 will be dropped!"

Entweder macht der Sensor Mist oder im Stack kommt tatsächlich was durcheinander.
Sonst habe ich eigentlich keine Übertragungsprobleme, da der Sensor und UZB1-Stick momentan nur eine Wand trennt.

Log vom eigentlichen Problem folgt.

Titel: Antw:UZB1 Stick: Lizenz schaltet AES Security frei?
Beitrag von: buspirat am 22 November 2016, 00:08:16

Problem reproduziert :D

Code Auswählen


*** Fenster-Sensor ausgelöst ***

2016.11.21 23:56:48 4: ZWDongle_Read ZWDongle_0: rcvd 00040026029840 (request APPLICATION_COMMAND_HANDLER), sending ACK
2016.11.21 23:56:48 5: SW: 06
2016.11.21 23:56:48 5: ZWDongle_0 dispatch 00040026029840
2016.11.21 23:56:48 4: CMD:APPLICATION_COMMAND_HANDLER ID:26 ARG:029840 CB:00
2016.11.21 23:56:48 5: ZWDongle_Write 0013260a988068a01c35382ffca0250a (ee557686)
2016.11.21 23:56:48 5: SW: 01110013260a988068a01c35382ffca0250a4c
2016.11.21 23:56:48 5: ACK received, WaitForAck=>2 for 01110013260a988068a01c35382ffca0250a4c
2016.11.21 23:56:48 4: ZWDongle_Read ZWDongle_0: rcvd 011301 (answer ZW_SEND_DATA), sending ACK
2016.11.21 23:56:48 5: SW: 06
2016.11.21 23:56:48 5: ZWDongle_0 dispatch 011301
2016.11.21 23:56:48 4: ZWDongle_Read ZWDongle_0: rcvd 00130a000002 (request ZW_SEND_DATA), sending ACK
2016.11.21 23:56:48 5: SW: 06
2016.11.21 23:56:48 5: device ack reveived, removing 01110013260a988068a01c35382ffca0250a4c from dongle sendstack
2016.11.21 23:56:48 5: ZWDongle_0 dispatch 00130a000002
2016.11.21 23:56:48 4: CMD:ZW_SEND_DATA ID:00 ARG:0002 CB:0a
2016.11.21 23:56:48 4: ZWDongle_0 transmit OK for CB 0a, target ZWave_SENSOR_NOTIFICATION_38
2016.11.21 23:56:48 4: ZWDongle_Read ZWDongle_0: rcvd 00040026029840 (request APPLICATION_COMMAND_HANDLER), sending ACK
2016.11.21 23:56:48 5: SW: 06
2016.11.21 23:56:48 5: ZWDongle_0 dispatch 00040026029840
2016.11.21 23:56:48 4: CMD:APPLICATION_COMMAND_HANDLER ID:26 ARG:029840 CB:00
2016.11.21 23:56:48 5: ZWDongle_Write 0013260a98805ad0e03c3021932c250b (ee557686)
2016.11.21 23:56:48 5: SW: 01110013260a98805ad0e03c3021932c250b1f
2016.11.21 23:56:48 5: ACK received, WaitForAck=>2 for 01110013260a98805ad0e03c3021932c250b1f
2016.11.21 23:56:48 4: ZWDongle_Read ZWDongle_0: rcvd 011301 (answer ZW_SEND_DATA), sending ACK
2016.11.21 23:56:48 5: SW: 06
2016.11.21 23:56:48 5: ZWDongle_0 dispatch 011301
2016.11.21 23:56:48 4: ZWDongle_Read ZWDongle_0: rcvd 000400261d98815f3e641e7bb6f61d276bc9be51e599e8753b68fc41fffe4133acd3 (request APPLICATION_COMMAND_HANDLER), sending ACK
2016.11.21 23:56:48 5: SW: 06
2016.11.21 23:56:48 5: ZWDongle_0 dispatch 000400261d98815f3e641e7bb6f61d276bc9be51e599e8753b68fc41fffe4133acd3
2016.11.21 23:56:48 4: CMD:APPLICATION_COMMAND_HANDLER ID:26 ARG:1d98815f3e641e7bb6f61d276bc9be51e599e8753b68fc41fffe4133acd3 CB:00

*** ungefähr hier auf der Fernbedienung (ID: 28) rumgedrückt, der Befehl kam wohl nicht an ***
*** kann jedoch vor oder nach dem secDecrypt Fehler sein, Timing nicht 100% sicher ***

2016.11.21 23:56:48 1: ZWave_SENSOR_NOTIFICATION_38: secDecrypt: Authentification code not verified, command 18f4c63a5d9f91144d will be dropped!
2016.11.21 23:56:50 4: no response from device, removing 01110013260a98805ad0e03c3021932c250b1f from dongle sendstack
2016.11.21 23:56:52 4: ZWDongle_Read ZWDongle_0: rcvd 00130b0101ad (request ZW_SEND_DATA), sending ACK
2016.11.21 23:56:52 5: SW: 06
2016.11.21 23:56:52 5: ZWDongle_0 dispatch 00130b0101ad
2016.11.21 23:56:52 4: CMD:ZW_SEND_DATA ID:01 ARG:01ad CB:0b
2016.11.21 23:56:52 2: ZWDongle_0 transmit NO_ACK for CB 0b, target ZWave_SENSOR_NOTIFICATION_38
2016.11.21 23:56:53 4: ZWDongle_Read ZWDongle_0: rcvd 0004001c055b03af0204 (request APPLICATION_COMMAND_HANDLER), sending ACK
2016.11.21 23:56:53 5: SW: 06
2016.11.21 23:56:53 5: ZWDongle_0 dispatch 0004001c055b03af0204
2016.11.21 23:56:53 4: CMD:APPLICATION_COMMAND_HANDLER ID:1c ARG:055b03af0204 CB:00
2016.11.21 23:56:53 4: ZWDongle_Read ZWDongle_0: rcvd 0004001c055b03b00204 (request APPLICATION_COMMAND_HANDLER), sending ACK
2016.11.21 23:56:53 5: SW: 06
2016.11.21 23:56:53 5: ZWDongle_0 dispatch 0004001c055b03b00204
2016.11.21 23:56:53 4: CMD:APPLICATION_COMMAND_HANDLER ID:1c ARG:055b03b00204 CB:00
2016.11.21 23:56:54 4: ZWDongle_Read ZWDongle_0: rcvd 0004001c055b03b10204 (request APPLICATION_COMMAND_HANDLER), sending ACK
2016.11.21 23:56:54 5: SW: 06
2016.11.21 23:56:54 5: ZWDongle_0 dispatch 0004001c055b03b10204
2016.11.21 23:56:54 4: CMD:APPLICATION_COMMAND_HANDLER ID:1c ARG:055b03b10204 CB:00
2016.11.21 23:56:58 4: ZWDongle_Read ZWDongle_0: rcvd 0004001c055b03b20204 (request APPLICATION_COMMAND_HANDLER), sending ACK
2016.11.21 23:56:58 5: SW: 06
2016.11.21 23:56:58 5: ZWDongle_0 dispatch 0004001c055b03b20204
2016.11.21 23:56:58 4: CMD:APPLICATION_COMMAND_HANDLER ID:1c ARG:055b03b20204 CB:00
2016.11.21 23:56:59 4: ZWDongle_Read ZWDongle_0: rcvd 0004001c055b03b30204 (request APPLICATION_COMMAND_HANDLER), sending ACK
2016.11.21 23:56:59 5: SW: 06
2016.11.21 23:56:59 5: ZWDongle_0 dispatch 0004001c055b03b30204
2016.11.21 23:56:59 4: CMD:APPLICATION_COMMAND_HANDLER ID:1c ARG:055b03b30204 CB:00
2016.11.21 23:56:59 4: ZWDongle_Read ZWDongle_0: rcvd 0004001c055b03b40204 (request APPLICATION_COMMAND_HANDLER), sending ACK
2016.11.21 23:56:59 5: SW: 06
2016.11.21 23:56:59 5: ZWDongle_0 dispatch 0004001c055b03b40204
2016.11.21 23:56:59 4: CMD:APPLICATION_COMMAND_HANDLER ID:1c ARG:055b03b40204 CB:00
2016.11.21 23:57:04 4: ZWDongle_Read ZWDongle_0: rcvd 0004001c055b03b50204 (request APPLICATION_COMMAND_HANDLER), sending ACK
2016.11.21 23:57:04 5: SW: 06
2016.11.21 23:57:04 5: ZWDongle_0 dispatch 0004001c055b03b50204
2016.11.21 23:57:04 4: CMD:APPLICATION_COMMAND_HANDLER ID:1c ARG:055b03b50204 CB:00
2016.11.21 23:57:04 4: ZWDongle_Read ZWDongle_0: rcvd 0004001c055b03b60204 (request APPLICATION_COMMAND_HANDLER), sending ACK
2016.11.21 23:57:04 5: SW: 06
2016.11.21 23:57:04 5: ZWDongle_0 dispatch 0004001c055b03b60204
2016.11.21 23:57:04 4: CMD:APPLICATION_COMMAND_HANDLER ID:1c ARG:055b03b60204 CB:00
2016.11.21 23:57:04 4: ZWDongle_Read ZWDongle_0: rcvd 0004001c055b03b70204 (request APPLICATION_COMMAND_HANDLER), sending ACK
2016.11.21 23:57:04 5: SW: 06
2016.11.21 23:57:04 5: ZWDongle_0 dispatch 0004001c055b03b70204
2016.11.21 23:57:04 4: CMD:APPLICATION_COMMAND_HANDLER ID:1c ARG:055b03b70204 CB:00
2016.11.21 23:57:04 4: ZWDongle_Read ZWDongle_0: rcvd 0004001c055b03b80204 (request APPLICATION_COMMAND_HANDLER), sending ACK
2016.11.21 23:57:04 5: SW: 06
2016.11.21 23:57:04 5: ZWDongle_0 dispatch 0004001c055b03b80204
2016.11.21 23:57:04 4: CMD:APPLICATION_COMMAND_HANDLER ID:1c ARG:055b03b80204 CB:00
2016.11.21 23:57:04 4: ZWDongle_Read ZWDongle_0: rcvd 0004001c055b03b90204 (request APPLICATION_COMMAND_HANDLER), sending ACK
2016.11.21 23:57:04 5: SW: 06
2016.11.21 23:57:04 5: ZWDongle_0 dispatch 0004001c055b03b90204
2016.11.21 23:57:04 4: CMD:APPLICATION_COMMAND_HANDLER ID:1c ARG:055b03b90204 CB:00
2016.11.21 23:57:09 4: ZWDongle_Read ZWDongle_0: rcvd 0004001c055b03bb0204 (request APPLICATION_COMMAND_HANDLER), sending ACK
2016.11.21 23:57:09 5: SW: 06
2016.11.21 23:57:09 5: ZWDongle_0 dispatch 0004001c055b03bb0204
2016.11.21 23:57:09 4: CMD:APPLICATION_COMMAND_HANDLER ID:1c ARG:055b03bb0204 CB:00
2016.11.21 23:57:14 4: ZWDongle_Read ZWDongle_0: rcvd 0004001c055b03bc0204 (request APPLICATION_COMMAND_HANDLER), sending ACK
2016.11.21 23:57:14 5: SW: 06
2016.11.21 23:57:14 5: ZWDongle_0 dispatch 0004001c055b03bc0204
2016.11.21 23:57:14 4: CMD:APPLICATION_COMMAND_HANDLER ID:1c ARG:055b03bc0204 CB:00
2016.11.21 23:57:14 4: ZWDongle_Read ZWDongle_0: rcvd 0004001c055b03bd0204 (request APPLICATION_COMMAND_HANDLER), sending ACK
2016.11.21 23:57:14 5: SW: 06
2016.11.21 23:57:14 5: ZWDongle_0 dispatch 0004001c055b03bd0204
2016.11.21 23:57:14 4: CMD:APPLICATION_COMMAND_HANDLER ID:1c ARG:055b03bd0204 CB:00
2016.11.21 23:57:19 4: ZWDongle_Read ZWDongle_0: rcvd 0004001c055b03bf0204 (request APPLICATION_COMMAND_HANDLER), sending ACK
2016.11.21 23:57:19 5: SW: 06
2016.11.21 23:57:19 5: ZWDongle_0 dispatch 0004001c055b03bf0204
2016.11.21 23:57:19 4: CMD:APPLICATION_COMMAND_HANDLER ID:1c ARG:055b03bf0204 CB:00
2016.11.21 23:57:19 4: ZWDongle_Read ZWDongle_0: rcvd 0004001c055b03c00204 (request APPLICATION_COMMAND_HANDLER), sending ACK
2016.11.21 23:57:19 5: SW: 06
2016.11.21 23:57:19 5: ZWDongle_0 dispatch 0004001c055b03c00204
2016.11.21 23:57:19 4: CMD:APPLICATION_COMMAND_HANDLER ID:1c ARG:055b03c00204 CB:00
2016.11.21 23:58:12 4: ZWDongle_Read ZWDongle_0: rcvd 00040026029840 (request APPLICATION_COMMAND_HANDLER), sending ACK
2016.11.21 23:58:12 5: SW: 06
2016.11.21 23:58:12 5: ZWDongle_0 dispatch 00040026029840
2016.11.21 23:58:12 4: CMD:APPLICATION_COMMAND_HANDLER ID:26 ARG:029840 CB:00
2016.11.21 23:58:19 3: ZWave_SENSOR_NOTIFICATION_38: secStart older than 6 seconds detected, secUnlock will call Zwave_secEnd
2016.11.21 23:58:20 4: ZWDongle_Read ZWDongle_0: rcvd 00040026029840 (request APPLICATION_COMMAND_HANDLER), sending ACK
2016.11.21 23:58:20 5: SW: 06
2016.11.21 23:58:20 5: ZWDongle_0 dispatch 00040026029840
2016.11.21 23:58:20 4: CMD:APPLICATION_COMMAND_HANDLER ID:26 ARG:029840 CB:00
2016.11.21 23:58:27 3: ZWave_SENSOR_NOTIFICATION_38: secStart older than 6 seconds detected, secUnlock will call Zwave_secEnd
2016.11.21 23:58:28 4: ZWDongle_Read ZWDongle_0: rcvd 00040026029840 (request APPLICATION_COMMAND_HANDLER), sending ACK
2016.11.21 23:58:28 5: SW: 06
2016.11.21 23:58:28 5: ZWDongle_0 dispatch 00040026029840
2016.11.21 23:58:28 4: CMD:APPLICATION_COMMAND_HANDLER ID:26 ARG:029840 CB:00
2016.11.21 23:58:35 3: ZWave_SENSOR_NOTIFICATION_38: secStart older than 6 seconds detected, secUnlock will call Zwave_secEnd
2016.11.21 23:58:36 4: ZWDongle_Read ZWDongle_0: rcvd 00040026029840 (request APPLICATION_COMMAND_HANDLER), sending ACK
2016.11.21 23:58:36 5: SW: 06
2016.11.21 23:58:36 5: ZWDongle_0 dispatch 00040026029840
2016.11.21 23:58:36 4: CMD:APPLICATION_COMMAND_HANDLER ID:26 ARG:029840 CB:00
2016.11.21 23:58:43 3: ZWave_SENSOR_NOTIFICATION_38: secStart older than 6 seconds detected, secUnlock will call Zwave_secEnd
2016.11.21 23:58:44 4: ZWDongle_Read ZWDongle_0: rcvd 00040026029840 (request APPLICATION_COMMAND_HANDLER), sending ACK
2016.11.21 23:58:44 5: SW: 06
2016.11.21 23:58:44 5: ZWDongle_0 dispatch 00040026029840
2016.11.21 23:58:44 4: CMD:APPLICATION_COMMAND_HANDLER ID:26 ARG:029840 CB:00
2016.11.21 23:58:51 3: ZWave_SENSOR_NOTIFICATION_38: secStart older than 6 seconds detected, secUnlock will call Zwave_secEnd
2016.11.21 23:58:52 4: ZWDongle_Read ZWDongle_0: rcvd 00040026029840 (request APPLICATION_COMMAND_HANDLER), sending ACK
2016.11.21 23:58:52 5: SW: 06
2016.11.21 23:58:52 5: ZWDongle_0 dispatch 00040026029840
2016.11.21 23:58:52 4: CMD:APPLICATION_COMMAND_HANDLER ID:26 ARG:029840 CB:00
2016.11.21 23:58:59 3: ZWave_SENSOR_NOTIFICATION_38: secStart older than 6 seconds detected, secUnlock will call Zwave_secEnd
2016.11.21 23:59:00 4: ZWDongle_Read ZWDongle_0: rcvd 00040026029840 (request APPLICATION_COMMAND_HANDLER), sending ACK
2016.11.21 23:59:00 5: SW: 06
2016.11.21 23:59:00 5: ZWDongle_0 dispatch 00040026029840
2016.11.21 23:59:00 4: CMD:APPLICATION_COMMAND_HANDLER ID:26 ARG:029840 CB:00
2016.11.21 23:59:07 3: ZWave_SENSOR_NOTIFICATION_38: secStart older than 6 seconds detected, secUnlock will call Zwave_secEnd
2016.11.21 23:59:08 4: ZWDongle_Read ZWDongle_0: rcvd 00040026029840 (request APPLICATION_COMMAND_HANDLER), sending ACK
2016.11.21 23:59:08 5: SW: 06
2016.11.21 23:59:08 5: ZWDongle_0 dispatch 00040026029840
2016.11.21 23:59:08 4: CMD:APPLICATION_COMMAND_HANDLER ID:26 ARG:029840 CB:00
2016.11.21 23:59:15 3: ZWave_SENSOR_NOTIFICATION_38: secStart older than 6 seconds detected, secUnlock will call Zwave_secEnd
2016.11.21 23:59:16 4: ZWDongle_Read ZWDongle_0: rcvd 00040026029840 (request APPLICATION_COMMAND_HANDLER), sending ACK
2016.11.21 23:59:16 5: SW: 06
2016.11.21 23:59:16 5: ZWDongle_0 dispatch 00040026029840
2016.11.21 23:59:16 4: CMD:APPLICATION_COMMAND_HANDLER ID:26 ARG:029840 CB:00
2016.11.21 23:59:23 3: ZWave_SENSOR_NOTIFICATION_38: secStart older than 6 seconds detected, secUnlock will call Zwave_secEnd
2016.11.22 00:00:08 4: ZWDongle_Read ZWDongle_0: rcvd 00040026029840 (request APPLICATION_COMMAND_HANDLER), sending ACK
2016.11.22 00:00:08 5: SW: 06
2016.11.22 00:00:08 5: ZWDongle_0 dispatch 00040026029840
2016.11.22 00:00:08 4: CMD:APPLICATION_COMMAND_HANDLER ID:26 ARG:029840 CB:00
2016.11.22 00:00:15 3: ZWave_SENSOR_NOTIFICATION_38: secStart older than 6 seconds detected, secUnlock will call Zwave_secEnd

*** hier wurde nichts rausgeschnitten, tatsächlich vier Minuten Pause ***

2016.11.22 00:04:02 4: ZWDongle_Read ZWDongle_0: rcvd 00040026029840 (request APPLICATION_COMMAND_HANDLER), sending ACK
2016.11.22 00:04:02 5: SW: 06
2016.11.22 00:04:02 5: ZWDongle_0 dispatch 00040026029840
2016.11.22 00:04:02 4: CMD:APPLICATION_COMMAND_HANDLER ID:26 ARG:029840 CB:00
2016.11.22 00:04:09 3: ZWave_SENSOR_NOTIFICATION_38: secStart older than 6 seconds detected, secUnlock will call Zwave_secEnd
2016.11.22 00:05:01 4: ZWDongle_Read ZWDongle_0: rcvd 00040026029840 (request APPLICATION_COMMAND_HANDLER), sending ACK
2016.11.22 00:05:01 5: SW: 06
2016.11.22 00:05:01 5: ZWDongle_0 dispatch 00040026029840
2016.11.22 00:05:01 4: CMD:APPLICATION_COMMAND_HANDLER ID:26 ARG:029840 CB:00
2016.11.22 00:05:08 3: ZWave_SENSOR_NOTIFICATION_38: secStart older than 6 seconds detected, secUnlock will call Zwave_secEnd

und so weiter in der Schleife... es kommen auch keine Readings mehr vom Sensor an. Nur Neustart von FHEM hilft.

Titel: Antw:UZB1 Stick: Lizenz schaltet AES Security frei?
Beitrag von: A.Harrenberg am 22 November 2016, 22:29:58

Hi,

für mich sieht das leider sehr nach Übertragungsproblemen aus.

Es gibt mehrere Stellen an denen der Controller den Empfang einer Nachricht mit ACK bestätigt, die selbe Nachricht wird aber danach sofort wieder empfangen was nur bedeuten kann das dieses ACK nicht bei dem Gerät angekommen ist und es deswegen die Nachricht noch mal erneut verschickt.

Was genau im Hintergrund passiert wenn Du den Fehler reproduzierst kann ich leider noch nicht ganz genau sagen, aber auch hier fängt kommt es zu einer doppelten Nachricht vom Gerät.

Ablauf ist grob:

- Gerät fragt nach einer NONCE
- ACK wird gesendet
- NONCE wird versendet (#1)
- ACK wird empfangen
- Gerät fragt noch mal nach einer NONCE (#2, sollte nicht so sein...)
- ACK wird gesendet
- verschlüsselte Nachricht wird empfangen

Diese Nachricht kann jedoch nicht entschlüsselt werden da die Authentifizierung nicht stimmt. Zur Authentifizierung wird die gesendete NONCE verwendet, ich merke mir im Code nur die letzte gesendete NONCE da es immer nur eine laufende Kommunikation geben darf. Allerdings ist in diesem Fall das Packet mit NONCE #1 verschlüsselt während im Code mit NONCE #2 entschlüsselt wird.

Mir ist momentan nicht klar wieso das Geräte erneut nach einer NONCE fragt aber dennoch mit der ersten verschlüsselt hat.

Anschliessend bleibt es interessant...
Es kommen dann so ca. 18-20 Nachrichten von Deiner Fernbedienung.
Danach beginnt dann eine Schleife in der das Gerät wieder nach einer NONCE fragt, hier sendet fhem allerdings nicht mehr und nach jeweils ca. 6 sekunden wird diese von einem Timer erkannt und der "Lock" der verhindern soll das mehrere Kommunikationen durcheinander stattfinden wird wieder entfernt und es beginnt von vorne.

Warum fhem hier nicht mehr sendet kann ich momentan noch nicht sagen, dazu müsste ich da noch mal sehr genau in den Code reinschauen um das nachzuvollziehen. Grundproblem ist aber irgendwie das es hier recht häufig zu doppelten Nachrichten kommt die den Ablauf durcheinanderbringen.

Könntest Du bitte noch mal ein get assoziationAll von dem Sensor macht und das list von dem Sensor posten? Könnte es sein das der Dongle da in mehreren Assoziationsgruppen gleichzeitig drin ist?

Gruß,
Andreas.

Titel: Antw:UZB1 Stick: Lizenz schaltet AES Security frei?
Beitrag von: buspirat am 23 November 2016, 08:40:19

Zitat von: A.Harrenberg am 22 November 2016, 22:29:58
Könntest Du bitte noch mal ein get assoziationAll von dem Sensor macht und das list von dem Sensor posten? Könnte es sein das der Dongle da in mehreren Assoziationsgruppen gleichzeitig drin ist?

Danke für die Analyse! Kurz zwischen Tür und Angel:

Das "get Sensor_Haustuere associationAll" liegt jetzt erstmal auf dem SendStack, der Sensor schickt keine WN bei einem Event wie Fenster auf/zu. Kann bis zu 24h dauern.

Der Sensor ist momentan ohne Security eingebunden. Langt Dir das oder soll ich Ihn vorher wieder mit SECURITY einbinden?
Explizitie Associations habe ich eigentlich nicht gesetzt...

Titel: Antw:UZB1 Stick: Lizenz schaltet AES Security frei?
Beitrag von: A.Harrenberg am 23 November 2016, 12:19:47

Hi,

dann warte mal auf die WUN, wenn Du nichts besonderes gemacht hast dann müssen die Assoziationen jetzt ja genauso aussehen wie mit Security und Du musst den (erst mal) nicht wieder mit Security einbinden. Ansonsten müsste ich in dem XML nachsehen welche Assoziationen bei der Inklusion ausgeführt werden.

Gruß,
Andreas.

Titel: Antw:UZB1 Stick: Lizenz schaltet AES Security frei?
Beitrag von: buspirat am 24 November 2016, 00:04:55

Der Sensor ist erwacht :D

Code Auswählen


list Sensor_Haustuere
Internals:
   DEF        12345678 40
   IODev      ZWDongle_0
   LASTInputDev ZWDongle_0
   MSGCNT     667
   NAME       Sensor_Haustuere
   NR         70
   STATE      wakeupInterval 86400 1
   TYPE       ZWave
   ZWDongle_0_MSGCNT 667
   ZWDongle_0_RAWMSG 00040028097105000000ff07fe00
   ZWDongle_0_TIME 2016-11-23 23:57:58
   ZWaveSubDevice no
   homeId     12345678
   isWakeUp   1
   lastMsgSent 1479935114.88089
   nodeIdHex  28
   Readings:
     2016-11-23 23:57:58   alarm           HomeSecurity: unknown event 254
     2016-11-23 22:05:12   assocGroup_1    Max 8 Nodes ZWDongle_0
     2016-11-23 22:05:12   assocGroup_2    Max 8 Nodes 
     2016-11-23 22:05:12   assocGroups     2
     2016-11-23 23:57:37   battery         100 %
     2016-11-09 23:03:32   configAutoReportBatteryTime 12
     2016-11-09 23:03:32   configAutoReportDoorWindowStateTime 12
     2016-11-09 23:03:32   configAutoReportIlluminationTime 0
     2016-11-09 23:03:32   configAutoReportTemperatureTime 12
     2016-11-09 23:03:32   configAutoReportTickInterval 60
     2016-11-09 23:03:33   configBasicSetLevel 255
     2016-11-09 23:03:33   configCustomerFunction 4
     2016-11-09 23:03:33   configIlluminationDifferentialReport 0
     2016-11-09 23:03:33   configLightThreshold 99
     2016-11-09 23:03:33   configMultiSensorFunctionSwitch 4
     2016-11-09 23:03:33   configOperationMode 8
     2016-11-09 23:03:33   configPIRReDetectIntervalTime 3
     2016-11-09 23:03:33   configPIRSensitivity 80
     2016-11-09 23:03:33   configTemperatureDifferentialReport 0
     2016-11-09 23:03:33   configTurnOffLightTime 4
     2016-11-23 23:57:37   luminance       11 %
     2016-11-09 22:27:02   model           Philio Technology Corporation PST02-A 4 in 1 Multi-Sensor
     2016-11-09 22:27:02   modelConfig     philio/pst02.xml
     2016-11-09 22:27:02   modelId         013c-0002-000c
     2016-11-22 08:20:55   setpointTemp    23.68 C heating
     2016-11-09 22:26:58   state           wakeupInterval 86400 1
     2016-11-23 23:57:37   temperature     18.5 C
     2016-11-23 22:05:14   timeToAck       0.029
     2016-11-23 22:05:14   transmit        OK
     2016-11-23 22:05:12   wakeup          notification
     2016-11-09 23:00:16   wakeupReport    interval 86400 target 1
     2016-11-09 22:30:12   zwavePlusInfo   version:01 role:SleepingReportingSlave node:Z-Wave+Node installerIcon:0c07 userIcon:0c07
Attributes:
   IODev      ZWDongle_0
   classes    ZWAVEPLUS_INFO BATTERY ALARM ASSOCIATION CONFIGURATION MANUFACTURER_SPECIFIC VERSION SENSOR_BINARY SENSOR_MULTILEVEL WAKE_UP ASSOCIATION_GRP_INFO POWERLEVEL DEVICE_RESET_LOCALLY MULTI_CMD SECURITY FIRMWARE_UPDATE_MD MARK BASIC
   room       ZWave
   vclasses   ALARM:4 ASSOCIATION:2 ASSOCIATION_GRP_INFO:1 BASIC:0 BATTERY:1 CONFIGURATION:1 DEVICE_RESET_LOCALLY:1 FIRMWARE_UPDATE_MD:2 MANUFACTURER_SPECIFIC:2 MULTI_CMD:1 POWERLEVEL:1 SECURITY:1 SENSOR_BINARY:2 SENSOR_MULTILEVEL:5 VERSION:2 WAKE_UP:2 ZWAVEPLUS_INFO:2

Die 100% offensichtliche homeId oben habe ich ersetzt. Vermute jedoch, daß die in den Raw-Nachrichten im Verbose-Level 5 mit drin ist... aber pssssst.

Durch das erneute Inkludieren hat er eine höhere NodeId. Hoffe das hilft.

VG,
Thomas

Titel: Antw:UZB1 Stick: Lizenz schaltet AES Security frei?
Beitrag von: A.Harrenberg am 24 November 2016, 07:03:53

Hi,

danke, ich hatte die Vermutung das der Sensor evtl. den Dongle in zwei Assoziationsgruppen hat und dann für jede Gruppe eine eigene Kommunikation öffnet und das es dann deswegen zu den doppelten Nachrichten kommt. Wäre ungewöhnlich und so nicht vorgesehen, es soll/darf immer nur eine aktive Kommunikation geben. Es gibt den Dongle bei Dir aber nur in einer Assoziation, daher kann es aber als Ursache auch ausgeschlossen werden.

Aufgrund der vielen nötigen Nachrichten ist die Kommunikation mit Security leider etwas anfälliger gegen Störungen und die Implementierung ist auch nicht besonders robust gegen Störungen im Ablauf...

Kannst Du mal versuchen das Szenario was zum Absturz der Kommunikation mit Security geführt hat jetzt mal ohne Security durchzuführen und ein Log posten? Gibt es aktuell im Log NO_ACK Meldungen vom Sensor?

Gruß,
Andreas.

Titel: Antw:UZB1 Stick: Lizenz schaltet AES Security frei?
Beitrag von: buspirat am 24 November 2016, 22:18:36

Zitat von: A.Harrenberg am 24 November 2016, 07:03:53
Kannst Du mal versuchen das Szenario was zum Absturz der Kommunikation mit Security geführt hat jetzt mal ohne Security durchzuführen und ein Log posten? Gibt es aktuell im Log NO_ACK Meldungen vom Sensor?

Der Sensor_Haustuere ist momentan eher Sensor_Durchgangsflur und somit wird der Bewegungsmelder oft ausgelöst. Bisher keine einzige NO_ACK Meldung für den Sensor im Log. Einzig das Danfoss Heizungsventil produziert mind. einmal die Stunde ein NO_ACK, die Kommunikation ist dennoch stabil.

Werde jetzt versuchen Sensor_Haustuere ein wenig zu stressen.

Titel: Antw:UZB1 Stick: Lizenz schaltet AES Security frei?
Beitrag von: buspirat am 24 November 2016, 23:26:06

Ohne SECURITY schaffe ich es nicht die Kommunikation zu stören. Sehr effektiv ist es den Sensor auf den Tisch zu legen und mit dem Fenstermagneten zu fuchteln -> das erzeugt viel Traffic.
Gleichzeitiges Rumdrücken auf der Fernbedienung, die per SECURITY eingebunden ist, geht auch problemlos.

Hier ein Kommunikationsbeispiel von Sensor_Haustuere:

Code Auswählen


2016.11.24 23:03:53 4: ZWDongle_Read ZWDongle_0: rcvd 0004002803800364 (request APPLICATION_COMMAND_HANDLER), sending ACK
2016.11.24 23:03:53 5: SW: 06
2016.11.24 23:03:53 5: ZWDongle_0 dispatch 0004002803800364
2016.11.24 23:03:53 4: CMD:APPLICATION_COMMAND_HANDLER ID:28 ARG:03800364 CB:00
2016.11.24 23:03:53 4: ZWDongle_Read ZWDongle_0: rcvd 00040028097105000000ff061600 (request APPLICATION_COMMAND_HANDLER), sending ACK
2016.11.24 23:03:53 5: SW: 06
2016.11.24 23:03:53 5: ZWDongle_0 dispatch 00040028097105000000ff061600
2016.11.24 23:03:53 4: CMD:APPLICATION_COMMAND_HANDLER ID:28 ARG:097105000000ff061600 CB:00
2016.11.24 23:03:53 4: ZWDongle_Read ZWDongle_0: rcvd 00040028053105030107 (request APPLICATION_COMMAND_HANDLER), sending ACK
2016.11.24 23:03:53 5: SW: 06
2016.11.24 23:03:53 5: ZWDongle_0 dispatch 00040028053105030107
2016.11.24 23:03:53 4: CMD:APPLICATION_COMMAND_HANDLER ID:28 ARG:053105030107 CB:00
2016.11.24 23:03:53 4: ZWDongle_Read ZWDongle_0: rcvd 00040028063105012200c3 (request APPLICATION_COMMAND_HANDLER), sending ACK
2016.11.24 23:03:53 5: SW: 06
2016.11.24 23:03:53 5: ZWDongle_0 dispatch 00040028063105012200c3
2016.11.24 23:03:53 4: CMD:APPLICATION_COMMAND_HANDLER ID:28 ARG:063105012200c3 CB:00
2016.11.24 23:03:54 4: ZWDongle_Read ZWDongle_0: rcvd 0004002803800364 (request APPLICATION_COMMAND_HANDLER), sending ACK
2016.11.24 23:03:54 5: SW: 06
2016.11.24 23:03:54 5: ZWDongle_0 dispatch 0004002803800364
2016.11.24 23:03:54 4: CMD:APPLICATION_COMMAND_HANDLER ID:28 ARG:03800364 CB:00
2016.11.24 23:03:54 4: ZWDongle_Read ZWDongle_0: rcvd 00040028097105000000ff061700 (request APPLICATION_COMMAND_HANDLER), sending ACK
2016.11.24 23:03:54 5: SW: 06
2016.11.24 23:03:54 5: ZWDongle_0 dispatch 00040028097105000000ff061700
2016.11.24 23:03:54 4: CMD:APPLICATION_COMMAND_HANDLER ID:28 ARG:097105000000ff061700 CB:00
2016.11.24 23:03:54 4: ZWDongle_Read ZWDongle_0: rcvd 00040028053105030109 (request APPLICATION_COMMAND_HANDLER), sending ACK
2016.11.24 23:03:54 5: SW: 06
2016.11.24 23:03:54 5: ZWDongle_0 dispatch 00040028053105030109
2016.11.24 23:03:54 4: CMD:APPLICATION_COMMAND_HANDLER ID:28 ARG:053105030109 CB:00
2016.11.24 23:03:54 4: ZWDongle_Read ZWDongle_0: rcvd 00040028063105012200c3 (request APPLICATION_COMMAND_HANDLER), sending ACK
2016.11.24 23:03:54 5: SW: 06
2016.11.24 23:03:54 5: ZWDongle_0 dispatch 00040028063105012200c3
2016.11.24 23:03:54 4: CMD:APPLICATION_COMMAND_HANDLER ID:28 ARG:063105012200c3 CB:00
2016.11.24 23:03:54 4: ZWDongle_Read ZWDongle_0: rcvd 0004002803800364 (request APPLICATION_COMMAND_HANDLER), sending ACK
2016.11.24 23:03:54 5: SW: 06
2016.11.24 23:03:54 5: ZWDongle_0 dispatch 0004002803800364
2016.11.24 23:03:54 4: CMD:APPLICATION_COMMAND_HANDLER ID:28 ARG:03800364 CB:00
2016.11.24 23:03:54 4: ZWDongle_Read ZWDongle_0: rcvd 00040028097105000000ff061600 (request APPLICATION_COMMAND_HANDLER), sending ACK
2016.11.24 23:03:54 5: SW: 06
2016.11.24 23:03:54 5: ZWDongle_0 dispatch 00040028097105000000ff061600
2016.11.24 23:03:54 4: CMD:APPLICATION_COMMAND_HANDLER ID:28 ARG:097105000000ff061600 CB:00
2016.11.24 23:03:54 4: ZWDongle_Read ZWDongle_0: rcvd 0004002805310503010f (request APPLICATION_COMMAND_HANDLER), sending ACK
2016.11.24 23:03:54 5: SW: 06
2016.11.24 23:03:54 5: ZWDongle_0 dispatch 0004002805310503010f
2016.11.24 23:03:54 4: CMD:APPLICATION_COMMAND_HANDLER ID:28 ARG:05310503010f CB:00
2016.11.24 23:03:54 4: ZWDongle_Read ZWDongle_0: rcvd 00040028063105012200c3 (request APPLICATION_COMMAND_HANDLER), sending ACK
2016.11.24 23:03:54 5: SW: 06
2016.11.24 23:03:54 5: ZWDongle_0 dispatch 00040028063105012200c3
2016.11.24 23:03:54 4: CMD:APPLICATION_COMMAND_HANDLER ID:28 ARG:063105012200c3 CB:00
2016.11.24 23:03:54 4: ZWDongle_Read ZWDongle_0: rcvd 0004002803800364 (request APPLICATION_COMMAND_HANDLER), sending ACK
2016.11.24 23:03:54 5: SW: 06
2016.11.24 23:03:54 5: ZWDongle_0 dispatch 0004002803800364
2016.11.24 23:03:54 4: CMD:APPLICATION_COMMAND_HANDLER ID:28 ARG:03800364 CB:00
2016.11.24 23:03:54 4: ZWDongle_Read ZWDongle_0: rcvd 0004002805310503010f (request APPLICATION_COMMAND_HANDLER), sending ACK
2016.11.24 23:03:54 5: SW: 06
2016.11.24 23:03:54 5: ZWDongle_0 dispatch 0004002805310503010f
2016.11.24 23:03:54 4: CMD:APPLICATION_COMMAND_HANDLER ID:28 ARG:05310503010f CB:00
2016.11.24 23:03:54 4: ZWDongle_Read ZWDongle_0: rcvd 00040028063105012200c3 (request APPLICATION_COMMAND_HANDLER), sending ACK
2016.11.24 23:03:54 5: SW: 06
2016.11.24 23:03:54 5: ZWDongle_0 dispatch 00040028063105012200c3
2016.11.24 23:03:54 4: CMD:APPLICATION_COMMAND_HANDLER ID:28 ARG:063105012200c3 CB:00
2016.11.24 23:03:55 4: ZWDongle_Read ZWDongle_0: rcvd 0004002803800364 (request APPLICATION_COMMAND_HANDLER), sending ACK
2016.11.24 23:03:55 5: SW: 06
2016.11.24 23:03:55 5: ZWDongle_0 dispatch 0004002803800364
2016.11.24 23:03:55 4: CMD:APPLICATION_COMMAND_HANDLER ID:28 ARG:03800364 CB:00
2016.11.24 23:03:55 4: ZWDongle_Read ZWDongle_0: rcvd 00040028097105000000ff061700 (request APPLICATION_COMMAND_HANDLER), sending ACK
2016.11.24 23:03:55 5: SW: 06
2016.11.24 23:03:55 5: ZWDongle_0 dispatch 00040028097105000000ff061700
2016.11.24 23:03:55 4: CMD:APPLICATION_COMMAND_HANDLER ID:28 ARG:097105000000ff061700 CB:00
2016.11.24 23:03:55 4: ZWDongle_Read ZWDongle_0: rcvd 00040028053105030114 (request APPLICATION_COMMAND_HANDLER), sending ACK
2016.11.24 23:03:55 5: SW: 06
2016.11.24 23:03:55 5: ZWDongle_0 dispatch 00040028053105030114
2016.11.24 23:03:55 4: CMD:APPLICATION_COMMAND_HANDLER ID:28 ARG:053105030114 CB:00
2016.11.24 23:03:55 4: ZWDongle_Read ZWDongle_0: rcvd 00040028063105012200c3 (request APPLICATION_COMMAND_HANDLER), sending ACK
2016.11.24 23:03:55 5: SW: 06
2016.11.24 23:03:55 5: ZWDongle_0 dispatch 00040028063105012200c3
2016.11.24 23:03:55 4: CMD:APPLICATION_COMMAND_HANDLER ID:28 ARG:063105012200c3 CB:00
2016.11.24 23:04:06 4: ZWDongle_Read ZWDongle_0: rcvd 0004002803800364 (request APPLICATION_COMMAND_HANDLER), sending ACK
2016.11.24 23:04:06 5: SW: 06
2016.11.24 23:04:06 5: ZWDongle_0 dispatch 0004002803800364
2016.11.24 23:04:06 4: CMD:APPLICATION_COMMAND_HANDLER ID:28 ARG:03800364 CB:00
2016.11.24 23:04:06 4: ZWDongle_Read ZWDongle_0: rcvd 00040028097105000000ff061600 (request APPLICATION_COMMAND_HANDLER), sending ACK
2016.11.24 23:04:06 5: SW: 06
2016.11.24 23:04:06 5: ZWDongle_0 dispatch 00040028097105000000ff061600
2016.11.24 23:04:06 4: CMD:APPLICATION_COMMAND_HANDLER ID:28 ARG:097105000000ff061600 CB:00
2016.11.24 23:04:06 4: ZWDongle_Read ZWDongle_0: rcvd 00040028053105030113 (request APPLICATION_COMMAND_HANDLER), sending ACK
2016.11.24 23:04:06 5: SW: 06
2016.11.24 23:04:06 5: ZWDongle_0 dispatch 00040028053105030113
2016.11.24 23:04:06 4: CMD:APPLICATION_COMMAND_HANDLER ID:28 ARG:053105030113 CB:00
2016.11.24 23:04:06 4: ZWDongle_Read ZWDongle_0: rcvd 00040028063105012200c3 (request APPLICATION_COMMAND_HANDLER), sending ACK
2016.11.24 23:04:06 5: SW: 06
2016.11.24 23:04:06 5: ZWDongle_0 dispatch 00040028063105012200c3
2016.11.24 23:04:06 4: CMD:APPLICATION_COMMAND_HANDLER ID:28 ARG:063105012200c3 CB:00
2016.11.24 23:04:06 4: ZWDongle_Read ZWDongle_0: rcvd 0004002803800364 (request APPLICATION_COMMAND_HANDLER), sending ACK
2016.11.24 23:04:06 5: SW: 06
2016.11.24 23:04:06 5: ZWDongle_0 dispatch 0004002803800364
2016.11.24 23:04:06 4: CMD:APPLICATION_COMMAND_HANDLER ID:28 ARG:03800364 CB:00
2016.11.24 23:04:06 4: ZWDongle_Read ZWDongle_0: rcvd 00040028053105030113 (request APPLICATION_COMMAND_HANDLER), sending ACK
2016.11.24 23:04:06 5: SW: 06
2016.11.24 23:04:06 5: ZWDongle_0 dispatch 00040028053105030113
2016.11.24 23:04:06 4: CMD:APPLICATION_COMMAND_HANDLER ID:28 ARG:053105030113 CB:00
2016.11.24 23:04:06 4: ZWDongle_Read ZWDongle_0: rcvd 00040028063105012200c3 (request APPLICATION_COMMAND_HANDLER), sending ACK
2016.11.24 23:04:06 5: SW: 06
2016.11.24 23:04:06 5: ZWDongle_0 dispatch 00040028063105012200c3
2016.11.24 23:04:06 4: CMD:APPLICATION_COMMAND_HANDLER ID:28 ARG:063105012200c3 CB:00
2016.11.24 23:04:07 4: ZWDongle_Read ZWDongle_0: rcvd 0004002803800364 (request APPLICATION_COMMAND_HANDLER), sending ACK
2016.11.24 23:04:07 5: SW: 06
2016.11.24 23:04:07 5: ZWDongle_0 dispatch 0004002803800364
2016.11.24 23:04:07 4: CMD:APPLICATION_COMMAND_HANDLER ID:28 ARG:03800364 CB:00
2016.11.24 23:04:07 4: ZWDongle_Read ZWDongle_0: rcvd 00040028097105000000ff061700 (request APPLICATION_COMMAND_HANDLER), sending ACK
2016.11.24 23:04:07 5: SW: 06
2016.11.24 23:04:07 5: ZWDongle_0 dispatch 00040028097105000000ff061700
2016.11.24 23:04:07 4: CMD:APPLICATION_COMMAND_HANDLER ID:28 ARG:097105000000ff061700 CB:00
2016.11.24 23:04:07 4: ZWDongle_Read ZWDongle_0: rcvd 00040028053105030113 (request APPLICATION_COMMAND_HANDLER), sending ACK
2016.11.24 23:04:07 5: SW: 06
2016.11.24 23:04:07 5: ZWDongle_0 dispatch 00040028053105030113
2016.11.24 23:04:07 4: CMD:APPLICATION_COMMAND_HANDLER ID:28 ARG:053105030113 CB:00
2016.11.24 23:04:07 4: ZWDongle_Read ZWDongle_0: rcvd 00040028063105012200c3 (request APPLICATION_COMMAND_HANDLER), sending ACK
2016.11.24 23:04:07 5: SW: 06
2016.11.24 23:04:07 5: ZWDongle_0 dispatch 00040028063105012200c3
2016.11.24 23:04:07 4: CMD:APPLICATION_COMMAND_HANDLER ID:28 ARG:063105012200c3 CB:00
2016.11.24 23:04:17 4: ZWDongle_Read ZWDongle_0: rcvd 00040028097105000000ff07fe00 (request APPLICATION_COMMAND_HANDLER), sending ACK
2016.11.24 23:04:17 5: SW: 06
2016.11.24 23:04:17 5: ZWDongle_0 dispatch 00040028097105000000ff07fe00
2016.11.24 23:04:17 4: CMD:APPLICATION_COMMAND_HANDLER ID:28 ARG:097105000000ff07fe00 CB:00
2016.11.24 23:04:26 4: ZWDongle_Read ZWDongle_0: rcvd 000400080380034e (request APPLICATION_COMMAND_HANDLER), sending ACK
2016.11.24 23:04:26 5: SW: 06
2016.11.24 23:04:26 5: ZWDongle_0 dispatch 000400080380034e

-> alles in Butter

Titel: Antw:UZB1 Stick: Lizenz schaltet AES Security frei?
Beitrag von: buspirat am 25 November 2016, 00:37:03

Zitat von: A.Harrenberg am 22 November 2016, 22:29:58
Mir ist momentan nicht klar wieso das Geräte erneut nach einer NONCE fragt aber dennoch mit der ersten verschlüsselt hat.

gehen wir davon aus, daß der Sensor die Kommunikation verbockt hat.

Das Paket mit der alten NONCE muss als Fehler behandelt werden, da sonst der Schutz vor Replay-Attacken flöten gehen würde.

Zitat von: A.Harrenberg am 22 November 2016, 22:29:58
Danach beginnt dann eine Schleife in der das Gerät wieder nach einer NONCE fragt, hier sendet fhem allerdings nicht mehr und nach jeweils ca. 6 sekunden wird diese von einem Timer erkannt und der "Lock" der verhindern soll das mehrere Kommunikationen durcheinander stattfinden wird wieder entfernt und es beginnt von vorne.

Warum fhem hier nicht mehr sendet kann ich momentan noch nicht sagen

ich habe den Code grob überflogen und das einzig offensichtliche ist, daß ZWave_secStart() den Timer stets zurücksetzt, auch wenn secInProgress bereits auf 1 gesetzt ist. Allerdings ist das nicht der Bug bzw. vermutlich sogar so gewollt.

Ich tippe darauf, daß aus irgendeinem Grund nach dem eingehenden NONCE-Request das ZWave_secNonceRequestReceived() nicht aufgerufen wird. Oder der SendStack irgendwie tot ist. Zumindest vermisse ich den ZWDongle_Write nach der Nonce Anfrage.

Andere Idee: Ich setze einen Data::Dumper($hash) in den ZWave_secUnlock() "timer expired" Fehlerhandler. Vielleicht sieht man dem Hash einen krummen Zustand an. Eventuell dazu noch "zwave_parsehook" dumpen.

Ganz böse Geister würden sogar in den timer expired Handler Code einbauen, der eine Textdatei von der Festplatte lädt und mit eval() ausführt. Sozusagen live FHEM Patching. Keine Lust jeweils eine halbe Stunde auf den Fehler zu warten...

Titel: Antw:UZB1 Stick: Lizenz schaltet AES Security frei?
Beitrag von: A.Harrenberg am 25 November 2016, 20:16:31

Hi,

Zitat von: buspirat am 25 November 2016, 00:37:03
gehen wir davon aus, daß der Sensor die Kommunikation verbockt hat.

bin noch nicht davon überzeugt das es so einfach ist...

Zitat von: buspirat am 25 November 2016, 00:37:03
Das Paket mit der alten NONCE muss als Fehler behandelt werden, da sonst der Schutz vor Replay-Attacken flöten gehen würde.

Hier bin ich anderer Meinung. Die Kenntnis der NONCE kann nicht für Attacken ausgenutzt werden, das zurückgeschickte Packet ist ja immer noch mit dem (unbekannten Schlüssel) verschlüsselt und daher weiterhin sicher. Die NONCE wird ja auch unverschlüsselt gesendet und kann daher immer als bekannt vorausgesetzt werden.

Zitat von: buspirat am 25 November 2016, 00:37:03
ich habe den Code grob überflogen und das einzig offensichtliche ist, daß ZWave_secStart() den Timer stets zurücksetzt, auch wenn secInProgress bereits auf 1 gesetzt ist. Allerdings ist das nicht der Bug bzw. vermutlich sogar so gewollt.

Hmm, kann ich mich gerade nicht mehr so dran erinnern, hatte sicherlich einen guten Grund ,-)

Zitat von: buspirat am 25 November 2016, 00:37:03
Ich tippe darauf, daß aus irgendeinem Grund nach dem eingehenden NONCE-Request das ZWave_secNonceRequestReceived() nicht aufgerufen wird. Oder der SendStack irgendwie tot ist. Zumindest vermisse ich den ZWDongle_Write nach der Nonce Anfrage.

Ein weiteres versenden eine NONCE fehlt, das stimmt... Ich fürchte das der Ablauf mit sec_start/end und dem Umkopieren des Stacks etc, da irgendwie aus dem Tritt kommt. Das zu finden nicht ganz so einfach sein...

Ich werde mal versuchen meinen WALL-C und den AEOTEC Multisensor mit SECURITY einzubinden und mal schauen ob ich das nachstellen kann. Das wäre dann wesentlich einfacher als Ping-Pong mit Logfiles....

Zitat von: buspirat am 25 November 2016, 00:37:03
Andere Idee: Ich setze einen Data::Dumper($hash) in den ZWave_secUnlock() "timer expired" Fehlerhandler. Vielleicht sieht man dem Hash einen krummen Zustand an. Eventuell dazu noch "zwave_parsehook" dumpen.

Ganz böse Geister würden sogar in den timer expired Handler Code einbauen, der eine Textdatei von der Festplatte lädt und mit eval() ausführt. Sozusagen live FHEM Patching. Keine Lust jeweils eine halbe Stunde auf den Fehler zu warten...

Hier hast Du mich abgehängt... Habe von Perl gar nicht so viel Ahnung, verstehe zwar das dies debugging ist, aber die Details?

Na ich werde mal anfangen die beiden Geräte zu exkludieren und mit SECURITY zu inkludieren und dann mal sehen was passiert.

Gruß,
Andreas.

Titel: Antw:UZB1 Stick: Lizenz schaltet AES Security frei?
Beitrag von: buspirat am 25 November 2016, 21:19:53

Zitat von: A.Harrenberg am 25 November 2016, 20:16:31
Hier bin ich anderer Meinung. Die Kenntnis der NONCE kann nicht für Attacken ausgenutzt werden, das zurückgeschickte Packet ist ja immer noch mit dem (unbekannten Schlüssel) verschlüsselt und daher weiterhin sicher. Die NONCE wird ja auch unverschlüsselt gesendet und kann daher immer als bekannt vorausgesetzt werden.

alles korrekt, daß NONCE ist öffentlich verfügbar.

Was ich sagen wollten: Wir dürfen unter keinen Umständen alte NONCE-Werte akzeptieren, es darf nur das aktuelle gelten.

Sonst kann jemand hingehen und eine verschlüsselte Nachricht aufzeichnen und später wieder abspielen. Sowas nennt sich ein Replay-Attacke. War früher beliebt bei Funk-Autoschlüsseln...

Zitat von: A.Harrenberg am 25 November 2016, 20:16:31Hier hast Du mich abgehängt... Habe von Perl gar nicht so viel Ahnung, verstehe zwar das dies debugging ist, aber die Details?

Kennst Du das perl-Zusatzmodul Data::Dumper()?
Damit kann man sich beliebige perl-Datenstrukturen als Text darstellen lassen.
Sehr hilfreich für's Debugging.

Mit Hilfe von eval() kann man perl-Code aus einem String ausführen.
Die Idee ist, sobald der Expire-Timer feuert, jeweils Code von der Platte nachzuladen und ggf. um weitere Debug-Meldungen zu erweitern. Sonst müsste ich FHEM anhalten, den Code ändern und neu starten. Dann ist die Fehlersituation erstmal wieder weg und ich würde bis zu einer halben Stunde brauchen, um in die Fehlersituation zu kommen.

Viele Grüße
Thomas

Titel: Antw:UZB1 Stick: Lizenz schaltet AES Security frei?
Beitrag von: A.Harrenberg am 25 November 2016, 22:53:43

Hi,

Zitat von: buspirat am 25 November 2016, 21:19:53
alles korrekt, daß NONCE ist öffentlich verfügbar.

Was ich sagen wollten: Wir dürfen unter keinen Umständen alte NONCE-Werte akzeptieren, es darf nur das aktuelle gelten.

Sonst kann jemand hingehen und eine verschlüsselte Nachricht aufzeichnen und später wieder abspielen. Sowas nennt sich ein Replay-Attacke. War früher beliebt bei Funk-Autoschlüsseln...

wenn die NONCE genutzt wurde wird sie ja gelöscht, theoretisch müsste man da noch einen Timer einbauen das die NONCE nicht länger als z.B. 2 sekunden gültig ist. In der Spec sind (ähnliche) Timer für die Kommunikation vorgesehen.

Zitat von: buspirat am 25 November 2016, 21:19:53
Kennst Du das perl-Zusatzmodul Data::Dumper()?
Damit kann man sich beliebige perl-Datenstrukturen als Text darstellen lassen.
Sehr hilfreich für's Debugging.

Jetzt wo Du es erwähnst habe ich da mal was gelesen und das glaube ich sogar mal ausprobiert, werde ich mir noch mal anschauen. Danke für den Hinweis.

Zitat von: buspirat am 25 November 2016, 21:19:53
Mit Hilfe von eval() kann man perl-Code aus einem String ausführen.
Die Idee ist, sobald der Expire-Timer feuert, jeweils Code von der Platte nachzuladen und ggf. um weitere Debug-Meldungen zu erweitern. Sonst müsste ich FHEM anhalten, den Code ändern und neu starten. Dann ist die Fehlersituation erstmal wieder weg und ich würde bis zu einer halben Stunde brauchen, um in die Fehlersituation zu kommen.

Ok, es geht Dir also darum Debug Code ändern zu können ohne fhem neu zu starten. Ok, das wäre dann schon recht "advanced" ...

Musste gerade feststellen das der Wall-Controler von Popp zwar Security unterstützt, aber dennoch seine Tasten unverschlüsselt sendet. Damit kann ich zumindest die Kommunikation zum Multisensor nicht stören...

Gruß,
Andreas.

Titel: Antw:UZB1 Stick: Lizenz schaltet AES Security frei?
Beitrag von: buspirat am 25 November 2016, 23:25:16

Zitat von: A.Harrenberg am 25 November 2016, 22:53:43
Ok, es geht Dir also darum Debug Code ändern zu können ohne fhem neu zu starten. Ok, das wäre dann schon recht "advanced" ...

Hier ist jetzt dokumentiert wie es geht:
https://forum.fhem.de/index.php/topic,61436.0.html

Zitat von: A.Harrenberg am 25 November 2016, 22:53:43
Musste gerade feststellen das der Wall-Controler von Popp zwar Security unterstützt, aber dennoch seine Tasten unverschlüsselt sendet.

immerhin konnte man SECURITY ins Datenblatt schreiben 8)

ich denke das ein vollständiger Dump von $hash, sobald das Problem auftritt, uns ein sehr gutes Stück weiter bringen wird. Das dokumentiert den kompletten internen Zustand. Sobald es vorliegt werde ich es posten.

Weiß allerdings nicht ob ich das am WE schaffe, die Regierung hat auch noch Pläne für mich.

VG,
Thomas

Titel: Antw:UZB1 Stick: Lizenz schaltet AES Security frei?
Beitrag von: A.Harrenberg am 25 November 2016, 23:27:37

Hi,

keine Eile, meine freie Zeit ist momentan auch recht eingeschränkt...

Gruß,
Andreas.

Titel: Antw:UZB1 Stick: Lizenz schaltet AES Security frei?
Beitrag von: buspirat am 26 November 2016, 00:08:27

Kommunikationsfehler ist gerade aufgetreten:

So sieht der relevante Teil von $hash aus:

Code Auswählen


$VAR1 = {
        'secInProgress' => 1,
        'secStack' => [],
        'SendStack' => [
                        'sentset:13290a9880947ec5aad6a5ed80253c',
                        'set:13290a98808affa067a0c17d9e253d',
                        'set:13290a98809f6f2cff397deaf5253e',
                        'set:13290a98809a5afccb9609fc5a253f'
                        ],

        'isWakeUp' => 1,
};

Für jede NONCE-Anforderung kommt ein set:xxxxxxx im SendStack hinzu.
Ich tippe darauf, daß das "sentset" die Abarbeitung blockiert, da es auf ein ACK wartet?

Vorschlag, den ich auch gleich probieren werde:
ZWAVE_secEnd() bekommt ein "clear_sendstack" Flag.

ZWAVE_secUnlock() ruft das mit clear_sendstack=true auf und dann leeren wir neben dem "secStack" auch den kompletten "sendStack".

Weniger invasiv wäre alle "sentset" Anfrage aus dem "sendStack" zu entfernen,
aber ein komplettes Cleanup kann auch nicht schaden, um die Kommunikation wieder in geordnete Bahnen zu lenken.

Titel: Antw:UZB1 Stick: Lizenz schaltet AES Security frei?
Beitrag von: buspirat am 26 November 2016, 00:27:00

Hmm, eigentlich ist da bereits Code in Zwave_processSendStack(), der genau die "sentset" Nachricht aufräumen soll. Allerdings bei $ackType = "next".

Der Timer für $ackType = "next" wird jedoch an einer Codestelle nur gesetzt, wenn es kein WakeUp Device ist. Es handelt sich hier jedoch um ein Wakeup-Device.

Titel: Antw:UZB1 Stick: Lizenz schaltet AES Security frei?
Beitrag von: buspirat am 26 November 2016, 01:49:05

Anbei nochmal ein Log, der das Problem zeigt, daß fhem nicht mehr sendet.
Im process_SendStack habe ich das "pSS:" Debug-Logging vorher einkommentiert + einen Dump des Hashes eingebaut, sobald der Expire-Timer triggert.

Code Auswählen


2016.11.26 01:09:39 1: pSS: ZWave_SENSOR_NOTIFICATION_41, next set:13290a98809b37e545fa27dec9256d
2016.11.26 01:09:39 5: ZWDongle_Write 0013290a98809b37e545fa27dec9256d (ee557686)
2016.11.26 01:09:39 5: SW: 01110013290a98809b37e545fa27dec9256d48
2016.11.26 01:09:39 5: ACK received, WaitForAck=>2 for 01110013290a98809b37e545fa27dec9256d48
2016.11.26 01:09:39 4: ZWDongle_Read ZWDongle_0: rcvd 011301 (answer ZW_SEND_DATA), sending ACK
2016.11.26 01:09:39 5: SW: 06
2016.11.26 01:09:39 5: ZWDongle_0 dispatch 011301
2016.11.26 01:09:39 4: ZWDongle_Read ZWDongle_0: rcvd 000400291a9881f658fbdeaf196ed32d10d446af66dc6b8dfebe98f1fd6be6 (request APPLICATION_COMMAND_HANDLER), sending ACK
2016.11.26 01:09:39 5: SW: 06
2016.11.26 01:09:39 5: ZWDongle_0 dispatch 000400291a9881f658fbdeaf196ed32d10d446af66dc6b8dfebe98f1fd6be6
2016.11.26 01:09:39 4: CMD:APPLICATION_COMMAND_HANDLER ID:29 ARG:1a9881f658fbdeaf196ed32d10d446af66dc6b8dfebe98f1fd6be6 CB:00
2016.11.26 01:09:39 1: ZWave_SENSOR_NOTIFICATION_41: secDecrypt: Authentification code not verified, command 23c5f47c36b0 will be dropped!

2016.11.26 01:09:41 4: no response from device, removing 01110013290a98809b37e545fa27dec9256d48 from dongle sendstack

2016.11.26 01:09:42 4: ZWDongle_Read ZWDongle_0: rcvd 00040029029840 (request APPLICATION_COMMAND_HANDLER), sending ACK
2016.11.26 01:09:42 5: SW: 06
2016.11.26 01:09:42 5: ZWDongle_0 dispatch 00040029029840
2016.11.26 01:09:42 4: CMD:APPLICATION_COMMAND_HANDLER ID:29 ARG:029840 CB:00
2016.11.26 01:09:43 4: ZWDongle_Read ZWDongle_0: rcvd 0004001c055b03c40002 (request APPLICATION_COMMAND_HANDLER), sending ACK

2016.11.26 01:09:49 3: ZWave_SENSOR_NOTIFICATION_41: secStart older than 6 seconds detected, secUnlock will call Zwave_secEnd
2016.11.26 01:09:49 1: HASH DUMP in secUnlock before calling secEnd(): $VAR1 = {
          'lastMsgSent' => '1480118979.84631',
          'secStack' => [],
          'ZWaveSubDevice' => 'no',
          'ZWDongle_0_TIME' => '2016-11-26 01:09:45',
          'homeId' => 'ee557686',
          'secInProgress' => 1,
          'nodeIdHex' => '29',
          'ZWDongle_0_MSGCNT' => 1620,
          'secTime' => '1480118982.15724',
          'NR' => 80,
          'LASTInputDev' => 'ZWDongle_0',
          'READINGS' => {
                          'state' => {
                                       'VAL' => 'wakeupInterval 86400 1',
                                       'TIME' => '2016-11-25 23:32:02'
                                     },
                          'modelConfig' => {
                                             'TIME' => '2016-11-25 23:32:04',
                                             'VAL' => 'philio/pst02.xml'
                                           },
                          'timeToAck' => {
                                           'TIME' => '2016-11-26 01:09:39',
                                           'VAL' => '0.070'
                                         },
                          'transmit' => {
                                          'TIME' => '2016-11-26 01:09:45',
                                          'VAL' => 'NO_ACK'
                                        },
                          'luminance' => {
                                           'TIME' => '2016-11-26 01:09:35',
                                           'VAL' => '37 %'
                                         },
                          'alarm' => {
                                       'VAL' => 'AccessControl: Window/Door is closed',
                                       'TIME' => '2016-11-26 01:09:35'
                                     },
                          'temperature' => {
                                             'TIME' => '2016-11-26 01:09:35',
                                             'VAL' => '23.5 C'
                                           },
                          'model' => {
                                       'VAL' => 'Philio Technology Corporation PST02-A 4 in 1 Multi-Sensor',
                                       'TIME' => '2016-11-25 23:32:04'
                                     },
                          'battery' => {
                                         'VAL' => '90 %',
                                         'TIME' => '2016-11-26 01:09:35'
                                       },
                          'SECURITY' => {
                                          'TIME' => '2016-11-25 23:31:44',
                                          'VAL' => 'ENABLED'
                                        },
                          'UNPARSED' => {
                                          'TIME' => '2016-11-25 23:31:44',
                                          'VAL' => 'SECURITY 03980500'
                                        },
                          'send_nonce' => {
                                            'VAL' => 'dcfb932e3219dca7',
                                            'TIME' => '2016-11-26 01:09:42'
                                          },
                          'modelId' => {
                                         'TIME' => '2016-11-25 23:32:04',
                                         'VAL' => '013c-0002-000c'
                                       }
                        },
          'DEF' => 'ee557686 41',
          'isWakeUp' => 1,
          'ZWDongle_0_RAWMSG' => '00136d010214',
          'STATE' => 'wakeupInterval 86400 1',
          'secTimer' => {
                          'hash' => $VAR1
                        },
          'MSGCNT' => 1620,
          '.vclasses' => {},
          'SendStack' => [
                           'sentset:13290a98809b37e545fa27dec9256d',
                           'set:13290a9880dcfb932e3219dca7256e'
                         ],
          'NAME' => 'ZWave_SENSOR_NOTIFICATION_41',
          'TYPE' => 'ZWave'
        };

Was tatsächlich hilft ist in ZWAVE_secUnlock() den SendStack komplett zu löschen,
die Kommunikation erholt sich dann sofort. Das ist allerdings der Vorschlaghammer...

Titel: Antw:UZB1 Stick: Lizenz schaltet AES Security frei?
Beitrag von: A.Harrenberg am 26 November 2016, 10:26:37

Hi,

Zitat von: buspirat am 26 November 2016, 01:49:05
Anbei nochmal ein Log, der das Problem zeigt, daß fhem nicht mehr sendet.
Im process_SendStack habe ich das "pSS:" Debug-Logging vorher einkommentiert + einen Dump des Hashes eingebaut, sobald der Expire-Timer triggert.

Du bist ja ganz schön aktiv ,-)

Ich denke das der Auslöser für das Verhalten einen Schritt vor dem Log liegt... Ich versuche das mal aufzudröseln und zu kommentieren:

Code Auswählen


2016.11.26 01:09:39 1: pSS: ZWave_SENSOR_NOTIFICATION_41, next set:13290a98809b37e545fa27dec9256d
2016.11.26 01:09:39 5: ZWDongle_Write 0013290a98809b37e545fa27dec9256d (ee557686)
2016.11.26 01:09:39 5: SW: 01110013290a98809b37e545fa27dec9256d48

Hier wird eine NONCE gesendet <b37e545fa27dec92> (d.h. sie fängt mit <b3> an, das erste Byte wird im verschlüsselten Packet noch mal wieder mit zurückgeschickt, das kommt gleich...)

Code Auswählen


2016.11.26 01:09:39 4: ZWDongle_Read ZWDongle_0: rcvd 000400291a9881f658fbdeaf196ed32d10d446af66dc6b8dfebe98f1fd6be6 (request APPLICATION_COMMAND_HANDLER), sending ACK
2016.11.26 01:09:39 5: SW: 06
2016.11.26 01:09:39 5: ZWDongle_0 dispatch 000400291a9881f658fbdeaf196ed32d10d446af66dc6b8dfebe98f1fd6be6
2016.11.26 01:09:39 4: CMD:APPLICATION_COMMAND_HANDLER ID:29 ARG:1a9881f658fbdeaf196ed32d10d446af66dc6b8dfebe98f1fd6be6 CB:00
2016.11.26 01:09:39 1: ZWave_SENSOR_NOTIFICATION_41: secDecrypt: Authentification code not verified, command 23c5f47c36b0 will be dropped!

Jetzt kommt die verschlüsselte Nachricht an, hier wird aber auf eine andere NONCE referenziert, daher stimmt die Authentifizierung nicht...
1a9881f658fbdeaf196ed32d10d446af66 dc 6b8dfebe98f1fd6be6
^^ Kennung der genutzen NONCE ist <dc>

Der Befehl wird weggeworfen, und an dieser Stelle mache ich eventuell schon einen Fehler, hier müsste(n) die "sent NONCE" schon mal aufgeräumt werden, das muss ich mal prüfen ob die das mache oder übersehen habe. Gedachtes Vorgehen ist ja:
- Geräte will was senden und fragt nach einer NONCE
- NONCE wird generiert, gesendet und gespeichert
- Gerät schickt verschlüsselte Nachricht und wird mit der gespeicherten NONCE entschlüsselt bzw. authentifiziert
- gespeicherte NONCE wird entfernt und die nächste Kommunikation kann beginnen

Ist hierfür aber denke ich nicht relevant, Problem liegt wohl eher im Handling vom Stack...

Code Auswählen


2016.11.26 01:09:41 4: no response from device, removing 01110013290a98809b37e545fa27dec9256d48 from dongle sendstack

Keine Antwort auf das Senden der <b3> NONCE...

Code Auswählen


2016.11.26 01:09:42 4: ZWDongle_Read ZWDongle_0: rcvd 00040029029840 (request APPLICATION_COMMAND_HANDLER), sending ACK

Hier wird noch mal nach einer neuen NONCE gefragt, im Log ist aber kein Senden der Nonce enthalten.

Code Auswählen


2016.11.26 01:09:49 3: ZWave_SENSOR_NOTIFICATION_41: secStart older than 6 seconds detected, secUnlock will call Zwave_secEnd

Timer expired und der schöne Data::Dump ;-)

Hier gibt es jetzt zwei, bzw. sogar drei Auffälligkeiten für mich, die das ganze aber etwas erklären, aber natürlich neue Fragen aufwerfen.

Code Auswählen


                          'UNPARSED' => {
                                          'TIME' => '2016-11-25 23:31:44',
                                          'VAL' => 'SECURITY 03980500'
                                        },
                          'send_nonce' => {
                                            'VAL' => 'dcfb932e3219dca7',
                                            'TIME' => '2016-11-26 01:09:42'
                                          },
          'SendStack' => [
                           'sentset:13290a98809b37e545fa27dec9256d',
                           'set:13290a9880dcfb932e3219dca7256e'
                         ],

Auffälligkeiten:

Es gibt einen UNPARSED Eintrag für 03980500, das ist die Bestätigung des Gerätes das S0 Security mit "Scheme 0" genutzt wird. Mir ist völlig unklar wie das in UNPARSED landen kann, das wird während der Inklusion genutzt und der Empfang der Nachricht wird mMn auch für den Ablauf der Inklusion genutzt. Muss ich mir auch noch mal anschauen, ist hier aber nur Nebenschauplatz.
Bei der send_nonce geht jetzt wirklich was durcheinander... Hier ist die <dc> Nonce als "gültige" versendete NONCE eingetragen, allerdings passt der Zeitstempel zu dem zweiten Request um 01:09:42 der aber nie wirklich gesendet wurde.
Auf dem Stack kann man das ganze auch noch mal sehen: Die Antwort auf die <b3> NONCE kommt nicht, deswegen "verhungert" der SentStack -> eigentlich müsste hier der Stack aufgeräumt werden da ja erkannt wurde das keine Antwort kam. Als nächster liegt die <dc> NONCE auf dem Stack, die aber nciht gesendet wird weil der Stack hängt. Hier ist für mich jetzt aber das größte Fragezeichen! Wenn die <dc> NONCE ja nun noch gar nicht gesendet wurden, wie kann das Geräte dann auf eine <dc> NONCE verweisen? Es könnte natürlich Zufall sein das genau vorher eine NONCE mit <dc> verschickt wurde.

Um das weiter zu analysieren wäre es gut wenn Du etwas mehr von dem Log posten könntest damit ich mir die "Vorgeschichte" noch mal anschauen kann. (Für weitere Tests würde ich Dich bitten unter global das Attribut mseclog=1 zu setzen, dann werden auch millisekunden angezeigt).

Ich schau mir die Generierung der NONCE noch mal an, und würde das dann dort zum Testen mal so ändern das das erste Byte der NONCE fortlaufend nummeriert wird, dann kann man recht einfach erkennen wann welche NONCE erzeugt bzw. genutzt wird.

Dann muss ich mir noch mal die ganzen Stacks (sec-Stack, WU-Stack. send-Stack, Dongle send-Stack) anschauen um zu verstehen wieso die <b3> Nachricht nicht weggeräumt wird und wie das so die Interaktion läuft. Dabei kriege ich aber regelmäßig einen Knoten im Hirn ::)
Du hast ja da anscheinend schon eine Sonderbehandlung für die WU-Geräte gefunden die das erklären könnte.

Zitat von: buspirat am 26 November 2016, 01:49:05
Was tatsächlich hilft ist in ZWAVE_secUnlock() den SendStack komplett zu löschen,
die Kommunikation erholt sich dann sofort. Das ist allerdings der Vorschlaghammer...

Ja, Vorschlaghammer hilft immer, aber das setzt ja nur am Symptom und nicht an der Ursache an, wobei das natürlich auch für mein secUnlock() gilt! Ich dachte aber auch das mit den letzten Änderungen das secUnlock() nicht mehr nötig sein sollte...

Gruß,
Andreas.

Titel: Antw:UZB1 Stick: Lizenz schaltet AES Security frei?
Beitrag von: buspirat am 26 November 2016, 11:22:23

Vielen Dank für die Analyse! Während ich relativ gut programmieren kann, kenne ich leider die Details des Z-Wave Funkstandards noch nicht. Deine Analyse ist sehr hilfreich!

Habe gestern vor dem Test die Logdatei geleert und fhem neu gestartet.
Die vollständige Logdatei ist per E-Mail raus, unkomprimiert sind es 3,4MB.

Das Attribut mseclog=1 ist jetzt gesetzt. Sag Bescheid, falls ich den Fehler nochmal provozieren soll.

Die Komplexität mit SECURITY ist auch, daß es an ein paar Stellen den SendStack umgeht, z.B. um die NONCE zeitnah und nicht erst nach einem Wakeup-Event zu verschicken ;D Dann gibt es noch zig Timer die irgendwo werklen usw.

Titel: Antw:UZB1 Stick: Lizenz schaltet AES Security frei?
Beitrag von: A.Harrenberg am 26 November 2016, 17:21:44

Hi,

Zitat von: buspirat am 26 November 2016, 11:22:23
Die Komplexität mit SECURITY ist auch, daß es an ein paar Stellen den SendStack umgeht, z.B. um die NONCE zeitnah und nicht erst nach einem Wakeup-Event zu verschicken ;D Dann gibt es noch zig Timer die irgendwo werklen usw.

ja, ein WU-Gerät verschickt auch ohne WU-Notification seine Werte und wenn das unter Security geschieht dann schläft das Gerät für fhem, und dann darf die NONCE nicht auf dem WU-Stack liegenbleiben.

Die Interaktionen zwischen den ganzen Stacks und den Timern ist mittlerweile wirklich recht hoch, ich sage ja, jedesmal wenn ich damit anfange kriege ich einen Knoten im Hirn.

Jetzt schaue ich aber mal in Dein Logfile rein, mal sehen was dabei rauskommt.

Gruß,
Andreas.

Titel: Antw:UZB1 Stick: Lizenz schaltet AES Security frei?
Beitrag von: A.Harrenberg am 26 November 2016, 22:10:08

Hallo,

so, habe jetzt mal einen Teil des Logs durchgeschaut, ist schon ein ziemlicher Stresstest für die Kommunikation was da abgeht...

Zu Anfang kommt die Kommunikation mal aus dem Tritt, fängt sich dann aber nach dem secUnlock() wieder. Prinzipiell passiert das folgende: (irgendwann habe ich mal das NONCE request weggelassen)

Code Auswählen


NONCE request
<02> NONCE verschickt
<02> NONCE angekommen
SENSOR MULTILEVEL

NONCE request
<ae> NONCE verschickt
<ae> NONCE angekommen
SENSOR MULTILEVEL

NONCE request
<00> NONCE verschickt
<00> NONCE angekommen

*** jetzt kommen "Störungen" durch den KFOB

SCENE 2
SCENE 2
SCENE 2
SCENE 2
SCENE 2
SCENE 2

<00> NONCE wurde verschickt und Empfang wurde bestätigt, es kommt jedoch kein verchlüsseltes Packet an

2016.11.26 01:02:23 3: ZWave_SENSOR_NOTIFICATION_41: secStart older than 6 seconds detected, secUnlock will call Zwave_secEnd
				
*****
secUnlock
*****
				
NONCE request
<d0> NONCE verschickt
<d0> NONCE angekommen
SENSOR MULTILEVEL

NONCE request
<f4> NONCE verschickt
<f4> NONCE angekommen
SENSOR MULTILEVEL

Später kommt das ganze dann auch mal kurz aus dem Tritt, fängt sich wieder um dann aber für eine sehr lange Zeit asynchron zu laufen:

Code Auswählen


<cd> NONCE verschickt
<cd> NONCE angekommen
SENSOR MULTILEVEL

<1b> NONCE verschickt
*****
KEINE Bestätigung, aber neue Anforderung einer NONCE! Wahrscheinlich Übertragungsproblem des ACK in Richtung Sensor!
*****
<1b> NONCE angekommen ??

<db> NONCE verschickt
*****
verschlüsseltes Packet mit <1b> NONCE angekommen -> dropped da <db> NONCE aktuell ist!
*****

<db> NONCE angekommen
*****
verschlüsseltes Packet noch mal mit <1b> NONCE angekommen -> dropped da <db> NONCE aktuell war, aber entfernt wurde!
*****

<f0> NONCE verschickt
<f0> NONCE angekommen
BATTERY

<23> NONCE verschickt
<23> NONCE angekommen
ALARM

<83> NONCE verschickt
*****
(noch) KEINE Bestätigung
*****
BATTERY mit <83> NONCE

NONCE request
*****
<83> NONCE wird als angekommen markiert, ACK gehört aber wohl eher zum Empfangsbestätigung "NONCE request"
*****
<39> NONCE verschickt
<39> NONCE angekommen
<b2> NONCE verschickt
*****
verschlüsseltes Packet mit <83> NONCE angekommen -> dropped da <b2> NONCE aktuell ist!
Gar kein Paket mit <39> NONCE angekommen...
*****

<b2> NONCE angekommen
<4e> NONCE verschickt
*****
verschlüsseltes Packet mit <b2> NONCE angekommen -> dropped da <4e> NONCE aktuell ist!
*****

<4e> NONCE angekommen
<e7> NONCE verschickt
*****
verschlüsseltes Packet mit <4e> NONCE angekommen -> dropped da <e7> NONCE aktuell ist!
*****

<e7> NONCE angekommen
<3c> NONCE verschickt
*****
verschlüsseltes Packet mit <e7> NONCE angekommen -> dropped da <3c> NONCE aktuell ist!
*****

Das System kommt dabei in eine recht stabile asynchrone Kommunikation. Anscheinend sendet der Sensor eine neue Anforderung für eine NONCE nachdem wahrscheinlich das ACK nicht beim Sensor angekommen ist. Dadurch wird die aktuelle, bereits verschickte NONCE "weggeworfen" und eine neue erzeugt. Der Sensor nimmt aber die bereits verschickte NONCE um die Nachricht zu verschlüsseln. Die wird aber weggeworfen das die NONCE mittlerweile nicht mehr gültig ist. Die neue NONCE wird angefordert, die alte weggeworfen, der Sensor nutz die aber wieder zur Verschlüsseung und so weiter...

Es gibt hier meiner Meinung nach drei Probleme.

1.) Das versenden eine neuen NONCE während bereits eine verschickt wurde kann den ganzen Zirkus starten und sollte blockiert werden, das sollte auch recht einfach zu realisieren sein da es ja secStart()/secEnd() gibt die secInProgress setzen. Sollte es hier zu einem "Hänger" kommen sollte secUnlock() das nach 6 sekunden auflösen, es sollte aber keine asynchronen NONCE Kommunikationen mehr geben.

2.) Die Stacks sind ja "fire-and-forget", d.h. aus Applikationsicht ist der Befehl für micht versendet sobald ich den in den Stack geschoben habe. Ob der Stack klemmt kriege ich nicht direkt mit, was die Sache nicht einfacher macht. Ich habe aber auch keine Idee wie das Problem gelöst werden kann ohne das gesamte System unnötig mit Warten zu blockieren. Ich denke das wir damit leben müssen

3.) Der Sendstack klemmt irgendwie merkwürdig bzw. das System scheint für einige Zeit einzufrieren und nicht mehr zu loggen oder so. In der ersten Analyse ist mir aufgefallen das die NONCES im Stack bzw. in den Readings nicht zueinanderpassen.
Es gibt dort einen Ablauf mit:

Code Auswählen


<86> NONCE angekommen

<6b> NONCE verschickt
*****
verschlüsseltes Packet mit <86> NONCE angekommen -> dropped da <6b> NONCE aktuell ist!
*****
<6b> NONCE angekommen

<9b> NONCE verschickt
*****
verschlüsseltes Packet mit <6b> NONCE angekommen -> dropped da <9b> NONCE aktuell ist!
*****

*****
no response from device
<9b> NONCE message removing from sendstack
*****
*****
NO_ACK for sending <9b> NONCE

dann kommt das secUnlock() und in dem Dump findet sich:

'send_nonce' => {
'VAL' => 'dcfb932e3219dca7',
'TIME' => '2016-11-26 01:09:42'

und

'SendStack' => [
'sentset:13290a98809b37e545fa27dec9256d',
'set:13290a9880dcfb932e3219dca7256e'
],

Das passt nicht zu dem Log... die Nachricht mit der <9b> NONCE sollte ja berits vom Stack entfernt worden sein und es taucht ein Paket mit einer <dc> NONCE im Stack auf, die im Log bis dahin nicht aufgetaucht ist und auch danach nicht mehr kommt...

Im weiteren Verlauf sammeln sich die weiteren Nachrichten hinter der sentset <9b> NONCE message und der Stack ist blockiert...

Für 1.) schaue ich mal nach einem Fix, für 2.) gibt es wohl keine Lösung, aber bei 3.) bin ich völlig überfragt was dort passiert. Ich habe das Gefühl das hier die ACK Nachrichten nicht korrekt zugeordnet werden da anscheinend einige nicht übertragen wurden, das erklärt aber nicht warum die Nachricht die angeblich entfernt wurde noch auf dem Stack liegt und der Stack danach blockiert ist.

Gruß,
Andreas.

Titel: Antw:UZB1 Stick: Lizenz schaltet AES Security frei?
Beitrag von: A.Harrenberg am 26 November 2016, 22:29:01

Hi buspirat,

kannst Du mal versuchen die Function ZWave_secNonceRequestReceived () durch diese Variante zu ersetzen und das ganze noch mal zu provozieren?
Hier wird dann einfach der NONCE-Request ignoriert solange noch eine Kommunikation aktiv ist.

Code Auswählen


sub
ZWave_secNonceRequestReceived ($)
{
  my ($hash) = @_;
  if (!ZWave_secIsEnabled($hash) || !$hash->{secInProgress}) {
    Log3 $hash->{NAME}, 1, "$hash->{NAME}: dropped NONCE request due to "
                          ."actual communication still active";
    return;
  }
  ZWave_secStart($hash);
  ZWave_secAddToSendStack($hash, '98'.ZWave_secCreateNonce($hash));
}

Gruß,
Andreas.

Titel: Antw:UZB1 Stick: Lizenz schaltet AES Security frei?
Beitrag von: A.Harrenberg am 26 November 2016, 22:32:43

Hi,

grummel, die negierung war natürlich falsch...

Code Auswählen

sub
ZWave_secNonceRequestReceived ($)
{
  my ($hash) = @_;
  if (!ZWave_secIsEnabled($hash) || $hash->{secInProgress}) {
    Log3 $hash->{NAME}, 1, "$hash->{NAME}: dropped NONCE request due to "
                          ."actual communication still active";
    return;
  }
  ZWave_secStart($hash);
  ZWave_secAddToSendStack($hash, '98'.ZWave_secCreateNonce($hash));
}

Gruß,
Andreas.

Titel: Antw:UZB1 Stick: Lizenz schaltet AES Security frei?
Beitrag von: buspirat am 27 November 2016, 10:26:33

Hi Andreas,

die Code-Änderung in ZWave_secNonceRequestReceived() kann ich gerne ausprobieren.
Bis jetzt hat sich der SendStack nicht mehr erholt und ist mehrere Bildschirmseiten lang.
Die WUN will vermutlich auch vorher eine NONCE... ich starte jetzt fhem neu.

Zitat von: A.Harrenberg am 26 November 2016, 22:10:08
dann kommt das secUnlock() und in dem Dump findet sich:

'send_nonce' => {
'VAL' => 'dcfb932e3219dca7',
'TIME' => '2016-11-26 01:09:42'

und

'SendStack' => [
'sentset:13290a98809b37e545fa27dec9256d',
'set:13290a9880dcfb932e3219dca7256e'
],

Das passt nicht zu dem Log... die Nachricht mit der <9b> NONCE sollte ja berits vom Stack entfernt worden sein und es taucht ein Paket mit einer <dc> NONCE im Stack auf, die im Log bis dahin nicht aufgetaucht ist und auch danach nicht mehr kommt...

mir war auch aufgefallen, daß die Nachricht "13290a98809b37e545fa27dec9256d" eigentlich weg sein müsste und danach wieder im Dump zu finden war. Hier gibt es für mich nur drei Erklärungsmöglichkeiten:

1. die Nachricht lag doppelt auf dem Stack
2. sie wurde nicht aus dem SendStack-Array entfernt.
Wenn man sich ZWDongle_shiftSendStack() ansieht kann das eigentlich nicht sein,
erst recht nicht nachdem die Logmeldung aufgetaucht ist.

Evtl. ein extrem unwahrscheinlicher perl-Bug, würde ich jedoch erstmal ausschließen.

3. Es wurde auf einer Kopie vom SendStack / $hash Objekt gearbeitet.
Das entspricht dann in etwa 1.

Ich tippe darauf, daß über irgendeinen verschlungenen Code-Pfad die gleiche Nachricht doppelt auf den Stack gelegt wurde. Anders kann ich mir das nicht erklären.

Bevor ich Deine Code-Änderung mit der NONCE reinmachen würde,
hatte ich noch folgende Idee:

- in 00_ZWDongle.pm in der Funktion ZWDongle_shiftSendStack($$$$;$)

vor

shift @{$ss};

ein

if ($txt != "device ack reveived") # PseudoCode. $txt hat Tippfehler im Code
Log Data::Dumper($ss)

- wie von Dir angedacht die NONCE-Generierung zu einem linearen Zähler umbauen.
Wie war das, nur das erste Byte wird im Klartext geloggt?

Dann müsste man irgendwie an den großen Stelle der Zahl hochzählen.
Weiß nicht ob sich das lohnt, wenn nur ein Byte geloggt wird,
dann sind die 255 möglichen Funktelegramme sehr schnell aufgebraucht
bis der Fehler auftritt. Es sei denn, man zählt dann wieder von vorne.
Müsste eigentlich möglich sein.

Fazit: Das bestehende Verhalten erstmal nicht verändern, sondern nur um zusätzliches Logging erweitern. Ich will den Bug fangen :)

Vermutlich werde ich erst in zwei Tagen wieder daran arbeiten können.

Titel: Antw:UZB1 Stick: Lizenz schaltet AES Security frei?
Beitrag von: A.Harrenberg am 27 November 2016, 10:47:04

Hi,

Zitat von: buspirat am 27 November 2016, 10:26:33
die Code-Änderung in ZWave_secNonceRequestReceived() kann ich gerne ausprobieren.
Bis jetzt hat sich der SendStack nicht mehr erholt und ist mehrere Bildschirmseiten lang.
Die WUN will vermutlich auch vorher eine NONCE... ich starte jetzt fhem neu.

wenn Dir Deine Batterien lieb sind solltest Du das nicht sooo lange laufen lassen, das Ding sendet ja quasi ununterbrochen...

Die WUN braucht keine NONCE, die ist unverschlüsselt, aber die regelmäßigen Werte wie BATTERY brauchen eine, die ALARM Meldung natürlich auch. Solche Meldungen kommen auch VOR der WUN...

Zitat von: buspirat am 27 November 2016, 10:26:33
mir war auch aufgefallen, daß die Nachricht "13290a98809b37e545fa27dec9256d" eigentlich weg sein müsste und danach wieder im Dump zu finden war. Hier gibt es für mich nur drei Erklärungsmöglichkeiten:

1. die Nachricht lag doppelt auf dem Stack

glaube ich eher nicht, dann hätte sie zwei mal als "ZWDonge_write" bzw. "SW:" auftauchen müssen. Sie ist ja als versendet gekennzeichnet.

Zitat von: buspirat am 27 November 2016, 10:26:33
2. sie wurde nicht aus dem SendStack-Array entfernt.
Wenn man sich ZWDongle_shiftSendStack() ansieht kann das eigentlich nicht sein,
erst recht nicht nachdem die Logmeldung aufgetaucht ist.

Evtl. ein extrem unwahrscheinlicher perl-Bug, würde ich jedoch erstmal ausschließen.

Was soll ich sagen, ich verstehe es ja auch nicht....

Zitat von: buspirat am 27 November 2016, 10:26:33
3. Es wurde auf einer Kopie vom SendStack / $hash Objekt gearbeitet.
Das entspricht dann in etwa 1.

Wüsste nicht wie das passieren sollte...

Zitat von: buspirat am 27 November 2016, 10:26:33
Ich tippe darauf, daß über irgendeinen verschlungenen Code-Pfad die gleiche Nachricht doppelt auf den Stack gelegt wurde. Anders kann ich mir das nicht erklären.

Glaube ich eher nicht. Ich hätte eher die diversen Timer in Hintergrund im Verdacht das da einer genau zu einer unpassenden Zeit zugeschlagen hat der Ablauf dann doch nicht so war wie geplant. Dazu müsste ich da aber mal sehr genau reinschauen oder Rudi kann hier behilflich sein.

Zitat von: buspirat am 27 November 2016, 10:26:33
Bevor ich Deine Code-Änderung mit der NONCE reinmachen würde,
hatte ich noch folgende Idee:

- in 00_ZWDongle.pm in der Funktion ZWDongle_shiftSendStack($$$$;$)

vor

shift @{$ss};

ein

if ($txt != "device ack reveived") # PseudoCode. $txt hat Tippfehler im Code
Log Data::Dumper($ss)

dagegen spricht ja nichts

Zitat von: buspirat am 27 November 2016, 10:26:33
- wie von Dir angedacht die NONCE-Generierung zu einem linearen Zähler umbauen.
Wie war das, nur das erste Byte wird im Klartext geloggt?

Dann müsste man irgendwie an den großen Stelle der Zahl hochzählen.
Weiß nicht ob sich das lohnt, wenn nur ein Byte geloggt wird,
dann sind die 255 möglichen Funktelegramme sehr schnell aufgebraucht
bis der Fehler auftritt. Es sei denn, man zählt dann wieder von vorne.
Müsste eigentlich möglich sein.

Die NONCE sind wie gesagt mehr oder weniger "öffentlich", ob die nun im Klartext geloggt werden oder nicht ist ziemlich egal.
Das erste Byte der gesendeten NONCE wird in der verschlüsselten Antwort noch mal wieder mit zurückgesendet damit man die "richtige" NONCE zum Entschlüsseln wiederfinden kann. Das ist aber eigentlich nur interessant wenn man das ganze an zentraler Stelle für mehrere Geräte macht. Für ein einzelnes Gerät darf es immer nur eine aktive Kommunikation geben und selbst für den Dongle gibt es da Einschränkungen.
Daher ist das erste Byte der gesendeten NONCE hier interessant. Und den Zähler kann man ja ohne weiteres "rollen" lassen, wenn der nach 255 Packeten wieder bei 0 anfängt macht das ja nichts.

Zitat von: buspirat am 27 November 2016, 10:26:33
Fazit: Das bestehende Verhalten erstmal nicht verändern, sondern nur um zusätzliches Logging erweitern. Ich will den Bug fangen :)

Ok, aber es wäre schön wenn Du dennoch mal probieren könntest ob die Änderungen denn auch im jetzigen Zustand helfen würde.

Gruß,
Andreas.

Titel: Antw:UZB1 Stick: Lizenz schaltet AES Security frei?
Beitrag von: buspirat am 01 Dezember 2016, 23:42:18

Hi Andreas,

Zitat von: A.Harrenberg am 27 November 2016, 10:47:04
Hi,wenn Dir Deine Batterien lieb sind solltest Du das nicht sooo lange laufen lassen, das Ding sendet ja quasi ununterbrochen...

ich wollte herausfinden, ob er z.B. nach 24h sich von alleine erholt. War leider nicht so, der klemmt komplett.

Zitat von: A.Harrenberg am 27 November 2016, 10:47:04
Was soll ich sagen, ich verstehe es ja auch nicht....
Wüsste nicht wie das passieren sollte...
Glaube ich eher nicht. Ich hätte eher die diversen Timer in Hintergrund im Verdacht das da einer genau zu einer unpassenden Zeit zugeschlagen hat der Ablauf dann doch nicht so war wie geplant. Dazu müsste ich da aber mal sehr genau reinschauen oder Rudi kann hier behilflich sein.

sieht mir irgendwie nach einem indirekten Ablauf aus. Ich habe ZWDongle_shiftSendStack() wie angedacht umgebaut und der SendStack ist eigentlich komplett leer und dann kommt der Fehler.

Wilde Theorie: Das Paket wird vom SendStack entfernt und kurz darauf wird das "sentXXXX" dennoch auf den Stack gelegt, obwohl die Bearbeitung des Anfrage eigentlich nicht geklappt hat.
Aus dem Bauch heraus würde ich tippen, daß das Einfügen von "sentXXX" die Fehlersituation nicht erkennt oder richtig überprüft.

Die Generierung der NONCE sieht jetzt so aus:

Code Auswählen


my $global_nonce_counter=0;
sub
ZWave_secGetNonce()
{
  my $nonce=sprintf "%02x", $global_nonce_counter;
  for (my $i = 0; $i <7; $i++) {
    $nonce .= sprintf "%02x",int(rand(256));
  }

  $global_nonce_counter++;
  if ($global_nonce_counter == 255) {
    $global_nonce_counter=0;
  }
  Log 1, "DEBUG: Computed NONCE: $nonce";

  return $nonce;
}

ZWDongle_shiftSendStack() hat auch Debug-Code bekommen:

Code Auswählen


    my $debug_dump_hash=0;
    if ($txt && $txt ne "device ack reveived" && $txt ne "ACK received") {
      $debug_dump_hash=1;
    }

    if ($debug_dump_hash)
    {
       Log 1, "DEBUG: Dumping hash in ZWDongle_shiftSendStack: ".Dumper($hash);
    }

    shift @{$ss};
    if ($debug_dump_hash)
    {
       Log 1, "DEBUG: SendStack after shift (txt: $txt): ".Dumper($ss);
    }

    Log3 $hash, $loglevel, "$txt, removing $cmd from dongle sendstack"
        if($txt && $cmd);

Der vorherige Data::Dumper() Aufruf im secUnlock ist weiterhin vorhanden.

Zitat von: A.Harrenberg am 27 November 2016, 10:47:04
Die NONCE sind wie gesagt mehr oder weniger "öffentlich", ob die nun im Klartext geloggt werden oder nicht ist ziemlich egal.

das Logging aus Sicherheitsgründen hatte ich bei meiner Aussage gar nicht im Sinn, sonder nur wieviele Bytes im Klartext bei der Antwort zurückgeschickt werden. Du hast meine Frage perfekt beantwortet. Danke :)
NONCE is eigentlich bei fast allen Kryptoprotokollen im Klartext.

Zitat von: A.Harrenberg am 27 November 2016, 10:47:04
Ok, aber es wäre schön wenn Du dennoch mal probieren könntest ob die Änderungen denn auch im jetzigen Zustand helfen würde.

werde ich morgen oder übermorgen auf jeden Fall machen. Dauert manchmal bis ich den Fehler erwische.

Neue Logdatei ist an Dich per E-Mail raus. Hoffentlich hilft die lineare NONCE beim Debuggen.

Viele Grüße
Thomas

Titel: Antw:UZB1 Stick: Lizenz schaltet AES Security frei?
Beitrag von: A.Harrenberg am 03 Dezember 2016, 14:53:32

Hi,

habe mir das neue Log mal angesehen, aber leider nicht mehr daraus gelernt...

Zu Anfang des Logs gibt es einen Fall wo das secUnlock() aufgerufen wird, das ist aber richtig (und gut) so. Es wurde eine NONCE verschickt, dann kamen etliche Nachrichten von der Fernbedienung und der Sensor hat nichts geschickt.

Ich habe dann mal das Log von "hinten" anscheschaut, das waren aber ein paar tausend Zeilen die ich dazu durchgeackert habe um den interessanten Teil zu finden... ,-(
Ich habe den Ablauf hier mal vereinfacht dargestellt, wenn nur eine hexzahl genannt ist wurde die entsprechende NONCE verschickt (SW:...), hexzahl + "ok" bedeutet das fhem ein ACK vom Device bekommen hat und das vom Stack genommen hat (device ack reveived, removing ... from dongle sendstack). Ansonsten habe ich die Klassen der angekommenen Nachrichten reingeschrieben.

Das hier ist der Anfang des Problems. Auf das Versenden der "af" NONCE gab es zwar ein ACK, es wird aber eine neue NONCE angefordert. Hier ist es wahrscheinlich zu einem Übertragungsproblem gekommen und es ist auf einer Seite ein ACK nicht angekommen...
Es kommen dann trotz ACK auf die versendete NONCE noch weitere NONCE-Request bis zum Versenden der NONCE "b2". Es kommt dann jedoch ein Paket mit der ursprunglichen "af" NONCE das natürlich als ungültig weggeworfen wird.

Code Auswählen


BATTERY
ac
ac ok
ALARM
ad
ad ok
SENSOR_MULTILEVEL
ae
ae ok
BATTERY
af
af ok
*****
noch kein verschlüsseltes Paket erhalten, neue Anfrge nach NONCE
*****
b0
b0 ok
*****
noch kein verschlüsseltes Paket erhalten, neue Anfrge nach NONCE
*****
b1
b1 ok
*****
noch kein verschlüsseltes Paket erhalten, neue Anfrge nach NONCE
*****
b2
*****
Paket mit NONCE af angekommen -> b2 ist aktiv! NONCE b0, b1, b2 "zwischenzeitlich erzeugt"
*****

Danach beginnt dann das bekannte asynchrone Spiel, "b2" NONCE wird bestätigt, "b3" NONCE wird erzeugt/verschickt, Paket kommt mit b2 NONCE an wird weggeworfen und so weiter...
Es kommen auch noch ein paar CAN dazu, die haben aber mMn. keinen Einfluß auf den Ablauf. An einer Stelle sind die NONCES sogar synchron, aber es werden wieder zwei NONCE hintereinander angefordert und das es ist gleich wieder asynchron..

Code Auswählen


CENTRAL_SCENE
b2 ok
b3
Dongle ACK für b3
NONCE request (b4)
*****
Paket mit NONCE b2 angekommen -> b3 ist aktiv!
*****
NONCE request (b5)
b3 ok
b4
*****
Paket mit NONCE b3 angekommen -> b4 ist aktiv
*****
CENTRAL_SCENE
NONCE request (b6)
b4 ok
b5
*****
Paket mit NONCE b4 angekommen -> b5 ist aktiv
*****
NOCE request (b7)
b5 ok
b6
*****
Paket mit NONCE b5 angekommen -> b6 ist aktiv
*****
*****
Paket mit NONCE b5 (noch mal) angekommen -> b6 ist aktiv, aber keine NONCE mehr vorhanden...
*****
b6 ok
b7
b7 ok
b8
CAN received (for b8?)
NONCE request (b9)
no ACK for b8
b8 erneut versendet (wg. CAN)
b8 ok
b9
*****
Paket mit NONCE b6 angekommen -> b9 ist aktiv
*****
CAN received (for b9?)
NONCE request (ba)
no ACK for b9
b9 erneut versendet (wg. CAN)
Dongle ACK b9
CENTRAL_SCENE
b9 ok
ba
*****
Paket mit NONCE b9 angekommen -> ba ist aktiv
*****
NONCE request (bb)
ba ok
bb
*****
Paket mit NONCE ba angekommen -> bb ist aktiv
*****
NONCE request (bc)
bb
bc
*****
Paket mit NONCE bb angekommen -> bc ist aktiv
*****
CENTRAL_SCENE
NONCE request (bd)
bc ok
bd
*****
Paket mit NONCE bc angekommen -> bd ist aktiv
*****
bd ok
be
Dongle ACK
NONCE request (bf)
CENTRAL_SCENE
be ok
bf
Dongle ACK
NONCE request (c0)
CENTRAL_SCENE
*****
Paket mit NONCE bd angekommen -> c0 ist aktiv
*****
NONCE request (c1)
CENTRAL_SCENE
CENTRAL_SCENE
CENTRAL_SCENE
bf ok
c0
Dongle ACK
*****
Paket mit NONCE bf angekommen -> c0 ist aktiv
*****
c0 ok
c1
Dongle ACK
NONCE request (c2)
*****
Paket mit NONCE c0 angekommen -> c2 ist aktiv
*****
NONCE request (c3)
CENTRAL_SCENE
c1 ok
c2
*****
Paket mit NONCE c1 angekommen -> c2 ist aktiv
*****
NONCE request (c4)
CENTRAL_SCENE
c2 ok
c3
*****
Paket mit NONCE c2 angekommen -> c3 ist aktiv
*****
NONCE request (c5)
c3 ok
c4
*****
Paket mit NONCE c3 angekommen -> c4 ist aktiv
*****
NONCE request (c6)
c4 ok
c5
*****
Paket mit NONCE c4 angekommen -> c5 ist aktiv
*****
NONCE request (c7)
c5 ok
c6
c6 ok
c7
NONCE request (c8)
c7 ok
c8
*****
Paket mit NONCE c5 angekommen -> c8 ist aktiv
*****
CENTRAL_SCENE
NONCE request (c9)
c8 ok
c9
*****
Paket mit NONCE c8 angekommen -> c9 ist aktiv
*****
c9 ok
ca
*****
Paket mit NONCE c9 angekommen -> ca ist aktiv
*****
ca ok
cb
*****
Paket mit NONCE ca angekommen -> cb ist aktiv
*****
cb ok
*****
Paket mit NONCE ca NOCHMAL angekommen -> cb ist aktiv, keine NONCE vorhanden
*****
cc
CENTRAL_SCENE
CAN received (for cc?)
CENTRAL_SCENE
no ACK for cc
cc erneut versendet (wg. CAN)
CENTRAL_SCENE
cc ok
*****
Paket mit passender NONCE cc angekommen, Ablauf sollte jetzt wieder stimmen...
*****
cd
NONCE request (ce)
CENTRAL_SCENE
cd ok
ce
*****
Paket mit NONCE cd angekommen -> ce ist aktiv, Ablauf wieder gestört...
*****
*****
Paket mit NONCE cd noch mal angekommen -> ce ist aktiv
*****
NONCE request (cf)
ce ok
cf

Im letzten Teil kommt es dann zu einem no response was ein ZWDongle_shiftSendStack auslöst, hier liegt die zuletzt verschickte "d1" NONCE noch auf dem Stack (und sollte mMn. auch entfernt werden)
Dann kommen wieder jede Menge Signale von der Fernbedienung und ein no ACK für die d1 NONCE.
Dann kommt ein neuer NONCE request (d2), die Nonce wird aber letztendlich nicht gesendet da der Stack klemmt.
Nach Ablauf des Timers wird SecUnlock aufgerufen, d1-NONCE und d2-NONCE liegen auf dem Stack,
Nächster NONCE-request (d3), selbes Spiel, danach liegen d1,d2,d3-NONCE auf dem Stack.

Code Auswählen


*****
Paket mit NONCE ce angekommen -> cf ist aktiv
*****
CENTRAL_SCENE
NONCE request (d0)
cf ok
d0
*****
Paket mit NONCE cf angekommen -> d0 ist aktiv
*****
NONCE request (d1)
CENTRAL_SCENE
d0 ok
d1
*****
Paket mit NONCE d0 angekommen -> d1 ist aktiv
*****
CENTRAL_SCENE
CENTRAL_SCENE
CENTRAL_SCENE
CENTRAL_SCENE
(was hat an dieser Stelle ZWDongle_shiftSendStack ausgelöst, no response?)
d1 NONCE liegt auf SendStack
2016.12.01 22:24:54 1: DEBUG: Dumping hash in ZWDongle_shiftSendStack: $VAR1 = {
*****				
'SendStack' => [
								 '011100132c0a9880d123839fb30c495f25d273'
							 ],				
*****
2016.12.01 22:24:54 1: DEBUG: SendStack after shift (txt: no response from device): $VAR1 = [];
2016.12.01 22:24:54 4: no response from device, removing 011100132c0a9880d123839fb30c495f25d273 from dongle sendstack
no response
CENTRAL_SCENE
CENTRAL_SCENE
CENTRAL_SCENE
CENTRAL_SCENE
CENTRAL_SCENE
CENTRAL_SCENE
CENTRAL_SCENE
CENTRAL_SCENE
CENTRAL_SCENE
CENTRAL_SCENE
CENTRAL_SCENE
CENTRAL_SCENE
CENTRAL_SCENE
CENTRAL_SCENE
CENTRAL_SCENE
CENTRAL_SCENE
CENTRAL_SCENE
CENTRAL_SCENE
CENTRAL_SCENE
CENTRAL_SCENE
CENTRAL_SCENE
CENTRAL_SCENE
CENTRAL_SCENE
CENTRAL_SCENE
CENTRAL_SCENE
CENTRAL_SCENE
CENTRAL_SCENE
CENTRAL_SCENE
CENTRAL_SCENE
CENTRAL_SCENE
CENTRAL_SCENE
CENTRAL_SCENE
CENTRAL_SCENE
CENTRAL_SCENE
CENTRAL_SCENE
CENTRAL_SCENE
CENTRAL_SCENE
CENTRAL_SCENE
CENTRAL_SCENE
no ACK for CB:d2 -> 2016.12.01 22:24:52 5: SW: 011100132c0a9880d123839fb30c495f25d273
CENTRAL_SCENE
CENTRAL_SCENE
CENTRAL_SCENE
CENTRAL_SCENE
NONCE request (d2)
*****
secUnlock, d2 NONCE wurde nicht geschrieben
2016.12.01 22:25:34 1: HASH DUMP in secUnlock before calling secEnd(): $VAR1 = {
*****
*****				
 'sentset:132c0a9880d123839fb30c495f25d2',
 'set:132c0a9880d24c2ec20d99ed8625d3'				
*****
NONCE request (d3)
2016.12.01 22:25:42 3: ZWave_SENSOR_NOTIFICATION_44: secStart older than 6 seconds detected, secUnlock will call Zwave_secEnd
*****
secUnlock, d2 NONCE wurde nicht geschrieben
2016.12.01 22:25:42 1: HASH DUMP in secUnlock before calling secEnd(): $VAR1 = {
*****
*****				
'sentset:132c0a9880d123839fb30c495f25d2',
'set:132c0a9880d24c2ec20d99ed8625d3',
'set:132c0a9880d3147bc03a3d8e3125d4'
*****

Es scheint das bei dem ZWDongle_shiftSendStack Aufruf was schief läuft und der Befehl nicht vom Stack entfernt wird. Ich war eigentlich der Meinung das im Hintergrund auch ein Timer werkelt der dort aufräumt, evtl. kommt auch Timer aus dem Tritt...

Mein resumeé ist momentan folgendes:
- die gesendeten NONCE in einer Liste aufbewaren
- nur neue NONCE erzeugen die sich in der ersten Stelle unterscheiden um eindeutig zu bleiben
- benutzte NONCE aus der Liste entfernen
- über time alte, unbenutze NONCE aus der Liste entfernen

Den Fehler im Ablauf mit dem Stack müssen wir irgendwie anders finden.

Gruß,
Andreas

Titel: Antw:UZB1 Stick: Lizenz schaltet AES Security frei?
Beitrag von: A.Harrenberg am 05 Dezember 2016, 20:14:29

Hi Thomas,

könntest Du bitte mal die angehängte 10_ZWave.pm ausprobieren?

Darin habe ich prinzipiell das gesagte aus dem vorherigen Post umgesetzt:

Zitat
- die gesendeten NONCE in einer Liste aufbewaren
- nur neue NONCE erzeugen die sich in der ersten Stelle unterscheiden um eindeutig zu bleiben
- benutzte NONCE aus der Liste entfernen
- über time alte, unbenutze NONCE aus der Liste entfernen

Allerdings habe ich keinen Timer eingebaut sondern prüfe das einfach vor jedem zurückholen einer Nonce. D.h. wenn sie alt ist wird sie vorher weggeworfen. Die Spezifikation sieht hier Timer zwischen 3 und 20 Sekunden vor, ich habe mich an die Empfehlung 10 sekunden gehalten.

Das sollte die Kommunikation deutlich robuster machen und stellt auch keine Verschlechterung der Sicherheit dar. Dieses asynchrone Pong-Ping sollte damit kein Problem mehr darstellen. Wenn am Ende ein paar NONCE "übrigbleiben" werden die einfach bei nächsten Befehl wieder entfernt.

Wenn das bei Dir wirkt würde ich das gerne schon mal offiziell bei Rudi abgeben, das Problem mit dem SendStack haben wir dann zwar immer noch nicht gefunden. Hierzu müssten wir uns wohl mal auf die Behandlung des Stacks konzentrieren. Ich kann mir höchtens vorstellen das eine normale Aktion aus dem Ablauf und der no_ACK Timer sich irgendwie in die Quere kommen und dann was undefiniertes dabei rauskommt.

Gruß,
Andreas

EDIT: Anhang gelöscht da fehlerhaft... ,-( Update kommt gleich...

Titel: Antw:UZB1 Stick: Lizenz schaltet AES Security frei?
Beitrag von: A.Harrenberg am 05 Dezember 2016, 20:47:08

Hi,

so, jetzt mit neuem Anhang...

Da ich noch recht viele unfertige Änderungen bei mir drin habe kann ich meine Datei nicht einfach weitergeben und muss die "richtigen" Änderungen da rausfiltern. Dabei ist mir eben ein kleiner Fehler unterlaufen der in einigen hundert Zeilen Fehlermeldungen beim Start von FHEM endete... ,-(

Sollte jetzt aber funktionieren, habe es noch mal quergetestet.

Gruß,
Andreas.

Titel: Antw:UZB1 Stick: Lizenz schaltet AES Security frei?
Beitrag von: A.Harrenberg am 08 Dezember 2016, 21:06:20

*push*

Hi Thomas,

hattest Du inzwischen mal Gelegenheit die Änderungen in der 10_ZWave.pm zu testen?

Gruß,
Andreas.

Titel: Antw:UZB1 Stick: Lizenz schaltet AES Security frei?
Beitrag von: krikan am 08 Dezember 2016, 21:20:33

Hallo Andreas!
Muss mit secure eingebundenen KFOB-S und Philio PST02 getestet werden?
Gruß, Christian

Titel: Antw:UZB1 Stick: Lizenz schaltet AES Security frei?
Beitrag von: A.Harrenberg am 08 Dezember 2016, 22:58:32

Hi,

Im Fall von Thomas war wenn mich nicht mein Gedächtnis nicht täuscht die KFOB-S nicht mit secure eingebunden, hat aber anscheinend den "Funkkanal dicht gemacht"...

Falls Du das testen möchtest wäre es natürlich gut wenn Du mit der bisherigen Version ähnliche "asynchrone" Übertrgungen provozieren könntest damit klar ist das es wirklich gegen so etwas hilft. Ein Test das es keine neuen Probleme aufwirft ist natürlich gerne gesehen ,-)

Gruß,
Andreas.

Titel: Antw:UZB1 Stick: Lizenz schaltet AES Security frei?
Beitrag von: buspirat am 09 Dezember 2016, 15:21:45

Hallo Andreas,

Zitat von: A.Harrenberg am 08 Dezember 2016, 21:06:20
*push*

hattest Du inzwischen mal Gelegenheit die Änderungen in der 10_ZWave.pm zu testen?

Sorry für die Pause auf meiner Seite, ich hatte gleich zwei undichte Schläuche am Fahrrad hintereinander, die relativ zeitnah beseitigt werden wollten. Dabei sind unplattbare Reifen verbaut...

Werde mir das nächste Woche ansehen, die Weihnachtsgeschenke sind auch bereits erledigt ;)

Schönes Wochenende,
Thomas

Titel: Antw:UZB1 Stick: Lizenz schaltet AES Security frei?
Beitrag von: krikan am 09 Dezember 2016, 18:46:46

Habe KFOB-S und Philio PST02-1A secure inkludiert und 0,5 Std. versucht Störungen mit svn-Version von FHEM zu erzeugen -> habe es nicht geschafft.

Test der obigen geaenderten Fassung kommt spaeter...

Titel: Antw:UZB1 Stick: Lizenz schaltet AES Security frei?
Beitrag von: A.Harrenberg am 10 Dezember 2016, 07:22:52

Hi Christian,

Zitat von: krikan am 09 Dezember 2016, 18:46:46
Habe KFOB-S und Philio PST02-1A secure inkludiert und 0,5 Std. versucht Störungen mit svn-Version von FHEM zu erzeugen -> habe es nicht geschafft.

das ist natürlich gut (für Dich) wenn Du auch mit der jetzigen Version keine Probleme hast, das Ergebnis

Zitat von: krikan am 09 Dezember 2016, 18:46:46
Test der obigen geaenderten Fassung kommt spaeter...

dieser Tests lautet dann hoffentlich das keine neuen Probleme durch meine Änderungen geschaffen wurden ,-)

Danke,
Andreas.

Titel: Antw:UZB1 Stick: Lizenz schaltet AES Security frei?
Beitrag von: krikan am 10 Dezember 2016, 08:28:36

Hallo Andreas!

Irgendetwas ist merkwürdig. Die Meldung

Code Auswählen

ZWave_SENSOR_NOTIFICATION_29: secStart older than 6 seconds detected, secUnlock will call Zwave_secEnd
füllt das Log nach manuellem Wakeup

Ausgangs-list

Code Auswählen

Internals: 
   DEF        e345c452 29 
   Frame_01 
   IODev      ZWDongle_0 
   LASTInputDev ZWDongle_0 
   MSGCNT     7 
   NAME       ZWave_SENSOR_NOTIFICATION_29 
   NR         317 
   STATE      configOperationMode 8 
   TYPE       ZWave 
   ZWDongle_0_MSGCNT 7 
   ZWDongle_0_RAWMSG 0004001d18988157023946a9d9081c4194e3eed4861e485518c4ff32fa 
   ZWDongle_0_TIME 2016-12-10 05:37:11 
   ZWaveSubDevice no 
   homeId     e345c452 
   isWakeUp   1 
   lastMsgSent 1481344631.29889 
   nodeIdHex  1d 
   secTime    1481344631.24378 
   Readings: 
     2016-12-09 18:28:30   SECURITY        ENABLED 
     2016-12-09 21:49:29   SEND_DATA       failed:00 
     2016-12-10 05:37:11   alarm_AccessControl Window/Door is open, notificationIsOn 
     2016-12-09 21:42:35   alarm_HomeSecurity Motion Detection - Unknown Location, notificationIsOn 
     2016-12-09 21:40:58   assocGroup_1    Max 8 Nodes ZWDongle_0 
     2016-12-09 21:40:58   assocGroup_2    Max 8 Nodes 
     2016-12-09 21:40:57   assocGroups     2 
     2016-12-10 05:37:11   battery         32 % 
     2016-12-09 21:26:54   configAutoReportBatteryTime 12 
     2016-12-09 21:26:54   configAutoReportDoorWindowStateTime 12 
     2016-12-09 21:26:54   configAutoReportIlluminationTime 12 
     2016-12-09 21:26:54   configAutoReportTemperatureTime 12 
     2016-12-09 21:26:54   configAutoReportTickInterval 30 
     2016-12-09 21:26:55   configBasicSetLevel 255 
     2016-12-09 21:26:55   configCustomerFunction 4 
     2016-12-09 21:26:55   configIlluminationDifferentialReport 0 
     2016-12-09 21:26:55   configLightThreshold 99 
     2016-12-09 21:26:55   configMultiSensorFunctionSwitch 4 
     2016-12-09 21:26:55   configOperationMode 0 
     2016-12-09 21:26:55   configPIRReDetectIntervalTime 3 
     2016-12-09 21:26:56   configPIRSensitivity 80 
     2016-12-09 21:26:58   configTemperatureDifferentialReport 1 
     2016-12-09 21:26:59   configTurnOffLightTime 4 
     2016-12-10 05:37:11   luminance       2 % 
     2016-12-09 18:28:42   model           Philio Technology Corporation PST02-A 4 in 1 Multi-Sensor 
     2016-12-09 18:28:42   modelConfig     philio/pst02.xml 
     2016-12-09 18:28:42   modelId         013c-0002-000c 
     2016-12-09 21:42:08   state           configOperationMode 8 
     2016-12-10 05:37:11   temperature     21.0 C 
     2016-12-10 05:37:11   timeToAck       0.029 
     2016-12-10 05:37:11   transmit        OK 
     2016-12-09 22:05:37   wakeup          notification 
   SendStack: 
     set:481d73 
   Secnonce: 
     0f: 
       nonce      0f51384eedcbe8cd 
       timeStamp  1481344631.24393 
     86: 
       nonce      86c239cd5ad34839 
       timeStamp  1481344631.29876 
Attributes: 
   IODev      ZWDongle_0 
   classes    ZWAVEPLUS_INFO BATTERY ALARM ASSOCIATION CONFIGURATION MANUFACTURER_SPECIFIC VERSION SENSOR_BINARY SENSOR_MULTILEVEL WAKE_UP ASSOCIATION_GRP_INFO POWERLEVEL DEVICE_RESET_LOCALLY MULTI_CMD SECURITY FIRMWARE_UPDATE_MD MARK BASIC 
   extendedAlarmReadings 1 
   room       ZWave 
   secure_classes BATTERY ALARM ASSOCIATION CONFIGURATION SENSOR_BINARY SENSOR_MULTILEVEL WAKE_UP MARK 
   vclasses   ALARM:4 ASSOCIATION:2 ASSOCIATION_GRP_INFO:1 BASIC:0 BATTERY:1 CONFIGURATION:1 DEVICE_RESET_LOCALLY:1 FIRMWARE_UPDATE_MD:2 MANUFACTURER_SPECIFIC:2 MULTI_CMD:1 POWERLEVEL:1 SECURITY:1 SENSOR_BINARY:2 SENSOR_MULTILEVEL:5 VERSION:2 WAKE_UP:2 ZWAVEPLUS_INFO:2

Log bis zum naechsten list haengt an.

Code Auswählen

Internals: 
   DEF        e345c452 29 
   Frame_01 
   IODev      ZWDongle_0 
   LASTInputDev ZWDongle_0 
   MSGCNT     12 
   NAME       ZWave_SENSOR_NOTIFICATION_29 
   NR         317 
   STATE      configOperationMode 8 
   TYPE       ZWave 
   ZWDongle_0_MSGCNT 12 
   ZWDongle_0_RAWMSG 00487322 
   ZWDongle_0_TIME 2016-12-10 08:14:06 
   ZWaveSubDevice no 
   homeId     e345c452 
   isWakeUp   1 
   lastMsgSent 1481354038.23286 
   nodeIdHex  1d 
   secInProgress 1 
   secTime    1481354341.04029 
   Readings: 
     2016-12-09 18:28:30   SECURITY        ENABLED 
     2016-12-09 21:49:29   SEND_DATA       failed:00 
     2016-12-10 05:37:11   alarm_AccessControl Window/Door is open, notificationIsOn 
     2016-12-09 21:42:35   alarm_HomeSecurity Motion Detection - Unknown Location, notificationIsOn 
     2016-12-09 21:40:58   assocGroup_1    Max 8 Nodes ZWDongle_0 
     2016-12-09 21:40:58   assocGroup_2    Max 8 Nodes 
     2016-12-09 21:40:57   assocGroups     2 
     2016-12-10 05:37:11   battery         32 % 
     2016-12-09 21:26:54   configAutoReportBatteryTime 12 
     2016-12-09 21:26:54   configAutoReportDoorWindowStateTime 12 
     2016-12-09 21:26:54   configAutoReportIlluminationTime 12 
     2016-12-09 21:26:54   configAutoReportTemperatureTime 12 
     2016-12-09 21:26:54   configAutoReportTickInterval 30 
     2016-12-09 21:26:55   configBasicSetLevel 255 
     2016-12-09 21:26:55   configCustomerFunction 4 
     2016-12-09 21:26:55   configIlluminationDifferentialReport 0 
     2016-12-09 21:26:55   configLightThreshold 99 
     2016-12-09 21:26:55   configMultiSensorFunctionSwitch 4 
     2016-12-09 21:26:55   configOperationMode 0 
     2016-12-09 21:26:55   configPIRReDetectIntervalTime 3 
     2016-12-09 21:26:56   configPIRSensitivity 80 
     2016-12-09 21:26:58   configTemperatureDifferentialReport 1 
     2016-12-09 21:26:59   configTurnOffLightTime 4 
     2016-12-10 05:37:11   luminance       2 % 
     2016-12-09 18:28:42   model           Philio Technology Corporation PST02-A 4 in 1 Multi-Sensor 
     2016-12-09 18:28:42   modelConfig     philio/pst02.xml 
     2016-12-09 18:28:42   modelId         013c-0002-000c 
     2016-12-10 08:14:06   neighborUpdate  done 
     2016-12-09 21:42:08   state           configOperationMode 8 
     2016-12-10 05:37:11   temperature     21.0 C 
     2016-12-10 05:37:11   timeToAck       0.029 
     2016-12-10 05:37:11   transmit        OK 
     2016-12-10 08:13:58   wakeup          notification 
   SendStack: 
     sentset:481d73 
     set:131d0a9880443ee2a81cf8fdac25a7 
     set:131d0a98806f6b505a664f270225a8 
     set:131d0a988035be32a0f561739c25a9 
     set:131d0a98804dbf17a78ee2376f25aa 
     set:131d0a9880b7199d8885ae181f25ab 
     set:131d0a9880415145dda0bd92c225ac 
     set:131d0a98806b515e5f439f125625ad 
     set:131d0a9880c9d2fc82b0335a9925ae 
     set:131d0a9880807854d6595085c725af 
     set:131d0a9880406456048242299925b0 
     set:131d0a9880e17f394e7135b43625b1 
     set:131d0a9880c7b30791c7a53c8125b2 
     set:131d0a9880464f5e97d2d69bdd25b3 
     set:131d0a98809f43b28138c7df5625b4 
     set:131d0a988092154cdce0fdd61825b5 
     set:131d0a98807da18fea0f795fea25b6 
     set:131d0a988039ebb158f4b625e525b7 
     set:131d0a9880891788377bd2ad7825b8 
     set:131d0a9880a8d28c4aca7f6dcd25b9 
   Secnonce: 
     0f: 
       nonce      0f51384eedcbe8cd 
       timeStamp  1481344631.24393 
     35: 
       nonce      35be32a0f561739c 
       timeStamp  1481354026.23165 
     39: 
       nonce      39ebb158f4b625e5 
       timeStamp  1481354287.68028 
     40: 
       nonce      4064560482422999 
       timeStamp  1481354101.74498 
     41: 
       nonce      415145dda0bd92c2 
       timeStamp  1481354035.23486 
     44: 
       nonce      443ee2a81cf8fdac 
       timeStamp  1481354020.27313 
     46: 
       nonce      464f5e97d2d69bdd 
       timeStamp  1481354195.13538 
     4d: 
       nonce      4dbf17a78ee2376f 
       timeStamp  1481354029.23243 
     6b: 
       nonce      6b515e5f439f1256 
       timeStamp  1481354040.32644 
     6f: 
       nonce      6f6b505a664f2702 
       timeStamp  1481354023.23214 
     7d: 
       nonce      7da18fea0f795fea 
       timeStamp  1481354275.83605 
     80: 
       nonce      807854d6595085c7 
       timeStamp  1481354073.98747 
     86: 
       nonce      86c239cd5ad34839 
       timeStamp  1481344631.29876 
     89: 
       nonce      891788377bd2ad78 
       timeStamp  1481354315.10169 
     92: 
       nonce      92154cdce0fdd618 
       timeStamp  1481354257.00108 
     9f: 
       nonce      9f43b28138c7df56 
       timeStamp  1481354235.83062 
     A8: 
       nonce      a8d28c4aca7f6dcd 
       timeStamp  1481354341.04043 
     B7: 
       nonce      b7199d8885ae181f 
       timeStamp  1481354032.23188 
     C7: 
       nonce      c7b30791c7a53c81 
       timeStamp  1481354164.96221 
     C9: 
       nonce      c9d2fc82b0335a99 
       timeStamp  1481354054.93475 
     E1: 
       nonce      e17f394e7135b436 
       timeStamp  1481354104.70756 
   secStack: 
   Sectimer: 
     Hash: 
Attributes: 
   IODev      ZWDongle_0 
   classes    ZWAVEPLUS_INFO BATTERY ALARM ASSOCIATION CONFIGURATION MANUFACTURER_SPECIFIC VERSION SENSOR_BINARY SENSOR_MULTILEVEL WAKE_UP ASSOCIATION_GRP_INFO POWERLEVEL DEVICE_RESET_LOCALLY MULTI_CMD SECURITY FIRMWARE_UPDATE_MD MARK BASIC 
   extendedAlarmReadings 1 
   room       ZWave 
   secure_classes BATTERY ALARM ASSOCIATION CONFIGURATION SENSOR_BINARY SENSOR_MULTILEVEL WAKE_UP MARK 
   vclasses   ALARM:4 ASSOCIATION:2 ASSOCIATION_GRP_INFO:1 BASIC:0 BATTERY:1 CONFIGURATION:1 DEVICE_RESET_LOCALLY:1 FIRMWARE_UPDATE_MD:2 MANUFACTURER_SPECIFIC:2 MULTI_CMD:1 POWERLEVEL:1 SECURITY:1 SENSOR_BINARY:2 SENSOR_MULTILEVEL:5 VERSION:2 WAKE_UP:2 ZWAVEPLUS_INFO:2

Gruß, Christian

Titel: Antw:UZB1 Stick: Lizenz schaltet AES Security frei?
Beitrag von: A.Harrenberg am 10 Dezember 2016, 08:45:55

Hi Christian,

habe noch nicht in das Log reingeschaut, aber es sieht so aus als ob bei Dir das gleiche Problem mit dem SendStack aufgetreten ist das buspirat auch schon hatte. Der Stack friert ein und es bleibt ein "sentset:" oben drauf liegen, danach wird nichts mehr versendet. Die "secUnlock" Nachricht wird generiert weil nach dem "Abschicken" der NONCE (die aber auf dem Stack landet und nicht bearbeitet wird keine RM vom Gerät kommt (kann ja auch nicht, wurde ja nix versendet).

D.h. Du hast jetzt erfolgreich das "andere" Problem nachgestellt.

Hier müssen wir verstehen was im Ablauf vom Stack schief läuft. Eigentlich erscheint der Ablauf fool-proof, irgendwas geht da aber dennoch schief.

Dieses Verhalten hat aber nichts mit meinen Änderungen zu tun, das war ja die Ausgangssituation durch die ich diese ewig langen asynchronen "eine NONCE daneben" Kommunikationen entdeckt habe die dann irgendwann auch das Problem mit dem eingefrorenen Stack gezeigt haben.

Am besten noch mal fhem neustarten, ich bin nicht sicher ob beim Laden des Moduls der Stack zurückgesetzt wird, vermute aber das es nicht passiert und daher nicht reicht um die Kommunikation wieder in Gang zu bringen.

Ich schau später auch noch mal in das Logfile ob ich erkenne wo der Stack hängen bleibt. Allerdings war da selbst mit den erweiterten Logmeldungen von buspirat nicht zu erkennen wo genau das hängenbleibt, daher mache ich mir da jetzt erst mal wenig Hoffnung was zu finden was uns der Lösung näherbringt. Außerdem leide ich noch ein wenig unter der gestrigen Weihnachtsfeier ,-)

Gruß,
Andreas.

Titel: Antw:UZB1 Stick: Lizenz schaltet AES Security frei?
Beitrag von: A.Harrenberg am 10 Dezember 2016, 10:27:28

Hi,

im Log ist auch nichts erhellendes zu finden. Anscheinend ist bereits zu Beginn des Logs der Stack schon eingefroren, es wird außer den ACK nichts mehr gesendet...

Gruß,
Andreas.

Titel: Antw:UZB1 Stick: Lizenz schaltet AES Security frei?
Beitrag von: krikan am 10 Dezember 2016, 10:56:37

Kann gut sein. System lief seit gestern abend durch.
FHEM empfängt während der "secStart older than 6 seconds detected, secUnlock will call Zwave_secEnd"- Meldung auch keine Nachrichten mehr vom Gerät. Im Log taucht nichts auf. Nach einiger Zeit erholt es sich aber wieder und Nachrichten kommen wieder an.

Aber egal, vermutlich alles Folgewirkungen. Ich beginne mal einen neuen Test mit frischen gestarteten FHEM und werde berichten. Wird aber frühestens heute abend etwas werden.

Gruß, Christian

Titel: Antw:UZB1 Stick: Lizenz schaltet AES Security frei?
Beitrag von: buspirat am 10 Dezember 2016, 16:12:26

Zitat von: A.Harrenberg am 03 Dezember 2016, 14:53:32
Es scheint das bei dem ZWDongle_shiftSendStack Aufruf was schief läuft und der Befehl nicht vom Stack entfernt wird. Ich war eigentlich der Meinung das im Hintergrund auch ein Timer werkelt der dort aufräumt, evtl. kommt auch Timer aus dem Tritt...

Kurze Rückmeldung von unterwegs: ich denke shiftSendStack für sich alleine arbeitet einwandfrei. Ich hatte extra den Data::Dumper vor und nach dem "shift" Befehl eingebaut. Ich tippe darauf, dass irgendwer *danach* die Nachricht wieder auf den Stack legt. Mein Plan ist bisher die Stellen bei denen die 'sentxxx' Nachrichten erzeugt werden mit weiteren debug Loggern zu versehen.

Evtl. wie von Dir vermutet ein Timer.

VG,
Thomas

Titel: Antw:UZB1 Stick: Lizenz schaltet AES Security frei?
Beitrag von: krikan am 10 Dezember 2016, 17:14:27

Mir ist nicht so ganz klar, worauf ich achten muss. Sind bspw. die vielen nonce und timeStamp-Angaben im list ok? Die tauchen schon nach kurzer Betriebszeit auf ohne im Log erkennbare Auffaelligkeiten.

Code Auswählen

Internals: 
   DEF        e345c452 29 
   Frame_01 
   Frame_02 
   Frame_03 
   IODev      ZWDongle_0 
   LASTInputDev ZWDongle_0 
   MSGCNT     20 
   NAME       ZWave_SENSOR_NOTIFICATION_29 
   NR         317 
   STATE      configOperationMode 8 
   TYPE       ZWave 
   ZWDongle_0_MSGCNT 20 
   ZWDongle_0_RAWMSG 0004001d189881e6b7ead4de885ec1da9f18acc9aea5eb83b3bb14bcd5 
   ZWDongle_0_TIME 2016-12-10 17:08:16 
   ZWaveSubDevice no 
   homeId     e345c452 
   isWakeUp   1 
   lastMsgSent 1481386096.91327 
   nodeIdHex  1d 
   secTime    1481386096.85669 
   Readings: 
     2016-12-09 18:28:30   SECURITY        ENABLED 
     2016-12-09 21:49:29   SEND_DATA       failed:00 
     2016-12-10 17:08:16   alarm_AccessControl Window/Door is closed, notificationIsOn 
     2016-12-10 08:30:45   alarm_HomeSecurity Tampering - product covering removed, notificationIsOn 
     2016-12-09 21:40:58   assocGroup_1    Max 8 Nodes ZWDongle_0 
     2016-12-09 21:40:58   assocGroup_2    Max 8 Nodes 
     2016-12-09 21:40:57   assocGroups     2 
     2016-12-10 17:08:16   battery         32 % 
     2016-12-09 21:26:54   configAutoReportBatteryTime 12 
     2016-12-09 21:26:54   configAutoReportDoorWindowStateTime 12 
     2016-12-09 21:26:54   configAutoReportIlluminationTime 12 
     2016-12-09 21:26:54   configAutoReportTemperatureTime 12 
     2016-12-09 21:26:54   configAutoReportTickInterval 30 
     2016-12-09 21:26:55   configBasicSetLevel 255 
     2016-12-09 21:26:55   configCustomerFunction 4 
     2016-12-09 21:26:55   configIlluminationDifferentialReport 0 
     2016-12-09 21:26:55   configLightThreshold 99 
     2016-12-09 21:26:55   configMultiSensorFunctionSwitch 4 
     2016-12-09 21:26:55   configOperationMode 0 
     2016-12-09 21:26:55   configPIRReDetectIntervalTime 3 
     2016-12-09 21:26:56   configPIRSensitivity 80 
     2016-12-09 21:26:58   configTemperatureDifferentialReport 1 
     2016-12-09 21:26:59   configTurnOffLightTime 4 
     2016-12-10 17:08:16   luminance       4 % 
     2016-12-09 18:28:42   model           Philio Technology Corporation PST02-A 4 in 1 Multi-Sensor 
     2016-12-09 18:28:42   modelConfig     philio/pst02.xml 
     2016-12-09 18:28:42   modelId         013c-0002-000c 
     2016-12-10 08:14:06   neighborUpdate  done 
     2016-12-09 21:42:08   state           configOperationMode 8 
     2016-12-10 17:08:16   temperature     21.5 C 
     2016-12-10 17:08:16   timeToAck       0.029 
     2016-12-10 17:08:16   transmit        OK 
     2016-12-10 08:30:59   wakeup          notification 
   Secnonce: 
     0b: 
       nonce      0bfd515ee83393b3 
       timeStamp  1481386096.38738 
     0e: 
       nonce      0e22c319694b0cd0 
       timeStamp  1481386094.92757 
     25: 
       nonce      25f9b9ccc73e30ff 
       timeStamp  1481386090.73895 
     3a: 
       nonce      3a09c932718a12dc 
       timeStamp  1481386087.84218 
     45: 
       nonce      455d0be88e7eaca3 
       timeStamp  1481386094.87272 
     50: 
       nonce      50e397c8dfcb3456 
       timeStamp  1481386095.97406 
     51: 
       nonce      51a11d894b0ba218 
       timeStamp  1481386087.78439 
     52: 
       nonce      526efbdc720c8a77 
       timeStamp  1481386096.33123 
     61: 
       nonce      613cf4a920658f68 
       timeStamp  1481386096.85683 
     6b: 
       nonce      6bd32ce909678b55 
       timeStamp  1481386091.23978 
     6f: 
       nonce      6f09fff199bc9056 
       timeStamp  1481386094.72877 
     79: 
       nonce      7981e37a82d3f84a 
       timeStamp  1481386094.64166 
     7d: 
       nonce      7d14e4c54eba8400 
       timeStamp  1481386091.29653 
     97: 
       nonce      97fe194e10dcb3d5 
       timeStamp  1481386090.68395 
     9b: 
       nonce      9bfda456537624e0 
       timeStamp  1481386094.58528 
     A0: 
       nonce      a0db3458fac0f6b6 
       timeStamp  1481386089.06342 
     Ad: 
       nonce      ad534d0bffa218b1 
       timeStamp  1481386089.11961 
     Ae: 
       nonce      ae79d8475d9c5c1d 
       timeStamp  1481386096.91315 
     D7: 
       nonce      d70e59a059d6944a 
       timeStamp  1481386094.78474 
     E0: 
       nonce      e0e356cbc63bdb0d 
       timeStamp  1481386096.02925 
Attributes: 
   IODev      ZWDongle_0 
   classes    ZWAVEPLUS_INFO BATTERY ALARM ASSOCIATION CONFIGURATION MANUFACTURER_SPECIFIC VERSION SENSOR_BINARY SENSOR_MULTILEVEL WAKE_UP ASSOCIATION_GRP_INFO POWERLEVEL DEVICE_RESET_LOCALLY MULTI_CMD SECURITY FIRMWARE_UPDATE_MD MARK BASIC 
   extendedAlarmReadings 1 
   room       ZWave 
   secure_classes BATTERY ALARM ASSOCIATION CONFIGURATION SENSOR_BINARY SENSOR_MULTILEVEL WAKE_UP MARK 
   vclasses   ALARM:4 ASSOCIATION:2 ASSOCIATION_GRP_INFO:1 BASIC:0 BATTERY:1 CONFIGURATION:1 DEVICE_RESET_LOCALLY:1 FIRMWARE_UPDATE_MD:2 MANUFACTURER_SPECIFIC:2 MULTI_CMD:1 POWERLEVEL:1 SECURITY:1 SENSOR_BINARY:2 SENSOR_MULTILEVEL:5 VERSION:2 WAKE_UP:2 ZWAVEPLUS_INFO:2

Titel: Antw:UZB1 Stick: Lizenz schaltet AES Security frei?
Beitrag von: A.Harrenberg am 11 Dezember 2016, 10:57:11

Hallo Christian,

Zitat von: krikan am 10 Dezember 2016, 17:14:27
Mir ist nicht so ganz klar, worauf ich achten muss. Sind bspw. die vielen nonce und timeStamp-Angaben im list ok? Die tauchen schon nach kurzer Betriebszeit auf ohne im Log erkennbare Auffaelligkeiten.

hmm, in der Version die ich euch zum Testen abgelegt habe ist leider eine Zeile auskommentiert... daher sammeln sich da NONCE Einträge an...

Könntest Du bitte die korrigierte Version aus dem Anhang nehmen oder einfach in der Funktion ZWave_secRetrieveNonce in Zeile 3624 die Kommentierung vor dem "delete($hash->{secNonce}{$s_nonce_id_hex});" entfernen?

Code Auswählen

  if ($hash->{secNonce}{$s_nonce_id_hex}) {
      $s_nonce_hex = $hash->{secNonce}{$s_nonce_id_hex}{nonce};
      delete($hash->{secNonce}{$s_nonce_id_hex});
      return $s_nonce_hex;
  } else {
    return undef;
  }

Das funktioniert zwar auch so, aber Du bekommst dann unnötige Einträge im Log und kannst das nicht mehr von potentiellen Fehlern unterscheiden.

WENN es zu mehrfachem Anfordern eine NONCE gekommen ist und die beide noch "jünger" als 10 Sekunden sind, sollte sich im Log (verbose 5) eine Meldung mit

Code Auswählen

SECURITY: multiple nonce warning, there are $n nonce active
finden lassen.

Falls das passiert wäre ich an dem entsprechenden Logsegment interessiert um zu sehen warum hier zwei Nonce aktiv wurden.
Gleiches gilt für Passagen in denen secUnlock aufgerufen wird. Hier ist es aber in bisher allen Fällen die ich so gesehen haben wirklich zu einem Kommunikationsabbruch gekommen, in letzter Zeit aber auch das von Dir nachgestellte Verhalten mit dem klemmenden SendStack.

Ansonsten sollten hoffentlich keine neuen Nebeneffekte auftreten.

Gruß,
Andreas.

Titel: Antw:UZB1 Stick: Lizenz schaltet AES Security frei?
Beitrag von: krikan am 11 Dezember 2016, 22:15:59

Hallo Andreas!

Habe den Philio mit Abfragen im Sendstack gequaelt. Jetzt bleibt der Sendstack so haengen:

Code Auswählen

Internals: 
   DEF        e345c452 29 
   Frame_01 
   IODev      ZWDongle_0 
   LASTInputDev ZWDongle_0 
   MSGCNT     92 
   NAME       ZWave_SENSOR_NOTIFICATION_29 
   NR         317 
   STATE      closed 
   TYPE       ZWave 
   ZWDongle_0_MSGCNT 92 
   ZWDongle_0_RAWMSG 0004001d1998818b6b089ede9ad86882fc28e630b82bd558ff850b33de29 
   ZWDongle_0_TIME 2016-12-11 21:56:45 
   ZWaveSubDevice no 
   homeId     e345c452 
   isWakeUp   1 
   lastMsgSent 1481489817.82236 
   nodeIdHex  1d 
   secTime    1481490203.23422 
   Readings: 
     2016-12-09 18:28:30   SECURITY        ENABLED 
     2016-12-09 21:49:29   SEND_DATA       failed:00 
     2016-12-11 21:55:44   alarm_AccessControl Window/Door is closed, notificationIsOn 
     2016-12-11 21:55:28   alarm_HomeSecurity Motion Detection - Unknown Location, notificationIsOn 
     2016-12-11 21:54:37   assocGroup_1    Max 8 Nodes ZWDongle_0 
     2016-12-11 21:54:38   assocGroup_2    Max 8 Nodes 
     2016-12-11 21:54:37   assocGroups     2 
     2016-12-11 21:55:44   battery         32 % 
     2016-12-11 21:54:35   configAutoReportBatteryTime 12 
     2016-12-11 21:54:35   configAutoReportDoorWindowStateTime 12 
     2016-12-11 21:54:35   configAutoReportIlluminationTime 12 
     2016-12-11 21:56:43   configAutoReportTemperatureTime 12 
     2016-12-11 21:56:44   configAutoReportTickInterval 30 
     2016-12-11 21:56:44   configBasicSetLevel 255 
     2016-12-11 21:56:44   configCustomerFunction 4 
     2016-12-11 21:56:44   configIlluminationDifferentialReport 0 
     2016-12-11 21:56:44   configLightThreshold 99 
     2016-12-11 21:56:44   configMultiSensorFunctionSwitch 4 
     2016-12-11 21:56:44   configOperationMode 8 
     2016-12-11 21:56:45   configPIRReDetectIntervalTime 3 
     2016-12-11 21:56:45   configPIRSensitivity 80 
     2016-12-11 21:56:45   configTemperatureDifferentialReport 1 
     2016-12-11 21:56:45   configTurnOffLightTime 4 
     2016-12-11 21:55:44   luminance       6 % 
     2016-12-09 18:28:42   model           Philio Technology Corporation PST02-A 4 in 1 Multi-Sensor 
     2016-12-09 18:28:42   modelConfig     philio/pst02.xml 
     2016-12-09 18:28:42   modelId         013c-0002-000c 
     2016-12-10 08:14:06   neighborUpdate  done 
     2016-12-09 21:42:08   state           configOperationMode 8 
     2016-12-11 21:55:44   temperature     25.0 C 
     2016-12-11 21:56:57   timeToAck       0.092 
     2016-12-11 21:56:57   transmit        OK 
     2016-12-11 21:56:43   wakeup          notification 
   SendStack: 
     sentackget:131d03861331250b 
     get:131d03861386250c 
     get:131d03861384250d 
     get:131d0386135e250e 
     set:131d0298402510 
     set:131d0a98801ec1ca50510f17b52511 
     set:131d0a9880daf7ad79a46044e62512 
     set:131d0a98804bdf27270ccd8d832513 
     set:131d0a988013d6118d21bddc432514 
     set:131d0a9880e9faec99aff4ff3e2515 
   secMsg: 
     8505 get ZWave_SENSOR_NOTIFICATION_29 associationGroups 
   Secnonce: 
     13: 
       nonce      13d6118d21bddc43 
       timeStamp  1481490184.41603 
     1e: 
       nonce      1ec1ca50510f17b5 
       timeStamp  1481489817.82169 
     29: 
       nonce      2923cf83e3bc6197 
       timeStamp  1481489800.3939 
     4b: 
       nonce      4bdf27270ccd8d83 
       timeStamp  1481490169.39011 
     Da: 
       nonce      daf7ad79a46044e6 
       timeStamp  1481489876.53989 
     Db: 
       nonce      dbfadec559d2b3ea 
       timeStamp  1481489797.39694 
     E9: 
       nonce      e9faec99aff4ff3e 
       timeStamp  1481490203.23437 
Attributes: 
   IODev      ZWDongle_0 
   classes    ZWAVEPLUS_INFO BATTERY ALARM ASSOCIATION CONFIGURATION MANUFACTURER_SPECIFIC VERSION SENSOR_BINARY SENSOR_MULTILEVEL WAKE_UP ASSOCIATION_GRP_INFO POWERLEVEL DEVICE_RESET_LOCALLY MULTI_CMD SECURITY FIRMWARE_UPDATE_MD MARK BASIC 
   extendedAlarmReadings 1 
   room       ZWave 
   secure_classes BATTERY ALARM ASSOCIATION CONFIGURATION SENSOR_BINARY SENSOR_MULTILEVEL WAKE_UP MARK 
   stateFormat {(split(/,|is /, ReadingsVal($name,"alarm_AccessControl","")))[1]} 
   vclasses   ALARM:4 ASSOCIATION:2 ASSOCIATION_GRP_INFO:1 BASIC:0 BATTERY:1 CONFIGURATION:1 DEVICE_RESET_LOCALLY:1 FIRMWARE_UPDATE_MD:2 MANUFACTURER_SPECIFIC:2 MULTI_CMD:1 POWERLEVEL:1 SECURITY:1 SENSOR_BINARY:2 SENSOR_MULTILEVEL:5 VERSION:2 WAKE_UP:2 ZWAVEPLUS_INFO:2

Das angehaengte Log ist "etwas" laenger. Aber so siehst Du es hoffentlich von Anfang an.

Nach der angehaengten Datei geht es so weiter, wenn ich nichts mehr selbst in den Sendstack lege:

Code Auswählen

2016.12.11 22:02:23.387 4: ZWDongle_Read ZWDongle_0: rcvd 000400040a320221440000000c0000 (request APPLICATION_COMMAND_HANDLER), sending ACK
2016.12.11 22:02:23.387 5: SW: 06
2016.12.11 22:02:23.389 5: ZWDongle_0: dispatch 000400040a320221440000000c0000
2016.12.11 22:02:23.390 4: CMD:APPLICATION_COMMAND_HANDLER ID:04 ARG:0a320221440000000c0000 CB:00
2016.12.11 22:02:49.386 4: ZWDongle_Read ZWDongle_0: rcvd 0004001d029840 (request APPLICATION_COMMAND_HANDLER), sending ACK
2016.12.11 22:02:49.387 5: SW: 06
2016.12.11 22:02:49.388 5: ZWDongle_0: dispatch 0004001d029840
2016.12.11 22:02:49.389 4: CMD:APPLICATION_COMMAND_HANDLER ID:1d ARG:029840 CB:00
2016.12.11 22:02:56.390 3: ZWave_SENSOR_NOTIFICATION_29: secStart older than 6 seconds detected, secUnlock will call Zwave_secEnd
2016.12.11 22:03:04.412 4: ZWDongle_Read ZWDongle_0: rcvd 0004001d029840 (request APPLICATION_COMMAND_HANDLER), sending ACK
2016.12.11 22:03:04.413 5: SW: 06
2016.12.11 22:03:04.414 5: ZWDongle_0: dispatch 0004001d029840
2016.12.11 22:03:04.415 4: CMD:APPLICATION_COMMAND_HANDLER ID:1d ARG:029840 CB:00
2016.12.11 22:03:11.416 3: ZWave_SENSOR_NOTIFICATION_29: secStart older than 6 seconds detected, secUnlock will call Zwave_secEnd
2016.12.11 22:03:23.231 4: ZWDongle_Read ZWDongle_0: rcvd 0004001d029840 (request APPLICATION_COMMAND_HANDLER), sending ACK
2016.12.11 22:03:23.231 5: SW: 06
2016.12.11 22:03:23.233 5: ZWDongle_0: dispatch 0004001d029840
2016.12.11 22:03:23.233 4: CMD:APPLICATION_COMMAND_HANDLER ID:1d ARG:029840 CB:00
2016.12.11 22:03:27.708 4: ZWDongle_Read ZWDongle_0: rcvd 0004001b0a32022144000000020000 (request APPLICATION_COMMAND_HANDLER), sending ACK
2016.12.11 22:03:27.708 5: SW: 06
2016.12.11 22:03:27.710 5: ZWDongle_0: dispatch 0004001b0a32022144000000020000
2016.12.11 22:03:27.711 4: CMD:APPLICATION_COMMAND_HANDLER ID:1b ARG:0a32022144000000020000 CB:00
2016.12.11 22:03:30.234 3: ZWave_SENSOR_NOTIFICATION_29: secStart older than 6 seconds detected, secUnlock will call Zwave_secEnd
2016.12.11 22:03:48.103 4: ZWDongle_Read ZWDongle_0: rcvd 0004001d029840 (request APPLICATION_COMMAND_HANDLER), sending ACK
2016.12.11 22:03:48.103 5: SW: 06
2016.12.11 22:03:48.104 5: ZWDongle_0: dispatch 0004001d029840
2016.12.11 22:03:48.105 4: CMD:APPLICATION_COMMAND_HANDLER ID:1d ARG:029840 CB:00
2016.12.11 22:03:55.106 3: ZWave_SENSOR_NOTIFICATION_29: secStart older than 6 seconds detected, secUnlock will call Zwave_secEnd
2016.12.11 22:04:02.408 4: ZWDongle_Read ZWDongle_0: rcvd 0004001d029840 (request APPLICATION_COMMAND_HANDLER), sending ACK
2016.12.11 22:04:02.408 5: SW: 06
2016.12.11 22:04:02.410 5: ZWDongle_0: dispatch 0004001d029840
2016.12.11 22:04:02.410 4: CMD:APPLICATION_COMMAND_HANDLER ID:1d ARG:029840 CB:00
2016.12.11 22:04:09.411 3: ZWave_SENSOR_NOTIFICATION_29: secStart older than 6 seconds detected, secUnlock will call Zwave_secEnd
2016.12.11 22:05:45.534 4: ZWDongle_Read ZWDongle_0: rcvd 0004001d029840 (request APPLICATION_COMMAND_HANDLER), sending ACK
2016.12.11 22:05:45.534 5: SW: 06
2016.12.11 22:05:45.535 5: ZWDongle_0: dispatch 0004001d029840
2016.12.11 22:05:45.536 4: CMD:APPLICATION_COMMAND_HANDLER ID:1d ARG:029840 CB:00
2016.12.11 22:05:52.538 3: ZWave_SENSOR_NOTIFICATION_29: secStart older than 6 seconds detected, secUnlock will call Zwave_secEnd
2016.12.11 22:07:43.000 4: ZWDongle_Read ZWDongle_0: rcvd 0004001d029840 (request APPLICATION_COMMAND_HANDLER), sending ACK
2016.12.11 22:07:43.001 5: SW: 06
2016.12.11 22:07:43.002 5: ZWDongle_0: dispatch 0004001d029840
2016.12.11 22:07:43.003 4: CMD:APPLICATION_COMMAND_HANDLER ID:1d ARG:029840 CB:00
2016.12.11 22:07:50.004 3: ZWave_SENSOR_NOTIFICATION_29: secStart older than 6 seconds detected, secUnlock will call Zwave_secEnd
2016.12.11 22:09:04.738 4: ZWDongle_Read ZWDongle_0: rcvd 0004001d029840 (request APPLICATION_COMMAND_HANDLER), sending ACK
2016.12.11 22:09:04.738 5: SW: 06
2016.12.11 22:09:04.740 5: ZWDongle_0: dispatch 0004001d029840
2016.12.11 22:09:04.740 4: CMD:APPLICATION_COMMAND_HANDLER ID:1d ARG:029840 CB:00
2016.12.11 22:09:11.741 3: ZWave_SENSOR_NOTIFICATION_29: secStart older than 6 seconds detected, secUnlock will call Zwave_secEnd
2016.12.11 22:09:28.755 4: ZWDongle_Read ZWDongle_0: rcvd 0004001d029840 (request APPLICATION_COMMAND_HANDLER), sending ACK
2016.12.11 22:09:28.755 5: SW: 06
2016.12.11 22:09:28.757 5: ZWDongle_0: dispatch 0004001d029840
2016.12.11 22:09:28.757 4: CMD:APPLICATION_COMMAND_HANDLER ID:1d ARG:029840 CB:00
2016.12.11 22:09:34.481 4: ZWDongle_Read ZWDongle_0: rcvd 0004003e0e32022144000000b10e10000000b0 (request APPLICATION_COMMAND_HANDLER), sending ACK
2016.12.11 22:09:34.481 5: SW: 06
2016.12.11 22:09:34.482 5: ZWDongle_0: dispatch 0004003e0e32022144000000b10e10000000b0
2016.12.11 22:09:34.483 4: CMD:APPLICATION_COMMAND_HANDLER ID:3e ARG:0e32022144000000b10e10000000b0 CB:00
2016.12.11 22:09:35.758 3: ZWave_SENSOR_NOTIFICATION_29: secStart older than 6 seconds detected, secUnlock will call Zwave_secEnd
2016.12.11 22:09:47.791 4: ZWDongle_Read ZWDongle_0: rcvd 0004000d032001ff (request APPLICATION_COMMAND_HANDLER), sending ACK
2016.12.11 22:09:47.792 5: SW: 06
2016.12.11 22:09:47.793 5: ZWDongle_0: dispatch 0004000d032001ff
2016.12.11 22:09:47.793 4: CMD:APPLICATION_COMMAND_HANDLER ID:0d ARG:032001ff CB:00
2016.12.11 22:09:47.847 4: ZWDongle_Read ZWDongle_0: rcvd 0004000d0a710507ff00ff07080000 (request APPLICATION_COMMAND_HANDLER), sending ACK
2016.12.11 22:09:47.847 5: SW: 06
2016.12.11 22:09:47.849 5: ZWDongle_0: dispatch 0004000d0a710507ff00ff07080000
2016.12.11 22:09:47.849 4: CMD:APPLICATION_COMMAND_HANDLER ID:0d ARG:0a710507ff00ff07080000 CB:00
2016.12.11 22:09:52.149 4: ZWDongle_Read ZWDongle_0: rcvd 0004001d029840 (request APPLICATION_COMMAND_HANDLER), sending ACK
2016.12.11 22:09:52.150 5: SW: 06
2016.12.11 22:09:52.152 5: ZWDongle_0: dispatch 0004001d029840
2016.12.11 22:09:52.152 4: CMD:APPLICATION_COMMAND_HANDLER ID:1d ARG:029840 CB:00
2016.12.11 22:09:59.154 3: ZWave_SENSOR_NOTIFICATION_29: secStart older than 6 seconds detected, secUnlock will call Zwave_secEnd
2016.12.11 22:10:24.776 3: Wetter: 0 result(s) retrieved
2016.12.11 22:10:38.064 4: ZWDongle_Read ZWDongle_0: rcvd 0004001d029840 (request APPLICATION_COMMAND_HANDLER), sending ACK
2016.12.11 22:10:38.064 5: SW: 06
2016.12.11 22:10:38.066 5: ZWDongle_0: dispatch 0004001d029840
2016.12.11 22:10:38.066 4: CMD:APPLICATION_COMMAND_HANDLER ID:1d ARG:029840 CB:00
2016.12.11 22:10:45.067 3: ZWave_SENSOR_NOTIFICATION_29: secStart older than 6 seconds detected, secUnlock will call Zwave_secEnd
2016.12.11 22:11:02.285 4: ZWDongle_Read ZWDongle_0: rcvd 0004001d029840 (request APPLICATION_COMMAND_HANDLER), sending ACK
2016.12.11 22:11:02.286 5: SW: 06
2016.12.11 22:11:02.288 5: ZWDongle_0: dispatch 0004001d029840
2016.12.11 22:11:02.289 4: CMD:APPLICATION_COMMAND_HANDLER ID:1d ARG:029840 CB:00
2016.12.11 22:11:09.291 3: ZWave_SENSOR_NOTIFICATION_29: secStart older than 6 seconds detected, secUnlock will call Zwave_secEnd

Code Auswählen

Internals: 
   DEF        e345c452 29 
   Frame_01 
   IODev      ZWDongle_0 
   LASTInputDev ZWDongle_0 
   MSGCNT     92 
   NAME       ZWave_SENSOR_NOTIFICATION_29 
   NR         317 
   STATE      closed 
   TYPE       ZWave 
   ZWDongle_0_MSGCNT 92 
   ZWDongle_0_RAWMSG 0004001d1998818b6b089ede9ad86882fc28e630b82bd558ff850b33de29 
   ZWDongle_0_TIME 2016-12-11 21:56:45 
   ZWaveSubDevice no 
   homeId     e345c452 
   isWakeUp   1 
   lastMsgSent 1481489817.82236 
   nodeIdHex  1d 
   secTime    1481490662.29033 
   Readings: 
     2016-12-09 18:28:30   SECURITY        ENABLED 
     2016-12-09 21:49:29   SEND_DATA       failed:00 
     2016-12-11 21:55:44   alarm_AccessControl Window/Door is closed, notificationIsOn 
     2016-12-11 21:55:28   alarm_HomeSecurity Motion Detection - Unknown Location, notificationIsOn 
     2016-12-11 21:54:37   assocGroup_1    Max 8 Nodes ZWDongle_0 
     2016-12-11 21:54:38   assocGroup_2    Max 8 Nodes 
     2016-12-11 21:54:37   assocGroups     2 
     2016-12-11 21:55:44   battery         32 % 
     2016-12-11 21:54:35   configAutoReportBatteryTime 12 
     2016-12-11 21:54:35   configAutoReportDoorWindowStateTime 12 
     2016-12-11 21:54:35   configAutoReportIlluminationTime 12 
     2016-12-11 21:56:43   configAutoReportTemperatureTime 12 
     2016-12-11 21:56:44   configAutoReportTickInterval 30 
     2016-12-11 21:56:44   configBasicSetLevel 255 
     2016-12-11 21:56:44   configCustomerFunction 4 
     2016-12-11 21:56:44   configIlluminationDifferentialReport 0 
     2016-12-11 21:56:44   configLightThreshold 99 
     2016-12-11 21:56:44   configMultiSensorFunctionSwitch 4 
     2016-12-11 21:56:44   configOperationMode 8 
     2016-12-11 21:56:45   configPIRReDetectIntervalTime 3 
     2016-12-11 21:56:45   configPIRSensitivity 80 
     2016-12-11 21:56:45   configTemperatureDifferentialReport 1 
     2016-12-11 21:56:45   configTurnOffLightTime 4 
     2016-12-11 21:55:44   luminance       6 % 
     2016-12-09 18:28:42   model           Philio Technology Corporation PST02-A 4 in 1 Multi-Sensor 
     2016-12-09 18:28:42   modelConfig     philio/pst02.xml 
     2016-12-09 18:28:42   modelId         013c-0002-000c 
     2016-12-10 08:14:06   neighborUpdate  done 
     2016-12-09 21:42:08   state           configOperationMode 8 
     2016-12-11 21:55:44   temperature     25.0 C 
     2016-12-11 21:56:57   timeToAck       0.092 
     2016-12-11 21:56:57   transmit        OK 
     2016-12-11 21:56:43   wakeup          notification 
   SendStack: 
     sentackget:131d03861331250b 
     get:131d03861386250c 
     get:131d03861384250d 
     get:131d0386135e250e 
     set:131d0298402510 
     set:131d0a98801ec1ca50510f17b52511 
     set:131d0a9880daf7ad79a46044e62512 
     set:131d0a98804bdf27270ccd8d832513 
     set:131d0a988013d6118d21bddc432514 
     set:131d0a9880e9faec99aff4ff3e2515 
     set:131d0a988012167ba4209a30b62516 
     set:131d0a988050071a5c16203f6b2517 
     set:131d0a9880582d3fa38f4f21fb2518 
     set:131d0a98806d0f68ed211935312519 
     set:131d0a9880e2b13a9330fe799b251a 
     set:131d0a988019b40df8836c4894251b 
     set:131d0a9880fcbeaeb653bee8f6251c 
     set:131d0a9880325f5034b90d6118251d 
     set:131d0a988057a8403761d5b4fe251e 
   secMsg: 
     8505 get ZWave_SENSOR_NOTIFICATION_29 associationGroups 
   Secnonce: 
     12: 
       nonce      12167ba4209a30b6 
       timeStamp  1481490228.10585 
     13: 
       nonce      13d6118d21bddc43 
       timeStamp  1481490184.41603 
     19: 
       nonce      19b40df8836c4894 
       timeStamp  1481490568.75829 
     1e: 
       nonce      1ec1ca50510f17b5 
       timeStamp  1481489817.82169 
     29: 
       nonce      2923cf83e3bc6197 
       timeStamp  1481489800.3939 
     32: 
       nonce      325f5034b90d6118 
       timeStamp  1481490638.06751 
     4b: 
       nonce      4bdf27270ccd8d83 
       timeStamp  1481490169.39011 
     50: 
       nonce      50071a5c16203f6b 
       timeStamp  1481490242.41115 
     57: 
       nonce      57a8403761d5b4fe 
       timeStamp  1481490662.29072 
     58: 
       nonce      582d3fa38f4f21fb 
       timeStamp  1481490345.53691 
     6d: 
       nonce      6d0f68ed21193531 
       timeStamp  1481490463.00396 
     Da: 
       nonce      daf7ad79a46044e6 
       timeStamp  1481489876.53989 
     Db: 
       nonce      dbfadec559d2b3ea 
       timeStamp  1481489797.39694 
     E2: 
       nonce      e2b13a9330fe799b 
       timeStamp  1481490544.74118 
     E9: 
       nonce      e9faec99aff4ff3e 
       timeStamp  1481490203.23437 
     Fc: 
       nonce      fcbeaeb653bee8f6 
       timeStamp  1481490592.1539 
Attributes: 
   IODev      ZWDongle_0 
   classes    ZWAVEPLUS_INFO BATTERY ALARM ASSOCIATION CONFIGURATION MANUFACTURER_SPECIFIC VERSION SENSOR_BINARY SENSOR_MULTILEVEL WAKE_UP ASSOCIATION_GRP_INFO POWERLEVEL DEVICE_RESET_LOCALLY MULTI_CMD SECURITY FIRMWARE_UPDATE_MD MARK BASIC 
   extendedAlarmReadings 1 
   room       ZWave 
   secure_classes BATTERY ALARM ASSOCIATION CONFIGURATION SENSOR_BINARY SENSOR_MULTILEVEL WAKE_UP MARK 
   stateFormat {(split(/,|is /, ReadingsVal($name,"alarm_AccessControl","")))[1]} 
   vclasses   ALARM:4 ASSOCIATION:2 ASSOCIATION_GRP_INFO:1 BASIC:0 BATTERY:1 CONFIGURATION:1 DEVICE_RESET_LOCALLY:1 FIRMWARE_UPDATE_MD:2 MANUFACTURER_SPECIFIC:2 MULTI_CMD:1 POWERLEVEL:1 SECURITY:1 SENSOR_BINARY:2 SENSOR_MULTILEVEL:5 VERSION:2 WAKE_UP:2 ZWAVEPLUS_INFO:2

Wenn ich etwas bestimmtes probieren darf, bitte melden.
Gruß, Christian

Titel: Antw:UZB1 Stick: Lizenz schaltet AES Security frei?
Beitrag von: krikan am 11 Dezember 2016, 22:27:06

Wichtiges vergessen:
Im Zeitraum zwischen den beiden lists kommen keine Events mehr durch. Dazwischen liegt auch keine WUN. Nach einer WUN erholt es sich wieder und Events kommen durch.

Titel: Antw:UZB1 Stick: Lizenz schaltet AES Security frei?
Beitrag von: buspirat am 12 Dezember 2016, 23:57:25

Hallo Andreas,

ich habe mir den letzten Crashlog den ich Dir per E-Mail
geschickt hatte nochmal genau angesehen: In 10_ZWave.pm
ist die "pSS:" Meldung in 10_ZWave.pm aktiv, die NONCEs sind durchnummeriert.
Zusätzlich noch der Data::Dumper() in ZWDongle_shiftSendStack().

Der Übersicht halber die relevanten Meldungen am Stück:

Code Auswählen


2016.12.01 22:24:51 1: pSS: ZWave_SENSOR_NOTIFICATION_44, ack sentset:132c0a9880cda12b7c2a4d147a25ce  omsg:ce
2016.12.01 22:24:51 1: pSS: ZWave_SENSOR_NOTIFICATION_44, ack sentset:132c0a9880ced6f55c507d1ff125cf  omsg:cf
2016.12.01 22:24:51 1: pSS: ZWave_SENSOR_NOTIFICATION_44, ack sentset:132c0a9880cffba71648715d4825d0  omsg:d0
2016.12.01 22:24:52 1: pSS: ZWave_SENSOR_NOTIFICATION_44, ack sentset:132c0a9880d0ae995d353673a325d1  omsg:d1

# Jetzt kommt der Fehler in der Kommunikation.
# -> Paket wird in ZWDongle_ProcessSendStack() entfernt:
# Hinweis: Der SendStack ist nach dem "shift" in ZWDongle_shiftSendStack() leer.

2016.12.01 22:24:54 1: DEBUG: Dumping hash in ZWDongle_shiftSendStack: $VAR1 = {
          'WaitForAck' => 2,
          'SendStack' => [
                           '011100132c0a9880d123839fb30c495f25d273'
                         ],
2016.12.01 22:24:54 1: DEBUG: SendStack after shift (txt: no response from device): $VAR1 = [];
2016.12.01 22:24:54 4: no response from device, removing 011100132c0a9880d123839fb30c495f25d273 from dongle sendstack

# debug-Dump Meldungen später
2016.12.01 22:25:34 3: ZWave_SENSOR_NOTIFICATION_44: secStart older than 6 seconds detected, secUnlock will call Zwave_secEnd
2016.12.01 22:25:34 1: HASH DUMP in secUnlock before calling secEnd(): $VAR1 = {
          'SendStack' => [
                           'sentset:132c0a9880d123839fb30c495f25d2',
                           'set:132c0a9880d24c2ec20d99ed8625d3'
                         ],

-> es gibt nie eine "pSS:" Meldung für "132c0a9880d1xxxxxxx",
die Bearbeitung der "next" Nachricht findet evtl. direkt innerhalb
von 00_ZWDongle.pm statt, ZWDongle_Read() kann z.B. das auslösen.

Hier ist der Code in ZWDongle_ProcessSendStack(), der die Nachricht vom Stack löscht:

Code Auswählen


    } elsif($hash->{WaitForAck} == 2 && $ts-$hash->{SendTime} >= 2) {
      ZWDongle_shiftSendStack($hash, 1, 4, "no response from device");
    }
    ...
    # SendStack ist leer (siehe debug Output) -> vorzeitiger Rücksprung.
      return if(!@{$hash->{SendStack}} ||
               $hash->{WaitForAck} ||
               !DevIo_IsOpen($hash));

Der "ZWave_processSendStack()" Code in 10_ZWave.pm sieht so aus:

Code Auswählen


  IOWrite($hash,
          $hash->{homeId}.($hash->{route}?",".$hash->{route}:""),
          "00$msg");
  $ss->[0] = "sent$type:$msg";

Ich denke hier liegt das Problem: Obwohl der SendStack
durch das "no response from device" geleert wurde,
fügen wir im SendStack an Position 0 das "sent$type:$msg" ein.

An genau die

Code Auswählen

"$ss->[0] = sentXXX" Stelle werde ich einen Debug-Logger die nächsten Tage einbauen und sowohl den SendStack als auch die aktuelle $msg rausloggen.
Bei mir im Log kommt zwischen dem letzten "pSS:" und dem "Crash" noch das eine oder andere ZWDongle_Read(), da könnte im 00_ZWDongle.pm schon die nächste Nachricht bearbeitet werden.
(zumindest von meinem Halbwissen vom Code her ;))

Durch das Logging wissen wir dann, ob wir uns a) eventuell innerhalb von 00_ZWDongle.pm verlaufen und die Kontrolle erst an 10_ZWave.pm zurückgeht, wenn die Nachricht vom Stack wegen Unzustellbarkeit bereits gelöscht wurde.

oder b) wir nach dem IOWrite() keinen Rückgabewert der Funktion prüfen, ob die letzte Nachricht überhaupt sauber verschickt wurde. Legen wir dann die "sentxxx" Nachricht auf den Stack, kommt alles zum Erliegen.

VG,
Thomas

Titel: Antw:UZB1 Stick: Lizenz schaltet AES Security frei?
Beitrag von: buspirat am 13 Dezember 2016, 00:04:17

Anbei noch ein rudimentärer Callgraph für den Zwave-Stack.
Ist sehr unvollständig und ohne Security-Teil.
Geholfen hat er dennoch beim Debugging :)

Erstellt mit "yED".

Titel: Antw:UZB1 Stick: Lizenz schaltet AES Security frei?
Beitrag von: A.Harrenberg am 13 Dezember 2016, 18:27:35

Hi Thomas,

Ich hatte mich da auf den Ablauf der Nonce konzentriert und noch nicht so sehr auf den Stack, schön das Du dazu gekommen bist!

Zitat von: buspirat am 12 Dezember 2016, 23:57:25
Der Übersicht halber die relevanten Meldungen am Stück:

Ok, ich bin gerade nicht zu Hause am Rechner, aber das eine ist doch der Stack vom Dongle und das andere ist der Stack vom Device. Ich muss mir den Ablauf da auch noch mal in Ruhe anschauen, für mich sieht es jetzt gerade danach aus das der "shift" im Dongle-Sendstack fälschlicherweise den Stack im Device nicht korrigiert, hier müsste mMn im Device-Stack ein "next" ausgelöst werden.

Zitat von: buspirat am 12 Dezember 2016, 23:57:25
-> es gibt nie eine "pSS:" Meldung für "132c0a9880d1xxxxxxx",
die Bearbeitung der "next" Nachricht findet evtl. direkt innerhalb
von 00_ZWDongle.pm statt, ZWDongle_Read() kann z.B. das auslösen.

Hier kann ich Dir jetzt nicht folgen...
ZWDongle_Read() sollte mMn keinen direkten Einfluß auf die Stacks haben, außer dadurch das bei erkannten ACK die versendete Nachricht vom Dongle-Sendstack genommen wird und das ACK dann auch im Device-SendStack gemeldet wird...

Zitat von: buspirat am 12 Dezember 2016, 23:57:25
Der "ZWave_processSendStack()" Code in 10_ZWave.pm sieht so aus:

Code Auswählen Erweitern
IOWrite($hash, $hash->{homeId}.($hash->{route}?",".$hash->{route}:""), "00$msg"); $ss->[0] = "sent$type:$msg";

Ich denke hier liegt das Problem: Obwohl der SendStack
durch das "no response from device" geleert wurde,
fügen wir im SendStack an Position 0 das "sent$type:$msg" ein.

Ist jetzt "offline" nicht so einfach das alles nachzuvollziehen. Ich muss mir das zu Hause auch noch mal in Ruhe anschauen und das mal dahingehend analysieren.
Das "sent" wird mMn gesetzt sobald der Befehl vom Controller mit dem ersten ACK bestätigt wurde. Das Problem wäre dann das nach dem Ausbleiben des ACK vom Empfänger das nicht entfernt wird..

Ich meine der normale Ablauf sieht so aus:

Nachricht liegen mit set:<msg> oder get:<msg> auf dem Stack.
Die oberste wird an den Controller geschickt, der bestätigt den Empfang mit ACK -> Kennung auf dem Stack wird in sentset: bzw. sentget: geändert.
Falls ACK vom Empfänger kommt:
- sentset: Nachrichten werden entfernt
- sentget: Nachrichten bekommen eine neue Kennung (habe ich gerade vergessen wie es heißt) und es wird auf den Empfang der Antwort gewartet
Falls Nachricht vom Empfänger kommt und die gleiche Klasse wir der get-Befehl hat wird es als Antwort gedeutet und auch die (umbeannte) sentget: Nachricht wird vom Stack entfernt.

Problem ist hier das die ACK von den Geräten keine CallBack-ID mehr haben und daher nicht mehr ein-eindeutig zugeordnet werden können.

Zitat von: buspirat am 12 Dezember 2016, 23:57:25
An genau die
Code Auswählen Erweitern
"$ss->[0] = sentXXX" Stelle werde ich einen Debug-Logger die nächsten Tage einbauen und sowohl den SendStack als auch die aktuelle $msg rausloggen.
Bei mir im Log kommt zwischen dem letzten "pSS:" und dem "Crash" noch das eine oder andere ZWDongle_Read(), da könnte im 00_ZWDongle.pm schon die nächste Nachricht bearbeitet werden.
(zumindest von meinem Halbwissen vom Code her ;))

Durch das Logging wissen wir dann, ob wir uns a) eventuell innerhalb von 00_ZWDongle.pm verlaufen und die Kontrolle erst an 10_ZWave.pm zurückgeht, wenn die Nachricht vom Stack wegen Unzustellbarkeit bereits gelöscht wurde.

oder b) wir nach dem IOWrite() keinen Rückgabewert der Funktion prüfen, ob die letzte Nachricht überhaupt sauber verschickt wurde. Legen wir dann die "sentxxx" Nachricht auf den Stack, kommt alles zum Erliegen.

Das Logging sollte auf jeden Fall helfen das einfach zu erkennen.
Ich versuche das obige in den nächsten Tagen mal gedanklich nachzuspielen, allerdings wird jetzt die freie Zeit gerade ein wenig knapp...

Gruß,
Andreas.

Titel: Antw:UZB1 Stick: Lizenz schaltet AES Security frei?
Beitrag von: A.Harrenberg am 13 Dezember 2016, 21:25:10

Hi,

das hier habe ich mir mal zusammengebastelt als ich was für Security nachvollziehen musste...
Ist aber auch nur ZWave_processSendStack.

Gruß,
Andreas.

Titel: Antw:UZB1 Stick: Lizenz schaltet AES Security frei?
Beitrag von: buspirat am 13 Dezember 2016, 21:31:19

Zitat von: A.Harrenberg am 13 Dezember 2016, 18:27:35
für mich sieht es jetzt gerade danach aus das der "shift" im Dongle-Sendstack fälschlicherweise den Stack im Device nicht korrigiert, hier müsste mMn im Device-Stack ein "next" ausgelöst werden.

Treffer! :)

Im aktuellen Debug Log sieht man es deutlich: Der Dongle-Stack entfernt die Nachricht wegen "no response from device" in ZWDongle_ProcessSendStack(), im Device-Stack bleibt die Nachricht liegen. Aktuelle Logdatei per E-Mail.

Deine Erklärung hat mir geholfen, daß sofort nachzuvollziehen. Irgendwie bin ich davon ausgegangen, daß es nur einen globalen SendStack gibt. Ist natürlich wieder mal Käse, es gibt den Stack vom Dongle und den pro Device.

Ich schaue mir jetzt die Timeout-Timer-Logik im Device-Stack an. Soweit ich mich erinnere war der jedoch nicht aktiv, da es sich um ein Wakeup-Device handelt.

Dein Flowchart werde ich mir auch ansehen. Mit was hast Du denn das erstellt?

Viele Grüße
Thomas

Titel: Antw:UZB1 Stick: Lizenz schaltet AES Security frei?
Beitrag von: A.Harrenberg am 13 Dezember 2016, 22:25:48

Hi Thomas,

Zitat von: buspirat am 13 Dezember 2016, 21:31:19
Im aktuellen Debug Log sieht man es deutlich: Der Dongle-Stack entfernt die Nachricht wegen "no response from device" in ZWDongle_ProcessSendStack(), im Device-Stack bleibt die Nachricht liegen. Aktuelle Logdatei per E-Mail.

habe mir den Code eben auch noch mal angeschaut und wie jedes mal auf's neue verstehe ich ihn nicht. >:(
Fängt bei mir immer damit das ich darüber stolper das man processSendStack mit "next" aufruft aber da gar keine direkte Aktion mit verknüpft ist...
Da kann ich aber frühestens am Freitag noch mal reinschauen.

Zitat von: buspirat am 13 Dezember 2016, 21:31:19
Ich schaue mir jetzt die Timeout-Timer-Logik im Device-Stack an. Soweit ich mich erinnere war der jedoch nicht aktiv, da es sich um ein Wakeup-Device handelt.

An der Stelle war ich eben auch mal, da gibt es nämlich einen Kommentar im Code der ungefähr "warten bis der retry-counter die msg vom Stack entfernt" lautet. Ich will nicht ausschliessen das hier ohne den Timer genau diese Aktion fehlschlägt bzw. gar nicht passieren kann...

Ich schaue mir aber auch noch mal die Timer aus Security an, nicht das ich dusseligerweise irgendwie den gleichen hash nutze und dann bei einem RemoveTimer beide Timer gelöscht werden. Denke ich aber nicht, das hätte sicherlich viel mehr auswirkungen auf das system.

Zitat von: buspirat am 13 Dezember 2016, 21:31:19
Dein Flowchart werde ich mir auch ansehen. Mit was hast Du denn das erstellt?

XMind, werde mir yED aber auch mal ansehen.

Gruß,
Andreas.

Titel: Antw:UZB1 Stick: Lizenz schaltet AES Security frei?
Beitrag von: buspirat am 13 Dezember 2016, 22:39:12

Zitat von: A.Harrenberg am 13 Dezember 2016, 18:27:35
für mich sieht es jetzt gerade danach aus das der "shift" im Dongle-Sendstack fälschlicherweise den Stack im Device nicht korrigiert, hier müsste mMn im Device-Stack ein "next" ausgelöst werden.

die Frage ist hier wie man das "next" vom Dongle beim richtigen Device auslöst: Schickt man eine spezielle Message von ZWDongle_ProcessSendStack() via ZWDongle_Parse() vom Dongle zum Device? Oder Dispatch() direkt aufrufen?

Der Aufräum-Code wird benötigt für
ZWDongle_shiftSendStack($hash, 1, 4, "no response from device");
und
ZWDongle_shiftSendStack($hash, 1, 1, "ERROR: max send retries reached");

in 00_ZWDongle.pm:ZWDongle_ProcessSendStack().

@rudolfkoenig: Hast Du eine Idee zur Architektur?

Hintergrund: Da es ein Wakeup-Device ist wird in 10_ZWave.pm kein Timer gesetzt.

VG,
Thomas

Titel: Antw:UZB1 Stick: Lizenz schaltet AES Security frei?
Beitrag von: buspirat am 13 Dezember 2016, 22:47:22

Zitat von: A.Harrenberg am 13 Dezember 2016, 22:25:48
Da kann ich aber frühestens am Freitag noch mal reinschauen.
An der Stelle war ich eben auch mal, da gibt es nämlich einen Kommentar im Code der ungefähr "warten bis der retry-counter die msg vom Stack entfernt" lautet. Ich will nicht ausschliessen das hier ohne den Timer genau diese Aktion fehlschlägt bzw. gar nicht passieren kann...

jetzt haben sich unsere Antworten überschnitten :)

Der Timer wird sehr wahrscheinlich nicht gesetzt, da es ein Wakeup-Device ist. Es gibt bisher keinen Mechanismus, daß der Dongle den Device-Stack explizit benachrichtigt, wenn er eine Nachricht verwirft. Zumindest konnte ich keine entdecken.

Das gleiche Fehlverhalten sollten auch bei einem MaxSendTries auftreten, da der ZME Stick keine extra Message für den nicht erfolgten Versand generiert bzw. auch nicht wissen kann, wieviele Versuche FHEM überhaupt unternimmt. Sprich wenn da kein gültiges NO_ACK zurück kommt, dann bleibt der Device-Stack vermutlich auch stecken.

Ein explizites Notify vom Dongle-Stack zum Device-Stack ist vermutlich besser als alles über Timer zu lösen, deswegen auch meine Anfrage an den großen Meister ;)

Titel: Antw:UZB1 Stick: Lizenz schaltet AES Security frei?
Beitrag von: rudolfkoenig am 14 Dezember 2016, 08:16:25

Zitat@rudolfkoenig: Hast Du eine Idee zur Architektur?

Sollte ich haben, bis auf das, was ich verdraengt habe.
Fuer Security muss ich aber auf Andreas verweisen, das habe ich immer noch nicht verinnerlicht.

Kommunikation von ZWDongle zu ZWave muss ueber Dispatch laufen, damit andere Module wie FHEM2FHEM/RFR/STACKABLE_CC/usw. sich zwischenhaengen koennen. In diesem Fall wuerde ich eine spezielle Nachricht mit dem passenden Callbackid oder nodeId schicken. Das muss im ZWave_Parse rechtzeitig abgefragt werden.

Titel: Antw:UZB1 Stick: Lizenz schaltet AES Security frei?
Beitrag von: buspirat am 14 Dezember 2016, 10:15:57

Zitat von: rudolfkoenig am 14 Dezember 2016, 08:16:25
Kommunikation von ZWDongle zu ZWave muss ueber Dispatch laufen, damit andere Module wie FHEM2FHEM/RFR/STACKABLE_CC/usw. sich zwischenhaengen koennen. In diesem Fall wuerde ich eine spezielle Nachricht mit dem passenden Callbackid oder nodeId schicken. Das muss im ZWave_Parse rechtzeitig abgefragt werden.

eventuell könnte man die bestehende Nachricht auf dem Dongle-Stack nehmen und in eine NO_ACK-Nachricht umbauen?
Checksumme und Co müsste natürlich angepasst werden. Oder ist das zu fragil und lieber eine neue Nachricht erzeugen?
Die bestehnde Nachricht hätte den Charme, daß die NodeID und Co schon passt.

Titel: Antw:UZB1 Stick: Lizenz schaltet AES Security frei?
Beitrag von: A.Harrenberg am 14 Dezember 2016, 11:25:05

Hi Rudi,

Zitat von: rudolfkoenig am 14 Dezember 2016, 08:16:25
Sollte ich haben, bis auf das, was ich verdraengt habe.
Fuer Security muss ich aber auf Andreas verweisen, das habe ich immer noch nicht verinnerlicht.

Security ist doch "transparent" implementiert ,-)
Nee, an der Stelle mit den verschiedenen Stacks gibt es eigentlich nur die Besonderheit das auch wenn es ein WU-Gerät ist und noch keine WUN empfangen wurde bereits trotzdem ein NONCE-Request vom Geräte kommen kann. Die Antwort darauf, also das versenden der NONCE wird dann am WU-Stack vorbei direkt per addtosendstack auf den normalen Stack gelegt. Ab da sollte im Stack nichts mehr besonderes für Security sein.

An einer Stelle gibt es noch ein wenig Code damit fehlgeschlagene Transmit während Security auch den Befehl vom Security-Stack entfernen, das hat aber keinen Einfluß auf die "normalen" Stacks.

Zitat von: rudolfkoenig am 14 Dezember 2016, 08:16:25
Kommunikation von ZWDongle zu ZWave muss ueber Dispatch laufen, damit andere Module wie FHEM2FHEM/RFR/STACKABLE_CC/usw. sich zwischenhaengen koennen. In diesem Fall wuerde ich eine spezielle Nachricht mit dem passenden Callbackid oder nodeId schicken. Das muss im ZWave_Parse rechtzeitig abgefragt werden.

Ich wäre auch dafür an der Stelle eine besondere Nachricht zu generieren die man in ZWave dann explizit abfragen kann anstelled das man hier eine NO_ACK Bedingung erzeugt.

Ist aber interessant das dies alles bisher nicht wirklich aufgefallen ist. Zeugt eigentlich davon das die Übertragung an sich recht stabil und robust ist.

Wenn wir das mit eine solchen Nachricht und entsprechendem Stackeingriff in processSendStack hinbekommen dann sollte das zusammen mit der Änderung das mehr als eine NONCE gleichzeitig aktiv sein kann eine deutliche Robustheitssteigerung bewirken.

Um doppelte (oder dreifache) Arbeit zu vermeiden, wer kümmert sich denn um die Generierung einer solchen Nachricht und die Änderungen im ZWave-code um das auf den Stack anzuwenden?

Gruß,
Andreas.

Titel: Antw:UZB1 Stick: Lizenz schaltet AES Security frei?
Beitrag von: buspirat am 14 Dezember 2016, 22:18:33

Zitat von: A.Harrenberg am 14 Dezember 2016, 11:25:05
Um doppelte (oder dreifache) Arbeit zu vermeiden, wer kümmert sich denn um die Generierung einer solchen Nachricht und die Änderungen im ZWave-code um das auf den Stack anzuwenden?

ich kann die Änderung zumindest testen :) Manchmal dauert es fünf Minuten bis der Fehler auftritt, manchmal zwanzig Minuten wild mit dem Magneten vom Fenstersensors rumwedeln. Die eigentliche Codeänderung traue ich mir bei meinem halbwissen über Z-Wave und FHEM noch nicht zu.

Mein FHEM verwalte ich mittlerweile lokal via git, also kann ich jederzeit Änderungen reinnehmen und z.B. problemlos meine Debug-Meldungen wieder obendrüber stülpen. Auschecken aus einer SVN-Branch wäre auch kein Problem.

VG,
Thomas

Titel: Antw:UZB1 Stick: Lizenz schaltet AES Security frei?
Beitrag von: buspirat am 14 Dezember 2016, 22:21:24

Hi Andreas,

Zitat von: A.Harrenberg am 14 Dezember 2016, 11:25:05
... mit der Änderung das mehr als eine NONCE gleichzeitig aktiv sein kann eine deutliche Robustheitssteigerung bewirken.

soll ich den letzten Code von Dir noch versuchen zu quälen oder sollen wir erst abwarten bis der Fix für das ursprüngliche Problem verfügbar ist und dann die NONCE-Änderung auf Herz und Nieren prüfen?

VG,
Thomas

Titel: Antw:UZB1 Stick: Lizenz schaltet AES Security frei?
Beitrag von: A.Harrenberg am 15 Dezember 2016, 07:02:06

Hi Thomas,

Zitat von: buspirat am 14 Dezember 2016, 22:21:24
soll ich den letzten Code von Dir noch versuchen zu quälen oder sollen wir erst abwarten bis der Fix für das ursprüngliche Problem verfügbar ist und dann die NONCE-Änderung auf Herz und Nieren prüfen?

ja bitte, aber dazu dann die nochmals korrigierte 10_ZWave.pm von hier (https://forum.fhem.de/index.php/topic,60976.msg537330.html#msg537330) nehmen oder einfach in der Funktion ZWave_secRetrieveNonce in Zeile 3624 die Kommentierung vor dem "delete($hash->{secNonce}{$s_nonce_id_hex});" entfernen.
Die Probleme sind ja voneinander getrennt, auch wenn das dauernde asynchrone Senden der nonce das andere Problem durch den erhöhten Traffic wahrscheinlich eher hervorruft.

Gruß,
Andreas.

Titel: Antw:UZB1 Stick: Lizenz schaltet AES Security frei?
Beitrag von: buspirat am 15 Dezember 2016, 22:05:40

Hi Andreas,

Zitat von: A.Harrenberg am 15 Dezember 2016, 07:02:06
Hi Thomas,ja bitte, aber dazu dann die nochmals korrigierte 10_ZWave.pm

habe mir die Code-Änderungen im Detail durchgesehen, gefallen mir gut.

Einzig zu diesem Code habe ich einen Kommentar:

Code Auswählen


sub ZWave_secCreateNonce()
+    do {
+      $nonce = ZWave_secGetNonce();
+      $nonce_id = substr($nonce, 0, 2);
+    } until (!$hash->{secNonce}{$nonce_id});

wenn ein Angreifer / schlechtes Device es schafft innerhalb der zehn Sekunden bis zum Aufräumen mehr NONCES abzufragen als die zweitstellige ID-Reservierung hergibt, dann verfängt sich FHEM in einer Endlosschleife. Da sollte auf jeden Fall einen Abbruch-Bedingung rein, z.B. wenn mehr als 255 NONCES durchprobiert wurden. Oder lass es 1024 sein, sollte im realen Betrieb nie auftreten.

Werde jetzt den Code testen :)

VG,
Thomas

Titel: Antw:UZB1 Stick: Lizenz schaltet AES Security frei?
Beitrag von: A.Harrenberg am 16 Dezember 2016, 07:31:42

Hi,

Zitat von: buspirat am 15 Dezember 2016, 22:05:40
Einzig zu diesem Code habe ich einen Kommentar:
...
wenn ein Angreifer / schlechtes Device es schafft innerhalb der zehn Sekunden bis zum Aufräumen mehr NONCES abzufragen als die zweitstellige ID-Reservierung hergibt, dann verfängt sich FHEM in einer Endlosschleife. Da sollte auf jeden Fall einen Abbruch-Bedingung rein, z.B. wenn mehr als 255 NONCES durchprobiert wurden. Oder lass es 1024 sein, sollte im realen Betrieb nie auftreten.

ist mir bewußt und noch auf meiner Liste. Wollte erst mal sichergehen das es überhaupt funktioniert.
Weiß noch nicht so richtig wie ich das implementieren soll. Getrennter Counter den ich bei jedem schreiben / löschen eine Nonce incrementiere/decrementiere oder ob ich jedesmal über das Hash iteriere und zähle. Da der Hash im Normalfall nicht groß werden dürfte tendiere ich momentan dazu das jedesmal zu zählen.
Die Variante die Versuche die Nonce zu generieren zu zählen lasse ich mir auch noch mal durch den Kopf gehen.

Gruß,
Andreas.

Titel: [PATCH] Update Nonce Handling
Beitrag von: A.Harrenberg am 29 Dezember 2016, 18:12:26

Hi Rudi,

anbei ein Patch der erlaubt das mehr als eine NONCE "aktiv" sein kann. Das verbessert die Robustheit wenn mal eine Nonce "verlorengegangen" ist und der Ablauf dann asynchron wird, d.h. es wird ein neue NONCE erzeugt bevor das Paket mit der alten NONCE angekommen ist. Normalerweise führt das zu einer sehr langen Schleife in der die Pakete dauernd weggeworfen werden bis das Gerät irgendwann aufgibt. Die Nonce haben nur eine gewisse Gültigkeitsdauer (10 Sekunden), .dh. wenn irgendwann mal eine übrigbleibt wird sie bei der nächsten Schleife entsorgt falls sie älter ist.

Falls mehr als 50 Nonce generiert wurden wird erst versucht alte Nonce wegzuräumen, falls danach selbst mit 512 Versuchen keine neue eindeutige Nonce generiert werden konnte wird abgebrochen.

Das Problem mit dem Sendstack ist damit aber nicht behoben...

Gruß,
Andreas.

Titel: Antw:UZB1 Stick: Lizenz schaltet AES Security frei?
Beitrag von: rudolfkoenig am 30 Dezember 2016, 11:11:37

Habs eingecheckt.

FHEM Forum

FHEM - Hausautomations-Systeme => ZWave => Thema gestartet von: buspirat am 18 November 2016, 13:37:11