Fhem via Razberry mit Danalock verbinden

[Bigsonic1]

Ich habe leider auch ab und zu das Problem das auf dem Stack ein Befehl "liegen" bleibt.
Bei Abwesenheit wird bei mir automatisch abgeschlossen, letztens als ich weg war, hat er statt abzuschliessen aufgeschlossen...  Gestern hat er statt aufzuschliessen abgeschlossen.
Gibt es da vllt. schon eine Lösung? Wäre echt super. 

[A.Harrenberg]

Hi,

Ich habe leider auch ab und zu das Problem das auf dem Stack ein Befehl "liegen" bleibt.
Bei Abwesenheit wird bei mir automatisch abgeschlossen, letztens als ich weg war, hat er statt abzuschliessen aufgeschlossen...  Gestern hat er statt aufzuschliessen abgeschlossen.
Gibt es da vllt. schon eine Lösung? Wäre echt super. 

nein, leider nicht. Die allgemeine Kommunikation mit ZWave wurde in den letzten Tagen von Rudi durch CallBack-IDs, diverse Umbauten am Stack und der Behandlung von CAN-Nachrichten deutlich verbessert. Das Problem das gelegentlich ein SECURITY-Befehl liegenbleibt behebt das aber leider nicht. Da ich in zwei Tagen bis Anfang Mai weg bin wird es bis dahin von mir da leider keine Lösung geben.

Gruß,
Andreas.

[Bigsonic1]

Da bei mir jeder Befehl im Stack liegen geblieben ist, wollte ich das Schloss neu Inkludieren...
mit Security geht es jetzt gar nicht mehr, etliche mal probiert.

Code Auswählen Erweitern

2016.03.23 09:08:30 2: autocreate: define ZWave_ENTRY_CONTROL_19 ZWave ee52057b 19 5e72985a807322
2016.03.23 09:08:30 2: autocreate: define FileLog_ZWave_ENTRY_CONTROL_19 FileLog ./log/ZWave_ENTRY_CONTROL_19-%Y.log ZWave_ENTRY_CONTROL_19
2016.03.23 09:08:31 2: ZWave get ZWave_ENTRY_CONTROL_19 model
2016.03.23 09:08:32 2: ZWDongle_ProcessSendStack: no ACK, resending message 01090013130272042502a5
2016.03.23 09:08:54 1: ZWave_ENTRY_CONTROL_19 SECURITY DISABLED (command dropped)
2016.03.23 09:08:57 2: ZWave set ZWave_ENTRY_CONTROL_19 neighborUpdate
2016.03.23 09:09:05 1: ZWave_ENTRY_CONTROL_19 SECURITY DISABLED (command dropped)
2016.03.23 09:09:05 2: ZWave get ZWave_ENTRY_CONTROL_19 battery
2016.03.23 09:09:08 2: ZWave get ZWave_ENTRY_CONTROL_19 battery
2016.03.23 09:09:12 1: ZWave_ENTRY_CONTROL_19 SECURITY DISABLED (command dropped)
2016.03.23 09:09:12 2: ZWave set ZWave_ENTRY_CONTROL_19 secSupportedReport

[A.Harrenberg]

Hi,

ungewöhnlich... Kannst Du mal in Dein Logfile schauen, da sollte normalerweise irgendwo der Grund ausgegeben werden warum Security DISABLED ist.

Hast Du vielleicht den Networkkey aus Versehen gelöscht?

Gruß,
Andreas.

[Bigsonic1]

Den Networkkey hab ich nicht verändert oder gelöscht.
Hab mal verbose auf 5 gesetzt:

Code Auswählen Erweitern

