zigpy / zigpy-znp

TI CC2531, CC13x2, CC26x2 radio support for Zigpy and ZHA

zigpy

zigpy is a hardware independent Zigbee protocol stack integration project to implement Zigbee standard specifications as a Python 3 library.

Zigbee integration via zigpy allows you to connect one of many off-the-shelf Zigbee Coordinator adapters using one of the available Zigbee radio library modules compatible with zigpy to control Zigbee based devices. There is currently support for controlling Zigbee device types such as binary sensors (e.g., motion and door sensors), sensors (e.g., temperature sensors), lights, switches, buttons, covers, fans, climate control equipment, locks, and intruder alarm system devices. Note that Zigbee Green Power devices currently are unsupported.

Zigbee stacks and hardware from many different hardware chip manufacturers are supported via radio libraries which translate their proprietary communication protocol into a common API which is shared among all radio libraries for zigpy. If some Zigbee stack or Zigbee Coordinator hardware for other manufacturers is not supported by yet zigpy it is possible for any independent developer to step-up and develop a new radio library for zigpy which translates its proprietary communication protocol into the common API that zigpy can understand.

zigpy contains common code implementing ZCL (Zigbee Cluster Library) and ZDO (Zigbee Device Object) application state management which is being used by various radio libraries implementing the actual interface with the radio modules from different manufacturers. The separate radio libraries interface with radio hardware adapters/modules over USB and GPIO using different native UART serial protocols.

The ZHA integration component for Home Assistant, the Zigbee Plugin for Domoticz, and the Zigbee Plugin for Jeedom (competing open-source home automation software) are all using zigpy libraries as dependencies, as such they could be used as references of different implementations if looking to integrate a Zigbee solution into your application.

Zigbee device OTA updates

zigpy have ability to download and perform Zigbee OTAU (Over-The-Air Updates) of Zigbee devices firmware. The Zigbee OTA update firmware image files should conform to standard Zigbee OTA format and OTA provider source URLs need to be published for public availability. Updates from a local OTA update directory also is also supported and can be used as an option for offline firmware updates if user provide correct Zigbee OTA formatted firmware files themselves.

Support for automatic download from existing online OTA providers in zigpy OTA provider code is currently only available for IKEA, Inovelli, LEDVANCE/OSRAM, SALUS/Computime, and SONOFF/ITEAD devices. Support for additional OTA providers for other manufacturers devices could be added to zigpy in the future, if device manufacturers publish their firmware images publicly and developers contribute the needed download code for them.

How to install and test, report bugs, or contribute to this project

For specific instructions on how-to install and test zigpy or contribute bug-reports and code to this project please see the guidelines in the CONTRIBUTING.md file:

• Guidelines in CONTRIBUTING.md

This CONTRIBUTING.md file will contain information about using zigpy, testing new releases, troubleshooting and bug-reporting as, as well as library + code instructions for developers and more. This file also contain short summaries and links to other related projects that directly or indirectly depends in zigpy libraries.

You can contribute to this project either as an end-user, a tester (advanced user contributing constructive issue/bug-reports) or as a developer contributing code.

Compatible Zigbee coordinator hardware

Radio libraries for zigpy are separate projects with their own repositories and include bellows (for communicating with Silicon Labs EmberZNet based radios), zigpy-deconz (for communicating with deCONZ based radios from Dresden Elektronik), and zigpy-xbee (for communicating with XBee based Zigbee radios), zigpy-zigate for communicating with ZiGate based radios, zigpy-znp or zigpy-cc for communicating with Texas Instruments based radios that have Z-Stack ZNP coordinator firmware.

Note! Zigbee 3.0 support or not in zigpy depends primarily on your Zigbee coordinator hardware and its firmware. Some Zigbee coordinator hardware support Zigbee 3.0 but might be shipped with an older firmware which does not, in which case may want to upgrade the firmware manually yourself. Some other Zigbee coordinator hardware may not support a firmware that is capable of Zigbee 3.0 at all but can still be fully functional and feature complete for your needs, (this is very common as many if not most Zigbee devices do not yet Zigbee 3.0 or are backwards-compable with a Zigbee profile that is support by your Zigbee coordinator hardware and its firmware). As a general rule, newer Zigbee coordinator hardware released can normally support Zigbee 3.0 firmware and it is up to its manufacturer to make such firmware available for them.

Compatible zigpy radio libraries

• Digi XBee based Zigbee radios via the zigpy-xbee library for zigpy.
• dresden elektronik deCONZ based Zigbee radios via the zigpy-deconz library for zigpy.
• Silicon Labs (EmberZNet) based Zigbee radios using the EZSP protocol via the bellows library for zigpy.
• Texas Instruments based Zigbee radios with all compatible Z-Stack firmware via the zigpy-znp library for zigpy.
• ZiGate based ZigBee radios via the zigpy-zigate library for zigpy.

Legacy or obsolete zigpy radio libraries

• Texas Instruments with Z-Stack legacy firmware via the zigpy-cc library for zigpy.

Release packages available via PyPI

New packages of tagged versions are also released via the "zigpy" project on PyPI

• https://pypi.org/project/zigpy/
  • https://pypi.org/project/zigpy/#history
  • https://pypi.org/project/zigpy/#files

Older packages of tagged versions are still available on the "zigpy-homeassistant" project on PyPI

• https://pypi.org/project/zigpy-homeassistant/

Packages of tagged versions of the radio libraries are released via separate projects on PyPI

• https://pypi.org/project/zigpy/
  • https://pypi.org/project/bellows/
  • https://pypi.org/project/zigpy-cc/
  • https://pypi.org/project/zigpy-deconz/
  • https://pypi.org/project/zigpy-xbee/
  • https://pypi.org/project/zigpy-zigate/
  • https://pypi.org/project/zigpy-znp/

zigpy-znp's Issues

Removing device from the network doesn't remove device from the database

Removing device from the network doesn't remove device from the internal database/device list.
Here's log of device being removed two times. The device does receive the leave request and leaves the network, but it seems it still being kept in the ControllerApplication.devices dict.

On the second "device removed" I was expecting to see "device not found" message

2020-05-10 22:14:00 DEBUG (MainThread) [zigpy_znp.api] Received command: ZDO.LeaveInd.Callback(NWK=0x66d6, IEEE=7c:b0:3e:aa:00:a5:e4:7f, Request=<Bool.false: 0>, Remove=<Bool.true: 1>, Rejoin=<Bool.false: 0>)
2020-05-10 22:14:00 INFO (MainThread) [zigpy_znp.zigbee.application] ZDO device left: ZDO.LeaveInd.Callback(NWK=0x66d6, IEEE=7c:b0:3e:aa:00:a5:e4:7f, Request=<Bool.false: 0>, Remove=<Bool.true: 1>, Rejoin=<Bool.false: 0>)
2020-05-10 22:14:00 INFO (MainThread) [zigpy.application] Device 0x66d6 (7c:b0:3e:aa:00:a5:e4:7f) left the network
2020-05-10 22:14:07 DEBUG (MainThread) [homeassistant.components.zha.core.channels.base] [0xfab6:1:0x0b04]: async_update
2020-05-10 22:14:07 DEBUG (MainThread) [zigpy.device] [0xfab6] Extending timeout for 0x5b request
2020-05-10 22:14:07 DEBUG (MainThread) [zigpy_znp.api] Sending request: AF.DataRequestExt.Req(DstAddrModeAddress=AddrModeAddress(mode=<AddrMode.NWK: 2>, address=0xfab6), DstEndpoint=1, DstPanId=0x0000, SrcEndpoint=1, ClusterId=2820, TSN=91, Options=<TransmitOptions.RouteDiscovery: 32>, Radius=30, Data=b'\x00\x5B\x00\x0B\x05')
2020-05-10 22:14:07 DEBUG (MainThread) [zigpy_znp.api] Received command: AF.DataRequestExt.Rsp(Status=<Status.Success: 0>)
2020-05-10 22:14:07 DEBUG (MainThread) [zigpy_znp.api] Received command: AF.DataConfirm.Callback(Status=<Status.NwkNoRoute: 205>, Endpoint=1, TSN=91)
2020-05-10 22:14:07 DEBUG (MainThread) [zigpy_znp.zigbee.application] Received a data request confirmation: AF.DataConfirm.Callback(Status=<Status.NwkNoRoute: 205>, Endpoint=1, TSN=91)
2020-05-10 22:14:07 DEBUG (MainThread) [zigpy.device] [0xfab6] Delivery error for seq # 0x5b, on endpoint id 1 cluster 0x0b04: Invalid response status
2020-05-10 22:14:15 DEBUG (MainThread) [homeassistant.core] Bus:Handling <Event call_service[L]: domain=zha, service=remove, service_data=ieee_address=7c:b0:3e:aa:00:a5:e4:7f>
2020-05-10 22:14:15 INFO (MainThread) [homeassistant.components.zha.api] Removing node 7c:b0:3e:aa:00:a5:e4:7f
2020-05-10 22:14:15 INFO (MainThread) [zigpy.application] Removing device 0x66d6 (7c:b0:3e:aa:00:a5:e4:7f)
2020-05-10 22:14:15 DEBUG (MainThread) [zigpy_znp.zigbee.application] Intercepted AP ZDO request and replaced with ZDO.MgmtLeaveReq.Req(DstAddr=0x66d6, IEEE=7c:b0:3e:aa:00:a5:e4:7f, RemoveChildren_Rejoin=<LeaveOptions.RemoveChildren: 2>)/ZDO.MgmtLeaveRsp.Callback(Src=0x66d6, Status=None)
2020-05-10 22:14:15 DEBUG (MainThread) [zigpy_znp.api] Sending request: ZDO.MgmtLeaveReq.Req(DstAddr=0x66d6, IEEE=7c:b0:3e:aa:00:a5:e4:7f, RemoveChildren_Rejoin=<LeaveOptions.RemoveChildren: 2>)
2020-05-10 22:14:15 DEBUG (MainThread) [zigpy_znp.api] Received command: ZDO.MgmtLeaveReq.Rsp(Status=<Status.Success: 0>)
2020-05-10 22:14:25 DEBUG (MainThread) [homeassistant.core] Service did not complete before timeout: <ServiceCall zha.remove (c:f6a4607338844eca94304c1bbdaa938f): ieee_address=7c:b0:3e:aa:00:a5:e4:7f>
2020-05-10 22:14:30 DEBUG (MainThread) [zigpy.application] Sending 'zdo_leave_req' failed: 
2020-05-10 22:14:30 DEBUG (MainThread) [zigpy_znp.api] Sending request: ZDO.MgmtLeaveReq.Req(DstAddr=0x0000, IEEE=7c:b0:3e:aa:00:a5:e4:7f, RemoveChildren_Rejoin=<LeaveOptions.NONE: 0>)
2020-05-10 22:14:30 DEBUG (MainThread) [zigpy_znp.api] Received command: ZDO.MgmtLeaveReq.Rsp(Status=<Status.Success: 0>)
2020-05-10 22:14:30 DEBUG (MainThread) [zigpy_znp.api] Received command: ZDO.MgmtLeaveRsp.Callback(Src=0x0000, Status=<Status.SUCCESS: 0>)
2020-05-10 22:14:30 WARNING (MainThread) [zigpy_znp.api] Received an unhandled command: ZDO.MgmtLeaveRsp.Callback(Src=0x0000, Status=<Status.SUCCESS: 0>)
2020-05-10 22:14:37 DEBUG (MainThread) [homeassistant.components.zha.core.channels.base] [0xfab6:1:0x0b04]: async_update
2020-05-10 22:14:37 DEBUG (MainThread) [zigpy.device] [0xfab6] Extending timeout for 0x5d request
2020-05-10 22:14:37 DEBUG (MainThread) [zigpy_znp.api] Sending request: AF.DataRequestExt.Req(DstAddrModeAddress=AddrModeAddress(mode=<AddrMode.NWK: 2>, address=0xfab6), DstEndpoint=1, DstPanId=0x0000, SrcEndpoint=1, ClusterId=2820, TSN=93, Options=<TransmitOptions.RouteDiscovery: 32>, Radius=30, Data=b'\x00\x5D\x00\x0B\x05')
2020-05-10 22:14:37 DEBUG (MainThread) [zigpy_znp.api] Received command: AF.DataRequestExt.Rsp(Status=<Status.Success: 0>)
2020-05-10 22:14:37 DEBUG (MainThread) [zigpy_znp.api] Received command: AF.DataConfirm.Callback(Status=<Status.NwkNoRoute: 205>, Endpoint=1, TSN=93)
2020-05-10 22:14:37 DEBUG (MainThread) [zigpy_znp.zigbee.application] Received a data request confirmation: AF.DataConfirm.Callback(Status=<Status.NwkNoRoute: 205>, Endpoint=1, TSN=93)
2020-05-10 22:14:37 DEBUG (MainThread) [zigpy.device] [0xfab6] Delivery error for seq # 0x5d, on endpoint id 1 cluster 0x0b04: Invalid response status
2020-05-10 22:14:43 DEBUG (MainThread) [homeassistant.core] Bus:Handling <Event call_service[L]: domain=zha, service=remove, service_data=ieee_address=7c:b0:3e:aa:00:a5:e4:7f>
2020-05-10 22:14:43 INFO (MainThread) [homeassistant.components.zha.api] Removing node 7c:b0:3e:aa:00:a5:e4:7f
2020-05-10 22:14:43 INFO (MainThread) [zigpy.application] Removing device 0x66d6 (7c:b0:3e:aa:00:a5:e4:7f)
2020-05-10 22:14:43 DEBUG (MainThread) [zigpy_znp.zigbee.application] Intercepted AP ZDO request and replaced with ZDO.MgmtLeaveReq.Req(DstAddr=0x66d6, IEEE=7c:b0:3e:aa:00:a5:e4:7f, RemoveChildren_Rejoin=<LeaveOptions.RemoveChildren: 2>)/ZDO.MgmtLeaveRsp.Callback(Src=0x66d6, Status=None)
2020-05-10 22:14:43 DEBUG (MainThread) [zigpy_znp.api] Sending request: ZDO.MgmtLeaveReq.Req(DstAddr=0x66d6, IEEE=7c:b0:3e:aa:00:a5:e4:7f, RemoveChildren_Rejoin=<LeaveOptions.RemoveChildren: 2>)
2020-05-10 22:14:43 DEBUG (MainThread) [zigpy_znp.api] Received command: ZDO.MgmtLeaveReq.Rsp(Status=<Status.Success: 0>)
2020-05-10 22:14:53 DEBUG (MainThread) [homeassistant.core] Service did not complete before timeout: <ServiceCall zha.remove (c:ca530e4b4f3d48ed89a26220ba8b2923): ieee_address=7c:b0:3e:aa:00:a5:e4:7f>
2020-05-10 22:14:58 DEBUG (MainThread) [zigpy.application] Sending 'zdo_leave_req' failed: 
2020-05-10 22:14:58 DEBUG (MainThread) [zigpy_znp.api] Sending request: ZDO.MgmtLeaveReq.Req(DstAddr=0x0000, IEEE=7c:b0:3e:aa:00:a5:e4:7f, RemoveChildren_Rejoin=<LeaveOptions.NONE: 0>)
2020-05-10 22:14:58 DEBUG (MainThread) [zigpy_znp.api] Received command: ZDO.MgmtLeaveReq.Rsp(Status=<Status.Success: 0>)
2020-05-10 22:14:58 DEBUG (MainThread) [zigpy_znp.api] Received command: ZDO.MgmtLeaveRsp.Callback(Src=0x0000, Status=<Status.SUCCESS: 0>)
2020-05-10 22:14:58 WARNING (MainThread) [zigpy_znp.api] Received an unhandled command: ZDO.MgmtLeaveRsp.Callback(Src=0x0000, Status=<Status.SUCCESS: 0>)

