Probleme bei "set <device> configRequestAll"

[krikan]

Hallo Rudi,

habe ein paar Tests mit dem neuen Kommando und netzbetriebenen Geräten gemacht. Folgende Auffälligkeiten bei mir:

• Fibaro FGRM222: Es gibt Telegrammverluste beim Versand; d.h. einzelene Abfragen gehen verloren. Hier tritt mMn das im SECURITY-Thread angesprochene Thema der fehlenden Überwachung auf fehlgeschlagenen Versand 011300 als Problem auf. Neben zu häufigen CANs. Überlege auch schon, ob nicht doch noch eine zusätzliche Überwachung von 0013.... auf Node-Ebene notwendig ist. Also 3Stufig, bei 0013xx01=Fehler keine Resends, sondern den Node sperren. Log anbei. Ist reproduzierbar.
• AEOTEC LED:Hier kannst Du im list erkennen, dass nicht alle Readings aktualisiert sind. 6 aktualisierte configXY-Readings, aber deutliche mehr verschickte Telegramme. Problemursache erkenne ich nicht. Es fehlen auch reproduzierbar einzelne Readings. Habe den Fall nur vorab beigefügt. Wollte mir das XML noch mal  auf Fehler anschauen. Wobei immer verschiedene zuvor aktualisierte configXY bei folgenden Abfragen fehlen, was für mich gegen ein alleiniges Problem mit dem XML spricht. list und log anbei.

Mich wundert, dass ich solche Telegrammverluste mit netzbetriebenen Aktoren zuvor nie hatte. Und ich habe das System auch vor eineiger Zeit bei diversen Tests mit Abfragen überzogen; tlw. mit for each -Konstruktionen. Daher kann ich ein Problem hier nicht ausschließen. Stelle aber sonst nichts fest und das kommt aus dem Produktivsystem, wo Beschwerden kommen würden. Dennoch wäre Gegentest von anderen nicht schlecht.

Wenn Du mehr brauchst, bitte anfordern.

Gruß, Christian

[krikan]

Beim batteriebtriebenen FGMS-001 auch Telegrammverluste mit:

Code Auswählen Erweitern

2015.08.31 18:57:03 5: SW: 06
2015.08.31 18:57:03 5: ZWDongle_0 dispatch 011300
2015.08.31 18:57:03 2: ERROR: cannot SEND_DATA: 00
Verzichte erst einmal auf das ausführliche Log, da es für mich gleich zum FGRM222 aussieht. Wenn mehr gebraucht wird, liefere ich es nach.

Beim Absetzen von "set <device> configRequestAll" wird der Hinweis "Scheduled for sending after WAKEUP" nicht wie sonst am Bildschirm angezeigt. Im Log ist er vorhanden.

[krikan]

Das callback = 0013xx vor Versand der nächsten Nachricht abgewartet werden soll, ergibt sich mMn aus NOTE zu "completeFunc callback" in ins*.
Nur warum tritt das jetzt erst bei mir als Problem auf !?

[rudolfkoenig]

Hallo Christian,

bitte solche logs mit "attr global mseclog" machen.

Was mir beim AOTECLED auffaellt ist, dass dein System 2-3 Sekunden benoetigt, um 10 Abfragen in die Warteschlange zu stellen, mein System hat gestern 19 Abfragen fuer ein FGS221 in 0.06 Sekunden in die Warteschlange gestellt. Da ich nicht vorstellen kann, dass mein Rechner 63 bis 95-mal schneller ist, muss hier noch was anderes am Werk sein. Auf was fuer ein Prozessor/OS laeuft FHEM bei dir? Meins war ein 8-9 Jahre altes 2GHz Core2 mit Ubuntu 12.04. Das verwendete ZWDongle ist das Goodway WD6001, auch nicht das neueste/beste.

