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:
Suggest asking in the dedicated thread for that Blueprint or its GitHub reposiroty instead as kind of off-topic from the original post here which really just a feature request for ZHA devs to add this and not a support thread for workarounds.
Not if restoring/migrating from third-party Zigbee solutions like Zigbee2MQTT (or IoBroker) to the ZHA integration, however it should keep it if the backup is made from the ZHA integration and migration is only from one supported Zigbee Coordinator adapter to a different supported Zigbee Coordinator adapter.
I’m slowly migrating from Domoticz to Home Assistant and loving it so far!
I’ve been using a Conbee II on domoticz with the own Deconz software. Is it possible to migrate the stick + backup from the Raspberry Pi running Domoticz and Deconz to ZHA?
Not yet (but perhaps in the distant future you could convince Dresden-Dlektronik’s developers), and the reason for is that Dresden-Elektronik’s deCONZ/Phoscon software does not (yet) use the same “Open ZigBee Coordinator Backup Format” that most of the open-source Zigbee implementations now support, (including; Home Assistant’s ZHA integration, Zigbee2MQTT, IoBroker, Jeedom, and the Zigbee Plugin for Domoticz). You can read and post feedback to Dresden-Dlektronik’s developers in this request → https://github.com/dresden-elektronik/deconz-rest-plugin-v2/issues/12
