Resolve issue #104: unhandled 0x8012 responses for Ikea TRADFRI

[nlhomme]

See issues #104 for more details

[nlhomme]

Any news about this PR?

Currently zigpy is flooding my logs

[nlhomme]

I see that this PR has been treated in #107 , I will now close this PR.

[Hedda]

@nlhomme You might want to consider reopening this or creating a new patch and pull request based on #107

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 than 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 (and we have seen the zigpy-zigate somehow not maintain since ages and very out-dated comparing to the firmware, and zigpy)
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

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