Support von Danalock V3 Türschloss

Begonnen von Klaus Rubik, 16 Oktober 2017, 12:14:16

Vorheriges Thema - Nächstes Thema

Klaus Rubik

Hallo,

ich habe heute mein neues Danalock V3 mit Zwave Unterstützung bekommen. Leider wird es von FHEM scheinbar noch nicht richtig erkannt. Es wird lediglich als UNKNOWN_nn erkannt:

nodeList
Z_Wave Kuehlschrank_Power Tuerschloss UNKNOWN_10


nodeInfo_10
ProtocolVers:SDK4.5x+6.0x sleeping routing maxBaud:40kbps SpecificDev RoutingSlave BeamCap FrequentListen1000ms OptFunc SpeedExt:100kbps RoleType:N/A BasicDevClass:ROUTING_SLAVE GenericDevClass:ENTRY_CONTROL SpecificDevClass:03


Verbose 5 und set createnode 10 führt zu folgendem Log-Output:
2017.10.16 12:39:06 4: ZWDongle *** set Z_Wave createNode 10
2017.10.16 12:39:06 5: ZWDongle_Write 00600a ()
2017.10.16 12:39:06 5: SW: 010400600a91
2017.10.16 12:39:06 5: ACK received, removing 010400600a91 from dongle sendstack
2017.10.16 12:39:06 4: ZWDongle_Read Z_Wave: rcvd 016001 (answer ZW_REQUEST_NODE_INFO), sending ACK
2017.10.16 12:39:06 5: SW: 06
2017.10.16 12:39:06 5: Z_Wave: dispatch 016001
2017.10.16 12:39:06 4: Z_Wave unhandled ANSWER: ZW_REQUEST_NODE_INFO 01
2017.10.16 12:39:09 4: ZWDongle_Read Z_Wave: rcvd 0049840a070440035e989f55 (request ZW_APPLICATION_UPDATE), sending ACK
2017.10.16 12:39:09 5: SW: 06
2017.10.16 12:39:09 5: Z_Wave: dispatch 0049840a070440035e989f55
2017.10.16 12:39:09 4: CMD:ZW_APPLICATION_UPDATE ID:0a ARG:070440035e989f55 CB:84
2017.10.16 12:39:11 4: ZWDongle_Read Z_Wave: rcvd 0049840a070440035e989f55 (request ZW_APPLICATION_UPDATE), sending ACK
2017.10.16 12:39:11 5: SW: 06
2017.10.16 12:39:11 5: Z_Wave: dispatch 0049840a070440035e989f55
2017.10.16 12:39:11 4: CMD:ZW_APPLICATION_UPDATE ID:0a ARG:070440035e989f55 CB:84
2017.10.16 12:39:11 4: ZWDongle_Read Z_Wave: rcvd 0049840a070440035e989f55 (request ZW_APPLICATION_UPDATE), sending ACK
2017.10.16 12:39:11 5: SW: 06
2017.10.16 12:39:11 5: Z_Wave: dispatch 0049840a070440035e989f55
2017.10.16 12:39:11 4: CMD:ZW_APPLICATION_UPDATE ID:0a ARG:070440035e989f55 CB:84
2017.10.16 12:40:18 4: ZWDongle_Read Z_Wave: rcvd 000400020a32022144000083820000 (request APPLICATION_COMMAND_HANDLER), sending ACK
2017.10.16 12:40:18 5: SW: 06
2017.10.16 12:40:18 5: Z_Wave: dispatch 000400020a32022144000083820000
2017.10.16 12:40:18 4: CMD:APPLICATION_COMMAND_HANDLER ID:02 ARG:0a32022144000083820000 CB:00
20


Als Anlage habe ich noch die ZWave Dokumentation beigelegt.

Vielen Dank für jegliche Unterstützung im voraus.
FHEM 6.0 auf RPI4 mit CUL868, AEOTEC, RFXTRX 433
CUL_WS  : S300TH              FHT         : FHT80B, FHT80TF
HMS        : HMS100-TF         FBDECT   : DECT!200, FRITZ!Powerline 546E
FS20       : FS20DI10, FS20ST, FS20WS1, FS20DU-2, FS20 FMS

krikan

