FHEM Forum

Hallo,

hier soll ein Thread entstehen, der sich mit der Implementierung der CommandClass SECURITY (0x98) und der darin enthaltenen AES-Verschlüsselung beschäftigt.

In einem anderen Thread im ZWave-Forum (ZME_KFOB_S / ZME_KFOB2 (http://forum.fhem.de/index.php/topic,37121.0.html)) wird die Implementierung der AES-Verschlüsselung für Fernbedienungen (ZWaveMe KFOB (http://www.z-wave.me/index.php?id=31)) bereits diskutiert. Da der Titel nur auf die Fernbedienung, aber nicht auf die AES-Verschlüsselung oder die entsprechende Befehlsklasse hinweist, eröffne ich hier mal einen neuen Thread.

Ich werde versuchen in diesem ersten Post eine Art Status der Entwicklung und Links zu wichtigen Nachrichten aktuell zu halten, diesen Post also immer wieder mal editieren.

Gruß,
Andreas.

Stand: 04.09.2015

Status:
Die Implementierung ist Dank der zur Verfügung stehenden Logfiles und Sourcen aus OpenZWave jetzt prinzipiell funktionsfähig, die Umsetzung im FHEM Code ist aber noch nicht wirklich schön und vor allem noch nicht gegen irgendwelche Fehler abgesichert.

Aktuell sind keine Fehler in den Security Funktionen bekannt, allerdings gibt es noch Störungen des Kommunikationsprotokolls sobald mehrere Nachrichten "gleichzeitig" bzw. aus dem Wake-Up-Stack abgearbeitet werden. Das ist ein generelles Problem und eigentlich nicht direkt SECURITY spezifisch, die Kommunikation ist aufgrund der größeren Anzahl an Nachrichten aber leider empfindlicher gegen Störungen durch andere Nachrichten.

Die Befehle werden jetzt per Timer und einer "Pause" vom WakeUp-Stack geholt und verschickt. Nach unverschlüsselte Nachrichten wird jetzt nur noch  0.05 Sekunden gewartet, da hier theoretisch keine weiteren Nachrichten gesendet werden sollten, nach  verschlüsselten Nachrichten wird 1.5 Sekunden gewartet. Diese Werte sind neu und müssen sich noch in Tests bewähren...

Es gibt jetzt ein Reading "SECURITY" in dem der Status (hoffentlich ENABLED) gespeichert wird. Falls es hier einen Fehlereintrag mit "DISABLED" gibt, werden die security Befehle nur als dummy 0x9800 ausgegeben. (Hier muss noch eine bessere Lösung gefunden werden...)

Die letzten Änderungen von Rudi aus der 9176 habe ich erst einmal soweit übernommen, aber noch nicht im Zusammenspiel mit Security getestet. Die Zwischenspeicherung der Daten ist jetzt mit "Internals" statt "Readings" implementiert.

Dokumentation ist wieder gefixt, war in der letzten Datei (intern V1.26) leider durcheinander geraten...

Das Ganze ist noch in der Testphase, daher empfehle ich das nur auf Testsystemen auszuprobieren oder man sollte genau wissen was man tut...

• OK: Initialisierung des Controllers, sodass Geräte die SECURITY unterstützen dies auch melden
• OK: erste Befehle zur Vorbereitung des Schlüsselaustauschs implementiert (SchemeGet/-Report, NonceGet/-Report, NetworkkeySet)
• OK: Schlüsselaustausch / Verschlüsselung / Authentifizierung kann offline nachvollzogen werden
• OK: Implementierung Schlüsselaustausch
• OK: Implementierung AES-Verschlüsselung
• OK: Implementierung Abfrage der verschlüsselten Klassen
• OK: Implementierung Messagehandling Senden/Empfangen von verschlüsselten Nachrichten
• OK: Probleme bei Wake-Up Gerät, Work-around eingefügt bis vernünftige Lösung gefunden ist
• OK: Prüfen ob AES-Verschlüsselungsroutingen im CUL-HM kompatibel sind -> CUL-HM nutzt ebenfalls Crypt::Rijndael
• OK: Funktion bei Multi-Channel nachvollziehen, Befehle werden transparent abgearbeitet
• OK: Abarbeiten des WakeUp-Sendstacks per Timer
• Offen: Fehlende Steuerung des Sendstacks
• OK: Status für Securtiy als Reading (ENABLED / DISABLED)
• OK: Abfrage auf Crypt::Rijndael per "eval require" mit Fehlermeldungen im Log
• OK: Abfrage auf SECURITY Klasse mit Fehlermeldungen im Log
• OK: Abfrage auf vorhandenen Netzwerkschlüssel mit Fehlermeldungen im Log
• OK: Abfrage auf Verify des Netzwerkschlüssel per Timer mit Fehlermeldungen im Log
• OK: Umstellung des security stacks von Readings auf Internals
• OK: Umstellung des frame stacks von Readings auf Internals
• Offen: Abbruch eines Befehls falls Status "DISABLED", aktuell wird noch 9800 gesendet...

Eine Version zum Testen (basiert auf 9176) ist angehängt, Auslösen einer "secure Inclusion" geht nur über die Befehlszeile mit:
set <Devicename ZWave, meist ZWDongle_0> addNode on sec
Das "addNode off" kann dann ganz normal über das DropDown gemacht werden.

Zum Testen muss auch ein Netzwerkschlüssel im ZWDongle Gerät definiert sein:
Attribut 'networkKey' muss mit einer 32-zeichen langen Hexzahl gefüllt werden (ohne 0x), also z.B. '0102030405060708090a0b0c0d0e0f10'.

Zitat von: Netsurfer am 07 September 2015, 16:17:56
falls noch jemand wie ich nicht weiß wie man das Perl Modul Crypt::Rijndael unter Ubuntu installiert
apt-get install libcrypt-rijndael-perl
hat bei mir funktioniert.

Infos:

• Ursprüngliche Diskussion zur Fernbedienung (ZME_KFOB_S / ZME_KFOB2 (http://forum.fhem.de/index.php/topic,37121.0.html))
• Beitrag mit Logfile einer "Secure-Inclusion" des KFOB_S unter OpenZWave (KFOB_S Inclusion mit OpenZWave (http://forum.fhem.de/index.php/topic,37121.msg297468.html#msg297468))
• Beitrag mit weiterem Logfile einer "Secure-Inclusion" des KFOB_S unter OpenZWave (KFOB_S Inclusion mit OpenZWave (http://forum.fhem.de/index.php/topic,37121.msg297524.html#msg297524))
• Beitrag mit Logfile einer "Secure-Inclusion" einer AEON-Labs Sirene unter OpenZWave (DSD31 Inclusion mit OpenZWave (http://forum.fhem.de/index.php/topic,37121.msg297532.html#msg297532))
• Beitrag von Rudi zur Implementierung der Controller Initialisierung (Implementierung Controller Initialisierung (http://forum.fhem.de/index.php/topic,37121.msg297691.html#msg297691))
• Beitrag von Rudi zur Implementierung der ersten SECURITY Befehle (Implementierung Controller Initialisierung (http://forum.fhem.de/index.php/topic,37121.msg297790.html#msg297790))
• Beitrag mit Logfile einer "Secure-Inclusion" des KFOB_S unter Z-Way (KFOB_S Inclusion mit Z-Way (http://forum.fhem.de/index.php/topic,37121.msg303085.html#msg303085))

Hallo,

um den ersten Post nicht zu überfrachten hier mal eine etwas ausführlichere Beschreibung des aktuellen Stands:

Für die Implementierung der Befehlsklasse SECURITY sind neben "normalen" Befehlen auch verschlüsselte Nachrichten zu erzeugen, wozu man eine AES Implementierung benötigt und den genauen Ablauf und die Erzeugung der nötigen Schlüsselpaare abbilden muss.

Da dies bei OpenZwave bereits weitgehend implementiert ist, haben wir entsprechende Logfiles einer "Secure Inclusion" zur Verfügung. Deren Analyse hat bereits zu der Implementierung der Initialisierung des Controllers und einiger grundlegender Befehle der Klasse durch Rudi geführt.

In den wenigen zur Verfügung stehenden Dokumenten zu dem Thema ist für eine "Secure Inclusion" beschrieben das direkt nach Ablauf der normalen Inclusion das Aushandeln/Übertragen des Schlüssels durchzuführen ist.

Für die Erklärung des Ablaufs gilt:
C = Controller
N = Node (also das einzubindende Gerät)
S = Send -> CS = Controller sendet etwas, NS = Node sendet etwas
R = Receice -> CR = Controller empfängt etwas, NR = Node empfängt etwas

Der Unterschied zwischen CR (Controller empfängt) und NS (Node sendet) ist, das es sich bei CR normalerweise um eine Antwort auf einen vorherigen Befehl handelt, und bei NS um einen neuen Befehl den die Node verschickt.
Bei den Angaben hinter CR, CS, NR oder NS handelt es sich dann um Befehle der SECURITY Class.

In der Doku ist der Ablauf wie folgt dargestellt:
1: CS SchemeGet / CR SchemeReport
2: CS NonceGet / CR NonceReport
3: CS NetworkkeySet (lt. Doku verschlüsselte Nachricht)
4: NS NonceGet / NR NonceReport
5: NS NetworkkeyVerify (lt. Doku verschlüsselte Nachricht)

In den Logfiles von OpenZWave ist das NetworkkeySet aus Schritt 4 nicht verschlüsselt, es erfolgt aber eine verschlüsselte Bestätigung im Schritt 5. Allerdings wird beim Empfang dieser verschlüsselten Bestätigung dort ein Fehler in der Verschlüsselung angezeigt. Im weiteren Verlauf des Logfiles scheint aber trotzdem alles zu funktionieren.

In der aktuellen Version von FHEM kann man eine "secure Inclusion" mit <set ZWDongle_0 addNode on sec> auslösen. Hierbei wird aktuell noch eine andere Reihenfolger der Schritte ausgelöst und es erfolgt KEINE verschlüsselte Bestätigung des Schlüssels.

Ich habe lokal bei mir die Befehle auf die oben dargestellte und in OpenZWave vorhandene Reihenfolge umgestellt, erhalte aber leider trotzdem KEINE verschlüsselte Rückmeldung von meinem Gerät.

Da bis zu diesem Zeitpunkt noch keine Verschlüsselung auf Seiten des Controllers (FHEM) benötigt wird, scheint es demnach immer noch Unterschiede bei der Initialisierung des Controllers oder Details bei den versendeten Befehlen zu geben. Hier sind weitere Analysen der Logfiles nötig um Unterschiede aufzudecken und Anpassungen an FHEM zu machen.

Aktuell habe ich Domoticz/OpenZWave zum Testen unter Windows installiert, da kann ich jetzt zwar einen Vergleichstest machen, ich kann dort allerdings nichts am Code ändern. Als nächsten Schritt werde ich daher versuchen mir OpenZWave und das dazugehörige Control Panel mit den Sourcen unter Linux zu compilieren/installieren, damit ich da die Möglichkeit habe Vergleichstests zu machen und ggf. auch Änderungen wie z.B. erweiterte Debug-Ausgaben neu in den Code einzucompilieren.

Zum Thema AES Verschlüsselung ist momentan noch nicht soo viel zu sagen, soweit bisher bekannt werden verschiedene Block-Modi für AES benötigt, hier gehen die Informationen aus den verschiendenen Quellen aber auseinander. An dieser Stelle ist wahrscheinlich ein reverse Engineering aus den Sourcen von OpenZWave hilfreich.

Soweit erst einmal der Stand, leider bin ich am Mitte der Woche erst mal für 2.5 Wochen in Urlaub, werde mich daher erst nach meinem Urlaub intensiver um das Thema kümmern können.

Gruß,
Andreas.

Hallo,

und schon die ersten neuen Erkenntnisse ,-)

Eine erste oberflächliche Analyse des Logfiles von Z-Way zeigt, dass der NetworkkeySet (im Schritt 4 aus dem zweiten Post) dort VERSCHLÜSSELT erfolgt! Das passt dann zu der Beschreibung in der Doku, jedoch nicht zu dem Ablauf bei OpenZWave...

Ich werde mal versuchen mir den Code von OpenZWave anzuschauen, ich hatte bereits den Verdacht das dort der NetworkkeySet auch verschlüsselt erfolgt, dies aber im Logfile nicht zu erkennen weil evtl. die Ausgabe an der "falschen" Stelle im Code erzeugt wird. Das Log von Z-Way verstärkt diesen Verdacht...

Gruß,
Andreas.

Hallo Andreas,
meine Logs mit openzwave waren noch mit dem "alten" security-Branch erstellt. Vielleicht hat sich dort zwischenzeitlich, nach Übernahme in den Master-Branch, noch etwas getan. Soll ich noch mal probieren mit dem aktuellen Master-Branch Logs zu erzeugen?
Gruß, Christian

Hallo Christian,

ich habe hier selbst mal mit "domoticz-win32-2_2583-setup" rumgespielt, das sollte eigentlich die neueste Version sein. Falls Du nichts neueres zur Verfügung hast brauch ich da ersteinmal keine weiteren Logfiles.

Ich muss allerdings sagen das ich mit Domoticz ganz schön gekämpft habe bis da mal ein vernünftiges Logfile rauskam.

Falls Du doch noch was testen möchtest, einfach im Logfile schauen ob da ein 9806 (SECURITY NetworkkeySet) als Befehl drin vorkommt, falls ja ist es unverschlüsselt... (oder nicht richtig geloggt).
Ansonsten müsste nach dem SchemeGet/-Report, NonceGet/-Report ein 9881 (SECURITY MessageEncap) als Befehl vorkommen. Das wäre dann ein verschlüsseltes Packet, so eins kommt dann später als Antwort und müsste eigentlich eine 9807 (SECURITY NetworkKeyVerify) enthalten.

Gruß,
Andreas.

Zitat von: A.Harrenberg am 27 Juni 2015, 23:39:55
mal mit "domoticz-win32-2_2583-setup" rumgespielt, das sollte eigentlich die neueste Version sein.

Wenn ich das richtig verstehe, enthält das nicht den aktuellen Master-Branch, sondern nur den von mir getesteten security-branch.

Zitat von: A.Harrenberg am 27 Juni 2015, 23:39:55
Falls Du doch noch was testen möchtest, ......

Möchten, mmh ;). Aber wenn es Dir/uns ggfs. hilft probiere ich es.

Hi Christian,

momentan ist meine Zeit eh recht knapp, da ich vor dem Urlaub beruflich und privat noch so einige andere Sachen zu erledigen habe... Und im Urlaub habe ich kein Internet ,-)

Von daher würde ich sagen das ich momentan mit weiteren Logfiles nicht sooo viel anfangen kann, Ich denke ich werde erst mal versuchen mir das ganze OpenZWave mit der Console aus den aktuellen Sourcen zu kompilieren und das auf meiner Linuxrechner ans Laufen zu bringen. Das bringt auf lange Sicht wohl mehr.

Das schöne an Perl ist ja das man "mal eben" eine weitere Zeile mit einer Logausgabe zum Code hinzufügt und es sofort ausprobieren kann. Bei OpenZWave muss man ja compilieren, und das werde ich mir unter Windows nicht "antun".

Wenn ich diese Woche noch ein wenig Zeit finde schaue ich mir den Sourcecode von OpenZWave noch mal an um zu sehen ob dieser NetworkkeySet nun wirklich unverschlüsselt gesendet wird oder ob da das Logging nicht stimmt.

Also würde ich sagen warten wir mal ab bis mein OpenZWave mit den akutellen Sourcen läuft, dann kann ich da weitere Logfiles erzeugen und habe dann wahrscheinlich auch schon mehr Übersicht über den Sourcecode.

Gruß,
Andreas.

OK, dann habe ich noch mal Glück gehabt ;). Wenn ich etwas testen/probieren kann, gib einfach Bescheid. Ansonsten schönen Urlaub.

Hallo,

so, habe es jetzt nach einigen Anläufen geschafft mir Domoticz auf dem Linux Rechner zu installieren und habe die Inclusion dort noch mal ausgeführt.

Es ist jetzt ziemlich sicher das auch OpenZwave den NetworkkeySet verschlüsselt überträgt. Das Logfile der etwas neueren Version ist da etwas gesprächiger, der Befehl für die Schlüsselübertragung ist im Klartext angegeben, danach kommt die verschlüsselte Variante und das danach dürfte die MAC sein.

Beim der Logzeile mit dem "Send" wird dann wieder die unverschlüsselte Version ausgegeben, so wie in den alten Logfiles auch, wodurch ja das Missverständnis aufkam.

2015-06-28 17:32:07.907 Info, Node001, Setting Up Inclusion Network Key for Secure Communications
2015-06-28 17:32:07.907 Info, Plain Text Packet:: 0x00, 0x98, 0x06, 0x01, 0x02, 0x03, 0x04, 0x05, 0x06, 0x07, 0x08, 0x09, 0x0a, 0x0b, 0x0c, 0x0d, 0x0e, 0x0f, 0x10
2015-06-28 17:32:07.907 Info, Node001, Setting Up Inclusion Network Key for Secure Communications
2015-06-28 17:32:07.907 Info, Encrypted Packet: 0x1d, 0x31, 0xdd, 0x53, 0xf7, 0xee, 0x56, 0x41, 0x90, 0x36, 0x8b, 0x71, 0xdc, 0x01, 0xdf, 0xb3, 0x3a, 0xea, 0x52
2015-06-28 17:32:07.907 Info, Raw Auth (minus IV): 0x81, 0x01, 0x28, 0x13, 0x1d, 0x31, 0xdd, 0x53, 0xf7, 0xee, 0x56, 0x41, 0x90, 0x36, 0x8b, 0x71, 0xdc, 0x01, 0xdf, 0xb3, 0x3a, 0xea, 0x52

2015-06-28 17:32:07.907 Info, Computed Auth: 0x05, 0xac, 0xda, 0x23, 0xf8, 0x45, 0x00, 0x72
2015-06-28 17:32:07.907 Info, Node040, Sending (Security) message (Callback ID=0x0d, Expected Reply=0x04) - SecurityCmd_NetworkKeySet (Node=40): 0x01, 0x19, 0x00, 0x13, 0x28, 0x12, 0x98, 0x06, 0x01, 0x02, 0x03, 0x04, 0x05, 0x06, 0x07, 0x08, 0x09, 0x0a, 0x0b, 0x0c, 0x0d, 0x0e, 0x0f, 0x10, 0x25, 0x0d, 0x69


Damit ist jetzt klar das wir jetzt auf die AES Implementierung angewiesen sind um diesen Schritt auszuführen. Immerhin bin ich jetzt beruhigt das dies mit der Dokumentation übereinstimmt. In dieser Version von OpenZWave ist der MAC-Fehler bei der NetworkkeyVerifiy Antwort vom Gerät allerdings immer noch enthalten, das sollte sicherlich auch nicht so sein...

Gruß,
Andreas.

Hallo zusammen,

mal ein kleiner Gruß aus meinem Urlaub... Hab' doch Internet... :-)

Ich wollte mal einen ersten kleinen, aber durchaus wichtigen Erfolg melden: Mittels Crypt:Rijndael konnte ich jetzt offline die Entschlüsselung eines Packetes nachvollziehen und bekomme auch das gleiche Ergebnis wie OpenZWave...

Dabei kam auch raus, das OpenZWave das erste Packet mit der Bestätigungsantwort des Netzwerkschlüssels falsch dekodiert, dies aber nicht weiter beachtet. Wenn ich die verschlüsselte Nachricht entschlüssel dann erhalte ich wie im Protokoll vorgesehen eine "0x98 0x07", was dann "Networkkey Verify" ist.

Als nächstes muss ich mir jetzt mal eine gesendete Nachricht anschauen, die sollte aber prinzipiell genauso verschlüsselt werden, das Verfahren ist an der Stelle symmetrisch.

Danach muss ich dann noch die an die Nahricht angehängte Authentifizierung (MAC message authentication code) nachvollziehen, hier wird ein anderer Modus verwendet, ich denke aber das ich das auch "nachbauen" kann.

Dann wäre die eigentliche Verschlüsselung schon mal geklärt, ich fürchte allerdings das die Implementierung einige größere Änderungen an der bisherigen Struktur von 00_ZWDongle und 10_ZWave benötigt. Dazu muss ich dann aber erst mal besser verstehen wie der Ablauf dort funktioniert.

Gruß,
Andreas.

Hallo,

so, jetzt bin ich soweit "durch"...

Ich kann jetzt alle Verschlüsselungsschritte und auch die Authentifizierung die OpenZWave macht offline nachvollziehen.

Bei der Verschlüsselung der ersten Nachricht (die Übermittelung des Networkkey Set) sowie der dazugehörigen MAC (message authentification code) werden jeweils temporäre Keys für die Verschlüsselung und die Authentifizierung verwendet.

Aus dem angegebenen Networkkey wird jeweils ein "encryption key" und ein "authentication key" gebildet mit dem dann bereits die Antwort (Networkkey Verify) verschlüsselt und authentifiziert ist.

Ab hier werden dann nur noch der "encryption key" und der "authentication key" verwendet.

Der Fehler bei OpenZWave besteht im Moment darin das dort versucht wird die Antwort noch mit dem temporären Keys zu entschlüsseln und zu authentifizieren. Dies ist zwar unschön, hat aber weiter keine Auwirkung, da die Antwort nicht weiter geprüft wird.

Mehr kann ich dann erst wieder von zu Hause machen.

Gruß,
Andres

Hi,

kurzer "Zwischenbericht":

Ich habe mir im ersten Schritt jetzt mal ganz grob die Verschlüsselung und Authentifizierung für den "NetworkKey_Set" Befehl in den bisher vorhandenen SecureInit reingebastelt. (Das wird anders verschlüsselt als die nachfolgenden Nachrichten, da der Key beim Empfänger ja noch nicht bekannt ist)
Ich kann jetzt mit der empfangenen Nonce vom Gerät eine verschlüsselte Nachricht erzeugen und auch verschicken, allerdings reagiert mein Gerät leider NICHT mit einer entsprechenden Antwort darauf.  ,-(

Ich habe mir in Domoticz/OpenZwave ein paar zusätzliche Logmeldungen eingebaut, bisher aber keine prinzipiellen Unterschiede feststellen können.
Leider kann man das ja nich so einfach vergleichen, da die Verschlüsselung ja die empfangene Nonce berücksichtigt und die Packete damit jedesmal anders lauten.

Ich werde mir morgen mal die beiden verschlüsselten Nachrichten (von FHEM und OpenZWave) nehmen und die noch mal offline entschlüsseln, vielleicht habe ich ja doch noch einen oder mehrere Fehler bei der Verschlüsselung reingebaut. Falls nicht könnte es noch etwas mit der Initialisierung des Controllers zu tun haben. Dazu muss ich mir aber JEDES Packet aus dem Domoticz/OpenZwave Logfile ansehen...

Ich hatte eigentlich gehofft hier schneller weiter zu kommen, da die Verschlüsselung jetzt ja eigentlich klar ist...
Ich werde dann morgen noch mal berichten.

Gruß,
Andreas.

Hallo,

zweiter Versuch, meine erste Antwort ist gerade im Nirvana verschwunden ,-(

Zitat von: A.Harrenberg am 25 Juli 2015, 22:56:21
Ich werde mir morgen mal die beiden verschlüsselten Nachrichten (von FHEM und OpenZWave) nehmen und die noch mal offline entschlüsseln, vielleicht habe ich ja doch noch einen oder mehrere Fehler bei der Verschlüsselung reingebaut.

Natürlich waren noch Fehler bei der Verschlüsselung drin...

Aber jetzt funktioniert es!

Ich bekomme jetzt auf das verschlüsselte Senden des Netzwerkschlüssels eine verschlüsselte Antwort vom Gerät. Diese kann ich zwar aktuell nur offline entschlüsseln, es ist aber "Networkkey_Verify"!

Damit wäre der "Proof of Concept" gemacht, die aktuelle Umsetzung ist aber nicht allgemein tauglich sonder ist nur diesen ersten Schritt zusammengebastelt. Da sind z.B. etliche Sachen einfach fest eingetragen statt vernünftig berechnet zu werden und der Ablauf ist auch alles andere als "schön" realisiert. Aber es ging mir jetzt eigentlich nur darum festzustellen ob denn das Gerät die Verschlüsselung akzeptieren würde.

Momentan habe ich noch keinen richtigen Ansatz wie man das "schön" implementieren kann, irgendwie hat das immer etwas von Sonderfallregelung und Work-around...

Hier mal ein paar Gedanken zum Ablauf zur Diskussion:

Beim Versenden eine Nachricht muss geprüft werden ob die Nachricht verschlüsselt gesendet werden muss. Hierzu könnte ich mir ein zusätzliches Attribut (oder besser Internal) "secure_classes" vorstellen das aus der Abfrage des "Supported_Get" bei der secure-Inklusion gebildet werden muss. Die Nachricht würde man wahrscheinlich am besten in ZWave_Cmd "abfangen" und müsste sie zwischenspeichern. Dann müsste man bei dem Geräte eine Nonce anfragen und auf die Antwort warten. Mit der empfangenen Nonce, einer eignenen Nonce und dem Netzwerkschlüssel kann die Nachricht dann versendet werden.
Das Abfangen und zwischenspeichern könnte man evtl. ähnlich zu dem Sendstack für Wake-Up Geräte realisieren, das habe ich mir aber bisher noch nicht genau genug angesehen.

Beim Empfang einer verschlüsselten Nachricht muss es vorher eine Anfrage für eine Nonce gegeben haben. Diese muss generiert, verschickt und zwischengespeichert werden, da sie zur Entschlüsselung benötigt wird. Wenn dann eine verschlüsselte Nachricht eintrifft muss man die dazu passende Nonce "wiederfinden" und die Nachricht mit dem Netzwerkschlüssel entschlüsseln. Die so entschlüsselte Nachricht muss dann noch mal in FHEM eingespeist werden, hier hatte Rudi in einem anderen Thread das Stichwort "Dispatch" gebracht.

@Rudi, bitte versteh' das jetzt nicht falsch, aber der aktuelle Code für ZWave ist teilweise sehr schwer nachzuvollziehen und enthält schon eine ganze Menge an Sonderfällen und Work-arounds. Dies würde durch die beschriebenen Funktionen sicherlich nicht besser werden sondern noch mal deutlich leiden.

Aktuell habe ich aber auch (noch) keinen Verbesserungsvorschlag, fürchte jedoch das sich Security nicht wirklich sauber in den aktuellen Code implementieren lässt...

Hast Du evtl. konkrete Ideen zur Implementierung/Umstrukturierung die Du mal kurz beschreiben könntest? Das soll ja nicht bedeuten das Du es dann auch umsetzen sollst, ich denke das ich mich so langsam einarbeite und da sicherlich auch einiges umsetzen kann, zumal man ja auch fragen kann ,-)

So, jetzt muss ich aber frühstücken, wollte ich ja vorhin schon, nur ist dann die Antwort verschwunden...

Gruß,
Andreas.

Hallo,

noch mal ein kurzer Bericht zum Zwischenstand:

Ich habe jetzt einige Unterroutinen erstellt mit deren Hilfe ich die Nachrichten ver- und entschlüsseln kann, sowie die Authentfizierung erstellen bzw. prüfen kann. Das ganz funktioniert jetzt schon sehr schön bis zum Empfang der verschlüsselten Bestätigung des Netzwerkschlüssels. Die Entschlüsselung der empfangenen Nachricht funktioniert jetzt auch schon, muss aber noch etwas erweitert werden.

Soweit schon mal gut, jetzt muss ich diesen entschlüsselten Befehl nur noch wieder in neu in FHEM einspeisen, meine erste Idee mit "dispatch" wird leider nicht funktionieren, da es ja an der Stelle keine komplette ZWave Nachricht mehr ist. Wahrscheinlich kann ich den Befehl aber einfach in ZWave_Parse einspeisen. Momentan ist im Code noch so gut wie keine Sicherheitsabfragen drin, aber so langsam wird das was...

Als nächstes muss ich dann eine verschlüsselte Nachricht mit "Supported_Get" erzeugen und die Rückgabewerte auswerten.

Gruß,
Andreas.

Hallo,

nachdem ich ein paar Tage leider nichts machen konnte habe ich gestern mal wieder etwas gebastelt und bin dabei auch ein gutes Stück weitergekommen.

Das Entschlüsseln einer empfangenen Nachricht und erneutes "Einspeisen" dieser Nachricht in FHEM funktioniert ja schon und gestern abend habe ich es dann geschafft eine unverschlüsselte Nachricht mit dem Supported_Get, "abzufangen", zu verschlüsseln und dann verschlüsselt zu verschicken. Das Gerät hat auch brav die verschlüsselte Nachricht mit dem Supported_Report zurückgeschickt, das Parsen dieser Antwort ist dann als nächstes dran, das sollte aber einfach zu erledigen sein, die Routine für das Parsen der normalen Befehlsklassen existiert ja schon, die muss ich nur kopieren und ein wenig anpassen.

Mit der Liste der unterstützten verschlüsselten Klassen aus dem Supported_Report kann ich dann ein Attribut "secure_Classes" füllen, aus dem ich dann abfragen kann ob ich die Nachricht abfangen und verschlüsseln muss, momentan ist da nur der "Supported_Get" fest codiert... Hier muss ich allerdings einige Sonderfälle bei der SECURITY-Class selbst beachten.

Sobald das mit der Liste implementiert habe wäre das schon mal soweit funktionsfähig, wobei ich vor allem mit dem Ablauf der Initialisierung noch alles andere als Glücklich bin. Der Code ist momentan auch noch überfrachtet mit Logmessages und ist an vielen Stellen auch noch verbesserungswürdig...

Sobald ich dann da mal etwas aufgeräumt habe könnte ich dann mal eine Version zum Antesten zur Verfügung stellen, wobei das ganze momentan nicht auf der aktuellsten Version von FHEM basiert.

Gruß,
Andreas.

Hallo,

noch mal ein kleines Update:

Die Implementierung ist prinzipiell geschafft! Das mit der Liste der zu verschlüsselnden Klassen hat jetzt auch funktioniert und läuft bei mir schon mal.

Der Code ist aber noch reichlich unaufgeräumt und muss an einigen Stellen noch etwas bearbeitet und höchstwahrscheinlich auch geändert werden. Ich werde da noch ein wenig aufräumen, mehr Sicherheitsabfragen etc. einbauen und evtl. auch die eine oder andere Funktion noch mal umschreiben, sowie das ganze mal mit dem aktuellen Stand von FHEM abgleichen, meine Implementierung beruht nämlich auf einem alten Stand noch vor den ganzen Problemen mit SourceForge.

Edit: Anscheinend gab es in der Zwischenzeit gar keine Updates für 10_ZWave.pm, d.h. an der Stelle muss ich das Ganze jetzt doch nicht mehr anpassen... (Version 8955)

Ich bin mir auch recht sicher das ich im Code gegen ein paar "Richtlinien" verstosse... Das muss ich mit Rudi nach seinem Urlaub mal abklären.

Gruß,
Andreas.

Ich verfolge diesen thread schon eine Weile und freue mich schon den Code auszuprobieren  :)
Gute Arbeit soweit. Habe hier bisher nur ein Zwave Gerät (Danalock).

Hi Darkscout!

Zitat von: darkscout am 07 August 2015, 20:25:00
Ich verfolge diesen thread schon eine Weile und freue mich schon den Code auszuprobieren  :)
Gute Arbeit soweit. Habe hier bisher nur ein Zwave Gerät (Danalock).

ist das Schloß denn bereits verbaut oder ist es zum Testen verfügbar?
Ich habe Krikan eine Vorabversion zum Testen gegeben und das hat natürlich erst mal alles so gar nicht funktionieren wollen... Von daher wäre es vielleicht keine gute Idee ein eingebautes Schloss zum Testen zu nutzen. :-)

Hast Du das Schloss bereits mit ZWave in FHEM ausprobiert? Das Ding müsste ja ein FLIRS (also Frequent Listening) Gerät sein, keine Ahnung ob von Seiten des Controllers oder von FHEM aus irgendetwas besonderes gemacht werden müsste.

Wäre nett wenn Du mal kurz schreiben könntest ob und wie das Ding momentan mit FHEM und ZWave zusammenarbeitet und ob das Ding zum Testen nutzbar wäre.

Gruß,
Andreas.

Zitatist das Schloß denn bereits verbaut oder ist es zum Testen verfügbar?
Ich habe Krikan eine Vorabversion zum Testen gegeben und das hat natürlich erst mal alles so gar nicht funktionieren wollen... Von daher wäre es vielleicht keine gute Idee ein eingebautes Schloss zum Testen zu nutzen. :-)

Hast Du das Schloss bereits mit ZWave in FHEM ausprobiert? Das Ding müsste ja ein FLIRS (also Frequent Listening) Gerät sein, keine Ahnung ob von Seiten des Controllers oder von FHEM aus irgendetwas besonderes gemacht werden müsste.

Wäre nett wenn Du mal kurz schreiben könntest ob und wie das Ding momentan mit FHEM und ZWave zusammenarbeitet und ob das Ding zum Testen nutzbar wäre.

Das Schloß ist schon verbaut und wird derzeit per Bluetooth genutzt. Habe es mal per Zwave versucht anzulernen an FHEM (mit Z-Wave ZME_UZB1 Me USB Stick). Gerät wird erkannt (ZWave_ENTRY_CONTROL) aber sonst ist nicht viel möglich.

UNPARSED SECURITY 029840
battery 64 %
model Polycontrol Danalock Circle/Square
modelConfig polycontrol/doorlock.xml
modelId 010e-0003-0002
state TRANSMIT_NO_ACK
transmit OK
version Lib 3 Prot 2.78 App 2.4

classes MANUFACTURER_SPECIFIC BATTERY VERSION SECURITY


Seit heute habe ich noch ein "Devolo Home Control - Tür/Fensterkontakt" auch mit Security attribut. Er funktioniert auch einwanfrei ohne Security. Der liegt zum testen bereit auf meinem Schreibtisch.

Als Info - ich bin Software Entwickler. Eher C++, Java und C# aber Perl geht auch  ::)

Hi Darkscout,

Zitat von: darkscout am 08 August 2015, 15:19:01
Das Schloß ist schon verbaut und wird derzeit per Bluetooth genutzt. Habe es mal per Zwave versucht anzulernen an FHEM (mit Z-Wave ZME_UZB1 Me USB Stick). Gerät wird erkannt (ZWave_ENTRY_CONTROL) aber sonst ist nicht viel möglich.

Code Auswählen Erweitern

UNPARSED SECURITY 029840
[...]
classes MANUFACTURER_SPECIFIC BATTERY VERSION SECURITY


Klar, Security wird nicht unterstützt und die "richtigen" Klassen tauchen erst auf nachdem SECURITY aktiv ausgehandelt wurde. Da nimmt Danalock das aber wirklich ernst mit Security (bei einem Türschloss aber auch gut so...), bei den "normalen" Geräten funktionieren zumindest die Basisklassen ja meist auch ohne Security.

Zitat von: darkscout am 08 August 2015, 15:19:01
Seit heute habe ich noch ein "Devolo Home Control - Tür/Fensterkontakt" auch mit Security attribut. Er funktioniert auch einwanfrei ohne Security. Der liegt zum testen bereit auf meinem Schreibtisch.

Als Info - ich bin Software Entwickler. Eher C++, Java und C# aber Perl geht auch  ::)

Ich hänge gleich mal die aktuelle Version an den ersten Post in diesem Thread an, wenn Du magst kannst Du ja mal antesten was bei Dir passiert. Mit der letzten Änderung funktioniert das einbinden der KFOB_S Fernbedienung bei Krikan schon mal soweit, allerdings gibt es dann anscheindend Probleme damit, dass die FB natürlich ein Wake-Up Gerät ist und die Antworten mit der NONCE irgendwie im Sendstack liegenbleiben und dann keine Kommunikation mehr stattfindet... Daher könnte es sein das Du mit dem Tür-/Fensterkontakt da auch erst einmal nicht sehr weit kommst.

Das Schloss sollte FLIRS machen und sich eigentlich wie ein "normales" Geräte verhalten, das Risiko muss Du selber abschätzen falls sich da was in der Kommunikation verabschiedet... (Ich geh' mal davon aus das Du es momentan über Bluetooth bedienst, oder?)
Der Test könnte aber spannend werden, für die Kommunikation müssen für jeden Befehl sogenannte NONCE Werte ausgetauscht werden, der in Deinem Log aufgetauchte "UNPARSED SECURITY 029840" ist so eine Anfrage für eine NONCE. Es gibt in der Befehlsliste noch einen Befehl der darauf schliessen lässt das es hier auch eine verschlüsselte Version dieser Übertragung geben könnte, das ist aber selbst in OpenZWave nicht implementiert. Falls das Danalock sowas nutzt wird es richtig spannend, das rauszubekommen geht dann nur mit Try-and-Error (und viel Glück...)

Ach ja, Einbinden mit Security geht nicht über das Menü sondern nur über die "Kommandozeile":

set <ZWDongle-Device-Name> addNode on sec

Gruß,
Andreas.

Hi,

eine erste Testversion für Mutige ist jetzt im ersten Post dieses Thread angehängt.

Gruß,
Andreas.

Hallo Rudi,

mal eine Frage zu dem Sendstack für die Wake-Up Geräte:

Kann es sein das die dort gespeicherten Nachrichten nur gesendete werden wenn eine Wake-Up-Notification eintrifft, und nicht auch wenn das Gerät einfach so sendet?

Ich bin mir da unsicher ob ein Gerät so eine Wake-Up Notification schicken soll wenn es per Timer aufwacht, also einfach nur mal horcht ob was für ihn anliegt oder auch wenn es z.B. auf den Tastendruck reagiert und sowieso auch aktiv eine Nachricht verschickt. Im Logfile von Krikan kommen Nachrichten mit einer Nonce-Request vom der KFOB ohne das ich Wake-Up Notifications erkennen kann, die Nonce-Antworten landen dann aber alle im Sendstack und werden auch nach dem Eintreffen des nächsten Nonce-Request nicht verschickt.

Bei meinem RFID Leser scheint es so zu sein das der mir erst die Nachricht schickt das ein RFID-Tag erkannt wurde und DANACH (< 1sek)  dann eine Wake-Up-Notification. Da ist aber auch so einiges merkwürdig im Logfile.

Wenn meine erste Analyse so richtig ist, fürchte ich das wir da einiges umstellen müssen. Würde es helfen wenn ich beim Eintreffen eines Nonce-Request den lastMsgTimestamp setze?
$hash->{lastMsgTimestamp} = time();
Damit müsste ich dann ja eigentlich den Sendstack umgehen, oder?

Gruß,
Andreas.

Hallo,

ich habe den angesprochenen kleinen Hack mit dem Setzen des Zeitstempels einfach mal eingebaut und bei ersten Tests von Krikan mit dem KFOB funktioniert es damit schon mal ohne offensichtliche Probleme.

Ob das alles so bleiben kann wird sich im Laufe der Zeit zeigen, ich denke es kann mit der Version aus Post #1 getestet werden, ich würde aber empfehlen das erst einmal nur auf einem Testsystem zu machen. Die aktualisierte Fassung von 10_ZWave.pm (basierend auf 9041) habe ich wie gesagt an Post #1 angehängt.

Gruß,
Andreas.

Hallo,

bei der Implementierung der SECURITY Class treten jetzt die ersten "Folgeprobleme" auf... :-)

Nach der secure-Inclusion tauchen Befehlsklassen auf, die noch nicht in FHEM implementiert sind...
Aktuell gibt es hier z.B. das DanaLock, das nach secure-Inclusion
secure_classes  DOOR_LOCK USER_CODE SCHEDULE_ENTRY_LOCK CONFIGURATION TIME MANUFACTURER_SPECIFIC BATTERY VERSION MARK
meldet...

Die Klassen:
DOOR_LOCK
SCHEDULE_ENTRY_LOCK
werden zur Zeit noch nicht von FHEM unterstützt, für DOOR_LOCK gibt es zumindest eine Dokumentation für eine Version V1 (aktuell scheint aber V3 zu sein...), für SCHEDULE_ENTRY_LOCK habe ich bisher nichts an Dokumentation gefunden.

Die Implementierung von SECURITY ist hier dann nur der erste Schritt, die zusätzlichen Klassen müssen dann auch noch implementiert werden damit die Geräte auch funktionieren.

DOOR_LOCK könnte ich mir in V1 mal ansehen, für höhere Versionen müsste man mal schauen was z.B. in OpenZWave bereits implementiert ist. Gleiches gilt für SCHEDULE_ENTRY_LOCK, wenn es in OpenZWave implementiert ist hat man Chancen sich das da herauszupicken was man braucht, ansonsten ist das ohne Doku der Klasse sehr mühsames Try-and-Error...

Da ich momentan noch mit dem Aufräumen des Codes für SECURITY beschäftigt bin und die Implementierung ja auch noch nicht von Rudi "abgesegnet" ist, kann ich da erst mal nicht so viel Zeit in neue Klassen stecken.

Wer hier also an DOOR_LOCK oder SCHEDULE_ENTRY_LOCK arbeiten möchte, dem kann ich gerne meine Informationen zur Verfügung stellen, ansonsten muss das noch warten bis wieder Zeit dafür ist.

Gruß,
Andreas.

Hallo,

habe mal ganz grob mit DOOR_LOCK V1 angefangen... Falls jemand noch Informationen zu V2 oder V3 haben sollte bitte melden, ein kurzer Blick in OpenZWave ergibt für mich da auch nur eine V1.

Gruß,
Andreas.

Hallo Andreas,

Danke für deine Arbeit an der DOOR_LOCK Implementierung, ich hoffe dass sich hier noch ein wenig mehr Dokumentation finden wird. Ich habe bisher KeyMatic verwendet gehabt, jedoch nach einem Motorschaden kein Vertrauen mehr in das System. Jetzt bin ich auf DanaLock gestoßen und habe bei der Recherche (habe gerade bei DanaLock angerufen) festgestellt, dass es wohl verschiedene Versionen davon gibt. Bisher in Deutschland mit Z-WAVE verfügbar ist nur die "ganz alte Version", bspw. gerade bei Amazon mit der Kennung POL_BTZEC100. Laut Aussage der Mitarbeiterin kommt Ende August in Deutschland auch die neue Version (POL_BTZE125?) heraus wie man sie bereits bei Danalock US (https://danalock.com/?page_id=773) findet. Zwischen der alten Version, der aktuell offiziell in DE verfügbaren Version mit Bluetooth (POL_BT125 (https://danalock.com/?page_id=1064)) und der neuen Version mit BT & Z-WAVE hat sich laut der Mitarbeiterin von Danalock einiges intern getan. Eine Vermutung von mir ist, dass hieraus auch die 3 verschiedenen Versionen von DOOR_LOCK resultieren.

Hallo,

kleiner Bug-fix...

ZitatBei Test mit einem Tür-/Fensterkontakt von DarkScout und Krikan traten weitere Probleme auf, hier wurde die Antwort mit den zu verschlüsselnden Klassen nicht richtig dekodiert und daher nicht akzeptiert. Problem lag an einer falschen Berechung der Blocklänge, ein Bug ist gefunden und damit (hoffentlich) gefixt.

Bei der ganzen Verschlüsselung müssen die Daten immer auf Blocklänge aufgefüllt werden, bei der Routine zum Auffüllen auf diese Blocklänge hatte ich leider einen kleinen Gedankenfehler drin. Die Antwort des Devices von DarkScout und Krikan (sind wohl baugleiche Sensoren von verschiedenen OEM) hatte genau die erforderliche Blocklänge, ich habe jedoch durch meinen Bug noch einen Block voll mit '00' angehängt.

Code ist geändert, an Post #1 ist die aktualisierte Version angehängt.

Gruß,
Andreas.

Hi,

Zitat von: alexschomb am 13 August 2015, 14:20:57
Danke für deine Arbeit an der DOOR_LOCK Implementierung, ich hoffe dass sich hier noch ein wenig mehr Dokumentation finden wird.

Bisher ist da noch nicht viel passiert. Die Befehle die in V1 definiert sind jetzt auch nicht sooo umfangreich. Ich bin mir nicht sicher wie "weit" man mit der V1 bei dem DanaLock kommt. Die Versionen sind immerhin immer abwärtskompatibel, d.h. auch wenn das DanaLock eine V3 hat, so muss es die Befehle von V1 weiterhin unterstützen.

Zitat von: alexschomb am 13 August 2015, 14:20:57
Jetzt bin ich auf DanaLock gestoßen und habe bei der Recherche (habe gerade bei DanaLock angerufen) festgestellt, dass es wohl verschiedene Versionen davon gibt. Bisher in Deutschland mit Z-WAVE verfügbar ist nur die "ganz alte Version", bspw. gerade bei Amazon mit der Kennung POL_BTZEC100. Laut Aussage der Mitarbeiterin kommt Ende August in Deutschland auch die neue Version (POL_BTZE125?) heraus wie man sie bereits bei Danalock US (https://danalock.com/?page_id=773) findet. Zwischen der alten Version, der aktuell offiziell in DE verfügbaren Version mit Bluetooth (POL_BT125 (https://danalock.com/?page_id=1064)) und der neuen Version mit BT & Z-WAVE hat sich laut der Mitarbeiterin von Danalock einiges intern getan. Eine Vermutung von mir ist, dass hieraus auch die 3 verschiedenen Versionen von DOOR_LOCK resultieren.

Die Versionen von DOOR_LOCK nicht direkt was mit den Versionen des DanaLock zu tun. Die werden vom ZWave-Konsortium festgelegt, allerdings teilweise auf Anforderung der Kunden/Hersteller. Es kann also durchaus sein das einige Funktionen die DanaLock implementieren wollte in die ZWave Definition gekommen sind.

Ohne weitere Doku oder Mitschnitte von anderen Systemen die schon V2 oder V3 unterstützen sehe ich da keine große Hoffnung da mehr zu implementieren. Das ist immerhin ein recht teures Gerät was man durch rumprobieren an unbekannten Parametern durchaus (mechanischen) Schaden nehmen könnte...

Aber erst mal abwarten wie weit ich mit der V1 komme, SECURITY hat da erst noch Priorität.

Gruß,
Andreas.

Hallo,

ein Problem gelöst, schon ist das nächste da...
Das Testgerät nutzt nun leider einen Befehl (SecurityCmd_MessageEncapNonceGet = 0xc1) den ich noch nicht kenne, und der deshalb auch nicht implementiert ist.

Ich hoffe ich werde da auch bei OpenZWave fündig.

Gruß,
Andreas.

Hallo,

noch mal ein kleines Update, Befehle mit SecurityCmd_MessageEncapNonceGet (98c1) werden nun auch verarbeitet. Es hat sich herausgestellt das dies ein kombinierter Befehl ist, es wird eine verschlüsselte Nachricht verschickt, gleichzeitig wird mit dem Befehl die NONCE für die nächste angefordert. Das spart einen Befehl und verringert den ohnehin schon recht hohen overhead für SECURITY...

Allerdings gibt es noch merkwürdige Kommunikationsprobleme mit dem Testgeräte von Krikan (bzw. DarkScout, baugleiche Geräte). Anscheinend werden dort get-Befehle an verschlüsselte Klassen nicht verarbeitet und es gibt unbekannte Rückmeldungen vom Gerät.

Meine erste Analyse der Logfiles von Krikan hat leider noch keinen Anhaltspunkt bzw. Grund für dieses Verhalten oder für die unbekannte Rückmeldung ergeben.

Falls noch jemand Geräte mit Unterstützung für SECURITY hat und bereit wäre das mal anzutesten würde das schon mal helfen zu unterscheiden ob es ein geräteabhängiges Problem oder ein generelles Problem ist.

Gruß,
Andreas.

Hallo,

ich denke ich habe schon mal die Ursache für das merkwürdige Verhalten und die unbekannten Rückmeldungen gefunden. Das Device sendet eine so lange Multi-CMD Nachricht, das diese auf zwei verschlüsselte Nachrichten aufgeteilt werden muss.

Hier muss ich also die Nachrichtenteile erst zwischenspeichern und zusammenbauen und dann erst parsen lassen. Aktuell wird hier jede Nachricht einzeln sofort entschlüsselt und neu geparsed. Der "Rest" der Nachricht im zweiten Paket ergibt dann diese unbekannte Rückmeldung...

Ursache scheint also gefunden zu sein, Lösungsansatz existiert schon, ist aber noch nicht umgesetzt.

Gruß,
Andreas.

Hallo,

Status Update:

Lange Nachrichten (mit 98c1 Header) werden jetzt sauber verarbeitet.

Mein kleiner Hack um auf die NONCE-Request Anfragen von Wake-Up-Geräten zu antworten hatte wohl doch Nebeneffekte, da es Allgemein galt, und so auch andere Befehle am SendStack vorbei an das Gerät gelangt sind. Hier habe ich das ganze jetzt so angepasst, das nur die Antworten auf NONCE-Requests am Sendstack vorbei antworten können.

Aktuell arbeite ich gerade daran die zu verschlüsselnden Nachrichten zwischenzuspeichern, dies ist nötig wenn mehrere Befehle hintereinander ankommen, besonders natürlich wenn das Gerät ein Wake-Up Gerät ist und eingeschlafen ist. Hier muss aber noch getestet werden um zu sehen ob das ganze auch so funktioniert wie beabsichtigt.

Sobald wieder eine getestete Version ohne auffällige Probleme existiert, werde ich die wieder zum Testen an den Post #1 anhängen.

Leider tauchen bei den Tests immer wieder recht viele CAN (Cancel-) Messages auf. Als Ursache vermute ich hier die fehlende Kontrolle von FHEM über die noch "offenen" Antworten und die damit verbundene Möglichkeit, bereits neue Befehle an ein Gerät zu schicken, obwohl die letzte Abfrage noch nicht beendet wurde (also noch auf eine Antwort gewartet wird). Hier sind wir aber noch am Anfang der Analyse.
Dies ist mMn kein Problem das direkt mit den Änderungen für die SECURITY Implementierung zu tun hat, sondern die SECURITY Kommunikation ist in diesem Fall leider empfindlicher, da hier deutlich mehr zusammenhängende Nachrichten verschickt werden müssen, die nicht "gestört" werden dürfen.

Die noch fehlende Zwischenspeicherung der Nachrichten und die Nebeneffekte bei der Umgehung des Sendstacks haben dieses Problem auf jeden Fall deutlich verschlimmert. Hier muss sich jetzt erst einmal zeigen wie das ganze mal läuft wenn diese Probleme jetzt behoben sein sollten.

Gruß,
Andreas.

Hallo,

so, nochmal eine Rückmeldung:

Es gibt gute Nachrichten und es gibt schlechte Nachrichten...
Die gute Nachricht ist: Security funktioniert und tut das was es soll!
Die schlechte Nachricht ist: Security Nachrichten sind sehr empfindlich gegen Störungen im Kommunikationsablauf

Um das zu erklären muss ich jetzt leider ein wenig weiter ausholen... (und das Thema dann wahrscheinlich in einen neuen Thread verlagern, da es nicht direkt etwas mit SECURITY zu tun hat)

Im wesentlichen muss man bei ZWave zwischen SET- und GET-Befehlen unterscheiden. SET-Befehle senden Daten ohne eine Antwort darauf zu erwarten (Lampe einschalten, Config Parameter setzen, ....), die GET-Befehle senden eine Anfrage und erwarten darauf eine Antwort (Report) (Config auslesen, Status auslesen, ...).

Die Kommunikation von ZWave ist nun mMn so festegelegt das immer nur eine "offene" Kommunikation vorhanden sein darf. Das bedeutet das man nach einer Anfrage erst die Antwort abwarten muss, bevor man einen weiteren Befehl verschicken darf. (Auf Controller-Ebene muss auch noch mal alles bestätigt werden, das hat hier mMn, aber keinen Einfluss)
Eine derartige Abfrage ist in ZWave aktuell (noch) nicht implementiert, d.h. es wird nicht aktiv auf die Antwort gewartet bevor die nächste Nachricht verschickt wird.

Eine normale GET-Abfrage sieht demnach so aus: Controller sendet GET ---warten---> Node sendet Report

Wird nun, während auf die Antwort gewartet wird, eine weitere Nachricht erzeugt, so wird diese laufende Übertragung gestört. Dies wird von der Node normalerweise erkannt und mit einer Cancel-Message beantwortet.

Im Fall von Wake-Up-Geräten werden die Befehle auf einem Stack gespeichert bis das Gerät sich wieder meldet. Die Befehle werden dann alle direkt (ohne Pause) nacheinander abgearbeitet. Wenn man jetzt davon ausgeht das es zwei GET-Befehle auf dem Stack gibt, passiert in etwa das folgende:

Controller sendet GET #1 ---> Controller sendet GET #2 ---> Node sendet CANCEL für GET #2 ----> Node sendet Report #1 ---> Controller sendet GET #2 nochmal ---> Node sendet Report #2

Das Ganze kann sich noch "verschlimmern" wenn der Controller seinen zweiten Sendeversuch macht bevor die Antwort auf den ersten GET-Befehl eintrifft, dann gibt es noch mal eine Cancel-Nachricht und einen weiteren Versuch. Hier wird in der Regel die Kommunikation durch das erneute Verschicken irgendwann trotzdem funktionieren, zumindest solange bis die maximale Anzahl an Wiederholungen noch nicht erreicht ist.

Das Problem bei den Security-Nachrichten ist nun das die Kommunikation deutlich länger ist und mehrere GET-REPORT Übertragungen benötigt, da für jede Verschlüsselung eine neue NONCE (eine Art Einmal-Code) angefordert werden muss.
Aus dem einfachen GET-REPORT oben wird nun:
Controller sendet GET-NONCE ---warten---> Node sendet NONCE-REPORT ---warten---> Controller sendet verschlüsselten GET-Befehl ---warten---> Node sendet GET-Nonce ---warten---> Controller sendet NONCE-REPORT ---warten---> Node sendet verschlüsselten Report

Hier gibt es also bereits 5 Stellen an denen auf eine entsprechende Rückmeldung gewartet werden muss und die Übertragung durch einen weiteren Befehl gestört werden kann.
Einige der verschlüsselten Nachrichten sind nun sogar so lang, das sie auf zwei Nachrichten aufgeteilt werden, d.h. es kommen dann noch mal 2 weitere GET-REPORTS dazu, sodass dann 7 Übertragungen vorhanden sind die gestört werden könnten.

Es ist nun leicht vorstellbar das zwei solcher Befehle direkt hintereinander versandt, zu  jede Menge Cancel-Messages bis hin zum Datenverlust (irgendwann gibt anscheinend sowohl der Controller als auch die Node auf...) führen. Ich habe von Krikan ein (langes) Logfile, indem das deutlich zu erkennen ist.

(Mein) Fazit hieraus:
a.) die Security Implementierung an sich funktioniert einwandfrei
b.) die fehlende Kontrolle über den Nachrichtenfluss führt jedoch aktuell zu einer sehr anfälligen Kommunikation mit Verlust von Nachrichten
c.) die Umstellung beim Senden/Empfangen auf eine gesteuerte Form des Sendestacks (ähnlich wie bei OpenZWave) erscheint mir unumgänglich zu sein

Für diese Umstellung wäre mMn ein recht umfangreiches Re-Design des bisherigen ZWave-Codes nötig, was natürlich eine größere Baustelle wäre. Andererseits ist der momentane Ablauf nicht wirklich konform mit dem ZWave-Protokoll und hat ja an der einen oder anderen Stelle bereits ein paar kleine Workarounds erforderlich gemacht und kann bereits bei normalen Befehlen zu CANCEL Messages führen.

Ohne solch eine Umstellung erscheint mir Security nicht sinnvoll einsetzbar, da die Wahrscheinlichkeit von Datenverlust hier doch extrem hoch ist.

Die Implementierung von OpenZWave habe ich mir noch nicht so genau angesehen, anscheinend wird dort aber bei jeder versendeten Nachricht neben der Callback-ID bereits die erwartete Antwort (Klasse und Befehl) gespeichert um das für die "Freigabe" der nächsten Kommunikation zu nutzen.

@Rudi: Wie ist Deine Einschätzung hierzu? Ich denke Du verstehst die Problematik mit dem Ablauf, wenn nicht, kann ich mal ein kommentierten Ausschnitt aus Krikans Log erstellen und posten. Ich bin mir bewusst das ich hier ein "Fass" aufmache, denke aber das es sinnvoll und nötig ist das umzustellen.

Ich werde den aktuellen Code für Security wieder im Post #1 anhängen, es kann ja jeder mal damit testen und vielleicht auch mal zurückmelden ob im "realen" Betrieb wirklich Datenverluste auftreten oder ob das System sich mit Cancel-Messages und Retries "retten" kann.

Gruß,
Andreas.

P.S.:
@DarkScout: Wenn Du "mutig" bist, dort sind auch schon mal zwei GET-Befehle für DOOR_LOCK drin. An Logs dazu wäre ich interessiert...

Hallo,

nicht das der letzte Post jetzt zu negativ klingt, es geht auf jeden Fall weiter ,-)

Ich habe mal eine Version gebaut bei der zumindest der WakeUpStack jetzt mit Hilfe eines Timer "geleert" wird, das sollte die Kollisionen der Nachrichten untereinander verhindern oder zumindest vermindern. Falls das funktioniern sollte hätten wir schon mal einen Workaround.

Sobald das getestet ist werde ich das Ergebnis hier kundtun.

Gruß,
Andreas.

Hallo,

die Testversion mit dem Timer für das abarbeiten des Stacks funktioniert soweit schon mal, es gehen aber gelegentlich immer noch Nachrichten verloren.

Bisher konnte ich hier drei Gründe feststellen:
- während des Abarbeitens des Stacks kommen Nachrichten vom Gerät
- während des Abarbeitens des Stacks wird zufällig eine neue Nachricht von FHEM bzw. dem Benutzer erzeugt
- es wird eine WakeUp-NoMoreInformation erzeugt bevor der Stack abgearbeitet ist bzw. noch ausstehende Antworten eingetroffen sind.

Um das Verhalten etwas zu verbessern müsste ich etwas am Ablauf nach der WakeUp-Notification und der Erkennung auf Inaktivität und aktivierung des Sendstacks ändern.

Hierzu habe ich allerdings eine Frage zu ZW_APPLICATION_UPDATE.

In der Funktion ZWave_Parse wird bei einer WakeUp-Notification (8407) das Senden aus dem Sendstack ausgelöst. Bei einem ZW_APPLICATION_UPDATE Befehl wird dies allerdings auch gemacht, und das kann ich nicht nachvollziehen.

Wozu ist dieser Befehl gut und was für Informationen stecken da drin?
Ist es wirklich nötig das hier der Sendstack angetriggert wird? Mir scheint das nicht "konform" mit dem Protokoll zu sein, aber da ich ZW_APPLICATION_UPDATE nicht kenne, frage ich lieber mal nach bevor ich soetwas komplett umbaue oder sogar ausbaue.

Also Kurzfassung: Was macht ZW_APPLICATION_UPDATE und warum wird der Sendstack abgearbeitet wenn der Befehl ankommt?

Gruß,
Andreas.

Hallo,

und gleich noch mal eine Frage in die Runde:

In diesem Ausschnitt aus einem Log wird bei 2015.08.24 22:32:11.545 ein Befehl ausgelöst, den meine Routinen "abfangen" und stattdessen eine NONCE vom Gerät anfordern. Das funktioniert normalerweise einwandfrei, an dieser Stelle wird mMn der Befehl ordnungsgemäß verschickt, mit ACK bestätigt und auch per "011301" der Versand bestätigt, dennoch antwortet das Device für 3 Sekunden nicht...

2015.08.24 22:32:09.312 2: ZWave_Parse: msg: 000400020a8f0101063105010a0053
2015.08.24 22:32:09.312 4: ZWDongle_1 CMD:APPLICATION_COMMAND_HANDLER ID:02 ARG:0a8f0101063105010a0053

2015.08.24 22:32:11.545 2: ZWave get ZWave_GARAGE_DOOR_2 configAutoReportTemperatureTime
2015.08.24 22:32:11.546 2: ZWave set ZWave_GARAGE_DOOR_2 secNonce
2015.08.24 22:32:11.546 5: ZWDongle_Write 00 13020298402502
2015.08.24 22:32:11.546 5: SW: 010900130202984025021a
2015.08.24 22:32:11.564 5: ACK received, removing 010900130202984025021a from sendstack
2015.08.24 22:32:11.564 4: ZWDongle_Read ZWDongle_1: sending ACK, processing 011301
2015.08.24 22:32:11.565 5: SW: 06
2015.08.24 22:32:11.576 5: ZWDongle_1 dispatch 011301
2015.08.24 22:32:11.576 2: ZWave_Parse: msg: 011301

2015.08.24 22:32:14.826 2: ZWave get ZWave_GARAGE_DOOR_2 configAutoReportTemperatureTime
2015.08.24 22:32:14.827 2: ZWave set ZWave_GARAGE_DOOR_2 secNonce
2015.08.24 22:32:14.827 0: Device not awake (dt= 4.68778204917908), command (13020298402502) stored in sendstack
2015.08.24 22:32:15.826 4: ZWDongle_Read ZWDongle_1: sending ACK, processing 0013020101a6
2015.08.24 22:32:15.826 5: SW: 06
2015.08.24 22:32:15.841 5: ZWDongle_1 dispatch 0013020101a6
2015.08.24 22:32:15.842 2: ZWave_Parse: msg: 0013020101a6
2015.08.24 22:32:15.842 4: ZWDongle_1 CMD:ZW_SEND_DATA ID:01 ARG:01a6
2015.08.24 22:32:15.842 2: ZWDongle_1 transmit NO_ACK for 02

2015.08.24 22:32:20.748 4: ZWDongle_Read ZWDongle_1: sending ACK, processing 00040002028407


Hat irgendjemand eine Idee warum das Ding da keine Antwort gibt und/oder was 001302 für eine Antwort ist die dann 5 Sekunden später ankommt?

Anschliessend gibt es noch ein NO_ACK , ab der nächsten WakeUp-Notification bei 2015.08.24 22:32:20.748 funktioniert dann erst mal wieder alles.

Gruß,
Andreas.

Hallo,

zum Thema ZW_APPLICATION_UPDATE habe ich jetzt das hier gefunden: (wieso findet man sowas über Google besser als über die Forumssuche?)

Hat das Verhalten außer Hanske noch jemand beobachten können? Ich selbst habe leider nur ein WakeUp-Gerät, das steht aber für Tests nicht zur Verfügung. Auch mit der Erklärung finde ich das weiterhin merkwürdig...

Zitat von: hanske am 05 Dezember 2014, 21:03:03
Hallo,

der Patch läuft immer noch ohne Probleme und ich würde mich freuen, wenn er mit in das Release käme.
Man sollte allerdings auch bei "ZW_APPLICATION_UPDATE" den ganzen Stapel abarbeiten.

Ich hatte gerade einen neuen Sensor eingerichtet und gleich eine ganze Menge Setting abgesetzt.
Leider hatte ich nicht als erstes das Wakeupinterval und den Empfängerknoten angegeben.

Ich habe dann manuell Wakeups ausgelöst, die aber nur als  "ZW_APPLICATION_UPDATE" ankamen.
Es wurde dann aber immer nur ein gespeicherter Befehl abgesetzt.
Ich habe dann das foreach aus dem Wakeup auch dorthin kopiert und schon lief es perfekt.

Also, es wäre schön wenn das mal in das Release kommt, dann kann ich auch wieder updaten ;-)

Gruß,
Andreas.

Hallo,

an Post #1 ist wieder eine aktualisierte Testversion angehängt.

ZitatDie Befehle werden jetzt per Timer und einer "Pause" vom WakeUp-Stack geholt und verschickt. Aktuell wird hier zwischen verschlüsselten und unverschlüsselten Befehlen unterschieden. Da auch unverschlüsselte Nachrichten prinzipiell von dem Problem betroffen sind gibt es hier 0.5 Sekunden Abstand bevor die nächste Nachricht verschickt wird, bei verschlüsselten wird 1.5 Sekunden Abstand genutzt. Hierdurch konnten die Kollisionen schon sehr wirkungsvoll verhindert werden.

Kleine Bemerkung: Falls bei den Tests Nachrichten verlorengehen (kann ich leider nicht völlig verhindern), so können evtl. Befehle im Reading secMsg "übrigbleiben" welche nicht mehr automatisch abgearbeitet werden. Hier kann man entweder
set <gerätename> secNonce
aufrufen und damit einen Befehl aus der Liste abarbeiten, oder man löscht das Reading mit
deletereading <gerätename> secMsg

Momentan ist das Versenden der WakeUp-NoMoreInformation Nachricht und das Aktivieren des Sendstacks noch unabhängig voneinander gelöst, wodurch es bei (un-)passendem Timing auch zu Problemen kommen. Hier versuche ich gerade eine Lösung zu finden.

Ansonsten funktioniert das wie bereits geschrieben schon alles sehr gut!

Gruß,
Andreas.

Christian hat mich heute auf diesen Thread aufmerksam gemacht: ich habe wohl in meinem Urlaub verpasst das "Benachrichtigen" zu aktivieren, das tut mir jetzt leid. Andreas, du hast eine Menge geschafft, gratulation dafuer.

Ich habe gerade den diff zu den aktuellen ZWave.pm gemacht und (sehr schnell) ueberflogen, hier meine Bemerkungen dazu:

- bitte die letzten Aenderungen aus ZWave.pm uebernehmen, ich habe beim WAKE_UP das Senden von wakeupNoMoreInformation umgestellt, das funktioniert bei mir jetzt deutlich besser, und ich habe auch noch keine Beschwerden gehoert. Falls es damit bei dir klappt, dann sehe ich kein Problem dein Patch ins trunk aufzunehmen. Wenn nicht, dann muss ich dein Wakeup-code verstehen, und das dauert laenger :)

- wenn moeglich, bitte die Zeilenbreite auf 80 Zeichen begrenzen. Alte Marotte von mir.

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

- das Zwischenspeichern von Daten in Readings ist zwar moeglich, uch wuerde aber analog zu Wakeup diese Daten in einem Internal halten.

- ZWave_getSecMsg: falls die letze Nachricht rausgelesen wurde, dann is der Wert vom secMsg leer, was wiederum bei Readings an manchen Stellen (Wiedereinlesen der Daten aus fhem.state) problematisch ist.

- 'aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa' kann man eleganter als 'a' x 32 schreiben.

- Why CallbackId=id: ich bzw. FHEM braucht CallbackId nicht, aber die meisten ZWave Funktionen gehen von einem aus. Es gibt nur 256 moegliche Calbackids, d.h. ernsthaft kann man sie eh nicht verwenden.

Zu deinen Fragen aus dem Thread:
- Antwort #35: 001302: keine Ahnung
- Antwort #34: ZW_APPLICATION_UPDATE wird von batteriebetriebenen Geraeten gesendet, wenn man an den Knoepfen rumfummelt.

Wenn noch weitere Fragen offen sind, bitte melden.

Hallo Rudi,

Zitat von: rudolfkoenig am 27 August 2015, 22:05:54
Ich habe gerade den diff zu den aktuellen ZWave.pm gemacht und (sehr schnell) ueberflogen, hier meine Bemerkungen dazu:

- bitte die letzten Aenderungen aus ZWave.pm uebernehmen, ich habe beim WAKE_UP das Senden von wakeupNoMoreInformation umgestellt, das funktioniert bei mir jetzt deutlich besser, und ich habe auch noch keine Beschwerden gehoert. Falls es damit bei dir klappt, dann sehe ich kein Problem dein Patch ins trunk aufzunehmen. Wenn nicht, dann muss ich dein Wakeup-code verstehen, und das dauert laenger :)

Danke für die Rückmeldung, die letzten Änderungen von Dir habe ich mir noch nicht angesehen, werde ich aber nachholen. Momentan stört mich noch das der WU-Sendstack unabhängig von der WU-NoMoreInformation aktiviert wird. Ich schau mal was Du gemacht hast und überlege noch mal wie ich das vorhatte und melde mich dann noch mal deswegen.
Hast Du auch eine Anmerkung zu dem Abarbeiten des Sendstacks per Timer? Ist zwar eigentlich nur ein Workaround, wirkt aber sehr gut.

Die anderen Sachen werde ich mir ansehen und anpassen/ändern.

Wieso "nur" 256 Callback-IDs? Sobald die erwartete Antwort mit der passenden Callback-ID (und Node-ID) eingetroffen ist, kann/wird diese Callback-ID ja wieder "frei", das bedeutet das man auf maximal 256 "offene" Kommunikationen beschränkt ist, wenn man das je Node verwaltet sollte das mehr sein als man normalerweise benötigt.

Callback-IDs sind für die Nachverfolgung von Nachrichten nicht ganz unpraktisch und wahrscheinlich auch genau dafür gedacht. Hier ist immer noch die Frage nach einer besseren Ablaufsteuerung der Kommunikation so wie z.B. OZW das macht. Eine Umstellung auf einen ähnlichen Ablauf wie OZW wäre schon sehr aufwändig, aber mMn eigentlich sinnvoll.

Zitat von: rudolfkoenig am 27 August 2015, 22:05:54
- ZWave_getSecMsg: falls die letze Nachricht rausgelesen wurde, dann is der Wert vom secMsg leer, was wiederum bei Readings an manchen Stellen (Wiedereinlesen der Daten aus fhem.state) problematisch ist.

Hast Du hier evtl. auch einen Tipp wie das zu lösen wäre? Gilt das gleiche auch für Internals?

Zitat von: rudolfkoenig am 27 August 2015, 22:05:54
- Antwort #34: ZW_APPLICATION_UPDATE wird von batteriebetriebenen Geraeten gesendet, wenn man an den Knoepfen rumfummelt.

"Darf" man denn dann auch einfach was senden? Normalerweise senden WU-Geräte ja auch eine WU-Notification wenn Sie Ihre Meldung gemacht haben (Bewegungsmeldung, etc.).
Bei "Hanske" hat es zwar funktioniert, aber "richtig" finde ich das nicht...

So, dann mach' ich mal meine Hausaufgaben und versuche das schon mal in Richtung Patch anzupassen und aufzuhübschen.

@ALL: Es darf/sollte getestet werden, ein paar zusätzliche Rückmeldungen bzgl. Testergebnissen wären nicht schlecht... Bisher hat hauptsächlich Kirkan (Danke!) getestet, ein paar Sachen habe ich auch mit DarkScout ausprobiert, das waren aber baugleiche Geräte, ein paar mehr verschiedene Geräte wären nicht schlecht.

Gruß,
Andreas.

ZitatHast Du auch eine Anmerkung zu dem Abarbeiten des Sendstacks per Timer?

Wie geschrieben, das habe ich noch nicht tiefer angeschaut. Ich bin auch nicht sicher, ob meine aktuelle Version perfekt ist, funktioniert bei mir aber auch gut, und sendet sofort, wenn es moeglich ist, die Kommunikation sollte also schneller ablaufen.

Zitatauf maximal 256 "offene" Kommunikationen beschränkt ist

Sage ich doch: nur.  Mir ist das "wozu" noch nicht klar, ich kenne jedenfalls noch keinen konkreten Fall, wo es mir helfen wuerde. Evtl. ist das wg. SEC anders.

ZitatHast Du hier evtl. auch einen Tipp wie das zu lösen wäre?

Indem man das Reading loescht, fallst nichts mehr drin ist.

ZitatGilt das gleiche auch für Internals?

Nein. Dafuer geht der Inhalt verloren, wenn man FHEM nau startet. Ob das gut oder schlecht ist, weiss ich nocht nicht.

ZitatNormalerweise senden WU-Geräte ja auch eine WU-Notification wenn Sie Ihre Meldung gemacht haben

Nicht nach meiner Erfahrung. Ein batteriebetriebenes Geraet kann stundenlang senden, ohne dass es auf Empfang geht. Nur nach manuellen stimulieren oder konfigurierten wake_up nimmt es Befehle entgegen.

0013020101a6  aus Antwort #35 / CallbackIDs
001302xx sind die Rückgabewerte der Callbacks zu ZW_SEND_DATA. xx steht für das Ergebnis der vesandten Nachricht.
Hier mit 01 ist das "TRANSMIT_COMPLETE_NO_ACK". Ergebniswerte kann man unter http://svn.linuxmce.org/trac/browser/trunk/src/ZWave/ZW_transport_api.h?rev=7476 und natürlich OZW herausfinden. Die 02 ist die CallbackID anhand derer man die empfangene Antwort einer versandten Nachricht zuordnen kann. Derzeit aber nicht wirklich brauchbar, da Fhem bei einem Empfangsgerät für jede versandte Nachricht die NodeID als CallbackId vergibt. Man kann also nicht feststellen, welcher versandten Nachricht die Antwort zuzuordnen ist. Das kann zu den letzten Y versandten Nachrichten gehören oder schlimmstenfalls auch ein Gerätefehler sein.
Der restliche Teil der Antwort 01a6 ist unklar und gibt es vermutlich erst seit ZW-Chipsatz 500.

CallbackIds sorgen demnach für die Zuordnung der empfangenen Antwort zur versandten Nachricht. Ohne SECURITY ist der zwingende Bedarf nicht vorhanden diese aktiv zu nutzen. Die Problemsituationen, die aus der vereinfachten Nutzung (immer NodeID) entstehen können, sind mMn recht überschaubar. Mir fällt nur ein, dass eine versandte Nachricht mehrfach beantwortet wird und Fhem diese mehrfache Antwort nicht erkennt und statt 1 Event eben 2 Events produziert. Das ist mEn auch das Beispiel aus der zwapi für die Nutzung der CallbackIds.

Bei SECURITY wird diese Vereinfachung bei den CallbackIds aber zum Problem, da SECURITY eine bestimmte Reihenfolge der Verarbeitung und Erkennung von fehlenden Nachrichten/Antworten bedarf. Das kann man letztlich nur durch eine konkrete Identifizierung von versandter Nachricht zur empfangenden Antwort/asubleibenden Antwort einfach feststellen. Dafür müssten auch 256 callbackIds reichen. Innerhalb von 1 Sekunde bis zum Timeout werden, selbst wenn man 2 Sekunden wartet, vermutlich schwerlich 256 Nachrichten zusammenkommen. @Andreas: Du kannst das bestimmt noch detaillierter und genauer darlegen. Ich frage mich auch, ob in meinen SECURITY Tests mit Controller und nur 1 ZWave-Gerät (=secure Gerät) die komplette Auswirkung des Problems überhaupt schon zum Tragen gekommen ist.

ZW_APPLICATION_UPDATE
Bei ZW_APPLICATION_UPDATE stimme ich Rudi zu. Eine Behandlung als wakeupNotification-Variante halte ich (weiterhin) für richtig und notwendig. Wenn ich mich nicht irre, habe ich irgendwo gelesen, das der Zustand des batteriebtriebenen Gerätes beim Versand von ZW_APPLICATION_UPDATE ähnlich/gleich Inklusionsbereitschaft=wach ist. Ob ZW_APPLICATION_UPDATE immer eine wakeupNotification-Nachricht mitbringt kann ich nicht definitiv sagen. Das kann letztlich auch an dem zum Testen verwendeten Gerät (Philio PST02-1A) liegen.

Hallo Rudi,

Zitat von: rudolfkoenig am 28 August 2015, 07:58:37
Wie geschrieben, das habe ich noch nicht tiefer angeschaut. Ich bin auch nicht sicher, ob meine aktuelle Version perfekt ist, funktioniert bei mir aber auch gut, und sendet sofort, wenn es moeglich ist, die Kommunikation sollte also schneller ablaufen.

Deine Änderung, das am Ende des Sendstacks der Timer mit der Abfrage zum Sendes er WU-NMI gestartet wird, habe ich bereits prinzipiell so übernommen, ich habe nur die Zeiten etwas angepasst da dies bei security nachrichten knapp werden könnte. Was noch nicht drin ist, sind die letzten Änderungen mit den ExplorerFrames für die Nachricht.

Zitat von: rudolfkoenig am 28 August 2015, 07:58:37
Sage ich doch: nur.  Mir ist das "wozu" noch nicht klar, ich kenne jedenfalls noch keinen konkreten Fall, wo es mir helfen wuerde. Evtl. ist das wg. SEC anders.

Das alleinige setzen der Callback-ID nutzt nichts, dazu gehört natürlich das man den Ablauf der Nachrichten "nachverfolgt", und das ist mMn. ohne eindeutige Callback-IDs fast unmöglich.

Mal zwei Beispiel die ich in den Logs von Krikan bereits hatte, in beiden Fällen lagen relativ viele Befehle im Sendstack die gerade abgearbeitet wurden.
a.) Nutzer (oder Notify oder sonstwas) hat einen neuen Befehl ausgelöst, der mitten in die laufende Kommunikation gesendet wurde
b.) Neue Nachricht vom Gerät (z.B. Bewegung, Tür-Auf, ...) kommt mitten in der laufenden Kommunikation

In beiden Fällen sind Befehle verloren gegangen. Das ist ein generelles Problem, Security Nachrichten sind nur leider aufgrund der größeren Länge viel empfindlicher.
Hmm, ich denke ich mach' dafür demnächst mal einen eigenen Thread auf.

Zitat von: rudolfkoenig am 28 August 2015, 07:58:37
Indem man das Reading loescht, fallst nichts mehr drin ist.
Nein. Dafuer geht der Inhalt verloren, wenn man FHEM nau startet. Ob das gut oder schlecht ist, weiss ich nocht nicht.
Nicht nach meiner Erfahrung. Ein batteriebetriebenes Geraet kann stundenlang senden, ohne dass es auf Empfang geht. Nur nach manuellen stimulieren oder konfigurierten wake_up nimmt es Befehle entgegen.

Danke für die Hinweise:
- das bei Internals der Inhalt nach Neustart verlorgen geht würde ja bedeutet das auch der WU-Sendstack nach Neustart weg ist, oder?
- ich habe nur den RFID-Leser als WU-Gerät, der sendet zusätzlich zu der zeitlich konfigurierten nach jeder nachricht die er verschickt brav eine WU-Notification. Bei welchem Gerät war/ist das denn so das der keine WU-Notification sendet? Ich lass' das mit dem Abarbeiten des WU-Sendstacks nach ZW_APPLICATION_UPDATE drin, richtig finde ich es aber nicht.

Danke,
Andreas.

Hallo Christian,

Zitat von: krikan am 28 August 2015, 09:30:23
0013020101a6  aus Antwort #35 / CallbackIDs
001302xx sind die Rückgabewerte der Callbacks zu ZW_SEND_DATA. xx steht für das Ergebnis der vesandten Nachricht.
Hier mit 01 ist das "TRANSMIT_COMPLETE_NO_ACK". Ergebniswerte kann man unter http://svn.linuxmce.org/trac/browser/trunk/src/ZWave/ZW_transport_api.h?rev=7476 und natürlich OZW herausfinden. Die 02 ist die CallbackID anhand derer man die empfangene Antwort einer versandten Nachricht zuordnen kann. Derzeit aber nicht wirklich brauchbar, da Fhem bei einem Empfangsgerät für jede versandte Nachricht die NodeID als CallbackId vergibt. Man kann also nicht feststellen, welcher versandten Nachricht die Antwort zuzuordnen ist. Das kann zu den letzten Y versandten Nachrichten gehören oder schlimmstenfalls auch ein Gerätefehler sein.
Der restliche Teil der Antwort 01a6 ist unklar und gibt es vermutlich erst seit ZW-Chipsatz 500.

Ah, dann war ich in meiner "Auswertung" eins zu weit nach vorne gerutscht und hatte die 0x02 als Rückmeldung statt als CB-ID angesehen. 0x00 und 0x01 war klar, 0x02 kann ich aber nicht.

Zitat von: krikan am 28 August 2015, 09:30:23
Bei SECURITY wird diese Vereinfachung bei den CallbackIds aber zum Problem, da SECURITY eine bestimmte Reihenfolge der Verarbeitung und Erkennung von fehlenden Nachrichten/Antworten bedarf. Das kann man letztlich nur durch eine konkrete Identifizierung von versandter Nachricht zur empfangenden Antwort/asubleibenden Antwort einfach feststellen. Dafür müssten auch 256 callbackIds reichen. Innerhalb von 1 Sekunde bis zum Timeout werden, selbst wenn man 2 Sekunden wartet, vermutlich schwerlich 256 Nachrichten zusammenkommen. @Andreas: Du kannst das bestimmt noch detaillierter und genauer darlegen. Ich frage mich auch, ob in meinen SECURITY Tests mit Controller und nur 1 ZWave-Gerät (=secure Gerät) die komplette Auswirkung des Problems überhaupt schon zum Tragen gekommen ist.

Ich werde da morgen mal einen eigenen Thread zu aufmachen...
Ich stimme Dir bei der Nutzung der CB und einer besseren Kontrolle/Steuerung der Nchrichten natürlich zu. ,-)
Security macht längere Frage-Antwort-Frage-Antwort-... Sequenzen wegen der NONCE werte die zum Verschlüsseln benötigt werden. Wird dieser Ablauf gestört, reicht es mMn nicht unbedingt die letzte Nachricht zu wiederholen. Falls das gerät der Meinung ist die gesamte Sequenz ist ungültig geworden (und davon gehe ich momentan aus), dann muss man ganz von vorne anfangen. Das gibt die momentane Behandlung von CAN / NO_ACK aber nicht her.

Und klar, mehr Geräte bedeuten mehr "Traffic" und dadurch mehr Potenzial für gestörte Nachrichten.

Zitat von: krikan am 28 August 2015, 09:30:23

ZW_APPLICATION_UPDATE
Bei ZW_APPLICATION_UPDATE stimme ich Rudi zu. Eine Behandlung als wakeupNotification-Variante halte ich (weiterhin) für richtig und notwendig. Wenn ich mich nicht irre, habe ich irgendwo gelesen, das der Zustand des batteriebtriebenen Gerätes beim Versand von ZW_APPLICATION_UPDATE ähnlich/gleich Inklusionsbereitschaft=wach ist. Ob ZW_APPLICATION_UPDATE immer eine wakeupNotification-Nachricht mitbringt kann ich nicht definitiv sagen. Das kann letztlich auch an dem zum Testen verwendeten Gerät (Philio PST02-1A) liegen.

Ich lass das drin, falls Du die Stelle an der Du das gelesen hast irgendwann mal wiederfinden solltest sag Bescheid. Die ganzen Controllerbefehle sind ja leider nicht so wirklich gut dokumentiert. Ich habe das halt bisher nicht beobachten können.

Gruß,
Andreas.

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

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

Zitat von: rudolfkoenig am 28 August 2015, 11:06:33
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.

Hallo Rudi,

Zitat von: rudolfkoenig am 28 August 2015, 11:06:33
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.

Zitat von: rudolfkoenig am 28 August 2015, 11:06:33
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.

Zitat von: rudolfkoenig am 28 August 2015, 11:06:33
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.

Hallo Rudi,

Zitat von: A.Harrenberg am 28 August 2015, 09:37:21
- 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.

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

ZitatWie 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:
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


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

Hallo Rudi,

Zitat von: rudolfkoenig am 29 August 2015, 12:32:59
@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.
  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.

Zitat von: rudolfkoenig am 29 August 2015, 12:32:59
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?

Zitat von: rudolfkoenig am 29 August 2015, 12:32:59
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.

Hallo Rudi,

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

Zitat von: rudolfkoenig am 27 August 2015, 22:05:54
- 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.
  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?

  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.

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

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

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

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

Hallo Rudi,

Zitat von: rudolfkoenig am 30 August 2015, 11:30:13
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...

Zitat von: rudolfkoenig am 30 August 2015, 11:30:13
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 ...

Zitat von: rudolfkoenig am 30 August 2015, 11:30:13
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...

Zitat von: rudolfkoenig am 30 August 2015, 11:30:13
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.

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

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

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

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

Hallo Rudi,

Zitat von: rudolfkoenig am 30 August 2015, 16:04:47
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.

Zitat von: rudolfkoenig am 30 August 2015, 16:04:47
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.

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.

Hallo Rudi,

Zitat von: rudolfkoenig am 30 August 2015, 18:47:26
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...

Zitat von: rudolfkoenig am 30 August 2015, 18:47:26
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.

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

Zitat@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:
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

Hi Krikan,

Zitat von: krikan am 01 September 2015, 23:39:49
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.

Hallo Rudi,

ich habe jetzt mal eine Patch-Datei für 10_ZWave.pm erzeugt. Das ganze basiert auf der aktuellen revision 9176.

+ Zeilenbreite ist jetzt 80 Zeichen
+ use Crypt::Rijndael ist durch eine "eval require" Funktion ersetzt
+ Fehlermeldungen und Status-Reading falls Rijndael Modul nicht installiert, Networkkey nicht gesetzt, Gerät Security gar nicht unterstützt (aber dennoch secure inclusion gestartet wurde) oder der Networkkey vom Gerät nicht verifiziert werden konnte
+ Logmeldungen etwas reduziert und an die verbose-Level angepasst
+ Zwischenspeichern des security stacks und der frames bei langen Nachrichten ist von Readings auf Internals umgestellt
+ die langen Zeichenketten in den AES Funktionen habe ich angepasst
+ Dokumentation für Security ist enthalten

++ WakeUpStack Abarbeitung ist ggü. der 9176 allerdings leicht verändert. "Meine" Version verschickt nicht per Schleife sondern per Timer, da dies bei Security ansonsten Probleme macht.
++ zwei GET-Befehle für DOOR_LOCK, allerdings noch ohne Dokumentation... (muss nicht mit rein)

In dem Diff sind jede Menge "nicht geänderter" Zeilen, da im SVN Code die Zeilen teilweise ein Leerzeichen angehängt haben, das entfernt mein Editor anscheinend...

Eine (vor-)letzte Version hat Krikan kurz angetestet und keine Auffälligkeiten bemerkt, danach habe ich "nur" noch die Zeilenlängen auf 80 Zeichen angepasst.
Die zum Patch gehörende Version der 10_ZWave.pm habe ich ebenfalls angehängt (und werde Sie auch noch an Post #1 hängen), falls Du mehr Rückmeldungen benötigst finden sich ja vielleicht noch ein oder zwei andere Tester...

Gruß,
Andreas.

Hallo Rudi,

Krikan hat gerade noch Merkwürdigkeiten in der Patchdatei gefunden. Anscheinend ist da im Bereich der Dokumentation was schief gelaufen, da werden wohl haufenweise Zeilen "gelöscht" die ich nicht gelöscht habe... Anscheinend kommt da der Diff mit einige Sachen nicht zurecht.

Ich schau da heute abend noch mal rein.

Gruß,
Andreas.

Hallo Rudi,

habe die Datei jetzt noch mal neu abgeglichen und dann einen neuen Diff gemacht. Sieht jetzt besser aus. Irgendwie funktioniert das mit dem SVN bei mir anscheinend nicht immer sauber, da hatte ich ja schon mal Schwierigkeiten... Liegt aber wahrscheinlich daran das ich da mit Windows und Linux gleichzeitig dran arbeite... Sollte mich wohl mal auf Linux beschränken. Danke noch mal an Krikan für das wachsame Auge!

Neue Version vom Patch und der Datei ist angehängt.

Gruß,
Andreas.

Hallo Andreas,

dein Patch ist ok, bis auf zwei Ausnahmen:
- ich meine das Senden der Daten aus den WakeUp-Stack per Timer ist auch falsch (genau wie meine Methode, alles zu senden), hier muss man auf die Nachricht vom Controller warten. Das werde ich jetzt umbauen.
- Ich wuerde presumed_State als Internal speichern. Eigentlich kann man das aus lastMsgTimestamp ableiten, allerdings muss man ein gesendetes wakeupNoMoreInformation beruecksichtigen.

Ich uebernehme diesen Patch, werde aber die o.g. Punkte umbauen.
Ich bitte dich Security nach dem Umbau zu testen, und evtl. zu korrigieren.

Gruss,
  Rudi

Hallo Andreas, Hallo Rudi!

Habe 10_ZWave.pm (r9203) aus dem SVN mit PST02-1A getestet. Leider läuft die secure-Inklusion nicht durch. Offensichtlich funktioniert die Ermittlung des Attributs secure_classes nicht. Ich habe es jetzt mehrfach versucht.

2 Versuche habe ich beigefügt (jeweils list und log in der Datei)
Einmal scheitert Einbindung wegen zu vieler CAN, beim 2. Versuch verstehe ich das Problem nicht.
Eine manuelle Abfrage der secure_classes führt auch nicht zum Erfolg.
Wäre schön, wenn ihr Euch das anschauen könntet.

Wenn ihr mehr Infos/Tests braucht, bitte anfordern...

@Rudi: Den Sensor habe ich zu den SECURITY-Tests der 10_ZWave.pm-Versionen aus diesem Thread genutzt und das lief jetzt seit längerem problemlos.

Gruß, Christian

Christian, du warst zu schnell.

Die von dir getestete Version war ein Zwischenschritt, bevor ich die Warteschlangen umgebaut habe, damit nicht alles in einem Version untergebracht wird. Ich weiss zwar immer noch nicht, ob security mit der aktuellen Version (9204) tut, sie hat aber eine Chance. Bei der 9203 funktioniert sie sicher nicht, da hier die alte (meine) Warteschlange drin war, und Andreas hat es schon gesagt, dass damit Security nicht funktioniert, deswegen hat er sie modifiziert.

Habe ich schon gemerkt und Test mit r9204 läuft. Erster ist leider wieder nicht durchgelaufen.

Habe im Log mit Stacktrace folgende Ausgabe (Zusammenhang?):

2015.09.05 22:30:26 4: ZWDongle_Read ZWDongle_0: sending ACK, processing 00040418028407
2015.09.05 22:30:26 5: SW: 06
2015.09.05 22:30:26 5: ZWDongle_0 dispatch 00040418028407
2015.09.05 22:30:26 4: ZWDongle_0 CMD:APPLICATION_COMMAND_HANDLER ID:18 ARG:028407
2015.09.05 22:30:26 5: ZWDongle_Write 00 1318039804002518
2015.09.05 22:30:26 5: SW: 010a0013180398040025185c
2015.09.05 22:30:26 5: ACK received, removing 010a0013180398040025185c from dongle sendstack
2015.09.05 22:30:26 4: ZWDongle_Read ZWDongle_0: sending ACK, processing 011301
2015.09.05 22:30:26 5: SW: 06
2015.09.05 22:30:26 5: ZWDongle_0 dispatch 011301
2015.09.05 22:30:26 4: ZWDongle_Read ZWDongle_0: sending ACK, processing 00131800
2015.09.05 22:30:26 5: SW: 06
2015.09.05 22:30:26 5: ZWDongle_0 dispatch 00131800
2015.09.05 22:30:26 4: ZWDongle_0 CMD:ZW_SEND_DATA ID:00 ARG:
2015.09.05 22:30:26 4: ZWDongle_0 transmit OK for 18
2015.09.05 22:30:26 1: PERL WARNING: Use of uninitialized value in string eq at fhem.pl line 2722.
2015.09.05 22:30:26 3: stacktrace:
2015.09.05 22:30:26 3:     main::__ANON__                      called by fhem.pl (2722)
2015.09.05 22:30:26 3:     main::RemoveInternalTimer           called by ./FHEM/00_ZWDongle.pm (543)
2015.09.05 22:30:26 3:     main::ZWDongle_ProcessSendStack     called by ./FHEM/00_ZWDongle.pm (674)
2015.09.05 22:30:26 3:     main::ZWDongle_Read                 called by fhem.pl (3057)
2015.09.05 22:30:26 3:     main::CallFn                        called by fhem.pl (651)
2015.09.05 22:30:27 5: ZWDongle_Write 00 13180284082518
2015.09.05 22:30:27 5: SW: 010900131802840825184e
2015.09.05 22:30:27 5: ACK received, removing 010900131802840825184e from dongle sendstack
2015.09.05 22:30:27 4: ZWDongle_Read ZWDongle_0: sending ACK, processing 011301
2015.09.05 22:30:27 5: SW: 06
2015.09.05 22:30:27 5: ZWDongle_0 dispatch 011301
2015.09.05 22:30:27 4: ZWDongle_Read ZWDongle_0: sending ACK, processing 00131800
2015.09.05 22:30:27 5: SW: 06
2015.09.05 22:30:27 5: ZWDongle_0 dispatch 00131800
2015.09.05 22:30:27 4: ZWDongle_0 CMD:ZW_SEND_DATA ID:00 ARG:
2015.09.05 22:30:27 4: ZWDongle_0 transmit OK for 18

Hab den Stacktrace-Bug geloest, sollte aber keine Nebenwirkungen haben. Das Security-Problem sollte zunaechst Andreas anschauen, da ich deutlich mehr Zeit brauche, um sein Code zu verstehen.

Leider läuft secure-Inklusion mit r9204 nicht durch. Log und list anbei.
secure_classes habe versuchsweise manuell ergänzt. Hat aber keine erkennbaren positiven Auswirkungen.
Morgen mit r9205 mehr Tests (auch außerhalb SECURITY) und gesetztem Attribut mseclog.

Hallo Rudi,

Zitat von: rudolfkoenig am 05 September 2015, 17:46:21
dein Patch ist ok, bis auf zwei Ausnahmen:
- ich meine das Senden der Daten aus den WakeUp-Stack per Timer ist auch falsch (genau wie meine Methode, alles zu senden), hier muss man auf die Nachricht vom Controller warten. Das werde ich jetzt umbauen.

Das Timer falsch ist weiß ich, ging aber erst mal nicht anders. Für Security muss die gesamte Abarbeitung von bis zu 8 Nachrichten "AM STÜCK" geschützt werden, obwohl da erst mal nur ein Befehl auf dem Stack (Nonce-Get) liegt. Ich muss mir Deine Lösung erst ansehen und ausprobieren, dann sehen wir weiter.

Zitat von: rudolfkoenig am 05 September 2015, 17:46:21
- Ich wuerde presumed_State als Internal speichern. Eigentlich kann man das aus lastMsgTimestamp ableiten, allerdings muss man ein gesendetes wakeupNoMoreInformation beruecksichtigen.

Ja, Internal ist auch hier besser, die Steuerung über das presumed_State war im Patch noch gar nicht fertig, das hatte ich jetzt bei cnkru für den Danfoss in einer ersten Version probiert. Da waren noch zwei Fehler drin, ansonsten hat das sehr schön funktioniert und alle Nachrichten so lange an das Ende des Stack gepackt bis der Stack abgearbeitet war.

Zitat von: rudolfkoenig am 05 September 2015, 17:46:21
Ich uebernehme diesen Patch, werde aber die o.g. Punkte umbauen.
Ich bitte dich Security nach dem Umbau zu testen, und evtl. zu korrigieren.

Ja, werde ich mir gleich ansehen, erste Tests von Krikan gibt es ja auch bereits, wird aber eine Weile dauern bis ich da durch bin.

Gruß,
Andreas.

Hallo,

GANZ kurzer Zwischenstand bei mir mit 9205:

• Inklusion läuft prinzipiell durch, einige Merkwürdigkeiten noch offen
• set <..> configRequestAll läuft nicht durch, die meisten Befehle scheinen da auf dem Stack zu vergammeln und werden nach 10 sekunden abgeräumt
  

Es scheint da Probleme mit dem ReadAnswer zu geben, könnte daran liegen das ich ZWave_CMD rekursiv aufrufe...

Gruß,
Andreas.

Hallo Rudi,

hab' mir mal ein paar Logmessages eingebaut und "set <...> configRequestAll" mit Security gemacht. Es sieht so aus als ob die ReadAnswerFn gestartet wird, BEVOR der eigentlich dazugehörige Befehl aus dem Sendstack gesendet wurde. Dann kommt es zu den Verzögerungen und den "alten" Nachrichten auf dem SendStack.

Das erste "2015.09.06 09:41:53.062 2: ZWave get ZWave_SWITCH_BINARY_154 secNonce " funktioniert noch,
das zweite "2015.09.06 09:41:53.553 2: ZWave get ZWave_SWITCH_BINARY_154 secNonce " dann nicht mehr.

Die erste Nachricht wird durch das Warten auf Godot ;-) erst 13 Sekunden später ausgeführt.
2015.09.06 09:42:05.560 5: SW: 011e00139a179881e9da194b1d43f01c91ef6b7b09184d07c2afe16453259a84

Ohne Security passiert das bei diesem Beispiel nicht, da alles als SET-Befehl implementiert ist. Einzelne manuell Get-Befehle haben ohne Security bisher auch nicht dieses Verhalten gezeigt. "Problem" dürfte noch größer werden wenn man das Delay nutzt, oder?

Any Idea?

Gruß,
Andreas.


2015.09.06 09:41:53.062 2: ZWave set ZWave_SWITCH_BINARY_154 configEnableDisableLockConfiguration request
2015.09.06 09:41:53.062 3: ZWave_SWITCH_BINARY_154 SECURITY: 7005fc stored for encryption
2015.09.06 09:41:53.062 2: ZWave get ZWave_SWITCH_BINARY_154 secNonce
2015.09.06 09:41:53.062 1: ZWave_SWITCH_BINARY_154: adding 139a029840259a to Sendstack
2015.09.06 09:41:53.062 1: ZWave_SWITCH_BINARY_154: processing SendStack
2015.09.06 09:41:53.063 1: ZWave_SWITCH_BINARY_154: sending 00139a029840259a from SendStack
2015.09.06 09:41:53.063 5: ZWDongle_Write 00 139a029840259a
2015.09.06 09:41:53.063 5: SW: 010900139a029840259a1a
2015.09.06 09:41:53.064 1: ZWave_SWITCH_BINARY_154: type=get; data=139a029840259a
2015.09.06 09:41:53.064 1: ZWDongle_ReadAnswer arg:secNonce regexp:^0004009a..98
2015.09.06 09:41:53.451 5: ACK received, removing 010900139a029840259a1a from dongle sendstack
2015.09.06 09:41:53.471 4: ZWDongle_Read ZWDongle_0: sending ACK, processing 011301
2015.09.06 09:41:53.471 5: SW: 06
2015.09.06 09:41:53.472 5: ZWDongle_0 dispatch 011301
2015.09.06 09:41:53.491 4: ZWDongle_Read ZWDongle_0: sending ACK, processing 00139a000002
2015.09.06 09:41:53.491 5: SW: 06
2015.09.06 09:41:53.492 5: ZWDongle_0 dispatch 00139a000002
2015.09.06 09:41:53.492 4: ZWDongle_0 CMD:ZW_SEND_DATA ID:00 ARG:0002
2015.09.06 09:41:53.492 4: ZWDongle_0 transmit OK for 9a
2015.09.06 09:41:53.492 1: ZWave_SWITCH_BINARY_154: processing SendStack
2015.09.06 09:41:53.551 4: ZWDongle_Read ZWDongle_0: sending ACK, processing 0004009a0a98800953477ad6c8302e
2015.09.06 09:41:53.551 5: SW: 06
2015.09.06 09:41:53.552 4: ZWDongle_ReadAnswer for secNonce: 0004009a0a98800953477ad6c8302e
2015.09.06 09:41:53.552 4: ZWDongle_0 CMD:APPLICATION_COMMAND_HANDLER ID:9a ARG:0a98800953477ad6c8302e
2015.09.06 09:41:53.552 3: ZWave_SWITCH_BINARY_154 SECURITY: 7005fc retrieved for encryption
2015.09.06 09:41:53.552 2: ZWave set ZWave_SWITCH_BINARY_154 secEncap 81e9da194b1d43f01c91ef6b7b09184d07c2afe16453
2015.09.06 09:41:53.552 1: ZWave_SWITCH_BINARY_154: adding 139a179881e9da194b1d43f01c91ef6b7b09184d07c2afe16453259a to Sendstack
2015.09.06 09:41:53.553 2: ZWave set ZWave_SWITCH_BINARY_154 configPartnerID request
2015.09.06 09:41:53.553 3: ZWave_SWITCH_BINARY_154 SECURITY: 7005c8 stored for encryption
2015.09.06 09:41:53.553 2: ZWave get ZWave_SWITCH_BINARY_154 secNonce
2015.09.06 09:41:53.553 1: ZWave_SWITCH_BINARY_154: adding 139a029840259a to Sendstack
2015.09.06 09:41:53.553 1: ZWave_SWITCH_BINARY_154: type=get; data=139a029840259a
2015.09.06 09:41:53.553 1: ZWDongle_ReadAnswer arg:secNonce regexp:^0004009a..98
2015.09.06 09:41:56.556 5: ZWDongle_ReadAnswer: select timeout
2015.09.06 09:41:56.556 1: configPartnerID: Timeout reading answer for get secNonce
2015.09.06 09:41:56.557 2: ZWave set ZWave_SWITCH_BINARY_154 configResetDefaultConfiguration request
2015.09.06 09:41:56.557 3: ZWave_SWITCH_BINARY_154 SECURITY: 7005ff stored for encryption
2015.09.06 09:41:56.557 2: ZWave get ZWave_SWITCH_BINARY_154 secNonce
2015.09.06 09:41:56.557 1: ZWave_SWITCH_BINARY_154: adding 139a029840259a to Sendstack
2015.09.06 09:41:56.557 1: ZWave_SWITCH_BINARY_154: type=get; data=139a029840259a
2015.09.06 09:41:56.557 1: ZWDongle_ReadAnswer arg:secNonce regexp:^0004009a..98
2015.09.06 09:41:59.557 5: ZWDongle_ReadAnswer: select timeout


Hallo Rudi,

anbei ein kleiner Patch für 10_ZWave.pm. (9205)

Hintergrund: Falls ein Gerät mit Security "unsolicited" Messages verschickt, also z.B. ein Bewegungsmelder, dann muss auch vor der WU-Notification auf den Nonce-Get geantwortet werden können ohne das diese Nachricht in den WakeUp-Stack gelangt.

Ich habe das bisher nur "simuliert" indem ich meinem (netzbetriebenem) Device die WakeUp Klasse hinzugefügt habe und dann per dispatch einen Nonce-Get geschickt habe. Bei mir hat es funktioniert, Krikan hatte bisher (noch) keine Zeit das zu testen, wird sich aber sicherlich noch mit einem Log dazu melden.

Gruß,
Andreas.

- patch meldet bei mir "patch: **** malformed patch at line 23:  "
- habs per Hand eingefuegt, aber den regexp mit einem ^ ergaenzt, sonst ist das mit zu unsicher.
- habs eingecheckt.

Hallo Rudi,

muss gestehen das ich an dem File editiert hatte, aber eigentlich nur die anderen Unterschiede rausgelöscht hatte, sorry wenn es dadurch nicht direkt funktioniert hat.

Danke,
Andreas.

Hallo zusammen,

falls noch jemand wie ich nicht weiß wie man das Perl Modul Crypt::Rijndael unter Ubuntu installiert
apt-get install libcrypt-rijndael-perl
hat bei mir funktioniert.

Hi,

Zitat von: Netsurfer am 07 September 2015, 16:17:56
falls noch jemand wie ich nicht weiß wie man das Perl Modul Crypt::Rijndael unter Ubuntu installiert
apt-get install libcrypt-rijndael-perl
hat bei mir funktioniert.

guter Hinweis, ich habe das einfach mal in den Post #1 eingefügt. ,-)

Momentan gibt es aber noch ein paar Problemchen mit Security, da jetzt im "normalen" ZWave-code relativ viel umgestellt wurde und noch nicht alles darauf angepasst wurde.

Gruß,
Andreas.

schön das ich auch mal einen kleinen Beitrag leisten konnte  :D

Hallo,

ich wollte nur mal kurz ankündigen das ich die nächsten 3 Wochen leider keinen Support bei Problemen leisten kann. Ich muss jetzt erst mal auf eine Dienstreise und bin anschließend noch privat unterwegs.

Bei Problemen diese ruhig auch in der Zwischenzeit hier posten/schildern, vielleicht ist es ja gar nichts Security spezifisches und Rudi oder Krikan können helfen. Ich erwarte auch keine größeren Probleme mit der mit den internen Verschlüsselungsroutinen. Was auftreten könnte sind häufigere CAN Messages. Das liegt dann einfach daran das durch die Verschlüsselung zusätzliche Nachrichten übertragen werden müssen.

Durch das erneute Versenden der betroffenen Nachrichten sollte es im Idealfall zu keinem Nachrichtenverlust kommen.
Sollten hier ernsthaftere Probleme auftreten muss ich mir das dann nach meiner Rückkehr anschauen.

Gruß,
Andreas.

Security Evaluation of the Z-Wave Wireless Protocol (https://sensepost.com/cms/resources/conferences/2013/bh_zwave/Security%20Evaluation%20of%20Z-Wave_WP.pdf)

Zitat von: Ralli am 26 September 2015, 12:00:46
Security Evaluation of the Z-Wave Wireless Protocol (https://sensepost.com/cms/resources/conferences/2013/bh_zwave/Security%20Evaluation%20of%20Z-Wave_WP.pdf)

Was soll uns das sagen?

Dass ich noch immer nicht dazugekommen bin, ZWave in culfw zu implementieren.

Mach Dir mal keinen Stress, sonst "muss" ich mir noch einen CUL kaufen...
Zu kein Stress: Hattest Du meinen Patch http://forum.fhem.de/index.php/topic,32823.msg336233.html#msg336233 gesehen? Habe noch so etwas auf Lager..

@krikan:

Das ist ein interessanter Artikel über einen Implementierungsfehler vom Key-Exchange, der aber an Sigma kommuniziert wurde. Soll hier in dem Thread einfach für den Hinterkopf sein, dass ggf. eben darauf zu achten ist.

@krikan: nein, und ich wuesste gerne wieso. Die Diskussion war nicht auf Beobachtung... Ich schaue es mir heute Abend oder Morgen an. Bitte dein Link nicht loeschen.

@Ralli: das Dokument ist aelter, die beiden Autoren haben die Funk-Telegramme mit einem CC1101 kompatiblen Empfaenger aufgezeichnet. Sie ruecken zwar nicht den ganzen Code raus, aber nach etwas betteln haben sie mir die CC1101 Konfiguration zugeschickt. Leider hat es beim ersten Versuch nicht funktioniert, obwohl ich sehr gerne die ZWave-Funk-Telegramme sehen wuerde. Solange so eine freie Implementierung nicht verfuegbar ist, ist ZWave mAn auch ohne Verschluesselung sicher.

Ob danach ZWave mit Verschluesselung sicher ist, wage ich zu bezweifeln: weder wir von FHEM, noch die Geraetehersteller sind Profis, was Sicherheit betrifft. Die Aussage vom Paper ist (wenn ich es richtig verstanden habe), dass das Firmware im Tueroeffner fehlerhaft war.

Immerhin koennte man mit aktivierten Security dem Einbrecher mit DMCA drohen :)

Hi,

Zitat von: rudolfkoenig am 26 September 2015, 13:33:06
@Ralli: das Dokument ist aelter[...]
Solange so eine freie Implementierung nicht verfuegbar ist, ist ZWave mAn auch ohne Verschluesselung sicher.

Ob danach ZWave mit Verschluesselung sicher ist, wage ich zu bezweifeln: weder wir von FHEM, noch die Geraetehersteller sind Profis, was Sicherheit betrifft. Die Aussage vom Paper ist (wenn ich es richtig verstanden habe), dass das Firmware im Tueroeffner fehlerhaft war.

Immerhin koennte man mit aktivierten Security dem Einbrecher mit DMCA drohen :)

der beschriebene Fehler lag wie von Rudi geschrieben in der Firmware des Gerätes und nicht im Protokoll von ZWave.

Das Protokoll ist sicher, solange niemand die Kommunikation währed der Inklusion belauscht. Dort wird das Passwort nämlich mit einem Standard-Passwort verschlüsselt übertragen. Da dieses Standard-Passwart jetzt kein "Geheimnis" mehr ist, liesse sich aus der Kommunikation das Passwort extrahieren. Ohne die Kenntnis des Passworts ist das Protokoll an sich sicher, Implementierungsfehler in den Geräten (oder in FHEM...) könnten das evtl. aber aushebeln wie in dem Beispiel gezeigt wurde.

Aber selbst mit Kenntnis des Passworts wäre es ein ziemlicher Aufwand sich mit geeigneter Hardware als der eigentliche Controller im Netzwerk auszugeben und entsprechende Nachrichten zu verschicken. Die Haustüre einzutreten ist da viel einfacher...

Der eigentliche Controller würde ja die Anfragen für die NONCE des Gerätes auch beantworten und damit dann wahrscheinlich ein heilloses Durcheinander an CAN und NO_ACK Messages erzeugen... ,-)

Gruß,
Andreas.

P.S.: Bin wie zu erkennen ist wieder aus dem Urlaub zurück, so wie ich das sehe ist in der Zwischenzeit nicht sooo viel an Rückmeldungen bzgl. SECURITY aufgelaufen. Ich werde mir in den nächsten Tagen dann mal die letzten Änderungen am Code ansehen und dann mal schauen was noch zu tun ist.

Hallo Andreas,

... das erinnert mich an Homematic. Sobald du das Initalpasswort bzw. den Initialschlüssel kennst, kannst du nur noch im pharadäischen Käfig sicher anlernen  ;).

Nicht ganz.
Bei Homematic hat man (frueher?) das Default-Passwort verwendet, da ein selbstgewaehltes Passwort diverse und zum Teil schwerwiegende Probleme verursacht hat. Hier ist die Rede von der Verwendung eines Initialpasswortes nur waehrend des Anlernens, ein default Passwort gibt es mWn bei ZWave nicht. Homematic hat das Problem bei der Iniitalisierung zusaetzlich.

Hi,

Zitat von: Ralli am 04 Oktober 2015, 13:54:20
... das erinnert mich an Homematic. Sobald du das Initalpasswort bzw. den Initialschlüssel kennst, kannst du nur noch im pharadäischen Käfig sicher anlernen  ;).

