search

dresden-elektronik / phoscon-app-beta

Access to Phoscon app beta
78 stars 5 forks source link

[REQUEST] Open ZigBee Coordinator Backup Format support for Zigbee network backups and restoring from and to ConBee/RaspBee (deCONZ based adapters) #449

Open Hedda opened 2 years ago

Hedda commented 2 years ago

Request dresden-elektronik deCONZ/Phoscon developers consider implementing support for Zigbee network backup/restore to the "Open ZigBee Coordinator Backup Format" open format and shared common file standard in deCONZ/Phoscon implementations.

https://github.com/zigpy/open-coordinator-backup

This new open format standard is a unified file format for storing and restoring Zigbee network backups. It was initially invented as a shared project by developers from Zigbee2MQTT and zigpy (library used in Home Assistant's ZHA and other implementations).

By sharing the same open format in different Zigbee implementations/applications it makes it possible for end-users to upgrade, downgrade, and/or migrate between different hardware dongles and even between different Zigbee implementations/applications without ever having to re-pair their Zigbee devices.

While the deCONZ/Phoscon already has its own proprietary backup format, also supporting saving backups to standard "Open ZigBee Coordinator Backup Format" files would allow ConBee or RaspBee users in other implementations to save backup and restore them in the same or other Zigbee implementation using old or new hardware, including other implementations which already support ConBee or RaspBee, like Zigbee2MQTT, iOBroker, and zigpy-deconz (used by Home Assistant's ZHA integration, and Jeedom, etc.).

So far this open format standard has already has been adopted or is in the progress of being adopted by these Zigbee implementations:

Example usage in implementations:

FYI, this is already a popular upgrade, downgrade, and migration method among users in some communities as seen in examples here:

stale[bot] commented 2 years ago

As there hasn't been any response in 21 days, this issue has been automatically marked as stale. At OP: Please either close this issue or keep it active It will be closed in 7 days if no further activity occurs.

Hedda commented 2 years ago

This is still a valid request.

manup commented 2 years ago

Hi sorry I've missed the initial post. The idea itself is pretty nice, but the current spec is missing a few things imho to make it suitable for migration between different projects. I think it's limited to backup/restore while having the higher level configurations still available and importantly staying on the same project (ZHA, Zigbee2Mqtt, deCONZ,...).

Here are a few thoughts in that regard:

The endpoints / simple descriptors of the coordinator need to be included in the backup, as different projects use different configurations, just rewriting with the projects default settings would break the setup.

The spec could work for routers, if the application is able to query all further information like Basic Cluster attributes, bindings, groups and scenes, ....

This fails for sleeping devices. E.g. if you have coordinator A and paired a sleeping Xiaomi sensor. When coordinator B applies the backup it can receive messages from the sensor, but has no way to figure out which device it actually is and what to do with it, reading from the Basic Cluster is often not possible since the devices sleep. So here it would be good to extend the devices object with at least Basic Cluster "model id" and "manufacturer name", I'd also recommend the application version attribute (not to confuse with swbuildid) as some devices as Ikea switches need special handling based on it.

Bindings and ZCL attribute reporting configuration are a tricky topic. Every project has different default configurations for these, which may also be modified by the user, e.g. switch 1 sends OnOff group casts to group 1234. And might have reporting settings which may control when the device is polled after a timeout or the device is marked as unreachable.

In deCONZ with the new DDF approach we check/verify and reconfigure all of this if needed also for sleeping end devices. But I think it's quite common for projects to have some fixed assumptions here (as we had pre DDF). The binding and reporting configuration should be part of the backup, however even with that I'm afraid it gets really challenging to migrate between projects. Nearby bindings also group membership of other devices need to be backup.

Hedda commented 2 years ago

@manup Can you maybe post those request(s) as new issues to -> https://github.com/zigpy/open-coordinator-backup/issues ?

cc: @puddly, @castorw