Zwave Dongle wechseln

[FlorianZ]

Hallo zusammen.

Mein Z Wave Netzwerk ist in den letzten 1,5 Jahren mit 45 Nodes ziemlich groß geworden.
Als Controller läuft bei mir noch der alte Aeon Labs Z-Stick S2.
Jetzt würde ich gerne den Controller gegen einen ZMEUZB1 tauschen ohne alles exkludieren/inkludieren zu müssen.

Bisherige Tests von mir (nicht im Produktivsystem):
Mit Hilfe von Z-Tool/HS3 konnte ich den ZMEUZB1 als Secondary Controller ins vorhandene Netz inkludieren und
anschließend die Rolle des Primary zuweisen.
Unschön dabei ist, dass der neue Primary nicht die NodeID 1 bekommt.
Mir ist auch unklar, ob auf diese weise die ZwavePlus Features des neuen Dongles in einen vorhandenen Netzwerk
aktiv werden.

Gibt es noch andere Möglichkeiten für einen Wechsel oder Erfahrungen diesbezüglich?

vg
Florian

[krikan]

Hallo Florian!

Controllerwechsel habe ich gerade im Rahmen des Controller-Backups (set <ZWDongle> createBackup)  unter anderem auch mit dem AEOTEC-Support diskutiert.

Beim Wechsel von ohne Plus auf Plus-Dongle bleibt Dir nur der Weg Controllershift, den Du anhand Deiner Angaben bereits probiert hast. Dabei bekommt der neue Controller zwangsweise immer eine von 1 abweichende NodeId. Das kann man nicht verhindern. Anleitung von AEOTEC für Controllershift AEOTEC S2 zu AEOTEC Gen5, die auch auf einen Umstieg auf den UZB1 anwendbar ist, habe ich. Genutzt wird dazu Zensys ZWave-Controller. Vermutlich entspricht das aber Z-Tool/HS3.

Nur bei Wechsel zwischen verschiedenen ZWavePlus-Controllern sollte unter Umständen der Weg über Backup/Restore unter  Beibehaltung der Controller-Node-ID 1 möglich sein. Sicherer ist aber wohl selbst dann Controller-Shift.

Die ZWavePlus-Features http://z-wavealliance.org/z-wave_plus_certification/ stecken im Chipsatz des Controllers und sind automatisch aktiv.  Volle Vorteilsnutzung aber nur mit ZWavePlus-Endgeräten.

Aber: Das sind bisher alles von mir zusammengesuchte/erfragte Infos ohne eigene praktische Erfahrungen. Die kann ich Dir aber in Kürze liefern, da der Controllerwechsel bei mir auch ansteht.

Gruß, Christian

[FlorianZ]

Hallo Christian

Erstmal vielen Dank für deine ausführlichen Infos.
Ja Backup ist auch für mich ein Grund für den Wechsel.
Mir ist aufgefallen, dass mit Homeseer die Möglichkeit besteht,
vom Aeon S2 Stick ein Backup zu machen.
Es ist aber nicht möglich, das Backup wieder auf den S2 zu kopieren.
Vieleicht könnte man ja mal mit Fhem versuchen die Daten auszulesen?

vg
Florian

[krikan]

Mir ist aufgefallen, dass mit Homeseer die Möglichkeit besteht,
vom Aeon S2 Stick ein Backup zu machen.

Habe gestern abend versucht die Trial von Homeseer in Betrieb zu nehmen. Nach einer halben Stunde vergeblichen Versuchen habe ich aufgeben. ZWave-Sticks wurden nicht erkannt.
Bin mir nicht sicher, was Homeseer unter Backup versteht. Wohin kann das überhaupt zurückgesichert werden? Gibt es Logs, wenn Du das Backup in Homeseer ausführst?

Vieleicht könnte man ja mal mit Fhem versuchen die Daten auszulesen?

Bei den "alten" Sticks habe ich nie Infos zu einer Backup-Möglichkeit gefunden. Nur Berichte über vergebliche Versuche.
AEOTEC selbst führt als einzigen Weg S2 zu Gen5 nur den Controller-Shift an und die sollten es eigentlich wissen. Würde mich aber freuen, wenn es einen anderen Weg gibt.

[FlorianZ]

Im Anhang ist das Backup, dass HS3 vom Aeotec S2 anlegt.
Die HomeID vom S2 ist 0184DDF9 und es ist ein Fibaro Plug
inkludiert mit NodeID 2.
Ein ausführliches Log über den Backupvorgang konnte ich leider
nicht finden.
Viel entält die Datei nicht.
Kann man damit was anfangen?

