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
Comments
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. |
I did, it's just taking quite a long time to ship. |
Cool! And yes I know as recently placed an order for their new SONOFF ZBBridge (Zigbee WiFi Bridge) |
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. |
Someone else posted in Home Assistant forum also noting that it came with the same old firmware PS: I also asked the question here: |
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.
$ 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.
|
@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 |
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. |
I've successfully formed a network, joined a device, and received attribute reports with a CC2531. The latest release of |
Do you have a hue motion sensor be any chance? To try it with znp? |
Only Xiaomi and IKEA, unfortunately. Are you referring to zigpy/zigpy-cc#57? |
Yep. Ordered a hue sensor, should arrive on Tue. |
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 |
@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. |
I have the sensor just don't have time to try it. I'll try to carve something tonight and will let you know |
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. |
I'm pretty sure it was the Z-Stack endpoint stuff. 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 |
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? |
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
In this case per specs requests sent out to the server cluster 0x500 should be originating from epid 2. |
Support for Z-Stack Home 1.2 network formation is now in the main |
Nice! Are there any known limitations or missing functions and features in zigpy-znp in regards to Z-Stack Home 1.2? |
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.
The text was updated successfully, but these errors were encountered: