FHEM Forum

Hallo,

ich habe mir vor ein paar Tagen die ersten paar Bestandteile für mein Smart Home System bestellt (Danalock Z-Wave und das Phillips Hue Starter Kit). Das System läuft auf einem Raspberry Pi mit einem Razberry Modul.
Das Modul wird inzwischen richtig erkannt, die Inklusion des Schlosses hat auch (fast) problemlos funktioniert. Unter Everything sehe ich zumindest ein ZWave Gerät namens ZWave_ENTRY_CONTROL_2.
Nun habe ich aber ein Problem, laut wiki (http://www.fhemwiki.de/wiki/Z-Wave#Assoziation (http://www.fhemwiki.de/wiki/Z-Wave#Assoziation)) sollte man nach der Inklusion eine Assoziation zwischen dem Z-Wave Gateway (in meinem Fall dem Razberry) und dem Z-Wave Gerät (dem Danalock) herstellen.
Allerdings bringt der Befehl:
set <name> associationAdd <associationGroup> <CtrlNodeId>
in meinem Fall: set ZWave_ENTRY_CONTROL_2 associationAdd 2 1
die Ausgabe:
Unknown argument associationAdd, choose one of basicSet basicValue neighborUpdate secKey secNonce secScheme versionClassRequest

Übersehe ich etwas Grundlegendes?
Gibt es hier vielleicht jemanden der das Danalock schon komplett in Fhem eingerichtet hat?

Ein weiteres Problem ist, dass die meisten get Befehle für das Danalock einen Timeout werfen... könnte natürlich daran liegen das das Gerät das nicht unterstützt oder ständig im Tiefschlaf ist.

Danke schon einmal

tiffi

Danalock braucht die Command Class SECURITY, die derzeit noch nicht in Fhem implementiert ist. Darum kann es derzeit so nicht funktionieren.
Es gibt recht weit fortgeschrittene Testversion für die SECURITY-Implementierung, die auch noch Tester sucht. Details: http://forum.fhem.de/index.php/topic,38587.msg307798.html#msg307798
ZWave-spezfische Fragen sind im Übrigen besser im Unterforum ZWave aufgehoben.

Hallo tiffi,

Zitat von: krikan am 01 September 2015, 23:29:06
Danalock braucht die Command Class SECURITY, die derzeit noch nicht in Fhem implementiert ist. Darum kann es derzeit so nicht funktionieren.
Es gibt recht weit fortgeschrittene Testversion für die SECURITY-Implementierung, die auch noch Tester sucht. Details: http://forum.fhem.de/index.php/topic,38587.msg307798.html#msg307798

Neben der Command Class SECURITY die wir, wie Krikan schrieb, schon recht gut laufen haben, ist für das DanaLock aber auch noch (mindestens) die Command Class DOOR_LOCK nötig. In der Testversion für die SECURITY-Implementierung habe ich auch schon mal angefangen zwei GET-Befehle aus der Version 1 der Klasse zu implementieren. Bei Gelegenheit werde ich dann auch mal die beiden SET-Befehle implementieren. Allerdings unterstützt (benötigt?) das DanaLock anscheinend bereits Versionen >1, und hierzu existieren anscheinend keine verfügbaren Dokumentationen an denen man sich orientieren kann.

Wir werden sehen wie "weit" man mit den beiden SET-Befehlen aus der DOOR_LOCK V1 kommt, das Schloss hat auch noch die Klasse USER_CODE, welche z.B. bei meinem RFID-Leser dazu da ist, die Codes der (erlaubten) RFID-Tags zu programmieren. Alles weitere dann am besten im ZWave Forum.

Gruß,
Andreas.

Weitere

Hallo Zusammen,
hab seit 1 Woche ebenfalls das Danalock mit ZW. Auch wurde ein ZWave_ENTRY_CONTROL_4 in meinem FHEM unter Ubuntu angelegt.

Hat die Implementation schon jemand geschafft?

LG, Elmar

Hi,
Für die Befehlsklasse Doorlock sind aktuell nur zwei Get-Befehle implementiert. Die zwei dazu gehörenden Set-Befehle fehlen noch. Wie weit man mit der V1 der Klasse kommt muss man dann sehen. Doku für höhere Versionen habe ich nicht. Ich kann aber erst in 1 Woche was daran machen.
Einbindung mit Security sollte gehen, aber die zusätzlichen Klassen werden danach noch nicht eingebunden. Auch das ist noch offen.
Gruß, Andreas.

Hallo Andreas,
danke für die Info. Freut mich das Du da dran bist :-)

LG!

Hi ELmarK,
dauert aber noch etwas bis ich dazu komme, diese Woche ist ganz schlecht und dann ist erst noch mal etwas grundlegendes für SECURITY dran.

Steht das Schloss den zum ausprobieren zur Verfügung oder ist das bereits eingebaut? Wie konfigurierst/bedienst Du das denn jetzt? Per Bluetooth?

Gruß,
Andreas.