Gruß
Florian

[rudolfkoenig]

Bericht ueber ein Experiment.

Ich habe einen Goodway Stick (homeId gggggggg, unterstuetzt kein Backup), und einen ZME_UZB1 (homeId zzzzzzzz, unterstuetzt Backup).
1. Hin:
- Goodway abgesteckt.
- ZME mit einem "leeren" FHEM Instanz verbunden.
- get zme raw 2b0000080004gggggggg
- zme absgesteckt, und neu drangesteckt, FHEM neu gestartet.
- ein paar Geraetedefinitionen aus der Goodway-Fhem-Konfiguration uebernommen, insb. define und attr classes.
- ich konnte mit der ZME alle schalten bzw. empfangen: AN158, ZWave.me Remote und Homeseer HSM100. Ich habe "get version" und "get versionClassAll" ohne Probleme ausgefuehrt.

2. Zurueck:
- get zme raw 2b0000080004zzzzzzzz
- FHEM mit der "original" zme Konfiguration gestartet.
- ich konnte ein per Security frueher verbundenes AS6 _nicht_ schalten.
- zme abgesteckt, neu drangesteckt.
- jetzt funktioniert das Schalten, und get as6 version

Natuerlich sind die in der ZME gespeicherten NodeIds fuer das Goodway Netzwerk falsch, und damit auch die Routes. Wie man das korrigiert, weiss ich nicht.

[FlorianZ]

Wenn es möglich ist, die HomeID erfolgreich im Dongle zu überschreiben,
vielleicht besteht ja dann auch die Möglichkeit, die NodeID des Dongles zu ändern!?
Die HomeID, Routes und die gespeicherten NodeId´s könnte man ja über Controller-Shift
im Dongle zuerst hinterlegen.
Somit hätte man einen 1:1 Ersatz

[rudolfkoenig]

Ich behaupte ja, du musst "nur" die richtige Stelle im Speicher finden.

Ich habe die Backups vor und nach hinzuefuegen eines neuen Geraetes verglichen, und folgendes gefunden:

x00f8: Jeweils 5 Byte nodeInfo fuer die bekannten IDs, sonst 0
x0580: Neighbor-Info (== Routing): 29Byte/id
x1fc8: Last used NodeID
x268c: Last used NodeID
x26e2: 6 Byte-Change(?)
x270f: 1 Byte-Change(?)
x280e: 1 Byte-Change(?)

Gilt nur fuer den zme Stick, evtl. verwenden aber andere Hersteller die gleiche ZWave Bibliothek.

[krikan]

Die Backup-Datei von Homeseer ist für mich nichtssagend. Ohne vernünftige Logs wird eine Analyse vermutlich schwierig. Interessant wäre aber insbesondere, wofür das Backup durch Homeseer genutzt werden kann. Kann damit wirklich auf einen anderen ZWavePlus-Stick umgezogen werden?

Natürlich könnte man versuchen die Backup-Dateien der ZWavePlus-Sticks zu analysieren und die Daten der ohnePlus-Sticks auszulesen und entsprechend für ein Restore zu schreiben. Das ist sicherlich sehr interessant und Rudi hat es für die HomeId ja bereits entsprechend getestet. Das sollte man weiter verfolgen.

Aber für den Umzug meines Produktivsystem-Sticks will ich eine sichere Lösung und das bedeutet erprobte und halbwegs offizielle Verfahren nutzen. Ich kann mir persönlich im Produktivsystem aus WAF-Gründen keine Ausfälle leisten  . Genau die mir bekannten Varianten hatte ich oben beschrieben.

Wenn es möglich ist, die HomeID erfolgreich im Dongle zu überschreiben,
vielleicht besteht ja dann auch die Möglichkeit, die NodeID des Dongles zu ändern!?
Die HomeID, Routes und die gespeicherten NodeId´s könnte man ja über Controller-Shift
im Dongle zuerst hinterlegen.
Somit hätte man einen 1:1 Ersatz

Sicherlich möglich, aber mir auch im Produktivsystem noch zu heikel.

[FlorianZ]

Also zusammenfassend folgende Theorie/Ablauf:

1. Neuen Dongle mit Zensys oder Z-Tool in vorhandenes Zwave Netz als Secondary Controller inkludieren  ( funktioniert )
2. Mit Zensys oder Z-Tool Secondary zum Primary Controller umwandeln (  funktioniert )
3. Neuen Primary an Fhem Server anstecken ( funktioniert )
4. Backup des neuen Primary Controllers ( sollte funktionieren )
5. Im Backup die NodeID des Controllers ändern ( todo..)
6. Backup Restore auf Controller ( ? )