das problem ist nun mal leider systembedingt wenn man ein Passwort über das gleiche Medium aushandelt auf der auch die Kommunikation stattfindet...
Immerhin wird das Passwort überhaupt schon mal verschlüsselt übermittelt und nicht im Klartext. Damit ist schon mal die Kenntnis des Initalpassworts nötig.

"Umgehen" liesse sich das nur mit Geräteindividuellen Initalpasswörtern, die z.B. auf jedem Gerät aufgedruckt wären und die man manuell für die Initiale Verschlüsselung des Netzwerkschlüssels verwenden würde. Dann müsste ein Angreifer Kenntnis über dieses individuelle Passwort haben um den Netzwerkschlüssel rekonstruieren zu können.

Bei der Inklusion mit Security wird ein "Security-Scheme" ausgehandelt, hier gibt es momentan nur ein einziges Scheme "00", wer weiß was in zukünftigen Versionen der Schemes implementiert wird.

Gruß,
Andreas.

Zitatdas problem ist nun mal leider systembedingt wenn man ein Passwort über das gleiche Medium aushandelt auf der auch die Kommunikation stattfindet...

Nicht unbedingt, siehe https://de.wikipedia.org/wiki/Public-Key-Verschl%C3%BCsselungsverfahren

Hallo Rudi,

