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

[krikan]

weil ich zum gleichen Geraet keine Nachricht schicken sollte, bis ich nicht sicher bin, dass die vorherige angekommen ist.

Ob es zu den CallbackIds programmiertechnische andere Lösungen gibt, da bin ich raus.
Aber den obigen Satz(teil) verstehe ich nicht. Momentan überwacht Fhem mMn doch nur die korrekte Ablage einer Frage/Nachricht im Controller (NACK/CAN/OK/SOF). Alles was danach passiert, wird nicht durch Fhem progammtechnisch überwacht, das sind:
Wurde die Frage korrekt vom Controller verschickt ? -> 01130[ x ]
Wurde die Frage korrekt vom Gerät empfangen? -> 0013[callbackId][xx]
Fhem ist damit unbekannt, ob vor der nächsten im Controller abgelegten Frage die Antwort auf die vorherige Frage eingegangen ist.

Und man kann in größeren Installationen mMn nicht davon ausgehen, dass die Antworten zwingend in der Reihenfolge der Fragen eingehen. Telegrammlaufzeiten an den gleichen Node sind doch routen- und funklastabhängig und die Kommunikation ist störanfällig. (siehe zwapi: Z-Wave System Layer)

Wenn ich den Teilsatz richtig interpretiere, würde das einen Umbau der 00_ZWDongle.pm mit einem Warten auf die Antwort 0013[callbackId][xx] bedeuten. Das hatten wir vor kurzem zeitweise und führt zu deutlichen Verzögerungen in der Verarbeitung; jeweils 1 sek warten auf Controller-Timeout. Also nicht das, was ich mir wünsche. Und auch nach einem Controller-Timeout können Nachrichten in Sekundenbruchteilen eingehen.

Aus meiner Sicht dürfte man nur warten, bis die Frage korrekt vom Controller verschickt wurde (011301). Alles danach ist dann (auch für eine NodeId) dem Zufall überlassen. D.h. es ist vollkommen unklar, wann und ob die Antwort eingeht und in welcher Reihenfolge Antworten auf versandte, noch offene Fragen eingehen (siehe zwapi: Z-Wave System Layer). So verstehe ich theoretisch die Zufälligkeit des Funkkommunikation über die Router. Diese Probleme dürften umso größer werden, je größer das betrachtete Zwave-Netz ist.

Oder habe ich hier ein generelles Verständnisproblem bzw. etwas verpasst?

@Andreas: Sorry, war leicht Offtopic.

[A.Harrenberg]

Hallo Rudi,

Ich verstehe immer noch nicht die Notwendigkeit der CallbackIDs.
Die Funktion "Das ist die Antwort auf die Frage mit CallbackId 7" ist mAn uninteressant, da ich das auch sonst rauskriege bzw. nicht brauche. Die Funktion "Nachricht 7 ist verlorengegangen" ist natuerlich interessant, aber dazu braeuche ich auch kein Callbackid, weil ich zum gleichen Geraet keine Nachricht schicken sollte, bis ich nicht sicher bin, dass die vorherige angekommen ist.

Mir ist nicht klar wie Du das machen willst, dem Gerät keine Nachricht zu schicken bis die Antwort da ist? Meiner Meinung nach wird in FHEM/ZWave nicht verhindert das ich ein Get auslöse und noch bevor die Antwort mit dem Report kommt ein weiteren Befehl wegschicke. Oder habe ich da was im Code übersehen bzw. nicht verstanden?

Oder meinst Du nur das Verschicken bis zu der "Empfangsbestätigung" dieser Nachricht? Ich meine nämlich immer die Gesamt-Kommunikation, also vom Get bis zum Report. Mit den vielen NONCE Nachrichten bei Security ist das natürlich noch mal 'ne Nummer länger. Hier das Beispiel verschlüsselter Get Befehl, das dürfte das längste sein was auftreten kann:

