Support for Z-Stack 3 (Z-Stack 3.0.x and Z-Stack 3.x.x) - Texas Instruments Zigbee 3.0 stack on adapters like CC2652 and CC1352 #1226
Comments
|
I'm certainly happy for someone to provide a PR to add this support, but it is not something that I am personally likely to implement as all commercial users that I know of using this library are using Ember chipsets. So please feel free to provide a PR @Hedda |
OK. Then posted to openhab/org.openhab.binding.zigbee#649 as it is a community request for the OpenHAB Zigbee Binding. Texas Instruments USB dongles/sticks based on CC2652/CC2652P/CC2652R/CC2652RB are very popular among other many open source home automation projects/communities (inc. Zigbee2MQTT, IoBroker, and Home Assistant) as the CC26x2 series ais both relatively inexpensive, readily available, and very powerful Zigbee 3.0 compliant Zigbee coordinators. PS: I don't have the coding skills to code this myself, (plus OpenHAB is not the primary application that I use myself today). |
That's fine, but clearly it's not possible to implement the openHAB enhancement if the additions are not first made to this library. Again though, unless someone comes along to implement this, it is unlikely to be implemented by myself as I'm just too busy with other things.
I appreciate that this is the case for the hobby market as they are cheap, however the Silabs chipset is more popular for commercial users. Of around 20 customers I've supported, only 1 has used the TI chip - the others have used Silabs. |
|
Is the command set totally different between 1.2 and 3.0 ? Because adapter shows up with "Unknown" status. |
Personally I have no idea as I'm not familiar with the recent firmware. I know there were a number of changes a couple of years ago as I started to rewrite the TI driver for a customer who started using it, but they then moved to Silabs.
There would need to be a driver implemented to support the chipset - similar to the ones that are implemented for the other chips. |
zigbee2mqtt supports both adapters in the same code, it seems like: Would this shed some light on how different they are? |
|
The best place to look is the API documentation - reverse engineering other code is really a pain. However it is up to the implementor - if someone finds it easier to try to reverse other code, then it's a valid approach even if it's more difficult and error prone. As I've said above, unfortunately I personally do not have the time to look at this - there just aren't enough hours in the day at the moment. |
|
OK. Can't find the API documentation, and I do it faster reading the code. To me, it seems like there's not much differences, but it fails to reset in my case:
So in zigbee2mqtt it first requests version: https://github.com/Koenkk/zigbee-herdsman/blob/master/src/adapter/z-stack/adapter/zStackAdapter.ts#L106 And from there it initializes : https://github.com/Koenkk/zigbee-herdsman/blob/master/src/adapter/z-stack/adapter/startZnp.ts#L161 await znp.request(Subsystem.SYS, 'resetReq', {type: Constants.SYS.resetType.SOFT});is kinda similar to your dongleReset() . The difference is that you specify the whole frame while the js code builds it from the different components of the frame as an object. https://github.com/Koenkk/zigbee-herdsman/blob/master/src/adapter/z-stack/unpi/frame.ts#L35 Further on in that file, you can see how the startup sequence works with the special logic for version 3 of the stack. But if you don't even have time to look, it would be difficult for me to jump in and support it. |
I'm happy to answer a few questions, but a question like "what is the difference between API 1 and API 2" is a broad ranging question that can take a lot of time to understand. If you have the knowledge and capability to implement and debug this, then I'm happy to answer targeted questions, but I don't have a lot of time to start digging into the system to work out how something works in MQTT and implement it in Java here.
Maybe the new firmware uses a different sequence to escape from the bootloader? Or maybe some response before this is invalid such that the driver thinks it is in the bootloader and then can't escape. Just run through a debug sequence to work this out. |
|
Thanks a lot, maybe I can get it to work locally first. |
|
Yes, you can use the console application that is part of this repository. This is a full console application that's used as a demo since most users of this repository do not use openHAB. |
|
Thanks a lot! I totally missed that. |
FYI, zigpy-znp and zigpy-cc also support both stack versions in same code and while not Java they might shed light on differences. In those examples; zigpy-cc was written for Z-Stack Home 1.2 API/CLI and later @sanyatuning added support for Z-Stack 3 CLI/API. https://github.com/zigpy/zigpy-cc In the other example; zigpy-znp was written for Z-Stack 3.x API/CLI and later @puddly added support for Z-Stack Home 1.2 CLI/API. https://github.com/zigpy/zigpy-znp Both now support Z-Stack Home 1.2 API/CLI and Z-Stack 3 API/CLI, but zigpy-cc is now obsolete in favour of the newer zigpy-znp. For reference; zigpy-znp was written from scratch/docs, while zigpy-cc was reverse-engineered from zigbee-herdsman by @Koenkk |
For reference, a lot of TI documentation looks to be linked from the hardware development boards and software development kits: http://www.ti.com/tool/LAUNCHXL-CC26X2R1 http://www.ti.com/tool/LAUNCHXL-CC1352P https://www.ti.com/tool/SIMPLELINK-CC13X2-26X2-SDK https://www.ti.com/wireless-connectivity/zigbee/overview.html https://www.ti.com/wireless-connectivity/zigbee/technical-documents.html https://dev.ti.com/tirex/explore/node?node=AHjJ8SNDuLXt3h6qHE4-OA__pTTHBmu__LATEST Texas Instruments also seem to maintain much of official technical articles and guides in their forums as well: https://e2e.ti.com/search?category=forum&q=LAUNCHXL-CC26X2R1&group=341 https://e2e.ti.com/search?category=forum&q=LAUNCHXL-CC26X2R1 |
|
@cdjackson Had to use After running with -d CC2531 -p COM5 -b 115200 I get this:
Does this look correct? |
|
Network formation for Z-Stack 1 and 3 is complicated to say the least, especially if you want to form networks with arbitrary user-provided settings. The command sets are slightly different and it unfortunately requires you to directly modify opaque structures in NVRAM, whose alignment changes with the MCU architecture (i.e. CC2531, CC2538, and CC2652). I've extensively documented the formation process (as I understand it) in the network formation code for zigpy-znp but it relies on helper classes to perform NVRAM operations and an entire $ python -m zigpy_znp.tools.form_network -v /dev/cu.usbserial-1420 # or COM5
... |
|
Since network formation already works for the TI2531 I guess the question is if this has changed? I don't really think this issue is network formation related - the system works for the TI2531 - the issue is about making it work for newer version of zstack. |
Yes, it is now done with the BDB subsystem. That's effectively the only change. Formation for Z-Stack 3 is trickier because it performs scans during formation. There's no way to get it to form a network with a specific PAN ID, for example, if there are nearby routers sending out beacons with that PAN ID (unlike Z-Stack 1, which simply does it). If you're just forming a network with a random PAN ID, then it doesn't matter. |
|
Again, while not recommended for production, flashing a CC253x USB stick with Z-Stack 3.0.x is a good option for developers: https://github.com/Koenkk/Z-Stack-firmware/tree/master/coordinator https://github.com/Koenkk/Z-Stack-firmware/tree/master/coordinator/Z-Stack_3.0.x/bin If your CC2530 or CC2531 USB stick is already flashed with Z-Stack Home 1.2 then can upgrade firmware with zigpy-znp You can flash |
|
Maybe these old discussions might also be of interest for reference, or at the very least they contain many valid arguments why users would want to use a newer Z-Stack 3 FW on newer hardware instead of the older Z-Stack Home 1.2 on old HW: FYI, Tasmota Zigbee2Tasmota/Z2T project which previously only supported Z-Stack Home 1.2 also added support for Z-Stack 3: Zigbee compatibility with CC2652 ("The initialization sequence is now using SYS_OSAL_NV_READ/WRITE instead of SAPI_READ/WRITE_CONFIGURATION") Zigbee fix cc2652 init and permitjoin ("Fix PermitJoin indicator for ZStack 3" + "Fix init issue with ZStack 1.2 introduced by #11016") |
|
What other projects have done doesn't really assist here. It still requires someone to take some time to write the code - if you have the time, this would be appreciated of course. You can always start from this branch which was a full ZStack 3 driver, but never rolled out as the customer decided to move away from TI in the end and use Silabs. https://github.com/zsmartsystems/com.zsmartsystems.zigbee/tree/zstack_driver |
|
@cdjackson I am starting to look into your existing branch |
Not really. I wrote this a good few years ago now, so I forget exactly where it got to. I think it was reasonably complete, but of course there might be changes to the API. I would suggest to "give it a whirl" and see if it works - it would be nice to get this running and I'm happy to try and help support as best as I can, although I don't know if I have a stick to do any testing, but I am certainly happy to answer questions etc. |
arendst/Tasmota@62886b5 could be a good pointer. Do similar changes here? I have no idea how to test this and make sure it works with zigbee 3.0 though. I do have zigbee 3 devices and the "Tube’s CC2652P2 USB Coordinator" |
It's unclear how this is related? The branch mentioned above is a java stack for the ZStack 3 API and I'm not sure what this code is you've referenced, but it's not related I think. |
It gives a pointer what needs to be changed in the communication from 1.x to 3 |
|
But how is that related to this and the work that needs to be done to complete this implementation? This branch is a complete rewrite of the older Java driver. You are always going to be better off using the API documentation than trying to reverse engineer someone elses implementation. |
|
@cdjackson |
Thanks @t-8ch - yes, opening a WIP is probably a good idea so that there's some visibility. Hopefully this is not too much work to get working. From memory, this was mostly complete, but the company it was written for were using the 2531, and I was told at that point (by TI) that TI were not going to support the 2531 any more, so the company changed to use the EFR32 and we just never bothered to finish what is (hopefully) just the last bit of ironing to get it working.
So this is another device - not the coordinator? I'm surprised at this level it should cause attributes to be 0 unless there's maybe a serialisation issue. |
I find it easier to read code than documentation. |
From an engineering perspective, that's not a good approach as you will simply propagate incorrect implementation or bugs from one place to another. Anyway, it's not really relevant here since this is already 99% implemented and referring to another project does not help in any way. |
With limited time, and not being able to find the documentation, this is all I have to offer. See #1226 (comment) . |
|
With limited time, and not being able to find the documentation, this is all I have to offer. See #1226 (comment) <#1226 (comment)> .=
Fine, but I don’t see how that helps here. @t-8ch has offered to take a look at getting this working. You are also welcome to do so and provide any PRs that resolve any issues. Anyone is welcome to help - that’s open source :)
|
Seems like you got it under control, good luck
That's also a two way street. :) |
I’m not really sure what you mean by that comment, but if you are getting as me not helping you or something, then I offered to answer your questions in the earlier comment you referenced. I just said that I couldn’t explain all the differences from one version of the protocol to another. As I have also said here, I am happy to try and help people, but there are limits on my time as well. |
Thanks! as I mentioned earlier, it didn't seem like a huge undertaking to handle 3.x when I looked at other projects' diffs To "clear my name" I don't just paste or transplant code as a habit from other projects. I do it only for pointers and hits. Furthermore, I was stuck with the test app: #1226 (comment) - and I have no idea what it should do if it's successful or not, so if you had a guide on how to quickly test and validate it's functionality would be great. |
|
It is not just about diffs- this branch was a rewrite of the TI driver to improve a number of issues and remove a load of legacy code that was brought through from an earlier project and was not required. Yes, we possibly could have had a simpler hack to get the new API working, but the intention was to improve things for a commercial user - not just hack something together.
Please raise another issue on the console app and I will try and answer you questions. There is documentation on it in the reader, but as this is meant to be a low level library that is incorporated into other products, users are expected to have some knowledge of ZigBee.
Anyway, that is not really part of this issue, so please let’s discuss separately.
…Sent from my iPhone
On 28 Nov 2021, at 12:42, Emil Christopher Solli Melar ***@***.***> wrote:
That's also a two way street
I’m not really sure what you mean by that comment, but if you are getting as me not helping you or something, then I offered to answer your questions in the earlier comment you referenced. I just said that I couldn’t explain all the differences from one version of the protocol to another.
As I have also said here, I am happy to try and help people, but there are limits on my time as well.
Thanks! as I mentioned earlier, it didn't seem like a huge undertaking to handle 3.x when I looked at other projects' diffs
As I have no knowledge of zigbee from before and just wanted to jump into it to test locally if it worked, I just wanted some pointers, as I didn't find any documentation at the time.
And I had no idea how to find time to read old and new documentation to find the diffs, especially if there are successful implementation that essentially did the same thing. So I was hoping for you to take a quick glance at it because it could be useful to have a perspective on how big the change is.
Furthermore, I was stuck with the test app: #1226 (comment) - and I have no idea what it should do if it's successful or not, so if you had a guide on how to quickly test and validate it's functionality would be great.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or unsubscribe.
Triage notifications on the go with GitHub Mobile for iOS or Android.
|
|
Alright, then I understand. |
FYI, I believe that you can find copies of all the relevant documentation here (though I do not think those are the latest versions?): https://github.com/zigpy/zigpy-znp/tree/dev/docs The latest versions of same TI Z-Stack SDK documentation looks to be available from the official Texas Instruments source here: https://dev.ti.com/tirex/explore/node?node=AGfGICF0XoQz0l9l-rT2Qg__BSEc4rl__LATEST "SimpleLink CC13xx CC26xx SDK" (version 5.30.00 and later) covers CC2652 and CC1352 which are used for TI Zigbee Coordinator: https://www.ti.com/tool/SIMPLELINK-CC13XX-CC26XX-SDK PS: The very latest is TI SimpleLink CC13xx and CC26xx SDK version 5.30.00.56 which was released on the 27th of October 2021. |
|
A tip is that ITead now has their Sonoff branded CC2652P based USB dongles back in stock again for $10.99 (US) at least for now: https://itead.cc/product/sonoff-zigbee-3-0-usb-dongle-plus/ Also highly recommend it buying with a "1.5M USB Male to Female Extension Cable" to avoid EMF and fitting any tight USB-port. |
|
Hi @Hedda , Do you have any idea where I can find the original Z-STACK 3.x.0 coordinator firmware of the sonoff CC2562P dongle? Regards, |
It depends what exactly you mean by "the original Z-STACK 3.x.0 coordinator firmware of the sonoff CC2562P dongle" in context. ITead's Sonoff CC2652P dongle just uses Koenkk's Z-Stack 3.x.0 firmware that is initially built for the Zigbee2MQTT community. Koenkk's same firmware releases that other manufacturers that design Zigbee coordinator adapters for DIY communities, which include Zigbee implementations in other popular open-source applications like Home Assistant, ioBroker, Jeedom, and Domoticz. https://github.com/Koenkk/Z-Stack-firmware/tree/master/coordinator/ https://github.com/Koenkk/Z-Stack-firmware/blob/master/coordinator/Z-Stack_3.x.0/bin/README.md That is, it was early on confirmed by the community that ITead has at least shipped the first two batches ship pre-flashed with Koenkk's Z-Stack 3.x.0 firmware version 20210120 for "C1352P2_CC2652P_launchpad_coordinator" (CC1352P2_CC2652P_launchpad_20210120.zip) taken from https://github.com/Koenkk/Z-Stack-firmware/tree/master/coordinator/Z-Stack_3.x.0/bin I understand that it was only after Koenkk was contacted and some kind of unknown (and probably informal and unofficial) contact was established between ITead and developer(s) in the zigbee2mqtt community. I assume newer batches of ITead's Sonoff CC2562P dongle will probably just continue to ship pre-flashed with newer and newer releases of Koenkk's Z-Stack 3.x.0 firmware if they want users to get a better initial experience. There is more discussion about that here: and in: FYI, I also sent a mail to tITead requesting a firmware with Hardware Flow Control enabled and got the reply from ITead's project manager on this product that they currently no plans on releasing their own firmware images that they have built themselves and instead they intend on using community provided firmware as well as indirectly assist by continuing to provide instructions/guides on how the community can build and compile them own firmware images for it. More on that here: ITead has so far provided this guide for how to flash firmware and it included intructions on how to build with HW flow control: https://sonoff.tech/wp-content/uploads/2021/11/Zigbee-3.0-USB-dongle-plus-firmware-flashing-.docx (That doc was posted in https://sonoff.tech/product-review/zigbee-3-0-usb-dongle-plus/ which is their own official "review"). So to compile your own firmware you need to download and use "SimpleLink CC13xx CC26xx SDK" from Texas Instruments: https://www.ti.com/tool/SIMPLELINK-CC13XX-CC26XX-SDK https://www.ti.com/tool/download/SIMPLELINK-CC13XX-CC26XX-SDK To modify it to make it comparative to Koenkk's Z-Stack 3.x.0 firmware you need to apply this patch to code before compiling: https://github.com/Koenkk/Z-Stack-firmware/blob/master/coordinator/Z-Stack_3.x.0/firmware.patch https://github.com/Koenkk/Z-Stack-firmware/blob/master/coordinator/Z-Stack_3.x.0/COMPILE.md That patch makes these changes compared to the SDK default build: https://github.com/Koenkk/Z-Stack-firmware/blob/master/coordinator/Z-Stack_3.x.0/CHANGELOG.md PS: Please note that there are also discussions for non-developers about this and the Sonoff CC2652P dongle in forum here: |
|
Do you know why SonOff has a silicon labs bridge, meanwhile CC2531EMK Daughter card doesn't? What does the silicon labs bridge offer? |
@Aimen-Hammou That is really off-topic for here but as I wondered the same and have drawn a few conclusions and made some educated guesses based on ITead's product history and period product was developed based on when it was finally released. So I posted my speculations in the OpenHAB community forum instead as a reply -> https://community.openhab.org/t/sonoff-zigbee-3-0-usb-dongle-plus-by-itead-is-based-on-texas-instruments-cc2652p-can-now-be-ordered-for-10-99/126738/29 |
|
FYI; @leonschenk posted now in OpenHAB community forum here https://community.openhab.org/t/discussion-about-texas-instruments-z-stack-3-0-and-cc2652-and-cc1352-zigbee-coordinator-adapters-with-openhab-zigbee-binding/129385/4 Summery; leonschenk has now picked up the development on driver support for Z-Stack 3 (CC2652/1352) where @t-8ch left it, forking his branch of the zstack driver with Z-Stack 3 support to https://github.com/leonschenk/com.zsmartsystems.zigbee/tree/zstack/initial in order to continue the work of adding initial support for CC2652/CC1352 based adapters with Z-Stack 3.x.0 Zigbee Coordinator firmware https://github.com/Koenkk/Z-Stack-firmware/tree/master/coordinator/Z-Stack_3.x.0/bin Hopefully once leonschenk feels that it works good enough for review he will create a new pull request to the com.zsmartsystems.zigbee ZigBee Cluster Library Java framework//libraries that OpenHAB's ZigBee Binding and other projects depend on https://github.com/zsmartsystems/com.zsmartsystems.zigbee |
PR #1352 by @leonschenk with new "zstack" driver for Texas Instruments Z-Stack 3 dongles should now be ready to be reviewed. As he notes here it should be a non-breaking change as the new "zstack" driver does not at this point replace the "cc2531" driver:
|
Is your feature request related to a problem? Please describe.
This is a feature request as there is today currently no support for Z-Stack 3 / Z-Stack 3.x.x (Texas Instruments Zigbee 3.x stack)?
Z-Stack 3 support is needed to be compliant with adapters like CC2652/CC2652P/CC2652R/CC2652RB and CC1352/CC1352P.
https://github.com/Koenkk/Z-Stack-firmware/blob/master/coordinator/Z-Stack_3.x.0/bin/README.md
As it looks there is currently only support for the older and obsolete/deprecated Z-Stack Home 1.2 from Texas Instruments?
https://www.ti.com/tool/Z-STACK-ARCHIVE
Texas Instruments USB adapters based on CC2652/CC2652P/CC2652R/CC2652RB are very popular as Zigbee 3.0 compliant Zigbee coordinators among other open source home automation projects/communities (inc. Zigbee2MQTT, IoBroker, and Home Assistant).
Personally, I can recommend Electrolama zzh (zig-a-zig-ah) CC2652R USB stick/dongle which is open-source hardware:
https://electrolama.com/projects/zig-a-zig-ah/
https://github.com/electrolama/zig-a-zig-ah
Describe the solution you'd like
Full support for Z-Stack 3 API for Texas Instruments adapters running Z-Stack 3 firmware (Z-Stack 3.0.x and Z-Stack 3.x.x).
The primary goal would be to use the newer and more powerful USB adapter based on Texas Instruments CC2652/CC2652P/CC2652R/CC2652RB and CC1352/CC1352P which today can be found from many suppliers:
https://github.com/Koenkk/Z-Stack-firmware/tree/master/coordinator
Hopefully, it will also lead to full Zigbee 3.0 compliance but that is only a secondary goal and probably not really a priority.
http://www.ti.com/lit/an/swra615a/swra615a.pdf
Describe alternatives you've considered
The primary alternative today, if you like to like a Zigbee 3.0 compliant Zigbee coordinator USB adapter for creating a Zigbee 3 network, is to go with a newer Silicon Labs EmberZNet based adapter like EFR32 (EFR32MG12 or EFR32MG21).
Additional context
While not recommended for a "production" Zigbee network it is possible for testing and development purposes to flash CC2538, CC2531 and CC2530 based USB adapters with Z-Stack 3.0.x firmware:
https://github.com/Koenkk/Z-Stack-firmware/tree/master/coordinator/Z-Stack_3.0.x/bin
If you today have a CC2531 USB adapter that is already flashed with Z-Stack Home 1.2 firmware then you can now actually upgrade to a Z-Stack 3.0.x firmware yourself quite easily via USB using zigpy-znp command-line tools (as a stand-alone tool):
https://github.com/zigpy/zigpy-znp/blob/dev/TOOLS.md
Note! Be sure to do a backup before you upgrade from Z-Stack Home 1.2 firmware to Z-Stack 3.0.x firmware as you will need to restore that backup afterwards as the upgrade procedure will perform an initialization of the adapter.
https://github.com/zigpy/zigpy-znp/blob/dev/TOOLS.md#backup-and-restore
By the way, zigpy-znp supports bidirectional migration between any coordinators via Open ZigBee Coordinator Backup Format
https://github.com/zigpy/open-coordinator-backup/
PS: Zigbee2MQTT have lists of TI adapters that are made for Z-Stack 3 (Z-Stack 3.x.x) as well as precompiled firmware images:
https://www.zigbee2mqtt.io/information/supported_adapters.html
https://github.com/Koenkk/Z-Stack-firmware/tree/master/coordinator/Z-Stack_3.x.0/bin
More information on those adapters including recommendations can be found here:
https://www.zigbee2mqtt.io/guide/adapters (previously https://www.zigbee2mqtt.io/information/supported_adapters.html )
The text was updated successfully, but these errors were encountered: