zigpy-zigate compatibility with ZiGate firmware 31e

[Hedda]

@doudz is zigpy-zigate ready for ZiGate firmware 31e?

Saw that the question was asked here -> https://github.com/pipiche38/Domoticz-Zigpy/issues/32

PS: This is indirectly related to Domoticz-Zigpy discussion -> https://github.com/zigpy/zigpy/discussions/750

[doudz]

Not yet ready because some new messages (like 0x8012, 0x8702 or 0x9999) are just unhandled
but it should be compatible since the new messages extend the possibilities but do not change how zigate works and how zigpy use it

[pipiche38]

check PR #107 or #106

[max5962]

Any news about that ticket ? #107 and #106 has been closed
thanks

[Hedda]

Any news about that ticket ? #107 and #106 has been closed

See the last comment by pipiche38 in #107

we are currently working on zigpy-zigate library under a fork dedicated to our project, we don't have the possibility to test it under the ZHA environment but if you are ready to do, you can eventually use it https://github.com/zigbeefordomoticz/zigpy-zigate

When ready we will be providing PRs against the main stream

Forking a project/library means that the library has been copied and some or any code patches (like new fixes or features) to forks might or might not be actively contributed back to the original upstream project by the developers that are working on that forked version.

In this case, it means that there is at least one patch in the fork https://github.com/zigbeefordomoticz/zigpy-zigate that is not available in upstream https://github.com/zigpy/zigpy-zigate but those patches in that fork are not currently being actively tested to check for any breakage in the ZHA integration component in Home Assistant by the developers working on that fork of zigpy-zigate as they are testing the library with another software application and do not have time or interest in regression testing with other applications using the same library, like ZHA.

As in, if you want those patches to be in upstream now rather hoping that they might be added later then regression testing of that fork (or just specific patches) is needed by other volunteers and then once confirmed not broken anything, someone, either the tester or some other volunteer will need to backport that and any other acceptable fixes from that fork back here to the upstream zigpy-zigate.

Terminology for reference:

• https://en.wikipedia.org/wiki/Fork_(software_development)
• https://en.wikipedia.org/wiki/Regression_testing
• https://en.wikipedia.org/wiki/Backporting

If you have the ability to test that fork with your setup then please do so and report your result here and also to #107 and #106

There is some more information about testing here that would need to be adapted when working with a forked library version:

• https://github.com/zigpy/zigpy-zigate#testing-new-releases
• https://github.com/zigpy/zigpy/blob/dev/CONTRIBUTING.md
• https://github.com/zigpy/zha-device-handlers/#testing-quirks-in-development-in-docker-based-install

PS: As I understand it, the main reason why they choose to fork to https://github.com/zigbeefordomoticz/zigpy-zigate rather than just keep submitting pull requests to upstream https://github.com/zigpy/zigpy-zigate is that no zigpy developers who own any ZiGate hardware and have a personal interest in maintaining support for are currently actively working on maintaining upstream https://github.com/zigpy/zigpy-zigate thus new volunteering developers with a personal interest in maintaining support is needed.

[pipiche38]

@Hedda the fork gave use the possibility to move forward without having the all zigpy approval chain mecanism.
In between we (@badzz) have made already a lot of improvement toward the zigpy-zigate library like:

• handling the new 8012/8011/8702 messages which are there to insure the proper flow of messages without exceeding Zigate ressources.

happy to support any tester on ZHA side if they are willing to

[edited] In any means it is not our wishes to maintain a fork of the zigpy-zigate, when ready we will push the update via PRs, up