Hallo Andreas,
ist eingebaut und kann jederzeit mit Z-Wave getestet werden. Ja, derzeit leider
nur via Bluetooth :-(

LG, Elmar

Hi,

dann muss ich mal anfangen da ein wenig mehr zu implementieren.

Was für Möglichkeiten hast Du denn wenn Du das Schloss per Bluetooth bedienst?
Wir/Ich habe nämlich nur eine Doku V1 und das Schloss unterstützt V2, evtl. kann man da aus den Möglichkeiten der Bluetooth App erkennen was V2 beinhaltet...

Dauert aber sicherlich noch einige Tage bis ich da mal etwas weiter gekommen bin.

Gruß,
Andreas.

Hi ElmarK,

Zitat von: ElmarK am 02 November 2015, 19:56:21
Hallo Andreas,
ist eingebaut und kann jederzeit mit Z-Wave getestet werden. Ja, derzeit leider
nur via Bluetooth :-(

mit der neuesten Version von 10_ZWave.pm müsstest Du das Schloss mit SECURITY einbinden können und es müssten die neuen Klassen unter SECURITY dann auch im Attribut classes angezeigt werden.
Ein paar Hinweise zum Einbinden unter Security sind hier (http://forum.fhem.de/index.php/topic,38587.msg307798.html#msg307798), vor allem das hier ist wichtig... ,-)
set <Devicename ZWave, meist ZWDongle_0> addNode on sec

Wenn Du das Schloss mal einbinden könntest und ein "list" von dem Gerät posten könntest wäre das schon mal hilfreich. Es müssten dann auch zwei GET-Befehle:
(get) doorLockOperation und
(get) doorLockConfiguration auswählbar sein.

Damit könntest Du auch schon mal rumprobieren und schreiben was so angezeigt wird bzw. in das Log geschrieben wird. Vielleicht kannst Du auch mal vergleichen was Dein Bluetooth Tool da im Vergleich anzeigt.

Gruß,
Andreas.

Hallo Andreas,
sorry für die späte Reaktion. ich habe den Dongle schon länger im FHEM eingebunden. den Dongle habe ich nun mit sec
und networkkey integriert. muss ich das schloss löschen und neu anlernen ?

LG, Elmar

Hallo Andreas,
hilft das vielleicht f?

http://www.pepper1.net/zwavedb/device/603

Hi Elmar,

Zitat von: ElmarK am 09 November 2015, 13:36:40
Hallo Andreas,
sorry für die späte Reaktion. ich habe den Dongle schon länger im FHEM eingebunden. den Dongle habe ich nun mit sec
und networkkey integriert. muss ich das schloss löschen und neu anlernen ?

da ich nicht weiß mit welcher Version Du das gemacht hast und bei der Inklusion was geändert wurde solltest Du das Schloss noch exkludieren und wieder neu (mit "sec on") inkludieren.
Ein Log mit Level 5 (Attribut verbose beim ZWave-Dongle) von der Inklusion wäre schön.

Für die weiteren Tests solltest Du danach auch beim Schloss den Loglevel auf 5 setzen.
Ein "get <...> versionClass" wäre dann interessant, und wenn Du dann noch die beiden Befehle für Doorlock auslösen könntest hätte ich erst mal alles. Da noch nichts auf das Schloss geschrieben wird ist das auch erst einmal völlig ungefährlich ,-)

Zitat von: ElmarK am 09 November 2015, 13:38:14
http://www.pepper1.net/zwavedb/device/603

Das hilft nur eingeschränkt, aber da sind zumindest mal die Configurationsparameter aufgelistet. In dieser Liste steht z.B. die Klasse DoorLock noch mit V1 drin, ich bin mir aber recht sicher das da schon jemand was mit einer V2 gepostet hat, d.h. der Eintrag ist auch nicht mehr ganz aktuell.

Aber schauen wir erst mal was die Inklusion und die beiden get-Reports ergeben.

Gruß,
Andreas.

Hallo Andreas,
die 10_zwave... ist über die fhem update Funktion immer aktuell, oder muss ich eine Andere nehmen?

LG, Elmar

Hallo Andreas,
hier das LOG:

2015.11.09 19:16:48 2: autocreate: define ZWave_ENTRY_CONTROL_4 ZWave e6bfee46 4 72808698
2015.11.09 19:16:48 2: autocreate: define FileLog_ZWave_ENTRY_CONTROL_4 FileLog ./log/ZWave_ENTRY_CONTROL_4-%Y.log ZWave_ENTRY_CONTROL_4
2015.11.09 19:16:49 4: ZWDongle_Read ZWDongle_0: sending ACK, processing 004a01050400
2015.11.09 19:16:49 5: SW: 06
2015.11.09 19:16:49 5: ZWDongle_0 dispatch 004a01050400
2015.11.09 19:16:49 4: ZWDongle_0 CMD:ZW_ADD_NODE_TO_NETWORK ID:05 ARG:0400
2015.11.09 19:16:49 2: ZWAVE Starting secure init
2015.11.09 19:16:49 5: ZWDongle_Write 00 1304039804002504
2015.11.09 19:16:49 5: SW: 010a0013040398040025045c
2015.11.09 19:16:49 5: ACK received, WaitForAck=>2 for 010a0013040398040025045c
2015.11.09 19:16:49 4: ZWDongle_Read ZWDongle_0: sending ACK, processing 011301
2015.11.09 19:16:49 5: SW: 06
2015.11.09 19:16:49 5: ZWDongle_0 dispatch 011301
2015.11.09 19:16:51 4: no response from device, removing 010a0013040398040025045c from dongle sendstack
2015.11.09 19:16:52 4: ZWDongle_Read ZWDongle_0: sending ACK, processing 00130401015d
2015.11.09 19:16:52 5: SW: 06
2015.11.09 19:16:52 5: ZWDongle_0 dispatch 00130401015d
2015.11.09 19:16:52 4: ZWDongle_0 CMD:ZW_SEND_DATA ID:01 ARG:015d
2015.11.09 19:16:52 2: ZWDongle_0 transmit NO_ACK for 04
2015.11.09 19:16:53 4: ZWDongle_Read ZWDongle_0: sending ACK, processing 0004000403980500
2015.11.09 19:16:53 5: SW: 06
2015.11.09 19:16:53 5: ZWDongle_0 dispatch 0004000403980500
2015.11.09 19:16:53 4: ZWDongle_0 CMD:APPLICATION_COMMAND_HANDLER ID:04 ARG:03980500
2015.11.09 19:16:53 4: ZWDongle_ReadAnswer arg:secNonce regexp:^00040004..98
2015.11.09 19:16:53 4: ZWDongle_Read ZWDongle_0: sending ACK, processing 0004000403980500
2015.11.09 19:16:53 5: SW: 06
2015.11.09 19:16:53 4: ZWDongle_ReadAnswer for secNonce: 0004000403980500
2015.11.09 19:16:53 4: ZWDongle_0 CMD:APPLICATION_COMMAND_HANDLER ID:04 ARG:03980500
2015.11.09 19:16:59 2: ZWave: No ACK from ZWave_ENTRY_CONTROL_4 after 10s for sent:1304039804002504
2015.11.09 19:16:59 5: ZWDongle_Write 00 13040298402504
2015.11.09 19:16:59 5: SW: 010900130402984025041a
2015.11.09 19:16:59 5: ACK received, WaitForAck=>2 for 010900130402984025041a
2015.11.09 19:16:59 4: ZWDongle_Read ZWDongle_0: sending ACK, processing 011301
2015.11.09 19:16:59 5: SW: 06
2015.11.09 19:16:59 5: ZWDongle_0 dispatch 011301
2015.11.09 19:16:59 4: ZWDongle_Read ZWDongle_0: sending ACK, processing 001304000002
2015.11.09 19:16:59 5: SW: 06
2015.11.09 19:16:59 5: device ack reveived, removing 010900130402984025041a from dongle sendstack
2015.11.09 19:16:59 5: ZWDongle_0 dispatch 001304000002
2015.11.09 19:16:59 4: ZWDongle_0 CMD:ZW_SEND_DATA ID:00 ARG:0002
2015.11.09 19:16:59 4: ZWDongle_0 transmit OK for 04
2015.11.09 19:16:59 4: ZWDongle_Read ZWDongle_0: sending ACK, processing 000400040a98808c700c9ad5bcd82c
2015.11.09 19:16:59 5: SW: 06
2015.11.09 19:16:59 5: ZWDongle_0 dispatch 000400040a98808c700c9ad5bcd82c
2015.11.09 19:16:59 4: ZWDongle_0 CMD:APPLICATION_COMMAND_HANDLER ID:04 ARG:0a98808c700c9ad5bcd82c
2015.11.09 19:16:59 1: ZWave_ENTRY_CONTROL_4: no stored commands in Internal secMsg found
2015.11.09 19:16:59 1: PERL WARNING: Use of uninitialized value $getSecMsg in split at ./FHEM/10_ZWave.pm line 2070.
2015.11.09 19:16:59 1: ZWave_ENTRY_CONTROL_4: Error, nonce reveived but no stored command for encryption found
2015.11.09 19:17:12 4: ZWDongle_Read ZWDongle_0: sending ACK, processing 004984040704400272808698
2015.11.09 19:17:12 5: SW: 06
2015.11.09 19:17:12 5: ZWDongle_0 dispatch 004984040704400272808698
2015.11.09 19:17:12 4: ZWDongle_0 CMD:ZW_APPLICATION_UPDATE ID:04 ARG:0704400272808698

Das Danalock steht jetzt auf: SECURITY INITIALIZING (starting secure inclusion)

Die get sind leider nicht vorhanden ...

Hi Elmar,

Zitat von: ElmarK am 09 November 2015, 19:13:39
die 10_zwave... ist über die fhem update Funktion immer aktuell, oder muss ich eine Andere nehmen?

die offizielle Version ist erst einmal in Ordnung, die letzten Änderungen sind auch schon ein paar Tage alt, d.h. es ist also alles enthalten solange Du auch "shutdown restart" nach dem Update machst.

Es hat mit den Tests auch Zeit, ich hab' gerade auch noch zwei andere Baustellen zu Hause ,-)
Hmm, während ich schrieb hast Du schon den ersten Test geschickt... Ich schau mir das später noch mal kurz an. Status "Initializing" ist schon mal nicht gut... Dann ist Security nicht da, dann sind die ganzen Klassen nicht da und die beiden Befehle auch nicht.

Gruß,
Andreas.

Edit: P.S.: Logausschnitte am besten in die "Code-Tags" packen (das Icon mit dem "#")

Hallo Andreas,
hier noch ein 2ter Versuch.... :)


2015.11.09 19:39:29 1: in UNDEFINED
2015.11.09 19:39:29 2: autocreate: define ZWave_ENTRY_CONTROL_4 ZWave e6bfee46 4 72808698
2015.11.09 19:39:29 2: autocreate: define FileLog_ZWave_ENTRY_CONTROL_4 FileLog ./log/ZWave_ENTRY_CONTROL_4-%Y.log ZWave_ENTRY_CONTROL_4
2015.11.09 19:39:31 1: checkFritzMACpresent (FritzBox_Telnet): mac_98_FE_94_39_8B_95 nicht gefunden, abwesend.
2015.11.09 19:39:31 1: checkFritzMACpresent (FritzBox_Telnet): mac_24_E3_14_26_AF_D7 gefunden, Gerät heißt >eKoschka-SKV<.
2015.11.09 19:39:31 1: checkFritzMACpresent (FritzBox_Telnet): mac_78_D7_5F_53_94_2F gefunden, Gerät heißt >PC-192-168-178-22<.
2015.11.09 19:39:34 4: ZWDongle_Read ZWDongle_0: sending ACK, processing 004a01050400
2015.11.09 19:39:34 5: SW: 06
2015.11.09 19:39:34 5: ZWDongle_0 dispatch 004a01050400
2015.11.09 19:39:34 4: ZWDongle_0 CMD:ZW_ADD_NODE_TO_NETWORK ID:05 ARG:0400
2015.11.09 19:39:34 2: ZWAVE Starting secure init
2015.11.09 19:39:34 5: ZWDongle_Write 00 1304039804002504
2015.11.09 19:39:34 5: SW: 010a0013040398040025045c
2015.11.09 19:39:34 5: ACK received, WaitForAck=>2 for 010a0013040398040025045c
2015.11.09 19:39:34 4: ZWDongle_Read ZWDongle_0: sending ACK, processing 011301
2015.11.09 19:39:34 5: SW: 06
2015.11.09 19:39:34 5: ZWDongle_0 dispatch 011301
2015.11.09 19:39:35 4: ZWDongle_Read ZWDongle_0: sending ACK, processing 001304000074
2015.11.09 19:39:35 5: SW: 06
2015.11.09 19:39:35 5: device ack reveived, removing 010a0013040398040025045c from dongle sendstack
2015.11.09 19:39:35 5: ZWDongle_0 dispatch 001304000074
2015.11.09 19:39:35 4: ZWDongle_0 CMD:ZW_SEND_DATA ID:00 ARG:0074
2015.11.09 19:39:35 4: ZWDongle_0 transmit OK for 04
2015.11.09 19:39:35 4: ZWDongle_Read ZWDongle_0: sending ACK, processing 0004000403980500
2015.11.09 19:39:35 5: SW: 06
2015.11.09 19:39:35 5: ZWDongle_0 dispatch 0004000403980500
2015.11.09 19:39:35 4: ZWDongle_0 CMD:APPLICATION_COMMAND_HANDLER ID:04 ARG:03980500
2015.11.09 19:39:35 5: ZWDongle_Write 00 13040298402504
2015.11.09 19:39:35 5: SW: 010900130402984025041a
2015.11.09 19:39:35 4: ZWDongle_ReadAnswer arg:secNonce regexp:^00040004..98
2015.11.09 19:39:35 5: ACK received, WaitForAck=>2 for 010900130402984025041a
2015.11.09 19:39:35 4: ZWDongle_Read ZWDongle_0: sending ACK, processing 011301
2015.11.09 19:39:35 5: SW: 06
2015.11.09 19:39:35 5: ZWDongle_0 dispatch 011301
2015.11.09 19:39:37 4: ZWDongle_Read ZWDongle_0: sending ACK, processing 00130400007c
2015.11.09 19:39:37 5: SW: 06
2015.11.09 19:39:37 5: device ack reveived, removing 010900130402984025041a from dongle sendstack
2015.11.09 19:39:37 5: ZWDongle_0 dispatch 00130400007c
2015.11.09 19:39:37 4: ZWDongle_0 CMD:ZW_SEND_DATA ID:00 ARG:007c
2015.11.09 19:39:37 4: ZWDongle_0 transmit OK for 04
2015.11.09 19:39:40 5: ZWDongle_ReadAnswer: select timeout


Hab den FHEM Server mal komplett neu gestartet. Jetzt stehe ich auf

SECURITY  INITIALIZING (Networkkey sent)


Das Logfile sagt:

2015.11.09 19:50:42 2: autocreate: define ZWave_ENTRY_CONTROL_4 ZWave e6bfee46 4 72808698
2015.11.09 19:50:42 2: autocreate: define FileLog_ZWave_ENTRY_CONTROL_4 FileLog ./log/ZWave_ENTRY_CONTROL_4-%Y.log ZWave_ENTRY_CONTROL_4
2015.11.09 19:50:44 4: ZWDongle_Read ZWDongle_0: sending ACK, processing 004a01050400
2015.11.09 19:50:44 5: SW: 06
2015.11.09 19:50:44 5: ZWDongle_0 dispatch 004a01050400
2015.11.09 19:50:44 4: ZWDongle_0 CMD:ZW_ADD_NODE_TO_NETWORK ID:05 ARG:0400
2015.11.09 19:50:44 2: ZWAVE Starting secure init
2015.11.09 19:50:44 5: ZWDongle_Write 00 1304039804002504
2015.11.09 19:50:44 5: SW: 010a0013040398040025045c
2015.11.09 19:50:44 5: ACK received, WaitForAck=>2 for 010a0013040398040025045c
2015.11.09 19:50:44 4: ZWDongle_Read ZWDongle_0: sending ACK, processing 011301
2015.11.09 19:50:44 5: SW: 06
2015.11.09 19:50:44 5: ZWDongle_0 dispatch 011301
2015.11.09 19:50:46 4: no response from device, removing 010a0013040398040025045c from dongle sendstack
2015.11.09 19:50:47 4: ZWDongle_Read ZWDongle_0: sending ACK, processing 00130400016e
2015.11.09 19:50:47 5: SW: 06
2015.11.09 19:50:47 5: ZWDongle_0 dispatch 00130400016e
2015.11.09 19:50:47 4: ZWDongle_0 CMD:ZW_SEND_DATA ID:00 ARG:016e
2015.11.09 19:50:47 4: ZWDongle_0 transmit OK for 04
2015.11.09 19:50:47 4: ZWDongle_Read ZWDongle_0: sending ACK, processing 0004000403980500
2015.11.09 19:50:47 5: SW: 06
2015.11.09 19:50:47 5: ZWDongle_0 dispatch 0004000403980500
2015.11.09 19:50:47 4: ZWDongle_0 CMD:APPLICATION_COMMAND_HANDLER ID:04 ARG:03980500
2015.11.09 19:50:47 5: ZWDongle_Write 00 13040298402504
2015.11.09 19:50:47 5: SW: 010900130402984025041a
2015.11.09 19:50:47 4: ZWDongle_ReadAnswer arg:secNonce regexp:^00040004..98
2015.11.09 19:50:47 5: ACK received, WaitForAck=>2 for 010900130402984025041a
2015.11.09 19:50:47 4: ZWDongle_Read ZWDongle_0: sending ACK, processing 011301
2015.11.09 19:50:47 5: SW: 06
2015.11.09 19:50:47 5: ZWDongle_0 dispatch 011301
2015.11.09 19:50:47 4: ZWDongle_Read ZWDongle_0: sending ACK, processing 001304000002
2015.11.09 19:50:47 5: SW: 06
2015.11.09 19:50:47 5: device ack reveived, removing 010900130402984025041a from dongle sendstack
2015.11.09 19:50:47 5: ZWDongle_0 dispatch 001304000002
2015.11.09 19:50:47 4: ZWDongle_0 CMD:ZW_SEND_DATA ID:00 ARG:0002
2015.11.09 19:50:47 4: ZWDongle_0 transmit OK for 04
2015.11.09 19:50:48 4: ZWDongle_Read ZWDongle_0: sending ACK, processing 000400040a98800c1d9d4f0f6b178f
2015.11.09 19:50:48 5: SW: 06
2015.11.09 19:50:48 4: ZWDongle_ReadAnswer for secNonce: 000400040a98800c1d9d4f0f6b178f
2015.11.09 19:50:48 4: ZWDongle_0 CMD:APPLICATION_COMMAND_HANDLER ID:04 ARG:0a98800c1d9d4f0f6b178f
2015.11.09 19:50:48 5: ZWDongle_Write 00 1304269881aa22b29b0d5aa9928ba4fcc53bc223c49afdfb72db92a265e61d900c268721843416c9d72504
2015.11.09 19:50:48 5: SW: 012d001304269881aa22b29b0d5aa9928ba4fcc53bc223c49afdfb72db92a265e61d900c268721843416c9d7250421
2015.11.09 19:50:48 5: ACK received, WaitForAck=>2 for 012d001304269881aa22b29b0d5aa9928ba4fcc53bc223c49afdfb72db92a265e61d900c268721843416c9d7250421
2015.11.09 19:50:48 4: ZWDongle_Read ZWDongle_0: sending ACK, processing 011301
2015.11.09 19:50:48 5: SW: 06
2015.11.09 19:50:48 5: ZWDongle_0 dispatch 011301
2015.11.09 19:50:48 4: ZWDongle_Read ZWDongle_0: sending ACK, processing 001304000003
2015.11.09 19:50:48 5: SW: 06
2015.11.09 19:50:48 5: device ack reveived, removing 012d001304269881aa22b29b0d5aa9928ba4fcc53bc223c49afdfb72db92a265e61d900c268721843416c9d7250421 from dongle sendstack
2015.11.09 19:50:48 5: ZWDongle_0 dispatch 001304000003
2015.11.09 19:50:48 4: ZWDongle_0 CMD:ZW_SEND_DATA ID:00 ARG:0003
2015.11.09 19:50:48 4: ZWDongle_0 transmit OK for 04


Hi Elmar,

ich denke Du kannst erst mal 'ne kleine Pause beim Testen machen. Ich muss mal schauen an welchen Stellen das System hängen bleibt und kann Dir dann evtl. eine angepasste Version der 10_Zwave.pm für weitere Tests zur Verfügung stellen. Das wird aber wohl frühestens Donnerstag was werden.

Bisher ist mir aufgefallen das im ersten Versuch die Empfangsbestätigung vom Schloss 2 Sekunden gebraucht hat -> ZWave hatte da bereits "aufgegeben"....
Danach kommt der Ablauf etwas durcheinander und anscheinend geht in meinem Stack ein Befehl verloren ,-(

Im zweiten Versuch gibt es einen Timeout bei einem Get-Befehl (kann ich in einer Testversion "umgehen")

Im dritten Versuch fängt es erst mal genau an wie im ersten, läuft dann aber weiter durch. Allerdings kommt anscheinend keine Antwort auf das Senden des Netzwerkschlüssels.

Insgesamt alles eher Probleme die auf grundlege Probleme mit dem aktuellen ZWave Code hindeuten. Ich schau mir das mal etwas genauer an und werde mich auch mal mit Rudi deswegen in Verbindung setzen.

Weitere Tests machen daher momentan wenig Sinn...

Gruß,
Andreas.

P.S.: Könntest Du bitte in "global" das Attribut mseclog auf "1" setzen? Das schaltet die Anzeige von millisekunden im Logfile ein.

Hallo Andreas,
dann pausier ich mal :-)

Danke, das Du da so dran bist !

LG, Elmar

Hi Elmar,

hast Du evtl. gleichzeitig noch irgendwas auf dem Server oder in FHEM laufen was zum Blockieren von FHEM führen könnte? Andere komplizierte Steuerungen, HomeMatic Geräte, weitere CUL, ...?

Da ich auch Probleme mit der Kommunikation hatte habe ich ein allgemeines Problem vermuten, aktuell funktioniert bei mir aber alles einwandfrei, sodaß es kein allegemeines Problem sein kann.
Bei Dir dauern Antworten vom Schloss aber teilweise ungewöhnlich lang oder bleiben ganz weg.

Hast Du noch weitere ZWave Geräte? Wie weit bist Du mit dem Dongle vom Schloss weg? Wird das evtl. über ein anderes Gerät geroutet?

Gruß,
Andreas.

 

Zitat von: A.Harrenberg am 09 November 2015, 21:31:31
hast Du evtl. gleichzeitig noch irgendwas auf dem Server oder in FHEM laufen was zum Blockieren von FHEM führen könnte? Andere komplizierte Steuerungen, HomeMatic Geräte, weitere CUL, ...?

Da ich auch Probleme mit der Kommunikation hatte habe ich ein allgemeines Problem vermuten, aktuell funktioniert bei mir aber alles einwandfrei, sodaß es kein allegemeines Problem sein kann.
Bei Dir dauern Antworten vom Schloss aber teilweise ungewöhnlich lang oder bleiben ganz weg.

Hast Du noch weitere ZWave Geräte? Wie weit bist Du mit dem Dongle vom Schloss weg? Wird das evtl. über ein anderes Gerät geroutet?

Gruß,
Andreas.

Hallo Andreas,
ich habe noch einen CUL an einem anderen USB Port. Allerdings kann man nicht von komplizierter Steuerung reden. Bin erst am Aufbauen und habe nur 3 Intertechno Steckdosen zum testen dran. ZWave habe ich derzeit nur das Danalock. Allerdings ist der Server am Dachboden und die Tür im Erdgeschoss (2 Stockwerke). Kann das zu weit weg sein, zumal ja ein teil am ZWave Stick ankommt? Werde das heute Abend mal testen, wenn ich das Schloss neben den Stick halte ...

LG, Elmar
Hi Elmar,

Hallo Andreas,
also jetzt ca 50 cm. vom ZWave Dongle weg stehe ich wieder auf:

SECURITY INITIALIZING (starting secure inclusion)

:-[

Hi Elmar,

Zitat von: ElmarK am 10 November 2015, 18:00:18
Hallo Andreas,
also jetzt ca 50 cm. vom ZWave Dongle weg stehe ich wieder auf:

Code Auswählen Erweitern

SECURITY INITIALIZING (starting secure inclusion)

:-[

könntest Du bitte noch mal ein Log von der Inklusion (mit dem mseclog = 1) machen und posten?

Wahrscheinlich reicht bei Dir der Time-Out von 2 Sekunden für die Sendebestätigung nicht aus und müsste etwas erhöht werden, das muss ich mir aber erst noch mal im Detail ansehen da Rudi da kurzlich was geändert hat und ich das noch nicht so genau analysiert haben.

Gruß,
Andreas.

Hallo Andreas,
klar!

2015.11.10 17:57:34.594 1: in UNDEFINED
2015.11.10 17:57:34.594 2: autocreate: define ZWave_ENTRY_CONTROL_4 ZWave e6bfee46 4 72808698
2015.11.10 17:57:34.594 2: autocreate: define FileLog_ZWave_ENTRY_CONTROL_4 FileLog ./log/ZWave_ENTRY_CONTROL_4-%Y.log ZWave_ENTRY_CONTROL_4
2015.11.10 17:57:35.778 4: ZWDongle_Read ZWDongle_0: sending ACK, processing 004a01050400
2015.11.10 17:57:35.778 5: SW: 06
2015.11.10 17:57:35.779 5: ZWDongle_0 dispatch 004a01050400
2015.11.10 17:57:35.781 4: ZWDongle_0 CMD:ZW_ADD_NODE_TO_NETWORK ID:05 ARG:0400
2015.11.10 17:57:35.781 2: ZWAVE Starting secure init
2015.11.10 17:57:35.781 5: ZWDongle_Write 00 1304039804002504
2015.11.10 17:57:35.782 5: SW: 010a0013040398040025045c
2015.11.10 17:57:35.783 5: ACK received, WaitForAck=>2 for 010a0013040398040025045c
2015.11.10 17:57:35.791 4: ZWDongle_Read ZWDongle_0: sending ACK, processing 011301
2015.11.10 17:57:35.791 5: SW: 06
2015.11.10 17:57:35.792 5: ZWDongle_0 dispatch 011301
2015.11.10 17:57:36.935 4: ZWDongle_Read ZWDongle_0: sending ACK, processing 001304000073
2015.11.10 17:57:36.935 5: SW: 06
2015.11.10 17:57:36.936 5: device ack reveived, removing 010a0013040398040025045c from dongle sendstack
2015.11.10 17:57:36.936 5: ZWDongle_0 dispatch 001304000073

Hi Elmar,

wie, mehr kommt / passiert da nicht?

Also mit: "ZWDongle_Write 00 1304039804002504" wird eine Anfrage "980400" an das Schloss geschickt, das muss vom Schloss mit einer Nachricht *980500* beantwortet werden. Wenn die Antwort vom Schloss nicht kommt dann kann es nicht weitergehen...

Die Anfrage ist aber einwandfrei beim Schloss angekommen, der Empfang der Nachricht wird sauber bestätigt, das ist absolut gar nichts auffällig, außer das keine Antwort kommt.

Kann es evtl. sein das die Batterie von dem Schloss nicht mehr so ganz "frisch" ist? Mir gehen die Ideen aus was hier passiert...

Gruß,
Andreas.

Hallo Andreas,
aktueller Versuch:
2015.11.10 21:45:00.526 2: autocreate: define ZWave_ENTRY_CONTROL_4 ZWave e6bfee46 4 72808698
2015.11.10 21:45:00.526 2: autocreate: define FileLog_ZWave_ENTRY_CONTROL_4 FileLog ./log/ZWave_ENTRY_CONTROL_4-%Y.log ZWave_ENTRY_CONTROL_4
2015.11.10 21:45:01.991 4: ZWDongle_Read ZWDongle_0: sending ACK, processing 004a01050400
2015.11.10 21:45:01.991 5: SW: 06
2015.11.10 21:45:01.993 5: ZWDongle_0 dispatch 004a01050400
2015.11.10 21:45:01.994 4: ZWDongle_0 CMD:ZW_ADD_NODE_TO_NETWORK ID:05 ARG:0400
2015.11.10 21:45:01.994 2: ZWAVE Starting secure init
2015.11.10 21:45:01.995 5: ZWDongle_Write 00 1304039804002504
2015.11.10 21:45:01.995 5: SW: 010a0013040398040025045c
2015.11.10 21:45:01.996 5: ACK received, WaitForAck=>2 for 010a0013040398040025045c
2015.11.10 21:45:02.004 4: ZWDongle_Read ZWDongle_0: sending ACK, processing 011301
2015.11.10 21:45:02.004 5: SW: 06
2015.11.10 21:45:02.005 5: ZWDongle_0 dispatch 011301
2015.11.10 21:45:03.148 4: ZWDongle_Read ZWDongle_0: sending ACK, processing 001304000073
2015.11.10 21:45:03.148 5: SW: 06
2015.11.10 21:45:03.149 5: device ack reveived, removing 010a0013040398040025045c from dongle sendstack
2015.11.10 21:45:03.149 5: ZWDongle_0 dispatch 001304000073
2015.11.10 21:45:03.149 4: ZWDongle_0 CMD:ZW_SEND_DATA ID:00 ARG:0073
2015.11.10 21:45:03.149 4: ZWDongle_0 transmit OK for 04

Steht jetzt wieder bei :

SECURITY INITIALIZING (starting secure inclusion) 2015-11-10 21:45:01


LG, Elmar

Hi Elmar,

sorry, aber so wird das irgendwie nichts ;-(

Es kommte einfach keine Antwort auf die Anfrage vom Gerät... Ob das am Gerät oder an FHEM/ZWave liegt ist nicht feststellbar.
Könntest Du vielleicht noch mal versuchen das Ding OHNE Security einzubinden und das Log posten?

Gruß,
Andreas.

Hallo Andreas,
klar. Mach ich gleich heute Abend.

Komisch ist nur, dass ich z.B. den Batteriezustand abfragen kann...

LG, Elmar

Hi Elmar,

Zitat von: ElmarK am 12 November 2015, 11:42:53
klar. Mach ich gleich heute Abend.

Komisch ist nur, dass ich z.B. den Batteriezustand abfragen kann...

keine übertriebene Eile, aber "komisch" ist das ganze Verhalten schon.

Ich bin mir nicht sicher ob wir (damit meine ich das ZWave-Modul) nicht durch "Quereinwirkung" von anderen Modulen gestört werden. Ich hatte vor ein paar Tagen ja auch ganz merkwürdige Effekte die ich jetzt nicht mehr nachvollziehen kann.

Das Schloss antwortet ja auch auch ansonsten, die Inklusion hat funktioniert, der Empfang der Nachricht wurde ja auch bestätigt, Batteriezustand funktioniert... Es kann kein absolut generelles Problem sein, nur irgendetwas temporäres. Das zu Finden ist aber nahezu unmöglich, das es ja kein "Logfile" im Schloss gibt das man sich anschauen könnte...

Na schauen wir mal was das Ding heute abend "sagt" ,-)

Gruß,
Andreas.

Hallo Andreas,
hier ohne Sec...


2015.11.12 18:31:49.350 2: autocreate: define ZWave_ENTRY_CONTROL_4 ZWave e6bfee46 4 72808698
2015.11.12 18:31:49.351 2: autocreate: define FileLog_ZWave_ENTRY_CONTROL_4 FileLog ./log/ZWave_ENTRY_CONTROL_4-%Y.log ZWave_ENTRY_CONTROL_4
2015.11.12 18:31:58.034 4: ZWDongle_Read ZWDongle_0: sending ACK, processing 004a01050400
2015.11.12 18:31:58.034 5: SW: 06
2015.11.12 18:31:58.035 5: ZWDongle_0 dispatch 004a01050400
2015.11.12 18:31:58.037 4: ZWDongle_0 CMD:ZW_ADD_NODE_TO_NETWORK ID:05 ARG:0400
2015.11.12 18:31:58.538 2: ZWave get ZWave_ENTRY_CONTROL_4 model
2015.11.12 18:31:58.538 5: ZWDongle_Write 00 13040272042504
2015.11.12 18:31:58.538 5: SW: 01090013040272042504b4
2015.11.12 18:31:58.540 4: ZWDongle_ReadAnswer arg:model regexp:^00040004..72
2015.11.12 18:31:58.540 5: ACK received, WaitForAck=>2 for 01090013040272042504b4
2015.11.12 18:31:58.548 4: ZWDongle_Read ZWDongle_0: sending ACK, processing 011301
2015.11.12 18:31:58.548 5: SW: 06
2015.11.12 18:31:58.549 5: ZWDongle_0 dispatch 011301
2015.11.12 18:32:01.552 5: ZWDongle_ReadAnswer: select timeout
2015.11.12 18:32:01.552 1: ZWAVE INIT: get ZWave_ENTRY_CONTROL_4 model: Timeout reading answer for get model
2015.11.12 18:32:01.563 4: no response from device, removing 01090013040272042504b4 from dongle sendstack
2015.11.12 18:32:02.094 4: ZWDongle_Read ZWDongle_0: sending ACK, processing 001304010163
2015.11.12 18:32:02.094 5: SW: 06
2015.11.12 18:32:02.095 5: ZWDongle_0 dispatch 001304010163
2015.11.12 18:32:02.095 4: ZWDongle_0 CMD:ZW_SEND_DATA ID:01 ARG:0163
2015.11.12 18:32:02.095 2: ZWDongle_0 transmit NO_ACK for 04


LG, Elmar und nochmal danke das Du mir da so hilfst...

Hi Elmar,

Zitat von: ElmarK am 12 November 2015, 18:34:02
hier ohne Sec...

LG, Elmar und nochmal danke das Du mir da so hilfst...

irgendwie sieht das nicht besser aus...

Auf die "get ZWave_ENTRY_CONTROL_4 model"gibt es eine Empfangsbestätigung vom Dongle (die 011301 Nachricht), dann kommt ein Timeout weil die Empfangsbestätigung und die Antwort auf die Abfrage nicht kommen.

3.5 sekunden nach dem get-Befehl kommt dann eine 0013xx01 Nachricht vom Gerät, normalerweise würde eine 0013xx00 Nachricht eine Empfangsbestätigung für den Befehl darstellen, in diesem Fall wird aber ein "transmit NO_ACK" zurückgegeben, d.h. der Dongle sagt das das Gerät den Empfang der Nachricht NICHT bestätigt hat.

Irgendwas ist da oberfaul und es hat relativ sicher nichts mit SECURITY zu tun.
Ich bin hier mit meinem Latein (fast) am Ende, vielleicht hat Krikan oder Rudi noch eine Idee was hier klemmt oder wie man das herausfinden könnte.

Ich bastel Dir gleich mal eine Version die den select-Timeout umgeht, vielleicht passiert dann ja mehr...

Gruß,
Andreas.

Hi Elmar,

Du könntest es noch mal mit der angehängten Version der 10_ZWave.pm versuchen. Ich habe dort die Routinen für die GET-Befehle auskommentiert. D.h. es wird jetzt nicht auf eine Antwort gewartet. Das kann dazu führen das die nächste Nachricht zu früh gesendet wird und es deshalb CAN-Nachrichten gibt, es verhindert aber diese 3 Sekunden Wartezeit wenn die Antwort eben "hängt"...
Das ist jetzt nur zum Testen gedacht (die gewohnten Antwortfenster in der WebOberfläche sind damit z.B. auch abgeschaltet) und nichts für die Produktivumgebung.

Du kannst damit ja mal eine normale und eine Secure Inklusion probieren.

Hast Du das Schloss jetzt eigentlich ausgebaut oder ist das immer noch 2 Etagen weit weg?

Gruß,
Andreas.

Hallo Andreas,
danke, aber hier mit sec:

2015.11.12 19:22:33.611 2: autocreate: define ZWave_ENTRY_CONTROL_4 ZWave e6bfee46 4 72808698
2015.11.12 19:22:33.612 2: autocreate: define FileLog_ZWave_ENTRY_CONTROL_4 FileLog ./log/ZWave_ENTRY_CONTROL_4-%Y.log ZWave_ENTRY_CONTROL_4
2015.11.12 19:22:42.213 4: ZWDongle_Read ZWDongle_0: sending ACK, processing 004a01050400
2015.11.12 19:22:42.213 5: SW: 06
2015.11.12 19:22:42.214 5: ZWDongle_0 dispatch 004a01050400
2015.11.12 19:22:42.216 4: ZWDongle_0 CMD:ZW_ADD_NODE_TO_NETWORK ID:05 ARG:0400
2015.11.12 19:22:42.216 2: ZWAVE Starting secure init
2015.11.12 19:22:42.216 5: ZWDongle_Write 00 1304039804002504
2015.11.12 19:22:42.216 5: SW: 010a0013040398040025045c
2015.11.12 19:22:42.218 5: ACK received, WaitForAck=>2 for 010a0013040398040025045c
2015.11.12 19:22:42.226 4: ZWDongle_Read ZWDongle_0: sending ACK, processing 011301
2015.11.12 19:22:42.226 5: SW: 06
2015.11.12 19:22:42.227 5: ZWDongle_0 dispatch 011301
2015.11.12 19:22:43.370 4: ZWDongle_Read ZWDongle_0: sending ACK, processing 001304000073
2015.11.12 19:22:43.370 5: SW: 06
2015.11.12 19:22:43.371 5: device ack reveived, removing 010a0013040398040025045c from dongle sendstack
2015.11.12 19:22:43.371 5: ZWDongle_0 dispatch 001304000073
2015.11.12 19:22:43.371 4: ZWDongle_0 CMD:ZW_SEND_DATA ID:00 ARG:0073
2015.11.12 19:22:43.371 4: ZWDongle_0 transmit OK for 04


und ohne sec wird es nicht mehr angelegt :-(

Hatte das Schloss vorgestern direkt neben dem Dongle liegen...keine Veränderung.

Mannomann

Hi Elmar,

tja, sieht genauso aus wie ein paar Versuche vorher.

Get-Befehl für Security-Scheme wird versendet, Empfang wird vom Dongle UND vom Gerät bestätigt, es kommt aber keine Antwort.

Ich habe keine weiteren Ideen mehr...

Gruß,
Andreas.

Schade ... :-(

Hi,

Zitat von: ElmarK am 12 November 2015, 20:10:40
Schade ... :-(

ja, finde ich auch, aber wenn das Ding nicht mit uns reden will...
Hast Du das Ding vielleicht mal mit Batterie raus/rein resettet? Aber es schon noch eingebaut, oder?

Gruß,
Andreas.

Ja, hab ich auch schon versucht :-(

Ich hoffe das die Einbindung in FHEM klappt, die Danalock App funktioniert nämlich nicht ganz so gut...
Lohnt es sich einen Zwave usb-stick zu kaufen, damit ich das Schloss einbinden und mit testen kann, oder ist die Situation ausweglos?
Habe die neue Version des Schlosses.

Hi,

Zitat von: Bigsonic1 am 13 November 2015, 23:29:24
Ich hoffe das die Einbindung in FHEM klappt, die Danalock App funktioniert nämlich nicht ganz so gut...
Lohnt es sich einen Zwave usb-stick zu kaufen, damit ich das Schloss einbinden und mit testen kann, oder ist die Situation ausweglos?
Habe die neue Version des Schlosses.

vielleicht erst mal eine kurze Erklärung.

Zum einen geht es um die Verschlüsselung, die ist bereits in der Befehlsklasse SECURITY implementiert und funktioniert mMn gut. Zum anderen geht es um die Befehlsklasse DOORLOCK, hier wären die spezifischen Befehle für solch ein Türschloss zu implementieren. Informationen zur Version 1 dieser Befehlsklasse liegen vor, Informationen zu höheren Versionen nicht. Inwieweit die Befehle der Version 1 zur Bedienung des Schlosses ausreichen kann ich nicht sagen, ich gehe aber davon aus.

Daraus folgt, eigentlich machbar, aber das Gerät von Elmar antwortet einfach teilweise nicht auf Befehle, das passiert sowohl mit, als auch ohne SECURITY.
Ich denke nicht das dies ein generelles Problem ist, sondern eher etwas mit dem Setup bei Elmar zu tun hat. (Defekter Stick, defektes Z-Wave Modul vom Schloss...)

Ich habe Danalock mal kontaktiert ob die mir was zum testen zur Verfügung stellen können. Wenn die Hardwar vor einem liegt ist das mit dem Testen deutlich einfacher.

In der Version 1 von DOORLOCK sind nur 4 Befehle definiert, 2 GET Befehle und 2 SET Befehle. Ein ersten Ansatz für die beiden GET Befehle ist bereits in der aktuellen Versionen von FHEM vorhanden, kann aber momentan nicht getestet werden. Sobald das funktioniert kann ich auch anfangen die beiden SET Befehle zu implementieren. Soweit ich das verstehe ist das jeweils ein GET/SET für die "Betriebsart" des Schlosses und je ein GET/SET für den Zustand. Vieles davon wird für das Danalock gar nicht relevant sein.

Lange Rede, kurzer Sinn: Ich denke das zumindest die Basisfunktionen mit der V1 der Befehlsklasse implementiert werden kann.

Falls Du Dir nun einen ZWave-Stick kaufen möchtest, nimm' einen mit ZWave+ damit solltest Du auf der sicheren Seite sein. Ich habe z.B. zwei von den UZB Stick von Z-Wave.me (https://z-wave.me/index.php?id=28), bestellt hab' ich die bei Amazon.

Gruß,
Andreas.

Zitat

Zitat von: Bigsonic1 am 13 November 2015, 23:29:24
Ich hoffe das die Einbindung in FHEM klappt, die Danalock App funktioniert nämlich nicht ganz so gut...
Lohnt es sich einen Zwave usb-stick zu kaufen, damit ich das Schloss einbinden und mit testen kann, oder ist die Situation ausweglos?
Habe die neue Version des Schlosses.

Hallo und willkommen :-)

Würde ich sehr interessieren ob es bei Dir klappt !

Zitat von: A.Harrenberg am 14 November 2015, 08:54:48
Ich habe Danalock mal kontaktiert ob die mir was zum testen zur Verfügung stellen können. Wenn die Hardwar vor einem liegt ist das mit dem Testen deutlich einfacher.

Das wäre toll, sonst schick ich dir meins ;-) Woher bist Du ?

Hi Elmar,

mal sehen ob die sich melden. Das Ding ist ja recht teuer von daher mach' ich mir da eigentlich keine großen Hoffnungen.

Zitat von: ElmarK am 14 November 2015, 14:50:57
Das wäre toll, sonst schick ich dir meins ;-) Woher bist Du ?

Wenn gar nichts mehr geht komme ich mal drauf zurück. Wobei ich bei Dir ja fast von einem Hardwareproblem ausgehe...
Und ich lebe in Aachen, was aber für's verschicken ziemlich egal wäre.

Ich muss noch mal in den alten Threads suchen,  da war noch jemand mit dem Danalock, vielleicht kann der ja auch noch mal was testen.

Gruß,
Andreas.

Hi,

kurze Rückmeldung wegen der Anfrage bei DanaLock.
Sie bieten mir an das ich ein Testgeräte gegen ein "Pfand" bekommen kann und das "Pfand" dann zurückbekomme wenn ich das Ding wieder zurückschicke. Das Angebot werde ich wohl annehmen, wie lange das jetzt dauert bis das Ding dann bei mir auf dem Tisch liegt ist aber noch völlig offen.

Immerhin haben die bereits heute Mittag geantwortet, wenn der Rest auch so schnell geht... ,-)

Gruß,
Andreas.

Das hört sich doch gut an, dann werden die aber ja bestimmt die 2. Version zuschicken!?

Hi, momentan haben die erst mal einen kleinen Rückzieher gemacht und mich an den deutschen Partner verwiesen. Ich bin aber noch positiv gestimmt das es klappt.

Hast Du denn auch ein DanaLock?

Gruß,
Andreas.

Hallo Andreas,
hilft der Anhang evtl. weiter ?

LG, Elmar

Hi Elmar,

zumindest ist das schon mal die Liste der Config parameter drin.

Ich bin momentan immer noch im Kontakt mit DanaLock, allerdings scheinen meine Mail an den deutschen Vertriebspartner im SPAM zu landen... ,-( Vielleicht muss ich dort mal anrufen.

Gruß,
Andreas.

Hallo!
Wo bekommt man die ZWave+ Variante?
Gruß, Christian

Moinsen,

ich überlege auch schon mir ein Danalock zu holen - mit Bluetooth allein ist schon nicht schlecht,
aber Z-Wave würde mich noch mehr interessieren.
Wie ist denn die Chance das Teil mit FHEM steuern zu können ?


Das Danalock mit Z-Wave kostet übrigens mit den 4 Wechselzylindern 249,- und ohne die Zylinder 229,- €

Guggst hier z.B. : http://www.amazon.de/gp/product/B015JGRK6Q/ref=noref?ie=UTF8&psc=1&s=ce-de (http://www.amazon.de/gp/product/B015JGRK6Q/ref=noref?ie=UTF8&psc=1&s=ce-de)

Hi Fylo,

das Ding mit dem Amazon-Link ist noch die "alte" Version V1.25, die neue V2 Variante scheint igendwie noch nicht im Handel zu sein...

Die Unterstützung seitens FHEM sieht nicht soo schlecht aus. Die verschlüsselte Kommunikation funktioniert prinzipiell ja schon, es gibt da aber noch Probleme das Nachrichten verloren gehen können und das ganze dann etwas aus dem Takt kommt. Das wird auch noch eine Weile dauern bis ich das in den Griff bekomme, dazu sind leider ein paar größere Änderungen nötig.

Zudem ist die DOOR_LOCK Klasse noch nicht fertig implementiert, hier gibt es nur Informationen zu der Version 1, das Schloss unterstützt bereits eine V2, d.h. die neuen Funktionen können wir nur durch probieren herausbekommen...

Ich würde da vielleicht doch noch etwas abwarten ,-)

Gruß,
Andreas.

Hi Andreas, Hi all,

ah jetzt - ja ;)

Nu macht auch das V125 einen Sinn im Produkttitel.
Fragt sich nur ob die V1.25 besser oder schlechter sein wird als die kommende V2.0(die es ja noch nicht zu geben scheint)

Grüßles, Fylo

Zitat von: Fylo am 30 November 2015, 13:43:27
Fragt sich nur ob die V1.25 besser oder schlechter sein wird als die kommende V2.0(die es ja noch nicht zu geben scheint)

Ich kaufe persönlich keine ZWave-, sondern nur -wenn irgendmöglich- ZWave+-Geräte. Unterschiede (u.a. bessere Reichweite usw.) müsstest Du bitte im Wiki bzw. den Links nachlesen. Normalerweise fällt man mit den neueren ZWave+ Geräten nicht auf die Nase. Aber Ausnahmen (http://forum.fhem.de/index.php/topic,40771.0.html) bestätigen die Regel und ohne dass jemand das neue Gerät hat, kann man noch wenig schreiben.
Gruß, Christian

Hallo zusammen,
hier schreibt der Deutsche Danalock Vertrieb.

-> A.Harrenberg
Wohin gingen die Anfragen? Wir haben leider nichts erhalten.

->FHEM Integration
Hat die Z-Wave Dokumentation die wir ElmarK geschickt haben weitergeholfen? Können wir hier noch unterstützen?

-> Verwirrung V125 & V2
V125 ist die V2. Hintergrund ist ganz einfach. Das Produkt wurde Intern erstmal V125 genannt. Die Kommunikation in Deutschland wurde damit gestartet. Danach hat Poly Control sich umentschieden und zum internationalen Release V2 genannt.

Für weitere Fragen stehen wir gerne zur Verfügung.
0951 30900710 oder info@smartlock.de

Viele Grüße
Danalock Deutschland

Zitat von: krikan am 30 November 2015, 13:53:15
Ich kaufe persönlich keine ZWave-, sondern nur -wenn irgendmöglich- ZWave+-Geräte. Unterschiede (u.a. bessere Reichweite usw.) müsstest Du bitte im Wiki bzw. den Links nachlesen. Normalerweise fällt man mit den neueren ZWave+ Geräten nicht auf die Nase. Aber Ausnahmen (http://forum.fhem.de/index.php/topic,40771.0.html) bestätigen die Regel und ohne dass jemand das neue Gerät hat, kann man noch wenig schreiben.
Gruß, Christian

Diese frisch eingetroffenen Danalock´s (Z-Wave ohne Zylinder) haben schon den Z-Wave+ Chip:
http://www.amazon.de/gp/product/B018QTTMS2/ref=noref?ie=UTF8&psc=1&s=ce-de

Viele Grüße
Danalock Deutschland

Hallo DanalockDE,

Zitat von: DanalockDE am 30 November 2015, 21:42:31
Hallo zusammen,
hier schreibt der Deutsche Danalock Vertrieb.

oh hallo, herzlich Willkommen!

Zitat von: DanalockDE am 30 November 2015, 21:42:31
-> A.Harrenberg
Wohin gingen die Anfragen? Wir haben leider nichts erhalten.

->FHEM Integration
Hat die Z-Wave Dokumentation die wir ElmarK geschickt haben weitergeholfen? Können wir hier noch unterstützen?

Ich hatte zuerst Kontakt mit Poly Control, jetzt mit SoulAr, weitere Details kommen per PN bzw. an die info@smartlock.de.
(Allerdings erst morgen...)

Zitat von: DanalockDE am 30 November 2015, 21:42:31
-> Verwirrung V125 & V2
V125 ist die V2. Hintergrund ist ganz einfach. Das Produkt wurde Intern erstmal V125 genannt. Die Kommunikation in Deutschland wurde damit gestartet. Danach hat Poly Control sich umentschieden und zum internationalen Release V2 genannt.

Ah, habe ich also was falsches erzählt... ;-(

Gruß,
Andreas.

Hallo DanalockDE,

Kontakt wurde jetzt hergestellt, ein Testgerät wird vorübergehend gestellt werden. Danke!

Gruß,
Andreas.

Hi,

wollte mich nur mal kurz melden...

Schloß und Zylinder wurden mir vom Distributor zur Verfügung gestellt und stehen jetzt als Testaufbau neben mir auf dem Schreibtisch. Einbindung mit Security in FHEM/ZWave hat recht gut funktioniert, reines Öffnen/Schließen funktioniert jetzt schon mal ,-)

Allerdings fängt der "Kleinkram" jetzt erst an, da ist noch eine Menge auszuprobieren. Die Konfiguration von "DOOR_LOCK" wird z.B. nicht über die in der DOOR_LOCK-Klasse verfügbaren Konfigurationsbefehle gemacht, sondern über "normale" Konfig-Register. Dies ist anscheinend ein Kompromiss wegen der gleichzeitigen Nutzung von Bluetooth.

Hier habe ich noch nicht so viel probiert, es gibt aber ein paar Ungereimtheiten in den Anleitungen. ZWave sagt z.B. bei einer Einstellung 0-60 sekunden, Bluetooth geht bis 3 Minuten... Da muss ich ein paar Gegentests mit beiden Systemen machen.

Außerdem zieht das jetzt einen kleinen Ratenschwanz nach sich, da auch noch weitere Befehlsklassen (TIME und TIME_PARAMETER) implementiert werden müssen, welche aktuell noch nicht in FHEM drin sind, aber für die Zeitsteuerung des Schlosses benötigt werden...

Es gibt also noch eine Menge zu tun, die Grundfunktion tut es aber schon mal ,-)

Gruß,
Andreas.

Cool das du dich um die Sache kümmerst.
Ich bekomme das mit dem Security irgendwie nicht hin.
Beim ZWDongle steht "Initialized".
Als attr hab ich einen Networkkey gesetzt.
Beim ZWave_ENTRY_CONTROL_4 steht "INITIALIZING (starting secure inclusion)"
Hatte vorher aber das Schloß ohne Security inkludiert, muß ich es vorher entfernen oder so?

Hi Bigsonic1!

Zitat von: Bigsonic1 am 17 Dezember 2015, 19:06:13
Ich bekomme das mit dem Security irgendwie nicht hin.
Beim ZWDongle steht "Initialized".
Als attr hab ich einen Networkkey gesetzt.
Beim ZWave_ENTRY_CONTROL_4 steht "INITIALIZING (starting secure inclusion)"
Hatte vorher aber das Schloß ohne Security inkludiert, muß ich es vorher entfernen oder so?

ja, leider "hakt" das noch an ein paar Stellen...

Mal der Reihe nach:
ZWDongle "initialized" hat in dem Zusammenhang wenig zu sagen, der Dongle sollte immer auf initialized stehen, der Status ändert sich z.B. wenn Du ihn rausziehst ,-)

Networkkey muss gesetzt sein und Crypt::Rijndael muss installiert sein -> http://forum.fhem.de/index.php/topic,38587.msg307798.html#msg307798 (http://forum.fhem.de/index.php/topic,38587.msg307798.html#msg307798)

Die Meldung beim Schloss "INITIALIZING (starting secure inclusion)" zeigt das die  Einbindung hängen geblieben ist. Das passiert leider momentan noch recht häufig, da noch keine echte Ablaufsteuerung implementiert ist. Zum testen habe ich mir da momentan erst mal ein paar kleine Hacks eingebaut die das anscheinend recht gut abfangen, ist aber nicht im offiziellen Code und sollte es in der Form dort auch nicht geben.

Also eine nachträgliche Einbindung mit Sekurity geht nicht, dazu muss das Schloss excludiert werden und mit "sec on" inkludiert werden. Die Meldung von Deinem Schloss kannst Du aber nur bekommen haben wenn es vorher nicht inkludiert war und Du es so probiert hast. Wenn die secure-inclusion fehlschlägt bleibt der normale Funktionsumfang bestehen, was bei dem Schloss aber nicht viel ist...

Ich würde Dir raten noch ein wenig Geduld zu haben. Ich würde gerne erst mal die noch nötigen Befehlsklassen implementieren und mich danach dann um Probleme mit dem Ablauf der Kommunikation kümmern.

Im jetzigen Zustand kann ich das Schloss zwar Auf- und Zu machen, viel mehr geht aber noch nicht...

Gruß,
Andreas.

Crypt::Rijndael hab ich installiert.
Wie exkludiere ich denn das Schloß?
Den zwave Stick bring ich in dem exklusions Modus, aber wie bring ich das Schloß dazu?

Hi,

das sollte entweder über die Bluetooth-App gehen oder ich meine gelesen zu haben das Sensorfeld festhalten bis es drei mal gepiept hat.

Gruß,
Andreas.

Danke, es muß zweimal piepen.
Dachte über die App kann ich nur die Inklusion anstoßen, geht aber auch zur exklusion.

Hi,

hat es denn diesmal geklappt oder ist das wieder bei "INITIALIZING (starting secure inclusion)" hängen geblieben?

Gruß,
Andreas.

Bleibt noch leider jedesmal dabei hängen...

Hallo,
hab es jetzt geschafft mit der neusten Version von 10_ZWave.pm das Schloss mit Security einzubinden.
Mit welchem Befehl fahre ich denn jetzt das Schloss auf und zu?  :)

Hi Bigsonic,

die ganzen neuen Befehle sind noch nicht offiziell verfügbar, ich bin zwar schon recht weit mit den einzelnen Befehlsklassen, aber der Doku-Block für die Commandref muss dann auch noch gemacht werden. Daher wird das offiziell erst im Januar was...

Wenn Du unbedingt damit spielen möchtest müsstest Du die 10_ZWave.pm editieren und am Anfang (ca. Zeile 235) den Eintrag für DOOR_LOCK finden und entsprechend um die zwei set-Befehle ergänzen. Die beiden Befehle sind ja nicht besonders schwierig ,-)

  DOOR_LOCK                => { id => '62',
    set   => { doorClose              => '01ff',
               doorOpen               => '0100' },
    get   => { doorLockOperation => '02',
               doorLockConfiguration => '05'},
    parse => { "..6203(.*)" => 'ZWave_DoorLockOperationReport($hash, $1)',
               "..6206(.*)" => 'ZWave_DoorLockConfigReport($hash, $1)'} },