Hattest Du autocreate bei der Inklusion an?
Wie genau hast Du inkludiert? Mit onSec oder onNwSec?

Auch das Danalock sollte secure inkludierbar sein. Was nicht funktionieren wird: Inklusion mit SECURITY V2.
createNode bei secure inkludierten Geräten ist problematisch und nicht zu Ende getestet.

Gruß, Christian

Klaus Rubik

Zitat von: krikan am 16 Oktober 2017, 12:54:14
Hattest Du autocreate bei der Inklusion an?
Wie genau hast Du inkludiert? Mit onSec oder onNwSec?

autocreate sollte an sein, zumindest habe ich es nicht bewusst abgeschaltet.
inkludiert habe ich mit onSec

Viele Grüße

Klaus
FHEM 6.0 auf RPI4 mit CUL868, AEOTEC, RFXTRX 433
CUL_WS  : S300TH              FHT         : FHT80B, FHT80TF
HMS        : HMS100-TF         FBDECT   : DECT!200, FRITZ!Powerline 546E
FS20       : FS20DI10, FS20ST, FS20WS1, FS20DU-2, FS20 FMS

krikan

UNKNOWN_10 bedeutet FHEM kennt kein zugehöriges Device und ist typischerweise Hinweis auf nicht eingeschaltetes autocreate bzw. zu umfangreiches Attribut ignoreTypes bei autocreate.
Ansonsten bin ich anhand Deiner Angaben gerade ideenlos. Sorry. Ich bräuchte als Ideenanreger eventuell ein Log mit gesetzten Attributen
attr <ZWDongle> verbose 5
attr global mseclog 1

von einem kompletten Inklusionsvorgang mit onSec nach Reset des Danalocks und removeFailedNode des Nodes 10.

Vielleicht wartest Du aber noch auf einfachere Ideen  :) .

Btw: Was ist eigentlich Tuerschloss? Nicht das in Rede stehende Danalock?


Klaus Rubik

Zitat von: krikan am 16 Oktober 2017, 13:59:44
Btw: Was ist eigentlich Tuerschloss? Nicht das in Rede stehende Danalock?
Nein, das war das Vorgänger Danalock (V125)

und Danke nochmal für deinen Input. Mal sehen, ob noch was einfacheres kommt und ansonsten poste ich die nächsten Tage den Log
FHEM 6.0 auf RPI4 mit CUL868, AEOTEC, RFXTRX 433
CUL_WS  : S300TH              FHT         : FHT80B, FHT80TF
HMS        : HMS100-TF         FBDECT   : DECT!200, FRITZ!Powerline 546E
FS20       : FS20DI10, FS20ST, FS20WS1, FS20DU-2, FS20 FMS

volschin

#5
Ich komme leider auch nicht voran. Ich dachte zuerst es ist das alte SDK meines UZB1. Da habe ich jetzt Firmware 5.22 aufgespielt, die auf Level SDK 6.71 ist und damit zum Danalock passt.

Ich bekomme beim inkludieren jetzt aber nur:
SECURITY          DISABLED (networkkey not verified and timer expired)
nachdem er zwischenzeitlich auf Initializing war.

Ich packe mal das List mit rein:
Internals:
   CFGFN
   DEF        e5e8f5b9 5
   IODev      UZB1
   LASTInputDev UZB1
   MSGCNT     4
   NAME       ZWave_ENTRY_CONTROL_5
   NR         680
   STATE      neighborUpdate
   TYPE       ZWave
   UZB1_MSGCNT 4
   UZB1_RAWMSG 00040005095e0201070003000300ca00
   UZB1_TIME  2017-10-21 20:36:13
   ZWaveSubDevice no
   cmdsPending 0
   homeId     e5e8f5b9
   isWakeUp
   lastMsgSent 1508610972.24466
   nodeIdHex  05
   secTime    1508610833.92674
   READINGS:
     2017-10-21 20:34:18   SECURITY        DISABLED (networkkey not verified and timer expired)
     2017-10-21 20:36:04   neighborUpdate  done
     2017-10-21 20:36:02   state           neighborUpdate
     2017-10-21 20:36:13   timeToAck       1.264
     2017-10-21 20:36:13   transmit        OK
     2017-10-21 20:36:13   zwavePlusInfo    version:01 role:SleepingListeningSlave node:Z-Wave+Node installerIcon:0300 userIcon:0300
   secNonce:
     60:
       nonce      60fc3c58ba8d6829
       timeStamp  1508610833.92707
     86:
       nonce      86cdc9bf367f2a6d
       timeStamp  1508610833.83054