Könnte das evtl. ein Weg sein den man weiter verfolgen sollte ?

[krikan]

Könnte das evtl. ein Weg sein den man weiter verfolgen sollte ?

Ja.  Probieren und berichten.

[McUles]

Stehe gerade vor dem selben Problem.
Hat das inzwischen mal jemand auf diesen Weg getestet?

Habe momentan ein RaZberry der ersten Version und möchte diesen mit einem Plus ersetzen.

Also zusammenfassend folgende Theorie/Ablauf:

1. Neuen Dongle mit Zensys oder Z-Tool in vorhandenes Zwave Netz als Secondary Controller inkludieren  ( funktioniert )
2. Mit Zensys oder Z-Tool Secondary zum Primary Controller umwandeln (  funktioniert )
3. Neuen Primary an Fhem Server anstecken ( funktioniert )
4. Backup des neuen Primary Controllers ( sollte funktionieren )
5. Im Backup die NodeID des Controllers ändern ( todo..)
6. Backup Restore auf Controller ( ? )

Könnte das evtl. ein Weg sein den man weiter verfolgen sollte ?

[krikan]

1.-4. geht mittlerweile alles mit FHEM:

1.-3. siehe Befehl "controllerChange"
4. siehe Befehl "backupCreate"

5.+6. hat Rudi meine ich mal probiert. Erfolg ? Ist aber abseits jeder offiziellen Spec.

[rudolfkoenig]

5 und 6 habe ich getestet, allerdings habe ich das Backup vom gleichen Geraet zurueckgespielt.
Backup von alten Modell auf neuen Modell restaurieren wuerde mich aber auch interessieren: ich raeume eine Erfolgchance von 50% ein

[McUles]

controllerChange und backupCreate werden bei mir scheinbar nicht unterstützt

"controllerChange is unsupported by this controller"