1. Controller 9840 (Get Nonce) -> Node
2. Node 9880 (Nonce Report) -> Controller
3. Controller 9881 (verschlüsseltes Get) -> Node
4. Node 9840 (Get Nonce) -> Controller
5. Controller 9880 (Nonce Report) -> Node
6. Node 98c1 (verschlüsselter Report Teil 1) -> Controller (98c1 fordert implizit die nächste Nonce an)
7. Controller 9880 (Nonce Report) -> Node
8. Node 9881 (verschlüsselter Get Teil 2)

mMn nach darf dieser GESAMTE Ablauf nicht mit anderen Nachrichten gestört werden da die Geräte immer nur eine "aktive" Kommunikation erlauben. Was im Log von Christian auch drin war, das während einer solchen Aktion das Geräte eine Nachricht schicken wollte und dazu ein 9840 Get Nonce verschickt hat. Der Befehl wurde von FHEM angenommen und ein Nonce Report mit 9880 verschickt. Dann hagelt es aber CAN-Messages. Ich kann jetzt auf Anhieb nicht sagen welche Kommunikation verlorenging und welche dann durchkam, muss ich noch mal suchen ob ich das wiederfinde.

Wie kann ich denn erkennen das etwas nicht zum Ablauf gehört, wenn ich den Ablauf nicht irgendwo/irgendwie abbilde?
In OZW wird dafür die CB, die Node-ID und die erwartete Anwort (cc+cmd) abgelegt und eintreffende Nachrichten damit abgeglichen. Wenn der Fall aus Christians Log nun zufällig in Schritt 4 vom Beispiel passieren würde könnte man das ohne die CB-ID gar nicht unterscheiden, man würde ja sogar ein Get Nonce mit 9840 erwarten, nur gehört es nicht zu diesem Ablauf sonder ist quasi Schritt 1 einer von der Node initiierten Nachricht. Wobei man schon sagen muss das OZW dazu irgendwie 5 oder 6 verschiedene Queues verwaltet und die Befehle da lustig hin-und-her transferiert.

Auch wenn man von Vorne anfangen muss, weil ein Befehl in der Sequenz verlorengegangen ist, braucht kein CallbackId, nur ein Hook, damit ich weiss, dass ich von vorne anfangen muss.
Kann jemand mir konkret ein Problemfall schildern? Ich will nicht mit einem Umbau anfangen, bevor ich weiss, wozu.

Ich such noch mal die Logs von Christian ab, ob ich diese Problemfälle wiederfinde, das sind aber ein paar Tausend Zeilen... Christian war sehr fleissig beim Testen .-)
Dummerweise habe ich mir keine Notizen zu diesen Auffälligkeiten gemacht, da ich zu der Zeit an anderen Baustellen gearbeitet habe.

Wg. ZW_APPLICATION_UPDATE: meine WAKE_UP Geraete schicken kein wakeupNotifikation, falls ich die Knoepfe druecke, nur ein ZW_APPLICATION_UPDATE.

Wie wird denn der Tastendruck an sich gemeldet? Über Switch_Binary? Und danach kommt dann ein ZW_APPLICATION_UPDATE? Hast Du da evtl. mal ein kleines Log dazu?

Bei Gelegenheit schaue ich mal bei OZW nach was die so alles mit ZW_APPLICATION_UPDATE anstellen und ob die evtl. eine Beschreibung der Payload haben.

So, jetzt haben wir hier schon so viel über CallBackIDs geschrieben, jetzt könnten wir das auch hier drin lassen, mir wäre es egal, könnte aber sein das es in Zukunft noch weiter auseinander driftet... Neuer Thread oder nicht? Rudi?

Gruß,
Andreas.

[A.Harrenberg]

Hallo Rudi,

- das bei Internals der Inhalt nach Neustart verlorgen geht würde ja bedeutet das auch der WU-Sendstack nach Neustart weg ist, oder?