Zitat von: rudolfkoenig am 04 Oktober 2015, 14:53:40
Nicht unbedingt, siehe https://de.wikipedia.org/wiki/Public-Key-Verschl%C3%BCsselungsverfahren

stimmt, allerdings benötigt man dann, zumindest bei der Inklusion, für jeden Empfänger einen eigenen Schlüssel.

Ein solches System könnte eine Möglichkeit für eine zukünftige "Scheme 01" Implementierung sein.
Gerät sendet seinen öffentlichen Schlüssel, Controller/FHEM verschlüsselt den Netzwerkschlüssel damit und sendet an das Gerät. Das Gerät kann den Schlüssel mit seinem (internen) geheimen Schlüssel entschlüsseln und ab da kann es wie bisher weitergehen und wäre damit sicher solange keine Implemtierungsfehler auftreten.

Ich habe sowieso ein wenig "Angst" davor das Sigma in einem V2 Update für Security solche Sachen einbaut. Dann wird es SEHR aufwändig das wieder zu rekonstruieren.

Gruß,
Andreas.

Hallo Andreas!

Hier http://www.zwave.de/problembehebung-mit-philio-mehrfachsensor/ wird über Probleme mit SECURITY zwischen Z-Way und Philio (=devolo?) berichtet. Es wird mir nur nicht klar, ob es an Z-way oder am Sensor liegt.

