ZWDongle Sicherung

Begonnen von rudolfkoenig, 01 Mai 2016, 22:28:10

Vorheriges Thema - Nächstes Thema

FunkOdyssey

Ach, sorry. Ich hatte modpath in /opt/fhem/FHEM vermutet. Dort passten die Rechte. Aber ein chmod 777 auf /opt/fhem hat das Problem gelöst.

krikan

Hallo Rudi!
Hast Du schon den Aufbau der ausgelesenen Daten (Backupdatei) des Dongles analysiert? Habe heute mal damit angefangen; aber will nicht weitermachen, wenn Du sowieso schon alles hast.
Gruß, Christian

rudolfkoenig

Nein, weiss nur, dass homeId irgendwo am Anfang steht.
Die Daten in EEPROM muessen mAn folgendes enthalten:
- nodeId
- Nachbarschaftsbeziehung zu den anderen (neighborList). Wenn Bitfeld, dann sind es 29 Bytes, jedenfalls wird das per API geliefert.
- 3 bis 6 Bytes nodeInfo

krikan

Zitat von: rudolfkoenig am 15 Juli 2016, 14:50:09
Nein, weiss nur, dass homeId irgendwo am Anfang steht.
Die Daten in EEPROM muessen mAn folgendes enthalten:
- nodeId
- Nachbarschaftsbeziehung zu den anderen (neighborList). Wenn Bitfeld, dann sind es 29 Bytes, jedenfalls wird das per API geliefert.
- 3 bis 6 Bytes nodeInfo
Dann mache ich weiter  ;)

Finde alle von Dir erwähnten Angaben außer der NodeIds, die sich wohl einfach aus der Speicherreihenfolge ergeben.
Es wird in 5 Byte-Block pro Node fortlaufend der Inhalt der Antwort auf 0x41 (ZW_GET_NODE_PROTOCOL_INFO) gespeichert. Nicht vorhandene Nodes werden mit 5x 0x00 abgespeichert.
Nachbarschaftsbeziehungen werden mit der Antwort auf 0x80 (GET_ROUTING_TABLE_LINE) = 29 Bytes abgespeichert.
Die homeId mit der Antwort 0x20 (MEMORY_GET_ID).
Dann gibt es noch eine Zahl die zufällig(?) dem Wert der letzten verwendeten NodeId entspricht.
Ansonsten noch ein paar 0xFF, die ich momentan mal als unwichtig einstufe.

Irgendwie ist mir das fast schon zu einfach. Es sind bis auf die omniöse letzte verwendete NodeId alle gespeicherten Werte Abfrageergebnisse der API. Probleme habe ich noch mit der passenden Speicheradresse. Muss noch abgleichen, ob das bei UZB1 und Vision gleich ist.

rudolfkoenig

ZitatEs wird in 5 Byte-Block pro Node fortlaufend der Inhalt der Antwort auf 0x41 (ZW_GET_NODE_PROTOCOL_INFO) gespeichert. Nicht vorhandene Nodes werden mit 5x 0x00 abgespeichert.Nachbarschaftsbeziehungen werden mit der Antwort auf 0x80 (GET_ROUTING_TABLE_LINE) = 29 Bytes abgespeichert. Die homeId mit der Antwort 0x20 (MEMORY_GET_ID).
D.h. all diese Calls sind nur ein "Alias" auf NVM_EXT_READ_LONG_BUFFER

ZitatDann gibt es noch eine Zahl die zufällig(?) dem Wert der letzten verwendeten NodeId entspricht.
Ich meine, das war nicht zufaellig so: ich habe was dazu-Inkludiert, und die Zahl hat sich um eins erhoeht. Ich war aber zu feige zu testen, ob man es wieder auf eins setzen kann :)

Wir sollten eine Methode finden, Controller mit bekannten EEPROM-Layout von welchen mit unbekannten Layout zu unterscheiden, damit wir nicht etwas Neues/Unbekanntes kaputtschreiben, z.Bsp. indem wir den Slot fuer den Controller mit den Angaben ueber nodeInfo/nodeList vergleichen. Und wir erzwingen vorher ein Backup. Oder so.

krikan

Zitat von: rudolfkoenig am 15 Juli 2016, 16:01:28
D.h. all diese Calls sind nur ein "Alias" auf NVM_EXT_READ_LONG_BUFFER
Das will ich nach meiner Feststellung von gerade so direkt nicht behaupten:
Die homeId wird durch SET_DEFAULT am Offset 0x08 gespeichert.
Durch createNewPrimary erhält der Controller eine "neue" homeId des alten zu ersetzenden Sticks. Diese homeId wird unter Offset 0x16 gespeichert. Die per SET_DEFAULT zugeteilte bleibt unter 0x08 erhalten.
0x20 (MEMORY_GET_ID) liefert dann auch die homeId in 0x16 und nicht 0x08, obwohl beide vorhanden.

ZitatIch meine, das war nicht zufaellig so: ich habe was dazu-Inkludiert, und die Zahl hat sich um eins erhoeht. Ich war aber zu feige zu testen, ob man es wieder auf eins setzen kann
An Offset 0x268c steht auch beim 2. Stick die nächste NodeId.
Es gibt irgendeine Controllerwechselfunktion, bei der die Zählung laut API auch wieder von vorne losgeht, habe nur vergessen welche...