Weiterhin komisch, dass selbst die allererste Nachricht erst nach dem dritten resend mit ACK bestaetigt wird, die anderen sind hier noch alle brav in der Schlange. Hier liegt wohl ein Problem vor, was unabhaengig vom configRequestAll ist, und das sollten wir zunaechst loesen. Obwohl die "2 Sekunden lang keine Antwort vom Dongle" mich etwas ideenlos zuruecklaesst.
configRequestAll macht nichts anderes, als alle moeglichen config Abfragen, die man sonst per get absetzt, per set abzusetzen (set dev configXXX request), als nix Weltbewegendes, das gleiche kriegt man mit Massen-Schalt-Befehlen (set ZWave.* off) auch hin.

Hast du mit associationRequestAll aehnliche Probleme? Batteriebetrieben konnte ich nur das testen, da mein KFOB2 kein config Eintrag hat. Lief aber ohne Probleme ab. Btw. versionClassRequest ist auch nichts anderes, als eine Reihe von Befehlen, und das klappt mit dem KFOB fuer die 19 Klassen der KFOB ohne Verlust in 1.45 Sekunden. Allerdings wird der N+1-te erst dann losgeschickt, wenn die Antwort auf die Frage Nr N angekommen ist. Genau so wie beim associationRequestAll. Vlt. muss configRequestAll auch auf diese Muster umgestellt werden, allerdings haben wir das Problem mit "set Zwave.* off" immer noch nicht geloest.

Gruss,
  Rudi

[krikan]

Hallo Rudi!

bitte solche logs mit "attr global mseclog" machen.

Sorry, vergesse ich jedes Mal. Habe auch von "SECURITY"-Andreas schon einen Rüffel bekommen  .

Auf was fuer ein Prozessor/OS laeuft FHEM bei dir? Meins war ein 8-9 Jahre altes 2GHz Core2 mit Ubuntu 12.04. Das verwendete ZWDongle ist das Goodway WD6001, auch nicht das neueste/beste.

Raspi B+ mit Raspian (Jessie). Ich gebe zu der ist belastungsmäßig am Anschlag (durchschittl. 50 % Systemlast), zeigt aber im Alltagsbetrieb keine für mich/uns erkennbaren Ausfälle. Log ist sauber. Dongle ist der Vision, der zeitweise keine Bestätigungen lieferte (vielleicht erinnerst Du Dich noch). Habe den mit mehreren Resets wiederbelebt. Vielleicht hat der doch eine bleibende Macke und sollte ausgetauscht werden; habe daran aber kein Vergnügen.

Also werde ich mal auf meinem Testsystem (i7, UZB1, aber Win10) probieren und berichten. Dort sind nur andere Geräte eingebunden.

Hast du mit associationRequestAll aehnliche Probleme?

Keine Auffälligkeiten.

versionClassRequest

Klappt auch bei allen problemlos.

Im Fazit auch ideenlos.

allerdings haben wir das Problem mit "set Zwave.* off" immer noch nicht geloest

Lässt sich das nicht über die 3stufige Prüfung lösen:
Controller-Ablage bis ACK
dann erst warten bis 011301 und resends bei Fehler (011300)
dann erst warten bis 0013xx00 und dann erst nächstes Telegramm. Bei Fehler (0013xx01) Node für weitere Telegramme sperren und keine Resends.
-> Folgerung aus ins*?

Gruß, Christian

[krikan]

Was mir im nachhinein zum Aeotec LED einfällt:
Der ist das Gerät mit der größten Entfernung vom Controller und ich habe ihn erst kurz vorher eingeschaltet und keine Befehle hingeschickt. Spekulation: Evtl. waren Routen noch nicht optimal.

[krikan]

Habe bei mir auch mit noExplorerFrames 1 in Anlehnung an http://forum.fhem.de/index.php/topic,40537.0.html getestet. Ändert nichts; gleiche Problem wie zuvor.

[krikan]

Auf meinem Testsystem (i7, Win10, UZB1, nur Philio PST02-1A und nur 1m vom Dongle entfernt) erhalte ich alle configXY-Werte. Aber es wimmelt nur so von CAN; zum Schluß gibt es im 1.Log ein für mich nicht verständliches TRANSMIT_NO_ACK. Habe Dir mal neben dem 1. Log mit Inklusionsprozeß und configRequestAll zum Vergleich ein Log von einer weiteren configRequestAll-Abfrage des Sensors ein paar Sekunden später angehängt.