diese Frage habe ich mir jetzt per Test selbst beantwortet, ja, der WakeUp-Sendstack ist nach FHEM-Neustart weg. ;-(

Wenn der verlorengeht, dann sind auch die zu dem Security-Stack gehörenden GET-Nonce Befehle weg, d.h. ich könnte das auf Internals umstellen, dann wäre "synchron" beides weg.

Ich finde es aber unschön das da bei einem Neustart Nachrichten verloren gehen können, wenn es irgendwie vermeidbar ist. Die Befehle um neue Codes an meinen RFID-Leser anzulernen sind recht lange Hexzahlenketten die man manuell erstellen muss. Wenn solche Nachrichten dann verlorgengehen weil man FHEM vor der nächsten WU-Notification neu startet wäre das schon nervig.

Ist denn ein "leeres" Reading das einzige Problem das sich beim Abspeichern in Readings ergibt? Dann wäre es doch eigentlich schöner das leere Reading, wie von Dir vorgeschlagen, zu löschen und den WU-Stack analog auch auf Readings umzustellen, oder?

Falls dies der einzige Nachteil ist, dann würde ich mal anfangen das umzubauen.

Gruß,
Andreas.

[rudolfkoenig]

@krikan: Kennst du konkrete Faelle, die ein Umstellen der Resends von CAN/NAK auf 011301-Pruefung begruenden koennten?
@Andreas:
- wenn dir beim Loesung des erwaehnten Problems (Security-Geraet sendet freiwillig Daten waehrend eines Gets) ein separates Callback-Id hilft, dann habe ich nichts gegen die Einfuehrung: sowas kann man als Internal pro Geraet ohne weiteres Speichern. Allerdings sehe ich noch nicht, inwieweit das helfen koennte, da zu einer bestimmten Zeitpunkt nur ein get am laufen sein kann.
Man kann waehrend des gets auch keine anderen Befehle senden. "sets" sind ein ganz anderes Thema, dafuer muss bei Security eine interne Warteschlange existieren.

Wie wird denn der Tastendruck an sich gemeldet? Über Switch_Binary? Und danach kommt dann ein ZW_APPLICATION_UPDATE? Hast Du da evtl. mal ein kleines Log dazu?

Nein, es kommt nur ZW_APPLICATION_UPDATE. Hier ist ein Log:

Code Auswählen Erweitern

2015.08.29 12:21:13.329 4: ZWDongle_Read D: sending ACK, processing 00498429180412025e70852d8e80848f5a595b738672ef205b26272b60
2015.08.29 12:21:13.329 5: SW: 06
2015.08.29 12:21:13.330 5: D dispatch 00498429180412025e70852d8e80848f5a595b738672ef205b26272b60
2015.08.29 12:21:13.330 4: D CMD:ZW_APPLICATION_UPDATE ID:29 ARG:180412025e70852d8e80848f5a595b738672ef205b26272b60
2015.08.29 12:21:14.331 5: ZWDongle_Write 00 13290284082529
2015.08.29 12:21:14.332 5: SW: 010900132902840825294e
2015.08.29 12:21:14.333 5: ACK received, removing 010900132902840825294e from sendstack
2015.08.29 12:21:14.339 4: ZWDongle_Read D: sending ACK, processing 011301
2015.08.29 12:21:14.339 5: SW: 06
2015.08.29 12:21:14.340 5: D dispatch 011301
2015.08.29 12:21:14.355 4: ZWDongle_Read D: sending ACK, processing 001329000002
2015.08.29 12:21:14.355 5: SW: 06
2015.08.29 12:21:14.356 5: D dispatch 001329000002
2015.08.29 12:21:14.356 4: D CMD:ZW_SEND_DATA ID:00 ARG:0002
2015.08.29 12:21:14.356 4: D transmit OK for 29


Falls dies der einzige Nachteil ist, dann würde ich mal anfangen das umzubauen.

Langsam... Ich bin (wie geschrieben) nicht sicher, ob abgesetzte Befehle ein FHEM-Neustart ueberleben sollten. FHEM-Neustarts passieren nicht so haeufig, und im "Normallfall" sollte in der Wakeup-Schlange kein Befehl sein. Wer gerade auf eine Antwort vom Geraet wartet, der sollte FHEM nicht neu starten. Auf der anderen Seite weiss man nicht, wie viel Zeit zwischen FHEM shutdown und start liegt, und ob mit viel Verspaetung abgesetzte Befehle nicht einen Schaden anrichten.

[A.Harrenberg]

Hallo Rudi,

@Andreas:
- wenn dir beim Loesung des erwaehnten Problems (Security-Geraet sendet freiwillig Daten waehrend eines Gets) ein separates Callback-Id hilft, dann habe ich nichts gegen die Einfuehrung: sowas kann man als Internal pro Geraet ohne weiteres Speichern. Allerdings sehe ich noch nicht, inwieweit das helfen koennte, da zu einer bestimmten Zeitpunkt nur ein get am laufen sein kann.

mir scheint ich übersehe da was oder verstehe den Code doch noch nicht so gut...

Wie ist denn sichergestellt das immer nur ein Get läuft? Das einzige was ich noch finde, ist diese Stelle hier, an der Du nach dem Senden des Befehls noch eine Unterscheidung machst ob es ein Get-Befehl warst und ReadAnswerFn aus ZWDongle aufrufst.

Code Auswählen Erweitern

  IOWrite($hash, "00", $data);

  my $val;
  if($type eq "get") {
    no strict "refs";
    my $iohash = $hash->{IODev};
    my $fn = $modules{$iohash->{TYPE}}{ReadAnswerFn};
    my ($err, $data) = &{$fn}($iohash, $cmd, "^000400${id}..$cmdId") if($fn);
    use strict "refs";

    return $err if($err);
    $val = ($data ? ZWave_Parse($iohash, $data, $type) : "no data returned");

  } else {
    $cmd .= " ".join(" ", @a) if(@a);

  }
Ich verstehe aber nicht wo da verhindert wird das irgendein at, notify oder User selbst noch einen weiteren Befehl auslöst.

Zu den Callbacks kann ich nur sagen das die nur helfen so eine Ablaufkontrolle zu implementieren, das alleinige Setzen von eindeutigen CB-IDs hilft dann höchsten beim Debuggen. Ohne Umstellung der gesamten Sende/-Empfangsroutine bringt das nichts.

Nein, es kommt nur ZW_APPLICATION_UPDATE. Hier ist ein Log:

Code Auswählen Erweitern

2015.08.29 12:21:13.329 4: ZWDongle_Read D: sending ACK, processing 00498429180412025e70852d8e80848f5a595b738672ef205b26272b60


Na dann kommt jetzt mal 'ne ganz dumme Frage: wie wird der Tastendruck denn dann ausgewertet?

Langsam... Ich bin (wie geschrieben) nicht sicher, ob abgesetzte Befehle ein FHEM-Neustart ueberleben sollten. FHEM-Neustarts passieren nicht so haeufig, und im "Normallfall" sollte in der Wakeup-Schlange kein Befehl sein. Wer gerade auf eine Antwort vom Geraet wartet, der sollte FHEM nicht neu starten. Auf der anderen Seite weiss man nicht, wie viel Zeit zwischen FHEM shutdown und start liegt, und ob mit viel Verspaetung abgesetzte Befehle nicht einen Schaden anrichten.

Deine Bedenken sind sicherlich nicht unbegründet, mein Fokus war eher auf unbedachten "shutdown restart" Aktionen, die mich auch so schon einiges an verlorenen Änderungen gekostet haben.

Ich fände es gut wenn die Stacks einen "shutdown restart" überleben würden, kann Deine Bedenken aber durchaus nachvollziehen. Ich werde mir da noch ein paar weitere Gedanken zu machen wie man evtl. beides unter einen Hut bringen könnte ohne da einen riesigen Aufwand in der Konfiguration zu erzeugen.

Gruß,
Andreas.

[A.Harrenberg]

Hallo Rudi,

ich hätte da noch mal zwei Fragen zu meinen Hausaufgaben ,-)