Danach musst Du entweder FHEM neu starten oder "reload 10_ZWave.pm" in der Kommandozeile eingeben und solltest dann mit doorClose/doorOpen das Schloss schließen können.

Die beiden bereits implementierten Befehle für doorLockOperation und doorLockConfiguration erzeugen in der aktuellen Version noch einen falschen Report, da habe ich damals mangels Informationen einiges nicht richtig umgesetzt, also nicht weiter beachten.

Wie gesagt kommt das und ein paar andere neue Befehlsklassen dann Anfang Januar in die offizielle Release. Damit wäre das Schloss dann unterstützt, allerdings muss ich mich noch etwas um SECURITY kümmern, da hakt es leider noch immer wieder am Ablauf. Mich wundert ehrlich gesagt das Du es geschafft hast das Schloss unter SECURITY einzubinden...

Gruß,
Andreas.

Danke hat geklappt, jetzt kann ich eine hoffentlich zuverlässigere Autounlock funktion mit Geofancy und Presence nutzen, als die Originale.

Warum es jetzt geklappt hat, mit Security kann ich nicht sagen. Hab die 10_ZWave.pm von hier: http://sourceforge.net/p/fhem/code/HEAD/tree/trunk/fhem/FHEM/ (http://sourceforge.net/p/fhem/code/HEAD/tree/trunk/fhem/FHEM/)