Aus meiner Sicht sind es bei diesem Test Optimalbedingungen: Controller und Gerät mit 500er Chipsatz. Keine störenden Einflüsse von anderen Geräten. Schneller Rechner,..
Wenn jetzt noch weitere ZWave-Geräte senden würden, gehe ich fast von Verlusten wegen zu vieler CANs aus. Jedoch ist das mMn ein anderes Problem als in meinem Produktivsystem. Dort treten mMn die Telegrammverluste eine Stufe später bei 011300 auf.

[rudolfkoenig]

CANs sind an sich kein Problem, zeigt aber, dass wir zu frueh versuchen zu senden.
Die Alternative waere, auf Sende oder Empfangsbestaetigung zu warten, allerdings ist das deiner Ansicht nach zu langsam. Findest noch die Diskussion dazu, oder kannst du noch konkretes dazu sagen? Ich habe das Problem nicht klar behalten.
Waere die Loesung eine eigene Schlange je Zielgeraet, und dabei den naechsten Telegramm nur senden, falls eine Empfangs- oder Sendebestaetigung vorliegt? Damit bremsen langsame Geraete nicht die schnellen aus, wir haben aber eine bessere Flusskontrolle.

[krikan]

CANs sind an sich kein Problem, zeigt aber, dass wir zu frueh versuchen zu senden.

Genau das sehe ich auch so. Verstehe nur nicht, warum das vorher nicht so war, selbst nicht mit for-each bei wakeup-Sendstack. Ist aber letztlich Geschichte.

Die Alternative waere, auf Sende oder Empfangsbestaetigung zu warten, allerdings ist das deiner Ansicht nach zu langsam. Findest noch die Diskussion dazu, oder kannst du noch konkretes dazu sagen? Ich habe das Problem nicht klar behalten.
Waere die Loesung eine eigene Schlange je Zielgeraet, und dabei den naechsten Telegramm nur senden, falls eine Empfangs- oder Sendebestaetigung vorliegt? Damit bremsen langsame Geraete nicht die schnellen aus, wir haben aber eine bessere Flusskontrolle.

Habe das "zu langsam" mehrfach angebracht, aber in verschiedenen Stufen des Versandprozesses.
Grundlegend im Zusammenhang mit geros Änderungen:
http://forum.fhem.de/index.php/topic,37418.0.html (ab ca. Antwort #49)
Dort war aber das u.a. Problem, dass in der 3. Stufe (0013xx01) mehrere Versandvorgänge vorgenommen wurden, was mMn falsch ist und blockierte. Bei Fehler muss NodeId mMn "gesperrt" werden.
Du hast Dich nach meiner Erinnerung an der gegensätzlichen Bedeutung von 00/01 in Stufe 2 (011301 =OK) und 3 (0013xx01=Fehler) gestört und deshalb die mehrstufige Prüfung ausgebaut.
Mein derzeitiger Meinungsstand siehe Antwort #4, wobei ich noch nicht sicher bin, ob Warten auf 3. Stufe notwendig ist. Jedoch verstehe ich genau diese aus ins* (siehe Antwort #2) und meine openzwave löst das auch so.
Hoffe, das ist noch verständlich. Sonst muss ich meiner "Gedankenwelt" in Ruhe zusammenfassen.
Befürchte sowieso wir müssen einfach probieren.

@A.Harrenberg: Andreas hattest Du Dir das Thema Flußkontrolle bei openzwave schon angeschaut und kannst hierzu etwas schreiben?

[krikan]

Waere die Loesung eine eigene Schlange je Zielgeraet, und dabei den naechsten Telegramm nur senden, falls eine Empfangs- oder Sendebestaetigung vorliegt? Damit bremsen langsame Geraete nicht die schnellen aus, wir haben aber eine bessere Flusskontrolle.

Dazu: Ja.

[A.Harrenberg]

Hi Krikan,

Das callback = 0013xx vor Versand der nächsten Nachricht abgewartet werden soll, ergibt sich mMn aus NOTE zu "completeFunc callback" in ins*.
Nur warum tritt das jetzt erst bei mir als Problem auf !?