2016.03.23 14:33:48 5: Cmd: >define ZWAVE1 ZWDongle /dev/ttyACM0@115200<
2016.03.23 14:33:48 3: Opening ZWAVE1 device /dev/ttyACM0
2016.03.23 14:33:48 3: Setting ZWAVE1 serial parameters to 115200,8,N,1
2016.03.23 14:33:48 3: ZWAVE1 device opened
2016.03.23 14:33:48 4: ZWDongle_ReadAnswer arg:Clear regexp:wontmatch
2016.03.23 14:33:49 5: ZWDongle_ReadAnswer: select timeout
2016.03.23 14:33:49 4: ZWDongle *** get ZWAVE1 caps
2016.03.23 14:33:49 5: ZWDongle_Write 0007 ()
2016.03.23 14:33:49 5: SW: 01030007fb
2016.03.23 14:33:49 4: ZWDongle_ReadAnswer arg:caps regexp:^0107
2016.03.23 14:33:49 5: ACK received, removing 01030007fb from dongle sendstack
2016.03.23 14:33:49 4: ZWDongle_Read ZWAVE1: rcvd 01070501011504000001fe83ff88cf1f0000fb9f7da067008080008086000000e87300000e0000401a00 (answer SERIAL_API_GET_CAPABILITIES), sending ACK
2016.03.23 14:33:49 5: SW: 06
2016.03.23 14:33:49 4: ZWDongle_ReadAnswer for caps: 01070501011504000001fe83ff88cf1f0000fb9f7da067008080008086000000e87300000e0000401a00
2016.03.23 14:33:49 4: ZWDongle *** get ZWAVE1 homeId
2016.03.23 14:33:49 5: ZWDongle_Write 0020 ()
2016.03.23 14:33:49 5: SW: 01030020dc
2016.03.23 14:33:49 4: ZWDongle_ReadAnswer arg:homeId regexp:^0120
2016.03.23 14:33:49 5: ACK received, removing 01030020dc from dongle sendstack
2016.03.23 14:33:49 4: ZWDongle_Read ZWAVE1: rcvd 0120ee52057b01 (answer MEMORY_GET_ID), sending ACK
2016.03.23 14:33:49 5: SW: 06
2016.03.23 14:33:49 4: ZWDongle_ReadAnswer for homeId: 0120ee52057b01
2016.03.23 14:33:49 4: ZWDongle *** get ZWAVE1 random 32
2016.03.23 14:33:49 5: ZWDongle_Write 001c20 ()
2016.03.23 14:33:49 5: SW: 0104001c20c7
2016.03.23 14:33:49 4: ZWDongle_ReadAnswer arg:random regexp:^011c
2016.03.23 14:33:49 5: ACK received, removing 0104001c20c7 from dongle sendstack
2016.03.23 14:33:49 4: ZWDongle_Read ZWAVE1: rcvd 011c0120e992234069a5b43350f1df42e0250876799f653c70b204a2c4c5efda15b94bdc (answer ZW_GET_RANDOM), sending ACK
2016.03.23 14:33:49 5: SW: 06
2016.03.23 14:33:49 4: ZWDongle_ReadAnswer for random: 011c0120e992234069a5b43350f1df42e0250876799f653c70b204a2c4c5efda15b94bdc
2016.03.23 14:33:49 4: ZWDongle *** set ZWAVE1 timeouts 100 15
2016.03.23 14:33:49 5: ZWDongle_Write 0006640f ()
2016.03.23 14:33:49 5: SW: 01050006640f97
2016.03.23 14:33:49 4: ZWDongle_ReadAnswer arg:timeouts regexp:^0106
2016.03.23 14:33:49 5: ACK received, removing 01050006640f97 from dongle sendstack
2016.03.23 14:33:49 4: ZWDongle_Read ZWAVE1: rcvd 0106640f (answer SERIAL_API_SET_TIMEOUTS), sending ACK
2016.03.23 14:33:49 5: SW: 06
2016.03.23 14:33:49 4: ZWDongle_ReadAnswer for timeouts: 0106640f
2016.03.23 14:33:49 4: ZWDongle *** set ZWAVE1 setNIF 1 2 1 0
2016.03.23 14:33:49 5: ZWDongle_Write 000301020100 ()
2016.03.23 14:33:49 5: SW: 0107000301020100f9
2016.03.23 14:33:49 5: Cmd: >attr ZWAVE1 networkKey xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx<
2016.03.23 14:33:49 5: Cmd: >attr ZWAVE1 room ZWave<

