Implementierung der ZWAVE Command Class SECURITY (0x98, AES Verschlüsselung)

[A.Harrenberg]

Hallo,
bezüglich meiner Probleme mit dem WakeUp,

Da muss ich wohl etwas genauer analysieren...

ich habe das jetzt noch ein paar Mal ausprobiert (sind jedesmal ca. 2000 Zeilen Log...) und keine Probleme mehr feststellen können. Keine Ahnung was da bei dem ersten Test schief gelaufen ist. Die 23 Get-Config-Befehle die bei meinem Multisensor durch "ConfigRequestAll" ausgelöst werden laufen momentan sauber ohne jedes CAN durch, sowohl als WakeUp als auch als netzgespeister Router.
Allerdings nur wenn ich, wie oben beschrieben, die Befehle für den ConfigRequestAll intern alle auf den Typ "Get" ändere.

@Rudi: Ist es möglich die Befehle einfach so auf "Get" zu ändern? Dann müsste ich mir noch mal die AssociationRequest Sachen anschauen, die hängen da ja auch mit "dran", oder?

Gruß,
Andreas.

[rudolfkoenig]

Moeglich schon, allerdings wird waehrend der ganzen Zeit FHEM blockiert, wenn man Pech hat, dann Minuten lang. Ceterum censeo: get gehoert abgeschafft. Mir waere es lieber eine andere Methode zu finden, wann es mit dem Senden bei Security weitergehen kann.

[A.Harrenberg]

Hi Rudi,

Moeglich schon, allerdings wird waehrend der ganzen Zeit FHEM blockiert, wenn man Pech hat, dann Minuten lang. Ceterum censeo: get gehoert abgeschafft. Mir waere es lieber eine andere Methode zu finden, wann es mit dem Senden bei Security weitergehen kann.

wieso wird FHEM denn blockiert?

Unter Security dauert das Abfragen der 23 Config-Request ca. 8 sekunden... Allerdings wird unter Security die ReadAnswerFn auch nicht aufgerufen da der Befehl für das verschlüsselte Senden als SET implementiert ist, obwohl da auch ein GET drin sein könnte...
(Vielleicht muss ich das auch mal ohne Security testen)

Ich finde nicht das die Unterscheidung zwischen SET und GET abgeschafft werden sollte. Wir müssen einen Weg finden einen Ersatz für die ReadAnswerFn zu finden bei dem nicht blockiert wird und Time-out berücksichtigt werden.

Wenn Du der Meinung bist das GET abgeschafft werden sollte, könnten man damit anfangen den Aufruf von ReadAnswerFn zu entfernen ,-)

Gruß,
Andreas.

[A.Harrenberg]

Hallo nochmal,

ich habe das ganze jetzt mal ohne SECURITY getestet.

Wie zu erwarten gab es jede Menge CAN / NO_ACK (je 22), die Kommunikation konnte sich aber über die re-sends doch noch fangen, alle 23 Readings waren letztendlich gefüllt, allerdings hat das ganze ~25 sekunden gedauert (unter Security trotz des Overheads nur 8 sekunden). Hier macht es keinen Unterschied ob ich das als  "get" oder "set" absetze.

Das ganze ist, wie mir gerade aufgefallen ist, mit "DelayNeeded = 0".
Wenn ich das DelayNeeded wieder auf 1 setze, dann kommt es nur zu einem CAN und das ganze dauert nur 6-7 sekunden. Die "Pause" von 0.3 sekunden reicht hier aus damit die Antwort ankommt bevor die nächste Nachricht gesendet wird.

Wenn es keine technischen Gründe dafür gab die Befehle als "Set" zu senden, würde ich vorschlagen das erst einmal so zu ändern das diese Befehle als "get" gesendet werden. Da aus dem WakeUpStack auch ohne ReadAnswerFn gesendet wird, kann man wirklich darüber nachdenken diese Funktion rauszunehmen. Eine Pause von 0.3 Sekunden sollte für normale Anwendungen reichen, wer ein großes vermaschtes Netzwerk hat wird aber auch hier Probleme bekommen...

Gruß,
Andreas.

[A.Harrenberg]

Hi Rudi,

anbei ein kleiner Patch, der neue Klassen, die erst unter SECURITY auftauchen, in die classes reinkopiert damit sie danach auch genutzt werden können. Das ganze ist etwas umständlich gelöst, ich wollte die neuen Klassen aber nicht einfach hinten anhängen sondern die Unterscheidung vor/ nach MARK beibehalten und sortiere daher etwas...

Wenn Du das eleganter/kürzer hinbekommst darfst Du das gerne korrigieren.

Gruß,
Andreas.

[A.Harrenberg]

Hallo Rudi,

hier noch ein kleiner Patch. Das meiste sind nur kleine Kosmetiksachen, ich habe aber auch meinen Änderungsvorschlag für ConfigRequestAll (-> Typ auf "get" ändern) mit da reingepackt.

Gruß,
Andreas.

[rudolfkoenig]

Habe beide patches ungeaendert eingecheckt.

[A.Harrenberg]

Hi Rudi,