habe das Problem jetzt auch mal bei mir "nachgestellt" und dafür sogar die Sirene mit SECURITY genutzt. Ich bekomme da auch 7 CAN Messages bei einer Abfrage.

Ich habe mir mal "spaßeshalber" einen einfachen Zähler gebaut und damit Callback-ID gesetzt. Damit kann ich jetzt zumindest die "Transmit OK" Meldung aus ZWDongle eindeutig der versendeten Nachricht zuordnen, momentan blicke ich da aber dennoch noch nicht so wirklich durch. Mit den Controller-Messages stehe ich nach wie vor irgendwie auf Kriegsfuß...

Sind die Nachrichten mit 01 vorne vom Controller, die mit 00 vorne von der Node?

Code Auswählen Erweitern

2015.09.02 21:20:27.802 1: ZWave_SWITCH_BINARY_152: CallBackID 06
2015.09.02 21:20:27.802 5: ZWDongle_Write 00 13980298402506
2015.09.02 21:20:27.802 5: SW: 0109001398029840250684
2015.09.02 21:20:27.803 4: ZWDongle_ReadAnswer arg:secNonce regexp:^00040098..98
2015.09.02 21:20:28.688 5: ACK received, removing 0109001398029840250684 from sendstack
2015.09.02 21:20:28.700 4: ZWDongle_Read ZWDongle_0: sending ACK, data = 0104011301e8
2015.09.02 21:20:28.700 4: ZWDongle_Read ZWDongle_0: sending ACK, processing 011301
2015.09.02 21:20:28.700 5: SW: 06
2015.09.02 21:20:28.701 5: ZWDongle_0 dispatch 011301
2015.09.02 21:20:28.701 2: ZWave_Parse: msg: 011301
2015.09.02 21:20:28.729 4: ZWDongle_Read ZWDongle_0: sending ACK, data = 0107001306000002ef
2015.09.02 21:20:28.729 4: ZWDongle_Read ZWDongle_0: sending ACK, processing 001306000002
2015.09.02 21:20:28.729 5: SW: 06
2015.09.02 21:20:28.730 5: ZWDongle_0 dispatch 001306000002
2015.09.02 21:20:28.730 2: ZWave_Parse: msg: 001306000002
2015.09.02 21:20:28.730 4: ZWDongle_0 CMD:ZW_SEND_DATA ID:00 ARG:0002
2015.09.02 21:20:28.730 4: ZWDongle_0 transmit OK for 06

Die CallBack-ID taucht jedenfalls nur in der 0013 Nachricht wieder auf.

Code Auswählen Erweitern