2016.03.23 14:34:30 4: Connection accepted from WEB_192.168.178.51_52769
2016.03.23 14:34:30 4: WEB_192.168.178.51_52769 GET /fhem?detail=ZWave_ENTRY_CONTROL_19; BUFLEN:0
2016.03.23 14:34:30 4: name: /fhem?detail=ZWave_ENTRY_CONTROL_19 / RL:3977 / text/html; charset=UTF-8 / Content-Encoding: gzip
/
2016.03.23 14:34:30 4: Connection closed for WEB_192.168.178.51_52768: EOF
2016.03.23 14:34:30 4: WEB_192.168.178.51_52769 GET /fhem?cmd={ReadingsVal(%22ZWave_ENTRY_CONTROL_19%22,%22neighborUpdate%22,%22%22)}&XHR=1; BUFLEN:0
2016.03.23 14:34:30 5: Cmd: >{ReadingsVal("ZWave_ENTRY_CONTROL_19","neighborUpdate","")}<
2016.03.23 14:34:30 4: name: /fhem?cmd={ReadingsVal(%22ZWave_ENTRY_CONTROL_19%22,%22neighborUpdate%22,%22%22)}&XHR=1 / RL:21 / text/plain; charset=UTF-8 / Content-Encoding: gzip
/
2016.03.23 14:34:30 4: Connection accepted from WEB_192.168.178.51_52770
2016.03.23 14:34:30 4: WEB_192.168.178.51_52770 GET /fhem?cmd={AttrVal(%22ZWave_ENTRY_CONTROL_19%22,%22room%22,%22%22)}&XHR=1; BUFLEN:0
2016.03.23 14:34:30 5: Cmd: >{AttrVal("ZWave_ENTRY_CONTROL_19","room","")}<
2016.03.23 14:34:30 4: name: /fhem?cmd={AttrVal(%22ZWave_ENTRY_CONTROL_19%22,%22room%22,%22%22)}&XHR=1 / RL:26 / text/plain; charset=UTF-8 / Content-Encoding: gzip
/
2016.03.23 14:34:30 4: WEB_192.168.178.51_52770 GET /fhem?XHR=1&inform=type=status;filter=ZWave_ENTRY_CONTROL_19;since=1458740069;fmt=JSON&fw_id=607×tamp=1458740071744; BUFLEN:0
2016.03.23 14:34:31 4: CUL_HM_Resend: HM_29F26F nr 4
2016.03.23 14:34:32 4: WEB_192.168.178.51_52769 GET /fhem?cmd={ReadingsVal(%22ZWave_ENTRY_CONTROL_19%22,%22secSupportedReport%22,%22%22)}&XHR=1; BUFLEN:0
2016.03.23 14:34:32 5: Cmd: >{ReadingsVal("ZWave_ENTRY_CONTROL_19","secSupportedReport","")}<
2016.03.23 14:34:32 4: name: /fhem?cmd={ReadingsVal(%22ZWave_ENTRY_CONTROL_19%22,%22secSupportedReport%22,%22%22)}&XHR=1 / RL:21 / text/plain; charset=UTF-8 / Content-Encoding: gzip
/
2016.03.23 14:34:32 4: Connection accepted from WEB_192.168.178.51_52771
2016.03.23 14:34:32 4: WEB_192.168.178.51_52771 GET /fhem?cmd={ZWave_helpFn(%22ZWave_ENTRY_CONTROL_19%22,%22secSupportedReport%22)}&XHR=1; BUFLEN:0
2016.03.23 14:34:32 5: Cmd: >{ZWave_helpFn("ZWave_ENTRY_CONTROL_19","secSupportedReport")}<
2016.03.23 14:34:32 4: name: /fhem?cmd={ZWave_helpFn(%22ZWave_ENTRY_CONTROL_19%22,%22secSupportedReport%22)}&XHR=1 / RL:21 / text/plain; charset=UTF-8 / Content-Encoding: gzip
/
2016.03.23 14:34:33 4: WEB_192.168.178.51_52771 POST /fhem&detail=ZWave_ENTRY_CONTROL_19&dev.setZWave_ENTRY_CONTROL_19=ZWave_ENTRY_CONTROL_19&cmd.setZWave_ENTRY_CONTROL_19=set&arg.setZWave_ENTRY_CONTROL_19=secSupportedReport&val.setZWave_ENTRY_CONTROL_19=; BUFLEN:0
2016.03.23 14:34:33 5: Cmd: >set ZWave_ENTRY_CONTROL_19 secSupportedReport<
2016.03.23 14:34:33 1: ZWave_ENTRY_CONTROL_19 SECURITY DISABLED (command dropped)
2016.03.23 14:34:33 2: ZWave set ZWave_ENTRY_CONTROL_19 secSupportedReport
2016.03.23 14:34:33 5: ZWDongle_Write 0013130298002507 (ee52057b)
2016.03.23 14:34:33 5: SW: 010900131302980025074e
2016.03.23 14:34:33 5: Triggering ZWave_ENTRY_CONTROL_19 (1 changes)
2016.03.23 14:34:33 5: Notify loop for ZWave_ENTRY_CONTROL_19 secSupportedReport
2016.03.23 14:34:33 5: ACK received, WaitForAck=>2 for 010900131302980025074e
2016.03.23 14:34:33 4: ZWDongle_Read ZWAVE1: rcvd 011301 (answer ZW_SEND_DATA), sending ACK
2016.03.23 14:34:33 5: SW: 06
2016.03.23 14:34:33 5: ZWAVE1 dispatch 011301
2016.03.23 14:34:34 4: WEB_192.168.178.51_52771 GET /fhem?detail=ZWave_ENTRY_CONTROL_19&fw_id=; BUFLEN:0
2016.03.23 14:34:34 4: name: /fhem?detail=ZWave_ENTRY_CONTROL_19&fw_id= / RL:4012 / text/html; charset=UTF-8 / Content-Encoding: gzip
/
2016.03.23 14:34:34 4: Connection closed for WEB_192.168.178.51_52770: EOF
2016.03.23 14:34:34 4: WEB_192.168.178.51_52771 GET /fhem?cmd={ReadingsVal(%22ZWave_ENTRY_CONTROL_19%22,%22neighborUpdate%22,%22%22)}&XHR=1; BUFLEN:0
2016.03.23 14:34:34 5: Cmd: >{ReadingsVal("ZWave_ENTRY_CONTROL_19","neighborUpdate","")}<
2016.03.23 14:34:34 4: name: /fhem?cmd={ReadingsVal(%22ZWave_ENTRY_CONTROL_19%22,%22neighborUpdate%22,%22%22)}&XHR=1 / RL:21 / text/plain; charset=UTF-8 / Content-Encoding: gzip
/
2016.03.23 14:34:34 4: WEB_192.168.178.51_52769 GET /fhem?cmd={AttrVal(%22ZWave_ENTRY_CONTROL_19%22,%22room%22,%22%22)}&XHR=1; BUFLEN:0
2016.03.23 14:34:34 5: Cmd: >{AttrVal("ZWave_ENTRY_CONTROL_19","room","")}<
2016.03.23 14:34:34 4: name: /fhem?cmd={AttrVal(%22ZWave_ENTRY_CONTROL_19%22,%22room%22,%22%22)}&XHR=1 / RL:26 / text/plain; charset=UTF-8 / Content-Encoding: gzip
/
2016.03.23 14:34:34 4: WEB_192.168.178.51_52769 GET /fhem?XHR=1&inform=type=status;filter=ZWave_ENTRY_CONTROL_19;since=1458740073;fmt=JSON&fw_id=609×tamp=1458740075446; BUFLEN:0
2016.03.23 14:34:35 4: ZWDongle_Read ZWAVE1: rcvd 00130700007e (request ZW_SEND_DATA), sending ACK
2016.03.23 14:34:35 5: SW: 06
2016.03.23 14:34:35 5: device ack reveived, removing 010900131302980025074e from dongle sendstack
2016.03.23 14:34:35 5: ZWAVE1 dispatch 00130700007e
2016.03.23 14:34:35 4: CMD:ZW_SEND_DATA ID:00 ARG:007e CB:07
2016.03.23 14:34:35 4: ZWAVE1 transmit OK for CB 07, target ZWave_ENTRY_CONTROL_19

2016.03.23 14:35:10 2: ZWDongle_ProcessSendStack: no ACK, resending message 0107000301020100f9
2016.03.23 14:35:10 1: HMLAN_Parse: hmusb new condition ok
2016.03.23 14:54:08 1: ZWave_ENTRY_CONTROL_19 SECURITY DISABLED (command dropped)
2016.03.23 14:54:08 2: ZWave set ZWave_ENTRY_CONTROL_19 secSupportedReport

[A.Harrenberg]

Hi,

aus dem Log werde ich leider nicht schlau, existiert das Problem denn weiterhin oder ist es "verschwunden"?

Gruß,
Andreas.

[Bigsonic1]

Geht leider immer noch nicht, hab es mit einem anderen fhem-server versucht, mit dem gleichen zwave stick, aber das selbe Spiel:

Code Auswählen Erweitern