Hi,

das sollte aber die ganz "normale" offizielle 10_ZWave.pm sein die Du auch per Update bekommst.

Eine Merkwürdigkeit hat das Schloss allerdings, wenn man z.B. im abgeschlossenen Zustand ein DoorOpen sendet und dann ein DoorClose hinterschickt bevor das Schloss KOMPLETT offen ist, dann wird das DoorClose ignoriert! Andersherum ist das genauso.

Hier muss man also ggf. den Status abfragen bevor man da einen Befehl schickt.

Gruß,
Andreas.

Hallo,

so, ab morgen unterstützt FHEM die nötigen Befehle für alle Befehlsklassen des DanaLock in der offiziellen Version. Bitte einen Blick in die Commandref werfen...

Ein paar Bemerkungen:
- nicht alle Parameter für die Befehle sind vollständig bekannt, viele sind vom Namen her deutbar, andere teilweise eher nicht...
  - Für den Betrieb des DanaLock mit FHEM benötigt man momentan aber eigentlich auch nur "open" und "close" ,-)
- Das DanaLock meldet das "model" nicht vernünftig, aktuell wird daher nur das model erkannt, aber keine weiteren Informationen aus dem XML ausgelesen. Das schaue ich mir als nächstes an.
- Allgemein hakt die Einbindung und der Ablauf aller Geräte unter SECURITY noch, auch das steht auf meiner ToDo-Liste
- Für ~März ist ein Bluetooth Keypad und ein kleiner Fernbedienungssender für das DanaLock angekündigt, dann kann/muss man sich mit weiteren Befehlen beschäftigen (alle bereits implementiert, mangels Keypad aber nur prinzipiell getestet)