- statt "use Crypt ::Rijndael;" sollten wir require in einem eval durchfuehren (siehe z.Bsp. 01_FHEMWEB.pm mit Compress), falls es schiefgeht, warnen im Log und die Security Funktionen abschalten. Und doumentieren, dass das Modul noetig ist.

Ich habe eine globale Variable definiert die ich in ZWave_Initialize auf 1 setze falls Crypt::Rijndael verfügbar ist.

Code Auswählen Erweitern

  eval { require Crypt::Rijndael; };
  $crypt_Rijndael = 1 if(!$@);

Frage 1: Ist es in Ordnung für so etwas eine globale Variable zu nutzen und das in ZWave_Initialize zu setzen?

Code Auswählen Erweitern

  SECURITY                 => { id => '98',
    set   => { "secKey"    => "81%s",
               "secScheme" => "0400",
               "sendNonce" => 'ZWave_secCreateNonce($hash)',
               "secEncap"  => "%s" },
    get   => { "secSupported" => "02" ,
               "secNonce"  => "40" },
    parse => { "..9803(.*)" => 'ZWave_secSupported($hash, $1)',
               "..9805(.*)" => 'ZWave_secureInit($hash, $1)', # secScheme
               "..9807"     => 'ZWave_secNetWorkKeyVerify($hash)',
               "..9840"     => 'ZWave_Set($hash, $hash->{NAME}, "sendNonce")',
               "..9880(.*)" => 'ZWave_secNonceReceived($hash, $1)',
               "..9881(.*)" => 'ZWave_secDecrypt($hash, $1, 0)',
               "..98c1(.*)" => 'ZWave_secDecrypt($hash, $1, 1)' } },

