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

krikan · 25 April 2016, 21:13:32

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 · 26 April 2016, 09:34:13

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 · 27 April 2016, 08:29:56

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 · 27 April 2016, 08:55:25

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

krikan · 27 April 2016, 21:37:12

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 · 27 April 2016, 22:02:37

Zitat von: krikan am 27 April 2016, 21:37:12
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 · 28 April 2016, 21:04:27

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 · 30 April 2016, 09:26:18

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 · 30 April 2016, 09:34:10

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 · 30 April 2016, 14:17:44

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.