Fhem via Razberry mit Danalock verbinden

[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

[A.Harrenberg]

Hallo Elmar

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

[ElmarK]

Hallo Andreas,
bekommst Du heute Abend.

LG, Elmar

[A.Harrenberg]

Hi,

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.

[ElmarK]

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

Dankeschön !

[A.Harrenberg]

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

Code Auswählen Erweitern

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

[ElmarK]

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

[A.Harrenberg]

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.

[ElmarK]

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

LG, Elmar

[A.Harrenberg]

Hi Elmar,

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.

[ElmarK]

Merci

LG

[Nexus1211]

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ß

[A.Harrenberg]

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.

[Nexus1211]

Hallo Andreas,

danke fürs Feedback.

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?

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

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

Code Auswählen Erweitern

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

[A.Harrenberg]

Hi,

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

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.