Bug: Secure + Batteriebetriebene Geräte

Begonnen von charlie71, 18 Juni 2020, 20:28:53

Vorheriges Thema - Nächstes Thema

charlie71

Hallo liebe FHEM Gemeinde,

ich habe folgendes Problem, mit meine batteriebetriebene ZWAVE Sensoren (Aeotec Multisensor 6, TriSensor, Fibaro DoorSensor 2, ...). Die Sensoren wurden secure inkludiert und arbeiten zu Beginn einwandfrei.

Wenn man jedoch einen Befehl am Kontroller absetzt, den dieser bis zum WAKE_UP buffert (get ZWave_SENSOR_NOTIFICATION_36 battery"), können keine Sensordaten mehr empfangen werden.
Erst wenn der der Befehl aus dem Buffer abgearbeitet wurde, funktioniert alles wieder.

Details:
Ausgangspunkt
cmdsPending = 0
alles funktioniert (Beispiel PIR)
2020.06.18 18:19:00 4: ZWDongle_Read uzb: rcvd 00040024029840b500 (request APPLICATION_COMMAND_HANDLER), sending ACK
2020.06.18 18:19:00 5: SW: 06
2020.06.18 18:19:00 5: uzb: dispatch 00040024029840b500
2020.06.18 18:19:00 4: CMD:APPLICATION_COMMAND_HANDLER ID:24 ARG:029840b500 CB:00
2020.06.18 18:19:00 5: ZWDongle_Write 0013240a9880d621a0d2658d81a3257f (f721da44)
2020.06.18 18:19:00 5: SW: 01110013240a9880d621a0d2658d81a3257fde
2020.06.18 18:19:00 5: ACK received, WaitForAck=>2 for 01110013240a9880d621a0d2658d81a3257fde
2020.06.18 18:19:00 4: ZWDongle_Read uzb: rcvd 011301 (answer ZW_SEND_DATA), sending ACK
2020.06.18 18:19:00 5: SW: 06
2020.06.18 18:19:00 5: uzb: dispatch 011301
2020.06.18 18:19:00 4: ZWDongle_Read uzb: rcvd 00137f00000300b57f7f7f7f0001030000000002010000 (request ZW_SEND_DATA), sending ACK
2020.06.18 18:19:00 5: SW: 06
2020.06.18 18:19:00 5: device ack reveived, removing 01110013240a9880d621a0d2658d81a3257fde from dongle sendstack
2020.06.18 18:19:00 5: uzb: dispatch 00137f00000300b57f7f7f7f0001030000000002010000
2020.06.18 18:19:00 4: CMD:ZW_SEND_DATA ID:00 ARG:000300b57f7f7f7f0001030000000002010000 CB:7f
2020.06.18 18:19:00 4: uzb transmit OK for CB 7f, target ZWave_SENSOR_NOTIFICATION_36
2020.06.18 18:19:00 4: ZWDongle_Read uzb: rcvd 000400241e988145c66b0775562dd61091ca7f872be7370b9f52d6d523ce6e3908f58cb300 (request APPLICATION_COMMAND_HANDLER), sending ACK
2020.06.18 18:19:00 5: SW: 06
2020.06.18 18:19:00 5: uzb: dispatch 000400241e988145c66b0775562dd61091ca7f872be7370b9f52d6d523ce6e3908f58cb300
2020.06.18 18:19:00 4: CMD:APPLICATION_COMMAND_HANDLER ID:24 ARG:1e988145c66b0775562dd61091ca7f872be7370b9f52d6d523ce6e3908f58cb300 CB:00
2020.06.18 18:19:00 4: CMD:APPLICATION_COMMAND_HANDLER ID:24 ARG:0a7105000000ff07000108 CB:00

Nun setzte ich ein get ZWave_SENSOR_NOTIFICATION_36 battery ab
cmdsPending = 2
2020.06.18 18:20:32 3: ZWave get ZWave_SENSOR_NOTIFICATION_36 battery
2020.06.18 18:20:39 3: ZWave_SENSOR_NOTIFICATION_36: secStart older than 6 seconds detected, secUnlock will call Zwave_secEnd
2020.06.18 18:20:52 3: ZWave get ZWave_SENSOR_NOTIFICATION_36 battery
2020.06.18 18:20:59 3: ZWave_SENSOR_NOTIFICATION_36: secStart older than 6 seconds detected, secUnlock will call Zwave_secEnd


Wenn ich jetzt den PIR teste, werden die Readings nicht mehr aktualisiert:

2020.06.18 18:22:08 4: ZWDongle_Read uzb: rcvd 00040024029840b500 (request APPLICATION_COMMAND_HANDLER), sending ACK
2020.06.18 18:22:08 5: SW: 06
2020.06.18 18:22:08 5: uzb: dispatch 00040024029840b500
2020.06.18 18:22:08 4: CMD:APPLICATION_COMMAND_HANDLER ID:24 ARG:029840b500 CB:00
2020.06.18 18:22:15 3: ZWave_SENSOR_NOTIFICATION_36: secStart older than 6 seconds detected, secUnlock will call Zwave_secEnd


Nach dem ich das Gerät manuell aufgeweckt habe, und cmdsPending = 0 ist, werden die Readings wieder aktualisiert.

Das Verhalten scheint unabhängig von den Sensoren zu sein, da ich es mit verschiedenen Sensoren von unterschiedlichen Hersteller reproduzieren konnte.

vielen Dank für eure Hilfe

tux75at

Soviel ich weiß, ist der Send Stack für Secure Batteriebetriebene Geräte nicht ganz fehlerfrei.
Ich hab mir das früher auch angeschaut und es nicht hinbekommen.
Wenn die Bugs beseitigt worden sind, dann würde ich mir das nochmal ansehen.
Früher gab es Fehlermeldungen dass die Nounce abgelaufen ist, wenn das Gerät geschlafen hat, vielleicht war es die gleiche Meldung wie bei dir, ist schon 1-2 Jahre her, dass ich mir das angeschaut habe.

charlie71

Ich hab mir das mal genauer angesehen und das Problem in der Funktion ZWave_addToSendStack  lokalisiert. Ganz am Ende wird die Funktion ZWave_processSendStack aufgerufen, wenn exakt ein Element im SendStack liegt (if(@{$ss} == 1)). Sie sollte jedoch aufgerufen wenden, wenn zumindest ein Element im SendStack liegt ( if(@{$ss} >= 1)).

Anstatt

sub ZWave_addToSendStack($$$) {
  ...
ZWave_processSendStack($hash, "next") if(@{$ss} == 1);
}


sollte folgendes stehen


sub ZWave_addToSendStack($$$) {
  ...
  ZWave_processSendStack($hash, "next") if(@{$ss} >= 1);
}


Ich habe es mit meinen Z-Wave Geräten erfolgreich getestet.

bitte um Prüfung und Aufnahme meines Änderungsvorschlages

lG
Charlie71


gamauf

Hallo Charlie!
Wäre super wenn das Problem endlich gelößt wäre.
Wenn es so einfach ist, wundert es mich, dass A.Harrenberg, der die ZWave security in FHEM implementiert hat, das so lange nicht lösen konnte.
Seine Threds zu dem Thema hast Du gelesen?
(z.B.: https://forum.fhem.de/index.php/topic,66398.msg585366.html#msg585366)

Danke, dass Du dich diesem Thema angenommen hast!

LG
Rainer

rudolfkoenig

ZitatSie sollte jedoch aufgerufen wenden, wenn zumindest ein Element im SendStack liegt ( if(@{$ss} >= 1)).
So einfach geht das nicht: mit dieser Loesung funktionieren schnell hintereinander gesendete Befehle nicht mehr, da sie alle an das Dongle geschickt werden, das wiederum Befehle verwirft, wenn Ausstehende nicht bestaetigt wurden, oder eine Antwort auf ein get aussteht.

Mit der aktuellen Version wird beim ersten Befehl das Dongle benachrichtigt, und der zweite Befehl wird nach Bestaetigung der ersten gesendet.
Bin offen fuer Patches, aber bitte ohne offensichtliche Nebenwirkungen.