Wir sollten mMn dringend auch andere batteriebetriebene Geräte mit SECURITY testen oder ist das schon geschehen?

Gruß, Christian

Hi Krikan,

Zitat von: krikan am 05 Oktober 2015, 16:01:57
Hier http://www.zwave.de/problembehebung-mit-philio-mehrfachsensor/ wird über Probleme mit SECURITY zwischen Z-Way und Philio (=devolo?) berichtet. Es wird mir nur nicht klar, ob es an Z-way oder am Sensor liegt.

Wir sollten mMn dringend auch andere batteriebetriebene Geräte mit SECURITY testen oder ist das schon geschehen?

ist ja 'ne tolle Lösung... Einfach keine Security verwenden...

Ist das eigentlich der Sensor den Du hast oder ein anderer? Bisher habe ich nur Logs von Dir bzw. von einem baugleichen Sensor bekommen. Und jetzt die Logs von dem 6-fach Sensor, die nutzen aber nichts, da dort die Inclusion ja gar nicht richtig durchgelaufen ist.

Ich überlege ernsthaft mir auch so einen 6-fach Sensor zu kaufen damit ich das hier bei mir lokal testen kann, das ist deutlich einfacher/schneller...

Zuerst muss ich aber mal mein System updaten (ist ja >3 Wochen alt) und dann mal die letzten Änderungen nachvollziehen. Dann kann ich mal probieren ob meine Sirene noch mit Security will. Falls das noch geht muss ich mir mal ansehen was dann bei den WakeUp Geräten schief läuft.

Gruß,
Andreas.

Zitat von: A.Harrenberg am 05 Oktober 2015, 19:17:53
,ist ja 'ne tolle Lösung... Einfach keine Security verwenden...

Ich finde den Tipp klasse  ;)

ZitatIst das eigentlich der Sensor den Du hast oder ein anderer? Bisher habe ich nur Logs von Dir bzw. von einem baugleichen Sensor bekommen. Und jetzt die Logs von dem 6-fach Sensor, die nutzen aber nichts, da dort die Inclusion ja gar nicht richtig durchgelaufen ist.

Kann ich nicht definitiv sagen, da zwave.de keine Modellbezeichnung angibt. In dem Gehäuse gibt es mehrere Varianten. Vermutung aber: Ja

ZitatIch überlege ernsthaft mir auch so einen 6-fach Sensor zu kaufen damit ich das hier bei mir lokal testen kann, das ist deutlich einfacher/schneller...

Wenn Du den gebrauchen kannst; ansonsten teste ich weiter...
Wollte mich bei Gelegenheit auch mal mit meinen anderen SECURITY-Geräten beschäftigen. KFOB-S-Test ist schon zu lange her und den AEOTEC Mulitisensor  habe ich noch gar nicht probiert.

Gruß, Christian

Hi Krikan,

Zitat von: krikan am 05 Oktober 2015, 19:34:31
Wenn Du den gebrauchen kannst; ansonsten teste ich weiter...

ich meine damit den AEOTEC, ich bin mit meinem Homematic Bewegungsmelder nicht wirklich zufrieden, die Empfindlichkeit von dem Ding ist manchmal sehr schlecht. So ein Philio wollte ich mir nicht zulegen, die Bauform kann ich nicht vernünftig montieren...
Bei den Tests die wir mit Deinem Philio gemacht haben konnte ich aber keine prinzipiellen Probleme mit Security erkennen, vielleicht ist es ja doch eher ein Problem mit Z-way.

Zitat von: krikan am 05 Oktober 2015, 19:34:31
Wollte mich bei Gelegenheit auch mal mit meinen anderen SECURITY-Geräten beschäftigen. KFOB-S-Test ist schon zu lange her und den AEOTEC Mulitisensor  habe ich noch gar nicht probiert.

So ein KFOB-S würde mich ja auch interessieren, dafür hätte ich aber keine Verwendung mehr da ich ja den RFID-Leser nutze. Und nur zum "spielen" ist das Ding zu teuer.

Gruß,
Andreas.

Hi,

Tests mit der Version 9371 sehen leider immer noch nicht wirklich gut aus mit aktivierter SECURITY. Bei einem "set ... configRequestAll" auf meine (netzbetriebene) Sirene gehen  reproduzierbar zwei Packete aufgrund des "Durcheinanders" beim Senden verloren.

Das ganze habe ich hier im Forum (http://forum.fhem.de/index.php/topic,38587.msg325434.html#msg325434) ja schon mal etwas beschrieben.

DIe bisherigen Änderungen an ZWave und dem Sendstack machen den Transport insgesamt zwar deutlich stabiler und Fehlertoleranter falls Störungen/Kollisionen auftreten sollten, helfen aber bei diesem prinzipbedingten Problem leider nicht. Sobald die erste Antwort mit der NONCE ankommt, wird bereits der nächste Befehl vom Sendstack verarbeitet und gesendet, bevor die erste Nachricht mit der Nonce verschlüsselt und gesendet werden könnte. Dadurch kommt dann die ganze Kommunikation durcheinander und letztendlich bleiben dann Befehle "übrig" die gar nicht mehr abgearbeitet werden.

Bei einzelnen Kommandos tritt dieses Problem normalerweise nicht auf, da hier keine weiteren Befehle dazwischenkommen, das Abarbeiten des WakeUp-Stacks verursacht aber die gleichen Probleme.

Ohne einen steuerbaren Sendstack wird sich dieses Problem mMn nicht lösen lassen, allerdings habe ich momentan noch keinen richtigen Ansatz wie ich diese Steuerung realisieren kann.
Ich muss mir die Abläufe jetzt noch mal genauer ansehen und dann schauen ob ich eine Lösung finden kann die auch für den normalen Betrieb ohne Security funktioniert.
Solange bis hier eine Lösung gefunden ist, ist Security leider nur etwas eingeschränkt nutzbar...

Ich bin aber optimistisch das wir eine Lösung finden werden.

Gruß,
Andreas.

ZitatOhne einen steuerbaren Sendstack wird sich dieses Problem mMn nicht lösen lassen

Sehe ich auch so. Vorschlag:
- device Variable secInProgress. Falls gesetzt, schieben ZWave_Get und ZWave_Set neue FHEM-Befehle(!) auf einem secStack, ohne ZWave_Cmd aufzurufen. Vermutlich kann man diese Variable nach dem Aufruf von ZWave_isSecureClass setzen.
- in den Security-Routinen muss man  die Funktion ZWave_Cmd direkt verwenden, statt ZWave_Get und ZWave_Set.
- Falls die sec-Befehlskette fertig ist (auch wg. timeout!), muss man ZWave_processSecStack aufrufen, der secInProgress zuruecksetzt, und fuer die Abarbeitung der secStack sorgt, indem sie die gespeicherten Daten an ZWave_Get/ZWave_Set weitergibt.

Falls du damit einverstanden bist, wuerde ich das bauen, du muesstest nur den Aufruf von  ZWave_processSecStack an den richtigen Stellen ergaenzen, da fuehle mich naemlich unsicher.

Hallo Rudi,

meine erste Idee sah etwas anders aus, ich hatte eher überlegt eine Art Token OBEN auf den Sendstack zu legen der die weitere Abarbeitung des Stacks verhindert, und neue Nachrichten die zu der laufenden Security-Kommunikation gehören, dann auch OBEN auf den Stack (also über das Token zu setzen). Neue unverschlüsselte Befehle wie sonst auch auch ganz normal unten an den Sendstack zu hängen. Sobald dann die Security-Kommunikation beendet ist sollte das Token wieder oben liegen und könnte entfernt werden.

Deine Idee klingt aber auch gut und ist strukturierter. Gib mir bitte ein paar Tage Zeit das mal gedanklich in einigen Fällen durchzuspielen bevor Du das das so umsetzt. Hier muss ich mir vor allem mal überlegen was mit den Befehlen bei eingeschlafenen WakeUp-Geräten passiert. Aktuell "fange" ich diese Befehle ja ab und lege nur den ersten "get Nonce" Befehl auf den Stack.

Oder hast Du vor den Sendstack insgesamt auf ungeparste FHEM-Befehle umzustellen?

Danke schon mal,
Andreas.

Ich habe auch mit sowas wie dein Token angefangen, ist aber komplizierter/verwirrender, als der aktuelle Vorschlag.
Wenn sendStack auch auf FHEM-Befehle umgestellt waere, dann wuerde wir wieder bei einer komplizierter Variante landen.

Hallo Rudi,

Zitat von: rudolfkoenig am 11 Oktober 2015, 10:20:09
Ich habe auch mit sowas wie dein Token angefangen, ist aber komplizierter/verwirrender, als der aktuelle Vorschlag.
Wenn sendStack auch auf FHEM-Befehle umgestellt waere, dann wuerde wir wieder bei einer komplizierter Variante landen.

mal ein kleines "was wäre wenn": Device soll mal ein WakeUp-Gerät mit Security sein das "eingeschlafen" ist.

1. unverschlüsselter Befehl wird ausgelöst -> landet geparst im Sendstack
2. verschlüsselter Befehl wird ausgelöst -> Befehl wird geparst, aber "abgefangen" und auf meinen security-Stack gelegt
3. unverschlüsseltes Anfordern der NONCE für den verschlüsselten Befehl aus 2 -> landet geparst im Sendstack

Hierdurch beginnt jetzt eine Security-Kommunikation, die neue Variable "secInProgress" wird gesetzt, neue Befehle werden in ZWave_Set/Get ungeparst auf einen neuen secStack geschoben.

4. Egal welche Befehle (unverschlüsselt oder verschlüsselt) jetzt noch erzeugt werden, diese landen alle auf dem neuen secStack

5. Irgendwann kommt dann mal eine WU-Notification
6. Sendstack wird abgearbeitet -> unverschlüsselter Befehl aus 1 wird gesendet
7. Anforderung der NONCE aus Schritt 3, Befehl wird gesendet
8. NONCE wird vom Gerät empfangen
9. Befehl aus 2 wird mit NONCE verschlüsselt und gesendet

Problem #1: da der Befehl bereits geparst abgefangen und gespeichert wurde, ist jetzt nicht mehr klar ob es ein SET oder ein GET war! D.h. in der momentanen Implementierung ist nicht klar ob eine Antwort erwartet wird oder nicht.

10. Ende der Security-Kommunikation wird (irgendwie) erkannt, "secInProgress" kann wieder gelöscht werden.
11. Aufruf von ZWave_processSecStack um die weiteren im secStack gespeicherten Befehle abzuarbeiten. Diese werden aber erst jetzt geparst und versendet, falls ein verschlüsselter Befehl dabei war wird wieder "secInProgress" gesetzt...

Falls das Gerät eine Security-Nachricht schickt, kommt als erstes die Anfrage für eine NONCE, das wäre dann der Zeitpunkt secInProgress zu setzen, danach wäre es wieder wie oben...

Erste Erkenntnis: Ich werde meinen Stack um den Modus (Set oder Get) erweitern müssen um das Ende der Kommunikation erkennen zu können.
Zweite Erkenntnis: Die Routine zum Versenden einer verschlüsselten Nachricht sollte ich sowohl als Set- als auch als Get-Befehl implementieren
Dritte Erkenntnis: "Hinter" einem verschlüsselten Befehl könnten sich eine Menge Befehle ansammeln die dann erst nach Abarbeiten des verschlüsselten Befehls geparst werden.
Vierte Erkenntnis: Time-Out, CAN, NO_ACK etc. muss ich auch irgendwie zuverlässig erkennen.

Abgesehen von "meinem" Problem #1 sehe ich momentan nichts, was gegen eine solche Lösung sprechen würde.
(Mir wird nur gerade klar das bei GET-Befehlen aus WU-Stack keine ReadAnswerFn aufgerufen wird...)

Entspricht der Ablauf dem was Du Dir bei der Struktur gedacht hast?

Gruß,
Andreas.

Problem #1 verstehe ich nicht. Wozu muss man wissen, ob das urspruengliche Kommando ein get oder ein set ist?

Ich vermute, dass get ueber security bisher auch nicht funktioniert hat, und damit meine ich nicht die ZWave_Gets, die fuers Protokoll benoetigt werden (als secNonce, usw).

Hi Rudi,

Zitat von: rudolfkoenig am 13 Oktober 2015, 10:10:13
Problem #1 verstehe ich nicht. Wozu muss man wissen, ob das urspruengliche Kommando ein get oder ein set ist?

Ich vermute, dass get ueber security bisher auch nicht funktioniert hat, und damit meine ich nicht die ZWave_Gets, die fuers Protokoll benoetigt werden (als secNonce, usw).

ich muss ja nach Ende der Security-Kommunikation den normalen Ablauf durch löschen von secInProgress wieder freigeben. Dazu muss ich aber doch wissen ob ich nach dem Versenden der verschlüsselten Nachricht eine Antwort von dem Gerät erwarte oder nicht. Falls das ein verschlüsselter SET-Befehl ist kann ich direkt nach dem Transmit-OK secInProgress freigeben, bei einem verschlüsseltem GET-Befehl muss ich die Antwort abwarten (inklusiver der ganzen Nonce-Kommunikation).

Oder wie würdest Du entscheiden das secInProgress gelöscht werden kann, vielleicht übersehe ich ja was ganz offensichtliches...

Gruß,
Andreas.

Ok, ich meine das Problem zu verstehen.

Ich behaupte, dass get mit security sowieso nicht funktionieren kann, jedenfalls nicht so wie es z.Zt. implementiert ist und damit meine ich nicht die security-Implementierung, sondern die Schleife in ZWave_Cmd. Habe keine gute Idee, die Beste ist get komplett abzuschaffen.

Hallo Rudi,

Zitat von: rudolfkoenig am 13 Oktober 2015, 10:45:25
Ok, ich meine das Problem zu verstehen.

Ich behaupte, dass get mit security sowieso nicht funktionieren kann, jedenfalls nicht so wie es z.Zt. implementiert ist und damit meine ich nicht die security-Implementierung, sondern die Schleife in ZWave_Cmd. Habe keine gute Idee, die Beste ist get komplett abzuschaffen.

die Unterscheidung in GET- und SET-Befehle finde ich aber weiterhin sinnvoll. Damit kann/sollte man unterscheiden ob eine Antwort erwartet wird oder nicht.

Mein Vorschlag wäre daher eher die Struktur mit ReadAnswerFn durch eine Struktur mit "secInProgress" zu ersetzen, wobei man das dann in "communicationInProgress" ändern könnte ,-)

Falls man die Befehle auf dem Stack dann noch durch "get" bzw. "set" erweitert könnte man das ganze durchgehend sogar für Nachrichten auf dem WakeUp Stack unterscheiden.

Man müsste dann beim Versenden eine Funktion triggern die entweder auf Transmit_OK wartet, oder auf Transmit_OK und die nächste Nachricht, je nach set oder get, und diesen Status an eine Kontrollebene zurückmeldet. Im fall von Security müssen ja mehrere Nachrichten versendet werden und nicht nur eine.

Wie im anderen Thread geschrieben sollte das ganze wohl überlegt sein...

Gruß,
Andreas.

Netter Plan, ich kapiere es nur nicht welches Problem er loesen soll.

Hi Rudi,

wenn Du die bisherige GET-Implementierung mit dem ReadAnswerFn rauswirst ohne eine ähnliche Funktion einzubauen, werden die Befehle einfach hintereinander rausgeschickt, ohne das auf evtl. Antworten Rücksicht genommen wird.

Meinem Verständnis nach wird ein Gerät aber eine neue Nachricht abweisen solange das Gerät noch eine Antwort bearbeitet und diese vom Gerät nicht verschickt wurde.

Also Abfrage eines Configwertes (GET-Befehl) und verschicken eines weiteren Befehls bevor die Antwort auf diese Abfrage verschickt wurde muss nach ZWave-Protokoll dazu führen das der zweite Befehl nicht aktzeptiert wird. Hier bin ich bisher davon ausgegangen das dies durch eine CAN-Msg geschieht.

Und ich rede hier nicht von einem Verschicken bevor der Empfang quitiert wurde.
Ich bin daher weiterhin der Meinung das bei GET-Befehlen auch eine Ablaufsteuerung nötig ist um hier kein laufende Kommunikation zu stören.

Vielleicht bekomme ich so einen Fall ja mal provoziert indem ich den ganzen ReadAnswerFn Teil mal deaktiviere und entsprechende Nachrichten erzeuge.

Gruß,
Andreas.

Hi,

hier mal ein Test bei dem der gesamte Code in der Behandlung für "get" auskommentiert ist:
  if($type eq "get") {
    # no strict "refs";
    # my $iohash = $hash->{IODev};
    # my $fn = $modules{$iohash->{TYPE}}{ReadAnswerFn};
    # my $re = $cmdList{$cmd}{regexp};
    # my ($err, $data) = &{$fn}($iohash, $cmd, $re ? $re : "^000400${id}..$cmdId")
    #                     if($fn);
    # use strict "refs";
    #
    # return $err if($err);
    # $data = "$cmd $id $data" if($re);
    #
    # $val = ($data ? ZWave_Parse($iohash, $data, $type) : "no data returned");

  } else {


Ich habe dann mal bei dem Steckdosenschalter ohne Security mehrmals (4x) auf get powerlevel geklickt:
2015.10.13 21:48:42.283 2: ZWave get ZWave_SWITCH_BINARY_158 powerlevel
2015.10.13 21:48:42.283 5: ZWDongle_Write 00 139e027302259e
2015.10.13 21:48:42.283 5: SW: 010900139e027302259eb3
2015.10.13 21:48:42.467 2: ZWave get ZWave_SWITCH_BINARY_158 powerlevel
2015.10.13 21:48:42.643 2: ZWave get ZWave_SWITCH_BINARY_158 powerlevel
2015.10.13 21:48:42.834 2: ZWave get ZWave_SWITCH_BINARY_158 powerlevel
2015.10.13 21:48:43.283 5: ACK received, removing 010900139e027302259eb3 from dongle sendstack
2015.10.13 21:48:43.303 4: ZWDongle_Read ZWDongle_0: sending ACK, processing 011301
2015.10.13 21:48:43.303 5: SW: 06
2015.10.13 21:48:43.304 5: ZWDongle_0 dispatch 011301
2015.10.13 21:48:43.324 4: ZWDongle_Read ZWDongle_0: sending ACK, processing 00139e000002
2015.10.13 21:48:43.324 5: SW: 06
2015.10.13 21:48:43.326 5: ZWDongle_0 dispatch 00139e000002
2015.10.13 21:48:43.326 4: ZWDongle_0 CMD:ZW_SEND_DATA ID:00 ARG:0002
2015.10.13 21:48:43.326 4: ZWDongle_0 transmit OK for 9e
2015.10.13 21:48:43.326 5: ZWDongle_Write 00 139e027302259e
2015.10.13 21:48:43.326 5: SW: 010900139e027302259eb3

Hier wird der zweite Befehl gesendet BEVOR die Antwort auf das erste Get da ist. Aber "sauber" nach dem transmit OK... Also z.B. nicht zwischen Senden und ACK.

2015.10.13 21:48:43.357 4: ZWDongle_Read ZWDongle_0: sending ACK, processing 0004009e0473030000
2015.10.13 21:48:43.357 5: SW: 06
2015.10.13 21:48:43.359 5: ZWDongle_0 dispatch 0004009e0473030000
2015.10.13 21:48:43.359 4: ZWDongle_0 CMD:APPLICATION_COMMAND_HANDLER ID:9e ARG:0473030000
2015.10.13 21:48:43.360 4: ZWDongle_Read ZWDongle_0: CAN received
2015.10.13 21:48:44.360 2: ZWDongle_ProcessSendStack: no ACK, resending message 010900139e027302259eb3
2015.10.13 21:48:44.360 5: SW: 010900139e027302259eb3
In der Folge kommt dann erst die Antwort, dann wird aber ein CAN für den zu früh gesendeten Get-Befehl empfangen und er muss neu gesendet werden. Ich denke das stützt meine Theorie das man nicht zwischen Frage und Antwort senden sollte und das die CAN-Msg eher vom Gerät kommen als vom Dongle.

Das System "fängt" sich mit den Re-sends zwar wieder, d.h. auf die 4 Get gibt es letztendlich auch 4 Antworten, bei mehr Störungen wird das aber anders aussehen Datenverlust ist recht wahrscheinlich.

Gruß,
Andreas.

Hallo Rudi,

Zitat von: rudolfkoenig am 13 Oktober 2015, 13:41:49
Netter Plan, ich kapiere es nur nicht welches Problem er loesen soll.

wie stehst Du denn jetzt zu meiner Theorie mit der CAN-Msg und dem Senden zwischen SET-Befehl und REPORT-Antwort? Ich gebe ja zu das die meisten Antworten so schnell kommen das die Wahrscheinlichkeit da noch eine weitere Nachricht zu erzeugen nicht so groß ist.

Ich würde ja am liebsten den gesamten Ablauf auf steuerbare Stacks umstellen (und nicht nur die SECURITY), allerdings fehlt mir da etwas der Einstieg wie ich auf eine Antwort warten kann ohne FHEM zu blockieren und im Fall von anderen Störungen im Ablauf z.B. eintreffen eine Nachricht vom Sensor während auf eine Antwort gewartet wird, nicht aus dem ganzen Ablauf rauszufliegen...

Dazu würde mir nur gerade nur was mit InternalTimer einfallen, und bei den Timern habe ich noch nicht wirklich begriffen wie das da mit mehreren gleichzeitigen Timern aussehen würde, bzw. ob das überhaupt zu kontrollieren ist...

Ich habe aber auch gerade Deinen Thread zu FHEM 5.7 gesehen und denke das Du da recht beschäftigt bist. Und das ist sicherlich nichts was man da noch schnell reinbauen sollte...
Es wäre aber hilfreich für mich, wenn Du noch mal kurz Deine Meinung bzw. Deine Pläne beschreiben könntest, damit ich mir in die Richtung auch schon mal weitere Gedanken machen kann.

Gruß,
Andreas.

Zitatwie stehst Du denn jetzt zu meiner Theorie mit der CAN-Msg und dem Senden zwischen SET-Befehl und REPORT-Antwort?

Ich glaube nicht daran :) Wenn es stimmen wuerde, dann waeren CallbackIds ueberfluessig.

5.7 sollte nicht so viel Aufwand erzeugen, es ist eher ein Aufruf an die Anderen, nicht jetzt mit grundlegenden Umbaus anzufangen. Ich wuerde aber meinen Sec-Umbau Vorschlag nicht als grundlegend betrachten, da es nur sec betrifft, was bisher auch nicht 100% tut. Apropos: koenntest du mir sagen, was mit sec z.Zt. tut, und was nicht?

Hi Rudi,

Zitat von: rudolfkoenig am 16 Oktober 2015, 14:37:09
Ich glaube nicht daran :) Wenn es stimmen wuerde, dann waeren CallbackIds ueberfluessig.

hmm, das Argument kann ich auf Anhieb nicht entkräften...
Aber wie erklärst Du Dir die CAN-Msg wenn man dazwischen sendet? Wir bräuchten mal einen "Sniffer"...

Zitat von: rudolfkoenig am 16 Oktober 2015, 14:37:09
5.7 sollte nicht so viel Aufwand erzeugen, es ist eher ein Aufruf an die Anderen, nicht jetzt mit grundlegenden Umbaus anzufangen. Ich wuerde aber meinen Sec-Umbau Vorschlag nicht als grundlegend betrachten, da es nur sec betrifft, was bisher auch nicht 100% tut. Apropos: koenntest du mir sagen, was mit sec z.Zt. tut, und was nicht?

Also eigentlich gibt es mMn nur die Probleme mit der fehlenden Ablaufsteuerung, d.h. wenn neue Befehle dazwischenkommen. Das endet eigentlich immer mit CAN-Msg, wobei dann auch recht schnell Datenverlust auftritt.

Funktional ist in SECURITY nur noch offen das überlange Nachrichten nicht in zwei Teile gespilittet gesendet werden. Das ist aber in OpenZWave auch nicht implementiert und bisher hat es da wohl auch keinen Bedarf für gegegeben. Das würde ich mir mal vornehmen sobald es da ein Anwendungsfall gibt. Der Empfang von solchen zweigeteilten Nachrichten ist implementiert und funktioniert einwandfrei.

Status also: Funktioniert, sollte aber vorläufig nur eingesetzt werden wenn man weiß auf was man sich dabei einlässt.

Wenn Du die Änderungen mit dem sec-Stack als nicht so grundlegend betrachtest würde ich sagen das wir mit so einem System mal in's Rennen gehen. Du könntest mir ja einen Patch zur Verfügung stellen mit dem ich dann die weiteren Anpassungen machen kann bevor das dann gesamt implementiert wird. Mir würde es wahrscheinlich auch reichen wenn Du die grundlegende Struktur für den secStack so implementierst wie Du Dir das gedacht hast, den Rest drumherum bekomme ich dann schon hin.

Gruß,
Andreas.

Ich habe meinen Vorschlag implementiert.
- Dabei verwendet man ZWave_secStart($hash) vor dem ersten SECURITY relevanten Befehl, und ZWave_secEnd($hash), wenn man keine Daten mehr erwartet.
- ich habe im Security Abschnitt alle ZWave_Get/ZWave_Set Befehle auf ZWave_CMD umgestellt
- ich habe auch schon ZWave_secStart/ZWave_secEnd Aufrufe eingebaut, bin aber unsicher, ob die richtig sind.
- es fehlt sicher noch ein ZWave_secEnd, wenn irgendetwas schiefgeht, z.Bsp. wenn die andere Seite nicht antwortet.
- ich kann es leider nicht richtig testen, immerhin werden die verschluesselten Meldungen meines KFOBs weiterhin entschluesselt, und ich kann bei "normalen" Geraeten auch nichts schlimmes feststellen.

Weiterhin habe ich manche Security Relevante Funktionen umbenannt, so dass alles mit ZWave_sec beginnt.

Hallo Rudi,

Zitat von: rudolfkoenig am 25 Oktober 2015, 20:04:16
Ich habe meinen Vorschlag implementiert.

vielen Dank schon mal, damit erübrigt sich meine Bitte in dem anderen Thread das noch mal zu erklären... ,-)

