zigpy-zigate
zigpy-zigate copied to clipboard
zigpy
zigpy-zigate compatibility with ZiGate firmware 31e
@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
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
Any news about that ticket ? #107 and #106 has been closed
See the last comment by pipiche38 in https://github.com/zigpy/zigpy-zigate/pull/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 https://github.com/zigpy/zigpy-zigate/pull/107 and https://github.com/zigpy/zigpy-zigate/pull/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.
@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