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

[Hedda]

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

Adapter	TI Chip/Module Used	Firmware to Flash	BSL Trigger Pin (1)	Auto-BSL (2)	RF Switch Control Pins (3)	LED(s)
TI LAUNCHXL-CC26xR1	CC2652R	CC2652R_*.zip	DIO_13	No	N/A	DIO_6 (Red)DIO_7 (Green)
TI LAUNCHXL-CC1352P-2	CC1352P	CC1352P2_CC2652P_launchpad_*.zip	DIO_15	No	DIO_28: 2.4GhzDIO_29: 20dBm PADIO_30: Sub-1GHz	DIO_6 (Red)DIO_7 (Green)
Electrolama zzh	CC2652R	CC2652R_*.zip	DIO_13	No	N/A	DIO_7 (Pink)
Electrolama zzhp-lite	CC2652P(Ebyte E72)	CC1352P2_CC2652P_other_*.zip	DIO_15	Yes	DIO_5: 20dBm PA ??DIO_6: 2.4GHz ??	DIO_7 (Pink)
Electrolama zzhp	CC2652P	CC1352P2_CC2652P_other_*.zip	DIO_15	Yes	DIO_5: 20dBm PA ??DIO_6: 2.4GHz ??	DIO_7 (Pink)
Electrolama zoe2	CC1352P(Ebyte E79)	CC1352P2_CC2652P_other_*.zip	DIO_15	No	DIO_5: 20dBm PA ??DIO_6: 2.4GHz ??	DIO_7 (Pink)
Slaesh's CC2652RB stick	CC2652RB	CC2652RB_*.zip	DIO_13	Yes	N/A	DIO_7 (Blue)
ZigStar Stick v4	CC2652P(RFSTAR RF-BM-2652P2)	CC1352P2_CC2652P_launchpad_*.zip	DIO_15	Only for CH340C ver.	DIO_28: 2.4GhzDIO_29: 20dBm PA	DIO_6 (Green)DIO_7 (Red)
Tube's CC2652P2 USB Coordinator	CC2652P(RFSTAR RF-BM-2652P2)	CC1352P2_CC2652P_launchpad_*.zip	DIO_15	N/A	DIO_28: 2.4GhzDIO_29: 20dBm PA	N/A
Tube's Zigbee Gateways (CC2652P2 variant)	CC2652P(RFSTAR RF-BM-2652P2)	CC1352P2_CC2652P_launchpad_*.zip	DIO_15	N/A	DIO_28: 2.4GhzDIO_29: 20dBm PA	N/A
Tube's Zigbee PoE (Power Over Ethernet) Serial Coordinator (CC2652P2 variant)	CC2652P(RFSTAR RF-BM-2652P2)	CC1352P2_CC2652P_launchpad_*.zip	DIO_15	N/A	DIO_28: 2.4GhzDIO_29: 20dBm PA	N/A
Egony Stick V4 (Ebyte ver.)	CC2652P(Ebyte E72-2G4M20S1E)	CC1352P2_CC2652P_other_*.zip	DIO_15	Yes(from Rev.2.0)	DIO_5: 20dBm PADIO_6: 2.4GHz	DIO_8 (Green)DIO_7 (Red)
Gio-dot Z-Bee Duo with CC2652P	CC2652P(Ebyte E72-2G4M20S1E)	CC1352P2_CC2652P_other_*.zip	DIO_15	Yes(from Rev.2.0)	DIO_5: 20dBm PADIO_6: 2.4GHz	DIO_8 (Green)DIO_7 (Red)
Egony Stick V4 (RFSTAR ver.)	CC2652P(RFSTAR RF-BM-2652P2)	CC1352P2_CC2652P_launchpad_*.zip	DIO_15	Yes	DIO_28: 2.4GhzDIO_29: 20dBm PA	DIO_7 (Green)DIO_6 (Red)
cod.m Zigbee CC2652P RPi Module	CC2652P(RFSTAR RF-BM-2652P2)	CC1352P2_CC2652P_launchpad_*.zip	DIO_15	Yes	DIO_28: 2.4GhzDIO_29: 20dBm PA	DIO_7 (Green)DIO_6 (Red)
Gio-dot Z-Bee Duo with CC2652P	CC2652P (Ebyte E72-2G4M20S1E)	CC1352P2_CC2652P_other_*.zip	DIO_15	Yes (from Rev.2.0)	DIO_5: 20dBm PA	DIO_8 (Green) DIO_7 (Red)
cyijun OpenZ3Gateway	CC2652P (RFSTAR RF-BM-2652P2 SMA Ant.)	CC1352P2_CC2652P_launchpad_*.zip	DIO_15	No	DIO_28: 2.4Ghz DIO_29: 20dBm PA	DIO_7 (Green) DIO_6 (Red)
SONOFF Zigbee 3.0 USB Dongle Plus	CC2652P	CC1352P2_CC2652P_launchpad_*.zip	?	No	?	?

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 )