2016.04.05 10:49:47 3: Opening ZWDongle_0 device /dev/ttyACM0
2016.04.05 10:49:47 3: Setting ZWDongle_0 serial parameters to 115200,8,N,1
2016.04.05 10:49:47 3: ZWDongle_0 device opened
2016.04.05 10:49:48 1: Including ./log/fhem.save
2016.04.05 10:49:48 1: usb create starting
2016.04.05 10:49:48 3: Probing CUL device /dev/ttyAMA0
2016.04.05 10:49:49 3: Probing TCM_ESP3 device /dev/ttyAMA0
2016.04.05 10:49:49 3: Probing FRM device /dev/ttyAMA0
2016.04.05 10:49:54 1: usb create end
2016.04.05 10:49:54 0: Featurelevel: 5.7
2016.04.05 10:49:54 0: Server started with 51 defined entities (fhem.pl:11178/2016-04-03 perl:5.014002 os:linux user:fhem pid:2404)
2016.04.05 10:49:54 2: ZWDongle_ProcessSendStack: no ACK, resending message 0107000301020100f9
2016.04.05 10:58:09 2: autocreate: define ZWave_ENTRY_CONTROL_22 ZWave ee52057b 22 5e72985a807322
2016.04.05 10:58:09 2: autocreate: define FileLog_ZWave_ENTRY_CONTROL_22 FileLog ./log/ZWave_ENTRY_CONTROL_22-%Y.log ZWave_ENTRY_CONTROL_22
2016.04.05 10:58:10 2: ZWave get ZWave_ENTRY_CONTROL_22 model
2016.04.05 10:58:11 3: ZWave got config for polycontrol/doorlockV2BTZE.xml from ./FHEM/lib/fhem_zwave_deviceconfig.xml.gz
2016.04.05 10:58:33 1: ZWave_ENTRY_CONTROL_22 SECURITY DISABLED (command dropped)
2016.04.05 10:58:44 1: ZWave_ENTRY_CONTROL_22 SECURITY DISABLED (command dropped)

ich hab einen Z-wave.me usb stick, bei fhem steht: ZWDongle_0 version => Z-Wave 3.99 STATIC_CONTROLLER
ist 3.99 die Firmware Version des sticks? Auf der Hersteller Website http://www.z-wave.me/index.php?id=14 ist schon von Version 5 die rede...

[krikan]

ich hab einen Z-wave.me usb stick, bei fhem steht: ZWDongle_0 version => Z-Wave 3.99 STATIC_CONTROLLER
ist 3.99 die Firmware Version des sticks?

Nein, siehe https://forum.fhem.de/index.php/topic,49147.msg410063.html#msg410063

[decaflo]

Hallo,

ich habe ebenfalls Probleme mit der SECURE Verbindung des aktuellen Danalocks:

Ich bin wegen Problemem mit meinem Danalock V1 auf das aktuelle V125 umgestiegen.
Das V1 hat sich SECURE verbunden, das V125 nicht. Bei beiden habe ich die Inklusion mit addNode onNwSec gemacht. networkKey ist unverändert.

Hier ein list des V1:

Code Auswählen Erweitern

Internals:
   DEF        cc9f1aa1 18
   IODev      razberry
   NAME       danalock.old
   NR         182
   STATE      doorLockOperation FF
   TYPE       ZWave
   homeId     cc9f1aa1
   nodeIdHex  12
   Readings:
     2016-03-30 22:27:31   SECURITY        ENABLED
     2016-03-30 22:53:43   SEND_DATA       failed:00
     2016-03-30 23:00:54   UNPARSED        TIME 028a01
     2016-03-30 22:52:34   doorLockConfiguration mode: constant outsideHandles: 0000 insideHandles: 0000 timeoutSeconds: not_supported
     2016-03-30 23:00:54   doorLockOperation mode: secured outsideHandles: 1111 insideHandles: 1111 door: closed bolt: unlocked latch: closed timeoutSeconds: not_supported
     2016-03-30 22:27:34   model           Polycontrol Danalock Circle/Square
     2016-03-30 22:27:34   modelConfig     polycontrol/doorlock.xml
     2016-03-30 22:27:34   modelId         010e-0003-0002
     2016-03-30 23:01:34   state           doorLockOperation FF
     2016-03-30 23:01:34   transmit        OK
Attributes:
   IODev      razberry
   classes    MANUFACTURER_SPECIFIC BATTERY VERSION SECURITY DOOR_LOCK USER_CODE SCHEDULE_ENTRY_LOCK CONFIGURATION TIME MARK BASIC
   room       ZWave
   secure_classes DOOR_LOCK USER_CODE SCHEDULE_ENTRY_LOCK CONFIGURATION TIME MANUFACTURER_SPECIFIC BATTERY VERSION MARK


Hier das list des neuen

Code Auswählen Erweitern

fhem> list ZWave_ENTRY_CONTROL_20
Internals:
   DEF        cc9f1aa1 20
   IODev      razberry
   NAME       ZWave_ENTRY_CONTROL_20
   NR         188
   STATE      ???
   TYPE       ZWave
   homeId     cc9f1aa1
   nodeIdHex  14
Attributes:
   IODev      razberry
   classes    ZWAVEPLUS_INFO MANUFACTURER_SPECIFIC SECURITY DEVICE_RESET_LOCALLY BATTERY POWERLEVEL APPLICATION_STATUS
   room       ZWave


Hinweise auf einen Fehler im Log habe ich nicht gefunden. Nur das hier:

Code Auswählen Erweitern

2016.04.08 08:36:14 2: autocreate: define ZWave_ENTRY_CONTROL_20 ZWave cc9f1aa1 20 5e72985a807322
2016.04.08 08:36:16 2: ZWave get ZWave_ENTRY_CONTROL_20 model
2016.04.08 08:36:17 3: ZWave got config for polycontrol/doorlockV2BTZE.xml from ./FHEM/lib/fhem_zwave_deviceconfig.xml.gz