Zitat von: rudolfkoenig am 25 Oktober 2015, 20:04:16
- Dabei verwendet man ZWave_secStart($hash) vor dem ersten SECURITY relevanten Befehl, und ZWave_secEnd($hash), wenn man keine Daten mehr erwartet.
- ich habe im Security Abschnitt alle ZWave_Get/ZWave_Set Befehle auf ZWave_CMD umgestellt
- ich habe auch schon ZWave_secStart/ZWave_secEnd Aufrufe eingebaut, bin aber unsicher, ob die richtig sind.
- es fehlt sicher noch ein ZWave_secEnd, wenn irgendetwas schiefgeht, z.Bsp. wenn die andere Seite nicht antwortet.
- ich kann es leider nicht richtig testen, immerhin werden die verschluesselten Meldungen meines KFOBs weiterhin entschluesselt, und ich kann bei "normalen" Geraeten auch nichts schlimmes feststellen.

Ok, ich werde mir das dann mal ansehen, allerdings geht das bei mir leider erst ab Ende nächster Woche wieder intensiver. Hört sich aber doch schon sehr vielversprechend an.

Falls zwischendurch noch jemand testen könnte (und auch berichtet) wäre das natürlich hilfreich!

Danke,
Andreas.

Wenn Ihr mir vorgebt, was/womit ich testen soll, dann mache ich das....

Hi Krikan,

da ich noch nicht genau überblicke was Rudi da im einzelnen gemacht hat wären "normale" Funktionstests denke ich ausreichend. Solange alles funktioniert wie vorher ist ja erst mal alles in Ordnung.
So lange keine Auffälligkeiten auftreten hätte ich keine expliziten Anforderungen. WakeUp-Geräte wären natürlich interessant...

Ich habe jetzt nur mal ganz kurz über den Code geschaut und wollte gerade auch mal anfangen ein wenig mit auszuprobieren.

Gruß,
Andreas.

Hallo Rudi,
meine ersten Tests sehen leider schlecht aus... Sobald ich Befehle an ein security Gerät schicke wird secStack akitv und alle Befehle werden auf den Stack gelegt aber nicht mehr weiter bearbeitet.
2015.10.25 21:28:28.974 2: ZWave set ZWave_SENSOR_MULTILEVEL_168 configBatteryReportingThreshold
2015.10.25 21:28:28.974 1: configBatteryReportingThreshold: Secure operation in progress, executing in background
2015.10.25 21:28:28.974 2: ZWave set ZWave_SENSOR_MULTILEVEL_168 configCommandOptions
2015.10.25 21:28:28.974 1: configCommandOptions: Secure operation in progress, executing in background
2015.10.25 21:28:28.975 2: ZWave set ZWave_SENSOR_MULTILEVEL_168 configEnableDisableLockConfiguration
2015.10.25 21:28:28.975 1: configEnableDisableLockConfiguration: Secure operation in progress, executing in background
2015.10.25 21:28:28.975 2: ZWave set ZWave_SENSOR_MULTILEVEL_168 configEnableMotionSensor
2015.10.25 21:28:28.975 1: configEnableMotionSensor: Secure operation in progress, executing in background
2015.10.25 21:28:28.975 2: ZWave set ZWave_SENSOR_MULTILEVEL_168 configGroup1Interval
2015.10.25 21:28:28.975 1: configGroup1Interval: Secure operation in progress, executing in background
2015.10.25 21:28:28.975 2: ZWave set ZWave_SENSOR_MULTILEVEL_168 configGroup1Reports
2015.10.25 21:28:28.976 1: configGroup1Reports: Secure operation in progress, executing in background
2015.10.25 21:28:28.976 2: ZWave set ZWave_SENSOR_MULTILEVEL_168 configGroup2Interval
2015.10.25 21:28:28.976 1: configGroup2Interval: Secure operation in progress, executing in background
2015.10.25 21:28:28.976 2: ZWave set ZWave_SENSOR_MULTILEVEL_168 configGroup2Reports
2015.10.25 21:28:28.976 1: configGroup2Reports: Secure operation in progress, executing in background
2015.10.25 21:28:28.976 2: ZWave set ZWave_SENSOR_MULTILEVEL_168 configGroup3Interval
2015.10.25 21:28:28.976 1: configGroup3Interval: Secure operation in progress, executing in background
2015.10.25 21:28:28.977 2: ZWave set ZWave_SENSOR_MULTILEVEL_168 configGroup3Reports
2015.10.25 21:28:28.977 1: configGroup3Reports: Secure operation in progress, executing in background
2015.10.25 21:28:28.977 2: ZWave set ZWave_SENSOR_MULTILEVEL_168 configHumidityCalibration
2015.10.25 21:28:28.977 1: configHumidityCalibration: Secure operation in progress, executing in background
2015.10.25 21:28:28.978 2: ZWave set ZWave_SENSOR_MULTILEVEL_168 configHumidityReportingThreshold
2015.10.25 21:28:28.978 1: configHumidityReportingThreshold: Secure operation in progress, executing in background
2015.10.25 21:28:28.978 2: ZWave set ZWave_SENSOR_MULTILEVEL_168 configLowBattery
2015.10.25 21:28:28.979 1: configLowBattery: Secure operation in progress, executing in background
2015.10.25 21:28:28.979 2: ZWave set ZWave_SENSOR_MULTILEVEL_168 configLowTempAlarm
2015.10.25 21:28:28.979 1: configLowTempAlarm: Secure operation in progress, executing in background
2015.10.25 21:28:28.980 2: ZWave set ZWave_SENSOR_MULTILEVEL_168 configLuminanceCalibration
2015.10.25 21:28:28.980 1: configLuminanceCalibration: Secure operation in progress, executing in background
2015.10.25 21:28:28.980 2: ZWave set ZWave_SENSOR_MULTILEVEL_168 configLuminanceReportingThreshold
2015.10.25 21:28:28.981 1: configLuminanceReportingThreshold: Secure operation in progress, executing in background
2015.10.25 21:28:28.981 2: ZWave set ZWave_SENSOR_MULTILEVEL_168 configOnTime
2015.10.25 21:28:28.981 1: configOnTime: Secure operation in progress, executing in background
2015.10.25 21:28:28.981 2: ZWave set ZWave_SENSOR_MULTILEVEL_168 configReportingThreshold
2015.10.25 21:28:28.981 1: configReportingThreshold: Secure operation in progress, executing in background
2015.10.25 21:28:28.981 2: ZWave set ZWave_SENSOR_MULTILEVEL_168 configTemperatureCalibration
2015.10.25 21:28:28.982 1: configTemperatureCalibration: Secure operation in progress, executing in background
2015.10.25 21:28:28.982 2: ZWave set ZWave_SENSOR_MULTILEVEL_168 configTemperatureReportingThreshold
2015.10.25 21:28:28.982 1: configTemperatureReportingThreshold: Secure operation in progress, executing in background
2015.10.25 21:28:28.982 2: ZWave set ZWave_SENSOR_MULTILEVEL_168 configUVReportingThreshold
2015.10.25 21:28:28.982 1: configUVReportingThreshold: Secure operation in progress, executing in background
2015.10.25 21:28:28.982 2: ZWave set ZWave_SENSOR_MULTILEVEL_168 configUltravioletCalibration
2015.10.25 21:28:28.982 1: configUltravioletCalibration: Secure operation in progress, executing in background
2015.10.25 21:28:28.982 2: ZWave set ZWave_SENSOR_MULTILEVEL_168 configWakeUp10MinutesOnPowerOn
2015.10.25 21:28:28.982 1: configWakeUp10MinutesOnPowerOn: Secure operation in progress, executing in background

Danach passiert dann gar nichts mehr. Ein Set-Befehl endet ebenso im Nirvana.

Ich habe aber jetzt leider nur SEHR wenig Zeit da zu debuggen. Vielleicht ist es sinnvoller das Update morgen nicht zu verteilen...

Gruß,
Andreas.

Hi Rudi,

Du hattest ein ZWave_Get übersehen...
Patch ist angehängt. Damit läuft die Kommunikation erst mal, allerdings endet ein ConfigRequestAll natürlich immer noch in jeder Menge CAN-Msg und Time-Out.
Da muss ich dann auf jeden Fall noch weiter nachschauen. Mehr kann ich jetzt aber nicht mehr machen.

Gruß,
Andreas

Den Patch habe ich eingespielt.

Dass du beim configRequestAll CAN bekommst bedeutet, dass man man keine Befehle an dem Endgeraet schicken darf, wenn das Endgeraet selbst Daten schicken will.

Das Problem bei configRequestAll koennte man mit einer Ausnahme umgehen (kein secEnd bei config... request, habs eingecheckt, bitte testen), generell sehe ich aber ein Problem, und keine Loesung. Ideen?

Zitat von: rudolfkoenig am 26 Oktober 2015, 10:29:27
... man man keine Befehle an dem Endgeraet schicken darf, wenn das Endgeraet selbst Daten schicken will.
... generell sehe ich aber ein Problem, und keine Loesung. Ideen?

Verstehe ich das richtig:
Dann muss bei allen Befehlen (unabhängig von SECURITY) , die von Fhem an ein Endgeraet geschickt werden, auf die Antwort gewartet werden, bevor ein neuer Befehl verschickt wird. Nur dann kann man doch diese CANs verhindern.
Und dann (neuer Versuch  ;) ): Fortlaufende Callback-Ids zur Befehl-Antwort-Zuordnung.

Hi Rudi,

Zitat von: rudolfkoenig am 26 Oktober 2015, 10:29:27
Den Patch habe ich eingespielt.

Danke!

Zitat von: rudolfkoenig am 26 Oktober 2015, 10:29:27
Dass du beim configRequestAll CAN bekommst bedeutet, dass man man keine Befehle an dem Endgeraet schicken darf, wenn das Endgeraet selbst Daten schicken will.

Ich sag' ja das man zwischen einem GET und dem daraus resultieren REPORT vom Gerät nichts senden darf da sonst CAN Msg erzeugt werden die dann ab einer gewissen Menge an erzeugtem Chaos durch die Timeouts zu Datenverlust führen.

Zitat von: rudolfkoenig am 26 Oktober 2015, 10:29:27
Das Problem bei configRequestAll koennte man mit einer Ausnahme umgehen (kein secEnd bei config... request, habs eingecheckt, bitte testen), generell sehe ich aber ein Problem, und keine Loesung. Ideen?

Noch keine zu Ende gedachte Idee, aber für die Security Sachen werde ich mir einen Status anlegen müssen ob die akutelle Kommunikation noch läuft. Abhängig davon muss dann das secEnd gesteuert werden. Dabei muss ich auch mal überlegen was passiert wenn das Gerät einen GET-NONCE schickt und damit die Kommunikation startet.

Über secStart / secEnd kann jetzt ja kontrolliert werden das keine weiteren "non-security" Befehle mehr abgearbeitet werden, laufenden Security Kommunikationen können sich aber weiterhin untereinander stören wenn das secEnd "zu früh" kommt.

Ich habe diese Woche jetzt jeden Tag ganztägig Kundenbesuch und kann daher nicht viel machen. Ich werde mich aber am WE mal etwas näher mit dem Ablauf befassen und mal versuchen alle Möglichen Varianten einer Kommunikation (nur SET, Get mit "einteiliger" Antwort, Get mit "zweiteiliger" Antwort, eingehende Nachrichten vom Gerät, Time-out,...) mal aufzumalen und zu schauen ob bzw. an welchen Stellen sich da eine Steuerung realisieren lässt.

Problematisch sehe ich da gerade den Fall das eine ankommende verschlüsselte Nachricht auf jeden Fall abgearbeitet wird, selbst wenn secStart aktiv ist. Das wäre übrigens auch eine Stelle wo eine ID hilfreich wäre ,-)

Falls wärend einer security-Kommunikation das Gerät etwas verschicken möchte, schickt es erst mal einen GET-NONCE. Das passiert während einer laufenden Kommunikation natürlich auch mehrmals, hier wäre die ID Möglichkeit zu erkennen das es sich hier um eine NEUE Kommunikation handelt. Ob das kriegsentscheidend ist kann ich momentan nicht sagen, die NONCE wird ja in jedem Fall verschickt, es kommt dann nur nicht die erwartete Antwort sondern eine andere Nachricht vom Gerät.

Gruß,
Andreas.

@Christian: Neuer Versuch abgelehnt :) Wenn ich weiss, dass Geraet X nur ein ausstehendes Befehl haben darf, dann brauche ich gar kein CallbackId, da ich das Geraete-Id zusaetzlich kriege.

@Andreas: keine Hektik. Deine CANs sind in meinen Augen noch kein Beweis, evtl. haengt das auch mit deinem USB-Stick zusammen.

ZitatProblematisch sehe ich da gerade den Fall das eine ankommende verschlüsselte Nachricht auf jeden Fall abgearbeitet wird, selbst wenn secStart aktiv ist. Das wäre übrigens auch eine Stelle wo eine ID hilfreich wäre ,-)

Ich glaube das musst du mir ganz detailliert aufmalen. Nach meinem Verstaendnis kollidiert das naemlich mit deiner CAN Theorie: zwei Nachrichten in parallel kann (dein? / der) Kontroller nicht ab, ID hin oder her.

Kann mir jemand einen Aktor empfehlen, was SECURITY kann? Muss nicht superteuer sein.

Zitat von: rudolfkoenig am 26 Oktober 2015, 11:45:47
Kann mir jemand einen Aktor empfehlen, was SECURITY kann? Muss nicht superteuer sein.

Probiere vielleicht mal, ob AEOTEC Dich mit Mustern versorgt: http://aeotec.com/z-wave-gateways (unter Z-Wave gateway program).
Openzwave bekommt die wohl und warum dann nicht auch wir. Nennung von Fhem auf der Seite wäre auch OK. Selbst openhab wird schon gelistet und die können mMn noch überhaupt kein SECURITY...

Hi Rudi

Zitat von: rudolfkoenig am 26 Oktober 2015, 11:45:47
@Andreas: keine Hektik. Deine CANs sind in meinen Augen noch kein Beweis, evtl. haengt das auch mit deinem USB-Stick zusammen.

ich will da auch keine Hektik machen. Mag sein das es mit dem Stick zusammenhängt, ich sehe es aber eher als eine Grundeigenschaft der Gerätekommunikation. Es kann mMn immer nur EINE aktive Kommunikation geben. Ich muss mir den Pätz da noch mal ansehen, ich denke das er das auch irgendwo so beschrieben hatte.

Wie dem auch sei, das unkoordinierte Senden ist auf jeden Fall mindestens "unschön" und sollte vermieden werden.

Zitat von: rudolfkoenig am 26 Oktober 2015, 11:45:47
Ich glaube das musst du mir ganz detailliert aufmalen. Nach meinem Verstaendnis kollidiert das naemlich mit deiner CAN Theorie: zwei Nachrichten in parallel kann (dein? / der) Kontroller nicht ab, ID hin oder her.

Das  kollidiert nicht mit meiner Theorie, zumindest nicht in meinem Kopf ,-)
Fallbeispiel:
Get-Befehl auf Sensor:
1. GET-Nonce wird gesendet
2. Gerät antworten mit NONCE-REPORT
3. verschlüsselter Get-Befehl wird gesendet
4. Gerät schickt GET-NONCE
5. NONCE-REPORT wird verschickt
6. Gerät verschickt verschlüsselten Report

Falls nun während der Kommunikation z.B. ein Bewegungsmelder eine Bewegung meldet, muss dazu als erstes eine Nonce angefordert werden -> Gerät schickt GET-NONCE.
Falls das nun (zufällig) zwischen Schritt 3. und Schritt 4. passiert ist nicht klar ob der GET-NONCE Befehl zu der laufenden Kommunikation gehört oder eine neue Anfrage ist.

Das wird sicherlich nicht sehr oft vorkommen würde aber nach meinem momentanen Verständnis dazu führen das die laufende Kommunikation verloren geht.

Zitat von: rudolfkoenig am 26 Oktober 2015, 11:45:47
Kann mir jemand einen Aktor empfehlen, was SECURITY kann? Muss nicht superteuer sein.

Ich habe da leider auch nur die Sirene, und die ist nur bedingt zum "Ausprobieren" geeignet... Ansonsten habe ich diesen 6fach Sensor von AEOTEC, ist aber eben kein Aktor.

Ich würde insgesamt aber vorschlagen das ich mir die potenziell möglichen Abläufe mal in Ruhe aufmale und dann schaue was sich da als Steuerung für den Stack realisieren lässt. Ich denke schon das sich da eine Lösung finden lässt.

Gruß,
Andreas.

ZitatProbiere vielleicht mal, ob AEOTEC Dich mit Mustern versorgt:

Habs probiert, warten wir mal ab.

@Andreas: ja, das habe ich auch so verstanden. Allerdings wuerde mich wundern, wenn das, was du beschreibst, funktioniert, aber eine nur leicht andersartige parallele Kommmunikation (wg. CAN) nicht.
Oder auch: wo ist das Unterschied zwischen Antwort auf Frage vs. freiwillige Meldung von Daten.

Aber ich sehe ein, das wir in diesem Fall eine bessere CallbackId-Vergabe brauchen wuerden :)

Hi Rudi,

Zitat von: rudolfkoenig am 26 Oktober 2015, 13:32:29
@Andreas: ja, das habe ich auch so verstanden. Allerdings wuerde mich wundern, wenn das, was du beschreibst, funktioniert, aber eine nur leicht andersartige parallele Kommmunikation (wg. CAN) nicht.
Oder auch: wo ist das Unterschied zwischen Antwort auf Frage vs. freiwillige Meldung von Daten.

Das würde auch nicht funktionieren, eigentlich müsste da ja dann von FHEM ein CAN erzeugt werden... (oder die Kommunikation müsste noch mal gestartet werden)
Aber das ist erst mal recht unwahrscheinlich, daher würde ich das auch erst mal außen vor lassen.

Unterschied zwischen Frage-Antwort und Meldung von Daten gibt es eigentlich nicht, außer das Gerät meint genau zwischen Frage-Antwort lieber eine Meldung statt der ausstehenden Antwort zu schicken. Was ja durchaus eine Frage der Priorität ist und daher gerechtfertigt sein kann. Ich meine das damals in Logfiles von Krikan gesehen zu haben. Damals gingen die Nachrichten aber noch mehr durcheinander...

Gruß,
Andreas.