Attributes:
   IODev      UZB1
   classes    ZWAVEPLUS_INFO SECURITY SECURITY_S2 TRANSPORT_SERVICE
   room       ZWave
Intel NUC+Ubuntu 22.04+Docker+FHEM6
HomeMatic: HM-MOD-RPI-PCB+HM-USB-CFG2+hmland+diverse, HUE: Hue-Bridge, RaspBee+deCONZ+diverse
Amzn Dash-Buttons, Siro Rollos
4xRPi, 4xCO20, OWL+USB, HarmonyHub, FRITZ!Box 7590, Echo Dots+Show8, Logi Circle 2, HomeBridge
TIG Stack (Telegraf, InfluxDB, Grafana)

volschin

Intel NUC+Ubuntu 22.04+Docker+FHEM6
HomeMatic: HM-MOD-RPI-PCB+HM-USB-CFG2+hmland+diverse, HUE: Hue-Bridge, RaspBee+deCONZ+diverse
Amzn Dash-Buttons, Siro Rollos
4xRPi, 4xCO20, OWL+USB, HarmonyHub, FRITZ!Box 7590, Echo Dots+Show8, Logi Circle 2, HomeBridge
TIG Stack (Telegraf, InfluxDB, Grafana)

krikan

Zitat von: volschin am 21 Oktober 2017, 20:41:37
Ich komme leider auch nicht voran. Ich dachte zuerst es ist das alte SDK meines UZB1. Da habe ich jetzt Firmware 5.22 aufgespielt, die auf Level SDK 6.71 ist und damit zum Danalock passt.
Bekomme bereits Updates bis zur Firmware 5.27 angeboten. Release Notes gibt es aber nur bis zur 5.06, was ich merkwürdig finde und mich an Beta denken lässt.

Zum Danalock-Einbindungsproblem kann ich weiterhin mangels Logs nichts beitragen. Logs von einem UZB1/Razberry mit der 5.22 mag ich aber nicht. ;)

Klaus Rubik

#8
Hallo,

das Danalock V3 konnte ich inzwischen einbinden (Hatte wohl doch for etlicher Zeit mal autocreate abgeschlaten  ::) :-\). In FHEM taucht es jetzt wie folgt auf:

Internals:
   CFGFN
   CHANGED
   DEF        ceac4320 11
   IMAGE
   IODev      Z_Wave
   LASTInputDev Z_Wave
   MSGCNT     136
   NAME       Danalock_Tuer
   NR         278093
   STATE      associationAdd 1 1
   TYPE       ZWave
   ZWaveSubDevice no
   Z_Wave_MSGCNT 136
   Z_Wave_RAWMSG 0004000b189881caaeb2a2a1e1b3375c83e394c3bab9cc62001371432a
   Z_Wave_TIME 2017-10-23 08:53:59
   cmdsPending 0
   homeId     ceac4320
   isWakeUp
   lastMsgSent 1508741639.23991
   nodeIdHex  0b
   secTime    1508741639.23901
   READINGS:
     2017-10-17 13:18:11   SECURITY        ENABLED
     2017-10-17 16:17:31   SEND_DATA       failed:00
     2017-10-23 08:53:33   alarm           AccessControl: Event cleared: unknown event 0
     2017-10-23 08:48:01   alarmEventSupported_AccessControl (1) Manual Lock Operation, (2) Manual Unlock Operation, (3) RF Lock Operation, (4) RF Unlock Operation, (9) Auto Lock Locked Operation, (11) Lock Jammed
     2017-10-23 08:53:59   alarmTypeSupported AccessControl
     2017-10-23 08:51:31   assocGroup_1    Max 1 Nodes Z_Wave
     2017-10-23 08:51:29   assocGroups     1
     2017-10-17 13:44:26   battery         100 %
     2017-10-23 08:42:53   doorLockConfiguration  mode: constant outsideHandles: 0001 insideHandles: 0001 timeoutSeconds: not_supported
     2017-10-22 12:04:13   doorLockOperation mode: secured outsideHandles: 0001 insideHandles: 0001 door: closed bolt: locked latch: closed timeoutSeconds: not_supported
     2017-10-22 11:59:29   model           0x010e 0x0009 0x0001
     2017-10-22 11:59:29   modelId         010e-0009-0001
     2017-10-17 14:36:37   neighborList    Z_Wave Kuehlschrank_Power
     2017-10-17 13:44:19   powerlvl        current 0 remain 0
     2017-10-23 08:51:58   state           associationAdd 1 1
     2017-10-23 08:53:59   timeToAck       0.117
     2017-10-23 08:53:59   transmit        OK
     2017-10-23 08:43:21   version         Lib 3 Prot 4.61 App 1.2 HW 2 FWCounter 1 FW 0.7
     2017-10-17 13:19:27   zwavePlusInfo    version:01 role:SleepingListeningSlave node:Z-Wave+Node installerIcon:0300 userIcon:0300
   secMsg:
   secNonce:
