Fhem via Razberry mit Danalock verbinden

[rudolfkoenig]

Was ist der Grund fuer 38401 statt 38400 ?

[decaflo]

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

[acw81]

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:

Code Auswählen Erweitern


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


Code Auswählen Erweitern


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?

Code Auswählen Erweitern


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

[rudolfkoenig]

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

[A.Harrenberg]

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.

[acw81]

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.

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.

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

[A.Harrenberg]

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.

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.

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

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

[acw81]

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