@Christian: Aeon Labs wollen mir einen Zwischenstecker (http://www.pepper1.net/zwavedb/device/722) schicken, und der Zustaendige wollte wissen, wo man sich bei Pepper beschwert, weil deren Angaben ueber die Security-Klassen falsch sind. Hast du eine Idee?

Btw. auch die openzwave config Eintraege (aeon/ss6.xml) sind laut den Produkt-Beiblatt falsch, aber das korriegiere ich erst, wenn ich das verifizieren kann.

Zitatund der Zustaendige wollte wissen, wo man sich bei Pepper beschwert, weil deren Angaben ueber die Security-Klassen falsch sind. Hast du eine Idee?

Nicht wirklich, nur Standard(not)lösung: http://www.pepper1.net/en/contact .

Submitter des Eintrages bei pepper1 ist mWn Dr. Christian Paetz himself und die Einträge bei ozw (aeon/ss6.xml) sind vom ozw-Hauptentwickler Justin Hammond , der von AEOTEC auch u.a. den Zwischenstecker bekommen hat. Sind die Abweichungen evtl. gleich und AEOTEC hat nur einen neue Version herausgebracht?

Unwahrscheinlich:
- in pepper sind in der security Spalte die Klassen aufgefuehrt, die bei secure inclusion ohne security nutzbar sind
- in deviceconfig ist einmal hex mit dezimal verwechselt (14 vs 20), und bei der Farbkonfiguration sind 4 Items definiert mit den Werten 1-4 fuer none/red/green/blue, richtig waere mAn ein long, mit byte2=red, byte3=green, byte4=blue. Die anderen habe ich nicht geprueft.

Zitat von: rudolfkoenig am 29 Oktober 2015, 15:01:17
- in deviceconfig ist einmal hex mit dezimal verwechselt (14 vs 20), und bei der Farbkonfiguration sind 4 Items definiert mit den Werten 1-4 fuer none/red/green/blue, richtig waere mAn ein long, mit byte2=red, byte3=green, byte4=blue. Die anderen habe ich nicht geprueft.

Dann sollte ich mal schauen, dass ich endlich mal Korrekturen an ozw liefern kann...

@Andreas: Logs kommen noch; hoffe ich schaffe es heute.

Hi Krikan,

keine Panik mit den Logs, habe gerade 4 Tage full-time Kundenmeeting hinter mir, mein Firmenlaptop ist abgeraucht und meine DSL-Leitung zu Hause hat(te) sich verabschiedet... Seit heute mittag läuft die zwar wieder, allerdings nur mit 6Mbit...

Ich hab' also eh frühestens am Sonntag Zeit dazu.

Gruß,
Andreas.

Hi Rudi,

in den Funktionen für ConfigRequestAll und AssociationRequest wurden bislang noch ZWave_CMD ("set", ...) Aufrufe verwendet, mMn müssten dort auch ZWave_Set verwendet werden, da die Befehle ansonsten an dem neuen Stack vorbei laufen...
Kleinen Patch habe ich angehängt.

Auch mit dieser Änderungen gehen bei dem 6fach Sensor immer noch 4 config-Requests wegen CAN + Timeout verloren. Ohne die Änderungen waren es sogar noch mehr...

Ablauf schaue ich mir jetzt auch noch mal genauer an.

Gruß,
Andreas.

Habs eingecheckt.

Hi Rudi,

Zitat von: rudolfkoenig am 31 Oktober 2015, 14:58:37
Habs eingecheckt.

danke, ich habe noch einen kleinen Patch angehängt. Der sorgt normalerweise dafür das bei GET-Befehlen secEND nicht vorzeitig aufgerufen wird.

Hier habe ich allerdings eine Frage/Problem:
Ist es zwingend nötig die Befehle aus "ConfigRequestAll" als SET-Befehle zu senden? Das führt nämlich dazu das hier das secEnd zu früh ausgelöst wird und dann die Befehle doch durcheinander geraten.

Ich habe die Struktur, wie diese Befehle erzeugt werden, noch nicht so ganz durchschaut, bevor ich daran rumschraube wollte ich lieber mal erst mal fragen ob das einen "guten" Grund hat.

Damit das mit der Steuerung für Security funktionieren kann, muss die Zuordnung der Befehle zu  SET bzw. GET stimmen...

Gruß,
Andreas.

Hallo Rudi,

wenn ich zu Testzwcken einfach mal ganz stumpf den "type" auf get ändere falls $cfgReq gesetzt ist, dann läuft die Kommunikation störungsfrei durch. Ich kann dann bei dem Multisensor6 ein ConfigRequestAll durchlaufen lassen ohne das es zu Datenverlust, CAN oder Time-Out kommt.

Ich werde das nachher auch noch mal als WakeUp probieren, sehe da aber keinen prinzipiellen Unterschied.

  # Collect the commands from the distinct classes
  my %cmdList;
  my $classes = AttrVal($name, "classes", "");
  my $cfgReq = ($type eq "set" && $cmd =~ m/^config/ && @a && $a[0] eq "request");
  shift(@a) if($cfgReq);
  foreach my $cl (split(" ", $classes)) {
    my $ptr = ZWave_getHash($hash, $cl, $cfgReq ? "get" : $type);
    next if(!$ptr);

    foreach my $k (keys %{$ptr}) {
      if(!$cmdList{$k}) {
        $cmdList{$k}{fmt} = $ptr->{$k};
        $cmdList{$k}{id}  = $zwave_class{$cl}{id};
      }
    }
  }
  my $c=$cfgReq ? "1" : "0";
  Log3 $name, 5, "$name: cfgReq=$c type=$type";
  Log3 $name, 5, "$name: cmd=$cmd";
  if ($cfgReq) {
    $type="get";
  }


Gruß,
Andreas.

Hi,

Zitat von: A.Harrenberg am 01 November 2015, 11:11:42
Ich werde das nachher auch noch mal als WakeUp probieren, sehe da aber keinen prinzipiellen Unterschied.

den Kommentar muss ich leider zurücknehmen. Das System verklemmt sich irgendwie und es wird nur der erste (oder die ersten beiden?) Befehle abgearbeitet. Danach passiert erst mal gar nichts mehr ,-(

Da muss ich wohl etwas genauer analysieren...

Gruß,
Andreas.

Hab den Patch 9722b eingecheckt.

Hallo,
bezüglich meiner Probleme mit dem WakeUp,

Zitat von: A.Harrenberg am 01 November 2015, 12:12:16
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.

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.

Hi Rudi,

Zitat von: rudolfkoenig am 01 November 2015, 19:51:12
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.

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.

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.

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.

Habe beide patches ungeaendert eingecheckt.

Hi Rudi,

Zitat von: rudolfkoenig am 04 November 2015, 12:17:43
Habe beide patches ungeaendert eingecheckt.

Danke!
Hast Du meinen Thread mit dem NO_ACK bei WakeUp mit dem AEOTEC Multisensor6 (http://forum.fhem.de/index.php/topic,43457.msg354123.html#msg354123) gesehen? Einen Patch als Vorschlag hatte ich auch gepostet.

Gruß,
Andreas.

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

Hi,

mach ich.

Nicht untergehen...
Andreas.

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.

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.

Hi,

Zitat von: rudolfkoenig am 04 Januar 2016, 23:01:10
Habs grob angeschaut, muss aber evtl. mit klarerem Verstand es nochmal tun.

ja bitte... ,-)

Zitat von: rudolfkoenig am 04 Januar 2016, 23:01:10
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.

Zitat von: rudolfkoenig am 04 Januar 2016, 23:01:10
- 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.

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

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

Hi Rudi,

Zitat von: rudolfkoenig am 05 Januar 2016, 08:17:13
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?

Zitat von: rudolfkoenig am 05 Januar 2016, 08:17:13
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.

Ich hoffe, dass ist hier richtig:
Seit dem Update am 5.01.2016 (10_ZWave.pm) wird mir das Log mit diesen Meldungen "geflutet":
secUnlock will call Zwave_secEnd

Von den 8 Philio/Devolo/D-Link Kontakten sind "historisch" nur zwei mit Security inkludiert. Die Meldungen kommen nur von diesen beiden und immer nur dann wenn der jeweilige Sensor Status-Meldungen (Auf/Zu/Temperatur/etc) sendet. Fehlfunktionen kann ich bisher keine erkennen.

Edith: 10:32:01 war das Schließen des Fensters. 10:32.08 war der stündliche Status Report von Temperatur/Luminance. Das war Zufall.
Wenn ich das globale Log mit dem jeweiligen Filelog vergleiche, scheint die o.g. Meldung immer mit sieben Sekunden Verzögerung zu kommen.

Log (Fenster wieder geschlossen):

2016.01.07 10:32:01.496 4: ZWDongle_Read zw.dongle: sending ACK, processing 00040005029840
2016.01.07 10:32:01.497 5: SW: 06
2016.01.07 10:32:01.499 5: zw.dongle dispatch 00040005029840
2016.01.07 10:32:01.500 4: zw.dongle CMD:APPLICATION_COMMAND_HANDLER ID:05 ARG:029840
2016.01.07 10:32:01.506 5: ZWDongle_Write 0013050a98801ac1286b45b809cb2505 (e58b19ca)
2016.01.07 10:32:01.507 5: SW: 01110013050a98801ac1286b45b809cb25056d
2016.01.07 10:32:01.512 5: ACK received, WaitForAck=>2 for 01110013050a98801ac1286b45b809cb25056d
2016.01.07 10:32:01.517 4: ZWDongle_Read zw.dongle: sending ACK, processing 011301
2016.01.07 10:32:01.518 5: SW: 06
2016.01.07 10:32:01.520 5: zw.dongle dispatch 011301
2016.01.07 10:32:01.540 4: ZWDongle_Read zw.dongle: sending ACK, processing 001305000003
2016.01.07 10:32:01.541 5: SW: 06
2016.01.07 10:32:01.542 5: device ack reveived, removing 01110013050a98801ac1286b45b809cb25056d from dongle sendstack
2016.01.07 10:32:01.543 5: zw.dongle dispatch 001305000003
2016.01.07 10:32:01.544 4: zw.dongle CMD:ZW_SEND_DATA ID:00 ARG:0003
2016.01.07 10:32:01.544 4: zw.dongle transmit OK for 05
2016.01.07 10:32:01.582 4: ZWDongle_Read zw.dongle: sending ACK, processing 000400052d988164838b4ecc47394510eda224416cff215b12bda50ea37ff37b84443f2331b616cf681a1b5a5d5da020c3e9
2016.01.07 10:32:01.583 5: SW: 06
2016.01.07 10:32:01.585 5: zw.dongle dispatch 000400052d988164838b4ecc47394510eda224416cff215b12bda50ea37ff37b84443f2331b616cf681a1b5a5d5da020c3e9
2016.01.07 10:32:01.586 4: zw.dongle CMD:APPLICATION_COMMAND_HANDLER ID:05 ARG:2d988164838b4ecc47394510eda224416cff215b12bda50ea37ff37b84443f2331b616cf681a1b5a5d5da020c3e9
2016.01.07 10:32:01.589 4: zw.dongle CMD:APPLICATION_COMMAND_HANDLER ID:05 ARG:198f010403800364043003000a05310503011206310501220096
2016.01.07 10:32:08.510 3: secUnlock will call Zwave_secEnd
2016.01.07 10:32:08.692 4: ZWDongle_Read zw.dongle: sending ACK, processing 00040005029840
2016.01.07 10:32:08.692 5: SW: 06
2016.01.07 10:32:08.694 5: zw.dongle dispatch 00040005029840
2016.01.07 10:32:08.695 4: zw.dongle CMD:APPLICATION_COMMAND_HANDLER ID:05 ARG:029840
2016.01.07 10:32:08.701 5: ZWDongle_Write 0013050a9880e6bc2cd823a42d9f2505 (e58b19ca)
2016.01.07 10:32:08.702 5: SW: 01110013050a9880e6bc2cd823a42d9f250551
2016.01.07 10:32:08.706 5: ACK received, WaitForAck=>2 for 01110013050a9880e6bc2cd823a42d9f250551
2016.01.07 10:32:08.712 4: ZWDongle_Read zw.dongle: sending ACK, processing 011301
2016.01.07 10:32:08.712 5: SW: 06
2016.01.07 10:32:08.714 5: zw.dongle dispatch 011301
2016.01.07 10:32:08.733 4: ZWDongle_Read zw.dongle: sending ACK, processing 001305000003
2016.01.07 10:32:08.734 5: SW: 06
2016.01.07 10:32:08.736 5: device ack reveived, removing 01110013050a9880e6bc2cd823a42d9f250551 from dongle sendstack
2016.01.07 10:32:08.736 5: zw.dongle dispatch 001305000003
2016.01.07 10:32:08.737 4: zw.dongle CMD:ZW_SEND_DATA ID:00 ARG:0003
2016.01.07 10:32:08.737 4: zw.dongle transmit OK for 05
2016.01.07 10:32:08.761 4: ZWDongle_Read zw.dongle: sending ACK, processing 000400052498813d75f0362f7b548ac8ade47ec8f5cbe93ff644bf33fd9d753de6c02c9389d213afbe
2016.01.07 10:32:08.762 5: SW: 06
2016.01.07 10:32:08.764 5: zw.dongle dispatch 000400052498813d75f0362f7b548ac8ade47ec8f5cbe93ff644bf33fd9d753de6c02c9389d213afbe
2016.01.07 10:32:08.764 4: zw.dongle CMD:APPLICATION_COMMAND_HANDLER ID:05 ARG:2498813d75f0362f7b548ac8ade47ec8f5cbe93ff644bf33fd9d753de6c02c9389d213afbe
2016.01.07 10:32:08.767 4: zw.dongle CMD:APPLICATION_COMMAND_HANDLER ID:05 ARG:108f010205310503011c06310501220096
2016.01.07 10:32:15.705 3: secUnlock will call Zwave_secEnd


Log Sensor:

2016-01-07_10:32:01 eg.wc.window_open battery: 100 %
2016-01-07_10:32:01 eg.wc.window_open doorWindow: Zu
2016-01-07_10:32:01 eg.wc.window_open luminance: 18 %
2016-01-07_10:32:01 eg.wc.window_open temperature: 15.0 C
2016-01-07_10:32:08 eg.wc.window_open luminance: 28 %
2016-01-07_10:32:08 eg.wc.window_open temperature: 15.0 C


List Sensor:

Internals:
   DEF        e58b19ca 5
   IODev      zw.dongle
   LASTInputDev zw.dongle
   MSGCNT     4
   NAME       eg.wc.window_open
   NR         77
   STATE      Zu
   TYPE       ZWave
   homeId     e58b19ca
   isWakeUp   1
   lastMsgSent 1452159128.70422
   nodeIdHex  05
   secTime    1452159128.69713
   zw.dongle_MSGCNT 4
   zw.dongle_RAWMSG 000400052498813d75f0362f7b548ac8ade47ec8f5cbe93ff644bf33fd9d753de6c02c9389d213afbe
   zw.dongle_TIME 2016-01-07 10:32:08
   Readings:
     2015-10-20 12:17:40   SECURITY        ENABLED
     2015-10-20 12:19:48   assocGroup_01   Max 08 Nodes 01
     2015-10-20 12:19:49   assocGroup_02   Max 08 Nodes
     2015-10-20 12:19:47   assocGroups     2
     2016-01-07 10:32:01   battery         100 %
     2015-10-20 12:28:25   configAutoReportIlluminationTime 2
     2015-10-20 12:27:16   configAutoReportTemperatureTime 2
     2015-10-20 12:20:43   configTurnOffLightTime 4
     2016-01-07 10:32:01   doorWindow      00
     2016-01-07 10:32:08   luminance       28 %
     2015-10-20 12:25:28   model           devolo Door/Window Contact MT02648
     2015-10-20 12:25:28   modelConfig     philio/pst02-1c.xml
     2015-10-20 12:25:28   modelId         0175-0002-000e
     2015-10-20 12:28:24   received_nonce  cfbec5c6e77fa1d5
     2015-12-23 18:44:27   state           TRANSMIT_NO_ACK
     2015-10-20 12:56:43   tamper          ff
     2016-01-07 10:32:08   temperature     15.0 C
     2016-01-07 10:32:08   transmit        OK
     2016-01-07 08:10:24   wakeup          notification
     2015-10-20 12:23:26   wakeupReport    interval 21600 target 1
Attributes:
   IODev      zw.dongle
   alarmDevice Sensor
   alarmSettings alarm4,|eg.wc.window_open:.*Auf|Fenster Gäste WC|on
   alias      Fenster Gäste-WC
   classes    ZWAVEPLUS_INFO BATTERY ALARM ASSOCIATION CONFIGURATION MANUFACTURER_SPECIFIC VERSION SENSOR_BINARY SENSOR_MULTILEVEL WAKE_UP ASSOCIATION_GRP_INFO POWERLEVEL DEVICE_RESET_LOCALLY MULTI_CMD SECURITY FIRMWARE_UPDATE_MD MARK BASIC
   devStateIcon .*Zu:fts_window_1w@green .*Auf:fts_window_1w_open@red
   eventMap   00:Zu ff:Auf
   group      Türen/Fenster
   icon       control_building_eg
   room       Status
   secure_classes BATTERY ALARM ASSOCIATION CONFIGURATION SENSOR_BINARY SENSOR_MULTILEVEL WAKE_UP MARK
   sortby     22
   stateFormat doorWindow


List Dongle:

Internals:
   CallbackNr 0
   Clients    :ZWave:
   DEF        /dev/ttyACM0@115200
   DeviceName /dev/ttyACM0@115200
   FD         10
   MaxSendRetries 3
   NAME       zw.dongle
   NR         20
   PARTIAL
   RAWMSG     00040007198f010403800364043003ff0c053105030113063105012200be
   ReadTime   1452159433.1713
   STATE      Initialized
   SendRetries 0
   SendTime   1452159275.69238
   TYPE       ZWDongle
   WaitForAck 0
   homeId     e58b19ca
   nodeIdHex  01
   nrNAck     0
   zw.dongle_MSGCNT 32
   zw.dongle_TIME 2016-01-07 10:37:13
   Matchlist:
     1:ZWave    .*
   Readings:
     2016-01-07 10:07:22   caps            Vers:5 Rev:3 ManufID:0115 ProductType:0400 ProductID:0001 SERIAL_API_GET_INIT_DATA SERIAL_API_APPL_NODE_INFORMATION APPLICATION_COMMAND_HANDLER ZW_GET_CONTROLLER_CAPABILITIES SERIAL_API_SET_TIMEOUTS SERIAL_API_GET_CAPABILITIES SERIAL_API_SOFT_RESET UNKNOWN_09 UNKNOWN_0a ZW_SET_R_F_RECEIVE_MODE ZW_SET_SLEEP_MODE ZW_SEND_NODE_INFORMATION ZW_SEND_DATA ZW_SEND_DATA_MULTI ZW_GET_VERSION ZW_SEND_DATA_ABORT ZW_R_F_POWER_LEVEL_SET ZW_SEND_DATA_META ZW_GET_RANDOM MEMORY_GET_ID MEMORY_GET_BYTE MEMORY_PUT_BYTE MEMORY_GET_BUFFER MEMORY_PUT_BUFFER FLASH_AUTO_PROG_SET UNKNOWN_28 NVM_GET_ID NVM_EXT_READ_LONG_BUFFER NVM_EXT_WRITE_LONG_BUFFER NVM_EXT_READ_LONG_BYTE NVM_EXT_WRITE_LONG_BYTE ZW_GET_NODE_PROTOCOL_INFO ZW_SET_DEFAULT ZW_REPLICATION_COMMAND_COMPLETE ZW_REPLICATION_SEND_DATA ZW_ASSIGN_RETURN_ROUTE ZW_DELETE_RETURN_ROUTE ZW_REQUEST_NODE_NEIGHBOR_UPDATE ZW_APPLICATION_UPDATE ZW_ADD_NODE_TO_NETWORK ZW_REMOVE_NODE_FROM_NETWORK ZW_CREATE_NEW_PRIMARY ZW_CONTROLLER_CHANGE ZW_SET_LEARN_MODE ZW_ASSIGN_SUC_RETURN_ROUTE ZW_REQUEST_NETWORK_UPDATE ZW_SET_SUC_NODE_ID ZW_DELETE_SUC_RETURN_ROUTE ZW_GET_SUC_NODE_ID ZW_SEND_SUC_ID ZW_EXPLORE_REQUEST_INCLUSION ZW_REQUEST_NODE_INFO ZW_REMOVE_FAILED_NODE_ID ZW_IS_FAILED_NODE ZW_REPLACE_FAILED_NODE UNKNOWN_66 UNKNOWN_67 UNKNOWN_78 GET_ROUTING_TABLE_LINE LOCK_ROUTE_RESPONSE UNKNOWN_92 UNKNOWN_93 UNKNOWN_98 UNKNOWN_b4 ZW_WATCHDOG_ENABLE ZW_WATCHDOG_DISABLE ZW_WATCHDOG_CHECK ZW_SET_EXT_INT_LEVEL ZW_RF_POWERLEVEL_GET ZW_TYPE_LIBRARY ZW_SEND_TEST_FRAME ZW_GET_PROTOCOL_STATUS WATCHDOG_START WATCHDOG_STOP UNKNOWN_d4 UNKNOWN_ef ZME_FREQ_CHANGE ZME_BOOTLOADER_FLASH UNKNOWN_f5
     2015-10-07 20:02:47   ctrlCaps        MEMBER PRIMARY SUC
     2016-01-07 10:07:22   homeId          HomeId:e58b19ca CtrlNodeId:01
     2015-12-18 23:33:13   neighborList_10 zw.dongle
     2015-12-09 22:55:13   neighborList_11 zw.dongle eg.wz.media_switch
     2015-12-09 22:53:40   neighborList_2  zw.dongle eg.wz.media_switch
     2015-12-09 22:53:48   neighborList_4  zw.dongle eg.wz.media_switch
     2015-12-09 22:52:58   neighborList_7  zw.dongle eg.wz.media_switch
     2016-01-05 22:56:29   neighborList_8  zw.dongle eg.wz.media_switch
     2015-12-18 23:32:26   neighborList_9  eg.wz.media_switch
     2015-10-07 20:05:38   nodeInfo_1      STATIC_CONTROLLER STATIC_CONTROLLER listening frequentListening:0 beaming:16 40kBaud Vers:4 Security:0
     2015-12-09 22:54:19   nodeInfo_10     ROUTING_SLAVE GARAGE_DOOR sleeping frequentListening:0 beaming:16 routing 40kBaud Vers:4 Security:0
     2015-12-09 22:54:26   nodeInfo_11     ROUTING_SLAVE GARAGE_DOOR sleeping frequentListening:0 beaming:16 routing 40kBaud Vers:4 Security:0
     2015-12-20 17:29:05   nodeInfo_12     ROUTING_SLAVE SENSOR_NOTIFICATION sleeping frequentListening:0 beaming:16 routing 40kBaud Vers:4 Security:0
     2015-10-08 12:02:47   nodeInfo_2      ROUTING_SLAVE GARAGE_DOOR sleeping frequentListening:0 beaming:16 routing 40kBaud Vers:4 Security:0
     2015-10-29 12:11:34   nodeInfo_3      ROUTING_SLAVE SWITCH_BINARY listening frequentListening:0 beaming:16 routing 40kBaud Vers:4 Security:0
     2015-10-16 20:49:49   nodeInfo_4      ROUTING_SLAVE GARAGE_DOOR sleeping frequentListening:0 beaming:16 routing 40kBaud Vers:4 Security:0
     2015-10-21 13:40:20   nodeInfo_5      ROUTING_SLAVE GARAGE_DOOR sleeping frequentListening:0 beaming:16 routing 40kBaud Vers:4 Security:0
     2015-10-29 12:11:16   nodeInfo_6      node 6 is not present
     2015-10-29 16:50:54   nodeInfo_7      ROUTING_SLAVE GARAGE_DOOR sleeping frequentListening:0 beaming:16 routing 40kBaud Vers:4 Security:0
     2015-12-03 21:43:31   nodeInfo_8      ROUTING_SLAVE GARAGE_DOOR sleeping frequentListening:0 beaming:16 routing 40kBaud Vers:4 Security:0
     2015-12-03 21:43:42   nodeInfo_9      ROUTING_SLAVE GARAGE_DOOR sleeping frequentListening:0 beaming:16 routing 40kBaud Vers:4 Security:0
     2015-12-22 11:06:03   nodeList        zw.dongle eg.wz.window_open eg.wz.media_switch eg.fl.window_open eg.wc.window_open eg.kue.window_open dg.hint.window_open dg.vorn.window_open ke.hint.window_open ke.vorn.window_open eg.wz.smoke_detect
     2016-01-07 10:07:22   random          7ea84ce19a49ad9ed5f20bf45647a35d6ab1c3355e326568a77ccf10ff06c44b
     2016-01-07 10:07:22   state           Initialized
     2015-10-08 18:14:43   version         Z-Wave 4.05 STATIC_CONTROLLER
   SendStack:
Attributes:
   alias      Z-Wave Controller
   group      Controllers
   icon       it_wireless_dcf77
   networkKey 73479945XXXXXXXXXXXXXXXXXX
   room       Infrastruktur
   verbose    3


Hi,

Zitat von: Buwe am 07 Januar 2016, 11:00:56
Ich hoffe, dass ist hier richtig:
Seit dem Update am 5.01.2016 (10_ZWave.pm) wird mir das Log mit diesen Meldungen "geflutet":

Code Auswählen Erweitern

secUnlock will call Zwave_secEnd

Von den 8 Philio/Devolo/D-Link Kontakten sind "historisch" nur zwei mit Security inkludiert. Die Meldungen kommen nur von diesen beiden und immer nur dann wenn der jeweilige Sensor Status-Meldungen (Auf/Zu/Temperatur/etc) sendet. Fehlfunktionen kann ich bisher keine erkennen.

Edith: 10:32:01 war das Schließen des Fensters. 10:32.08 war der stündliche Status Report von Temperatur/Luminance. Das war Zufall.
Wenn ich das globale Log mit dem jeweiligen Filelog vergleiche, scheint die o.g. Meldung immer mit sieben Sekunden Verzögerung zu kommen.

diese Meldung sollte eigentlich nur kommen wenn im Ablauf mit SECURITY etwas durcheinander gekommen ist. Da ist ein Timer drin, der erkennen soll ob das System "klemmt" und dann das System wieder "resettet".

Ich schau heute abend mal genauer in das Log um zu sehen ob die Meldung bei Dir zu Recht kommt oder ein "Fehlalarm" ist. Es könnte sein das automatische Nachrichten ohne einen entsprechenden Get-Befehl evtl. die Erkennungslogik durcheinander bringt.

Gruß,
Andreas.

Hallo Rudi,

kannst Du bitte den Patch für den Workaround einchecken?

In der ursprünglichen Version wurde die Warnung ausgegeben und secEnd aufgerufen wenn der Timer abgelaufen war, unabhängig davon ob secEnd bereits aufgerufen war.
Ich habe das jetzt mit in die Abfrage aufgenommen.

Gruß,
Andreas.

Habs eingechekt, bin aber der Ansicht, dass es besser waere den Aufruf ganz zu sparen, indem man an der passenden Stelle RemoveInternalTimer aufruft.

Hi Rudi,

das geht ja nur wenn ich da einen "eigenen" Timer mit "eigenem" hash anlege. Soweit habe ich mir das mit den Timer noch nicht angesehen, einen entsprechenden Umbau schreibe ich mir auf meine ToDo-Liste.

Gruß,
Andreas.

$hash->{secTimer} = { hash => $hash };
InternalTimer(time()+5,"MyFunction", $hash->{secTimer},0);
sub
MyFunction($)
{
  my ($p) = @_;
  my $hash = $p->{hash};
  Log3 $hash, 1, "Hello";
}
RemoveInternalTimer($hash-{secTimer});


Ungetestet, aber vom Prinzip her sollte es stimmen.

Nachdem jetzt addNode die sec-Einbindung standardmäßig anbietet (Danke, Rudi), hätte ich dazu gerne ein paar Sätze im Wiki.
Andreas, soll ich das machen?
Falls ja, würde ich anmerken, dass SECURITY erhöhte Funklast sowie ggfs. Reaktionsverzögerungen verursacht und nur bei wirklich sicherheitsrelevanten Dingen (Schloß, etc) genutzt werden sollte. Standard ist ohne sec. Ok?

Hi Christian,

ja, das kannst Du gerne so in das Wiki übernehmen!

Vielen Dank dafür!
Andreas.

Hi Rudi,

habe jetzt so wie von Dir vorgeschlagen einen eigenen Timer das "Unlock" gemacht und die Änderungen in processSendStack wieder rückgängig gemacht das sie dann ja nicht mehr benötigt werden.
Patchfile habe ich angehängt.

Gruß,
Andreas.

Edit: Patchfile noch mal geändert erweitert, jetzt ist auch der Timer bei NetworkkeyVerify ein "eigener", außerdem werden die hash-werte jetzt wieder aufgeräumt.

Hi Rudi,

wegen "zwave_parsehook"...

Zitat von: rudolfkoenig am 05 Januar 2016, 08:17:13
Das wird ja sogar schon aktiv verwendet. Ob es fuer die Sec-Funktionen an der richtigen Stelle geprueft/aufgerufen wird, weiss ich aber nicht.

steh' ich anscheinend irgendwie auf dem Schlauch oder bin im falschen Film...

Was genau meinst Du mit zwave_parsehook? Ich finde keine Funktion mit dem Namen und auch sonst kommt mir auf den ersten Blick da nichts geändert vor.

Was übersehe ich?

Gruß,
Andreas.

Patch eingecheckt.

zwave_parsehook: sorry, es heisst zwave_parseHook (H gross). Hier traegt man fuer eine nodeId/Command-Regexp Kombination eine Funktion ein, und falls in ZWave_Parse eine passende Nachricht auftaucht, dann wird diese Funktion aufgerufen. Ich gehe davon aus, dass wir dafuer noch leichte Anpassungen vornehmen muessen, z.Bsp. Pruefung an anderer Stelle, je nach Rueckgabe der Funktion Abbruch der Weiterverarbeitung, um unerwuenschte Events zu vermeiden.

Ist nicht so dringend, da bisher keine Meldungen diesbezueglich aufgetaucht sind, andererseits wuerden Meldungen anderswo auftauchen, weil manche Module (z.Bsp. Homematic) empfindlich auf verspaetete Aufrufe reagieren. Die Ursache waere dann das blockierende Warten auf Security-Gets in ZWave.

Fuer direkte Aufrufe ueber die Frontends koennte man justme1968's Vorschlag implementieren, damit waeren diese Aufrufe auch blockierungsfrei. Bleiben noch die gets aufgerufen aus notify/at, dafuer koennten wir mit einem speziellen set einen Ersatz bauen, der nicht auf die Antwort wartet. Der Benutzer muss die Auswertung der Antworten (falls ueberhaupt noetig) mit einem weiteren notify realisieren.

Hi Rudi,

ah, jetzt, mein Editor zeigt mir eine Übersicht aller FUNKTIONEN an, da hatte ich nach zwave_parsehook geschaut und nichts gefunden. Jetzt weiß ich wenigstens wo ich schauen muss...

Danke,
Andreas.

Hi Rudi,

Zitat von: rudolfkoenig am 09 Januar 2016, 09:17:13
zwave_parsehook: sorry, es heisst zwave_parseHook (H gross). Hier traegt man fuer eine nodeId/Command-Regexp Kombination eine Funktion ein, und falls in ZWave_Parse eine passende Nachricht auftaucht, dann wird diese Funktion aufgerufen. Ich gehe davon aus, dass wir dafuer noch leichte Anpassungen vornehmen muessen, z.Bsp. Pruefung an anderer Stelle, je nach Rueckgabe der Funktion Abbruch der Weiterverarbeitung, um unerwuenschte Events zu vermeiden.

Ist nicht so dringend, da bisher keine Meldungen diesbezueglich aufgetaucht sind, andererseits wuerden Meldungen anderswo auftauchen, weil manche Module (z.Bsp. Homematic) empfindlich auf verspaetete Aufrufe reagieren. Die Ursache waere dann das blockierende Warten auf Security-Gets in ZWave.

Fuer direkte Aufrufe ueber die Frontends koennte man justme1968's Vorschlag implementieren, damit waeren diese Aufrufe auch blockierungsfrei. Bleiben noch die gets aufgerufen aus notify/at, dafuer koennten wir mit einem speziellen set einen Ersatz bauen, der nicht auf die Antwort wartet. Der Benutzer muss die Auswertung der Antworten (falls ueberhaupt noetig) mit einem weiteren notify realisieren.

hier verstehe ich so einige Sachen noch nicht...

Was bringt das Aufrufen einer Funktion in Parse durch zwave_parseHook wenn eine passende Nachricht eintrifft? Die würde doch auch sonst ganz normal geparst werden, wo ist da der Vorteil? Die Schwierigkeit, oder nennen wir es Herausforderung, ist doch zwischen dem GET und dem REPORT blockierungsfrei auf die Antwort zu warten. Mit dieser Konstruktion würde ja der normale Ablauf weitergehen und die Antwort bei Eintreffen geparst werden, aber nicht verhindert werden das der nächste Befehl die Kommunikation evtl. durcheinander bringt, oder bin ich hier auf dem Holzweg?

Ich habe den ganzen Ablauf immer noch so verstanden das der Dongle zwischen GET und REPORT auch keine weiteren Befehle verträgt, d.h. man muss warten. Wie lange ist natürlich eine Frage... Bei den Controller-Befehlen gibt es da 0x06 SERIAL_API_SET_TIMEOUTS, könnten das evtl. die internen Timeouts für den Dongle sein? Der muss ja auch irgendwann mal aufgeben und wieder weitermachen dürfen...

Mein Verständnis ist weiterhin das die globale, FHEM-weite, Blockierung durch ReadAnswerFn ausgelöst wird, das wird aber "nur" in ZWave_Parse bei get-Befehlen ausgeführt, die NICHT per SECURITY gesendet werden. In Security werden die ja vorher abgefangen und dann verschlüsselt als SET gesendet. Meiner Meinung nach dürfte es daher bei den Verschlüsselten Befehlen zu keiner Blockade von FHEM kommen. Ich überlege zwar gerade das verschlüsselte Senden je nach Inhalt als SET oder GET deklariert durchzuführen, die Stelle mit dem ReadAnswerFn erreichen verschlüsselte Pakete aber sowieso nie...

Könntest Du mir bitte noch mal auf die Sprünge helfen und mir sagen ob bzw. wo ich hier in meinem Verständnis einen Fehler habe?

Meine momentane Idee wäre es analog zu secStart/secEnd bzw. dem warten auf das ACK auch den normalen Sendstack anhalten zu können. Bei einem Get-Befehl einen Timer starten, falls die passende Antwort eintrifft Timer löschen, Sendstack wieder freigeben. Falls Timer abläuft, könnte man den Befehl wiederholen (mit Retry-counter) und letztendlich aufgeben und den nächsten Befehl abarbeiten.

Danke,
Andreas.

Problem:
Aufruf von ZWave get konzentriert sich nur auf dem betroffenen ZWDongle, und ignoriert z.Bsp. das HomeMatic CUL, die telnet und FHEMWEB Verbindung, usw. Im Normalfall sind das nur 100ms, und vermutlich irrelevant, im Problemfall kann das mit 3 Sekunden schon ein Problem werden, z.Bsp. wenn ein ACK im HomeMatic in FHEM generiert wird.

Vorgeschlagene Lösungen:
- fuer FHEMWEB/telnet: spezielle Benachrichtigungsroutinen in den Modulen, die beim Eintreffen der passenden Nachricht die Daten anzeigen. Es wird nicht blockierend gewartet, und im Problemfall gibts entweder keine Nachricht, oder im Modul muss ein Timer aufgezogen werden.
- fuer Modulinterne "get" schlage ich zwave_parseHook vor: da spezifiziert man, was man erwartet, und wo es weitergehen soll, wenn die Nachricht eintrifft. Fuer den Fall, dass sie nicht eintrifft, muss man einen Timer aufrufen.

Ich habe die Gets im ZWave jetzt naeher angeschaut, und ich meine man kommt auch viel einfacher an eine Loesung:
Es gibt drei Aufrufe von ZWave_Cmd im Security Kontext, aber alle drei Ergebnisse werden nicht direkt ausgewertet, sondern indirekt ueber ZWave_secNonceRequestReceived/ZWave_secSupported. Damit ist es trivial, aus diesen "get secNonce/set secSupported" gleichwertige "set secNonce/set secSupported" Aufrufe zu machen (die beiden gets auch im set Hash anbieten, und get durch set zu ersetzen). Nach diesem Umbau waere Security in ZWave blockierungsfrei.

Hi Rudi,

irgendwie bin ich jetzt auch noch nicht wirklich schlauer...

Zitat von: rudolfkoenig am 13 Januar 2016, 13:58:18
Problem:
Aufruf von ZWave get konzentriert sich nur auf dem betroffenen ZWDongle, und ignoriert z.Bsp. das HomeMatic CUL, die telnet und FHEMWEB Verbindung, usw. Im Normalfall sind das nur 100ms, und vermutlich irrelevant, im Problemfall kann das mit 3 Sekunden schon ein Problem werden, z.Bsp. wenn ein ACK im HomeMatic in FHEM generiert wird.

mir ist klar das eine blockierende Funktion innerhalb FHEM schlecht ist, aber welcher Teil GENAU löst das aus? Ist das wie von mir postuliert NUR die ReadAnswerFn?

Zitat von: rudolfkoenig am 13 Januar 2016, 13:58:18
Vorgeschlagene Lösungen:
- fuer FHEMWEB/telnet: spezielle Benachrichtigungsroutinen in den Modulen, die beim Eintreffen der passenden Nachricht die Daten anzeigen. Es wird nicht blockierend gewartet, und im Problemfall gibts entweder keine Nachricht, oder im Modul muss ein Timer aufgezogen werden.

Hier kann ich Dir jetzt nicht mehr folgen. Meinst Du hier das in FHEMWEB bzw. über telnet die Rückgabe des GET-Befehls angezeigt werden soll?

Zitat von: rudolfkoenig am 13 Januar 2016, 13:58:18
- fuer Modulinterne "get" schlage ich zwave_parseHook vor: da spezifiziert man, was man erwartet, und wo es weitergehen soll, wenn die Nachricht eintrifft. Fuer den Fall, dass sie nicht eintrifft, muss man einen Timer aufrufen.

Auch hier verstehe ich Dich nicht wirklich, ich habe den tieferen Sinn des zwave_parseHook aber auch noch nicht verstanden. Aber warum/wie soll ich einen Timer aufrufen wenn die Nachricht NICHT eintrifft? Das "nicht eintreffen" kann ich doch nur über einen Time-Out definieren/erkennen den ich ja über einen Timer realisieren muss...

Zitat von: rudolfkoenig am 13 Januar 2016, 13:58:18
Ich habe die Gets im ZWave jetzt naeher angeschaut, und ich meine man kommt auch viel einfacher an eine Loesung:
Es gibt drei Aufrufe von ZWave_Cmd im Security Kontext, aber alle drei Ergebnisse werden nicht direkt ausgewertet, sondern indirekt ueber ZWave_secNonceRequestReceived/ZWave_secSupported. Damit ist es trivial, aus diesen "get secNonce/set secSupported" gleichwertige "set secNonce/set secSupported" Aufrufe zu machen (die beiden gets auch im set Hash anbieten, und get durch set zu ersetzen). Nach diesem Umbau waere Security in ZWave blockierungsfrei.

Auch hier muss ich mir das noch mal genau ansehen, allerdings bin ich mir nicht sicher warum Du unbedingt die GET Befehle in SET Befehle (selbst im hash) ändern willst.

Ich verstehe immer noch nicht wo das Problem an einem GET Befehl ist was sich durch eine Umdeklarierung in ein SET ändern lässt... Wie soll das überhaupt mit den ganzen Befehlen rein namenstechnisch gehen. Die Klasse TIME z.B. hat ein SET timeOffset und ein GET timeOffset.

Meiner Meinung nach muss man zwischen einem SET und einem GET unterscheiden, woher ist denn sonst überhaupt klar das eine Antwort erwartet wird? Weiterhin muss man weiterhin zwingend zwischen dem GET und dem REPORT (der Antwort) verhindern das weitere Befehle über den Dongle abgesetzt werden. Das gilt MINDESTENS für die betroffene Node, wahrscheinlich aber eben global für den Dongle.

Mein Verständnis ist das bisher bei einem GET am Ende von ZWave_Cmd die ReadAnswerFn des IODev aufgerufen wird und das diese Funktion blockierend ist. (Kannst Du bitte mal bestätigen das dies wirklich die einzige Blockade ist?)

Prinzipiell macht dieser Block am ende von ZWave_Cmd ja nichts anderes als auf den REPORT zu warten und anschliessend ZWave_Parse für die erhaltene Antwort aufzurufen. Meiner Meinung nach muss das Problem an dieser Stelle gelöst werden.

Sendstack anhalten, Get-Befehl absetzen, Time-Out timer starten
Falls Nachricht eintrifft mit erwartetem Muster (Klasse und Befehl!) vergleichen, Nachricht passt -> Timer stoppen, Sendstack wieder freigben
Falls Nachricht eintrifft ohne erwartetes Muster, Nachricht normal parsen, weiter warten
Timer läuft ab ohne passende Nachricht -> Fehlermeldung, Sendstack wieder freigeben.

So ein Konstrukt sollte FHEM nicht blockieren aber sicherstellen das zwischen GET und REPORT nicht gesendet wird.

Mir dämmert aber gerade das hierbei kein Rückgabewert per "return" (an FHEMWEB/telnet) übergeben werden kann, da man dann ja quasi schon ohne die Antwort weitermacht... Dann wäre das Problem ja eher wie bekommt man die aufrufende Instanz asynchron hin? Die Funktion selbst müsste dann auch so aufgebaut sein das sie die Antwort nicht direkt im GET erwartet sondern diese "später" als REPORT bekommt...

Das werde ich mir am WE noch mal genauer anschauen müssen.

Immer noch verwirrt, (oder sogar noch mehr...)
Andreas.

P.S.: In Erweiterung der Diskussion wäre ich dafür bei den GET-Befehlen das "Muster" mit dem erwarteten REPORT mit in den hash aufzunehmen. Bisher wird ja quasi JEDE Antwort dieser Befehlsklasse als Treffer gewertet, falls da dann zufällig z.B. eine "unsolicited" Message (Bewegungsmelder...) kommt dann geht das schief. Bei jedem GET ist eigentlich zusätzlich zu der Klasse auch die Befehlsnummer klar die man als Antwort erwartet. Bei den meisten Befehlen sogar die Länge, einige haben jedoch auch eine variable, nicht vorhersehbare Länge.

Ich versuchs anders/fokussierter:
1. ja, ReadAnswerFn ist schuld

2. ja, ich meinte telnet/FHEMWEB, fuer dich irrelevant, fuer mich Arbeit (irgendwannmal).

3. timer: genau das habe ich gemeint.

4. Du sollst bitte secNonce und secSupported (auch?) als set anlegen, und die 3 Aufrufe von get aus set aendern. Da bei den Aufrufen das Rueckgabewert nicht ausgewertet wird, ist es egal, ob es set oder get ist, und da man mit set nicht auf eine Antwort wartet, blockiert auch nichts mehr. FHEM2FHEM:RAW muesste damit auch funktionieren.

5. Das Loesen des "get" Problems im ZWave_Cmd hat leider einen Haken: ich weiss nicht, wie man es ohne eine deutliche Interface-Aenderung (d.h. einfuehren von Callbacks oder Umsteigen auf Multithreading) loesen kann.
Dein Vorschlag wird z.Zt. schon umgesetzt. Was Du und die aktuelle Implementierung aber ignorieren: die anderen Filedeskriptoren (FHEMWEB/telnet/andere Inputs wie Homematic/etc) werden nicht geprueft, genausowenig werden Timer abgearbeitet, etc. Das alles passiert im Haupt-Select, aber ReadAnswerFn macht seinen eigenen eingeschraenkten select auf, was zwar bequem aber eigentlich falsch ist. Solange es selten verwendet wird, faellt es nicht auf, aber wenn man Security aktiviert, ist es staendig in Benutzung.

6. get wird auch jetzt mit einem regexp gestartet, der id beinhaltet. Wir sollten noch die Klasse hinzufuegen.

Hi Rudi,

Zitat von: rudolfkoenig am 14 Januar 2016, 09:54:25
Ich versuchs anders/fokussierter:

danke ,-)

Ich arbeite das am WE mal ab, vor allem Punkt 5 wird 'ne Weile brauchen bis ich das drumherum verstanden habe (Wir brauchen mal ein "BootCamp" mit Dir...) .-)

Zitat von: rudolfkoenig am 14 Januar 2016, 09:54:25
6. get wird auch jetzt mit einem regexp gestartet, der id beinhaltet. Wir sollten noch die Klasse hinzufuegen.

Ist das nicht genau anders herum? Die Klasse ist drin, aber die BefehlsID nicht?

Danke,
Andreas.

Hi Rudi,

Zitat von: rudolfkoenig am 14 Januar 2016, 09:54:25
4. Du sollst bitte secNonce und secSupported (auch?) als set anlegen, und die 3 Aufrufe von get aus set aendern. Da bei den Aufrufen das Rueckgabewert nicht ausgewertet wird, ist es egal, ob es set oder get ist, und da man mit set nicht auf eine Antwort wartet, blockiert auch nichts mehr. FHEM2FHEM:RAW muesste damit auch funktionieren.

so ganz habe ich das Endziel der Umbauarbeiten noch nicht verstanden aber ich habe mal die get-Befehle aus SECURITY ausgebaut und durch entsprechende SET ersetzt. Ich habe dabei die Namen etwas geändert, dafür aber auch die Doku angepasst ,-)