Attributes:
   IODev      Z_Wave
   classes    ZWAVEPLUS_INFO SECURITY SECURITY_S2 TRANSPORT_SERVICE DOOR_LOCK VERSION ALARM ASSOCIATION ASSOCIATION_GRP_INFO SUPERVISION MANUFACTURER_SPECIFIC POWERLEVEL DEVICE_RESET_LOCALLY BATTERY FIRMWARE_UPDATE_MD CONFIGURATION
   neighborListPos 276.5578578802596,43.98380336453465
   room       Alarm_Melder,Flur,Windfang
   secure_classes DOOR_LOCK VERSION ALARM ASSOCIATION ASSOCIATION_GRP_INFO SUPERVISION MANUFACTURER_SPECIFIC POWERLEVEL DEVICE_RESET_LOCALLY BATTERY FIRMWARE_UPDATE_MD CONFIGURATION
   vclasses   ALARM:8 ASSOCIATION:2 ASSOCIATION_GRP_INFO:1 BATTERY:1 CONFIGURATION:1 DEVICE_RESET_LOCALLY:1 DOOR_LOCK:2 FIRMWARE_UPDATE_MD:4 MANUFACTURER_SPECIFIC:2 POWERLEVEL:1 SECURITY:1 SECURITY_S2:1 SUPERVISION:1 TRANSPORT_SERVICE:2 VERSION:2 ZWAVEPLUS_INFO:2


Folgende Probleme/Herausforderungen habe ich jetzt noch:

  • Alarmnotifications scheinen nicht anzukommen, zumindest sehe ich keine
  • get model liefert einen TimeOut und folgende Einträgeim Log:
2017.10.23 08:57:47 3: ZWave get Danalock_Tuer model
2017.10.23 08:57:51 1: Danalock_Tuer: no stored commands in Internal secMsg found
2017.10.23 08:57:51 1: Danalock_Tuer: Error, nonce reveived but no stored command for encryption found
2017.10.23 08:57:54 3: Danalock_Tuer: secStart older than 6 seconds detected, secUnlock will call Zwave_secEnd
2017-10-23_08:57:57 Danalock_Tuer modelId: 010e-0009-0001
2017-10-23_08:57:57 Danalock_Tuer model: 0x010e 0x0009 0x0001
2017-10-23_08:57:57 Danalock_Tuer model: 0x010e 0x0009 0x0001


Hat hier noch jemand den einen oder anderen Tipp für mich?
FHEM 6.0 auf RPI4 mit CUL868, AEOTEC, RFXTRX 433
CUL_WS  : S300TH              FHT         : FHT80B, FHT80TF
HMS        : HMS100-TF         FBDECT   : DECT!200, FRITZ!Powerline 546E
FS20       : FS20DI10, FS20ST, FS20WS1, FS20DU-2, FS20 FMS

krikan

Zitat von: Klaus Rubik am 23 Oktober 2017, 09:00:53
Alarmnotifications scheinen nicht anzukommen, zumindest sehe ich keine
Das ist doch eine AlarmNotification!?:
     2017-10-23 08:53:33   alarm           AccessControl: Event cleared: unknown event 0