Gruß,
Andreas.

Hi,

so, noch ein kleiner Nachtrag...

Mir ist eben aufgefallen das Ich eine Befehlsklasse "vergessen" habe...

Die implementiere ich dann bei Gelegenheit mal, die ist aber von Sigma (dem Lizenzgeber von ZWave) sowieso zurückgezogen und wird von dem Danalock nur aus Gründen der Rückwärtskompatibilität (eingeschränkt) unterstützt.

Gruß,
Andreas.

Vielen Dank für die Implementierung!
Gibt es noch einen Befehl um den Schnapper zurückzuziehen?

Hi,

Zitat von: Bigsonic1 am 06 Januar 2016, 16:34:50
Vielen Dank für die Implementierung!
Gibt es noch einen Befehl um den Schnapper zurückzuziehen?

muss ich mal schauen, bei mir macht das Schloss das immer, einen separaten Befehl dafür gibt es eigentlich nicht. Allerdings habe ich das Schloss per Bluetooth angelernt und dort "gesagt" das meine Tür keine Klinke hat...

Daher habe ich da jetzt gar nicht drauf geachtet. Ich muss das Ding dann noch mal an FHEM anlernen und schauen ob sich ein Konfigurationsregister ändert wenn ich das per Bluetooth umstelle.

Gruß,
Andreas.