[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

[rudolfkoenig]

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?

Dazu braucht man kein backup, die homeId kann man auch direkt im EEPROM aendern (ihabs irgendwo schon beschrieben), allerdings hat dann der Controller nicht die Liste der bekannten nodeIds. Das fuehrt zwar nicht sofort zu einem Problem (schalten klappt im Normalfall), aber spaeter (doppelt vergebene ID bei Neu-Inklusion, Routing-Probleme, usw).

[krikan]

kleine Frage hier: sollte man zwei getrennte FHEM Installationen für die beiden ZWDongles verwenden oder geht das auch mit nur einer FHEM-Instanz?

Habe das nur mit 2 Instanzen getestet.

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?

Habe ich nie probiert, aber der oben unter #21 beschriebene Weg war bei mir erfolgreich. Der Controller ist seitdem ohne Auffälligkeiten im Produktiveinsatz.

[Cyber1000]

Hallo, irgendwie blick ich da noch nicht durch:

• will von einem razberry auf einen zwave.me Stick umsteigen, beides GEN5
• Auf Seite 1 dieses Threads steht etwas von controllerChange und backupCreate, bin mir jetzt nur unsicher was ich bei welchem Controller mache

Also ich hab jetzt beide Controller in Fhem, mach dann ein controllerChange am neuen Controller, ein backupcreate am alten Controller und ein backuprestore am neuen (oder kann ich immer nur auf einem Gerät backupen und restoren)? Kann das so funktionieren? Aber wozu ist dann hier auch beschrieben, dass man händisch den Node auf 1 ändern muss? Oder gilt das nur von Zwave auf Zwave+? Muss ich dann nicht noch den neuen Dongle umbenennen auf den Namen den ich vorher für den alten Dongle hatte? Sonst passt doch die fhem.cfg nicht mehr ...
Muss ich im Anschluss den alten Controller noch irgendwie resetten, wenn ich den weitergeben will?

Wie gesagt bin noch ein wenig verwirrt und will nicht gleich was zerschießen ...

[krikan]

razberry => backupCreate
UZB1 => backupRestore
sollte für einen Umzug zwischen Gen5 genügen.

razberry würde ich nach Test, ob der Umzug erfolgreich war, mit factoryReset zurücksetzen.

[Cyber1000]

Danke für die schnelle Hilfe, hat aber leider nicht funktioniert, folgende Schritte:

• razberry = ZWAVE_DONGLE
• USB1 = ZWAVE_DONGLE_NEW
• set ZWAVE_DONGLE backupCreate 256k
• rpi - shutdown
• razberry (ZWAVE_DONGLE) physisch entfernt und neustart
• ZWAVE_DONGLE in fhem gelöscht
• rename ZWAVE_DONGLE_NEW ZWAVE_DONGLE
• set ZWAVE_DONGLE backupRestore

Das war alles erfolgreich (zumindest ohne Fehlermeldung), aber ich kann danach trotzdem nicht schalten/Energiewerte auslesen.
Hab ich etwas vergessen?

[krikan]

Nach backupRestore Dongle stromlos machen (abziehen und neu anstecken)
FHEM neu starten (shutdown restart)

[Cyber1000]

Dachte ich hätte sogar den rpi neu gestartet, war offensichtlich schon zu spät gestern 
Hab ich gemacht, dann konnte ich auf einmal schalten.
Hatte jetzt noch ein Problem, dass ich zwar schalten konnte, aber Energiereadings gingen nicht, da ist mir noch aufgefallen, dass in der fhem.cfg beim (neuen) USB-Dongle noch die ursprüngliche Id stand:
attr DONGLE_ZWAVE homeId [Id]

Die hab ich jetzt auf die Id des vorherigen Gerätes (razberry) geändert, jetzt gehn auch wieder die Energiereadings, sieht gut aus.

Das heißt, dass die homeId auch im Backup war und somit überschrieben würde, oder?

[krikan]

Code Auswählen Erweitern

attr DONGLE_ZWAVE homeId [Id]
Dieses Attribut sollte nur gesetzt werden, wenn es Probleme mit der automatischen Ermittlung der homeId durch FHEM gibt. Diese Probleme sind die Ausnahme. Ansonsten ist das unnötig.

Das heißt, dass die homeId auch im Backup war und somit überschrieben würde, oder?

Ja. (siehe auch https://wiki.fhem.de/wiki/Z-Wave#Wie_f.C3.BChrt_man_eine_Komplett-Sicherung_der_ZWave-Installation_durch.3F)

[Cyber1000]

Ok ja wie gesagt funktioniert bei mir alles soweit ich das jetzt überprüft habe.
Und das hier:

Code Auswählen Erweitern

attr DONGLE_ZWAVE homeId [Id]
habe ich nicht selbst abgesetzt, sondern wurde mir in die fhem.cfg geschrieben als ich den USB-Dongle das erste mal angesteckt hatte und war nach dem backupRestore dann natürlich falsch (und hat bei mir zu Funktionsstörungen geführt)

[krikan]

Und das hier:

Code Auswählen Erweitern

attr DONGLE_ZWAVE homeId [Id]
habe ich nicht selbst abgesetzt, sondern wurde mir in die fhem.cfg geschrieben als ich den USB-Dongle das erste mal angesteckt hatte und war nach dem backupRestore dann natürlich falsch (und hat bei mir zu Funktionsstörungen geführt)

Ja, hast Recht. Sorry.
Das Attribut wird automatisch von FHEM gesetzt und soweit ich sehe nur automatisch auf eine geanderte homeId gesetzt, wenn man "modify <ZWDongle>" oder "reopen" aufruft bzw es löscht. Ein einfaches "shutdown restart" ohne die vorherigen Befehle aendert die homeId nicht.
Warum das Attribut überhaupt immer automatisch gesetzt wird, ist mir gerade auch nicht klar.

[rudolfkoenig]

Warum das Attribut überhaupt immer automatisch gesetzt wird, ist mir gerade auch nicht klar.

Wenn ich mich recht erinnere: Wir hatten das Problem, dass bei manchen Benutzern die Initialisierung der ZWDongle nicht vollstaendig durchgelaufen ist, und deswegen homeId unbekannt war. Wenn danach Funknachrichten eingetroffen sind, konnten sie nicht dem richtigen ZWDongle zugeordnet werden. Das habe ich "einfach" geloest, indem ich das homeId Attribut setze, falls es bekannt ist.

[krikan]

Habe den Thread https://forum.fhem.de/index.php/topic,35126.0.html sogar gelesen.
Mir erschließt sich danach trotzdem nicht, warum FHEM das Attribut automatisch in allen Installationen mit dem ermittelten Wert aus der ersten Anlage "define ZWDongle" setzt. So habe ich es zumindest in meinen Tests gestern festgestellt. Normalerweise erwarte ich, dass erst nach manuellem Setzen des Attributes durch den Anwender dieses Attribut eine Rolle spielt.
Letztlich ist der derzeitige Weg auch ok, da ein Wechsel der homeId eher die Ausnahme ist und wenn

"einfach" geloest

das Argument ist, habe ich es doch verstanden.