[Help] - zigbee readout

Hey I would like to read out a zigbee motion sensor with my raspberry Pi via Python. I dont want to use stuff like Home-Server and those big plattforms for home automation but rather build my own application for my specific needs. What hardware would be required and is there any documentation how to do that, because I couldnt manage to find any.

Thanks for the help!

100% CPU Load while requests are active (eg toggling lights)

Hi!

I noticed that my CPU load goes up to 100% while I am toggling multiple lights (almost happens every time I toggle living room lights - ~15 lights). I shortly had a very stable network with all the lights responding extremely fast: then the CPU load was normal.

I tried debugging asyncio but I did not get any messages.
Is there anything I can do to find out what the cause is?

[REQUEST] Zigbee 3.0 and/or Zigbee PRO network forming support in zigpy-znp?

This is a request/suggestion to make zigpy-znp support Zigbee 3.0 and/or Zigbee PRO network forming?

This directly relates to Zigbee 3.0 network supported requested for zigpy in zigpy/zigpy#360 and zigpy/bellows#292 and zigpy/zigpy-cc#64

That is, make it possible for zigpy-znp with or without zigpy to form a Zigbee 3.0 network allowing newer devices to use a Zigbee 3.0 profile as an option instead of ZHA 1.2 profile in a Zigbee Home Automation 1.2 network if and when newer devices support Zigbee 3.0 profiles?

If I understand it correctly, some of not all newer Zigbee Stacks support Zigbee 3.0 (Z3.0) network forming which allow a Zigbee network formed which support multiple profiles at the same time, allowing Zigbee 3.0 devices to connect using a Zigbee 3.0 profile, Zigbee Light Link 1.x devices can connect using a ZLL 1.0 profile, and Zigbee Home Automation 1.2 devices can connect using a ZHA 1.2 profile, or?

• Zigbee Cluster Library (ZCL) v7
• Zigbee PRO 2017 (R22)
• Child device management
• Base Device Behavior (BDB)
• Green Power

I know that bellows radio library just very recently got support for the later EZSP API versions used Silicon Labs EmberZNet Zigbee Stack firmware that supports Zigbee 3.0 and the zigpy-znp radio library supports the newer Texas Instruments chips use Z-Stack 3.0 Zigbee Stack firmware which all do support Zigbee 3.0 standard.

https://www.silabs.com/community/wireless/zigbee-and-thread/knowledge-base.entry.html/2018/04/24/how_to_form_zigbee3-zrzB

https://www.silabs.com/documents/public/application-notes/an1117-migrating-zigbee-profiles-to-z30.pdf

"At the core of Zigbee 3.0 is the Zigbee PRO 2017 (R22). Note that previously Zigbee Pro 2015 (R21) was required for Zigbee 3.0, which has now been replaced with the newer Zigbee Pro 2017 (R22) specification. Older implementation based on the R21 specification are still compatible with the new R22 specification. The Zigbee PRO Specification adds child device management, improved security features, and new network topology options to Zigbee networks. Commissioning devices into networks has also been improved and made more consistent through Base Device Behavior (BDB). Zigbee 3.0 furthermore requires Green Power Basic Proxy v1.1.1 functionality in all devices to further support Green Power capabilities and compiles all profile clusters into a single specification, Zigbee Cluster Library (ZCL) v7. Finally, it formalizes common Zigbee device application architecture nomenclature, expands on the Zigbee Lighting & Occupancy Device Specification, and comments towards Zigbee 3.0 certification. The following sections address each of these attributes."

https://www.ti.com/lit/swra615

PS: Previous versions of Silicon Labs firmware was also Zigbee PRO compatible, and the core of the Zigbee 3.0 standard is based on the Zigbee PRO 2015 specification, while the core of the Zigbee 3.1 standard will be based on the based on the Zigbee PRO 2017 specification.

[REQUEST] Feature for "backup and restore" to migrate from one Zigbee coordinator HW adapter to other hardware?

This idea came from developer discussion between @Adminiuga & @puddly in #10

Would it be possible to script a "backup and restore" migration feature/function built into zigpy radio libraries that allow users to relatively easily migrate from one Zigbee coordinator hardware adapter to a other Zigbee coordinator hardware adapter if use same radio library and maybe even if they are not using the exact same hardware MCU chip model/module?

Migrations such as these could become common as new more powerful adapters become available:

• LAUNCHXL-CC26X2R1 development board -> ZZH (Zig-a-zig-ah!) CC2652R based adapter
• LAUNCHXL-CC1352P-2 development board -> ZZH (Zig-a-zig-ah) CC2652R based adapter
• ZZH (Zig-a-zig-ah) CC2652R based adapter -> ZZH-P (Zig-a-zig-ah "P") CC2652P based adapter
• LAUNCHXL-CC26X2R1 development board -> LAUNCHXL-CC1352P-2 development board
• Any CC2652R based adapter hardware -> Any CC2652P based adapter hardware
• Any CC2652R based adapter hardware -> Any CC1352P based adapter hardware

Would be a more awesome feature if could also migrate from older TI chips to newer TI chips:

• Any CC2530 based adapter hardware -> Any CC2652 or CC1352 based adapter hardware
• Any CC2531 based adapter hardware -> Any CC2652 or CC1352 based adapter hardware
• Any CC2538 based adapter hardware -> Any CC2652 or CC1352 based adapter hardware

Would really be an awesome feature to have if could be made user-friendly for integration like ZHA!

Wrong device status