Vielleicht hilft das weiter!

Herzliche Grüße, Florian

[A.Harrenberg]

Hi,

Hier das list des neuen

Code Auswählen Erweitern

fhem> list ZWave_ENTRY_CONTROL_20
Internals:
   DEF        cc9f1aa1 20
   IODev      razberry
   NAME       ZWave_ENTRY_CONTROL_20
   NR         188
   STATE      ???
   TYPE       ZWave
   homeId     cc9f1aa1
   nodeIdHex  14
Attributes:
   IODev      razberry
   classes    ZWAVEPLUS_INFO MANUFACTURER_SPECIFIC SECURITY DEVICE_RESET_LOCALLY BATTERY POWERLEVEL APPLICATION_STATUS
   room       ZWave


Hmm, da ist ja nicht ein einziges Reading dabei... Falls die Einbindung mit SECURITY fehlschlägt sollte es da wenigstens ein Reading "SECURITY" geben das auf "INITIALIZING" oder "DISABLED" steht.

Bist Du GANZ sicher das Du mit "addNode onNwSec" inkludiert hast?
Könntest Du das Ding noch mal exkludieren und mit "verbose 5" (global) neu inkludieren? (Und in global das Attribut mseclog auf 1 setzen)

Gruß,
Andreas.

[decaflo]

Hallo Andreas,
ich bin mir schon ziemlich (...) sicher, dass ich mit addNode onNwSec inkludiert habe. Nachdem ich das Schloß nochmal exkludiert und neu inkludiert habe, sieht es aber besser aus:

Code Auswählen Erweitern

fhem> list danalock
Internals:
   CFGFN     
   DEF        cc9f1aa1 22
   IODev      razberry
   LASTInputDev razberry
   MSGCNT     34
   NAME       danalock
   NR         9734
   STATE      TRANSMIT_NO_ACK
   TYPE       ZWave
   homeId     cc9f1aa1
   isWakeUp   
   lastMsgSent 1462399371.0494
   nodeIdHex  16
   razberry_MSGCNT 34
   razberry_RAWMSG 00132e0101ea
   razberry_TIME 2016-05-05 00:02:55
   secTime    1462399371.04895
   timeToAck  2.591
   Helper:
     Dblog:
       Assocgroups:
         Dblog:
           TIME       1462398775.44217
           VALUE      1
       Configbatterytype:
         Dblog:
           TIME       1462398790.06647
           VALUE      1
       Configbrakegoback:
         Dblog:
           TIME       1462398790.72298
           VALUE      5
       Configdoorlockoperationreporttype:
         Dblog:
           TIME       1462398791.37235
           VALUE      0
       Configlockautolatchtime:
         Dblog:
           TIME       1462398792.03227
           VALUE      0
       Configlockdirection:
         Dblog:
           TIME       1462398792.69652
           VALUE      0
       Configlockmode:
         Dblog:
           TIME       1462398793.35436
           VALUE      1
       Configlockspeed:
         Dblog:
           TIME       1462398800.31747
           VALUE      2
       Configlockturndegrees:
         Dblog:
           TIME       1462398800.98324
           VALUE      34
       Configturngo:
         Dblog:
           TIME       1462398801.64357
           VALUE      0
       Model:
         Dblog:
           TIME       1462399317.88175
           VALUE      Polycontrol Danalock Circle V2 BTZE
       Modelconfig:
         Dblog:
           TIME       1462399317.88175
           VALUE      polycontrol/doorlockV2BTZE.xml
       Modelid:
         Dblog:
           TIME       1462399317.88175
           VALUE      010e-0008-0002
       State:
         Dblog:
           TIME       1462399375.96093
           VALUE      TRANSMIT_NO_ACK
       Transmit:
         Dblog:
           TIME       1462399375.96093
           VALUE      NO_ACK
   Readings:
     2016-05-04 23:32:28   SECURITY        ENABLED
     2016-05-04 23:53:02   SEND_DATA       failed:00
     2016-05-04 23:52:55   assocGroups     1
     2016-05-04 23:53:10   configBatteryType 1
     2016-05-04 23:53:10   configBrakeGoBack 5
     2016-05-04 23:53:11   configDoorLockOperationReportType 0
     2016-05-04 23:53:12   configLockAutoLatchTime 0
     2016-05-04 23:53:12   configLockDirection 0
     2016-05-04 23:53:13   configLockMode  1
     2016-05-04 23:53:20   configLockSpeed 2
     2016-05-04 23:53:20   configLockTurnDegrees 34
     2016-05-04 23:53:21   configTurnGo    0
     2016-05-05 00:01:57   model           Polycontrol Danalock Circle V2 BTZE
     2016-05-05 00:01:57   modelConfig     polycontrol/doorlockV2BTZE.xml
     2016-05-05 00:01:57   modelId         010e-0008-0002
     2016-05-05 00:02:55   state           TRANSMIT_NO_ACK
     2016-05-05 00:02:55   transmit        NO_ACK
   secMsg:
     86135e get danalock versionClass ZWAVEPLUS_INFO
     850201 get danalock association 1
     620100 set danalock doorLockOperation open
     620100 set danalock doorLockOperation 00
     6201FF set danalock doorLockOperation FF
     620100 set danalock doorLockOperation 00
