I have a moderate-sized (~50 devices) z-wafe network running on a Home Assistant Green with a Zooz Z-wave dongle and Z-wave JS UI.
I’ve become pretty dependent on this and it would be quite a disaster if it died, so I’m trying to be thoughtful and build a recovery plan now for any single points of failure. I’m able to backup my Home Assistant configuration and can restore to a replacement HA-Green device but my understanding is that if my Z-wave controller dongle dies then Z-wave devices need to be manually re-included 1-by-1. This is scary for a couple of reasons:
Many of the devices are not super easy to access (e.g., wall switches/outlets whose QR codes are only visible if you remove the faceplate, or temperature sensors in crawlspaces, etc.)
Including was a pretty unreliable activity the first time around (e.g., many devices needed multiple attempts or needed to be physically moved near the controller for initial inclusion and then returned to their “real” location, etc.)
I have a number of automations that refer to Z-Wave devices and I’m worried that re-including might break the connection (especially, if I can’t perfectly match the device names by memory when I re-add, etc.)
So my question is does anyone have any advice/best practices to prepare for a potential need to replace/migrate Z-wave controller hardware?
For example:
Am I correct in my understanding that replacing the controller will mean needing to manually exclude then re-include every single Z-wave device 1-by-1, or is there any way to “migrate” a network, intact, to a new controller?
For devices that are able to include via QR code, is there some way to export/back up my list of devices/codes, then re-import them en masse and auto re-include them?
What happens to my automations that reference Z-wave devices if the controller dies and is replaced with a new controller?
How would I go about “telling” Z-Wave JS UI that I have a new controller dongle?
etc.
The 3 most important pieces of your Z-Wave network are the NVM of the controller, your security keys, and the jsonl files generated by Z-Wave JS UI.
Only devices with the same home id can communicate with each other. Because the home id of your controller is randomly generated if your controller were to die you wouldn’t be able to communicate with existing devices and would have to repair them.
Devices that use security use the security keys to encrypt and decrypt messages. A device only gets a copy of these keys during inclusion. So if you change the keys you won’t be able to control the device unless you exclude it and reinclude it.
I haven’t looked much into this but I believe the jsonl files generated are somehow used for your devices. I noticed that when I deleted these files my custom entity names were also deleted which messed with my automations.
To prepare for failure all you need to do is backup your controllers NVM and the store files. The store contains your security keys as well as your jsonl files. You can schedule both of these by configuring the Z-Wave JS UI settings.
As someone with only 9 Zwave devices, my network died twice this week. Both due to a SDR that I introduced that crashed my Zigbee and Zwave and I had to buy new Zwave stick and then when happened again had to factory reset that. Once my devices were all factory reset, any automation that had them in it broke the automation/disabled it.
I’ll definitely be looking into what the guy above said. But one thing I did do after the first crash is write down all the pins to each switch that I labeled in my phone. This way next time if I have to do this again, I can just factory reset and re add and I have the pin already.
@cornellrwilliams Thanks for your reply about these important components to back up. Can you please help me understand (A) how to back these up (i.e., where in Z-Wave JS UI are the options to save/export these) and (B) how to restore these from the backups onto new hardware (i.e., where in Z-Wave JS UI are the options to replace current NVM, security keys, and jsonl with the contents of a backup file)?
Use entity states in your automation wherever necessary then when you do what Cornell says above and your devices get named the same way they were your automations keep trucking because they’re tied to entity_id NOT a ephemeral guid that changes every time you re-add a device.
(read:your answer for 3 - HA controls that every time a new device is added new ID. No matter if it’s the same device I joined and rejoined immediately)
Yes the advanced users know the UI goes device first to try to make it ‘easier’ Use entities.
Does not apply if you have to listen for a specific ZWave event however. That has to be donee the way it’s done.
Cornell I find as lo g as I get the custom name back it’s fine. What happens to JsUI if it’s connected without it, then restored. Then reconnects with a new NVM, unlocked with the correct keys Suddenly sees the network and has the JSON available?
Basically should we do something to prevent it from registering with HA before the user restoress the files to keep it from messing things up (this is the part of the chain where I’m most unclear what’s going on)
You go to settings > backup > then enable the store backup and the NVM backup.
To restore a store backup go to the store page > click the green restore button then select your stor zip.
To restore a NVM backup go to the control panel page > click the blue menu button > click the purple advanced actions button > under NVM MANAGEMENT click restore.
One other thing I forgot to mention is that you should go to settings > devices & services > click on the z-wave logo > click ⋮ > then disable your integration. This solves the problem of the entity names changing.
@cornellrwilliams You mentioned that the Home ID is critical for devices being able to communicate. I can see my home ID in Z-wave JS UI and have written it down. Is it possible to manually set this on the replacement controller to match the old one?
I guess I’m more-generally wondering/hoping if there is any way to back up the NVM, note down the security keys, copy nodes.json (or other Z-wave JS UI backup files?)… and then manually reset these values to match on a new virgin installation … with the hope that all of my devices would just start communicating with the new controller, without having to exclude/re-include… Is that possible?
If you are on fw 1.2 you can also use the zwavejs NVM backup to restore to another 1.2 stick. I find that to be easier since I can backup before and after including new nodes without having to shutdown and move the stick.