Die meisten set/get/parse werden bereits über Funktionsaufrufe abgewickelt. Es gibt nur relativ wenige Aufrufe die noch feste Werte oder die übergebenen Werte nutzen. Macht es jetzt Sinn jede dieser Aufrufe mit einer kleinen Funktion zu kapseln um dann dort auf Crypt::Rijndael abzufragen und die Warnungen ausgeben zu können? Eigentlich wollte ich soetwas in deser Art sowieso machen, da die ganzen Befehle ja automatisch zur Verfügung stehen sobald die Klasse SECURITY vorhanden ist, die Nutzung davon aber nur sinnvoll ist wenn auch eine secure-Inklusion stattgefunden hat.

Frage 2: Macht diese Kapselung jedes Befehls in einer Funktion Sinn, oder gäbe es eine Möglichkeit die Befehle aus der Liste des Gerätes zu entfernen falls zwar SECURITY vorhanden ist aber normal inkludiert wurde?

Eine entsprechende Abfrage/Warnung wegen Crypt::Rijndael könnte man auch nur einmal bei der Inklusion ausgeben, wenn danach keine Befehle vorhanden sind wird der Nutzer hoffentlich den Eintrag im Log finden...

Gruß,
Andreas.

[rudolfkoenig]

Wie ist denn sichergestellt das immer nur ein Get läuft?

Mit einer for-Schleife. Will sagen, solange keine Antwort von get da ist, ist alles blockiert. ZWave Nachrichten, die nicht auf als Antwort durchgehen, werden zwar angenommen und verarbeitet, aber sonst nix.

wie wird der Tastendruck denn dann ausgewertet?

Ich vermute, du bist auf falscher Faehrte: Bei allen Batteriebetriebenen gibt es eine Sonderfunktion (3-mal Knopf druecken, ader alle 4 auf einmal und dann den 2-er), die NUR ein ZW_APPLICATION_UPDATE ausloest, damit man die Controller-Befehle abholen kann, sonst nix.