[cdjackson]

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

[Hedda]

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.

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).

[cdjackson]

OK. Then posted to openhab/org.openhab.binding.zigbee#649

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.

Texas Instruments USB dongles/sticks based on CC2652/CC2652P/CC2652R/CC2652RB are very popular

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.

[emilm]

Is the command set totally different between 1.2 and 3.0 ? Because adapter shows up with "Unknown" status.
I have a CC2652P2 based adapter with the 3.0 stack installed. I know Java, so how can I help?
What needs to be done, exactly to get this properly recognized and operational in OpenHAB?

[cdjackson]

Is the command set totally different between 1.2 and 3.0 ?

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.

What needs to be done, exactly to get this properly recognized and operational in OpenHAB?

There would need to be a driver implemented to support the chipset - similar to the ones that are implemented for the other chips.

[emilm]

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:
https://github.com/Koenkk/zigbee-herdsman/blob/master/src/adapter/z-stack/adapter/nvItems.ts
https://github.com/Koenkk/zigbee-herdsman/blob/master/src/adapter/z-stack/adapter/zStackAdapter.ts

Would this shed some light on how different they are?

[cdjackson]

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.

[emilm]

OK. Can't find the API documentation, and I do it faster reading the code.
I bought 2 zigbee devices thinking they would be compatible with 1.2 but seems like many new devices are strictly 3.0 . So my guess is that there will more of this.

To me, it seems like there's not much differences, but it fails to reset in my case:

2021-04-28 14:29:51.165 [DEBUG] [bee.discovery.ZigBeeDiscoveryService] - Starting ZigBeeDiscoveryService
2021-04-28 14:29:51.676 [DEBUG] [bee.handler.ZigBeeCoordinatorHandler] - Initializing ZigBee network [zigbee:coordinator_cc2531:baaa34bafc].
2021-04-28 14:29:51.680 [DEBUG] [bee.handler.ZigBeeCoordinatorHandler] - Channel 11
2021-04-28 14:29:51.682 [DEBUG] [bee.handler.ZigBeeCoordinatorHandler] - PANID 31409
2021-04-28 14:29:51.684 [DEBUG] [bee.handler.ZigBeeCoordinatorHandler] - EPANID AB8165E5491D8BDA
2021-04-28 14:29:51.688 [DEBUG] [bee.handler.ZigBeeCoordinatorHandler] - Network Key 3903473C0DB0CA4AA92A6B5FBACB919C
2021-04-28 14:29:51.689 [DEBUG] [bee.handler.ZigBeeCoordinatorHandler] - Link Key 5A6967426565416C6C69616E63653039
2021-04-28 14:29:51.692 [DEBUG] [bee.handler.ZigBeeCoordinatorHandler] - Config: zigbee_initialise found, initializeNetwork=false
2021-04-28 14:29:51.695 [DEBUG] [bee.handler.ZigBeeCoordinatorHandler] - Network Key String 3903473C0DB0CA4AA92A6B5FBACB919C
2021-04-28 14:29:51.697 [DEBUG] [bee.handler.ZigBeeCoordinatorHandler] - Network key final array 3903473C0DB0CA4AA92A6B5FBACB919C
2021-04-28 14:29:51.699 [DEBUG] [bee.handler.ZigBeeCoordinatorHandler] - Link Key String 5A6967426565416C6C69616E63653039
2021-04-28 14:29:51.703 [DEBUG] [bee.handler.ZigBeeCoordinatorHandler] - Link key final array 5A6967426565416C6C69616E63653039
2021-04-28 14:29:51.705 [DEBUG] [.zigbee.cc2531.handler.CC2531Handler] - Initializing ZigBee CC2531 serial bridge handler.
2021-04-28 14:29:51.827 [DEBUG] [.zigbee.cc2531.handler.CC2531Handler] - ZigBee CC2531 Coordinator opening Port:'/dev/ttyZIGBEE0' PAN:7ab1, EPAN:AB8165E5491D8BDA, Channel:11
2021-04-28 14:29:51.842 [DEBUG] [bee.handler.ZigBeeCoordinatorHandler] - Scheduling ZigBee start
2021-04-28 14:29:52.854 [DEBUG] [bee.handler.ZigBeeCoordinatorHandler] - ZigBee network starting
2021-04-28 14:29:52.856 [DEBUG] [bee.handler.ZigBeeCoordinatorHandler] - Initialising ZigBee coordinator
2021-04-28 14:29:52.914 [DEBUG] [e.transaction.ZigBeeTransactionQueue] - Default: Set profile to ZigBeeTransactionProfile [maxOutstandingTransactions=1, interTransactionDelay=50, maxRetries=2]
2021-04-28 14:29:52.917 [DEBUG] [e.transaction.ZigBeeTransactionQueue] - Broadcast: Set profile to ZigBeeTransactionProfile [maxOutstandingTransactions=2, interTransactionDelay=4000, maxRetries=0]
2021-04-28 14:29:52.919 [DEBUG] [e.transaction.ZigBeeTransactionQueue] - Multicast: Set profile to ZigBeeTransactionProfile [maxOutstandingTransactions=3, interTransactionDelay=1200, maxRetries=0]
2021-04-28 14:29:52.940 [DEBUG] [tsystems.zigbee.ZigBeeNetworkManager] - ZigBeeNetworkManager initialize: networkState=UNINITIALISED
2021-04-28 14:29:52.942 [DEBUG] [tsystems.zigbee.ZigBeeNetworkManager] - Network state is updated to INITIALISING
2021-04-28 14:29:52.949 [DEBUG] [e.dongle.cc2531.ZigBeeDongleTiCc2531] - CC2531 transport initialize
2021-04-28 14:29:52.953 [DEBUG] [nding.zigbee.serial.ZigBeeSerialPort] - Connecting to serial port [/dev/ttyZIGBEE0] at 38400 baud, flow control FLOWCONTROL_OUT_RTSCTS.
2021-04-28 14:29:52.958 [DEBUG] [bee.handler.ZigBeeCoordinatorHandler] - null: networkStateUpdated called with state=INITIALISING
2021-04-28 14:29:53.041 [DEBUG] [nding.zigbee.serial.ZigBeeSerialPort] - Serial port [/dev/ttyZIGBEE0] is initialized.
2021-04-28 14:29:58.082 [WARN ] [.cc2531.network.ZigBeeNetworkManager] - Dongle reset failed. Assuming bootloader is running and sending magic byte 0xef.
2021-04-28 14:29:58.340 [INFO ] [zwave.handler.ZWaveControllerHandler] - Attempting to add listener when controller is null
2021-04-28 14:30:03.084 [WARN ] [.cc2531.network.ZigBeeNetworkManager] - Attempt to get out from bootloader failed.
2021-04-28 14:30:03.116 [DEBUG] [nding.zigbee.serial.ZigBeeSerialPort] - Serial port '/dev/ttyZIGBEE0' closed.

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.
I was hoping for you with the expertise on the protocol itself and your own library could quickly (relative term I know) spot the extra 3.x stuff. My hunch, it isn't all that much.