2015.09.02 21:20:28.779 4: ZWDongle_Read ZWDongle_0: sending ACK, data = 0110000400980a98809c80c6eb829c252942
2015.09.02 21:20:28.779 4: ZWDongle_Read ZWDongle_0: sending ACK, processing 000400980a98809c80c6eb829c2529
2015.09.02 21:20:28.779 5: SW: 06
2015.09.02 21:20:28.780 4: ZWDongle_ReadAnswer for secNonce: 000400980a98809c80c6eb829c2529
2015.09.02 21:20:28.780 2: ZWave_Parse: msg: 000400980a98809c80c6eb829c2529
2015.09.02 21:20:28.780 4: ZWDongle_0 CMD:APPLICATION_COMMAND_HANDLER ID:98 ARG:0a98809c80c6eb829c2529
2015.09.02 21:20:28.780 3: ZWave_SWITCH_BINARY_152 SECURITY: 7005fc retrieved for encryption
2015.09.02 21:20:28.781 2: ZWave set ZWave_SWITCH_BINARY_152 secEncap 81ccc3bfb28a989c9b42b271519c9b6b587eb27a1265
2015.09.02 21:20:28.781 1: ZWave_SWITCH_BINARY_152: CallBackID 07
2015.09.02 21:20:28.781 5: ZWDongle_Write 00 1398179881ccc3bfb28a989c9b42b271519c9b6b587eb27a12652507
2015.09.02 21:20:28.781 5: SW: 011e001398179881ccc3bfb28a989c9b42b271519c9b6b587eb27a1265250774
2015.09.02 21:20:28.782 2: ZWave set ZWave_SWITCH_BINARY_152 configPartnerID request
2015.09.02 21:20:28.782 1: ZWave_SWITCH_BINARY_152: CallBackID 08
2015.09.02 21:20:28.782 3: ZWave_SWITCH_BINARY_152 SECURITY: 7005c8 stored for encryption
2015.09.02 21:20:28.783 2: ZWave get ZWave_SWITCH_BINARY_152 secNonce
2015.09.02 21:20:28.783 1: ZWave_SWITCH_BINARY_152: CallBackID 09
2015.09.02 21:20:28.783 5: ZWDongle_Write 00 13980298402509
2015.09.02 21:20:28.783 4: ZWDongle_ReadAnswer arg:secNonce regexp:^00040098..98
2015.09.02 21:20:28.787 5: ACK received, removing 011e001398179881ccc3bfb28a989c9b42b271519c9b6b587eb27a1265250774 from sendstack
2015.09.02 21:20:28.787 5: SW: 010900139802984025098b
2015.09.02 21:20:28.803 4: ZWDongle_Read ZWDongle_0: sending ACK, data = 0104011301e8
2015.09.02 21:20:28.803 4: ZWDongle_Read ZWDongle_0: sending ACK, processing 011301
2015.09.02 21:20:28.803 5: SW: 06
2015.09.02 21:20:28.804 5: ZWDongle_0 dispatch 011301
2015.09.02 21:20:28.804 2: ZWave_Parse: msg: 011301
2015.09.02 21:20:28.804 4: ZWDongle_Read ZWDongle_0: CAN received
2015.09.02 21:20:28.804 5: SW: 010900139802984025098b
2015.09.02 21:20:28.806 5: ACK received, removing 010900139802984025098b from sendstack
2015.09.02 21:20:28.826 4: ZWDongle_Read ZWDongle_0: sending ACK, data = 0104011301e8
2015.09.02 21:20:28.826 4: ZWDongle_Read ZWDongle_0: sending ACK, processing 011301
2015.09.02 21:20:28.827 5: SW: 06
2015.09.02 21:20:28.828 5: ZWDongle_0 dispatch 011301
2015.09.02 21:20:28.828 2: ZWave_Parse: msg: 011301
2015.09.02 21:20:28.850 4: ZWDongle_Read ZWDongle_0: sending ACK, data = 0107001309000001e3
2015.09.02 21:20:28.851 4: ZWDongle_Read ZWDongle_0: sending ACK, processing 001309000001
2015.09.02 21:20:28.851 5: SW: 06
2015.09.02 21:20:28.852 5: ZWDongle_0 dispatch 001309000001
2015.09.02 21:20:28.852 2: ZWave_Parse: msg: 001309000001
2015.09.02 21:20:28.852 4: ZWDongle_0 CMD:ZW_SEND_DATA ID:00 ARG:0001
2015.09.02 21:20:28.852 4: ZWDongle_0 transmit OK for 09
Im nachfolgenden kommt es dann zur CAN-Message, der Re-Send scheint jedoch angekommen zu sein.

Diese Nachricht wird verschickt
2015.09.02 21:20:28.781 5: SW: 011e001398179881ccc3bfb28a989c9b42b271519c9b6b587eb27a1265250774

Diese Nachricht dann bevor es eine RM vom Controller oder der Node gegeben hat:
2015.09.02 21:20:28.787 5: SW: 010900139802984025098b

Damit wäre schon mal geklärt das es eine CAN Message gibt wenn man vorher noch was sendet...

Gruß,
Andreas.

[A.Harrenberg]

Hi Krikan,

@A.Harrenberg: Andreas hattest Du Dir das Thema Flußkontrolle bei openzwave schon angeschaut und kannst hierzu etwas schreiben?

jein...

Ich habe das zwangsläufig bei der Analyse des Codes und in den Logs gesehen, mir aber  nicht im Detail angesehen. Vor allem nicht den Umgang mit CAN, NO_ACK etc.