When I e.g. manually operate my outlet plug by pressing the physical button to toggle one-off (I.e. Innr SP120, but don't think it matters much), the state change isn't propagated back to home assistant.
I'm new using ZHA with a CC2531 adapter, but on a HUE Bridge the state is updated after a while (not instantly, so status is most likely polled).

[REQUEST] Capability to handle serial-port disconnects and reconnects

It is possible to implement some type of handling of serial port disconnects and reconnects?

I think that you can test this by unplugging the Zigbee coordinator adapter and then plug it back in after a minute to two.

Point is that zigpy-znp as well as all other radio libraries for zigpy should somehow always be able to reconnect and recover connection after reconnecting.

My main reason for that is when using ser2net and socat to use serial device over the network.

Problem is if the network temporarily goes down then it can not reconnect to recover the connection.

This is a relatively common networked setup if don't want the radio close to Home Assistant, see:

https://www.zigbee2mqtt.io/how_tos/how_to_connect_to_a_remote_adapter.html

A real-world scenario would be if you have Home Assistant and running on a virtual machine on your NAS with UPS-backup-power-supply but have your Zigbee coordinator adapter installed somewhere else in your house on a Raspberry Pi without UPS-backup-power-supply then a power-outage will cause the Raspberry Pi to reboot and maybe also any network switch that you have in between.

I think that preferable it should be able to try to recover at least once every 60-seconds and that recovery should still be possible after as much as 10-minutes (or more) because that is reasonably how long a reboot can take after a short power outage.

Another problem scenario is if the user accidentally unplugs the Zigbee USB adapter when running, as seen in related issue:

zigpy/zigpy-cc#15

References:

https://community.home-assistant.io/t/add-network-protocol-support-to-zigbee-and-zwave-integrations/136056

Danielhiversen/pyRFXtrx#85

zigpy/bellows#183

zigpy/zigpy#297

Custom Z-Stack builds

Right now the recommended firmwares are pre-compiled Z-Stack builds from zigbee2mqtt, which themselves have just a few minor config changes and one actual modified line of code (that may not even be necessary?).

The primary motivation for this feature is removing the ZDO translation layer that intercepts and rewrites ZDO responses. Working around this limitation requires quite a bit of extra code to get zigpy's ZDO requests working properly and needlessly separates the adapter from the Zigbee network.

Checklist:

• Write a COMPILING.md file describing how to at least setup the graphical dev environment.
• Replace the graphical environment with standard Makefiles. This might be difficult because the configuration is in part handled by a graphical tool, but the config file it generates seems to be human-readable and editable.
• Get rid of the ZDO translation code (I believe it's a single configuration flag) or possibly make it configurable at runtime, allowing the firmware to be used with other projects that assume the ZDO layer still exists.
• Allow low-level network configuration that was previously only possible at compile-time. Namely, things related to the Trust Center. Configuring the current channel (not just the mask) also might be possible by directly writing to the NIB stored in NVRAM but I have not tested it and it seems like this would need more supporting code on the microcontroller itself.

[HW RECOMMENDATIONS] CC1352P-2 verses CC26X2R1 (CC2652/CC2652P) verses CC2652R/CC2652RB-based Zig-a-zig-ah?

What hardware would you recommend someone to buy for Z-Stack 3.x Zigbee coordinator firmware?

• https://github.com/Koenkk/Z-Stack-firmware/tree/master/coordinator

Personally I am low on funds right now so thinking of just waiting for someone like Electrolama to start mass-producing and selling plug-and-play CC2652-based adapters such as their Zig-a-zig-ah ("ZZH") USB-stick at a lower price, but what hardware would you recommend today to someone who has enough funds now and is not willing to wait?

There are quite a few to choose from in Texas Instruments current SimpleLink multi-standard family:

http://www.ti.com/wireless-connectivity/simplelink-solutions/multi-standard/products.html

It looks like most people in the Zigbee2mqtt community who has made the lead is currently recommending the slightly more expensive CC13x2 based LAUNCHXL-CC1352P-2 development kit over the CC26x2 based LAUNCHXL-CC26X2R1 development kit for a number of reasons, though mainly because CC1352P-2 has a built-in RF-amplifier (PA/LNA) frontend as well as an SMA-connector for an external antenna and therefore has a much better link quality (people are even complaining that LAUNCHXL-CC26X2R1 has worse link quality than a CC2531 with an external antenna).

• Koenkk/zigbee2mqtt#1429
  • https://zigbee2mqtt.discourse.group/t/cc1352p-ore-cc26x2r/488/2

LAUNCHXL-CC1352P-2

• +1: Has a built-in RF-amplifier (PA/LNA) frontend for potentially better range (assuming Zigbee2mqtt will support enablement - enhancement is raised). RF design includes a shield.
• +1: Has a built-in SMA antenna connector (although it's still necessary to de/re-solder a tiny SMD capacitor switch from PCB antenna to SMA. Should provide an increase in range.
• +1: Can support sub 1GHz - opening the possibility for 868MHz (EU) and 915MHz (NA) Zigbee for better range (technically possible but no idea how many end devices support it) and possibly other applications in the future… IMO this “benefit” should not be a consideration at the point.
• -1: Bigger PCB (~2cm) than the CC26X2R1
• -1: A little ($10) more expensive than the CC26X2R1
  There are two versions with different RF suitability - The P-2 version favours 2.4GHz rather than sub 1GHz and this would be the recommended version to obtain for Zigbee2mqtt
• +1: STL for 3D printed case here: https://www.thingiverse.com/thing:3928171

LAUNCHXL-CC26X2R1

• +1: Seems to be the preferred board on this thread (maybe we need a poll?)
• +1: Slightly smaller PCB than the CC1352P
• +1: A little cheaper than the CC1352P and more sellers than just TI.
• +1: There is an STL for 3D printed case: https://www.thingiverse.com/thing:3305478
• +1: Another STL for 3D printed case here: https://www.thingiverse.com/thing:3928171
• -1: Theoretically less range than CC1352P due to lack of RF-amplifier (PA/LNA) frontend
• -1: Possibility to use external antenna (if de/re-solder the tiny SMD capacitor) but that requires a JSC-SMA antenna adaptor which is not cheap (~20 euros)
• -1: No support for sub-1GHz but there is no clear advantage of this currently

Other notes:

• There does not yet appear to be any more economical options from online China retailers like Aliexpress, etc. for either of these.
• Both have built-in JTAG programmer so no need for an external programmer

Migration CC2531 to CC2652R (zzh) inside LXC

He, first of all, great tool.
I was just about to migrate from my CC2531 to a new zzh stick and in time saw your tool that could simplify the migration a lot.
Currently, I am running zigbee2mqtt inside a Proxmox LXC and passed-through my USB devices.
Both show up under lsusb in /dev/ttyACM0 (CC2531) and /dev/ttyUSB0 (CC2652R).
I can also do the initial backup of the CC2531 and the backup file is generated using the following command:

sudo python3 -m zigpy_znp.tools.network_backup /dev/ttyACM0 -o network_backup.json

Now when I try to restore the backup config to /dev/ttyUSB0 I get an error message though as following (with -v enabled):

sudo python3 -m zigpy_znp.tools.network_restore /dev/ttyUSB0 -i network_backup.json -v

The zzh stick seems to work correctly as when I run the test.py script it returns the following:

Got 7 bytes in response to PING command: b'\xfe\x02a\x01Y\x06='
PASS|OK

Any advice on how to fix this?

Devices become unavailable but come back after restarting Controller (or bulb)

I am using ZHA in Home Assistant and "quite frequently" (every few days) have bulbs that seem to be unresponsive. They show up as unavailable in HA and do not seem to respond to any Cluster Commands.

I always thought it's the bulbs fault and simply restarted the bulb by power cycling it.
But I noticed that often it also works to restart the controller (I am using a Lauch XL Cc1352-P; I believe).

This makes me believe that the issue could actually be fixed in Ziggy.
Any help on how I can approach fixing this is appreciated.

[SUGGESTION] Team up with Electrolama to beta-test their new zzhp, zzhp-lite, and zoe2 adapters

Can I suggest that zigpy developers reach out to Omer Kilic a.k.a. @omerk at Electrolama about teaming up to alpha/beta-test and reference-test his upcoming zzh-p / zzh-p lite (CC2652P USB) and zoe2 (CC1352P shield) adapters together with zigpy-znp/zigpy-cc?

He previously mentioned that you can reach him on ([myfirstname]@electrolama.com) if you would like to test prototype hardware.

electrolama/zig-a-zig-ah#5

BTW, it is known that Koenkk from the zigbee2mqtt project has been testing those newer upcoming adapters with zigbee-herdsman:

https://github.com/Koenkk/Z-Stack-firmware/tree/develop/coordinator/Z-Stack_3.x.0/bin

For your information @omerk also announced that he is working on an optional Zigbee router firmware for his and zzhp adapters:

https://github.com/electrolama/zzh-router

I understand both Electrolama and zigpy are only spare-time hobby projects but I still think that teaming up might give both projects some positive recognition if ZHA for Home Assistant listed those as supported and that in turn might attract more developers and willing alpha/beta-testers from the community to come to help out with all those open source projects which in the long run could benefit all users wanting Zigbee in home automation software to become more mature and working out-of-the-box with an even wider range of available hardware than it is today.

https://electrolama.com/projects/zig-a-zig-ah/

https://github.com/electrolama/zig-a-zig-ah

https://electrolama.com/projects/zoe/

https://github.com/electrolama/zoe

CC2652P is similar to CC2652R but with a built-in RF Power-Amplifier (but for whatever reason the CC2652P is not pin compatible nor firmware compatible with CC2652R/CC2652RB).

CC1352P is CC1352R with a built-in RF PA, both being sub-1GHz and 2.4GHz wireless MCU (so essentially CC2652P with an extra sub-1GHz radio so that can use frequency ranges like 868MHz in Europe or 908MHz and 915MHz/916MHz in North America for Zigbee Smart Energy Specification Standard used by Zigbee based Smart Metering)

Unhandled Commands Warnings in Home Assistant Core

I've recently set up a new clean instance of Home Assistant with an Electrolama zzh! (TI CC2652R) plugged in to a RPi4 but am receiving a fairly solid stream of unhandled command warnings (~1 per minute):

Logger: zigpy_znp.api
Source: /usr/local/lib/python3.8/site-packages/zigpy_znp/api.py:395
First occurred: 10:30:35 (27 occurrences)
Last logged: 10:54:44

Received an unhandled command: ZDO.ParentAnnceRsp.Callback(Src=0xE6FA, Status=<Status.SUCCESS: 0>, ChildInfo=[00:12:4b:00:1f:54:22:77, 00:12:4b:00:1f:54:4c:80])
Received an unhandled command: ZDO.ConcentratorInd.Callback(NWK=0xF0DD, IEEE=00:1e:5e:09:02:13:2a:28, PktCost=3)
Received an unhandled command: ZDO.ConcentratorInd.Callback(NWK=0xF0DD, IEEE=00:1e:5e:09:02:13:2a:28, PktCost=1)
Received an unhandled command: ZDO.MgmtNWKUpdateNotify.Callback(Src=0xE6FA, Status=<Status.SUCCESS: 0>, ScannedChannels=<Channels.ALL_CHANNELS: 134215680>, TotalTransmissions=24, TransmissionFailures=7, EnergyValues=[167, 183, 162, 160, 170, 162, 173, 166, 174, 162, 164, 194, 182, 181, 169, 183])

Please advise if this is a problem with the configuration, or 'expected' behaviour?

Error doing job: Task exception was never retrieved

I've been getting the following exceptions from zigpy_znp, using a zzh! in Home Assistant 2021.6.4:

Logger: homeassistant
Source: /usr/src/homeassistant/homeassistant/runner.py:97 
First occurred: 4:55:17 PM (5 occurrences) 
Last logged: 4:56:33 PM

Error doing job: Task exception was never retrieved
Traceback (most recent call last):
  File "/usr/local/lib/python3.8/site-packages/zigpy_znp/api.py", line 563, in request_callback_rsp
    return await callback_rsp
asyncio.exceptions.CancelledError

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/usr/local/lib/python3.8/site-packages/zigpy_znp/api.py", line 563, in request_callback_rsp
    return await callback_rsp
  File "/usr/local/lib/python3.8/site-packages/async_timeout/__init__.py", line 55, in __aexit__
    self._do_exit(exc_type)
  File "/usr/local/lib/python3.8/site-packages/async_timeout/__init__.py", line 92, in _do_exit
    raise asyncio.TimeoutError
asyncio.exceptions.TimeoutError

It's not clear to me from the logs if a specific device is causing this, or how to trace this back to a specific device or command. If I'm reading correctly at https://docs.python.org/3/library/asyncio-dev.html#detect-never-retrieved-exceptions, it seems like there's an underlying exception that's not being awaited on. What I'm not clear about is if this should be done in this library or somewhere further up the stack. Any suggestions on how to debug this further?

Supporting older radios

While the faster and more powerful radios are easier to use, supporting older hardware probably won't be too difficult and will make this project more accessible.

Implementing an abstraction layer on top of the existing command sets will also solve a couple of glitches with compile-time options changing the behavior of a couple of commands.

I've purchased a cheap CC2531 module for $4 so I will give this a try when it arrives next week.

[REQUEST] ZGP (Zigbee Green Power) with zigpy-znp and Texas Instruments Z-Stack 3

@puddly Requesting support for ZGP (Zigbee Green Power) using zigpy-znp with Texas Instruments Z-Stack 3 Zigbee coordinator.

FYI, @zoic21 is trying to implement ZGP (Zigbee Green Power) device support into zigpy, however wrote that is only developing it using bellows and zigpy-deconz as he currently has no coordinator for zigpy-znp. See -> zigpy/zigpy#519 and zigpy/zigpy#656

PS: zoic21 is currently using EnOcean PTM 215ZE (PTM215ZE) based ZGP switch as reference but it should maybe be noted that it looks like the newer EnOcean PTM 216Z (PTM216Z) might be more common use, please see -> zigpy/zha-device-handlers#478

PPS: There is more info about ZGP (Zigbee Green Power) and devices supporting it in the zigpy request -> zigpy/zigpy#341

After permitting new joins for 60s, network remains opened

Here's log. Removing the device, but it immediately joins back:

2020-05-10 22:06:17 DEBUG (MainThread) [zigpy_znp.api] Received command: ZDO.LeaveInd.Callback(NWK=0xaa8f, IEEE=7c:b0:3e:aa:00:a5:e4:7f, Request=<Bool.false: 0>, Remove=<Bool.true: 1>, Rejoin=<Bool.false: 0>)
2020-05-10 22:06:17 INFO (MainThread) [zigpy_znp.zigbee.application] ZDO device left: ZDO.LeaveInd.Callback(NWK=0xaa8f, IEEE=7c:b0:3e:aa:00:a5:e4:7f, Request=<Bool.false: 0>, Remove=<Bool.true: 1>, Rejoin=<Bool.false: 0>)
2020-05-10 22:06:17 INFO (MainThread) [zigpy.application] Device 0xaa8f (7c:b0:3e:aa:00:a5:e4:7f) left the network
2020-05-10 22:06:20 DEBUG (MainThread) [zigpy_znp.api] Received command: ZDO.TCDevInd.Callback(SrcNwk=0x66d6, SrcIEEE=7c:b0:3e:aa:00:a5:e4:7f, ParentNwk=0x0000)
2020-05-10 22:06:20 INFO (MainThread) [zigpy_znp.zigbee.application] ZDO device join: ZDO.TCDevInd.Callback(SrcNwk=0x66d6, SrcIEEE=7c:b0:3e:aa:00:a5:e4:7f, ParentNwk=0x0000)
2020-05-10 22:06:20 INFO (MainThread) [zigpy.application] Device 0x66d6 (7c:b0:3e:aa:00:a5:e4:7f) joined the network
2020-05-10 22:06:20 DEBUG (MainThread) [zigpy.application] Device 7c:b0:3e:aa:00:a5:e4:7f changed id (0xaa8f => 0x66d6)
2020-05-10 22:06:20 ERROR (MainThread) [homeassistant.core] Error doing job: Task exception was never retrieved
Traceback (most recent call last):
  File "/home/lex/.venv/hass-zigpy/lib/python3.7/site-packages/zigpy/device.py", line 77, in group_membership_scan
    await ep.group_membership_scan()
  File "/home/lex/.venv/hass-zigpy/lib/python3.7/site-packages/zigpy/endpoint.py", line 149, in group_membership_scan
    res = await self.groups.get_membership([])
  File "/home/lex/.venv/hass-zigpy/lib/python3.7/site-packages/zigpy/device.py", line 188, in request
    use_ieee=use_ieee,
  File "/home/lex/.venv/hass-zigpy/lib/python3.7/site-packages/zigpy_znp/zigbee/application.py", line 608, in request
    data=data,
  File "/home/lex/.venv/hass-zigpy/lib/python3.7/site-packages/zigpy_znp/zigbee/application.py", line 566, in _send_request
    partial=True, Endpoint=dst_ep, TSN=sequence
  File "/home/lex/.venv/hass-zigpy/lib/python3.7/site-packages/zigpy_znp/api.py", line 333, in request_callback_rsp
    await response
  File "/home/lex/.venv/hass-zigpy/lib/python3.7/site-packages/zigpy_znp/api.py", line 317, in request
    f"Expected SRSP response {partial_response}, got {response}", response
zigpy_znp.exceptions.InvalidCommandResponse: Expected SRSP response AF.DataRequestExt.Rsp(Status=<Status.Success: 0>), got AF.DataRequestExt.Rsp(Status=<Status.InvalidParameter: 2>)
2020-05-10 22:06:20 DEBUG (MainThread) [zigpy.device] Canceling old initialize call
2020-05-10 22:06:20 DEBUG (MainThread) [zigpy_znp.api] Sending request: AF.DataRequestExt.Req(DstAddrModeAddress=AddrModeAddress(mode=<AddrMode.NWK: 2>, address=0x66d6), DstEndpoint=3, DstPanId=0x0000, SrcEndpoint=3, ClusterId=4, TSN=72, Options=<TransmitOptions.RouteDiscovery: 32>, Radius=30, Data=b'\x01\x48\x02\x00')
2020-05-10 22:06:20 DEBUG (MainThread) [zigpy_znp.api] Sending request: AF.DataRequestExt.Req(DstAddrModeAddress=AddrModeAddress(mode=<AddrMode.NWK: 2>, address=0x66d6), DstEndpoint=3, DstPanId=0x0000, SrcEndpoint=3, ClusterId=0, TSN=73, Options=<TransmitOptions.RouteDiscovery: 32>, Radius=30, Data=b'\x00\x49\x00\x04\x00\x05\x00')
2020-05-10 22:06:20 DEBUG (MainThread) [zigpy_znp.api] Received command: AF.DataRequestExt.Rsp(Status=<Status.InvalidParameter: 2>)
2020-05-10 22:06:20 DEBUG (MainThread) [zigpy_znp.api] Received command: AF.DataRequestExt.Rsp(Status=<Status.InvalidParameter: 2>)
2020-05-10 22:06:20 DEBUG (MainThread) [zigpy_znp.api] Received command: ZDO.EndDeviceAnnceInd.Callback(Src=0x66d6, NWK=0x66d6, IEEE=7c:b0:3e:aa:00:a5:e4:7f, Capabilities=<MACCapabilities.AllocateShortAddrDuringAssocNeeded|RXWhenIdle|MainsPowered|Router: 142>)
2020-05-10 22:06:20 INFO (MainThread) [zigpy_znp.zigbee.application] ZDO device announce: ZDO.EndDeviceAnnceInd.Callback(Src=0x66d6, NWK=0x66d6, IEEE=7c:b0:3e:aa:00:a5:e4:7f, Capabilities=<MACCapabilities.AllocateShortAddrDuringAssocNeeded|RXWhenIdle|MainsPowered|Router: 142>)
2020-05-10 22:06:20 INFO (MainThread) [zigpy.application] Device 0x66d6 (7c:b0:3e:aa:00:a5:e4:7f) joined the network
2020-05-10 22:06:20 DEBUG (MainThread) [zigpy.application] Skip initialization for existing device 7c:b0:3e:aa:00:a5:e4:7f
2020-05-10 22:06:20 ERROR (MainThread) [homeassistant.core] Error doing job: Task exception was never retrieved
Traceback (most recent call last):
  File "/home/lex/.venv/hass-zigpy/lib/python3.7/site-packages/zigpy/device.py", line 77, in group_membership_scan
    await ep.group_membership_scan()
  File "/home/lex/.venv/hass-zigpy/lib/python3.7/site-packages/zigpy/endpoint.py", line 149, in group_membership_scan
    res = await self.groups.get_membership([])
  File "/home/lex/.venv/hass-zigpy/lib/python3.7/site-packages/zigpy/device.py", line 188, in request
    use_ieee=use_ieee,
  File "/home/lex/.venv/hass-zigpy/lib/python3.7/site-packages/zigpy_znp/zigbee/application.py", line 608, in request
    data=data,
  File "/home/lex/.venv/hass-zigpy/lib/python3.7/site-packages/zigpy_znp/zigbee/application.py", line 566, in _send_request
    partial=True, Endpoint=dst_ep, TSN=sequence
  File "/home/lex/.venv/hass-zigpy/lib/python3.7/site-packages/zigpy_znp/api.py", line 333, in request_callback_rsp
    await response
  File "/home/lex/.venv/hass-zigpy/lib/python3.7/site-packages/zigpy_znp/api.py", line 317, in request
    f"Expected SRSP response {partial_response}, got {response}", response
zigpy_znp.exceptions.InvalidCommandResponse: Expected SRSP response AF.DataRequestExt.Rsp(Status=<Status.Success: 0>), got AF.DataRequestExt.Rsp(Status=<Status.InvalidParameter: 2>)
2020-05-10 22:06:20 DEBUG (MainThread) [zigpy_znp.api] Sending request: AF.DataRequestExt.Req(DstAddrModeAddress=AddrModeAddress(mode=<AddrMode.NWK: 2>, address=0x66d6), DstEndpoint=3, DstPanId=0x0000, SrcEndpoint=3, ClusterId=4, TSN=74, Options=<TransmitOptions.RouteDiscovery: 32>, Radius=30, Data=b'\x01\x4A\x02\x00')
2020-05-10 22:06:20 DEBUG (MainThread) [zigpy_znp.api] Received command: AF.DataRequestExt.Rsp(Status=<Status.InvalidParameter: 2>)
2020-05-10 22:06:27 DEBUG (MainThread) [homeassistant.components.zha.core.channels.base] [0xfab6:1:0x0b04]: async_update

[SUGGESTION] Team up with Electrolama to beta-test the "Zig-a-zig-ah!" CC2652 adapter

@Adminiuga & @puddly Can I suggest that you try to reach out to Omer Kilic a.k.a. @omerk at Electrolama about teaming up to beta-test his "Zig-a-zig-ah!" CC2652 adapter together with zigpy-znp for ZHA in Home Assistant?

https://electrolama.com/projects/zig-a-zig-ah/

https://github.com/electrolama/zig-a-zig-ah

As I understand both zig-a-zig-ah and zigpy-znp are only spare-time hobby projects but still I think that teaming up might give both projects some positive recognition in the Home Assistant community which might attract more developers and willing alpha/beta-testers from the community to come help out with both these projects which in the long run could benefit all users wanting ZHA to become more mature and working with more hardware than today.

https://www.home-assistant.io/components/zha/

Would also be nice to see collaboration with the guys working on zigpy-cc as an alternative

https://github.com/sanyatuning/zigpy-cc/

Tag release versions and make PyPi release(s) of zigpy-znp?

A friendly reminder to tag an initial release version of zigpy-znp and make PyPi release of zigpy-znp

@Adminiuga I guess that you might not yet be ready to make your first release of this zigpy-znp library but I just wanted to add a friendly reminder here under issues for tracking purposes only, so there is no rush.

An initial PyPi release version tag (like for example v0.0.1) and then continues versions/releases of newer version if and when code is added or changed will make it much easier for projects like Home Assistant and Linux OS distributions like Hass.io and Raspbian or others to update and make use of each new versions of this library.

Version tagging and PyPi release(s) is something that is already available for the zigpy library as well as similar radio libraries that it depends on such as; bellows, zigpy-deconz, zigpy-xbee, zigpy-zigate, and zigpy-cc. My thinking is that the more people are testing this early on then more developers will eventually also get interested and will be able to help you out with the development of zigpy-znp

https://github.com/zigpy/zigpy/releases
https://github.com/zigpy/bellows/releases
https://github.com/zigpy/zigpy-xbee/releases
https://github.com/zigpy/zigpy-deconz/releases
https://github.com/doudz/zigpy-zigate/releases
https://github.com/sanyatuning/zigpy-cc/releases

https://pypi.org/project/zigpy
https://pypi.org/project/bellows
https://pypi.org/project/zigpy-xbee
https://pypi.org/project/zigpy-deconz
https://pypi.org/project/zigpy-zigate
https://pypi.org/project/zigpy-cc

Off-topic but have you considerd maybe move this zigpy-znp repository to a GitHub repo under the zigpy organization @ https://github.com/zigpy/ so that more than one person has access to all your zigpy related projects for collaboration as well as having a greater chance of getting noticed by new developers who might be willing to help out?

How to test

I just got a zzh board, and was wondering if I could help test out zigpy-znp with it in a test ha box I have. Are there any instructions on using zigpy-znp to set up a network vs the default zigpy-cc?

Incorrectly neighbor parse on ZDOCmd.Mgmt_Lqi_req (Z-Stack bug ?)

• Coordinator : LAUNCHXL-CC26xR1, FW CC2652R_coordinator_20210120.zip, IEEE: 00:12:4b:00:21:9f:c1:f9, NWK: 0
• End device : Danfoss Ally, IEEE 84:2e:14:ff:fe:5e:50:10, NWK: 0x020C

I'm investigating this issue zigpy/zigpy#565 and found after a coordinator rset the neighbor table is wrong.

DEBUG:zigpy.util:Tries remaining: 3
DEBUG:zigpy_znp.zigbee.application:Intercepted a ZDO request: dst_addr=AddrModeAddress(mode=<AddrMode.NWK: 2>, address=0x0000), dst_ep=0, src_ep=0, cluster=ZDOCmd.Mgmt_Lqi_req, sequence=5, options=TransmitOptions.SUPPRESS_ROUTE_DISC_NETWORK|ACK_REQUEST, radius=30, data=b'\x05\x00'
DEBUG:zigpy_znp.zigbee.application:Intercepted AP ZDO request ZDOCmd.Mgmt_Lqi_req({'StartIndex': 0}) and replaced with ZDO.MgmtLqiReq.Req(Dst=0x0000, StartIndex=0)
DEBUG:zigpy_znp.api:Sending request: ZDO.MgmtLqiReq.Req(Dst=0x0000, StartIndex=0)
DEBUG:zigpy_znp.api:Received command: ZDO.MgmtLqiReq.Rsp(Status=<Status.SUCCESS: 0>)
DEBUG:zigpy_znp.api:Received command: ZDO.MgmtLqiRsp.Callback(Src=0x0000, Status=<Status.SUCCESS: 0>, Neighbors=Neighbors(entries=1, start_index=0, neighbor_table_list=[Neighbor(extended_pan_id=75:2f:df:c4:34:62:d5:ae, ieee=14:ff:fe:5e:50:10:02:0c, nwk=0x842E, packed=18, permit_joining=<PermitJoins.Unknown: 2>, depth=1, lqi=170)]))
DEBUG:zigpy_znp.zigbee.application:Pretending we received a ZDO message: b'\x05\x00\x01\x00\x01\xAE\xD5\x62\x34\xC4\xDF\x2F\x75\x0C\x02\x10\x50\x5E\xFE\xFF\x14\x2E\x84\x12\x02\x01\xAA'
DEBUG:zigpy.neighbor:[0x0000] request status: Status.SUCCESS. response: Neighbors(entries=1, start_index=0, neighbor_table_list=[Neighbor(extended_pan_id=75:2f:df:c4:34:62:d5:ae, ieee=14:ff:fe:5e:50:10:02:0c, nwk=0x842E, packed=18, permit_joining=<PermitJoins.Unknown: 2>, depth=1, lqi=170)])
DEBUG:zigpy.neighbor:[0x0000] Done scanning. Total 1 neighbours

We can see IEEE is mixed with NWK.

Sometimes there are 2 items, the 2nd is correct

DEBUG:zigpy.util:Tries remaining: 3
DEBUG:zigpy_znp.zigbee.application:Intercepted a ZDO request: dst_addr=AddrModeAddress(mode=<AddrMode.NWK: 2>, address=0x0000), dst_ep=0, src_ep=0, cluster=ZDOCmd.Mgmt_Lqi_req, sequence=3, options=TransmitOptions.SUPPRESS_ROUTE_DISC_NETWORK|ACK_REQUEST, radius=30, data=b'\x03\x00'
DEBUG:zigpy_znp.zigbee.application:Intercepted AP ZDO request ZDOCmd.Mgmt_Lqi_req({'StartIndex': 0}) and replaced with ZDO.MgmtLqiReq.Req(Dst=0x0000, StartIndex=0)
DEBUG:zigpy_znp.api:Sending request: ZDO.MgmtLqiReq.Req(Dst=0x0000, StartIndex=0)
DEBUG:aiosqlite:executing functools.partial(<built-in method execute of sqlite3.Connection object at 0x05E6E0A8>, 'DELETE FROM neighbors WHERE device_ieee = ?', (84:2e:14:ff:fe:5e:50:10,))
DEBUG:aiosqlite:operation functools.partial(<built-in method execute of sqlite3.Connection object at 0x05E6E0A8>, 'DELETE FROM neighbors WHERE device_ieee = ?', (84:2e:14:ff:fe:5e:50:10,)) completed
DEBUG:zigpy_znp.api:Received command: ZDO.MgmtLqiReq.Rsp(Status=<Status.SUCCESS: 0>)
DEBUG:aiosqlite:executing functools.partial(<built-in method executemany of sqlite3.Connection object at 0x05E6E0A8>, 'INSERT INTO neighbors VALUES (?, ?, ?, ?, ?, ?, ?, ?)', [(84:2e:14:ff:fe:5e:50:10, 75:2f:df:c4:34:62:d5:ae, 00:12:4b:00:21:9f:c1:f9, 0x0000, 4, <PermitJoins.Unknown: 2>, 0, 252)])
DEBUG:zigpy_znp.api:Received command: ZDO.MgmtLqiRsp.Callback(Src=0x0000, Status=<Status.SUCCESS: 0>, Neighbors=Neighbors(entries=2, start_index=0, neighbor_table_list=[Neighbor(extended_pan_id=75:2f:df:c4:34:62:d5:ae, ieee=14:ff:fe:5e:50:10:02:0c, nwk=0x842E, packed=18, permit_joining=<PermitJoins.Unknown: 2>, depth=1, lqi=170), Neighbor(extended_pan_id=75:2f:df:c4:34:62:d5:ae, ieee=84:2e:14:ff:fe:5e:50:10, nwk=0x020C, packed=18, permit_joining=<PermitJoins.Unknown: 2>, depth=1, lqi=172)]))
DEBUG:aiosqlite:operation functools.partial(<built-in method executemany of sqlite3.Connection object at 0x05E6E0A8>, 'INSERT INTO neighbors VALUES (?, ?, ?, ?, ?, ?, ?, ?)', [(84:2e:14:ff:fe:5e:50:10, 75:2f:df:c4:34:62:d5:ae, 00:12:4b:00:21:9f:c1:f9, 0x0000, 4, <PermitJoins.Unknown: 2>, 0, 252)]) completed
DEBUG:zigpy_znp.zigbee.application:Pretending we received a ZDO message: b'\x03\x00\x02\x00\x02\xAE\xD5\x62\x34\xC4\xDF\x2F\x75\x0C\x02\x10\x50\x5E\xFE\xFF\x14\x2E\x84\x12\x02\x01\xAA\xAE\xD5\x62\x34\xC4\xDF\x2F\x75\x10\x50\x5E\xFE\xFF\x14\x2E\x84\x0C\x02\x12\x02\x01\xAC'
DEBUG:zigpy.neighbor:[0x0000] request status: Status.SUCCESS. response: Neighbors(entries=2, start_index=0, neighbor_table_list=[Neighbor(extended_pan_id=75:2f:df:c4:34:62:d5:ae, ieee=14:ff:fe:5e:50:10:02:0c, nwk=0x842E, packed=18, permit_joining=<PermitJoins.Unknown: 2>, depth=1, lqi=170), Neighbor(extended_pan_id=75:2f:df:c4:34:62:d5:ae, ieee=84:2e:14:ff:fe:5e:50:10, nwk=0x020C, packed=18, permit_joining=<PermitJoins.Unknown: 2>, depth=1, lqi=172)])
DEBUG:aiosqlite:executing functools.partial(<built-in method commit of sqlite3.Connection object at 0x05E6E0A8>)
DEBUG:zigpy.neighbor:[0x0000] Done scanning. Total 2 neighbours

ZDOCmd.Unbind_req not implemented (needed to unbind device from coordinator)

After home-assistant/core#42854 was merged, Home Assistant can now unbind a device from the Zigbee coordinator. This is required for a Philips Hue Dimmer Switch (RWL021) as they can only be bound to one group/device because of the binding table size being 1.
When trying this using a ZZH with zigpy-znp, the following is displayed in the (debug) logs:

2021-01-06 19:51:31 DEBUG (MainThread) [zigpy_znp.zigbee.application] Intercepted a ZDO request: dst_addr=AddrModeAddress(mode=<AddrMode.NWK: 2>, address=0x577A), dst_ep=0, src_ep=0, cluster=ZDOCmd.Unbind_req, sequence=203, options=TransmitOptions.SUPPRESS_ROUTE_DISC_NETWORK|ACK_REQUEST, radius=30, data=b'\xcb\xb7\xd6t\x08\x01\x88\x17\x00\x01\x08\x00\x03\xf5\xf3\xa5\xfe\xff\xcc\xcc\xcc\x01'
2021-01-06 19:51:31 ERROR (MainThread) [zigpy_znp.zigbee.application] ZDO converter for cluster ZDOCmd.Unbind_req has not been implemented! Please open a GitHub issue and attach a debug log: https://github.com/zigpy/zigpy-znp/issues/new
2021-01-06 19:51:31 DEBUG (MainThread) [zigpy.zdo] [0x577a:zdo] cluster: 6 Unbind_req --> [cc:cc:cc:ff:fe:a5:f3:f5] failed: No ZDO converter
2021-01-06 19:51:31 DEBUG (MainThread) [zigpy.zdo] [0x577a:zdo] cluster: 8 Unbind_req --> [cc:cc:cc:ff:fe:a5:f3:f5] failed: No ZDO converter
2021-01-06 19:51:31 INFO (MainThread) [homeassistant.components.zha.api] Devices un-bound: source_ieee: [00:17:88:01:08:74:d6:b7] target_ieee: [cc:cc:cc:ff:fe:a5:f3:f5]

It looks like the ZDOCmd.Unbind_req "command" isn't implemented in https://github.com/zigpy/zigpy-znp/blob/dev/zigpy_znp/zigbee/zdo_converters.py.

[PSA] Recommend upgrading Z-Stack 3 Coordinator firmware based on Texas Instruments Z-Stack 4.40.00.44 SDK?

Please see discussion and copy of PSA about critical bug and new firmware recommendation in zigpy/zigpy#655

Maybe update readme to recommend upgrade all Z-Stack 3 Coordinators to firmware based on TI Z-Stack SDK 4.40.00.44 or later?

The "develop" tree for Koenkk's Z-Stack-firmware repo now has updated firmware images:

https://github.com/Koenkk/Z-Stack-firmware/tree/master/coordinator/Z-Stack_3.x.0/bin

Note! Highly recommend that people backup NVRAM of Texas Instruments adapters with zigpy-znp before upgrading firmware:

https://github.com/zigpy/zigpy-znp#nvram

Tip! If done a backup of NVRAM before then can do a restore of NVRAM after if have any issues or need to downgrade later.

Z-Stack rejects joins through routers unless coordinator is also permitting joins

@TheJulianJES reported that joins done via specific devices do not work. I've confirmed this occurs with release 0.3.0 with multiple coordinators. The new device successfully associates through the target router but the coordinator kicks the new device off the network with an "APS remove device (0x07)" command instead of sending it the transport key.

Comparing the behavior of zigpy-znp and Z2M shows that the only difference is the following at startup:

• zigpy-znp sends: ZDO.MgmtPermitJoinReq.Req(AddrMode=<AddrMode.NWK: 2>, Dst=0x0000, Duration=0, TCSignificance=1)
• Z2M sends: ZDO.MgmtPermitJoinReq.Req(AddrMode=<AddrMode.Broadcast: 3>, Dst=0xFFFC, Duration=0, TCSignificance=0)

The first command is sent on startup by zigpy-znp to fix the CC2531 Z-Stack Home 1.2 permanently permitting joins glitch. Unfortunately, it appears that sending any unicast permit join request to 0x0000 causes it to stop permitting joins later on. Sending a broadcast to all routers and the coordinator does not trigger this behavior. I've confirmed this on all of my Texas Instruments coordinators so it's not just a Z-Stack Home 1.2 bug.

Since Home Assistant includes buttons to permit joins through specific routers as well as just the coordinator, I see two possible solutions:

1. Overload ControllerApplication.permit to always call ControllerApplication.permit_ncp as well. This has the unfortunate side effect of allowing new devices to join the coordinator directly as well as the desired router, which is not intuitive behavior.
2. Make ControllerApplication.permit_ncp a no-op in zigpy-znp and somehow disable the "add devices via this device" button in Home Assistant for the coordinator. Removing functionality is not ideal but all the visible buttons will do exactly what they say.

TypeError: unsupported operand type(s) for *: 'float' and 'NoneType'

2020-12-15 11:28:59 ERROR (MainThread) [homeassistant] Error doing job: Task exception was never retrieved
Traceback (most recent call last):
File "/usr/local/lib/python3.8/site-packages/zigpy_znp/zigbee/application.py", line 1351, in _discover_route
await asyncio.sleep(0.1 * self._nib.RouteDiscoveryTime)
TypeError: unsupported operand type(s) for *: 'float' and 'NoneType'

Seems like RouteDiscoveryTime is not initialized (yet).
Message pops up in the log when restarting HA. Please let me know if you need further information.
As far as I can tell there is no misbehavior caused by this error.

I'm running supervised Home Assistant 2020.12.0 using a LAUNCHXL-CC26X2R1

Thanks for having a look.

Unable to use zigpy-znp library with Z-Stack 3.0.x on CC2531 USB dongle

Hi,

I followed the zigpy-znp readme and I'm using a CC2531 based USB dongle with Z Stack 3.0.x coordinator firmware that I successfully flashed with TI SmartRF Flash Programmer. When I'm running the following script, I'm getting a TimeoutError exception.

• The dongle seems to not answers to the SYS_PING request sent by the library.

import asyncio

import logging

logging.basicConfig()
logging.root.setLevel(logging.DEBUG)


from zigpy_znp import config
from zigpy_znp.zigbee.application import ControllerApplication

APP_CONFIG = {
    config.CONF_DEVICE: {
        config.CONF_DEVICE_PATH: "COM6",
        config.CONF_DEVICE_BAUDRATE: 115200,
    },
}

async def main():
    app = ControllerApplication(APP_CONFIG)

    await app.startup(auto_form=True)

    await app.permit(60)
    await asyncio.sleep(60)

    await asyncio.get_running_loop().create_future()

if __name__ == "__main__":
    asyncio.run(main())

Python Console Log

DEBUG:asyncio:Using proactor: IocpProactor
DEBUG:zigpy_znp.uart:Connecting to COM6 at 115200 baud
DEBUG:zigpy_znp.uart:Opened COM6 serial port
DEBUG:zigpy_znp.uart:Toggling RTS/CTS to skip CC2652R bootloader
DEBUG:zigpy_znp.uart:Connected to COM6 at 115200 baud
DEBUG:zigpy_znp.api:Waiting 1s before sending anything
DEBUG:zigpy_znp.api:Sending bootloader skip byte
DEBUG:zigpy_znp.uart:Sending data: b'\xEF\xEF\xEF\xEF\xEF\xEF\xEF\xEF\xEF\xEF\xEF\xEF\xEF\xEF\xEF\xEF\xEF\xEF\xEF\xEF\xEF\xEF\xEF\xEF\xEF\xEF\xEF\xEF\xEF\xEF\xEF\xEF\xEF\xEF\xEF\xEF\xEF\xEF\xEF\xEF\xEF\xEF\xEF\xEF\xEF\xEF\xEF\xEF\xEF\xEF\xEF\xEF\xEF\xEF\xEF\xEF\xEF\xEF\xEF\xEF\xEF\xEF\xEF\xEF\xEF\xEF\xEF\xEF\xEF\xEF\xEF\xEF\xEF\xEF\xEF\xEF\xEF\xEF\xEF\xEF\xEF\xEF\xEF\xEF\xEF\xEF\xEF\xEF\xEF\xEF\xEF\xEF\xEF\xEF\xEF\xEF\xEF\xEF\xEF\xEF\xEF\xEF\xEF\xEF\xEF\xEF\xEF\xEF\xEF\xEF\xEF\xEF\xEF\xEF\xEF\xEF\xEF\xEF\xEF\xEF\xEF\xEF\xEF\xEF\xEF\xEF\xEF\xEF\xEF\xEF\xEF\xEF\xEF\xEF\xEF\xEF\xEF\xEF\xEF\xEF\xEF\xEF\xEF\xEF\xEF\xEF\xEF\xEF\xEF\xEF\xEF\xEF\xEF\xEF\xEF\xEF\xEF\xEF\xEF\xEF\xEF\xEF\xEF\xEF\xEF\xEF\xEF\xEF\xEF\xEF\xEF\xEF\xEF\xEF\xEF\xEF\xEF\xEF\xEF\xEF\xEF\xEF\xEF\xEF\xEF\xEF\xEF\xEF\xEF\xEF\xEF\xEF\xEF\xEF\xEF\xEF\xEF\xEF\xEF\xEF\xEF\xEF\xEF\xEF\xEF\xEF\xEF\xEF\xEF\xEF\xEF\xEF\xEF\xEF\xEF\xEF\xEF\xEF\xEF\xEF\xEF\xEF\xEF\xEF\xEF\xEF\xEF\xEF\xEF\xEF\xEF\xEF\xEF\xEF\xEF\xEF\xEF\xEF\xEF\xEF\xEF\xEF\xEF\xEF\xEF\xEF\xEF\xEF\xEF\xEF\xEF\xEF\xEF\xEF\xEF\xEF'
DEBUG:zigpy_znp.api:Waiting 1s or until a reset indication is received
DEBUG:zigpy_znp.api:Creating one-shot listener OneShotResponseListener(matching_commands=(SYS.ResetInd.Callback(Reason=None, TransportRev=None, ProductId=None, MajorRel=None, MinorRel=None, MaintRel=None),), future=<Future pending>)
DEBUG:zigpy_znp.api:Removing listener OneShotResponseListener(matching_commands=(SYS.ResetInd.Callback(Reason=None, TransportRev=None, ProductId=None, MajorRel=None, MinorRel=None, MaintRel=None),), future=<Future cancelled>)
DEBUG:zigpy_znp.api:Cleaning up empty listener list for header CommandHeader(id=0x80, subsystem=Subsystem.SYS, type=CommandType.AREQ)
DEBUG:zigpy_znp.api:There are 0 callbacks and 0 one-shot listeners remaining
DEBUG:zigpy_znp.api:Testing connection to COM6
DEBUG:zigpy_znp.api:Sending request: SYS.Version.Req()
DEBUG:zigpy_znp.api:Creating one-shot listener OneShotResponseListener(matching_commands=(SYS.Version.Rsp(TransportRev=None, ProductId=None, MajorRel=None, MinorRel=None, MaintRel=None, CodeRevision=None, BootloaderBuildType=None, BootloaderRevision=None), RPCError.CommandNotRecognized.Rsp(ErrorCode=None, RequestHeader=CommandHeader(id=0x02, subsystem=Subsystem.SYS, type=CommandType.SREQ))), future=<Future pending>)
DEBUG:zigpy_znp.uart:Sending data: b'\xFE\x00\x21\x02\x23'
DEBUG:zigpy_znp.api:Removing listener OneShotResponseListener(matching_commands=(SYS.Version.Rsp(TransportRev=None, ProductId=None, MajorRel=None, MinorRel=None, MaintRel=None, CodeRevision=None, BootloaderBuildType=None, BootloaderRevision=None), RPCError.CommandNotRecognized.Rsp(ErrorCode=None, RequestHeader=CommandHeader(id=0x02, subsystem=Subsystem.SYS, type=CommandType.SREQ))), future=<Future cancelled>)
DEBUG:zigpy_znp.api:Cleaning up empty listener list for header CommandHeader(id=0x00, subsystem=Subsystem.RPCError, type=CommandType.SRSP)
DEBUG:zigpy_znp.api:Cleaning up empty listener list for header CommandHeader(id=0x02, subsystem=Subsystem.SYS, type=CommandType.SRSP)
DEBUG:zigpy_znp.api:There are 0 callbacks and 0 one-shot listeners remaining
DEBUG:zigpy_znp.api:Connection to COM6 failed, cleaning up
Traceback (most recent call last):
  File "C:\Users\ldietrich\Documents\zigbee.wiki\lucas\12_CC2531_Antenna\venv\lib\site-packages\zigpy_znp\api.py", line 507, in request
    response = await response_future
asyncio.exceptions.CancelledError
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
  File "<input>", line 1, in <module>
  File "C:\Program Files\JetBrains\PyCharm Community Edition 2020.3\plugins\python-ce\helpers\pydev\_pydev_bundle\pydev_umd.py", line 197, in runfile
    pydev_imports.execfile(filename, global_vars, local_vars)  # execute the script
  File "C:\Program Files\JetBrains\PyCharm Community Edition 2020.3\plugins\python-ce\helpers\pydev\_pydev_imps\_pydev_execfile.py", line 18, in execfile
    exec(compile(contents+"\n", file, 'exec'), glob, loc)
  File "C:/Users/ldietrich/Documents/zigbee.wiki/lucas/12_CC2531_Antenna/github_znp_issue.py", line 30, in <module>
    asyncio.run(main())
  File "C:\Python38\lib\asyncio\runners.py", line 44, in run
    return loop.run_until_complete(main)
  File "C:\Python38\lib\asyncio\base_events.py", line 616, in run_until_complete
    return future.result()
  File "C:/Users/ldietrich/Documents/zigbee.wiki/lucas/12_CC2531_Antenna/github_znp_issue.py", line 22, in main
    await app.startup(auto_form=True)
  File "C:\Users\ldietrich\Documents\zigbee.wiki\lucas\12_CC2531_Antenna\venv\lib\site-packages\zigpy_znp\zigbee\application.py", line 206, in startup
    return await self._startup(auto_form=auto_form)
  File "C:\Users\ldietrich\Documents\zigbee.wiki\lucas\12_CC2531_Antenna\venv\lib\site-packages\zigpy_znp\zigbee\application.py", line 215, in _startup
    await znp.connect()
  File "C:\Users\ldietrich\Documents\zigbee.wiki\lucas\12_CC2531_Antenna\venv\lib\site-packages\zigpy_znp\api.py", line 234, in connect
    self._version = await self.request(c.SYS.Version.Req())
  File "C:\Users\ldietrich\Documents\zigbee.wiki\lucas\12_CC2531_Antenna\venv\lib\site-packages\zigpy_znp\api.py", line 507, in request
    response = await response_future
  File "C:\Users\ldietrich\Documents\zigbee.wiki\lucas\12_CC2531_Antenna\venv\lib\site-packages\async_timeout\__init__.py", line 55, in __aexit__
    self._do_exit(exc_type)
  File "C:\Users\ldietrich\Documents\zigbee.wiki\lucas\12_CC2531_Antenna\venv\lib\site-packages\async_timeout\__init__.py", line 92, in _do_exit
    raise asyncio.TimeoutError
asyncio.exceptions.TimeoutError

I tried the following script to send the SYS_PING request over serial manually using the "Monitor and Test API" document, to be sure that the firmware works over the correct COM port.

import serial
from time import sleep
import threading

s = serial.Serial(port="COM6", baudrate=115200)

def listener():
    while True:
        r = s.read()

        if r:
            print(r, end="")

thread = threading.Thread(target=listener)
thread.start()

# TI Z Stack Monitor and Test API
# frames specifications on page 3
# SYS_PING request and response on page 6
cmd = b"\xFE\x00\x21\x01\x20" # START BYTE, LEN, CMD 1, CMD 2, [0 data bytes here], CHECKSUM

print("sending", cmd, "\nreponse ", end="")

s.write(cmd)

sleep(1.0)

thread.join()

s.close()

And I'm getting a response from the dongle.

sending b'\xfe\x00!\x01 ' 
reponse b'\xfe'b'\x02'b'a'b'\x01'b'y'b'\x07'b'\x1c'

I'm a beginner and I have some difficulties to identify the reasons. I expect a misconfiguration or the misuse of the python library in my script.

What are the things that I could have missed ? Or am I totally wrong with the use of the library in my script.

I also specify that I have the same problem with the zigpy-cc library but with the Z Stack 1.2 firmware, which could highlight my misunderstanding of library...

In addition, are there examples of use of this library (or more precise documentation) ?

Thank you

Lucas

PS: I'm not sure if my question is relevent in this category, I'm not completely comfortable with github yet...

[DEPENDENCY] The pre-commit/mirrors-isort mirror repository is deprecated so should use isort directly instead?

Probably need to update dependencies in setup.cfg and possibly other source for isort or in other way seperate isort dependency for all zigpy libraries as upstream repo for isort has moved?

@Adminiuga & @puddly This is only to bring this to your attention as I don't know the best solution for this, I just happened to stumble on the fact that the mirror of isort package for pre-commit is deprecated and that upstream isort has also recently been moved. I think that this applies to all zigpy libraries, including zigpy, bellows, zigpy-cc, zigpy-deconz, zigpy-xbee, zigpy-zigate, and zha-device-handlers, plus zigpy-znp as well?

For reference, updated now in zigpy and bellows:

zigpy/zigpy#488

zigpy/bellows#349

See comment in https://github.com/pre-commit/mirrors-isort where is says that the pre-commit mirror for isort repository is deprecated, and to instead use isort directly.

Mirror of isort package for pre-commit split and moved

For pre-commit: see https://github.com/pre-commit/pre-commit

For isort: see https://github.com/PyCQA/isort

Also note that isort upstream recently moved from https://github.com/timothycrosley/isort to https://github.com/PyCQA/isort

Currently, the latest release is 5.5.0 (as of September 3, 2020) and since isort 5.0.0 and later it now requires Python 3.6 or later:

https://pycqa.github.io/isort/CHANGELOG/

Some more information should be available at https://pycqa.github.io/isort/

PS: If you decide on changing this then please also remember to reflect the changes in the CONTRIBUTING.md file for zigpy:

https://github.com/zigpy/zigpy/blob/dev/CONTRIBUTING.md

zigpy/zigpy#490

ZNP issue after upgrading to fw CC2652RB_20210128

Hi,

I hope this is the right place for this.
I did migrate recently to the CC2652RB from slae.sh. I was running on firmware version CC2652RB_20201026.

As lost recently connectivity with all zigbee devices, I tried the last recommended version of the koenkk's fw for CC2652R
Upgrade was successful but after replugging, restarting home-assistant (core hosted on hassos), seems that HA is unable to communicate properly with the coordinator anymore:
2021-02-02 00:02:37 ERROR (MainThread) [zigpy.application] Couldn't start application
2021-02-02 00:02:37 ERROR (MainThread) [homeassistant.components.zha.core.gateway] Couldn't start ZNP = Texas Instruments Z-Stack ZNP protocol: CC253x, CC26x2, CC13x2 coordinator
Traceback (most recent call last)

Detailed logs:

2021-02-02 00:02:19 DEBUG (MainThread) [zigpy_znp.uart] Connecting to /dev/serial/by-id/usb-Silicon_Labs_slae.sh_cc2652rb_stick_-_slaesh_s_iot_stuff_00_12_4B_00_21_CC_0A_BD-if00-port0 at 115200 baud
2021-02-02 00:02:19 DEBUG (MainThread) [zigpy_znp.uart] Opened /dev/serial/by-id/usb-Silicon_Labs_slae.sh_cc2652rb_stick_-_slaesh_s_iot_stuff_00_12_4B_00_21_CC_0A_BD-if00-port0 serial port
2021-02-02 00:02:19 DEBUG (MainThread) [zigpy_znp.uart] Toggling RTS/CTS to skip CC2652R bootloader
2021-02-02 00:02:19 DEBUG (MainThread) [zigpy_znp.uart] Received data: b'\x00'
2021-02-02 00:02:20 DEBUG (MainThread) [zigpy_znp.uart] Received data: b'\x00'
2021-02-02 00:02:20 DEBUG (MainThread) [zigpy_znp.uart] Connected to /dev/serial/by-id/usb-Silicon_Labs_slae.sh_cc2652rb_stick_-_slaesh_s_iot_stuff_00_12_4B_00_21_CC_0A_BD-if00-port0 at 115200 baud
2021-02-02 00:02:20 DEBUG (MainThread) [zigpy_znp.api] Waiting 1s before sending anything
2021-02-02 00:02:21 DEBUG (MainThread) [zigpy_znp.api] Sending bootloader skip byte
2021-02-02 00:02:21 DEBUG (MainThread) [zigpy_znp.uart] Sending data: b'\xEF\xEF\xEF\xEF\xEF\xEF\xEF\xEF\xEF\xEF\xEF\xEF\xEF\xEF\xEF\xEF\xEF\xEF\xEF\xEF\xEF\xEF\xEF\xEF\xEF\xEF\xEF\xEF\xEF\xEF\xEF\xEF\xEF\xEF\xEF\xEF\xEF\xEF\xEF\xEF\xEF\xEF\xEF\xEF\xEF\xEF\xEF\xEF\xEF\xEF\xEF\xEF\xEF\xEF\xEF\xEF\xEF\xEF\xEF\xEF\xEF\xEF\xEF\xEF\xEF\xEF\xEF\xEF\xEF\xEF\xEF\xEF\xEF\xEF\xEF\xEF\xEF\xEF\xEF\xEF\xEF\xEF\xEF\xEF\xEF\xEF\xEF\xEF\xEF\xEF\xEF\xEF\xEF\xEF\xEF\xEF\xEF\xEF\xEF\xEF\xEF\xEF\xEF\xEF\xEF\xEF\xEF\xEF\xEF\xEF\xEF\xEF\xEF\xEF\xEF\xEF\xEF\xEF\xEF\xEF\xEF\xEF\xEF\xEF\xEF\xEF\xEF\xEF\xEF\xEF\xEF\xEF\xEF\xEF\xEF\xEF\xEF\xEF\xEF\xEF\xEF\xEF\xEF\xEF\xEF\xEF\xEF\xEF\xEF\xEF\xEF\xEF\xEF\xEF\xEF\xEF\xEF\xEF\xEF\xEF\xEF\xEF\xEF\xEF\xEF\xEF\xEF\xEF\xEF\xEF\xEF\xEF\xEF\xEF\xEF\xEF\xEF\xEF\xEF\xEF\xEF\xEF\xEF\xEF\xEF\xEF\xEF\xEF\xEF\xEF\xEF\xEF\xEF\xEF\xEF\xEF\xEF\xEF\xEF\xEF\xEF\xEF\xEF\xEF\xEF\xEF\xEF\xEF\xEF\xEF\xEF\xEF\xEF\xEF\xEF\xEF\xEF\xEF\xEF\xEF\xEF\xEF\xEF\xEF\xEF\xEF\xEF\xEF\xEF\xEF\xEF\xEF\xEF\xEF\xEF\xEF\xEF\xEF\xEF\xEF\xEF\xEF\xEF\xEF\xEF\xEF\xEF\xEF\xEF\xEF\xEF\xEF\xEF\xEF\xEF\xEF'
2021-02-02 00:02:21 DEBUG (MainThread) [zigpy_znp.api] Waiting 1s or until a reset indication is received
2021-02-02 00:02:21 DEBUG (MainThread) [zigpy_znp.api] Creating one-shot listener OneShotResponseListener(matching_commands=(SYS.ResetInd.Callback(Reason=None, TransportRev=None, ProductId=None, MajorRel=None, MinorRel=None, MaintRel=None),), future=<Future pending cb=[ZNP.wait_for_responses.<locals>.<lambda>() at /usr/local/lib/python3.8/site-packages/zigpy_znp/api.py:436, <TaskWakeupMethWrapper object at 0x69c4dc70>()]>)
2021-02-02 00:02:22 DEBUG (MainThread) [zigpy_znp.api] Removing listener OneShotResponseListener(matching_commands=(SYS.ResetInd.Callback(Reason=None, TransportRev=None, ProductId=None, MajorRel=None, MinorRel=None, MaintRel=None),), future=<Future cancelled>)
2021-02-02 00:02:22 DEBUG (MainThread) [zigpy_znp.api] Cleaning up empty listener list for header CommandHeader(id=0x80, subsystem=Subsystem.SYS, type=CommandType.AREQ)
2021-02-02 00:02:22 DEBUG (MainThread) [zigpy_znp.api] There are 0 callbacks and 0 one-shot listeners remaining
2021-02-02 00:02:22 DEBUG (MainThread) [zigpy_znp.api] Testing connection to /dev/serial/by-id/usb-Silicon_Labs_slae.sh_cc2652rb_stick_-_slaesh_s_iot_stuff_00_12_4B_00_21_CC_0A_BD-if00-port0
2021-02-02 00:02:22 DEBUG (MainThread) [zigpy_znp.api] Sending request: SYS.Version.Req()
2021-02-02 00:02:22 DEBUG (MainThread) [zigpy_znp.api] Creating one-shot listener OneShotResponseListener(matching_commands=(SYS.Version.Rsp(TransportRev=None, ProductId=None, MajorRel=None, MinorRel=None, MaintRel=None, CodeRevision=None, BootloaderBuildType=None, BootloaderRevision=None), RPCError.CommandNotRecognized.Rsp(ErrorCode=None, RequestHeader=CommandHeader(id=0x02, subsystem=Subsystem.SYS, type=CommandType.SREQ))), future=<Future pending cb=[ZNP.wait_for_responses.<locals>.<lambda>() at /usr/local/lib/python3.8/site-packages/zigpy_znp/api.py:436, <TaskWakeupMethWrapper object at 0x69c4d958>()]>)
2021-02-02 00:02:22 DEBUG (MainThread) [zigpy_znp.uart] Sending data: b'\xFE\x00\x21\x02\x23'
2021-02-02 00:02:29 DEBUG (MainThread) [homeassistant.core] Bus:Handling <Event state_changed[L]: entity_id=sensor.processor_use, old_state=<state sensor.processor_use=3; unit_of_measurement=%, friendly_name=Processor use (percent), icon=mdi:cpu-32-bit @ 2021-02-02T00:01:59.547391-05:00>, new_state=<state sensor.processor_use=7; unit_of_measurement=%, friendly_name=Processor use (percent), icon=mdi:cpu-32-bit @ 2021-02-02T00:02:29.550944-05:00>>
2021-02-02 00:02:29 DEBUG (MainThread) [homeassistant.core] Bus:Handling <Event state_changed[L]: entity_id=sensor.memory_use_percent, old_state=<state sensor.memory_use_percent=44.4; unit_of_measurement=%, friendly_name=Memory use (percent), icon=mdi:memory @ 2021-02-02T00:01:59.559425-05:00>, new_state=<state sensor.memory_use_percent=44.6; unit_of_measurement=%, friendly_name=Memory use (percent), icon=mdi:memory @ 2021-02-02T00:02:29.564764-05:00>>
2021-02-02 00:02:29 DEBUG (MainThread) [homeassistant.core] Bus:Handling <Event state_changed[L]: entity_id=sensor.swap_free, old_state=<state sensor.swap_free=223.7; unit_of_measurement=MiB, friendly_name=Swap free, icon=mdi:harddisk @ 2021-02-01T23:58:29.552396-05:00>, new_state=<state sensor.swap_free=223.5; unit_of_measurement=MiB, friendly_name=Swap free, icon=mdi:harddisk @ 2021-02-02T00:02:29.578521-05:00>>
2021-02-02 00:02:37 DEBUG (MainThread) [zigpy_znp.api] Removing listener OneShotResponseListener(matching_commands=(SYS.Version.Rsp(TransportRev=None, ProductId=None, MajorRel=None, MinorRel=None, MaintRel=None, CodeRevision=None, BootloaderBuildType=None, BootloaderRevision=None), RPCError.CommandNotRecognized.Rsp(ErrorCode=None, RequestHeader=CommandHeader(id=0x02, subsystem=Subsystem.SYS, type=CommandType.SREQ))), future=<Future cancelled>)
2021-02-02 00:02:37 DEBUG (MainThread) [zigpy_znp.api] Cleaning up empty listener list for header CommandHeader(id=0x00, subsystem=Subsystem.RPCError, type=CommandType.SRSP)
2021-02-02 00:02:37 DEBUG (MainThread) [zigpy_znp.api] Cleaning up empty listener list for header CommandHeader(id=0x02, subsystem=Subsystem.SYS, type=CommandType.SRSP)
2021-02-02 00:02:37 DEBUG (MainThread) [zigpy_znp.api] There are 0 callbacks and 0 one-shot listeners remaining
2021-02-02 00:02:37 DEBUG (MainThread) [zigpy_znp.api] Connection to /dev/serial/by-id/usb-Silicon_Labs_slae.sh_cc2652rb_stick_-_slaesh_s_iot_stuff_00_12_4B_00_21_CC_0A_BD-if00-port0 failed, cleaning up
2021-02-02 00:02:37 ERROR (MainThread) [zigpy.application] Couldn't start application
2021-02-02 00:02:37 DEBUG (MainThread) [zigpy_znp.uart] Closing serial port
2021-02-02 00:02:37 DEBUG (MainThread) [zigpy_znp.api] We were disconnected from /dev/serial/by-id/usb-Silicon_Labs_slae.sh_cc2652rb_stick_-_slaesh_s_iot_stuff_00_12_4B_00_21_CC_0A_BD-if00-port0: None
2021-02-02 00:02:37 ERROR (MainThread) [homeassistant.components.zha.core.gateway] Couldn't start ZNP = Texas Instruments Z-Stack ZNP protocol: CC253x, CC26x2, CC13x2 coordinator
Traceback (most recent call last):
  File "/usr/local/lib/python3.8/site-packages/zigpy_znp/api.py", line 507, in request
    response = await response_future
asyncio.exceptions.CancelledError
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
  File "/usr/src/homeassistant/homeassistant/components/zha/core/gateway.py", line 157, in async_initialize
    self.application_controller = await app_controller_cls.new(
  File "/usr/local/lib/python3.8/site-packages/zigpy/application.py", line 69, in new
    await app.startup(auto_form)
  File "/usr/local/lib/python3.8/site-packages/zigpy_znp/zigbee/application.py", line 206, in startup
    return await self._startup(auto_form=auto_form)
  File "/usr/local/lib/python3.8/site-packages/zigpy_znp/zigbee/application.py", line 215, in _startup
    await znp.connect()
  File "/usr/local/lib/python3.8/site-packages/zigpy_znp/api.py", line 234, in connect
    self._version = await self.request(c.SYS.Version.Req())
  File "/usr/local/lib/python3.8/site-packages/zigpy_znp/api.py", line 507, in request
    response = await response_future
  File "/usr/local/lib/python3.8/site-packages/async_timeout/__init__.py", line 55, in __aexit__
    self._do_exit(exc_type)
  File "/usr/local/lib/python3.8/site-packages/async_timeout/__init__.py", line 92, in _do_exit
    raise asyncio.TimeoutError
asyncio.exceptions.TimeoutError

Output of the first sucessfull flash with JelmerT python script:

cc2538-bsl.py -p COM3 -evw CC2652RB_20210128.hex
Opening port COM3, baud 500000
Reading data from CC2652RB_20210128.hex
Your firmware looks like an Intel Hex file
Connecting to target...
CC1350 PG2.0 (7x7mm): 352KB Flash, 20KB SRAM, CCFG.BL_CONFIG at 0x00057FD8
Primary IEEE Address: 00:12:4B:00:21:CC:0A:BD
    Performing mass erase
Erasing all main bank flash sectors
    Erase done
Writing 360448 bytes starting at address 0x00000000
Write 104 bytes at 0x00057F980
    Write done
Verifying by comparing CRC32 calculations.
    Verified (match: 0x4ae3081e)

Seeing the issue with HA, did then flash successfully with SmartRF Flash Programmer 2:

>Initiate access to target: COM3 using 2-pin cJTAG.
>Reading file: C:/Users/Julien/CloudSync/SOFTS/HA/CC2652RB_20210128.hex.
>Start flash erase ...
>Erase finished successfully.
>Start flash programming ...
>Programming finished successfully.
>Start flash verify ...
>Skip verification of unassigned page: 23.
>Skip verification of unassigned page: 24.
>Skip verification of unassigned page: 25.
>Skip verification of unassigned page: 26.
>Skip verification of unassigned page: 27.
>Skip verification of unassigned page: 28.
>Skip verification of unassigned page: 29.
>Skip verification of unassigned page: 30.
>Skip verification of unassigned page: 31.
>Skip verification of unassigned page: 32.
>Skip verification of unassigned page: 33.
>Skip verification of unassigned page: 34.
>Skip verification of unassigned page: 35.
>Skip verification of unassigned page: 36.
>Skip verification of unassigned page: 37.
>Skip verification of unassigned page: 38.
>Skip verification of unassigned page: 39.
>Skip verification of unassigned page: 40.
>Skip verification of unassigned page: 41.
>Skip verification of unassigned page: 42.
>Page: 0 verified OK.
>Page: 1 verified OK.
>Page: 2 verified OK.
>Page: 3 verified OK.
>Page: 4 verified OK.
>Page: 5 verified OK.
>Page: 6 verified OK.
>Page: 7 verified OK.
>Page: 8 verified OK.
>Page: 9 verified OK.
>Page: 10 verified OK.
>Page: 11 verified OK.
>Page: 12 verified OK.
>Page: 13 verified OK.
>Page: 14 verified OK.
>Page: 15 verified OK.
>Page: 16 verified OK.
>Page: 17 verified OK.
>Page: 18 verified OK.
>Page: 19 verified OK.
>Page: 20 verified OK.
>Page: 21 verified OK.
>Page: 22 verified OK.
>Page: 43 verified OK.
>Verification finished successfully.
>Reset target ...
>Reset of target successful.

HA details:
core-2021.1.5
supervisor-2021.01.7
HassOS 4.17

Any help to troubleshoot this will be greatly appreciated =)

CC2538 being seen as CC2531 and most of the time offline in Home Assistant

CC2538 module is being seen as CC2531 in Home Assistant and is most of the time showed as offline even though is seems to work fine.
This is what I see in Home Assistant log:

2021-05-22 21:15:46 DEBUG (MainThread) [homeassistant.components.zha.core.device] [0x0000](CC2531, Z-Stack 3.0.1/3.0.2): Attempting to checkin with device - missed checkins: 1
2021-05-22 21:15:46 DEBUG (MainThread) [homeassistant.components.zha.core.device] [0x0000](CC2531, Z-Stack 3.0.1/3.0.2): does not have a mandatory basic cluster
2021-05-22 21:17:04 DEBUG (MainThread) [homeassistant.components.zha.core.device] [0x0000](CC2531, Z-Stack 3.0.1/3.0.2): Attempting to checkin with device - missed checkins: 2
2021-05-22 21:17:04 DEBUG (MainThread) [homeassistant.components.zha.core.device] [0x0000](CC2531, Z-Stack 3.0.1/3.0.2): does not have a mandatory basic cluster

zigpy-znp version 0.5.1

[SUGGESTION] Suggest zigpy-znp and ZHA devs team-up with slaesh to test his CC2652RB stick as another reference adapter

Suggest zigpy-znp + zigpy-cc and ZHA devs team-up with @slaesh to test his new CC2652RB stick as another reference adapter.

@slaesh I believe that you already donated adapters to the Zigbee2mqtt project so wondering if you would also be willing to donate some of your CC2652RB stick adapters to @sanyatuning & @Adminiuga & @puddly & @dmulcahey for zigpy/zigpy-cc and zha-ng/zigpy-znp development as those Zigbee radio libraries is used via the zigpy project in Home Assistant's ZHA integration component for its native Zigbee support?

FYI; @slaesh has developed his new CC2652RB stick as an open source hardware designed similar to the CC2652R stick by Electrolama/omerk as a another friendly competition option, and as noted, slaesh stick is based on CC2652RB instead of CC2652R. His adapter is since recently listed as a supported reference adapter by Zigbee2MQTT on their project page.

https://github.com/slaesh/cc2652-stick

and

https://slae.sh/projects/cc2652/

Like omerk, slaesh is also based in Europe and is selling the finished product (unflashed) via Tindie

https://www.tindie.com/products/slaesh/cc2652-zigbee-coordinator-or-openthread-router/

Should you backup NVRAM before firmware update?

Hi!
I finally completely switched to using the ZHA with this library and I must say, the setup of all devices was much more smooth than when I was doing it with deconz. The attribute reporting like Cover position with Fyrtur blinds was setup immediately, group binding, device binding, Everyting worked right away. Really good piece of sw!

I am not so sure from the documentation if I need to do NVRAM backup/restore when upgrading Koenk Z-Stack firmware. (So no migration from different radios)
The zigbee2mqtt does a automatic coordinator backup from time to time, but I think the zigpy does not.

So should the right firmware upgrade procedure when using ZHA/zigpy-znp be: Backup NVRAM, reflash new firmware(I am using the https://github.com/JelmerT/cc2538-bsl ),and then restore nvram?

I just want to avoid nicely spent 2-3 hours of repairing devices haha.

CC2538 Support?

Due to lqi issues I ordered a CC2538, hoping I can replace my current ZZH! with a high power coordinator.

I realized, that zigpy sais support is experimental, using Z-Stack 1.2 and zigpy-cc (https://github.com/zigpy/zigpy/)
On zigbee2mqtt they suggest using Z-Stack 3.0 (https://www.zigbee2mqtt.io/information/supported_adapters#texas-instruments-cc2538-with-cc2592-rf-amplifier)

What can I expect from using a CC2538 with zigpy-znp? Is zigpy-znp more bound to the coordinator software (Z-Stack Version) or to the device itself?

Thank you for your time.

Light group not working

Key	Value
host_os	HassOS 4.11
installation_type	Home Assistant OS
os_name	Linux
os_version	4.19.127-v7l
python_version	3.7.7
supervisor	229
version	0.112.4

zigpy-znp installed from source
git+https://github.com/zha-ng/zigpy-znp.git@dev#zigpy-znp==1.0.0

Running on a TI CC2531

After creating a group and restarting HA, the following pops up in the log

2020-07-21 14:54:17 ERROR (MainThread) [homeassistant.util.logging] Exception in functools.partial(<function async_add_entities at 0xb22ec9c0>, <bound method EntityPlatform._async_schedule_add_entities of <homeassistant.helpers.entity_platform.EntityPlatform object at 0xa8321710>>, [(<class 'homeassistant.components.zha.light.Light'>, ('68:0a:e2:ff:fe:b7:b6:97-1', <homeassistant.components.zha.core.device.ZHADevice object at 0xa83b68d0>, [<homeassistant.components.zha.core.channels.general.OnOffChannel object at 0xa83b6c70>, <homeassistant.components.zha.core.channels.general.LevelControlChannel object at 0xa83b6ad0>, <homeassistant.components.zha.core.channels.lighting.ColorChannel object at 0xa83b6cb0>])), (<class 'homeassistant.components.zha.light.Light'>, ('58:8e:81:ff:fe:21:88:6b-1', <homeassistant.components.zha.core.device.ZHADevice object at 0xa83b6e10>, [<homeassistant.components.zha.core.channels.general.OnOffChannel object at 0xa83e2e90>, <homeassistant.components.zha.core.channels.general.LevelControlChannel object at 0xa83e2dd0>, <homeassistant.components.zha.core.channels.lighting.ColorChannel object at 0xa83c6070>])), (<class 'homeassistant.components.zha.light.LightGroup'>, (['light.left', 'light.right'], 'light_zha_group_0x0002', 0x0002, None))]) when dispatching 'zha_add_new_entities': ()
Traceback (most recent call last):
  File "/usr/src/homeassistant/homeassistant/components/zha/core/discovery.py", line 46, in async_add_entities
    to_add = [ent_cls(*args) for ent_cls, args in entities]
  File "/usr/src/homeassistant/homeassistant/components/zha/core/discovery.py", line 46, in <listcomp>
    to_add = [ent_cls(*args) for ent_cls, args in entities]
  File "/usr/src/homeassistant/homeassistant/components/zha/light.py", line 491, in __init__
    super().__init__(entity_ids, unique_id, group_id, zha_device, **kwargs)
  File "/usr/src/homeassistant/homeassistant/components/zha/light.py", line 105, in __init__
    super().__init__(*args, **kwargs)
  File "/usr/src/homeassistant/homeassistant/components/zha/entity.py", line 220, in __init__
    f"{zha_device.gateway.groups.get(group_id).name}_zha_group_0x{group_id:04x}"
AttributeError: 'NoneType' object has no attribute 'gateway'

Is there an zigpy-znp API

Hi. Looks very useful. Is there a published API so that zigpy-znp can be used by a python program to communicate with a CC2531 running as a client/router to send data via zigbee to a coordinator -> zigbee2mqtt -> mqtt broker -> recipient. Is this feasible?

I would imagine APIs would be needed to 1) set the zigbee identifier, 2) send a topic and message, 3) receive topics and messages.

Thanks, Alan

Group binding does not work for rwl021

Hi

I have just migrated from zigpy-zigate to zigpy-znp with CC2652RB device and I try to bind my philips RWL021 to a specific group.
I use dev branch to unbind coordinator first ( 62de24d , #54)

I am not sure witch one of bind unbind failed first, but it's not working for me

Log for unbind coordinator : https://pastebin.com/6BrNmeLC
Log for bind remote to group: https://pastebin.com/7S7Ai5Sr

I'ts working before with zigpy-zigate by doing this:

• unbind coordinator and press button remote
• bind group and press button on remote

Does anyone had success with this ?

Migrate asynctest to stdlib's AsyncMock

Same as zigpy/bellows#339 and zigpy/zigpy#475 as reported by @fabaff of Home Assistant / hass.io :

Asynctest doesn't work with Python 3.8 and above. It's the same issue as for zigpy (zigpy/zigpy#475).

Change Channel

I am using Zstack3 on a CC2531, with zigpy-znp via the HA beta.

I have successfully run the channel scan as per the readme, but can't figure out how to set this. Z2M has a config parameter in the yaml, for instance.

I am only using the ZHA integration and have not edited the HA config file for is (as I believe all configuration should be done via the UI). Should I add config for channel? If so, where?

`Could not pick endpoint` error for Centralite motion sensors

Reported by @walthowd

2020-10-27 15:15:00 ERROR (MainThread) [homeassistant.components.websocket_api.http.connection.140343427520064] Error handling message: Unknown error
Traceback (most recent call last):
  File "/usr/src/homeassistant/homeassistant/components/websocket_api/decorators.py", line 18, in _handle_async_response
    await func(hass, connection, msg)
  File "/usr/src/homeassistant/homeassistant/components/zha/api.py", line 641, in websocket_read_zigbee_cluster_attributes
    success, failure = await cluster.read_attributes(
  File "/usr/local/lib/python3.8/site-packages/zigpy/zcl/__init__.py", line 273, in read_attributes
    result = await self.read_attributes_raw(to_read, manufacturer=manufacturer)
  File "/usr/local/lib/python3.8/site-packages/zigpy/device.py", line 181, in request
    result, msg = await self._application.request(
  File "/usr/local/lib/python3.8/site-packages/zigpy_znp/zigbee/application.py", line 580, in request
    return await self._send_request(
  File "/usr/local/lib/python3.8/site-packages/zigpy_znp/zigbee/application.py", line 1213, in _send_request
    src_ep = self._find_endpoint(dst_ep=dst_ep, profile=profile, cluster=cluster)
  File "/usr/local/lib/python3.8/site-packages/zigpy_znp/zigbee/application.py", line 1106, in _find_endpoint
    raise ValueError(
ValueError: Could not pick endpoint for dst_ep=2, profile=49887, and cluster=0

This affects any device that uses profiles other than ZHA and ZLL.

[SUGGESTION] Migrate zigpy-znp repository to upstream zigpy organization?

@Adminiuga can I suggest that you please consider having your zigpy-znp repository here on GitHub moved to the zigpy organization @ https://github.com/zigpy/ so that the mainstream copy of this repo will stay there as its upstream instead and owned by the upstream zigpy organization?

That way all developers that are members in the zigpy organization can have write access to one or more projects that it own for collaboration as a community?

This would also help new developers take notice of this zigpy-znp project.

Hope that you could all come to an agreement that will make everyone happy with continuing with working on the zigpy-znp repository together without getting offended by any ownership conflicts.

Autodetect serial ports that has compatible adapter connected to it?

Would it be practical for zigpy-znp to have a probe method that scan all available serial ports in order to auto-detect port-path?

puddly posted in #28 slaesh provided information autodetecting at least his adapters:

@slaesh has sent me all the information I need to autodetect the serial port, although that functionality isn't being used by HA at the moment.

slaesh adapter does however not use the same type of USB-to-serial converter chip as others such as example Electrorama's ZZH.

I don't think testing is needed for an adapter that is functionally identical to the ZZH with the exception of a much better USB serial chip.

Perhaps that belongs in either the ZHA integration application level, discovery and/or Home Assistant Supervisor level instead?

HA already has several different methods to discover network services but no probes to discover Serial and/or USB adapters?

https://www.home-assistant.io/integrations/discovery/

https://developers.home-assistant.io/docs/supervisor/

https://www.home-assistant.io/integrations/zha/

PS: It would also be very good to be able to probe and discover if an adapter is already "in use" by any other application or not.

[REQUEST] Add same PyPa workflow as the other zigpy projects

PyPa has a GitHub Action for publishing pre-built distribution packages to PyPI.

• https://github.com/pypa/gh-action-pypi-publish

Consider adding PyPa workflow in the same unified way as other zigpy libraries, see:

• zigpy/zigpy-deconz#98

and

• zigpy/zigpy#336
  • zigpy/zigpy#338

Also, consider adding a long description to PyPi index by pointing to the README.md

• zigpy/zigpy#371

Keeping this and other methods the same in all zigpy libraries can help unify them.

Others features/functions which code could be reused and kept the same include:

• New zigpy initialization
• Support for radio lib configuration schemas
• Implement radio probe / API probe method
• USB reconnect (reconnect serial port on disconnects)

IMHO keep code for same functions/features the same to help the finding of issues.

This, in turn, could help existing and developers to which on all libraries for zigpy.

Allow option to disable and enable LED/LEDs on adapter or board

Copy request for LED control config from zigpy-cc zigpy/zigpy-cc#42 and zigpy/zigpy#384

Feature suggestion for optional settings to disable LED on CC2531 USB adapter/dongle/stick.

Option to configure setting for disabling and enabling LED/LEDs on the Zigbee radio adapter/dongle.

Requested for CC2531 dongle by Yevgenium in zigpy/zigpy-cc#42

I understand this is dependent on zigpy/zigpy#381 as another example of an optional extension?

Status.unknown_0xE9

Getting in the logs:

020-05-10 14:45:32 WARNING (MainThread) [zigpy_znp.types.named] Unhandled Status value: Status.unknown_0xE9

Latest zigpy version include NWK Status and MAC Statuses, so it would be nice to "chain" those here, as 0xE9 corresponds to MAC_NO_ACK

Similar feature in zigpy_deconz was implemented in zigpy/zigpy-deconz#109

No module named zigpy_znp.tools.network_backup

When attempting to use network backup on a TI CC1352P2
No module named zigpy_znp.tools.network_backup
I can perform NVRAM backup and run network scan etc.

Support for slae.sh CC2652RB stick

Hi,
does anyone tried this stick with this library? I am having problem to have it properly initialized.

It does work in zigbee2mqtt software, not here.

I tried to exclude all other factors, so instead of passing it to Home Assistant docker and using in ZHA, I downloaded zigpy-znp library to the host os (Arch Linux) and tried to launch the Energy scan tool.

It cannot even connect to the stick

• Its flashed with latest Koenkk firmware for CC2652RB
• No other software/container should currently be using the dongle
• If I connect generic Texas Instruments CC1352 board with Koenkk firmware, the energy scan works.

The error I am getting:

`python -m zigpy_znp.tools.energy_scan /dev/serial/by-id/usb-Silicon_Labs_http:_slae.sh_cc2652-_slaesh_s_iot_stuff_00:12:4B:00:21:A8:EB:55-if00-port0
2020-09-17 20:47:29 SERVER main[4075] INFO Starting up zigpy-znp
2020-09-17 20:47:34 SERVER zigpy.application[4075] ERROR Couldn't start application
Traceback (most recent call last):
File "/home/user/znp/zigpy-znp-dev/zigpy_znp/api.py", line 472, in request
response = await response_future
asyncio.exceptions.CancelledError

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
File "/usr/lib/python3.8/runpy.py", line 194, in _run_module_as_main
return _run_code(code, main_globals, None,
File "/usr/lib/python3.8/runpy.py", line 87, in _run_code
exec(code, run_globals)
File "/home/user/znp/zigpy-znp-dev/zigpy_znp/tools/energy_scan.py", line 98, in
asyncio.run(main(sys.argv[1:])) # pragma: no cover
File "/usr/lib/python3.8/asyncio/runners.py", line 43, in run
return loop.run_until_complete(main)
File "/usr/lib/python3.8/asyncio/base_events.py", line 616, in run_until_complete
return future.result()
File "/home/user/znp/zigpy-znp-dev/zigpy_znp/tools/energy_scan.py", line 94, in main
await perform_energy_scan(args.serial, num_scans=args.num_scans)
File "/home/user/znp/zigpy-znp-dev/zigpy_znp/tools/energy_scan.py", line 26, in perform_energy_scan
app = await ControllerApplication.new(
File "/home/user/znp/lib/python3.8/site-packages/zigpy/application.py", line 68, in new
await app.startup(auto_form)
File "/home/user/znp/zigpy-znp-dev/zigpy_znp/zigbee/application.py", line 152, in startup
await znp.connect()
File "/home/user/znp/zigpy-znp-dev/zigpy_znp/api.py", line 215, in connect
ping_rsp = await self.request(c.SYS.Ping.Req())
File "/home/user/znp/zigpy-znp-dev/zigpy_znp/api.py", line 472, in request
response = await response_future
File "/home/user/znp/lib/python3.8/site-packages/async_timeout/init.py", line 55, in aexit
self._do_exit(exc_type)
File "/home/user/znp/lib/python3.8/site-packages/async_timeout/init.py", line 92, in _do_exit
raise asyncio.TimeoutError
asyncio.exceptions.TimeoutError`

@slaesh Would you mind trying to use this library on your own stick?

InvalidCommandResponse: BUFFER_FULL error and light state not updating in Home Assistant

Hey I'm finding the following in my HomeAssitatnt log:

2020-10-21 22:57:38 ERROR (MainThread) [homeassistant.util.logging] Exception in _maybe_force_refresh when dispatching 'zha_light_group_state_changed': ({'entity_ids': ['light.kicker1_level_light_color_on_off', 'light.kicker0_level_light_color_on_off', 'light.schreibtisch1_level_light_color_on_off', 'light.tisch1_level_light_color_on_off', 'light.kuche1_level_light_color_on_off', 'light.kuche0_level_light_color_on_off', 'light.sofa_level_light_color_on_off', 'light.schreibtisch0_level_light_color_on_off', 'light.tisch0_level_light_color_on_off', 'light.schrank1_level_light_color_on_off', 'light.schrank0_level_light_color_on_off', 'light.kuche2_level_light_color_on_off']},)
Traceback (most recent call last):
  File "/usr/src/homeassistant/homeassistant/components/zha/light.py", line 482, in _maybe_force_refresh
    await self.async_get_state(from_cache=False)
  File "/usr/src/homeassistant/homeassistant/components/zha/light.py", line 450, in async_get_state
    results = await self._color_channel.get_attributes(
  File "/usr/src/homeassistant/homeassistant/components/zha/core/channels/base.py", line 266, in get_attributes
    result, _ = await self.cluster.read_attributes(
  File "/usr/local/lib/python3.8/site-packages/zigpy/zcl/__init__.py", line 273, in read_attributes
    result = await self.read_attributes_raw(to_read, manufacturer=manufacturer)
  File "/usr/local/lib/python3.8/site-packages/zigpy/device.py", line 181, in request
    result, msg = await self._application.request(
  File "/usr/local/lib/python3.8/site-packages/zigpy_znp/zigbee/application.py", line 578, in request
    return await self._send_request(
  File "/usr/local/lib/python3.8/site-packages/zigpy_znp/zigbee/application.py", line 1233, in _send_request
    response = await self._znp.request_callback_rsp(
  File "/usr/local/lib/python3.8/site-packages/zigpy_znp/api.py", line 554, in request_callback_rsp
    await self.request(request, **response_params)
  File "/usr/local/lib/python3.8/site-packages/zigpy_znp/api.py", line 529, in request
    raise InvalidCommandResponse(
zigpy_znp.exceptions.InvalidCommandResponse: Expected SRSP response AF.DataRequestExt.Rsp(Status=<Status.SUCCESS: 0>), got AF.DataRequestExt.Rsp(Status=<Status.BUFFER_FULL: 17>)

I'm using HomeAssistant: 0.116.4
With the CC2652R from https://electrolama.com/projects/zig-a-zig-ah/ with the 20200925 firmware from https://github.com/Koenkk/Z-Stack-firmware/tree/master/coordinator/Z-Stack_3.x.0/bin

Also I'm having some issues with incorrect device states, as I can sometimes turn on my light bulbs, but HA is not getting informed. A manual Get call to the on_off attribute of the OnOff cluster however updates the state. I'm not sure weather this is a HA, a zipy or a zigpy-snp issue.

README - Purpose of this library compared to zigpy-cc

Hi,
this is probably really dumb question. However, may I ask what is your goal in functionality or what are the differences against the zigpy-cc library, which is natively bundled with Home Assistant? :)
And maybe include that explanation in the default readme, so that user can find out if its right for him.

Have a nice day!

[REQUEST] Automagically auto-detect port-path and discover radio-type?

This is a feature request that I'm not exactly sure if it belongs to the Home Assistant core, the ZHA integration for Home Assistant, to zigpy, to each and every radio library for zigpy, or in many of all those mentioned in order to be achieved. Anyway, my main point with this feature request is this:

Is it possible to add some kind of "auto-detect" scanning option for automatic discovery/detection of port-path and radio-type (with recommended select) to achieve an even more plug-and-play experience of the initial install/configuration of the ZHA integration in Home Assistant or a zigpy implementation in any other software for that matter? An option for a so-called "next next next" installation process if you will.

From an end-users point-of-view the ZHA integration implementation of zigpy I think that it would be absolutely awesome if the installation process could automagically detect exactly which type of Zigbee adapter(s) you have plugged in and which USB-port(s) that the Zigbee adapter(s) is plugged into. Is this possible?

I think nicest would probably be if the user would be greeted by an option for "auto-detect and recommend Zigbee adapter(s)" that you could then simply click for automagic plug-and-play configuration of your Zigbee stick hardware instead of having to manually type the full port-path and the radio-type as you have to do today in ZHA.

Such an automagical auto-detect port-path and discover radio-type would make the ZHA integration component in Home Assistant even easier to install and configure for first-time ZHA users by removing the need for end-user to manually configure port-path and radio-type.

I believe that a plug-and-play oriented hardware configuration could be the last piece that is missing to make the ZHA in Home Assistant a much more user-friendly initial installation and configuration process experience.

[REQUEST] Allow strength of "TX Power" configuration for modules with Power Amplifier (PA)

Please consider allowing setting "TX power" (TX PWR) on radio modules with Power Amplifier (PA).

Backstory: Some if not all TI CC radio modules feature integrated or external Power Amplifier (PA), a powered RF-amplification frontend, and the amp power that goes to that RF-amplifier should be controllable via software via a configuration setting. All however also have a default setting which is always automatically used if no custom setting is asked for.

For example; the default TX power (TX_PWR) for the CC1352P and CC2652P is 5 dBm, however, these chips support up to a max of 19 dBm (though technical specification says 20 dBm), if you allow the user to control this then they could potentially get better reception if the power to amplification is increased.

See Koenkk/zigbee2mqtt#2253 from Koenkk of Zigbee2mqtt which the same idea and already implemented it as a proof-of-concept to allows setting the transmit power of the adapter for future versions which works for all adapters with Power Amplifiers, including CC2531, CC2530, CC1352P-2 and CC26X2R1, (in his POC allowed values are -22 dBm as the min to 19 dBm as the max, default is 0 except for the CC2530 + CC2591 = 4 and CC2530 + CC2592 = 19).

TI CC modules/chips which features an integrated or external RF-amplifier (PA/LNA) as I understand:

• CC1352P ("P" is for integrated Power Amplifier), example: LAUNCHXL-CC1352P
• CC2652P ("P" is for integrated Power Amplifier)
• CC2530 + CC2591 (where CC2591 is an external Power Amplifier chip)
• CC2530 + CC2592 (where CC2592 is an external Power Amplifier chip)
• CC2538 + CC2591 (where CC2591 is an external Power Amplifier chip)
• CC2538 + CC2592 (where CC2592 is an external Power Amplifier chip)

PS: As I understand, the chips have their maximum dBm hardcoded within safe limits so that there is no way to destroy the HW through these settings. It is just that depending on the frequency band, too high dBm values may not be legal outdoors and/or indoors depending on your country regulations, and therefore TI has set a low default value so that it is legal in all countries if one does not increase the values.

[REQUEST] Ability to upgrade Texas Instrument coordinator firmware via zigpy-znp and ZHA GUI?

Requesting this now as @puddly posted in #14 saying that he implemented the serial bootloader protocol (f67e8a4) used by the Windows utility mentioned in Koenkk/zigbee2mqtt#320 and was able to upgrade flash his already pre-flashed Texas Instruments CC adapter with a newer firmware without using any external tools, standalone to flash an adapter (in his case he tested it with a CC2531 adapter from ITead which is shipped with older firmware)

ip install zigpy-znp
$ python -m zigpy_znp.tools.flash_read /dev/serial/by-id/radio -o flash.bin
$ python -m zigpy_znp.tools.flash_write /dev/serial/by-id/radio -i flash.bin

Suggest considering adding ability to upgrade Texas Instrument coordinator firmware via zigpy-znp.

So not just backup and restore the firmware but update it if bought an adapter that has old firmware.

Best would probably be if users could have this ability if only they first manually download and rename firmware binary image file in a specific format to a predetermined file-name and then place that correctly formatted/named file in a specific directory before being able to issue an "upgrade coordinator firmware" command.

Even more awesome would then be to also add the ability to utilize that ability from HA ZHA GUI.

If so it would probably be best to first let the user manually download and unpack the firmware themselves so leave the responsibility to them to make sure it is in the correct format and then having a button in the ZHA UI for "upgrade coordinator firmware".

More user-friendly would then, of course, be if ZHA let you enter a URL source location for automatic download of firmware, like for example https://github.com/Koenkk/Z-Stack-firmware/