Attributes:
   IODev      razberry
   classes    ZWAVEPLUS_INFO MANUFACTURER_SPECIFIC SECURITY DEVICE_RESET_LOCALLY BATTERY POWERLEVEL APPLICATION_STATUS DOOR_LOCK CONFIGURATION ALARM TIME TIME_PARAMETERS SCHEDULE_ENTRY_LOCK USER_CODE NETWORK_SCHEDULE ASSOCIATION ASSOCIATION_GRP_INFO FIRMWARE_UPDATE_MD VERSION MARK
   room       ZWave
   secure_classes DOOR_LOCK CONFIGURATION ALARM TIME TIME_PARAMETERS SCHEDULE_ENTRY_LOCK USER_CODE NETWORK_SCHEDULE ASSOCIATION ASSOCIATION_GRP_INFO FIRMWARE_UPDATE_MD VERSION MARK
   vclasses   ALARM:3 APPLICATION_STATUS:1 ASSOCIATION:2 ASSOCIATION_GRP_INFO:1 BATTERY:1 CONFIGURATION:1 DEVICE_RESET_LOCALLY:1 DOOR_LOCK:2 FIRMWARE_UPDATE_MD:2 MANUFACTURER_SPECIFIC:2 NETWORK_SCHEDULE:1 POWERLEVEL:1 SCHEDULE_ENTRY_LOCK:1 SECURITY:1 TIME:2 TIME_PARAMETERS:1 USER_CODE:1 VERSION:2


Ist das Log der Inklusion trotzdem noch interessant?

Die Kommunikation mit dem Schloss scheint auch zu gehen (get danalock associationAll, get danalock configAll, get danalock versionClassAll). Es gelingt mir aber nicht, das Schloss auf und zu zumachen.

Bei

Code Auswählen Erweitern

set danalock doorLockOperation (00|FF|open|close)

passiert nichts. Hier das Log nach

Code Auswählen Erweitern

set danalock doorLockOperation 00

Code Auswählen Erweitern

2016.05.05 00:13:40.116 5: Triggering global (1 changes)
2016.05.05 00:13:40.117 5: Starting notify loop for global, first event ATTR global verbose 5
2016.05.05 00:13:40.118 5: Notify from Device: global recieved
2016.05.05 00:13:55.580 5: Cmd: >set danalock doorLockOperation 00<
2016.05.05 00:13:55.585 2: ZWave set danalock doorLockOperation 00
2016.05.05 00:13:55.586 5: danalock: DOOR_LOCK is a secured class!
2016.05.05 00:13:55.586 5: danalock SECURITY: 620100 stored for encryption
2016.05.05 00:13:55.587 5: ZWDongle_Write 0013160298402530 (cc9f1aa1)
2016.05.05 00:13:55.588 5: SW: 010900131602984025303c
2016.05.05 00:13:55.591 5: Triggering danalock (1 changes)
2016.05.05 00:13:55.592 5: Starting notify loop for danalock, first event doorLockOperation 00
2016.05.05 00:13:55.593 5: Notify from Device: danalock recieved
2016.05.05 00:13:55.596 5: DbLog: logging of Device: danalock , Type: ZWAVE , Event: doorLockOperation 00 , Reading: state , Value: doorLockOperation 00 , Unit:
2016.05.05 00:13:55.646 5: ACK received, WaitForAck=>2 for 010900131602984025303c
2016.05.05 00:13:55.647 4: ZWDongle_Read razberry: rcvd 011301 (answer ZW_SEND_DATA), sending ACK
2016.05.05 00:13:55.647 5: SW: 06
2016.05.05 00:13:55.649 5: razberry dispatch 011301
2016.05.05 00:13:57.654 4: no response from device, removing 010900131602984025303c from dongle sendstack
2016.05.05 00:14:00.393 4: ZWDongle_Read razberry: rcvd 0013300001e0 (request ZW_SEND_DATA), sending ACK
2016.05.05 00:14:00.393 5: SW: 06
2016.05.05 00:14:00.396 5: razberry dispatch 0013300001e0
2016.05.05 00:14:00.396 4: CMD:ZW_SEND_DATA ID:00 ARG:01e0 CB:30
2016.05.05 00:14:00.397 4: razberry transmit OK for CB 30, target danalock
2016.05.05 00:14:00.466 4: ZWDongle_Read razberry: rcvd 000400160a988098ac6ff4b420fcff (request APPLICATION_COMMAND_HANDLER), sending ACK
2016.05.05 00:14:00.467 5: SW: 06
2016.05.05 00:14:00.469 5: razberry dispatch 000400160a988098ac6ff4b420fcff
2016.05.05 00:14:00.470 4: CMD:APPLICATION_COMMAND_HANDLER ID:16 ARG:0a988098ac6ff4b420fcff CB:00
2016.05.05 00:14:00.472 5: danalock SECURITY: 86135e get danalock versionClass ZWAVEPLUS_INFO retrieved for encryption
2016.05.05 00:14:00.473 5: danalock: secEncrypt plain:0086135e enc:79ebecc0
2016.05.05 00:14:00.474 5: ZWDongle_Write 001316179881ec579ad4429261d379ebecc09802d4dc23d5ccc3432531 (cc9f1aa1)
2016.05.05 00:14:00.475 5: SW: 011e001316179881ec579ad4429261d379ebecc09802d4dc23d5ccc3432531ff
2016.05.05 00:14:00.481 5: ACK received, WaitForAck=>2 for 011e001316179881ec579ad4429261d379ebecc09802d4dc23d5ccc3432531ff
2016.05.05 00:14:00.486 4: ZWDongle_Read razberry: rcvd 011301 (answer ZW_SEND_DATA), sending ACK
2016.05.05 00:14:00.486 5: SW: 06
2016.05.05 00:14:00.488 5: razberry dispatch 011301
2016.05.05 00:14:00.608 4: ZWDongle_Read razberry: rcvd 00133100000d (request ZW_SEND_DATA), sending ACK
2016.05.05 00:14:00.617 5: SW: 06
2016.05.05 00:14:00.619 5: device ack reveived, removing 011e001316179881ec579ad4429261d379ebecc09802d4dc23d5ccc3432531ff from dongle sendstack
2016.05.05 00:14:00.620 5: razberry dispatch 00133100000d
2016.05.05 00:14:00.621 4: CMD:ZW_SEND_DATA ID:00 ARG:000d CB:31
2016.05.05 00:14:00.622 4: razberry transmit OK for CB 31, target danalock
2016.05.05 00:14:00.681 4: ZWDongle_Read razberry: rcvd 00040016029840 (request APPLICATION_COMMAND_HANDLER), sending ACK
2016.05.05 00:14:00.682 5: SW: 06
2016.05.05 00:14:00.684 5: razberry dispatch 00040016029840
2016.05.05 00:14:00.685 4: CMD:APPLICATION_COMMAND_HANDLER ID:16 ARG:029840 CB:00
2016.05.05 00:14:00.687 5: ZWDongle_Write 0013160a9880622068bbcedaeb222532 (cc9f1aa1)
2016.05.05 00:14:00.688 5: SW: 01110013160a9880622068bbcedaeb222532a2
2016.05.05 00:14:00.693 5: ACK received, WaitForAck=>2 for 01110013160a9880622068bbcedaeb222532a2
2016.05.05 00:14:00.697 4: ZWDongle_Read razberry: rcvd 011301 (answer ZW_SEND_DATA), sending ACK
2016.05.05 00:14:00.698 5: SW: 06
2016.05.05 00:14:00.700 5: razberry dispatch 011301
2016.05.05 00:14:00.824 4: ZWDongle_Read razberry: rcvd 00133200000d (request ZW_SEND_DATA), sending ACK
2016.05.05 00:14:00.824 5: SW: 06
2016.05.05 00:14:00.826 5: device ack reveived, removing 01110013160a9880622068bbcedaeb222532a2 from dongle sendstack
2016.05.05 00:14:00.827 5: razberry dispatch 00133200000d
2016.05.05 00:14:00.828 4: CMD:ZW_SEND_DATA ID:00 ARG:000d CB:32
2016.05.05 00:14:00.828 4: razberry transmit OK for CB 32, target danalock
2016.05.05 00:14:00.903 4: ZWDongle_Read razberry: rcvd 000400161898814e3352537c35b8b8fe6e55127c62904208e3065ef23f (request APPLICATION_COMMAND_HANDLER), sending ACK
2016.05.05 00:14:00.904 5: SW: 06
2016.05.05 00:14:00.906 5: razberry dispatch 000400161898814e3352537c35b8b8fe6e55127c62904208e3065ef23f
2016.05.05 00:14:00.907 4: CMD:APPLICATION_COMMAND_HANDLER ID:16 ARG:1898814e3352537c35b8b8fe6e55127c62904208e3065ef23f CB:00
2016.05.05 00:14:00.909 5: danalock: secDecrypt: decrypted cmd 0086145e02
2016.05.05 00:14:00.910 5: danalock: secDecrypt: Sequencebyte 0, sequenced 0, secondFrame 0, sequenceCounter 00
2016.05.05 00:14:00.911 5: danalock: secDecrypt: calculated Authentication code 904208e3065ef23f
2016.05.05 00:14:00.911 5: danalock: secDecrypt: parsing 000400160486145e02