But if you don't even have time to look, it would be difficult for me to jump in and support it.

[cdjackson]

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.

2021-04-28 14:30:03.084 [WARN ] [.cc2531.network.ZigBeeNetworkManager] - Attempt to get out from bootloader failed.

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.

[emilm]

Thanks a lot, maybe I can get it to work locally first.
Is there some way to do a quick setup and run a sequence of commands to verify that it works without running OpenHAB?
I run Windows and I would imagine this could be set up to work with a COM port or something.

[cdjackson]

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.

[emilm]

Thanks a lot! I totally missed that.

[Hedda]

zigbee2mqtt supports both adapters in the same code, it seems like:
https://github.com/Koenkk/zigbee-herdsman/blob/master/src/adapter/z-stack/adapter/nvItems.ts
https://github.com/Koenkk/zigbee-herdsman/blob/master/src/adapter/z-stack/adapter/zStackAdapter.ts

Would this shed some light on how different they are?

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

[Hedda]

Can't find the API documentation

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

https://software-dl.ti.com/simplelink/esd/simplelink_cc13x2_26x2_sdk/4.20.00.35/exports/docs/Documentation_Overview.html

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

[emilm]

@cdjackson
I tried it om my windows 10 x64, but ran into a problem. Got access violation with

 <dependency>
     <groupId>org.scream3r</groupId
     <artifactId>jssc</artifactId>
     <version>2.8.0</version>
 </dependency>

Had to use

<dependency>
    <groupId>io.github.java-native</groupId>
    <artifactId>jssc</artifactId>
    <version>2.9.2</version>
</dependency>

After running with -d CC2531 -p COM5 -b 115200 I get this:

ZigBee network state updated to INITIALISING
networkManager.initialize returned SUCCESS
PAN ID = 65535
Extended PAN ID = 0000000000000000
Channel = UNKNOWN

Does this look correct?

[puddly]

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 CStruct system for alignment detection and serialization/deserialization. If you're looking for just the raw commands, install zigpy-znp from Git (pip install git+https://github.com/zigpy/zigpy-znp/) and run one of the command line tools in verbose mode (use -vv to see the bytes being sent/received):

$ python -m zigpy_znp.tools.form_network -v /dev/cu.usbserial-1420  # or COM5
...

[cdjackson]

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.

[puddly]

I guess the question is if this has changed?

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.

