Zwave Dongle wechseln

[krikan]

controllerChange und backupCreate werden bei mir scheinbar nicht unterstützt

backupCreate funktioniert -soweit bisher bekannt- nur bei Zwave+-Controllern
controllerChange wundert mich. Könntest du bitte einmal die Ausgabe von "list <ZWDongle>" posten.

[McUles]

Habe es jetzt mal über den z-way-server versucht. Da kann man das Backup sowie den Restore direkt machen.
Hat problemlos funktioniert.

1. FHEM beendet und z-way-server gestartet
2. Backup des Controllers erstellt
3. RasPi heruntergefahren, die Module getauscht und wieder hochgefahren
4. z-way-server gestartet
5. Backup restored
7. z-way-server beendet und FHEM gestartet

Alle zWave Geräte haben sofort funktioniert.

[krikan]

Glückwunsch  .
Jetzt wäre interessant zu wissen, ob das zwave.me-Spezial ist, was ich vermute (z-way-server.log)...

[McUles]

Ich habe dir das Log mal in die Dropbox gelegt und dir den Link per PN geschickt.
Kannst ja mal schauen ob du etwas brauchbares darin findest

[krikan]

Danke.

Beim schnellen Durchsehen:
Wie die Daten aus dem alten Razberry ausgelesen werden, kann ich nicht erkennen.
Es sieht so aus, als würden beim Restore alle notwendigen Daten aus einer XML, die auch bei jedem Start von zway geladen und beim Stop geschrieben wird, rekonstruiert.
Vor dem Restore wird ein factoryReset (SET_DEFAULT) abgesetzt
Anschließend wird zum Restore auf den ZWave+-Controller die Funktion NVM_EXT_WRITE_LONG_BUFFER, die auch wir in FHEM nutzen, verwendet.
Interessanterweise gibt es nur 42x den Aufruf der Funktion, wovon nur selten (4-5x) durch die Funktion überhaupt von 0x00 abweichende Daten geschrieben werden.
Neben dem Controller habe ich 11 Nodes gezählt. (Korrekt?)

Hoffnung: Ein Restore auf Zwave+-Controllern ist vielleicht doch viel einfacher als (von mir) gedacht.
Befürchtung: Controllerabhängigkeit
Werde mal experimentieren...

[McUles]

Das mit den 11 Nodes haut gut hin
Muss noch mal schauen ob das Auslesen vielleicht vor 19 Uhr stattgefunden hat.

[krikan]

Infos vom Auslesen brauche ich wohl nicht mehr. Dank der Inspiration habe ich unser backupCreate-File analysiert https://forum.fhem.de/index.php/topic,52914.msg472478.html#msg472478 und dann aus jetziger Sicht erfolgreich den Umzug eines nicht FHEM-backupfähigen Altcontrollers meines Produktivsystems auf einen ZWave+ Controller vollzogen.

Warnung: Nur nachmachen, wenn man Elektroschrott und Funktionsstörungen verkraften kann  .

Controllerumzug:

Verwendete Hardware:
Altcontroller: Vision ZU1401EU (4er Chipsatz, keine Backupfunktionen = NVM_EXT_*) -> Primary, ControllerNodeId 1
Zielcontroller: Vision ZU1401EU-5  (5er-Chipsatz, Zwave+)

Für den Umzug sind folgende Datenbereiche als Offset in der backupCreate-Datei des Zielcontrollers anzupassen/zu überschreiben:
0x08                 = 4 Bytes = homeId
0xfd  - 0x57f     = 5 Bytes pro Node bei 231 Nodes = nodeInfo (ersten Node=Controller ausgelassen)
0x580 - 0x1fc7  = 29 Bytes pro Node = neighborList
0x268c              = 1 Byte = letzte inkludierte NodeId

Vorgehen:
Zielcontroller: "set <ZWDongle> factoryReset"
FHEM neu starten ("shutdown restart")
Zielcontroller: "set <ZWDongle> backupCreate"
Altcontroller:
Für das Auslesen der notwendigen Daten des Altcontrollers habe ich in 00_ZWDongle.pm in der Sud ZWDongle_Set den Aufruf der backupCreate-Funktion von der nicht unterstützten Funktion NVM_EXT_READ_LONG_BUFFER auf die unterstützte Funktion MEMORY_GET_BUFFER umgebaut. Diese Änderung ist nur für das Auslesen der Daten des Altcontrollers gedacht und damit anschließend wieder rückgängig zumachen.