Zitat
Wir sollten eine Methode finden, Controller mit bekannten EEPROM-Layout von welchen mit unbekannten Layout zu unterscheiden, damit wir nicht etwas Neues/Unbekanntes kaputtschreiben
Ja.
Tippe derzeit darauf, dass Vision und UZB1 das gleiche Layout haben. Hatte eine Sicherung damals auch zwischen den Controllern vertauscht und im Schnelltest keine Probleme festgestellt.

krikan

#36
Meine vorläufigen Ergebnisse zum Datei/EEP-Layout:

0x08                      = 4 Bytes = homeId = 0x20 komplette Antwort
0xf8  - 0x57f          = 5 Bytes pro Node bei 232 Nodes = nodeInfo = 0x41 Antwort ohne Byte für BASIC DEVICE CLASS oder 5x 0x00 bei nicht vorhanden
                                                                                                          (Bsp.: Antwort: 0141 d39c01041005 gespeichert wird nur d39c011005)
0x580 - 0x1fc7       = 29 Bytes pro Node = neighborList = 0x80 Antwort komplett oder 29x 0x00 bei nicht vorhanden
0x268c                   = 1 Byte = letzte inkludierte NodeId höchste inkludierte NodeId
0x1fc8                    = 1 Byte = von NodeId 1 abweichende ControllerId letzte inkludierte NodeId
0x1fc9                    = 1 Byte = SucNodeId = 0x56 Antwort komplett

Bei den Offsets 0x1fc8 und 0x1fc9 bin ich mir unsicher, aber die sind vermutlich nur in  Spezialfällen relevant.

edit:
0x1fc8 Bedeutung korrigiert
0x268c Bedeutung korrigiert

krikan

Weitere Erkenntnisse zum Datei/EEP-Layout der Gen5 Vision/UZB1-Sticks:

0x2568 - 0x264f = 1 Byte pro Node bei 232 Nodes = 0xff = Controller , 0xfe = belegt oder leer, 0x00 removeFailedNode erfolgreich
0x268b               = 1 Byte = ctrlCaps = 0x05 Antwort komplett
0x268d - 0x2800 (?) = evtl. Routing Infos?

krikan

Zitat von: krikan am 17 Juli 2016, 17:52:28
0x268d - 0x2800 (?) = evtl. Routing Infos?
Das ist falsch.

"Richtig"
0x268e - 0x2b15 =  5 Bytes pro Node bei 232 Nodes = Bedeutung unklar: ändert sich unter anderem bei addNode, removeNode, removeFailedNode

krikan

Zitat von: krikan am 18 Juli 2016, 06:54:56
0x268e - 0x2b15 =  5 Bytes pro Node bei 232 Nodes = Bedeutung unklar: ändert sich unter anderem bei addNode, removeNode, removeFailedNode
Ändert sich teilweise auch bei neigbhorUpdate -> also Routeninfos?

umtauscher

#40
Ich weiß schon sehr alt, aber vielleicht hat jemand neue Erkenntnisse....

Hat jemand herausgefunden, wo die Information SUC/SIS/Primary steht?

Hintergrund meiner Anfrage ist ein Netzwerk, dass durch einen Fehler jetzt keinen primary Controller mehr hat.
Ich habe aber einen Aeotec Gen5 Stick, der das komplette Netzwerk kennt. Dummerweise steht der auf Secondary/Other Network und hat NodeID 134 bzw. 0x86.  Ich möchte das Backup so umpatchen, dass er jetzt zum Primary wird. Der alte Primary ist leider platt.
Wäre echt super, wenn Ihr noch etwas mehr wüsstet.

Wilhelm

krikan

Hallo Wilhelm!

Habe leider keine Antwort auf Deine Frage.

Aber eventuell ist ja Dein Secondary SUC, dann könntest Du mit "createNewPrimary" einen neuen Primary erzeugen.

Gruß, Christian

umtauscher

Hallo Christian,

ich habe diese Funktion auf meinem Secondary aktiviert, indem ich (wie oben beschrieben) das Byte 0x1fc9 auf die eigene Node (0x86) gesetzt habe. Seitdem zeigt das Zensys z-wave Tool meinen Secondary als SUC an.

Ich hatte nur noch nicht den Mut die Funktion CreatNewPrimary auszuprobieren.

Was soll denn da passieren? Wird nur der Stick geändert oder werden auch Associationen in den anderen Nodes Umprogrammiert?

Ich mache ja die ganze Forschung, um nicht alle 133 Nodes neu anlernen zu müssen. Es darf also nichts schiefgehen. ;-)

Für weiter Hinweise bin ich dankbar.
Schöne Grüße

Wilhelm

krikan

Infos zum Thema createNewPrimary findest Du in https://forum.fhem.de/index.php/topic,53372.0.html .
Der Weg sollte eigentlich genau Dein Problem lösen, wenn Du einen 2. Controller zur Verfügung hast und das manuelle Setzen des SUCs beim Secondary-Controller so reicht/erfolgreich war.



umtauscher

ok, jetzt habe ich wengistens wieder einen Primary - danke.

Weißt Du zufällig, ob ich durch setzen von 0x1fc8 auf 0 erreichen kann, dass die nächste inkludierte Node die 1 wird?