Soweit ich das gesehen (und verstanden) habe, verwaltet OZW so ca. 5 verschiedene Queues pro Node und unterscheidet dabei nach verschiedenen Stadien im Versand, einer WakeUp-Queue, einer Queue in der die Nachrichten aus der WakeUp-Queue zum Versenden zwischengespeichert werden und so weiter. Nachrichten werden da "lustig" von einer Queue in die andere übertragen.

Jeder Nachricht wird eine Callback-ID zugeordnert und es wird bei jeder Nachricht die Klasse und der erwartete Befehl der Antwort abgelegt. Eintreffende Antworten werden dann mit den gespeicherten Callback-IDs verglichen, wobei ich das anhand des Verhaltens von FHEM-ZWave nicht nachvollziehen kann, da ich hier die CallBack-ID nicht in der Antwort finde.

Code Auswählen Erweitern

2015.09.02 22:33:41.651 2: ZWave get ZWave_SWITCH_BINARY_152 zwavePlusInfo
2015.09.02 22:33:41.651 1: ZWave_SWITCH_BINARY_152: CallBackID 14
2015.09.02 22:33:41.651 5: ZWDongle_Write 00 1398025e012514
2015.09.02 22:33:41.652 5: SW: 0109001398025e01251411
2015.09.02 22:33:41.653 4: ZWDongle_ReadAnswer arg:zwavePlusInfo regexp:^00040098..5e
2015.09.02 22:33:42.314 5: ACK received, removing 0109001398025e01251411 from sendstack
2015.09.02 22:33:42.330 4: ZWDongle_Read ZWDongle_0: sending ACK, data = 0104011301e8
2015.09.02 22:33:42.330 4: ZWDongle_Read ZWDongle_0: sending ACK, processing 011301
2015.09.02 22:33:42.330 5: SW: 06
2015.09.02 22:33:42.331 5: ZWDongle_0 dispatch 011301
2015.09.02 22:33:42.332 2: ZWave_Parse: msg: 011301
2015.09.02 22:33:42.361 4: ZWDongle_Read ZWDongle_0: sending ACK, data = 0107001314000002fd
2015.09.02 22:33:42.361 4: ZWDongle_Read ZWDongle_0: sending ACK, processing 001314000002
2015.09.02 22:33:42.361 5: SW: 06
2015.09.02 22:33:42.362 5: ZWDongle_0 dispatch 001314000002
2015.09.02 22:33:42.363 2: ZWave_Parse: msg: 001314000002
2015.09.02 22:33:42.363 4: ZWDongle_0 CMD:ZW_SEND_DATA ID:00 ARG:0002
2015.09.02 22:33:42.363 4: ZWDongle_0 transmit OK for 14
2015.09.02 22:33:42.411 4: ZWDongle_Read ZWDongle_0: sending ACK, data = 010f00040098095e020105000f000f003d
2015.09.02 22:33:42.411 4: ZWDongle_Read ZWDongle_0: sending ACK, processing 00040098095e020105000f000f00
2015.09.02 22:33:42.411 5: SW: 06
2015.09.02 22:33:42.412 4: ZWDongle_ReadAnswer for zwavePlusInfo: 00040098095e020105000f000f00
2015.09.02 22:33:42.412 2: ZWave_Parse: msg: 00040098095e020105000f000f00
2015.09.02 22:33:42.412 4: ZWDongle_0 CMD:APPLICATION_COMMAND_HANDLER ID:98 ARG:095e020105000f000f00

Hier taucht die "14" als CallBack-ID nur in der Controllerantwort auf, in der empfangenen Antwort ist davon nichts zu finden, ich habe mir sogar mal eine Log-Meldung mit der ganzen Nachricht (data = ) in ZWDongle gebaut. Eigentlich würde ich ja erwarten das auch die Antwort die CallBack-ID trägt. Zumindest habe ich das aus OZW so "mitgenommen".

Etwas ratlos,
Andreas.

[A.Harrenberg]

Hallo Rudi,

Waere die Loesung eine eigene Schlange je Zielgeraet, und dabei den naechsten Telegramm nur senden, falls eine Empfangs- oder Sendebestaetigung vorliegt? Damit bremsen langsame Geraete nicht die schnellen aus, wir haben aber eine bessere Flusskontrolle.