Ist es in Ordnung für so etwas eine globale Variable zu nutzen und das in ZWave_Initialize zu setzen?

Ja. Eine Warnung im Log gehoert auch dazu, damit der Benutzer weiss, wieso SECURITY nicht aktiv ist.

gäbe es eine Möglichkeit die Befehle aus der Liste des Gerätes zu entfernen falls zwar SECURITY vorhanden ist aber normal inkludiert wurde?

In ZWave_getHash sollte eine Pruefung rein, damit ohne Rijndael bzw. ohne Secure-Inclusion SECURITY uebersprungen wird. Letzteres muss man an irgendwelchen Readings erkennen.

[A.Harrenberg]

Hallo Rudi,

Mit einer for-Schleife. Will sagen, solange keine Antwort von get da ist, ist alles blockiert. ZWave Nachrichten, die nicht auf als Antwort durchgehen, werden zwar angenommen und verarbeitet, aber sonst nix.

Ok, ich bin bisher davon ausgegangen das der Aufruf der ReadAnswerFn NICHT blockieren ist und das ein neuer Aufruf von ZWave_get auch durchgeht bis zum IOWrite...

Ich vermute, du bist auf falscher Faehrte: Bei allen Batteriebetriebenen gibt es eine Sonderfunktion (3-mal Knopf druecken, ader alle 4 auf einmal und dann den 2-er), die NUR ein ZW_APPLICATION_UPDATE ausloest, damit man die Controller-Befehle abholen kann, sonst nix.

Noch mal ok, Krikan hatte das ja auch schon geschrieben. Ich hatte es wirklich so verstanden das Dein Gerät (der KFOB-S?) die normalen Tastendrücke so meldet... Kommt denn nach einem normalen Tastendruck eine WU-Notification? Dann wäre die Welt für mich wieder in Ordnung ...

Ja. Eine Warnung im Log gehoert auch dazu, damit der Benutzer weiss, wieso SECURITY nicht aktiv ist.

Ich denke das muss ich sogar zweistufig machen, abhängig davon ob überhaupt versucht wurde das Gerät mit security zu inkludieren. Es könnte ja alles zutreffen, Gerät unterstützt Security, Crypt::Rijndael ist installiert, Netzwerkschlüssel existiert etc. aber der Nutzer wollte (oder hat) normal includiert. Dazu werde ich entsprechendes Reading anlegen das den Security-Status enthält und die Meldungen zusätzlich noch ins Log schreiben.

Gibt es eigentlich einen groben Hinweis welche Art von Fehlern man bei welchem Log-Level ausgeben sollte? Ich finde das teilweise bei den einzelnen Modulen sehr unterschiedlich was die bei Loglevel 3 ausgeben. Einige sind ganz ruhig, andere werfen schon mit internen Zahlenkolonen um sich...

In ZWave_getHash sollte eine Pruefung rein, damit ohne Rijndael bzw. ohne Secure-Inclusion SECURITY uebersprungen wird. Letzteres muss man an irgendwelchen Readings erkennen.

Die Funktion muss ich mir in Ruhe anschauen... Das ganze "Listenzeug" ist noch immer etwas schwer verständlich für mich. Problematisch ist das ich ich einige Einträge davon bereits während der Initialisierung für das Aushandeln der "Scheme" und das setzen des Netwerkschlüssels benötige. D.h. die müssen erst mal vorhanden sein und wenn was schief geht sollten die wieder entfernt werden. (Oder wird die Liste immer dynamisch erzeugt?)

Danke,
Andreas.

[rudolfkoenig]

Kommt denn nach einem normalen Tastendruck eine WU-Notification?

Nein. Ist bei beiden Fernbedienungen nicht der Fall. Vmtl. generell nicht ueblich.
Sonst wuerde ich mir den Krampf mit "alle 4 Knoepfe 5sec druecken, danach Nr2 druecken" nicht staendig antun.

