Acks werden falsch zugeordnet und dadurch andere Stackeinträge gelöscht.

[maniachotmail]

Ich hab nach längerer Suche herausgefunden, dass bei empfangenem Ack einfach der erste Eintrag im Sendestapel entfernt wird, ohne zu überprüfen, ob dieser auch dazu gehört.
Man kann das Problem relativ leicht beheben:
00_ZWDongle Zeile 566:
-    ZWDongle_shiftSendStack($hash, 1, 5, "device ack reveived")
-      if($msg =~ m/^0013/);
+    ZWDongle_shiftSendStack($hash, 1, 5, "device ack reveived $1")
+      if($msg =~ m/^0013(..)/);
00_ZWDongle Zeile 415:
-  } else {
-    shift @{$ss};
-    Log3 $hash, $loglevel, "$txt, removing $cmd from dongle sendstack"
-        if($txt && $cmd);
-    $hash->{WaitForAck}=0;
-    $hash->{SendRetries}=0;
-    $hash->{MaxSendRetries}=3;
-    delete($hash->{GotCAN});
-  }
+  } elsif($txt =~ m/^device ack reveived (.*)/) {
+    if($1 eq substr($cmd,-4,2)) {
+     shift @{$ss};
+     Log3 $hash, $loglevel, "$txt, removing $cmd from dongle sendstack"   
+         if($txt && $cmd);
+     $hash->{WaitForAck}=0;
+     $hash->{SendRetries}=0;
+     $hash->{MaxSendRetries}=3;
+     delete($hash->{GotCAN}); 
+    }
+  } else {
+    shift @{$ss};
+    Log3 $hash, $loglevel, "$txt, removing $cmd from dongle sendstack"
+        if($txt && $cmd);
+    $hash->{WaitForAck}=0;
+    $hash->{SendRetries}=0;
+    $hash->{MaxSendRetries}=3;
+    delete($hash->{GotCAN}); 
+  }


Den zweiten Teil kann man wahrscheinlich vereinfachen, da ich den Code aber nicht völlig überblicke, sollte mein Patch so minimalinvasiv wie möglich sein.
Hoffe, ich hab das so richtig gemacht, wenn nicht bitte Info zur Verbesserung.

[rudolfkoenig]

Habe eine kuerzere Version eingecheckt, bitte pruefen.

[maniachotmail]

Funktioniert so ganz gut.
Prinzipiell besteht jedoch immer noch das Problem, dass ZWave_processSendStack aus der darüberliegenden Schicht unabhängig von eventuellen Re-sends nach 5 Zeiteinheiten abbricht und so eventuell einen Command entfernt, der noch nicht mal die Chance hatte gesendet zu werden, wenn der Sendestack gut gefüllt ist.
Generell finde ich den ganzen Sendestack recht "wacklig". Das Warten auf ein Acknowledge von nur einem Befehl bevor andere gesendet werden führt in den oberen Schichten zu gefährlichen Latenzen, die meiner Meinung nicht sinnvoll über Timeouts sondern nur über vertikal die Schichten durchlaufende Events verarbeitet werden können. Es sollte aus diesem Grund der Stabilität sogar förderlich sein, Commands quasi parallel abzuarbeiten.
Bitte nicht falsch verstehen, ich finde die hier geleistete Arbeit echt super, die FHEM ist definitiv eines der allerbesten Beispiele, was OpenSource tolles leisten kann.
Ich hoffe, mir bleibt im Sommer mal etwas Zeit übrig um etwas mehr dazu beizutragen.

[rudolfkoenig]

Commands quasi parallel abzuarbeiten.

Bitte bedenken, dass (zumindest manche) ZWave-Dongles dazu nicht in der Lage sind: beim Absetzen einer zweiten Nachricht, bevor der Empfang der Vorherigen per 0013 bestaetigt wurde, kriegt man CAN vom Dongle. Auch ZWCUL kann es nicht, da es wg. Resend z.Zt. nur das letzte Befehl merkt.
Bis belastbare Statistiken das Gegenteil beweisen , bin ich dagegen eine Nachricht vor dem ACK der Letzten loszuschicken, da ich befuerchte dass ACK und Nachricht #2 kollidieren.

[krikan]

Prinzipiell besteht jedoch immer noch das Problem, dass ZWave_processSendStack aus der darüberliegenden Schicht unabhängig von eventuellen Re-sends nach 5 Zeiteinheiten abbricht und so eventuell eventuell einen Command entfernt, der noch nicht mal die Chance hatte gesendet zu werden, wenn der Sendestack gut gefüllt ist.

