Supporting older radios about zigpy-znp

[puddly]

Support for Z-Stack Home 1.2 network formation is now in the main dev branch, making zigpy-znp compatible with all TI radios and firmware versions.

[puddly]

I've implemented the serial bootloader protocol (f67e8a4) used by the Windows utility mentioned in Koenkk/zigbee2mqtt#320 and flashed my Itead stick without any external tools.

Due to a lack of unit tests, for now I've committed only zigpy_znp.tools.flash_read Both flash_read and flash_write are now supported:

$ python -m zigpy_znp.tools.flash_read /dev/cu.usbmodem14201 -o flash.bin
...

I'm going to keep this issue open for now but I don't plan on supporting Z-Stack versions older than 3.0 for the time being.

Note: for whatever reason I need to now push a button after plugging in the stick (or wait 60 seconds) to get the green LED to shut off to get it to power on normally. Otherwise it seems to boot fine with Z-Stack 3.0.1. This might be because I've never formed a network with this hardware. Skipping the bootloader is automatically enabled as of 2b7666e

[Hedda]

Did you order this CC2531 pre-flashed from ITead? -> https://www.itead.cc/cc2531-usb-dongle.html

IMHO would be great for new users/devs if such inexpensive worked out-of-the-box without flashing.

PS: I know that ITead has local resellers in most countries so that you don't have to pay customs fees.

[puddly]

I did, it's just taking quite a long time to ship.

[Hedda]

Cool! And yes I know as recently placed an order for their new SONOFF ZBBridge (Zigbee WiFi Bridge)

[puddly]

It finally arrived...pre-flashed with Z-Stack from 20180507. Too bad there is no easy way to flash the board without using test hooks and a second microcontroller.

[Hedda]

Someone else posted in Home Assistant forum also noting that it came with the same old firmware

https://community.home-assistant.io/t/itead-of-sonoff-fame-now-sells-a-very-inexpensive-zigbee-usb-dongle-that-should-work-out-of-the-box-with-both-zigbee2mqtt-and-the-zha-integration/181085/5

PS: I also asked the question here:

Koenkk/zigbee2mqtt#3192

zigpy/zigpy-cc#26

[Hedda]

I've implemented the serial bootloader protocol (f67e8a4) used by the Windows utility mentioned in Koenkk/zigbee2mqtt#320 and flashed my Itead stick without any external tools.

Due to a lack of unit tests, for now I've committed only zigpy_znp.tools.flash_read Both flash_read and flash_write are now supported:

$ python -m zigpy_znp.tools.flash_read /dev/cu.usbmodem14201 -o flash.bin
...

@puddly Are you saying that also added the ability to flash Texas Instrument coordinator firmware?

You know that I am now going to post a Feature Request asking for a TI firmware upgrade feature ;)

Update: Posted that a separate request here now => #24

[puddly]

Some interesting progress: the internal NVRAM state of the CC2531 running 3.0.2 and the newer hardware running 3.30 and 4.40 seems to contain the same information, though in very incompatible formats. This might make it possible to switch between coordinator hardware without having to recreate your network.

I'm going to try and "restore" my network to the CC2531 from the ZZH's NVRAM backup.

#19

[puddly]

I've successfully formed a network, joined a device, and received attribute reports with a CC2531. The latest release of zigpy-znp in theory fully supports the CC2531 (after flashing Z-Stack 3.0.1, see the README) but I have not had a chance to setup a more complex network with it yet.

[Adminiuga]

Do you have a hue motion sensor be any chance? To try it with znp?

[puddly]

Only Xiaomi and IKEA, unfortunately. Are you referring to zigpy/zigpy-cc#57?

[Adminiuga]

Yep. Ordered a hue sensor, should arrive on Tue.

[puddly]

CC2531 works fine with Home Assistant, though it starts having memory issues when HA tries to bind to a bunch of clusters on multiple devices at once. Adding an application-level randomized retry loop for Status.MEM_ERROR seems like it would help.

[puddly]

@Adminiuga have you had a chance to try out the Hue sensor with zigpy-znp? I'm reluctant to order a sensor that works without any issues.

[Adminiuga]

I have the sensor just don't have time to try it. I'll try to carve something tonight and will let you know

[puddly]

No worries, just curious if the Z-Stack endpoint stuff was the root cause or if there is something lower level that needs to be patched.

[Adminiuga]

I'm pretty sure it was the Z-Stack endpoint stuff.
Are you overriding the source endpoint in zigpy-znp?

I haven't figured the best way to do it, as do it properly you need to know what profile_id and potentially the cluster_id and cluster_type the request is for and with that info ApplicationController could hint the right endpoint id.

But for simplicity, we could just do one endpoint per profile_id

[puddly]

Originally I did have it choosing the endpoint based on the profile but at the moment I'm just rewriting the source endpoint of every non-ZDO request to be endpoint 1.

In what scenario would the cluster matter?

[Adminiuga]

it would matter in very specific cases, like having multiple endpoint with the same profile id, but different set of input/output clusters, for example

endpoint_id: 1
  in_clusters: [0x500]
  out_cluster: []
endpoint_id: 2
  in_clusters: []
  out_clusters: [0x500]

In this case per specs requests sent out to the server cluster 0x500 should be originating from epid 2.
In real life, i don't think it matter much.

[Hedda]

Support for Z-Stack Home 1.2 network formation is now in the main dev branch, making zigpy-znp compatible with all TI radios and firmware versions.

Nice! Are there any known limitations or missing functions and features in zigpy-znp in regards to Z-Stack Home 1.2?