Hab es bei mir auch per App eingestellt, aber würde das Schloss gerne zwischen einer bestimmten Zeit aufgeschlossen haben.
Also nur den Befehl aufschliessen senden, ohne schnapper zurückziehen.

Hi,

Zitat von: Bigsonic1 am 06 Januar 2016, 18:53:31
Hab es bei mir auch per App eingestellt, aber würde das Schloss gerne zwischen einer bestimmten Zeit aufgeschlossen haben.
Also nur den Befehl aufschliessen senden, ohne schnapper zurückziehen.

wie gesagt, dafür gibt es keinen extra Befehl.

Die App ändert die Konfiguratin von "Brake&GoBack" (Config 10) bei mir von
3 = Schloss öffnet Schnapper und fährt dann (nach drei sekunden) zurück in
0 = Schloss fährt (fast) ganz auf, sodaß der Schnapper fast vollständig geöffnet ist. Sicherlich auch nicht das was Du willst...

Gruß,
Andreas.

Ja da hat sich ja einiges getan. Ich glaube ich befasse mich mit dem Thema dann die kommenden Tage doch mal wieder. Schön das es auch mit Danalock geklappt hat und sich der Vertrieb gemeldet hat.

LG, ElmarK

Hallo Zusammen,
hab es hinbekommen. Es ist eingebunden. Allerdings komisches Verhalten. Sogar bei get Befehlen öffnet oder schliesst es sich :-)

LG, Elmar

P.S. Andreas, danke für deine Mühen :-)

Hallo Elmar

Zitat von: ElmarK am 10 Januar 2016, 17:01:59
Hallo Zusammen,
hab es hinbekommen. Es ist eingebunden. Allerdings komisches Verhalten. Sogar bei get Befehlen öffnet oder schliesst es sich :-)

WIE BITTE????

Bitte mal ein Logfile (mit diesen Infos) (http://www.fhemwiki.de/wiki/Z-Wave#Welche_Infos_sollten_Anfragen_im_ZWave-Forum_enthalten.3F) erstellen und posten und dazu schreiben was das Schloss gemacht hat.

Ich vermute das bei Dir ein paar "alte" SECURITY Befehle im security-stack liegen geblieben sind. Die werden dann "anstelle" von den neuen Befehlen versendet, wodurch diese neuen Befehle auf dem Stack liegen bleiben und zu "alten" Befehlen werden... Damit wird das Verhalten von FHEM "aysnchron" zu dem was Du tust...

Wenn Du ein List vom Device machst kannst Du den Eintrag für den security stack sehen. Wenn da noch Einträge drin sind hilft momentan erst mal nur FHEM neu zu starten um die abzuarbeiten.

Das Problem mir ist bekannt und steht auf meiner ToDo-Liste, ist aber nicht soo einfach zu lösen...

Gruß,
Andreas.

Hallo Andreas,
bekommst Du heute Abend.

LG, Elmar

Hi,

Zitat von: ElmarK am 12 Januar 2016, 12:02:34
bekommst Du heute Abend.

danke schon mal, werde aber frühestens am Donnerstag dazu kommen da detailierter reinzuschauen, ich gehe aber wie gesagt aus das da noch alte Befehle auf dem Stack liegen.
Hast Du FHEM in der Zwischenzeit neu gestartet? Dann wären diese Befehle weg und das Verhalten müsste "normal" sein.

Gruß,
Andreas.

Hallo Andreas,
du hast recht. Jetzt nach Neustart und Update funktioniert alles einwandfrei.

Dankeschön !

Hi Rudi,
anbei ein Patch für "get model" damit das auch beim Danalock funktioniert.

Das Ding sendet leider 2 Byte zu viel und ich hatte Dein System mit den drei Zeilen in zwave_class missverstanden und nur eine Zeile für das Danalock angelegt, da ich dummerweise der Meinung war das (.{4}) wurde bedeuten das das GLEICHE Zeichen dann 4 mal vorkommen muss...
Tja, RegExp sind schon eine WIssenschaft für sich.

(Aber die drei Zeilen sind auch schon ein kleiner "Hack"...) ;-)

Gruß,
Andreas.

