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

[A.Harrenberg]

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.

[A.Harrenberg]

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.

[A.Harrenberg]

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

[A.Harrenberg]

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.

[A.Harrenberg]

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.

[A.Harrenberg]

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

Code Auswählen Erweitern

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.

[A.Harrenberg]

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

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.

[A.Harrenberg]

Hallo,

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

Die 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

Code Auswählen Erweitern

set <gerätename> secNonce
aufrufen und damit einen Befehl aus der Liste abarbeiten, oder man löscht das Reading mit

Code Auswählen Erweitern

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.

[rudolfkoenig]

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.

[A.Harrenberg]

Hallo Rudi,

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.

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

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

[rudolfkoenig]

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

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

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

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

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

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

[krikan]

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.

[A.Harrenberg]

Hallo Rudi,

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.

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.

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.

[A.Harrenberg]

Hallo Christian,

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.

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.

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.

[rudolfkoenig]

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.