Habe beide patches ungeaendert eingecheckt.

Danke!
Hast Du meinen Thread mit dem NO_ACK bei WakeUp mit dem AEOTEC Multisensor6 gesehen? Einen Patch als Vorschlag hatte ich auch gepostet.

Gruß,
Andreas.

[rudolfkoenig]

Frag mich naechste Woche nochmal. Bin z.Zt. unter Wasser

[A.Harrenberg]

Hi,

mach ich.

Nicht untergehen...
Andreas.

[A.Harrenberg]

Hi Rudi,

kannst Du Dir bitte mal das angehängte Patchfile anschauen? Da ist ein Workaround für SECURITY drin...

Problem ist das der Ablauf durcheinander kommt, wenn z.B. auf ein get mit SECURITY keine Antwort kommt, dann bleibt alles im Status "secStart" hängen und alle weiteren Befehle werden blockiert. Dann hilft nur noch ein Neustart von FHEM ,-(

Da ist jetzt ein Timer drin der immer wieder neu gestartet wird und wenn der letzte gesendete Befehl zu alt ist, wird als Notlösung "secEnd" aufgerufen. Das ist sicherlich etwas unschön, andererseits aber ähnlich dem TimeOut im normalen SendStack.

Die Wartezeiten sind willkürlich gewählt, einerseits will ich die ZWave-Kommunikation ja nicht unnötig lange verzögern, bei einem langsamen Netzwerken mit 4 Hops will ich aber auch nicht "aufgeben" bevor die Antwort ganz normal ankommt.

Falls Du noch eine bessere Idee hast um das abzufangen kann ich auch versuchen das anders umzusetzen.

Danke,
Andreas.

[rudolfkoenig]

Habs grob angeschaut, muss aber evtl. mit klarerem Verstand es nochmal tun.
Was auffaellt:
- RemoveInternalTimer($hash) entfernt _alle_ InternalTimer mit $hash Argument. Z.Zt. verwendet ZWave_secTestNetworkkeyVerify, ZWave_secUnlock, ZWave_wakeupTimer, und der Namenlose sub in ZWave_processSendStack $hash als Argument. Ich habe ein ungutes Gefuehl.
- Timer brauchen wir, auch weil wir mittel/langfristig get in set + hook in Parse (zwave_parseHook) umbauen werden.
- Log-Ausgabe in sec_unlock habe ich einkommentiert auf Level 3: das ist ein Fehler, und man sollte davon wissen.
- Eingecheckt, da ich im Normalbetrieb keine Probleme sehe.

[A.Harrenberg]

Hi,

Habs grob angeschaut, muss aber evtl. mit klarerem Verstand es nochmal tun.

ja bitte... ,-)

Was auffaellt:
- RemoveInternalTimer($hash) entfernt _alle_ InternalTimer mit $hash Argument. Z.Zt. verwendet ZWave_secTestNetworkkeyVerify, ZWave_secUnlock, ZWave_wakeupTimer, und der Namenlose sub in ZWave_processSendStack $hash als Argument. Ich habe ein ungutes Gefuehl.

Der RemoveInternalTimer($hash) war da vorher schon drin, den habe ich da nicht eingebaut...
Ich bin über die Stelle gestolpert da mein Timer nicht gegriffen hat und an der Stelle eben gelöscht wurde.

- Timer brauchen wir, auch weil wir mittel/langfristig get in set + hook in Parse (zwave_parseHook) umbauen werden.

Gibt es schon da schon ein Konzept für das zwave_parseHook?
Ich muss sagen das mir das Konzept hinter dem InternalTimer nicht wirklich klar ist, sehe das aber auch so das wir da mit einer Menge Timer arbeiten müssen um die verschiedenen TimeOuts zu realisieren. Wie gesagt habe ich mir die Timer noch nicht soo detailliert angeschaut, aber es wäre nützlich wenn man einen bestimmten, einzelnen, Timer löschen könnte und nicht nur alle auf einmal. Aber vielleicht geht das ja auch schon und ich habe es nur noch nicht gefunden.

Gruß,
Andreas.

[rudolfkoenig]

Gibt es schon da schon ein Konzept für das zwave_parseHook?

Das wird ja sogar schon aktiv verwendet. Ob es fuer die Sec-Funktionen an der richtigen Stelle geprueft/aufgerufen wird, weiss ich aber nicht.

es wäre nützlich wenn man einen bestimmten, einzelnen, Timer löschen könnte

Das kann man doch, man darf dann halt nicht $hash als Parameter angeben, sonder was Eigenes.

[A.Harrenberg]

Hi Rudi,

Das wird ja sogar schon aktiv verwendet. Ob es fuer die Sec-Funktionen an der richtigen Stelle geprueft/aufgerufen wird, weiss ich aber nicht.

huch, hab' ich da was übersehen?

Das kann man doch, man darf dann halt nicht $hash als Parameter angeben, sonder was Eigenes.

Auch das muss ich mir dann noch mal genauer ansehen. Die ganzen verschiedenen $hash in FHEM habe ich auch noch nicht so richtig verstanden...

Gruß,
Andreas.