Sodala, alles funktioniert einwandfrei. Schloss schliesst zu bestimmten Zeiten automatisch.
Ein automatisches Aufschließen zu definierten Zeiten wäre jetzt noch toll. Das hab ich
derzeit noch nicht eingerichtet, da sich die Tür dann gleich wg. Schnapper vollständig öffnet :-)

Hat da schon jemand einen Workaround ?

LG, Elmar

Hi Elmar,

nein leider nicht. Wie geschrieben ist in der Spezifikation der Befehle soetwas nicht vorgesehen und das Schloss scheint die Definition des Drehwinkels zu ignorieren. Mein erster Ansatz dazu war nämlich den Winkel umzudefinieren und damit zu bestimmen wie weit das Schloss öffnet. Ich werde mich noch mal mit der technischen Abteilung in Verbindung setzen.

Gruß,
Andreas.

Hi Andreas,
wollte mal vorsichtig nachfragen, obs schon was Neues gibt.

LG, Elmar

Hi Elmar,

Zitat von: ElmarK am 10 Februar 2016, 15:29:51
wollte mal vorsichtig nachfragen, obs schon was Neues gibt.

nein, leider noch nichts wirkliches. Bisher habe ich nur eine Anwort aus Deutschland die besagt das es gehen "müsste", von der "Technik" aus Dänemark habe ich bisher nichts gehört.

Ich werde noch mal nachfragen.

Gruß,
Andreas.

Merci :-)

LG

Hallo,

das beschriebene Verhalten von Elmar von 10 Januar tritt immer ab und zu auf. In der Release r10869 sind die Änderungen vom Andreas von 28.02 nicht drin.
Hat es vielleicht damit zu tun?

Ein get doorLockOperation hat heute dazu geführt, dass der Lock sich verschlossen hat!
Mehr Info im Log:

2016.02.18 11:22:17 2: ZWave get Door_Lock doorLockOperation 2016.02.18 11:22:24 3: XBMC_CheckConnection: Connection lost! Last data from Kodi received 120 s ago 2016.02.18 11:22:24 1: 192.168.178.12:8080 disconnected, waiting to reappear (Kodi) 2016.02.18 11:22:24 1: 192.168.178.12:8080 reappeared (Kodi) 2016.02.18 11:22:30 3: Door_Lock: secStart older than 6 seconds detected, secUnlock will call Zwave_secEnd 2016.02.18 11:22:42 3: Door_Lock: secStart older than 6 seconds detected, secUnlock will call Zwave_secEnd Loading device description failed with error: 500 Server closed connection without sending any data back at ./FHEM/00_SONOS.pm line 3757 thread 1. Loading device description failed with error: 500 Server closed connection without sending any data back at ./FHEM/00_SONOS.pm line 3757 thread 1. 2016.02.18 11:23:25 2: ZWave set Door_Lock doorLockOperation 00 Loading device description failed with error: 500 Server closed connection without sending any data back at ./FHEM/00_SONOS.pm line 3757 thread 1. Loading device description failed with error: 500 Server closed connection without sending any data back at ./FHEM/00_SONOS.pm line 3757 thread 1. 2016.02.18 11:24:04 3: SONOS0: Connection accepted from localhost:48120 2016.02.18 11:24:24 3: XBMC_CheckConnection: Connection lost! Last data from Kodi received 120 s ago 2016.02.18 11:24:24 1: 192.168.178.12:8080 disconnected, waiting to reappear (Kodi) 2016.02.18 11:24:24 1: 192.168.178.12:8080 reappeared (Kodi) 2016.02.18 11:25:40 2: ZWave get Door_Lock doorLockOperation 2016.02.18 11:25:42 1: Door_Lock: Error, no send_nonce to decrypt message available 2016.02.18 11:25:43 1: Door_Lock: Error, no send_nonce to decrypt message available 2016.02.18 11:26:04 3: SONOS0: Connection accepted from localhost:48123 2016.02.18 11:26:24 3: XBMC_CheckConnection: Connection lost! Last data from Kodi received 120 s ago 2016.02.18 11:26:24 1: 192.168.178.12:8080 disconnected, waiting to reappear (Kodi) 2016.02.18 11:26:24 1: 192.168.178.12:8080 reappeared (Kodi) 2016.02.18 11:28:04 3: SONOS0: Connection accepted from localhost:48126

Gruß

Hi,

welche Änderungen meinst Du denn? 28.2 haben wir ja noch nicht ganz... :-)

Bei Dir im System scheint es immer wieder mal Probleme mit Kodi/XBMC oder Sonos zu geben. Kann es sein das diese Module dann FHEM blockieren?

Die Kommunikation mit SECURITY ist leider nicht so wirklich gegen solche Sachen abgesichert. Sobald da eine Nachricht verlorengeht kann die ganze Kommunikation durcheinander geraten. Das führt dann dazu das der letzte Befehl auf dem Stack liegenbleibt und ausgeführt wird sobald der nächste Befehl ausgelöst wird. Dann bleibt allerdings dieser Befehl "übrig" und liegt dann auf dem Stack...

Das ganze kannst Du sehen wenn Du mal ein "list Door_Lock" machst. Da gibt es dann secMsg Einträge. Normalerweise sollte da nur ein Befehl während der Kommunikation gespeichert werden und danach gelöscht werden. Kommt es aber zu Störungen bleibt der da momentan noch liegen...

Ich habe leider momentan SEHR wenig Zeit mich darum zu kümmern, außerdem habe ich da auch noch keinen richtig guten Ansatz wie man das Problem in den Griff bekommen kann. Ich hoffe das ich da ab nächster Woche nach schauen kann.

Gruß,
Andreas.

Hallo Andreas,

danke fürs Feedback.

ZitatBei Dir im System scheint es immer wieder mal Probleme mit Kodi/XBMC oder Sonos zu geben. Kann es sein das diese Module dann FHEM blockieren?

Glaube ich nicht, da alle anderen Z-wave Komponente problemlos funktionieren und zwar sehr reaktiv.

ZitatDas ganze kannst Du sehen wenn Du mal ein "list Door_Lock" machst. Da gibt es dann secMsg Einträge. Normalerweise sollte da nur ein Befehl während der Kommunikation gespeichert werden und danach gelöscht werden. Kommt es aber zu Störungen bleibt der da momentan noch liegen...

Ich habe das mehrmals probiert. Bei mir war der secMsg niemals lehr. Immer enthält er den letzten Kommando, der zuletzt ausgeführt wurde. Mehrmals muss man den Kommando 2 mal verschicken damit er tatsächlich ausgeführt wird.

anbei mein "List Door_Lock"

Internals:
   DEF        c9315585 44
   IODev      ZWAVE1
   LASTInputDev ZWAVE1
   MSGCNT     7
   NAME       Door_Lock
   NR         67
   STATE      locked
   TYPE       ZWave
   ZWAVE1_MSGCNT 7
   ZWAVE1_RAWMSG 0004002c179881cfb91cf2f841f66e5540d34ffd8f03068d08a8f4dd
   ZWAVE1_TIME 2016-02-25 13:44:31
   homeId     c9315585
   isWakeUp
   lastMsgSent 1456404270.84715
   nodeIdHex  2c
   secTime    1456404270.8444
   Readings:
     2016-02-07 09:11:11   SECURITY        ENABLED
     2016-02-18 11:22:23   SEND_DATA       failed:00
     2016-02-25 11:23:59   UNPARSED        PROPRIETARY 0a88803dd90e24bbc4838f
     2016-02-25 13:44:31   battery         100 %
     2016-02-09 11:53:47   configBatteryAlarmPercent 30
     2016-02-09 11:53:55   configBatteryType 1
     2016-02-09 11:54:01   configInvertLockDirection 1
     2016-02-09 11:54:01   configLockMode  1
     2016-02-09 11:54:02   configLockNormalCloseTime 0
     2016-02-09 11:54:02   configLockSound 1
     2016-02-09 11:54:34   configLockSpeed 5
     2016-02-09 11:55:05   configLockTurnDegrees 96
     2016-02-09 11:56:00   date            0000-00-00
     2016-02-24 21:35:35   doorLockOperation mode: secured outsideHandles: 1111 insideHandles: 1111 door: closed bolt: unlocked latch: closed timeoutSeconds: not_supported
     2016-02-07 09:11:14   model           Polycontrol Danalock Circle/Square
     2016-02-07 09:11:14   modelConfig     polycontrol/doorlock.xml
     2016-02-07 09:11:14   modelId         010e-0003-0002
     2016-02-22 15:51:41   state           doorLockOperation 00
     2016-02-25 11:23:26   time            00:00:00 RTC: working
     2016-02-25 13:44:31   transmit        OK
     2016-02-10 19:22:11   userCode        id 1 status 0 code 00000000000000000000
     2016-02-10 19:24:16   userCodeUsersNumber 20
   secMsg:
     8002 get Door_Lock battery
Attributes:
   IODev      ZWAVE1
   classes    MANUFACTURER_SPECIFIC BATTERY VERSION SECURITY DOOR_LOCK USER_CODE SCHEDULE_ENTRY_LOCK CONFIGURATION TIME MARK BASIC
   devStateIcon unlocked:secur_open locked:secur_locked
   eventMap   /doorLockOperation FF:lock/doorLockOperation 00:unlock
   group      Lock
   icon       status_locked
   room       ZWave
   secure_classes DOOR_LOCK USER_CODE SCHEDULE_ENTRY_LOCK CONFIGURATION TIME MANUFACTURER_SPECIFIC BATTERY VERSION MARK
   stateFormat {if(ReadingsVal("Door_Lock","doorLockOperation","papa")=~ /unsecured/) {sprintf("unlocked");}else{sprintf("locked");}}
   webCmd     lock:unlock

Hi,

Zitat von: Nexus1211 am 25 Februar 2016, 13:51:41
Ich habe das mehrmals probiert. Bei mir war der secMsg niemals lehr. Immer enthält er den letzten Kommando, der zuletzt ausgeführt wurde. Mehrmals muss man den Kommando 2 mal verschicken damit er tatsächlich ausgeführt wird.

wie gesagt, da bleiben die übriggebliebenen Befehle "liegen" wenn in der Kommunikation mal was nicht passt. Dagegen hilft momentan nur ein Neustart von FHEM, dann ist der Stack wieder leer.

Das Du das 2 mal verschicken musst ist auch klar, ich hatte ja erklärt das dann bei jedem neuen Befehl der älteste Befehl auf dem Stack ausgeführt wird und der aktuelle auf den Stack gelegt wird...

Zitat von: Nexus1211 am 25 Februar 2016, 13:51:41
anbei mein "List Door_Lock"

Code Auswählen Erweitern


   secMsg:
     8002 get Door_Lock battery


EGAL welchen (SECURITY-) Befehl Du danach ausführst, es wird erstmal der gespeicherte "get Door_Lock battery" ausgeführt und der aktuelle landet dann an dieser Stelle.

Wie gesagt kann ich momentan nichts daran machen das mir aktuell dazu gerade die nötige Zeit fehlt. Vielleicht geht das nächste Woche...

Gruß,
Andreas.

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.  ;D

Hi,

Zitat von: Bigsonic1 am 20 März 2016, 19:06:50
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.  ;D

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.

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.

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

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.

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

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

Hi,

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

Gruß,
Andreas.

Geht leider immer noch nicht, hab es mit einem anderen fhem-server versucht, mit dem gleichen zwave stick, aber das selbe Spiel:
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 (http://www.z-wave.me/index.php?id=14) ist schon von Version 5 die rede...

Zitat von: Bigsonic1 am 05 April 2016, 11:55:29
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

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:

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

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:

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

Hi,

Zitat von: decaflo am 08 April 2016, 14:29:00
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.

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:

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

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

passiert nichts. Hier das Log nach
set danalock doorLockOperation 00

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

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:
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:
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":
   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.

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 ;)