Code Auswählen Erweitern

  if($type eq "backupCreate") {
    return "Creating a backup is not supported by this device"
      if(ReadingsVal($name, "caps","") !~ m/MEMORY_GET_BUFFER/);
    return "Usage: set $name backupCreate [64k|128k|256k]"
      if(int(@a) != 1 || $a[0] !~ m/^(64|128|256)k$/);
    my $l = $1 * 1024;
    my $fName = "$attr{global}{modpath}/$name.bin";
    open(OUT, ">$fName") || return "Cant open $fName: $!";
    binmode(OUT);
    for(my $off = 0; $off < $l;) {
      ZWDongle_Write($hash, "", sprintf("0023%04x40", $off));
      my ($err, $ret) =
        ZWDongle_ReadAnswer($hash, "MEMORY_GET_BUFFER", "^0123");
Nach der Änderung von 00_ZWDongle.pm FHEM mit Altcontroller neu starten ("shutdown restart") und "set <ZWDongle> backupCreate 64k" absetzen.
Bei meinen Controller brach das Backup nach Erstellung einer 32k Backup-Datei ab, was aber kein Problem ist. Vorhandene Datei reicht aus.

Kopieren der Daten aus der Backupdatei Altcontroller in Backupdatei Zielcontroller mit Hexeditor:
Die Backupdatei des Altcontrollers enthält jeweils um einen Offset von 0x1400 verschoben, alle Daten die entsprechend der obigen Angaben in der Backupdatei des Zielcontrollers vorhanden sind.
Aus der Backupdatei des Altcontroller habe ich mit einem Hexeditor die oben genannten Daten(bereiche) in die Backupdatei des Zielcontrollers kopiert. Da die Backupdatei des Zielcontrollers (128k) die aufgeführten Daten auch noch einmal um einen Offset um 0x10000 verschoben enthält, habe ich auch dorthin die Daten noch einmal kopiert. Nur in die ersten 64k zu kopieren hat nicht gereicht.

Zielcontroller: Die geänderte Backupdatei mit "set <ZWDongle> backupRestore" im Zielcontroller speichern.
FHEM mit Zielcontroller neu starten ("shutdown restart").

Das war es. Bisher läuft das seit ein paar Stunden problemlos im Produktivsystem. Aber es bleibt ein deutliches Risiko von Funktionsstörungen und Elektroschrott.

Btw: Jetzt stellt sich mir die Frage, ob man bei Altcontrollern, die die *MEMORY*-Funktionen nutzen, auch -entgegen allen mir bekannten Aussagen- Backup und Restores machen kann. Das werde ich aber nicht weiterverfolgen.

[rudolfkoenig]

Danke fuer die Recherche & Experimente.

Ich habe in backupCreate & backupRestore die MEMORY Funktionen eingebaut (sie werden verwendet, falls keine NVM Funktionen zur Verfuegung stehen), allerdings nur backupCreate mit meinem Goodway getestet.  In der Doku fuer backupRestore habe ich erwaehnt, dass fuer alte Geraete nicht getestet wurde.

Was ich bei meinem Goodway gesehen habe:
- hat nur 16k sinnvolle Daten (wenn man 32k ausliest, dann hat man alles doppelt)
- es kann hoechstens 60 Bytes zurueckliefern, deswegen habe ich fuer die MEMORY Funktionen die Puffergroesse auf 32Bytes reduziert.
- homeId steht am Offset 0x1908
- nodeInfo steht ab 0x19f8, jeweils 5 Byte
- neighborList ab 0x1e80 (== 0x19f8 + 5*232).
- last nodeId: 0x38c8 (== 0x1e80 + 29*232).
- sonst stehen noch ca 20 Bytes an sonstigen Nutzinformationen drin, d.h. nicht 0x00 oder 0xff

Mein Fazit: ein automatischer Umzug ist derzeit nicht drin, mit etwas Nachdenken und Basteln aber durchaus moeglich.

[krikan]

Hast Du in der Backupdatei die Zeichenkette ZENSYS?
In allen meinen Backupdateien ist der Abstand von der Zeichkette zu den von mir verwendeten Nutzdaten gleich. Vielleicht kann man das als Orientierungspunkt nutzen.
Habe auch noch einige nicht übertragene Nutzdaten analysiert. Dort finden sich Angaben zu den Controllercaps, SUC usw. die man entweder am neuen Controller nachträglich setzen kann oder sie sind controllerspezifisch und müssen nicht übertragen werden. So zumindest mein derzeitiger Stand.

[McUles]

Au weia, da hab ich ja was angeleiert 😂

[rudolfkoenig]

Hast Du in der Backupdatei die Zeichenkette ZENSYS?

Nein, nicht mal 2 aufeinanderfolgende ASCII Zeichen.

Au weia, da hab ich ja was angeleiert 😂

Keine Sorge, niemand zwingt uns.
Und ich wette, Christian wollte schon seit langen einen ZWave+ Controller in seiner Produktionsumgebung.

[krikan]

- last nodeId: 0x38c8 (== 0x1e80 + 29*232).

Bei 0x1fc8 hatte ich bisher 0x00 übernommen. Dadurch werden die freien NodeIds wieder von vorne beginnend vergeben. Wenn ich das auf den Wert des alten Controllers aus der entsprechenden Speicheradresse setze, geht es nicht mehr von vorne los. Ich habe das jetzt mit dem alten Controllerwert überschrieben, da ich nicht geprüft habe, ob 0c1fc8 mit 0x00 in Folge zu Problemen führt (müsste erst 7 leere NodeIds per Inklusion füllen, bevor die nächste vergebene kommt)
Wenn ich 0x268c auf 0x00 setze, statt auf letzte NodeId, reagiert der Controller merkwürdig.
Darum 0x1fc8 und 0x268c am besten mit dem passenden Wert aus Altcontrollerbackup übernehmen.

Nein, nicht mal 2 aufeinanderfolgende ASCII Zeichen.

Schade, Offsets bei meinen Controllern (UZB, Vision+, Vision), die ich bisher angegeben habe, passen immer ausgehend vom Z in ZENSYS. Jedoch passen die grundlegenden Abstände bei Dir mMn auch. Also sieht es (vorsichtig) nach Chip/SDK-übergreifendem System aus.

Und ich wette, Christian wollte schon seit langen einen ZWave+ Controller in seiner Produktionsumgebung.

Ja, darum experimentiere ich schon länger mit den Controllerfunktionen.  Nur alle bisher bekannten "offiziellen" Wege vergaben eine neue ControllerNodeId...

[krikan]

Bei 0x1fc8 hatte ich bisher 0x00 übernommen. Dadurch werden die freien NodeIds wieder von vorne beginnend vergeben. Wenn ich das auf den Wert des alten Controllers aus der entsprechenden Speicheradresse setze, geht es nicht mehr von vorne los. Ich habe das jetzt mit dem alten Controllerwert überschrieben, da ich nicht geprüft habe, ob 0c1fc8 mit 0x00 in Folge zu Problemen führt (müsste erst 7 leere NodeIds per Inklusion füllen, bevor die nächste vergebene kommt)

Konnte es nicht lassen:
Habe wieder 0x1fc8 mit 0x00 beschrieben (backupRestore der ursprünglichen, geändeten Datei aus Antwort #21) und 20x einen Sensor in- und exkludiert. Alle Lücken in den NodeId-Nummern werden sauber gefüllt und noch vergebene NodeIds übersprungen. Darum dürfte mein erster Ansatz ok sein. (Testgerät: Vision ZU1401EU-5)

Da mich wundert, das sich in den backupCreate-Dateien die 64k-Blöcke wiederholen und deshalb die Änderungen in der Datei mehrfach gemacht werden müssen, habe ich mit dem UZB1 einen anderen Ansatz probiert: Nur die oben genannten Offset-Adressen habe ich nach factoryReset des Controllers direkt mit NVM_EXT_WRITE_LONG_BUFFER beschrieben. Umgezogene Controllerdaten werden erkannt und Funktion ist gegeben.

[krikan]

Von meiner Seite ist das Thema Controllerumzug von alten Controllergenerationen auf aktuelle ZWave+-Controller über den oben beschriebenen "inoffiziellen" Weg abgeschlossen.
Ich kann bisher keine Funktionsstörungen erkennen (aber auch nicht ausschließen  ) und es läuft produktiv. Sollten noch Probleme auftreten, werde ich natürlich berichten.
Offizielles Vorgehen für einen Umzug bleibt laut API "controllerChange" (auch Controllershift genannt), was mit FHEM durchführbar ist.

Einen Einbau für einen (teil)automatsichen Ablauf des Vorgehens in FHEM halte ich zwar grds. für möglich und wäre ein gewisses Alleinstellungsmerkmal; jedoch ist mir der Aufwand im Verhältnis zu den vermutlich wenigen Nutzern einer solchen Funktion und den potentiellen Funktionsproblemen momentan zu groß. Der Weg über die Bearbeitung des backupCreate-Image ist ja relativ simpel.

[moritz3155]

Hallo,
sorry dass ich den Thread hier nochmal ausgrabe...

Ich möchte demnächst von einem alten ZWave-Controller (ohne plus) auf den Aeotec AEOEZW090-C Stick wechseln. Wenn ich das alles richtig verstanden habe, muss man folgende Schritte durchführen (unter Berücksichtigung der Informationen in diesem Thread: https://forum.fhem.de/index.php?topic=57228.0):

1. mit FHEM den controllerChange durchführen, sodass der neue Controller der Primary wird (kleine Frage hier: sollte man zwei getrennte FHEM Installationen für die beiden ZWDongles verwenden oder geht das auch mit nur einer FHEM-Instanz?)
2. alle Assoziationen an die nodeID des neuen Controllers anpassen

Da ihr ja bereits erfolgreich an den Backup-Images der Controller gebastelt habt: Könnte man nach dem ControllerChange nicht auch ein Backup des neuen Sticks erstellen und in diesem die nodeID des Controllers ändern und dann wieder einspielen? Dann könnte man sich evtl. die Anpassung der Associations sparen.

Gruß,
Moritz