Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Supporting older radios #14

Closed
puddly opened this issue May 2, 2020 · 21 comments
Closed

Supporting older radios #14

puddly opened this issue May 2, 2020 · 21 comments
Labels
enhancement New feature or request good first issue Good for newcomers help wanted Extra attention is needed

Comments

@puddly
Copy link
Collaborator

puddly commented May 2, 2020

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
Copy link
Contributor

Hedda commented May 14, 2020

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
Copy link
Collaborator Author

puddly commented May 14, 2020

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

@Hedda
Copy link
Contributor

Hedda commented May 15, 2020

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

@puddly puddly added enhancement New feature or request help wanted Extra attention is needed labels May 16, 2020
@puddly
Copy link
Collaborator Author

puddly commented Jun 2, 2020

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
Copy link
Contributor

Hedda commented Jun 4, 2020

@puddly
Copy link
Collaborator Author

puddly commented Jun 6, 2020

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
Copy link
Contributor

Hedda commented Jun 8, 2020

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
Copy link
Collaborator Author

puddly commented Jul 4, 2020

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
Copy link
Collaborator Author

puddly commented Jul 12, 2020

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
Copy link
Contributor

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

@puddly
Copy link
Collaborator Author

puddly commented Jul 12, 2020

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

@Adminiuga
Copy link
Contributor

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

@puddly
Copy link
Collaborator Author

puddly commented Jul 21, 2020

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 puddly closed this as completed Jul 21, 2020
@puddly
Copy link
Collaborator Author

puddly commented Aug 6, 2020

@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
Copy link
Contributor

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
Copy link
Collaborator Author

puddly commented Aug 6, 2020

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
Copy link
Contributor

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
Copy link
Collaborator Author

puddly commented Aug 6, 2020

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
Copy link
Contributor

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
Copy link
Collaborator Author

puddly commented Sep 21, 2020

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
Copy link
Contributor

Hedda commented Sep 22, 2020

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?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request good first issue Good for newcomers help wanted Extra attention is needed
Projects
None yet
Development

No branches or pull requests

3 participants