Gibt es eigentlich einen groben Hinweis welche Art von Fehlern man bei welchem Log-Level ausgeben sollte?

http://fhem.de/commandref.html#verbose

Oder wird die Liste immer dynamisch erzeugt?

Ja.
Frisch reingekommen, und du solltest es kennen: %zwave_parseHook
Wird vmtl. aber fuer die Security-Funktionen zu spaet aufgerufen.

[A.Harrenberg]

Hallo Rudi,

Nein. Ist bei beiden Fernbedienungen nicht der Fall. Vmtl. generell nicht ueblich.
Sonst wuerde ich mir den Krampf mit "alle 4 Knoepfe 5sec druecken, danach Nr2 druecken" nicht staendig antun.

hmpf, ich gehe davon aus das Du da schon alle möglichen Konfigurationsparameter für WakeUp durchprobiert hast.

Man könnte mal ausprobieren was passiert, wenn man nach einem normalen Tastendruck einfach mal ein NO_OP am Sendstack vorbei zurückschickt und schaut was das Ding dann antwortet. (Und ob es überhaupt antwortet) Vielleicht lässt sich ihm ja so eine WU-Notification entlocken??

Bei dem RFID-Leser ist explizit beschrieben das nach der Nachricht eine WU-Notification gesendet wird um dem Gerät was mitzuteilen. Das kann aber daran liegen das man als "Bestätigung" da so einen kleinen Summer piepsen lassen kann. Das geht natürlich nur wenn das Ding auch Befehle entgegennimmt. Ich hatte vermutet das alle Geräte das so handhaben.

Ja.
Frisch reingekommen, und du solltest es kennen: %zwave_parseHook
Wird vmtl. aber fuer die Security-Funktionen zu spaet aufgerufen.

Äh, meinst Du mit "frisch reingekommen" das es noch nicht im SVN ist oder funktioniert da bei mir schon wieder was nicht? Aus dem SVN bekomme ich 9152 vom 29.8, und da ist %zwave_parseHook nicht zu finden.

Gruß,
Andreas.

[rudolfkoenig]

Die Geraete antworten nicht, wenn kein WakeUp ansteht.
Du kannst mir gerne das Gegenteil beweisen

Bzgl. Sourceforge: war mein Fehler, die Doku-Tags waren nicht geschlossen, und ich habe es bei Einchecken nicht gemerkt.

[A.Harrenberg]

Hallo Rudi,

Die Geraete antworten nicht, wenn kein WakeUp ansteht.
Du kannst mir gerne das Gegenteil beweisen

würde ich ja gerne, aber mein einziges WU-Gerät schickt ja IMMER eine WU-Notification...

Bzgl. Sourceforge: war mein Fehler, die Doku-Tags waren nicht geschlossen, und ich habe es bei Einchecken nicht gemerkt.

Ok, nun ist es drin, aber das wird ein paar Tage dauern bis ich begriffen was Du damit machst. Und dann noch ein paar Tage bis ich rausgefunden habe ob mir das hilft

Gruß,
Andreas.

[A.Harrenberg]

Hallo,

es gibt ein kleines Update, das aber nach außen keine wesentlichen funktionalen Unterschiede hat (hautpsächlich interne Änderungen).
Ich habe angefangen die Hausaufgaben von Rudi abzuarbeiten und habe das ganze auf die aktuelle Revision 9176 angepasst.

Das Rijndael Modul wird nun nicht mehr per "use Crypt::Rijndael" für alle Nutzer vorausgesetzt, sonder wird per "eval require" abgefragt. Falls das Modul nicht vorhanden ist, werden security Befehle nicht ausgeführt und es gibt Meldungen im Log. Ebenso wird auf die Klasse SECURITY und auf einen Netzwerkschlüssel geprüft.
Der Status wird in einem Reading "SECURITY" abgelegt und sollte hoffentlch ENABLED sein, ansonsten gibt es entsprechende DISABLED Einträge und Logmeldungen.