Ansonsten dringende Empfehlung bei allen aktuellen Geräten mit Class Alarm/Notification
attr <device> ◦extendedAlarmReadings 1
damit man für jede Alarm-Art ein separates Reading zur besseren Nachvollziehbarkeit hat.

Zitatget model liefert einen TimeOut und folgende Einträge im Log:
Aber es scheint doch zu funktionieren:
2017-10-23_08:57:57 Danalock_Tuer model: 0x010e 0x0009 0x0001
2017-10-23_08:57:57 Danalock_Tuer model: 0x010e 0x0009 0x0001

Wo ist das Problem?
Ohne Logfile-Auszug mit den Einstellungen wie hier beschrieben, ist es immer etwas schwierig konkreter zu werden.  :)

A.Harrenberg

Hi,
Zitat von: Klaus Rubik am 23 Oktober 2017, 09:00:53
get model liefert einen TimeOut und folgende Einträgeim Log:
2017.10.23 08:57:47 3: ZWave get Danalock_Tuer model
2017.10.23 08:57:51 1: Danalock_Tuer: no stored commands in Internal secMsg found
2017.10.23 08:57:51 1: Danalock_Tuer: Error, nonce reveived but no stored command for encryption found
2017.10.23 08:57:54 3: Danalock_Tuer: secStart older than 6 seconds detected, secUnlock will call Zwave_secEnd
2017-10-23_08:57:57 Danalock_Tuer modelId: 010e-0009-0001
2017-10-23_08:57:57 Danalock_Tuer model: 0x010e 0x0009 0x0001
2017-10-23_08:57:57 Danalock_Tuer model: 0x010e 0x0009 0x0001


Hat hier noch jemand den einen oder anderen Tipp für mich?
da ist leider was mit der secure-Kommunikation durcheinander gekommen....

Falls eine verschlüsselte Übertragung nötig ist wird der zu verschlüsselnde Befehl gespeichert und eine NONCE beim Gerät angefordert. Wenn die Nonce dann eintrifft wird die Nachricht damit verschlüsselt und dann versendet. In Deinem Fall wurde eine NONCE empfangen, es war aber keine Befehl zum Versenden (mehr) da. Meist passiert das wenn das Gerät auf das Versenden der NONCE das "ACK" nicht empfängt und daher die NONCE noch mal sendet. Das ist erst mal kein Problem, wenn allerdings in der Richtung "ACK" verlorengehen dann sicherlich auch in der anderen Richtung und dann kommt leider der ganze Sendstack durcheinander.