Hast Du eine Idee, wie ich das Schloss dazu bekomme, auf und zu zu gehen?

Viele Grüße
Florian

[A.Harrenberg]

Hallo Florian,

ok, zumindest ist jetzt SECURITY aktiv und funktioniert auch prinzipiell.

Bei Dir lagen/liegen anscheinend noch alte SECURITY Befehle auf dem Security Stack und die werden nur einzeln abgearbeitet. Das ist momentan eine große Schwachstelle und hängt damit zusammen wie ich das implementiert habe ,-(

Um den Ablauf mal kurz darzustellen:

Nutzer setzt Kommando ab, vor dem Absenden wird geschaut ob dieser Befehl verschlüsselt werden muss. Falls ja, wird dieser Befehl auf den Security Stack gelegt und stattdessen bei dem Gerät eine sogenannte NONCE angefordert die zur Verschlüsselung nötig ist.

Sobald diese eintrifft wird der oberste Befehl vom Security Stack zurückgeholt und mit der NONCE verschlüsselt und das ganze dann versendet. Falls der Befehl ein GET-Befehl war geht das mit dem Verschlüsseln noch ein paar Mal hin und her.

Falls das Gerät aber diese NONCE nicht schickt (oder diese aus anderen Gründen nicht zugeordnet wird) bleibt der Befehl auf dem Stack liegen und wird erst dann abgearbeitet wenn die nächste NONCE eintrifft, d.h. wenn der nächste Befehl verschlüsselt werden soll. Dann wird der alte Befehl verarbeitet und der neue bleibt dann wieder liegen... ;-(

In Deinem Beispiel lag anscheinend noch ein Version-Befehl auf dem Stack, der wurde dann nämlich anstelle des "Door open" ausgeführt.

Allerdings ist Dein System auch etwas "merkwürdig". Die Anfrage für die NONCE wird nicht vom Dongle bestätigt, wodurch FHEM/ZWave sogar aufgibt:

Code Auswählen Erweitern

2016.05.05 00:13:57.654 4: no response from device, removing 010900131602984025303c from dongle sendstack
Einen Retry gibt es hier nicht mehr.

Weitere 3 Sekunden später kommt dann allerdings doch noch eine Nonce und der Version Befehl wird abgearbeitet:

Code Auswählen Erweitern

2016.05.05 00:14:00.472 5: danalock SECURITY: 86135e get danalock versionClass ZWAVEPLUS_INFO retrieved for encryption

Schau mal in Dein "list danalock":

Code Auswählen Erweitern

   secMsg:
     86135e get danalock versionClass ZWAVEPLUS_INFO
     850201 get danalock association 1
     620100 set danalock doorLockOperation open
     620100 set danalock doorLockOperation 00
     6201FF set danalock doorLockOperation FF
     620100 set danalock doorLockOperation 00
Da liegen noch die ganzen Befehle rum...
Momentan hilft da leider nur FHEM neu zu starten da hierdurch der Stack gelöscht wird.

Leider tritt das Problem doch recht häufig auf, da vor allem wenn es CAN-Msg gibt oder gesendete Befehle ignoriert werden (Das Schloss z.B. ignoriert während es auf- oder zufährt weitere Befehle). Dabei gehen dann die Anfragen für die NONCE verloren und wenn die Antwort nicht kommt bleibt alles hängen und wird vollkommen asynchron.

Momentan habe ich noch keinen Workaround für das Problem, das steht aber auf meiner ToDo-Liste.

Gruß,
Andreas.

[decaflo]

Hallo Andreas,
danke für die ausführliche Antwort. Ich habe den Stack mit den associationAll, versionClassAll, configAll,... Anfragen auch ganz schön gestresst... Ich werde das nach einem Neustart nochmal probieren. Jetzt kann ich auf Grund der Uhrzeit nicht ans Schloss

Falls das Gerät aber diese NONCE nicht schickt (oder diese aus anderen Gründen nicht zugeordnet wird) bleibt der Befehl auf dem Stack liegen und wird erst dann abgearbeitet wenn die nächste NONCE eintrifft, d.h. wenn der nächste Befehl verschlüsselt werden soll. Dann wird der alte Befehl verarbeitet und der neue bleibt dann wieder liegen... ;-(

Das hört sich zumindest so an, als wäre das Problem erkannt Kann ich die Entwicklung irgendwie unterstützen?

Allerdings ist Dein System auch etwas "merkwürdig". Die Anfrage für die NONCE wird nicht vom Dongle bestätigt, wodurch FHEM/ZWave sogar aufgibt:

Code Auswählen Erweitern

2016.05.05 00:13:57.654 4: no response from device, removing 010900131602984025303c from dongle sendstack
Einen Retry gibt es hier nicht mehr.

Weitere 3 Sekunden später kommt dann allerdings doch noch eine Nonce und der Version Befehl wird abgearbeitet:

Code Auswählen Erweitern

2016.05.05 00:14:00.472 5: danalock SECURITY: 86135e get danalock versionClass ZWAVEPLUS_INFO retrieved for encryption

Ich glaube ich weiss. wo das merkwürdige Verhalten herkommt. Mein ZWave Dongle ist ein razberry, der per ser2net an fhem auf einem anderen host angebunden ist. Die Verbindung verabschiedet sich alle paar Minuten:

Code Auswählen Erweitern


...
2016.05.06 02:50:44.135 1: raspberrypi:38401 disconnected, waiting to reappear (razberry)
2016.05.06 02:50:44.222 1: raspberrypi:38401 reappeared (razberry)
2016.05.06 02:55:46.441 1: raspberrypi:38401 disconnected, waiting to reappear (razberry)
2016.05.06 02:55:46.498 1: raspberrypi:38401 reappeared (razberry)
2016.05.06 03:00:48.751 1: raspberrypi:38401 disconnected, waiting to reappear (razberry)
2016.05.06 03:00:48.817 1: raspberrypi:38401 reappeared (razberry)
...


Warum das so ist, habe ich noch nicht rausgefunden. Ich vermute aber, dass das das Kommunikationsproblem verschärft.

Viele Grüße
Florian

[A.Harrenberg]

Hi Florian,

Das hört sich zumindest so an, als wäre das Problem erkannt Kann ich die Entwicklung irgendwie unterstützen?

Ja, das prinzipielle Problem ist bekannt. Sobald eine Nonce "verlorengeht" kommt das ganze durcheinander...

Bei einem verschlüsselten GET-Befehl wird das ganze noch mal interessanter, da hier bis zu 7 Nachrichten hin- und hergehen. Sobald es hier zu einer Störung kommt geht das ganze schief. Dazu kommt die Möglichkeit das die Node evtl. "zeitgleich" selbst etwas verschlüsselt senden will, dann fordert Sie selbst solch eine NONCE an und ignoriert gesendete Befehle, was zu dem gleichen Ergebnis führt.

Meine momentane Idee ist eine Absicherung über einen Timer. der dann sicherstellt das der Sendstack abgearbeitet wird. Sobald ich da mal was implementiert habe kannst Du gerne mittesten. Momentan habe ich aber leider etwas Probleme mit meinem ganzen Rechnerzoo und der finalen Umstellung auf Win10... Zeitgleich hat mein Backupprogramm beschlossen unzuverlässig zu sein ,-(

Kann also leider noch ein paar Tage dauern bis ich damit anfangen kann...

Ich glaube ich weiss. wo das merkwürdige Verhalten herkommt. Mein ZWave Dongle ist ein razberry, der per ser2net an fhem auf einem anderen host angebunden ist. Die Verbindung verabschiedet sich alle paar Minuten:

[...]

Warum das so ist, habe ich noch nicht rausgefunden. Ich vermute aber, dass das das Kommunikationsproblem verschärft.

Ja, das hilft sicherlich nicht die Kommunikation stabiler zu machen.

Gruß,
Andreas.

[decaflo]

Nach dem Leeren des Stack durch Neustart von fhem kann ich das Schloss steuern, prima!
Ursache der disconnects war der Timeout in ser2net. Mit

Code Auswählen Erweitern

38401:raw:0:/dev/ttyAMA0:115200 8DATABITS NONE 1STOPBIT
statt

Code Auswählen Erweitern

38401:raw:300:/dev/ttyAMA0:115200 8DATABITS NONE 1STOPBIT

in /etc/ser2net.conf treten sie nicht mehr auf. Ich probiere weiter und teste gerne, wenn Du was hast!

Grüße!