I believe that Zigbee network + Zigbee Coordinator backups in the ZHA integration are also part of what Home Assistant founders indirectly thought about in new blog-post about “Streamlining Experiences”:
“With Home Assistant the last few years we’ve been focusing on making things easier, stable, and faster. More things can be managed via the UI, most YAML-based integrations can be reloaded without restarting and if something breaks, safe mode and built-in backups have your back.”
I really hope so.
I’m using the ZHA + ConBee2 setup and the single point of failure this poses is gnawing at the back of my head for a while now.
It does make me happy to see so much dedicated people working an an Esperanto version of the Zigbee network. This gives me the reassurance a decent option will be available in the near future.
Needless to say I upvoted this feature request!
Indeed. I was in the assumption I could just briefly disable ZHA, switch to zigbee2mqtt to test something, disable and stop that, enable ZHA again but… wrong!!!
No more working devices, everything needs to be re-paired again (opening up all those wall switches and build in devices etc.). I mean, the devices are still there and recognised in the integration, even if you delete it and add it again, but they keep greyed out and basically the network is just dead.
Home Assistant Core definitely needs this backup function build in. Even with the nice Home Assistant Blue (OS) Odroid nothing can go wrong or you can run around with your screwdriver (again) to copy/paste the right entity ID’s and walk trough all automations etc.
Became a bit reserved now expanding the Zigbee network on a regular base and will choose a strategy to wait until I have done all tests and with new devices that we want and then put it all in at some point and do not touch it ever again after. And pray the coordinator stick never dies.
Little extra’s could also be done with Z-Wave, that is way more stable with adding/excluding (though crazy expensive).
By the way, check out this new video at around 11 min 50 sec in where talk about and highlight this focus point about making it easier to start/setup common tasks and basic features in fewer steps, etc.
Hoping that this will peak the interest of more developers to help with more ZHA features, like backups.
This requested feature will become more important when Home Assistant Yellow becomes available. I will have to transfer my Zigbee configuration information (currently using a ConBee II stick) to the Zigbee coordinator on Home Assistant Yellow.
That is a good point. Although the Home Assistant Yellow has a Zigbee RF module, I could still plug in my ConBee II stick in a USB port. Hopefully, by the time that it begins to “Matter”, there will be a good migration path that allows me to take advantage of the upcoming Matter smart home standard, (which I assume will require me to use the Silicon Labs RF module on Home Assistant Yellow instead of the ConBee II). Thanks.
Off-topic but yeah, I don’t think that ConBee II will ever support Thread for Matter, (but I read a comment by ConBee developer which hinted ConBee III is currently in development so maybe that will support OpenThread). So assume to use Thread for Matter you will need another adapter other than ConBee II.
Yes, there has at least been a lot of progress on the underlying zigpy libraries that ZHA uses as a dependency and all zigpy libraries are currently in the process of being updated to a new radio API for zigpy which will once fully merged among other things introduce a new network backup/restore utility in " zigpy-cli" for any zigpy radio library for Zigbee Coordinator adapters/dongles that implementing that for the new radio API.
The initial support will include a unified radio command line interface and using standard network backup format for the zigpy radio libraries that support Zigbee Coordinator adapters/dongles based on Silicon Labs, Texas Instruments, and deconz (ConBee/RaspBee) serial protocols, (leaving someone else having to volunteer to add backup/restore code for XBee and ZiGate radio libraries when the new zigpy radio API is in place).
I also believe that once patches are merged on the zigpy side some other volunteering developer(s) would still have to step-up and implement the use of that new network backup/restore utility in “zigpy-cli” in the ZHA integration (which is component part of Home Assistant core) and the Home Assistant frontend for the UI interface, (and the developers working on the zigpy part for this have in the past mostly worked on the core/backend parts and not the frontend UI/GUI parts).
To follow the status of the underlying zigpy development see patches and pull requests linked here:
FYI, ZHA’s zigpy dependencies have now been updated with the mentioned new zigpy radio API that introduces a network backup/restore utility via “zigpy-cli ” (initially for zigpy-znp, bellows, and zigpy-deconz radio libraries) and those libraries has been bumped in Home Assistant core and thus the backend side needed to make this happen will be available is the upcoming Home Assistant 2022.7 release.
https://github.com/home-assistant/core/pull/73964 has the comment “This incorporates the new radio API for zigpy, which will allow for network parameter changes and backup/restore in a future patchset.”
Again, I still think that some other volunteering developer(s) might have to step up and implement the use of that new network backup/restore utility in “zigpy-cli ” in the ZHA integration (which is component part of Home Assistant core) and the Home Assistant frontend for the UI interface, (as as again gooing on historical UI features the developers working on the zigpy parts for this have in the past mostly worked on the core/backend parts and not the frontend UI/GUI parts). Read → https://github.com/zigpy/zigpy-cli/pull/2
Tip! If you have not yet purchased a replacement for that CC2530/CC2531 based adapter then keep in mind that TI CC2652 (CC2652P) or Silabs EFR32 (EFR32MG21) based adapters are generally recommended before ConBee/Raspbee for better performance when not using Dresden Elektronik’s official deCONZ/Phoscon Zigbee Gateway software for them. For CC2652 hardware links see → Supported Adapters | Zigbee2MQTT
but in the docs the two commands are specified as either:
service: zha_toolkit.execute
data:
command: ezsp_backup
# Optional command_data, string added to the basename.
# With this example the backup is written to `nwk_backup_20220105.json`
command_data: _20220105
or:
service: zha_toolkit.znp_backup
data:
# Optional command_data, string added to the basename.
# With this example the backup is written to `nwk_backup_20220105.json`
command_data: _20220105
FYI, zigpy and ZHA developer @puddly have now submitted initial patches for ZHA in Home Assistant core (backend) and frontend (GUI) for both automatic and manual Zigbee network backup + restore features/settings; “Implements the websocket API for listing, creating, and restoring ZHA network backups. This also adds a ZHA backup platform, which initiates network backup whenever a HA backup is created.” + “Add a new tab to the ZHA interface to show the current network settings to allow them to be backed up/restored.” See these pull requests for reference:
