Home assistant error Received unhandled response 0x8012 tradfri IKEA

[baimard]

``

zigpy-zigate/zigpy_zigate/api.py

Line 22 in 818c3a1

RESPONSES = {

My IKEA light send me a 0x8012 answer.

Is it possible to had this response ?

home_assistant.1.mn6u4y319qpd@ocre    | 2021-11-07 14:18:38 DEBUG (MainThread) [zigpy_zigate.uart] Frame received: 80000009be00b7053001b7000300
home_assistant.1.mn6u4y319qpd@ocre    | 2021-11-07 14:18:38 DEBUG (MainThread) [zigpy_zigate.api] data received 0x8000 b'00b7053001b70003' LQI:0
home_assistant.1.mn6u4y319qpd@ocre    | 2021-11-07 14:18:38 DEBUG (MainThread) [zigpy_zigate.zigbee.application] zigate_callback_handler [0, 183, 1328, b'\x01\xb7\x00\x03']
home_assistant.1.mn6u4y319qpd@ocre    | 2021-11-07 14:18:38 DEBUG (MainThread) [zigpy_zigate.uart] Frame received: 8012000a47000101025231b700030a
home_assistant.1.mn6u4y319qpd@ocre    | 2021-11-07 14:18:38 DEBUG (MainThread) [zigpy_zigate.api] data received 0x8012 b'000101025231b70003' LQI:10
home_assistant.1.mn6u4y319qpd@ocre    | 2021-11-07 14:18:38 ERROR (MainThread) [zigpy_zigate.api] Received unhandled response 0x8012

[baimard]

RESPONSES = {
    0x004D: (t.NWK, t.EUI64, t.uint8_t, t.uint8_t),
    0x8000: (t.uint8_t, t.uint8_t, t.uint16_t, t.Bytes),
    0x8002: (t.uint8_t, t.uint16_t, t.uint16_t, t.uint8_t, t.uint8_t,
             t.Address, t.Address, t.Bytes),
    0x8009: (t.NWK, t.EUI64, t.uint16_t, t.uint64_t, t.uint8_t),
    0x8010: (t.uint16_t, t.uint16_t),
    0x8011: (t.uint8_t, t.NWK, t.uint8_t, t.uint16_t, t.uint8_t),
    0x8012: (t.uint32_t,),
    0x8017: (t.uint32_t,),
    0x8024: (t.uint8_t, t.NWK, t.EUI64, t.uint8_t),
    0x8035: (t.uint8_t, t.uint32_t),
    0x8048: (t.EUI64, t.uint8_t),
    0x8701: (t.uint8_t, t.uint8_t),
    0x8702: (t.uint8_t, t.uint8_t, t.uint8_t, t.Address, t.uint8_t),
    0x8806: (t.uint8_t,),
}

I just add this line : 0x8012: (t.uint32_t,),

[nlhomme]

I'm having the same issue on Home Assistant with the ZHA integration:

Logger: zigpy_zigate.api
Source: /usr/local/lib/python3.9/site-packages/zigpy_zigate/api.py:115
First occurred: 12:03:31 (2 occurrences)
Last logged: 12:03:33
Received unhandled response 0x8012

My Zigbee controller is a Zigate v1 with firmware 3.1e

[nlhomme]

It seems that this issue has been treated in #107

[Hedda]

@baimard You might want to consider reopening issue and @nlhomme might want to create a new 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.

[baimard]

done

[pipiche38]

@baimard You might want to consider reopening issue and @nlhomme might want to create a new 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.

I don't understand all of this communication from @Hedda, if you are against what we are currently doing, tell us frankly , but so far the zigpy-zigate library is stuck and not maintained. So it is unbelievable to read such messages !

[MattWestb]

I agree with @pipiche38 but if hi and some more like forking some part (or all) of the Zigpy libs and patching it like more devs have doing in other system its more than OK.
The best is they can making the patches upstream for easter maintaining there system but its not primary one Zigpy problem but its best for all if its possible doing it.

In the end if more support for different hardware /system then better for all parts and our community.

Also having more devs working with different parts is also one win win situation then getting more devices supported in the upstream (pipiche38 have helping getting more device added and some other system have doing the same).

I hope all is working well and getting all part in place and the system working with Zigpy libs as underlying radio lib.

Witch one great 2022 to all that is helping all working well in our system and many hours or nice "dream coeding" for getting more function in place !!

[pipiche38]

@MattWestb this is exactly my point, we are currently trying to enhance the zigpy-zigate layer, because we benefits from all good work done on zigpy and especially zigpy-znp.
At the end we are not interested to use zigpy-zigate as we have our own native way to communicate with zigate and for now there is no plan. Our approach was to get zigpy-zigate to a point where it is usable , now if the zigpy community @Hedda feels this is not interested for them, fine.

[Hedda]

I don't understand all of this communication from @Hedda, if you are against what we are currently doing, tell us frankly , but so far the zigpy-zigate library is stuck and not maintained. So it is unbelievable to read such messages !

@pipiche38 I am not against what you are doing at all. I am not against it in any way. I am very much a fan of what you are trying to achieve and think all that you guys are doing is a good thing. I think that it is great that more projects are trying to use zigpy.

I was just trying to inform others what it means by a fork as do not think that was made clear when the pull requests were closed.

Personally, I understand why you forked and understand that it will hopefully not be your long term goal but something that has to be done in order to speed up the development process and part of the normal everyday development process.

So, me being frank; I really LOVE what you have been doing with your project and I do wish that you will continue using zigpy in it.

I also do hope that you at some point get to having a stable version of zigpy-zigate in it too, no matter if it is a fork of it or not.

@pipiche38 Again I am sorry for the misunderstanding. I am not a native English speaker and I believe that neither are you(?)..

PS: I think if you would re-read my posts and remember they were not posted as something bad then they read very differently. As again, my posts was not aimed towards or against you but instead aimed towards other people reporting about zigpy-zigate issues.

In the end if more support for different hardware /system then better for all parts and our community.

+1 The more projects using zigpy and the more developers/users using hardware with different Zigbee stack the better for us all.

[pipiche38]

@Hedda I have been contacted by several HA users willing to test the current fork that we have. Is there any one from HA whom can give a short procedure on how to shift from the current zigpy-zigate package to the one available here https://github.com/zigbeefordomoticz/zigpy-zigate

Currently we have made changes to:

• Support Zigbee group and broadcast
• Support Zigate firmware 321 (which is the minimum)
• Support and handle the message flow ( 8011/8012/8702 )