[Hedda]

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 CC2531ZNP-without-SBL.bin to your stick directly with zigpy_znp: python -m zigpy_znp.tools.flash_write -i /path/to/CC2531ZNP-without-SBL.bin /dev/serial/by-id/YOUR-CC2531 if your CC253x stick already has a serial bootloader.

https://github.com/zigpy/zigpy-znp/blob/dev/TOOLS.md

[Hedda]

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:

Koenkk/zigbee2mqtt#1445

Koenkk/zigbee2mqtt#211

Koenkk/zigbee2mqtt#1429

FYI, Tasmota Zigbee2Tasmota/Z2T project which previously only supported Z-Stack Home 1.2 also added support for Z-Stack 3:

arendst/Tasmota#11016

Zigbee compatibility with CC2652 ("The initialization sequence is now using SYS_OSAL_NV_READ/WRITE instead of SAPI_READ/WRITE_CONFIGURATION")

arendst/Tasmota#11034

Zigbee fix cc2652 init and permitjoin ("Fix PermitJoin indicator for ZStack 3" + "Fix init issue with ZStack 1.2 introduced by #11016")

[cdjackson]

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

[t-8ch]

@cdjackson I am starting to look into your existing branch zstack_driver.
Do you have any concrete pointers about what still needs to be done?

[cdjackson]

Do you have any concrete pointers about what still needs to be done?

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.

[emilm]

@cdjackson I am starting to look into your existing branch zstack_driver. Do you have any concrete pointers about what still needs to be done?

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"

[cdjackson]

arendst/Tasmota@62886b5 could be a good pointer.

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.

[emilm]

arendst/Tasmota@62886b5 could be a good pointer.

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

[cdjackson]

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.

[t-8ch]

@cdjackson
So far I got it running with my CC22652 stick. It only needed light forward porting of your branch and same adaption to the reset logic.
My test device shows up in the network manager but the attributes seem to be all zeros.
It is also not detecten in OpenHAB. I'll have to play with this some more.
If you want I can open a WIP pullrequest to share the ongoing work.

[cdjackson]

If you want I can open a WIP pullrequest to share the ongoing work.

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.

My test device shows up in the network manager but the attributes seem to be all zeros.

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.

[emilm]

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.

I find it easier to read code than documentation.

[cdjackson]

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.

[emilm]

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) .

[cdjackson]

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 :)

[emilm]

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.

Seems like you got it under control, good luck

Anyone is welcome to help - that’s open source :)

That's also a two way street. :)

[cdjackson]

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.

[emilm]

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. But .... this was in May.

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.

[cdjackson]

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.

[emilm]

Alright, then I understand.

[Hedda]

not being able to find the documentation

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

https://software-dl.ti.com/simplelink/esd/simplelink_cc13xx_cc26xx_sdk/5.30.00.56/exports/docs/Documentation_Overview.html

https://software-dl.ti.com/simplelink/esd/simplelink_cc13xx_cc26xx_sdk/5.30.00.56/exports/docs/zigbee/html/zigbee/znp_interface.html

https://software-dl.ti.com/simplelink/esd/simplelink_cc13xx_cc26xx_sdk/5.30.00.56/exports/docs/zigbee/html/zigbee/znp_interface.html#znp-software-command-interface

"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.

[Hedda]

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.

[Aimen-Hammou]

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?
Or it uses the ZigBee2MQTT's one?

Regards,
Aiman

[Hedda]

Do you have any idea where I can find the original Z-STACK 3.x.0 coordinator firmware of the sonoff CC2562P dongle?
Or it uses the ZigBee2MQTT's one?

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:

Koenkk/zigbee2mqtt#8840

and in:

Koenkk/zigbee2mqtt#9744

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:

Koenkk/Z-Stack-firmware#324

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:

https://community.openhab.org/t/discussion-about-ti-z-stack-3-x-and-cc2652-and-cc1352-zigbee-coordinator-adapters-with-openhab-zigbee-binding/129385

https://community.openhab.org/t/sonoff-zigbee-3-0-usb-dongle-plus-by-itead-is-based-on-texas-instruments-cc2652p-can-be-pre-ordered-for-10-99/126738/

[Aimen-Hammou]

@Hedda

Do you know why SonOff has a silicon labs bridge, meanwhile CC2531EMK Daughter card doesn't? What does the silicon labs bridge offer?

[Hedda]

@Hedda 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

[Hedda]

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

[Hedda]

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:

just to clarify, that new “zstack” driver will initially only add support for the newer the newer Z-Stack 3.x.0 Zigbee Coordinator firmware (used on the new C2652/CC1352 based adapters) and will at this time not even affect the existing “CC2531” driver for the older Z-Stack Home 1.2 firmware (used on the old CC253x/C2530/CC2531 based adapters) that use from Texas Instruments, is that correct?

you are correct. I can only test with my Sonoff device at home. It may also not have all capabilities people want.