Für mein Verständnis: Sind das theoretische Überlegungen oder anhand von Tests bestätigte Feststellungen? Heißt: Wie ernst muss ich die Aussage werten? 
Hintergrund: Ich suche (immer noch) ein Problem bei der Abarbeitung des Sendstacks iZm SECURITY; finde aber anhand der Logs keine Auffälligkeit

Commands quasi parallel abzuarbeiten.

Welche Zwave-Software macht das? Mir ist keine bekannt.

Gruß, Christian

[maniachotmail]

Ich habe mir einen Razberry besorgt (http://zwave.me/). In der ExpertGUI gibt es eine Möglichkeit sich den Stack anzeigen zu lassen und dort habe ich gesehen, dass mehrere Commands abgesetzt wurden und dann auf die Acks (Mehrzahl) gewartet wurde.
Der eigentliche Grund diese Hard- und Software einzusetzen war aber die Möglichkeit einen defekten Stick zu klonen und so zu ersetzen.
Bei ZWave werden wichtige Informationen ja nicht (nur) in der Steuersoftware (FHEM) vorgehalten, sondern auch direkt auf dem Stick.
Bei einem "Standard"-Stick (zB AEON) müßte man also das Netz neu aufbauen und alle Geräte neu inkludieren, wenn der Stick einfach so ohne Vorwarnung stirbt.
Bei meinen z.Z. 45 ZWave-Geräten ein Unding.
Die Software von zwave.me kann (inzwischen) ohne Probleme die Zusatzplatine - also den "Stick" - klonen (getestet!).
Die Zusatzplatine kann idioteneinfach z.B. per USB-Adapter mit FTDI oder ähnlichem Chip an den PC (also USB <-> seriell) angeschlosssen werden. Ich glaube, die hatte ich mal von amazon für 3,5€ das Stück gekauft.
Voilà.
Auf diese Weise konnte ich auch die sehr gut gemachte Funktionalität zum Aufbau des Netzwerkrouting verwenden.
Zwar geht das mit neighborUpdate anscheinend auch bei der FHEM, aber die Auswertung ist dort schwierig. So eine schöne Matrix mit "gute Verbindung"/"schlechte Verbindung" wäre nett
Es kann aber natürlich gut sein, dass z.B. der AEON-Stick das gar nicht alles kann, aber wie beschrieben, von dieser Hardware würde ich inzwischen dringend abraten.

[rudolfkoenig]

So eine schöne Matrix mit "gute Verbindung"/"schlechte Verbindung" wäre nett (https://forum.fhem.de/Smileys/default/smiley.gif)

Wenn du mir zeigst, wie man die noetigen Infos herkriegt, dann kriegst du eine Matrix.

Bei einem "Standard"-Stick (zB AEON) müßte man also das Netz neu aufbauen und alle Geräte neu inkludieren, wenn der Stick einfach so ohne Vorwarnung stirbt.

Oder man setzt, wenn das ZWDongle kaputtgegangen ist, ein CUL als Ersatz ein.

[maniachotmail]

Ja, wenn ich das wüsste, würde ich es auch gleich schreiben
Vielleicht kann man auf die dafür verwendeten Informationen schließen, wenn man den Datenaustausch zwischen zwave.me und Erweiterungsplatine mitprotokolliert.

Seit wann kann man einen CUL als ZWDongle einsetzen? Davon steht nichts im Wiki.

[krikan]

In der ExpertGUI gibt es eine Möglichkeit sich den Stack anzeigen zu lassen und dort habe ich gesehen, dass mehrere Commands abgesetzt wurden und dann auf die Acks (Mehrzahl) gewartet wurde.

Dann wäre das mMn neu in z-way. Alle Logs die ich kenne, haben keine parallele Verarbeitung gezeigt. Hast Du auch mal in die Logs geschaut? z-way berücksichtigt jedoch in irgendeiner Form frühere Telegrammlaufzeiten bei ausbleibenden Antworten.

Die Software von zwave.me kann (inzwischen) ohne Probleme die Zusatzplatine - also den "Stick" - klonen (getestet!).

Problem von razberry/UZB1 : Die nutzen keine Standardfunktionen, sondern ihre eigene Firmwareerweiterung für das Klonen. Und das finde ich nicht ideal.
AEOTEC Gen5 hat übrigens auch eine Backup-Software, ob es dort anders/besser ist?
Wenn Du über den uralten AEOTEC S2 schreibst, dann würde ich den mit SDK5 sowieso als nicht mehr marktrelevant betrachten. Obwohl AEOTEC gerade noch dafür ein Update spendiert hat.

So eine schöne Matrix mit "gute Verbindung"/"schlechte Verbindung" wäre nett

Ist das die Auswertung, wer viele Neigbours hat =gut und wenige =schlecht?

Darf ich noch mal zum Ausgangsproblem kommen, bei dem mich Infos freuen würden.

Für mein Verständnis: Sind das theoretische Überlegungen oder anhand von Tests bestätigte Feststellungen? Heißt: Wie ernst muss ich die Aussage werten? 
Hintergrund: Ich suche (immer noch) ein Problem bei der Abarbeitung des Sendstacks iZm SECURITY; finde aber anhand der Logs keine Auffälligkeit

[krikan]

Ja, wenn ich das wüsste, würde ich es auch gleich schreiben
Vielleicht kann man auf die dafür verwendeten Informationen schließen, wenn man den Datenaustausch zwischen zwave.me und Erweiterungsplatine mitprotokolliert.

Ist das die Auswertung auf Seite 13/14 in diesem Dokument: http://razberry.z-wave.me/docs/RaZberryEndUserManual20.pdf ? Dazu braucht man nichts mitprotokollieren.
Das sind zwapi-Funktionen.

Beim Thema Wiki/Zwave@Cul bummel ich eben    und hoffe auf andere Wiki-Schreiber. 

[rudolfkoenig]

Seit wann kann man einen CUL als ZWDongle einsetzen? Davon steht nichts im Wiki.

Je nach Anspruch seit 2-3 Monaten, siehe diese Diskussion, und ich suche Tester

Ist noch nicht ganz fertig (Routing ist statisch, Secure Kommunikation ist noch "problematisch"), und ich glaube nicht, dass wir das Lauschen auf allen 3 Baudraten hinkriegen. Manche Geraete senden bestimmte Nachrichten aus Lizenzgruenden immer auf 9.6kBaud (z.Bsp. der Knopfdruck bei Aeotec SmartSwitch 6), waehrend die "normale" Kommunikation auf 40k/100k laeuft.

Dafuer hat man mit einem CUL jetzt schon deutlich bessere Debuggingmoeglichkeiten als mit einem ZWDongle, da man alle Funknachrichten direkt sieht. Man kann ordentliche Antennen verwenden, ein separates Backup ist nicht notwendig, und die Firmware ist Open-Source.

[krikan]

Problem von razberry/UZB1 : Die nutzen keine Standardfunktionen, sondern ihre eigene Firmwareerweiterung für das Klonen. Und das finde ich nicht ideal.

Hieraus http://www.zwave.de/thema/sicherung/#post-3725 habe ich die Nutzung einer Eigenentwicklung geschlossen. Darin bin ich mir jetzt aber nicht mehr so sicher. Alle mir bekannten Sticks, die Backup/Restore versprechen (UZB1/Razberry, AEOTEC Gen5, Vision ZU1401-5) , haben u.a. zusätzlich folgende Controller-Caps

Code Auswählen Erweitern

NVM_GET_ID NVM_EXT_READ_LONG_BUFFER NVM_EXT_WRITE_LONG_BUFFER NVM_EXT_READ_LONG_BYTE NVM_EXT_WRITE_LONG_BYTE
Das AEOTEC Backup/Restore-Programm kann auch fremde Sticks auslesen, wenn man deren Security-Key(?) kennt.
Leider finde ich keine Infos zu den genannten Caps. Wer welche hat, kann die gerne mitteilen. 

[rudolfkoenig]

Laut "Appl. Prg. Guide" gibt es ein ZW_nvm_addr.h, leider hat das bisher keiner auf dem Netz "verloren".
Wo findet man das  AEOTEC Backup/Restore Programm (bzw. ist es das IMATool von der Download-Seite)?
Und wo findet man ein Security-Key fuer den ZME-UZB1?

[krikan]

Wo findet man das  AEOTEC Backup/Restore Programm

https://aeotec.freshdesk.com/support/solutions/articles/6000108806-z-stick-gen5-backup-software

Und wo findet man ein Security-Key fuer den ZME-UZB1?

Keine Ahnung. Wusste bis heute nicht mal, dass es so etwas gibt. Steht aber so im PDF zur AEOTEC-Backup-Software.
Evtl. NVM_GET_ID abrufen; mir fehlt bisher noch der Mut...

[rudolfkoenig]

Will nichts mit der UZB1 anfangen, weder LED noch Powerlevel oder read EEPROM klappt.
Komischerweise kann ich mit snoopy auch nichts protokollieren.