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.

[krikan]

Ich habe sowohl den UZB1 als auch den Vision ZU1401-5 mit Read EEPROM ansprechen können (nur Read EEPROM anklicken, sonst keine Einstellungsänderungen vornehmen). UZB1 ergibt ein 256 KB und Vision ein 128 KB - Bin-File. In den Bin-Files finde ich die HomeId und ansonsten ziemlich viel Analysebedarf. Ein Write EEPROM traue ich mich (noch?) nicht.
Beim ZWave ohne Plus-Stick scheitert Read EEPROM.
Habe dann mal mit Z-way ein Backup vom UZB1 erstellt; das Format ist aber mMn nicht kompatibel.
Weitere Erkenntnisse werden vermutlich schwierig, da das Backup-Programm leider nicht sehr gesprächig ist.

[krikan]

Da ich beim Backupthema leider nicht vorwärtskomme, habe ich mir noch mal im Internet verfügbare z-way-Logs hinsichtlich "paralleler" Abarbeitung angeschaut:

Ich kann nirgends die vom TE angeführte Aussage "mehrere Commands abgesetzt wurden und dann auf die Acks (Mehrzahl) gewartet wurde" feststellen. Laut Logs wird schön der Reihe nach verschickt und auf Antwort gewartet. Erst dann folgt nächstes Command. Wenn jemand die Parallelität anhand z-way-logs feststellen kann bzw. vermutet, dann freue ich mich über das entsprechende Logs (z-way-server.log).

[krikan]

Zum AEOTEC Backupprogramm und Backup von UZB1 mit Restore auf Gen5-Stick:
AEOTEC kennt den UZB1 nicht, aber "if you are able to get a binary file from it then it will work.". Jetzt bin ich endgültig bei der Vermutung Standardfunktionen im ZWavePlus-Controller, aber das Backupprogramm hat kein Log aus dem ich etwas zur Umsetzung erkennen könnte. Ein realer Test ist mir noch zu "heiß" und bringt mich mangels Log hinsichtlich FHEM-Implmentierung wohl nicht weiter. "Led on/off" und "Security Key" im Backupprogramm  sind Spezialitäten/Konfigurationsparameter des batteriebetriebenen AEOTEC-Sticks; siehe http://products.z-wavealliance.org/MarketCertification/File?folder=&filename=MarketCertificationFiles/1355/Z%20Stick%20Gen5%20manual%201.pdf (letze Seite)
Controller-Umzug (Controller Shift), was eigenlich nicht mein Ziel ist  , soll ich laut AEOTEC besser mit https://aeotec.freshdesk.com/solution/articles/6000110204-zensys-tool machen, das sehr gesprächig ist, aber kein Backup kann.

Was ist snoopy?

[rudolfkoenig]

USB Sniffer, protokolliert alle Zugriffe ueber USB.
Gibts inzwischen auch andere.

[krikan]

Für das Backup wird nach Initalisierung und HomeID-Ermittlung unter anderem NVM_GET_ID abgesetzt.  Wiederholt verschícktes NVM_EXT_READ_LONG_BUFFER liest die eigentlichen Daten aus.

Die Nachricht an den Controller "01 04 00 41 01 BB" bekomme ich nicht eingeordnet.

[krikan]

Die Nachricht an den Controller "01 04 00 41 01 BB" bekomme ich nicht eingeordnet.

Habe anscheind zu viele Hex-Werte gesehen: Das ist ZW_GET_NODE_PROTOCOL_INFO für Controller.

[krikan]

Restore mit VISION getestet und erfolgreich.
Beim Restore wird nach NVM_GET_ID mit NVM_EXT_WRITE_LONG_BUFFER die .bin Datei vom Backup 1:1 geschrieben. Logs von Backup/Restore habe ich, sind aber zu groß um hier anzuhängen. Wobei die eigentliche Backuop-/Restore-Logik von zwapi auf den ersten Blick recht simpel erscheint. Ob es die Mühe Wert ist, das in FHEM einzubauen ist ein anderes Thema. Immerhin kenne ich jetzt eine Möglichkeit, um meinen VISION Stick zu sichern.

[rudolfkoenig]

Hab jetzt Windows7 aufgetrieben, da laeuft das Programm sauber durch, erstellt fuer ein ZME-Stick eine 256kb .bin Datei, die aus 4 identischen 64kb Bloecken besteht (vmtl. hat die ZME nur 64kb Speicher). Von dieser 64 ist ca 4k "interessant", sprich nicht mit 0 oder ff gefuellt.

Snoopy laeuft leider nicht unter Windows7, und das MS-eigene Logman Output mit Netmon aufbereitet ist mir zu kryptisch. Kann jemand einen USB-Sniffer empfehlen? Oder wie man das Logman Output "lesbar" aufbereitet?

[krikan]

Habe den http://freeusbanalyzer.com/ genommen und es hat funktioniert. Anderen habe ich nicht getestet; also empfehlen ist schwierig.

Für den Vision gibt es 2 identische 64kb Blöcke in der Bin Datei.

Beim Backup wird für den UZB1 bei mir abweichend zum Vision eine mir unbekannte Controllerfunktion 0xf3 aufgerufen.

Wenn Du meine Analysedaten für Backup von UZB1 und Vision sowie Vision-Restore mit .bin-Dateien haben möchtest, bitte melden.

[krikan]

Auffälligkeit beim Restore auf Vision:

Nach einem Restore habe ich das EEPROM noch einmal ausgelesen und die neue .bin-Dateien mit der ursprünglichen verglichen => Die Dateien sind nicht gleich. Der "Vorspann" zu Beginn der Datei "ZeNsYs" mit folgender HomeId-Angabe ist nach dem Restore ein paar Positionen weiter noch einmal vorhanden. Jedoch steht an gleicher Stelle in beiden Dateien danach ab Offset  0x0f der HexWert von get-NodeInfo.
Dann gibt es noch ein paar Stellen in denen längere Folgen von 00, ff bzw. ef vertauscht sind.

ABER Funktionsprobleme kann ich dennoch nicht feststellen. Alle getesten Befehl arbeiten auch nach dem Restore normal.

Nach einem Controller-Reset (0x42) ist der Vorspann "ZeNsYs" mit HomeId dann wieder nur einmal vorhanden.

Das Backup vom UZB1 enthält auch nach einem Controller-Reset deutlich mehr von ff,00 abweichende "Daten" als der Vision. Sieht so aus, als seien im hinteren Bereich des UZB1 größere Mengen zusätzlicher Daten gespeichert. Restore habe ich beim UZB1 nicht probiert.