Patch ist angehängt...

Gruß,
Andreas.

Eingecheckt.

Ab jetzt duerfte ZWave auch im Security Modus nicht die Ursache fuer irgendwelche Haenger sein.

Könntet Ihr das bitte für mich (einfacher) übersetzen. Trifft das:
SECURITY hat damit das Problem der gelegentlichen Störungen bei der Kommunikation zwischen Gateway und Endgerät in einer Kette von Funktelegrammen für einen FHEM-Befehl verloren?
Danke und Gruß, Christian

Nein, innerhalb des ZWave-Welts sollte sich nichts aendern.
Es sollte aber nicht mehr passieren, dass wg. ZWave-Security HomeMatic Probleme kriegt.

Hi Christian,

Zitat von: krikan am 15 Januar 2016, 10:05:32
SECURITY hat damit das Problem der gelegentlichen Störungen bei der Kommunikation zwischen Gateway und Endgerät in einer Kette von Funktelegrammen für einen FHEM-Befehl verloren?

also durch das "secStart/secEnd" ist das Problem aber auch schon deutlich verringert worden. Von FHEM sollte dadurch jetzt kein weiterer Befehl mehr in einer laufenden SECURITY-Kommunikation gesendet werden.

Die Erkennung und Behandlung von eingehenden Paketen während der Kommunikation ist aber noch nicht wirklich implementiert. Falls eine Nachricht verlorengeht wird momentan wenigstens durch ein Timer das "secEnd" ausgelöst und damit der komplette DeadLock verhindert wird.

Für das Problem das dann evtl. eine Nachricht im Security Stack liegenbleibt und damit der Ablauf auch durcheinander kommt wollte ich mir demnächst mal auch so eine Lösung mit einem Timer überlegen.

Gruß,
Andreas.

Hallo Rudi,

Zitat von: rudolfkoenig am 14 Januar 2016, 09:54:25
5. Das Loesen des "get" Problems im ZWave_Cmd hat leider einen Haken: ich weiss nicht, wie man es ohne eine deutliche Interface-Aenderung (d.h. einfuehren von Callbacks oder Umsteigen auf Multithreading) loesen kann.
Dein Vorschlag wird z.Zt. schon umgesetzt. Was Du und die aktuelle Implementierung aber ignorieren: die anderen Filedeskriptoren (FHEMWEB/telnet/andere Inputs wie Homematic/etc) werden nicht geprueft, genausowenig werden Timer abgearbeitet, etc. Das alles passiert im Haupt-Select, aber ReadAnswerFn macht seinen eigenen eingeschraenkten select auf, was zwar bequem aber eigentlich falsch ist. Solange es selten verwendet wird, faellt es nicht auf, aber wenn man Security aktiviert, ist es staendig in Benutzung.

so nochmal eine Verständnisfrage.
Ist jetzt das select in ReadAnswerFn das eigentliche Problem oder (was ist eher vermute) das jegliches Warten den "return" zur aufrufenden Funktion verzögert und das durch Singlethread dann während der Wartezeit nichts anderes ausgeführt wird?
(Wobei ich bisher nicht wirklich verstanden habe was mit "select" wirklich im Hintergrund gemacht wird...)

Das mit dem %zwave_parseHook muss ich mir auch noch genauer anschauen. Der einzige Vorteil den ich momentan sehe ist das man dort auch Funktionen spezifizieren könnte die man nicht in  bei %zwave_class in PARSE angegeben hat. Ansonsten kann man doch auch einfach die Antwort normal parsen, oder?
Allerdings kann ich nicht erkennen wie man bei dem zwave_parseHook Parameter übergibt (für z.B. die Nachricht)???

Ich muss mir das für das AssociationRequest noch mal anschauen und nachvollziehen, vielleicht eignet sich das ja auch dazu das umständliche Konstrukt zum Einleiten der SECURITY-Inklusion besser zu lösen.

Gruß,
Andreas.

Zitat(Wobei ich bisher nicht wirklich verstanden habe was mit "select" wirklich im Hintergrund gemacht wird...)

Siehe "man select". Du musst das select Konzept verstehen, sonst verstehst das Problem (bzw. FHEM) nicht.
Problem ist nicht das select per se, sondern dass man SingleThreaded ist, auf das Ergebnis warten muss, und in diesem(!) Select man nur auf die betroffene ZWave Dongle aufpasst, und alle anderen FileDescriptoren ausser acht laesst.

zwave_parseHook ist vergleichbar mit der bei SECURITY verwendeten Methode (Funktionsaufruf bei Nachricht bestimmter Klasse). Der Aufruf ist aber temporaer, und kann auf einzelne Geraete oder andere Antwortparameter filtern, damit u.U. flexibler. Parameter kann man mit einem direkten sub
$zwave_parseHook{"$hash->{nodeIdHex}:..85"} = sub($h) { Funktion($h, meineParameter) }
uebergeben, oder indem man die im $hash zwischenspeichert. In diesem Fall ist $h und $hash gleich, in dem Sinne das vor dem Aufruf der sub das gleiche $hash ausgewaehlt wird.

Man koennte ein Grossteil (aber nicht alles) von Security auf parseHook umbauen, ob das danach besser/eleganter ist, kann ich jetzt nicht sagen.

Hi Rudi,

Zitat von: rudolfkoenig am 19 Januar 2016, 07:15:26
Siehe "man select". Du musst das select Konzept verstehen, sonst verstehst das Problem (bzw. FHEM) nicht.

so grundlegend habe ich ja schon verstanden das man dort per Bitmaske die FileDeskriptoren definiert die man dann auf lesen oder schreiben überwacht.

Zitat von: rudolfkoenig am 19 Januar 2016, 07:15:26
Problem ist nicht das select per se, sondern dass man SingleThreaded ist, auf das Ergebnis warten muss, und in diesem(!) Select man nur auf die betroffene ZWave Dongle aufpasst, und alle anderen FileDescriptoren ausser acht laesst.

Ok, so langsam verstehe ich das ganze etwas besser... Wie machen das denn die anderen Systeme (z.B. Homematic), dort gibt es doch auch Get-Befehle die auf Rückgaben der Devices angewiesen sind. (Und dort scheint mir die "Antwortzeit" vom System sogar noch länger zu sein als bei ZWave).
Ist dort eine asynchrone Verarbeitung implementiert?

Zitat von: rudolfkoenig am 19 Januar 2016, 07:15:26
zwave_parseHook ist vergleichbar mit der bei SECURITY verwendeten Methode (Funktionsaufruf bei Nachricht bestimmter Klasse). Der Aufruf ist aber temporaer, und kann auf einzelne Geraete oder andere Antwortparameter filtern, damit u.U. flexibler. Parameter kann man mit einem direkten sub

Code Auswählen Erweitern

$zwave_parseHook{"$hash->{nodeIdHex}:..85"} = sub($h) { Funktion($h, meineParameter) }
uebergeben, oder indem man die im $hash zwischenspeichert. In diesem Fall ist $h und $hash gleich, in dem Sinne das vor dem Aufruf der sub das gleiche $hash ausgewaehlt wird.

Man koennte ein Grossteil (aber nicht alles) von Security auf parseHook umbauen, ob das danach besser/eleganter ist, kann ich jetzt nicht sagen.

Danke für die Erklärung, dann lag ich ja nicht ganz so falsch. Ich werde mir das noch etwas genauer ansehen und dann wahrscheinlich mal einige der Sonderbehandlungen während der Inklusion damit umbauen, das ist dann deutlich eleganter und aufgeräumter. Kann sein das ich dafür kleine "Spezialfunktionen" brauche, dafür würden dann aber die Abfragen auf die Sonderfälle in den normalen Routinen entfallen.

Gruß,
Andreas.

Wenn ich das richtig sehe, gibt es keine HM get Befehle, die eine Kommunikation mit dem Stick oder gar mit den Endgeraeten ausloesen, es sind "nur" Befehle, die bereits vorhandene Informationen anders aufbereiten. Das ist eigentlich auch die richtige Vorgehensweise.

Hi Rudi,

was machen denn dann die GET-REG Befehle?
An irgendeiner Stelle muss da doch auch mal was gelesen werden? Muss mir das bei meinen Geräten mal ansehen.

Gruß,
Andreas.

Hi Rudi,

ich versuche gerade das mit dem zwave_parseHook nachzuvollziehen...

Der "interessante" Teil in ZWave_Parse ist ja hier:

    my $matched = 0;
    foreach my $k (keys %{$ptr}) {
      if($arg =~ m/^$k/) {
        my $val = $ptr->{$k};
        my @val = ($val);
        #Log3 $ioName, 1, "Parse: $val";
        @val = eval $val if(index($val, '$') >= 0);
        push @event, @val if(defined($val[0]));
        $matched++;
      }
    }

    foreach my $h (keys %zwave_parseHook) {
      if("$id:$arg" =~ m/$h/) {
        my $fn = $zwave_parseHook{$h};
        delete $zwave_parseHook{$h};
        $fn->($hash, $arg);
      }
    }

Dazu hätte ich mal ein paar Fragen...

Auch wenn die Nachricht im oberen Teil geparst werden konnte wird dennoch der untere Teil abgearbeitet, oder?

In der Konstellation sollte man also nur Sachen in zwave_parseHook eintragen die NICHT in der %zwave_class enthalten sind, da diese dann zweifach abgearbeitet werden, oder?

Spricht was dagegen die Reihenfolge der beiden Blöcke zu tauschen und den Block mit dem "normalen" Parsen nur zu durchlaufen falls in zwave_parseHook nichts passendes gefunden wurde?
Dadurch könnte man temporäre "Ausnahmen" für die normalen Parsefunktionen definieren. Ich könnte das dann (eventuell, ist bisher nur eine Idee) z.B. für ZWave_secNonceReceived nutzen. Da gibt es einen Sonderfall während der Inklusion der dann aus der normalen Funktion raus könnte und in eine spezielle Funktion gepackt werden könnte die dann nur durch das setzen in zwave_parseHook während der Inklusion gestartet werden kann.

Gruß,
Andreas.

Hi,

ich denke ich habe gerade durch ausprobieren und testen mit associationRequestAll herausbekommen das Du zwave_parseHook genau andersherum einsetzt wie ich das vorhatte...

Du lässt erst parsen und DANACH machst Du was besonderes, richtig?

Gruß,
Andreas.

Ich habe kein Problem, die Aufrufraihenfolge zu aendern, ich will es nur nicht "sinnlos" machen. Vorschlag: Reihenfolge der beiden Bloecke tauschen. Falls die zwave_parseHook Funktion != 0 zurueckliefert, dann wird die (jetzt darauffolgende) Schleife mit den Regexps aus zwave_class _nicht_ ausgefuehrt.

Fuer associationRequestAll sollte die Reihenfolge egal sein.

Hi Rudi,

weiterer Vorschlag:
die eigentliche foreach Schleife mit parseHook in eine kleine Funktion auslagern, und DREI %parseHook definieren
Dann diese Funktion mit den verschiedenen Hooks aufrufen:

-> %zwave_parseHookPreOnly (wird vor dem normalen Parsen ausgeführt, falls !=0 wird der Rest übersprungen)
-> %zwave_parseHookPre (wird vor dem normalen Parsen ausgeführt)
das normale Parsen
-> %zwave_parseHookPost (wie bisher nach dem normalen Parsen)

Ich kann die möglichen Anwendungsfälle bisher nicht wirklich abschätzen, ich bin momentan noch nicht mal sicher ob sich die SECURE-Inklusion programmtechnisch damit wirklich vereinfachen lässt, aber mit so einem Konstrukt wäre man schon SEHR flexibel. Damit könnte man für jeden Parse eine Alternative oder eine Pre und/oder Post Behandlung definieren.

AssociationRequestAll lässt sich aktuell aber nicht so einfach nach vorne schieben, da fehlt ja dann die normale Auswertung, außerdem wird im ParseHook momentan kein $matched incrementiert, da kriegt man dann ein "UNPARSED"... Schau ich mir aber noch mal an...

Gruß,
Andreas.

Hi Rudi,

ich habe das jetzt mit den drei Hooks mal so umgesetzt...
Kannst Du Dir ja bei Gelegenheit mal anschauen. AssociationRequestAll funktioniert damit jedenfalls weiterhin, allerdings nur wenn das normale Parsen auch ausgeführt wird.
Ich schau jetzt mal ob sich das für die SECURE-Inclusion als brauchbar erweist.

Gruß,
Andreas.

Sorry, aber 3 Hooks sind mir 2 zu viel, insb. wenn ich nicht weiss, ob sie je benoetigt werden.

Ich habe die parseHook Aufrufe vor dem normalen Parse geholt, und jetzt ist auch eine "Veto" Funktionalitaet drin, was sich aber von deinem "matched" unterscheidet: die aufgerufene Funktion muss 1 (bzw. != 0) zurueckliefern, damit es keine weitere Verarbeitung gibt. associationRequestAll funktioniert weiterhin.

Hi Rudi,

also ich bin eigentlich gerade dabe den Ablauf der Secure-Inklusion umzubauen und habe dazu bereits HookOnly und HookPost genutzt... Wobei ich auf HookPost aber wahrscheinlich verzichten kann, das würde auch mit HookPre funktionieren...

Wenn die Funktion von HookOnly mit dem "Veto" möglich ist, dann sollte ich das anpassen können.

Ich werde mir das mal ansehen allerdings wird das DIFF dazu sehr wüst aussehen.

Gruß,
Andreas.

ZitatWenn die Funktion von HookOnly mit dem "Veto" möglich ist, dann sollte ich das anpassen können.

Sicher, einfach 1 zurueckliefern, dann wird kein Event generiert.
Ist zwar noch nicht getestet, aber wenn es nicht gehen sollte, dann wird es umgehend gefixt.

Hi Rudi,

so, habe jetzt mal ein wenig im Security-Code und bei den Befehlen aufgeräumt...
Patch ist angehängt, aber nicht erschrecken, der Diff sieht wilder aus als es ist... ;-)

Ich habe den Ablauf bei der Inklusion jetzt über zwave_parseHook Ketten gelöst und die ganzen Sonderbehandlungen in kleine Funktionen ausgelagert die dann von dem parseHook aufgerufen werden. Das ist wesentlich aufgeräumter als die "Krücke" mit dem $hash->secstatus counter...

Das Initiieren der secure-Inklusion in ZWave_Parse mit den ganzen Sicherheitsabfragen habe ich jetzt in die secureInclusion funktion geschoben, damit sieht ZWave_Parse schon mal viel aufgeräumter aus.

Außerdem habe ich fast alle Befehle aus SET wieder ausgebaut und schreibe die jetzt direkt mit addToSendStack. Damit entfallen dann die unnötigen und eigentlich nicht nutzbaren Befehle im Menü. Außerdem spare ich mir da den ganzen Ablauf in ZWave_Cmd.

Dokumentationsblock ist auch angepasst.

Gruß,
Andreas.

Habs eingecheckt, ohne zu testen.

Wollte meine ersten Schritte mit SECURITY machen, und bin dabei gleich auf 3 Probeme gestossen:

- der Aeotec SmartSwitch 6 meldet kein SECURITY im NIF. Wenn man nach der Version der Klasse 98 fragt, dann kommt 1 zurueck, pepper sagt, dass der as6 Security kann, und meine Experimente bestaetigen das auch. Frage: wie ermoeglichen wir ein Secure inclusion? Meine beste Idee ist "set zwNode addNode onSecForce". Bessere Ideen? Zum Experimentieren habe ich die Pruefung auf SECURITY in classes abgeschaltet (und natuerlich nicht eingecheckt).

- die Laenge der Nachricht bei secNetworkkeySet ist 93 Bytes, das geht mit ZWCUL nicht, da das Firmware versucht die komplette Nachricht ins CC1101 Puffer (64 Bytes) zu stecken. Ich fuerchte, da muss ich was umbauen, damit das funktionieren kann.

- Secure-Inclusion ging schief, weil der AS6 zweimal ein Nonce angefordert hat. Er hat danach auch jeweils eine mit dem (vermutlich) "richtigen" Nonce verschluesselte Meldung zurueckgeschickt, FHEM hat aber beide Nachrichten verworfen, weil die Erste nicht mit dem letzten Nonce verschluesselt war, und die Zweite, weil beim Verwerfen der ersten Nachricht die zweite Nonce vernichtet wurde. @Andreas: soll ich das anschauen, oder willst du?

- Interessanter Fakt: removeNode braucht keine funktionierende Verschluesselung, aber immerhin einen Knopfdruck :)

Hallo Rudi,

beim Inkludieren in Secure Mode bitte den Knopf 2 Mal hintereinander (innerhalb einer Sekunde) drücken statt 1 Mal für normale Inklusion.
Hoffe das hilft

Hi Rudi,

Zitat von: rudolfkoenig am 13 März 2016, 20:34:44
Wollte meine ersten Schritte mit SECURITY machen, und bin dabei gleich auf 3 Probeme gestossen:

- der Aeotec SmartSwitch 6 meldet kein SECURITY im NIF. Wenn man nach der Version der Klasse 98 fragt, dann kommt 1 zurueck, pepper sagt, dass der as6 Security kann, und meine Experimente bestaetigen das auch. Frage: wie ermoeglichen wir ein Secure inclusion? Meine beste Idee ist "set zwNode addNode onSecForce". Bessere Ideen? Zum Experimentieren habe ich die Pruefung auf SECURITY in classes abgeschaltet (und natuerlich nicht eingecheckt).

Ich hoffe das erledigt sich wenn das mit dem "zwei mal drücken" funktionieren sollte und das Ding dann auch Security meldet.

Zitat von: rudolfkoenig am 13 März 2016, 20:34:44
- die Laenge der Nachricht bei secNetworkkeySet ist 93 Bytes, das geht mit ZWCUL nicht, da das Firmware versucht die komplette Nachricht ins CC1101 Puffer (64 Bytes) zu stecken. Ich fuerchte, da muss ich was umbauen, damit das funktionieren kann.

Oh, in der Tat sind die Nachrichten mit Security recht lang. Das Empfangen von langen, zweigeteilten Nachrichten ist ja implementiert, das teilen in zwei lange Nachrichten momentan allerdings noch nicht. Das mit dem Buffer von ZWCul ist natürlich jetzt aufwändiger. Für den Empfangsbuffer wird mMn GDO2 genutzt, ist GDO0 verbunden und könnte dann für den Sendbuffer verwendet werden?

Zitat von: rudolfkoenig am 13 März 2016, 20:34:44
- Secure-Inclusion ging schief, weil der AS6 zweimal ein Nonce angefordert hat. Er hat danach auch jeweils eine mit dem (vermutlich) "richtigen" Nonce verschluesselte Meldung zurueckgeschickt, FHEM hat aber beide Nachrichten verworfen, weil die Erste nicht mit dem letzten Nonce verschluesselt war, und die Zweite, weil beim Verwerfen der ersten Nachricht die zweite Nonce vernichtet wurde. @Andreas: soll ich das anschauen, oder willst du?

Momentan habe ich leider keine Zeit mich darum zu kümmern... Ich bin eben erst aus dem Ski-Urlaub zurückgekommen und habe jetzt noch drei Tage Zeit eine längere Dienstreise vorzubereiten. Danach bin ich dann bis Anfang Mai nicht da... Danach könnte ich mich wieder darum kümmern, voher geht nicht.

Der Ablauf mit den Nonce ist nicht wirklich "sicher". Ich speichere immer nur die letzte, wenn da eine andere Übertragung dazwischen kommt dann geht das ziemlich sicher schief...

Gruß,
Andreas.

Doppelclick fuer Secure-Inclusion bei der AS6 funktioniert, danke fuer den Hinweis. Und die letzten sendStack Aenderungen scheinen bei Security keinen Schaden zu verursachen: schalten klappt, auch ein "get versionClassAll" geht problemlos und schnell ueber die Buehne.