Kannst Du bitte mal ein list von dem Device machen und posten? Wenn da ein Internal secMsg mit alten Nachrichten auftaucht wäre das genau der Fall... ,-( Da hilft dann erst mal nur ein Neustart von FHEM um den Stack zu löschen. Evtl. kann auch ein
{ delete $defs{"Danalock_Tuer"}{secMsg} }
ohne Neustart helfen.

Gruß,
Andreas.
FB 7360, Homematic und ZWave
Support for ZWave-SECURITY

roadghost

Hallo Leute.

Ich nutze FHEM auf einem NUC unter Ubuntu und habe einen UZB1.

Mein UZB1 funktioniert, ich habe verschiedene Steckdosen über zwave eingebunden. Mein Danalock V3 möchte jedoch nicht.

Egal, ob mit addNote On / OnNw - Ich sehe nicht mal einen Eintrag im Eventmonitor oder im Log.

Das komische daran ist: Es hat in der vergangenheit mal funktioniert.

Ich hatte das V3 inkludiert, aber ohne das Perl-Modul Crypt-Rijndael. Dementsprechend bekam ich kein state, und konnte auch keine befehle abgeben.

Also habe ich das V3 exkludiert, das Modul installiert, meinen NUC samt FHEM neu gestartet, den 32er HEX-Key erzeugt - anschließend wollte ich das V3 wieder inkludieren - und jetzt geht es nicht mehr.

Ich habe das V3 bereits auf Werkseinstellung gesetzt, die Batterien rausgenommen. Nix.

Liegt es nun an FHEM, an mir, oder am V3 ??

Wo kann ich noch nachsehen ?? autocreate ist definitiv an, es sind auch keine ignore-attribute gesetzt. Andere zwave-devices kann ich exkludieren und neu inkludieren - nur das V3 nicht.

Help needed !
NUC/Ubuntu 22.04 m. FHEM, div. Tasmota-Steckdosen, HMCFGUSB-2 für 12x HM-CC-RT-DN + 8x HM-TC-IT-WW
Rademacher DuoFern für 12 Jalousien, JeeLink für LaCrosse Temp.Sensor, WLAN-smart-Plugs, 
NUKI smartlock, 2xIP-CAM, Pylontech Speicher + Sungrow WR, Unifi-AP´s + Controller auf weiterem NUC

volschin

Ich verfolge deine Versuche mal mit Spannung. Ich habe es mit dem UZB1 nicht ans Laufen bekommen und aufgegeben.
Intel NUC+Ubuntu 22.04+Docker+FHEM6
HomeMatic: HM-MOD-RPI-PCB+HM-USB-CFG2+hmland+diverse, HUE: Hue-Bridge, RaspBee+deCONZ+diverse
Amzn Dash-Buttons, Siro Rollos
4xRPi, 4xCO20, OWL+USB, HarmonyHub, FRITZ!Box 7590, Echo Dots+Show8, Logi Circle 2, HomeBridge
TIG Stack (Telegraf, InfluxDB, Grafana)

roadghost

Update:

Ich kann euch nicht sagen, warum - Aber: Die entfernung zwischen UZB1 und dem V3 scheint eine wichtige Rolle zu spielen. Auch wenn zwischen dem UZB1 und dem V3 weitere, bereits inkludierte smartPlugs von Fibaro sitzen.

Ich hatte, als ich das V3 erstmalig, ohne Sec, inkludiert hatte, den UZB1 mittels 1m USB-verlängerungskabel am NUC hängen.

Der UZB1 baumelte am Kabel, senkrecht hängend rum, und befand sich somit etwas näher am V3. Ich denke weniger als 1m. Optisch störte mich das, so hatte ich das Kabel einfach wieder abgesteckt, es funktionierte ja alles, bis ich vorhin mit dem Basteln begann......

Ich habe dann aus lauter verzweifelung, das V3 vom Sockel an der Tür abgenommen, und es neben den UZB1 gelegt - voila - inklusion geht.

Direkt via add node OnSec - nun funktioniert die Statusabfrage und auch das Steuern des V3 über FHEM.

Mal noch ne Frage an die Runde:

Das V3 gibt in FHEM den state an mit:

doorLockOperation open beziehungsweise mit doorLockOperation close

Scheinbar verhindert das Leerzeichen zwischen "Operation" und "open" eine Auswertung für das devStateIcon - kann das sein ??

Ist es möglich, den Text "doorLockOperation" aus dem state zu entfernen ??
NUC/Ubuntu 22.04 m. FHEM, div. Tasmota-Steckdosen, HMCFGUSB-2 für 12x HM-CC-RT-DN + 8x HM-TC-IT-WW
Rademacher DuoFern für 12 Jalousien, JeeLink für LaCrosse Temp.Sensor, WLAN-smart-Plugs, 
NUKI smartlock, 2xIP-CAM, Pylontech Speicher + Sungrow WR, Unifi-AP´s + Controller auf weiterem NUC

roadghost

Zitat von: volschin am 01 Januar 2018, 23:02:30
Ich verfolge deine Versuche mal mit Spannung. Ich habe es mit dem UZB1 nicht ans Laufen bekommen und aufgegeben.

Meinst Du mich damit ??

Kann ich, mit meinen limitierten Kenntnissen in FHEM, evtl. helfen ??
NUC/Ubuntu 22.04 m. FHEM, div. Tasmota-Steckdosen, HMCFGUSB-2 für 12x HM-CC-RT-DN + 8x HM-TC-IT-WW
Rademacher DuoFern für 12 Jalousien, JeeLink für LaCrosse Temp.Sensor, WLAN-smart-Plugs, 
NUKI smartlock, 2xIP-CAM, Pylontech Speicher + Sungrow WR, Unifi-AP´s + Controller auf weiterem NUC