I have a second (spare) ZST39 LR and I want to test disaster recovery. My goal is to prove that I can get a backup controller to work with my existing nodes.
I’ve backed up the NVM from my active ZST39 LR controller using Simplicity Studio.
I have zwave-js-ui running in docker on a spare machine (no HA involved). The plan is to:
Restore the NVM on my backup controller (using Simplicity Studio again)
Backup and restore my zwave-js-ui config & cache files onto the new docker image
Shut down zwave-js-ui on my HA instance to disable the controller.
Or do I just need to do this?
4: Plug in the new controller into my spare machine running zwave-js-ui
5: Check in the zwave-js-ui control panel that I can see all my devices.
Will that work? And is there any risk to my existing nodes as long as my HA controller is shut down (i.e. only one controller is running at a time)?
I assume that would also work with a restored version of HA because the NVM restore means my nodes retain the name NodeIDs and that is what is used to map to devices and entities in HA.
Another thing I’m curious about: why are the cache files prefixed with the HomeID but other controller-specific data (config, nodes.json) specific to a given homeID not prefixed? (The HomeID is in the NVM, right?)
I have SDK: v7.18.1 on my primary ZST39 LR controller so cannot use ZUI for that (I end up with a zero byte file).
My plan is after I verify that I can restore onto a new controller and see all the devices I’ll upgrade that old firmware. My new ZST39 LR came with v7.22.0.
Otherwise, the steps seem correct?
What about the “Shutdown Zwave API”? Does that somehow “power down” the stick, or does it just stop the websocket server? (i.e. same thing as disabling the integration). I don’t want two controllers on the same zwave network at the same time.
I’ve never used that. I would just stop the container, unplug the old stick, plug the new one back in, start the controller then reconfigure the USB path. That’s basically it. Optionally disable the Z-Wave integration until the new stick is up and running.
Periodically I do a similar exercise. Once I’ve proven the new controller is restored, I then use the new controller and put the existing controller back in the drawer as my backup.
You want to make sure only one controller is active. So only have one plugged in at a time.
Are you running a VM or HASSOS install.
if so the simplest thing to do is:
A) take a backup
B) take another backup
C) shutdown the image, turn off power
D) remove old stick
E) put in new stick
F) start it up, if it’s working great, put old stick in the drawer
G) if not restore the backup and put the old stick back in.
FYI, I confirmed there’s a bug in HA, it will delete your devices when you temporarily switch to the new controller before the backup has been restored. To prevent this either: 1) disable the Z-Wave integration before the switching the controller enable it after the restore is complete, or 2) disable the Websocket server in ZUI before switching the controller and enable it after.
Well, I bricked my new ZST39 LR. The little blue LED no longer comes on.
BTW, I’m doing all of this outside of Home Assistant (for now). My goal was just to see if I could restore the NVM onto a new stick and see the nodes on a separate docker instance of ZUI with matching config.
Probably a mistake, but Zooz support suggests using PC Controller, so I did the NVM restore using PC Controller. There’s an option to restore the zip file (which includes a few XML files, or just the .hex file. I picked just the .hex.
PC Controller reported the restore worked, but then could no longer connect to it.
I tried ZUI in bootloader mode (although unclear of sequence of doing that). I also tried the command line approach:
Zwavejsui performs translation on the NVM backup so it can be restored on a stick with a different firmware version. Simplicity studio does not do this it’s just write the NVM content. In your case since the two sticks have different firmware, it’s not surprising it got bricked.
And it seems bricked hard. Not sure when the blue LED should be on, but it’s not.
The USB stick is detected:
Jan 22 07:18:19 macha kernel: [408169.718761] usb 1-2: new full-speed USB device number 14 using xhci_hcd
Jan 22 07:18:19 macha kernel: [408169.873986] usb 1-2: New USB device found, idVendor=1a86, idProduct=55d4, bcdDevice= 4.43
Jan 22 07:18:19 macha kernel: [408169.873990] usb 1-2: New USB device strings: Mfr=1, Product=2, SerialNumber=3
Jan 22 07:18:19 macha kernel: [408169.873992] usb 1-2: Product: 800 Z-Wave Stick
Jan 22 07:18:19 macha kernel: [408169.873993] usb 1-2: Manufacturer: Zooz
Jan 22 07:18:19 macha kernel: [408169.873994] usb 1-2: SerialNumber: 533D004242
Jan 22 07:18:19 macha kernel: [408169.875421] cdc_acm 1-2:1.0: ttyACM0: USB ACM device
Jan 22 07:18:19 macha snapd[29059]: hotplug.go:200: hotplug device add event ignored, enable experimental.hotplug
Jan 22 07:18:21 macha ModemManager[41460]: <info> [base-manager] couldn't check support for device '/sys/devices/pci0000:00/0000:00:14.0/usb1/1-2': not supported by any plugin
