search

zigpy / zigpy-znp

TI CC2531, CC13x2, CC26x2 radio support for Zigpy and ZHA
GNU General Public License v3.0
148 stars 40 forks source link

Supporting older radios #14

Closed puddly closed 4 years ago

puddly commented 4 years ago

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.

Hedda commented 4 years ago

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 commented 4 years ago

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

Hedda commented 4 years ago

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

puddly commented 4 years ago

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 commented 4 years ago

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:

https://github.com/Koenkk/zigbee2mqtt/issues/3192

https://github.com/zigpy/zigpy-cc/issues/26

puddly commented 4 years ago

I've implemented the serial bootloader protocol (f67e8a48f9a0f9bcf400a6229e2d14b82c3aae70) used by the Windows utility mentioned in https://github.com/Koenkk/zigbee2mqtt/issues/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 https://github.com/zha-ng/zigpy-znp/commit/2b7666ed96438b31682be8bb2bfd3d7909a40cfd

Hedda commented 4 years ago

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 => https://github.com/zha-ng/zigpy-znp/issues/24

puddly commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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

puddly commented 4 years ago

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

Adminiuga commented 4 years ago

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

puddly commented 4 years ago

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 commented 4 years ago

@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 commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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.

puddly commented 4 years ago

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.

Hedda commented 4 years ago

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?