Closed Hedda closed 3 years ago
Currently the binding already supports the format used by the zigbee library used in openHAB. As there is no real standard for this I don't see the point in changing.
An extended idea is that eventually perhaps will enable a backup format that also allows migration between Zigbee implementations.
If you want to migrate between implementations there is nothing to stop you doing that now - you don't need to backup and restore the network.
As there is no real standard for this I don't see the point in changing.
The idea for that project was that if available then it might be adopted by open-source home automation software applications.
The goal with the Open Coordinator Backup Format is to be the go-to standard for all open-source Zigbee implementations.
zigpy got this now which means that it will be supported by both Home Assistant (ZHA integration) and Jeedom (official plugin).
zigbee-herdsman will support it soon too so that means it will also be supported by Zigbee2MQTT and IoBroker.
Home Assistant, Jeedom, IoBroker, and Zigbee2MQTT do together make up a large chunk of the worlds most popular open-source home automation applications with integrated Zigbee support. If would add OpenHAB to that list as well...
Again though, I don't see the purpose of this. If you want to run different software, you don't need to backup and restore - that will not restore the full network and there is just no need to do this.
@Hedda the "backup format" is just a high-level representation of network info and security state (link keys, counters, and network key). It's not intended for migrating networks between software despite what the README says (I should remove that), only for extracting coordinator state. It's intended as an intermediate representation to allow users to easily migrate between coordinator hardware (CC2531 to Silicon Labs, Silicon Labs to CC2652R, etc.).
Essentially, Zigpy needed a format for coordinator backups and Zigbee2MQTT's current on-disk format has the same goal so we are working on a common one. If openHab or the underlying Z-Smart Systems Zigbee library intends to support coordinator migration in the future with an intermediate file, working with us to extend our file format would be nice, since those state files will likely contain the exact same information. They could also be processed by other open source tools in the event the original coordinator hardware is unavailable.
If openHab or the underlying Z-Smart Systems Zigbee library intends to support coordinator migration in the future with an intermediate file
This has been supported for a few years now already. At the moment there is no intention to change this.
OK, but for reference; "ZNP Adapter Manager/Backup Refactor" pull request by castorw for zigbee-herdsman was now merged:
https://github.com/Koenkk/zigbee-herdsman/pull/303
This means Zigbee2MQTT and IoBroker can also use the same unified "Open ZigBee Coordinator Backup Format" as zigpy & HA:
That's fine - other software is free to use what ever format it desires. As already explained, this is not there to migrate systems - it's a backup so there is no need at all for a unified format.
This is a feature request and not a issue/bug report:
Suggest openHAB Zigbee add support for "Open ZigBee Coordinator Backup Format" for Zigbee network backup and restore.
https://github.com/zigpy/open-coordinator-backup/
The "Open ZigBee Coordinator Backup Format" project is a collaboration between puddly from the zigpy project and castorw from the zigbee2mqtt project in an effort to created a high-level and stack-agnostic backup of your Zigbee coordinator network data using the Open Coordinator Backup Format. This allows you to snapshot the device state and move your network between any supported hardware and firmware versions, and it can allow for bidirectional migration between any coordinators.
The concept is that this could not only enable backwards and forward migrations back and forth between different Zigbee stacks and Zigbee stack versions.
For example, a network backup will allow you to migrate from a CC2530/CC2531 stick with Z-Stack Home 1.2 to a CC2652/CC1352 stick with Z-Stack 3.0 and vice versa (if and when Z-Stack 3.0 is supported) without re-joining any devices. Same concept should in the future even work for migrating from Texas Instruments Z-Stack to Silicon Labs Ember/EmberZNet Zigbee stack and vice versa.
This backup format is human-readable and fully documented so you can fill out the appropriate information by hand to form a network if you are migrating from a non-Texas Instruments device.
Noticed that zigpy-znp v0.5.0 been released with initial support for this feature in zigpy-znp and in the release notes puddly credits castorw and reference his current effort to bring support for this "Open ZigBee Coordinator Backup Format" to Z2M:
https://github.com/zigpy/zigpy-znp/releases/tag/v0.5.0
"Huge thank you to castorw from the Z2M project for working with me to bring concurrent support for the Open Coordinator Backup Format to Z2M. This allows for bidirectional migration between any coordinators supported by zigpy-znp. More documentation is available in TOOLS.md#Backup and restore."
There is more discussion and information about this here in regards to zigpy (used by ZHA in Home Assistant and Jeedom):
https://github.com/zigpy/zigpy/issues/557
and more here in regards to the same backup feature and format zigbee-herdsman (used by Zigbee2MQTT and IoBroker) :
https://github.com/Koenkk/zigbee-herdsman/pull/303
PS: An extended idea is that eventually perhaps will enable a backup format that also allows migration between Zigbee implementations. So a user could migrate from example Zigbee2MQTT, IoBroker, Jeedom, or ZHA in Home Assistant (zigpy) to openHAB Zigbee Binding or vice versa by simply doing a backup of your Zigbee network in any of those applications and doing a restore in openHAB (or vice versa).