ich bin mir nicht ganz sicher ob dies ausreichend für Security ist. Wenn auf die Empfangs- oder Sendebstätigung gewartet wird ist damit ja nur Sichergestellt das der Befehl angekommen ist und das keine CAN-Message durch zu frühes Senden einer weiteren Nachricht provoziert wird.

So wie ich Dich im Security-Thread verstanden habe, wird bei GET-Befehlen anschliessend gewartet bis eine Antwort eingetroffen ist. (Ist dies eigentlich "irgendeine" Nachricht von der betreffenden Node?) Wenn das die richtige Antwort ist, wäre soweit alles gut, falls nicht, was passiert dann?

Ich sehe momentan zwei mögliche Probleme für Security "nur" auf die Bestätigung zu warten:

a.) mMn muss die gesamte Kette aus bis zu 8 Nachrichten zwischen Controller und Node ohne Unterbrechung durch eine anderen Nachricht erfolgen. Nur auf die Bestätigung zu warten dürfte zwar gegen die CAN-Messages wirken, verhindert aber nicht das die Nachrichtenkette unterbrochen wird.

b.) Der "Trick" bei den GET-Befehlen auf eine Antwort zu warten funktioniert bei SECURITY nicht mehr so einfach. Was in einer verschlüsselten Nachricht steckt sieht man von außen nicht mehr, hier müsste man irgendwie parallel zum codierten Befehl den Typ (Set oder Get) speichern.

Eine Lösung für a.) habe ich jetzt auch nicht direkt parat, vielleicht müssen wir auch erst mal gezielt versuchen, so eine Kommunikationskette mit einem anderen Befehl zu unterbrechen, um zu sehen was dann passiert.

@Rudi: (leicht Off-Topic) Siehst Du eine Chance Security in den aktuellen Code zu übernehmen BEVOR hier größere Umbaumaßnahmen beginnen? Ich denke wir sollten erst mal sehen was sich hieraus noch an Anforderungen für eine Flusskontrolle ergeben. Ich hätte sonst Angst das da jetzt mit viel Aufwand was umgebaut wird, das dann mit Security doch nicht richtig läuft.

Gruß,
Andreas.

P.S.: Von den Timern in Security rede ich jetzt noch nicht mal...

[rudolfkoenig]

Ich habe die Warteschlangen neu gebaut:
- ZWDongle prueft nun nicht mehr auf wakeupNoMoreInformation, der SendStack ist da einfacher geworden
- alle ZWave Geraete (ob mit oder ohne WAKE_UP) haben ein SendStack (ehemals WakeUp)
- Bei WAKE_UP Geraeten kommen die Befehle auf diesem Stack (wie frueher auf WakeUp), das erste Kommando wird losgeschickt, falls ein wakeup:notification eintrifft oder ein ZW_APPLICATION_UPDATE (auch wie bisher). Nachfolgende Kommandos werden erst losgeschickt, falls ein 0013..00 eintrifft (Antwort vom Geraet, habe Nachricht erhalten), oder ein 011300 (Nachricht vom ZWDongle, konnte Nachricht _nicht_ senden). Beim Letzteren bin ich unsicher.
- Bei Geraeten ohne WAKE_UP wird das erste Befehl sofort geschickt, die weiteren werden genauso behandelt, wie bei WAKE_UP. Ausnahme: falls beim Senden eines neuen Befehls festgestellt wurde, dass auf dem Stack unbestaetigte Befehle seit ueber 10 Sekunden rumgammeln, dann werden die alten Daten entfernt, und es wird mit einem leeren SendStack angefangen
- Es gibt ein neues ZWdongle Attribut delayNeeded (default ist 1), was bewirkt, dass nach einem 0013 das naechste Befehl erst mit einem delay von 0.3s versendet wird. Mein Goodway braucht das, das KFOB2 nicht (delayNeeded 0). Damit kann ich configRequestAll auf dem Goodway ohne Probleme absetzen.

Security habe ich nicht getestet, das bleibt erstmal fuer Andreas.