Zitat von: A.Harrenberg am 05 Mai 2016, 10:42:03
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?

Zitat
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:


...
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

Hi Florian,

Zitat von: decaflo am 06 Mai 2016, 03:37:11
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...

Zitat von: decaflo am 06 Mai 2016, 03:37:11
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.

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

38401:raw:0:/dev/ttyAMA0:115200 8DATABITS NONE 1STOPBIT
statt
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!

Was ist der Grund fuer 38401 statt 38400 ?

38400 ist belegt, da hängt noch ein CUL:

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

Hallo zusammen,

nach längerem hin und her hab ich es endlich mechanisch hinbekommen ein Danalock V125 Zwave in Betrieb zu nehmen. An der zweiten Hürde das Ganze in mein FHEM zu integrieren scheitere ich im Moment noch ein wenig. Ich habe nun schon einiges dazu im Forum gelesen und hänge mich deshalb jetzt einfach mal an diesen Beitrag an.

Mein aktueller Status sieht wie folgt aus:

- das Danalock ist "secure" in FHEM inkludiert
- anfänglich war auch eine Kommunikation möglich
- nun bekomme ich aber immer häufiger Timeouts wie z.B. folgende:


2017.02.25 13:43:25 3: ZWave get fl_danalock doorLockOperation
2017.02.25 13:43:29 2: ZDongle transmit NO_ACK for CB 09, target fl_danalock
2017.02.25 13:43:30 2: ZWave: No ACK from fl_danalock after 5s for sentset:130e0298402509
2017.02.25 13:43:30 1: fl_danalock: NO_ACK received during secured command: 6202 get fl_danalock doorLockOperation, command will be removed from security stack
2017.02.25 13:48:33 3: ZWave get fl_danalock battery
2017.02.25 13:48:37 2: ZDongle transmit NO_ACK for CB 0a, target fl_danalock
2017.02.25 13:48:38 2: ZWave: No ACK from fl_danalock after 5s for sentget:130e028002250a



2017-02-25_13:43:29 fl_danalock transmit: NO_ACK
2017-02-25_13:48:37 fl_danalock transmit: NO_ACK


Das Danalock habe ich temporär von der Tür entfernt und vor mir auf dem Schreibtisch, zur besseren Fehleranalyse, liegen. Das sind etwa 2-3 Meter bis zum ZWave Controller. Seit dem letzten FHEM restart bleibt nun auch nichts mehr auf dem Sendstack liegen was zurvor durchaus der Fall war. Dafür bekomme ich nun die Hinweisbox mit dem Timeout. Hat jemand eine Idee woran das liegen könnte?


Internals:
   DEF        cdf6772a 14
   IODev      ZDongle
   LASTInputDev ZDongle
   MSGCNT     5
   NAME       fl_danalock
   NR         116
   STATE      neighborUpdate
   TYPE       ZWave
   ZDongle_MSGCNT 5
   ZDongle_RAWMSG 00130a01015a
   ZDongle_TIME 2017-02-25 13:48:37
   ZWaveSubDevice no
   homeId     cdf6772a
   isWakeUp
   lastMsgSent 1488026913.8323
   nodeIdHex  0e
   secTime    1488026605.6062
   Readings:
     2017-02-25 08:48:23   SECURITY        ENABLED
     2017-02-25 12:02:50   SEND_DATA       failed:00
     2017-02-25 12:14:18   UNPARSED        TIME 028a06
     2017-02-25 12:01:44   assocGroup_1    Max 1 Nodes ZDongle
     2017-02-25 12:01:43   assocGroups     1
     2017-02-25 12:13:08   battery         97 %
     2017-02-25 12:02:52   configBrakeGoBack 1
     2017-02-25 12:02:52   configDoorLockOperationReportType 0
     2017-02-25 12:02:52   configLockAutoLatchTime 0
     2017-02-25 12:02:53   configLockDirection 1
     2017-02-25 12:02:53   configLockMode  1
     2017-02-25 12:02:53   configLockSound 1
     2017-02-25 12:02:53   configLockSpeed 5
     2017-02-25 12:12:38   doorLockOperation mode: secured outsideHandles: 0001 insideHandles: 0001 door: closed bolt: locked latch: closed timeoutSeconds: not_supported
     2017-02-25 08:48:28   model           Polycontrol Danalock Circle V2 BTZE
     2017-02-25 08:48:28   modelConfig     polycontrol/doorlockV2BTZE.xml
     2017-02-25 08:48:28   modelId         010e-0008-0002
     2017-02-25 12:24:11   neighborList    ZDongle
     2017-02-25 12:27:18   neighborUpdate  failed
     2017-02-25 12:26:57   state           neighborUpdate
     2017-02-25 12:24:20   timeToAck       0.037
     2017-02-25 13:48:37   transmit        NO_ACK
     2017-02-25 12:11:06   zwavePlusInfo   version:01 role:SleepingListeningSlave node:Z-Wave+Node installerIcon:0300 userIcon:0300
   secMsg:
Attributes:
   IODev      ZDongle
   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 ZWAVEPLUS_INFO:2
   verbose    5


Grüße
Andreas

Ich gehe davon aus, dass man fuer die bessere Beurteilung des Problems ein Log mit "attr global mseclog" und "attr ZWDongle verbose 5" beoetigt.

Hi,

woher der NO_ACK kommt ist schwer zu sagen, normalerweise dürfte der nur durch Übertragungsprobleme verlorengehen. Ein blockierendes Modul in FHEM könnte sowas auch noch verursachen, halte ich an der Stelle aber für nicht wahrscheinlich.

Insgesamt ist die Kommunikation per SECURITY leider noch nicht wirklich stabil, vor allem in Bezug auf WAKE_UP. Das Danalock arbeitet ja mit FLIRS, sodass hier nicht ganz so viele Probleme auftauchen sollten.

Falls bei Dir Nachrichten auf dem sec_stack liegen geblieben sind ist das ein Zeichen dafür das während eine Kommunikation eine Störung aufgetreten ist und der Befehl nicht zu Ende durchgeführt wurde. Der Momentane Ablauf lässt dann leider die alte Nachricht noch auf dem Stack liegen...

Ich bin gerade dabei die Abläufe zu analysieren und versuche das Handling der security-Nachrichten mit in den normalen SendStack zu integrieren und die möglichen Fehlerfälle bei der Kommunikation im Ablauf zu berücksichtigen.

Wegen der Probleme mit den liegengebliebenen Nachrichten und den damit verbundenen Problemen kann ich derzeit nicht wirklich empfehlen das Danalock zu nutzen...

Gruß,
Andreas.

Hi,

ich weiß jetzt nicht woran es lag, aber nach dem Tauschen einer Batterie ging die Kommunikation aus kurzer Entfernung problemlos. Ob es jetzt an der getauschten Batterie oder dem Reset des Schlosses lag kann ich nicht genau sagen. Bis zur Haustür scheint es aber trotzdem nicht auszureichen. Bin da doch etwas von der ZWave+ Reichweite enttäuscht. Da liegen eine Stahlbetondecke und maximal 10m dazwischen. Ist das normal oder liegt das auch an schwachen Batterien? Ich habe mir auf jeden Fall einen Satz neue bestellt. Ansonsten habe ich auch noch einen Fibaro Switch zur Reichweitenverlängerung zur Verfügung.

Kann es sein das der Batteriestatus nicht wirklich aussagekräftig ist? Ich hatte mit einem Fibaro Motion Sensor ebenfalls Probleme welche wohl auch an einer schwachen Batterie lagen obwohl die laut Sensor fast voll war.

Zitat
woher der NO_ACK kommt ist schwer zu sagen, normalerweise dürfte der nur durch Übertragungsprobleme verloren gehen. Ein blockierendes Modul in FHEM könnte sowas auch noch verursachen, halte ich an der Stelle aber für nicht wahrscheinlich.

Ein blockierendes Modul (GCM) habe ich zwischenzeitlich auch entfernt.

Zitat
Falls bei Dir Nachrichten auf dem sec_stack liegen geblieben sind ist das ein Zeichen dafür das während eine Kommunikation eine Störung aufgetreten ist und der Befehl nicht zu Ende durchgeführt wurde. Der Momentane Ablauf lässt dann leider die alte Nachricht noch auf dem Stack liegen...

Ich bin gerade dabei die Abläufe zu analysieren und versuche das Handling der security-Nachrichten mit in den normalen SendStack zu integrieren und die möglichen Fehlerfälle bei der Kommunikation im Ablauf zu berücksichtigen.

@Andreas: d.h. an der Problematik mit liegen gebliebenen Meldungen bist du noch dran. Seit Sommer letzten Jahres gab es dazu ja glaube ich keine Beiträge mehr ...

Grüße
Andreas

Hi,

Zitat von: acw81 am 28 Februar 2017, 10:07:44
ich weiß jetzt nicht woran es lag, aber nach dem Tauschen einer Batterie ging die Kommunikation aus kurzer Entfernung problemlos. Ob es jetzt an der getauschten Batterie oder dem Reset des Schlosses lag kann ich nicht genau sagen. Bis zur Haustür scheint es aber trotzdem nicht auszureichen. Bin da doch etwas von der ZWave+ Reichweite enttäuscht. Da liegen eine Stahlbetondecke und maximal 10m dazwischen. Ist das normal oder liegt das auch an schwachen Batterien? Ich habe mir auf jeden Fall einen Satz neue bestellt. Ansonsten habe ich auch noch einen Fibaro Switch zur Reichweitenverlängerung zur Verfügung.

Stahlbetondecke ist schon mal eine 1a Abschirmung... Je nach ausrichtung der Antenne(n) kann das schon zu viel sein. Ich würde auf jeden Fall mal die Steckdose in die Mitte bringen und ein Neighborlistupdate machen.

Zitat von: acw81 am 28 Februar 2017, 10:07:44
Kann es sein das der Batteriestatus nicht wirklich aussagekräftig ist? Ich hatte mit einem Fibaro Motion Sensor ebenfalls Probleme welche wohl auch an einer schwachen Batterie lagen obwohl die laut Sensor fast voll war.

Einen Batteriestatus anhand der Spannung zu generieren ist wohl nicht soo einfach. Die meisten Geräte die ich hier so habe sagen meist 100%, dann einen Tag lang 40% und danach sind sie tot...

Zitat von: acw81 am 28 Februar 2017, 10:07:44
@Andreas: d.h. an der Problematik mit liegen gebliebenen Meldungen bist du noch dran. Seit Sommer letzten Jahres gab es dazu ja glaube ich keine Beiträge mehr ...

Ja, leider bin ich da lange Zeit nicht zu gekommen. Als ich dann dazu gekommen bin habe ich gleich mehrere weitere Probleme entdeckt und beschlossen zu versuchen das jetzt in den normalen Ablauf zu integrieren und den Stackablauf entsprechend zu erweitern.
Der momentane Zustand ist, der alte Stack läuft nicht mehr und der neue läuft noch nicht...

Gruß,
Andreas.

Kurzes Update von meiner Seite, vielleicht hilft es ja dem ein oder anderen mit Z-Wave Reichweiten Problemen. Nach weiteren Recherchen bin ich auf einen Beitrag gestoßen bei dem dem direkte Verwendung des Z-Wave+ USB Dongle am Raspberry das Problem war. Ich habe nun ein USB Verlängerungskabel verwendet und siehe da, ich erreiche das Danalock sogar ohne Fibaro Switch dazwischen. Also sind die paar Meter und die Stahlbetondecke anscheinend selbst für einen batteriebetriebenen Aktor kein Problem ...

@Andreas: Bisher läuft die Kommunikation zwischen FHEM und dem Danalock ohne Probleme