Make full use of zigbee-herdsman ZNP Adapter Manager/Backup after refactor

[Hedda]

Disclaimer: I am not actually a user of ioBroker but are just curious to get it verified if Zigbee backups (and restore) in ioBroker:

Can ioBroker Zigbee developers verify if it makes full use of zigbee-herdsman ZNP Adapter Manager/Backup after its refactor?

The pull request for "ZNP Adapter Manager/Backup refactor" recently merged into zigbee-herdsman introduce new processes.

For reference please see Koenkk/zigbee-herdsman#303

PS: Can the new unified backup format make backups fully interchangeable for migration between IoBroker and Zigbee2MQTT?

[kirovilya]

We are already using the backup mechanism from zigbee-herdsman, but the latest changes caused some errors at start #1105
While we try to understand the reasons. Identified problems with extPanId

[asgothian]

Known issues popping up since the refactor (not necessarily caused by the refactor directly):

• Reversed ExtPanID in some cases
• ExtPanID dddddddddddddddd changed to Coordinator MACID -> Zigbee network must be reprovisioned and all devices must be paired anew.
• Unclear behavior with the nvbackup.json file. When will the new format be written. When is the old format retained.
• Duplicate device entries (shepherd.db, nvbackup.json) and issues when they are not in sync.
• Opening the network fails on some CC2538 coordinators. (Error Message Error: Failed to open the network: Error: SRSP - UTIL - ledControl after 6000ms)

PS: Can the new unified backup format make backups fully interchangeable for migration between IoBroker and Zigbee2MQTT?

This should have been possible before the refactor, with the caveat that the entries for PanID, ExtPanID and Zigbee Channel need to be transferred manually between zigbee2mqtt configuration and zigbee configuration.

I am in the process of reviewing if a setting to force use the nvbackup configuration is feasible with the current code, allowing for interoperability without explicit adapter configuration. (Also see here)

A.

[asgothian]

A quick update:
The current herdsman code does not support using the data stored in the nvram backup as default configuration:

• Network configuration is passed to the herdsman at creation.
• Network configuration may not be modified after creation.
• If no network configuration is given at creation, default entries are being used.
• nvram backup is read during startup.
• nvam content is not available to the client application in order to modify target network configuration.
• Issues remain with regards to configuration entry mismatch for devices between shepherd.db and devices.js

As it stands now, use of the nvram backup is limited to the use cases actively managed in the zigbee-herdsman. Significant modifications to the zigbee-herdsman are required to make this an actively used option for iobroker.zigbee. Final tests are running to see if it is viable to run the zigbee-herdsman without actually using the nvram backup at all.

A.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.