Momentan konnte ich es noch nicht umsetzen, dass die Befehle ausgeblendet werden, wenn SECURITY auf DISABLED steht. Momentan gibt es eine Fehlermeldung im Log und da ich das Senden momentan nicht abbrechen kann, wird eine 9800 gesendet. Das ist erst einmal eine Übergangslösung...

Der Code ist auf die Revision 9176 von Rudi angeglichen, die neuen Funktionen von Rudi habe ich aber noch nicht näher getestet.
Die Datei habe ich wieder an Post #1 angehängt.

Gruß,
Andreas.

P.S. Im Testcode sind auch zwei Get-Befehle für DOOR_LOCK enthalten,  hier habe ich (hoffentlich) ein paar dumme Fehler beim Parsen des Reports entfernt. Testobjekt war ein DanaLock von DarkScout. Bisher ist noch nicht klar wie man das Schloss entriegeln kann, das Gerät unterstützt nach secure-inclusion auch USER_CODE, das wird bei meinem RFID-Leser dazu genutzt die Codes zu programmieren die schalten dürfen.

@Rudi/Krikan: Tauchen bei der KFOB-S Fernbedienung eigentlich nach der secure-inclusion auch Klassen auf die vorher nicht da waren? Das DanaLock bietet ohne Security fast nichts...

   classes    MANUFACTURER_SPECIFIC BATTERY VERSION SECURITY
   secure_classes DOOR_LOCK USER_CODE SCHEDULE_ENTRY_LOCK CONFIGURATION TIME MANUFACTURER_SPECIFIC BATTERY VERSION MARK

[krikan]

@Rudi/Krikan: Tauchen bei der KFOB-S Fernbedienung eigentlich nach der secure-inclusion auch Klassen auf die vorher nicht da waren? Das DanaLock bietet ohne Security fast nichts...

KFOB-S:

Code Auswählen Erweitern

classes    ZWAVEPLUS_INFO MULTI_CMD POWERLEVEL SECURITY VERSION MANUFACTURER_SPECIFIC CONFIGURATION ASSOCIATION SCENE_CONTROLLER_CONF MULTI_CHANNEL_ASSOCIATION BATTERY WAKE_UP DEVICE_RESET_LOCALLY ASSOCIATION_GRP_INFO CENTRAL_SCENE MARK BASIC CENTRAL_SCENE SWITCH_MULTILEVEL SWITCH_ALL SCENE_ACTIVATION MULTI_CHANNEL
secure_classes MULTI_CMD MARK BASIC CENTRAL_SCENE SWITCH_MULTILEVEL SWITCH_ALL SCENE_ACTIVATION DOOR_LOCK MULTI_CHANNEL

[A.Harrenberg]

Hi Krikan,

KFOB-S:

Code Auswählen Erweitern

classes    ZWAVEPLUS_INFO MULTI_CMD POWERLEVEL SECURITY VERSION MANUFACTURER_SPECIFIC CONFIGURATION ASSOCIATION SCENE_CONTROLLER_CONF MULTI_CHANNEL_ASSOCIATION BATTERY WAKE_UP DEVICE_RESET_LOCALLY ASSOCIATION_GRP_INFO CENTRAL_SCENE MARK BASIC CENTRAL_SCENE SWITCH_MULTILEVEL SWITCH_ALL SCENE_ACTIVATION MULTI_CHANNEL
secure_classes MULTI_CMD MARK BASIC CENTRAL_SCENE SWITCH_MULTILEVEL SWITCH_ALL SCENE_ACTIVATION DOOR_LOCK MULTI_CHANNEL

Danke, auf Anhieb fällt mir da nur DOOR_LOCK auf.
Kannst Du bitte mal die Version von DOOR_LOCK abfragen? Ich habe ja nur die Doku für V1, wenn ich mich recht erinnere hat das DanaLock da aber sogar eine V3...

Gruß,
Andreas.