[SUGGESTION] Move zha-toolkit repository to zigpy organization?

[mdeweerd]

Following the message from @Hedda : mdeweerd/zha-toolkit#3. It's well said, so I am not rephrasing him ;-) .

My response: I am fine with "moving" zha-toolkit. If this entails any restrictions/rules - let me know up front.

[Hedda]

Like to bump this suggestion/question. zha-toolkit provides great values via low-level and high-level Zigbee commands through ZHA/zigpy:

https://community.home-assistant.io/t/zha-toolkit-a-big-set-of-zigbee-commands-on-top-of-zha-zigpy/373346

mdeweerd/zha-toolkit#3

@mdeweerd can I suggest that you consider asking/discussing the possibility of having your zha-toolkit repository moved from https://github.com/mdeweerd/zha-toolkit moved to the zigpy organization @ https://github.com/zigpy/ on GitHub so that the mainstream copy of this repo will stay there become upstream for shared access together by the collective of developers that make up the zigpy organization?

Note that "organization" is just GitHub's terminology as I understand it is more an informal collaboration between like-minded ZHA and zigpy developers in order to collect ZHA and zigpy projects ín one place and shared access rights, (noting that the zigpy organization on GitHub has no public members and that you must be a member to see who’s a part of that organization, which I am not myself).

https://github.com/zigpy/

Most ZHA related repositories have been moved there over time as a way for like-minded ZHA and zigpy developers that are members of the zigpy organization with yourself included can have shared ownership and access to your zha-toolkit repository and the other projects for collaboration within that community?

Moving it could potentially also help new ZHA developers take notice of this zha-toolkit project.

Hope that you at least will consider this option and if you think it is a good idea then hoping that you all could come to an agreement that will make everyone happy with you continuing this zha-toolkit repository under the zigpy organization together without getting offended by any ownership conflicts.

PS: Same people who are members of that zigpy organization on GitHub also share another GitHub organization called "zha-ng" (short for "ZHA next-generation"?) which contains additional early experimental projects before they became mature to be moved:

https://github.com/zha-ng

[Hedda]

@Adminiuga @puddly Given any consideration to this? IMHO, ZHA Toolkit is today essential just for its functions via backup blueprint alone.

https://community.home-assistant.io/t/daily-zigbee-coordinator-backup-blueprint-znp-ezsp-bellows/377149

https://community.home-assistant.io/t/zha-integration-to-do-nightly-backup-of-both-zigbee-coordinator-adapter-dongle-stick-and-zigbee-network-database/357558/

[Hedda]

@mdeweerd Have you by the way tested zha-toolkit with the new radio API for zigpy so that it does not break backups, etc.? -> #848

Originally posted by @puddly in #848 (comment)

Alright, this PR is about as ready as it will ever be. Any final thoughts before I merge this and the corresponding PRs in all of the other radio libraries?

[mdeweerd]

Short answer: no, and I do not actually have a test setup - I have two systems and both are used for real.

Longer answer: ZHA Toolkit does not rely on the radio interface for backups, but integrates code from the radio specific extensions:

• https://github.com/mdeweerd/zha-toolkit/blob/main/custom_components/zha_toolkit/ezsp_backup.py#L20 (which is essentially a copy of https://github.com/zigpy/bellows/blob/dev/bellows/cli/backup.py#L85 because it could not be called "as is"
• https://github.com/mdeweerd/zha-toolkit/blob/main/custom_components/zha_toolkit/znp.py#L29 which calls https://github.com/zigpy/zigpy-znp/blob/dev/zigpy_znp/tools/network_backup.py#L78 .

Both of these radio specific implementations did not change their CLI implementation, so either they still work, are obsolete and replaced by other methods, or require an update themselves. In case bellows changes, then zha-toolkit would need an update and I'ld prefer to have a callable function as with ZNP where the code is essentially under zigpy_znp control avoiding code repetition.

There may be other things that break with the new API because it is the zha-toolkit use is well beyond the backup feature.

I'll probably discover anything breaking when it's available in HA itself.

[Hedda]

Both of these radio specific implementations did not change their CLI implementation, so either they still work, are obsolete and replaced by other methods, or require an update themselves. In case bellows changes, then zha-toolkit would need an update and I'ld prefer to have a callable function as with ZNP where the code is essentially under zigpy_znp control avoiding code repetition.

FYI, there is a PR for zigpy-cli that depends on this change as it in turn will introduce a network backup/restore utility for any adapter implementing the new radio API, see -> zigpy/zigpy-cli#2

[Hedda]

FYI, there is a PR for zigpy-cli that depends on this change as it in turn will introduce a network backup/restore utility for any adapter implementing the new radio API, see -> zigpy/zigpy-cli#2

There is by the way a matching RFC discission about that new unified radio command line interface for standard backup here -> #557

[Hedda]

Oh, and PR zigpy/zigpy-cli#2 will also allow users of ConBee/RaspBee adapters to backup network via zigpy radio library for deconz

[Hedda]

@mdeweerd FYI, the new radio API was merged a little more than a month ago and puddly has now also 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 pull requests:

home-assistant/core#75791

and

home-assistant/frontend#13295

also see

zigpy/zigpy-cli#13

and

#1006

[mdeweerd]

I am sure that a good job was done and I am more than happy to see an implementation in the mainstream offer. More importantly, restoring should be easier in that setup.

[Hedda]

Bumping request asking to zigpy developers to reconsider merging mdeweerd's zha-toolkit repository/project into the zigpy organization:

e.i. moving https://github.com/mdeweerd/zha-toolkit repo to -> https://github.com/zigpy/zha-toolkit

Again, his zha-toolkit provides great value added for advanced ZHA users by allowing use of low-level Zigbee commands through ZHA:

https://github.com/mdeweerd/zha-toolkit/blob/main/README.md

The thread about "zha-toolkit" custom component still ranks among the most active in the Zigbee section on the HA community forum:

https://community.home-assistant.io/t/zha-toolkit-toolkit-providing-low-and-high-level-zigbee-commands-through-zha-zigpy/373346