ZHA integration to do nightly backup of both Zigbee Coordinator adapter/dongle/stick and Zigbee network/database?

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”:

https://www.home-assistant.io/blog/2022/01/19/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!

2 Likes

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).

1 Like

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.

1 Like

FYI, zigpy-deconz (ZHA dependency library) in another zigpy library that will soon be capable of supporting ConBee/RaspBee backup and restore that can be used for Zigbee network backups and migrations, see → https://community.home-assistant.io/t/zha-libraries-will-soon-support-conbee-raspbee-backup-and-restore-that-can-be-used-for-zigbee-network-migrations/374782 and https://github.com/zigpy/zigpy-cli/pull/2

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.

1 Like

Hopefully the Home Assistant Yellow will support same backup and restore method via EZSP/bellows:

Technically do you not have to transfer as you can still connect your ConBee II stick to it via a USB port.

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.

FYI, many testers testing has confirmed that patches for the mentioned pull request work with ConBee:

https://github.com/zigpy/zigpy-cli/pull/2

Again, idea is backup and restore will work via “zigpy-cli” regardless of Zigbee Coordinator make/model.

Has there been any progress with zha coordinator backups?

I’m relatively new to ZIgbee and this would be a great feature to have.

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:

https://github.com/zigpy/zigpy-cli/pull/2

and zigpy developers have discussed the concepts and ideas about unified backup CLI + format here:

https://github.com/zigpy/zigpy/issues/557

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

1 Like

Is it possible now to move from CC2531 to ConBee II or RaspBee ? I cant find informations about that.

Yes I believe that should be possible now, however not yet from Home Assistant, but using zigpy-cli command-line tool for backup and restore, again see discussions in ZHA libraries will soon support ConBee/RaspBee backup and restore that can be used for Zigbee network migrations and https://github.com/zigpy/zigpy-cli/pull/2 (as well as https://github.com/zigpy/open-coordinator-backup) so maybe post to zigpy-cli discussions if run into problems Discussions · zigpy/zigpy-cli · GitHub

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

It’s possible but annoying to make the backup from HA. In my config I have this:

shell_command:
  zigbee_backup: python -m zigpy_znp.tools.network_backup /dev/serial/by-id/usb-ITead_Sonoff_Zigbee_3.0_USB_Dongle_Plus_9493876151c9eb11b7dxxxxxxxx-if00-port0 -o network_backup-"`date +"%Y-%m-%d"`".json ; cp zigbee.db zigbee-"`date +"%Y-%m-%d"`".db

Then you’ll need to:

  • disable the ZHA integration
  • run the zigbee_backup from developer tools
  • enable the ZHA integration
  • reboot to get your zigbee up and running.

I haven’t found a way to disable or enable the integration using a HA service.

You can backup znp using zha-toolkit - there is a blueprint for it - you have to install zha-toolkit of course which is easiest to do using HACS.

There are two blueprints for backups:

.
  name: Daily Coordinator Backup - Monthly rotation
  description: >-
    Backup Zigbee Coordinator Configuration (ZNP/ezsp(bellows)),
    monthly rotation
.
.
action:
  - service: zha_toolkit.execute
    data:
      command: backup

and the other:

.
  name: Daily ZNP Backup - Monthly rotation
  description: Backup ZNP Zigbee configuration, monthly rotation
.
.
action:
  - service: zha_toolkit.execute
    data:
      command: znp_backup

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

Which of the four should it be?

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:

3 Likes

Good news at last, soon I will be able to move to my Sonoff dongle plus