Zstack driver

As discussed in #1226

This is a rebased version of your zstack_driver branch. Most of the patches are 1:1 rebases of yours.

Beginning from my patches:

1. Updates the pom.xml files to match the current versions in the repo.
2. Is a small cleanup
3. Adds a new reset sequence that is necessary for my device.

My setup:

• Slae.sh CC2652 Stick with firmware CC2652RB_coordinator_20210708 from Koenkk
• Aqara Mini Switch
• Philips Hue Dimmer switch

Current status:

• The Aqara switch gets found but not fully discovered. This could maybe be a weak battery and I will retest it with a new one soon.
• The Battery of the Philips switch is dead and I will have to get a new one, too.

Nice! Are you testing with Koenkk's firmware images from "develop" branch or "master" branch (currently "20210708"), or other?

https://github.com/Koenkk/Z-Stack-firmware/tree/master/coordinator/Z-Stack_3.x.0/bin

https://github.com/Koenkk/Z-Stack-firmware/tree/develop/coordinator/Z-Stack_3.x.0/bin

FYI, 20211114 currently in develop branch is based on TI SDK 5.30.00.56 comparing to it should in practice only have bug fixes.

@Hedda 20210708 as written in the PR description.

@t-8ch Hi, could you explain how did you test the code? I have a CC2562P with ZSTACK 3.X.0 and a zigbee thermostat; would like to test the code to it.

Edit: I forgot to add what I tried: Cloned the repository, run mvn clean install and it gives me error regarding missing headers(?) used the .skip=true flag and still fails. Git cloned using Eclipse, SLF4J missing because MVN cannot run; Pretty confused on what to do.

(also: where did you find informations regarding ZStack Booting and startup sequence? Can't understand what changes between 1.2 to 3.X.0)

@Aimen-Hammou This should be explained in the docs. You should probably wait with enduser-testing until it is confirmed that it works in general.

@t-8ch Tried the DOCS, nothing. Even the main repository doesn't work tbh

@Aimen-Hammou Then it would be best to open a new ticket for that and describe the issue in more detail there.

@t-8ch Ok, thank you. Out of curiosity: where did you find informations regarding ZStack 3.X.0 and the startup process?

@Aimen-Hammou The schematics show that RTS and DTR of the USB-UART adapter are wired to Reset and BOOTLOADER_ENABLE of the CC2652. So what this does is: Assert BOOTLOADER_ENABLE and force reset the CC2652 which will then bypass the bootloader. (This is specified in the CC2652 datasheet)

where did you find informations regarding ZStack 3.X.0 ...

FYI, the latest versions of 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.

@t-8ch @Hedda Thank you so much for the time!

Thanks @t-8ch

Regarding the firmware that is being used for testing - is this a "standard" TI version? ie there's nothing too much different - just tweaking table sizes etc? I would just like that this conforms to the standard API and doesn't rely on anything from other projects that is non-standard.

Regarding the reset - again - is this standard on all devices, or is this somehow implementation specific. If it's implementation specific (as I suspect?) then it would be good to make this configurable so that it's not locked to the hardware you use. In the Ember driver I have a ResetProvider which if set can be used to generate reset sequences, and then different implementations can implement this as they see fit. I think it would be wise to do something similar to ensure we're implementation agnostic.

I think you know what you're doing here so probably you don't need me, but if there's anything you want me to answer or help with, just shout.

@Aimen-Hammou as I have said a few times now, if you have questions, then please open a ticket and I can try and help, however this project does compile just fine, so I'm not sure why you are getting errors. Please though, let's discuss separately.

@cdjackson This should be the difference to the vanilla Zstack firmware from TI: https://github.com/Koenkk/Z-Stack-firmware/blob/master/coordinator/Z-Stack_3.x.0/firmware.patch It doesn't look to make any changes to the actual protocol.

A resetprovider looks reasonable. I will try to refactor that part during the cleanup phase.

As I got to it to generally recognize the Aqara Button I am confident in both the hardware and your existing code. The failure for a complete pair I blame on the Button being a Xiaomi device. Going forward I'll work with the switch, but it uses a not-so-common batterytype, and I did not yet get one of those.

.. but if there's anything you want me to answer or help with, just shout.

Thanks, will do.

Regarding the firmware that is being used for testing - is this a "standard" TI version? ie there's nothing too much different - just tweaking table sizes etc? I would just like that this conforms to the standard API and doesn't rely on anything from other projects that is non-standard.

The patch that Koen applies to each of his builds can be found in that same repo with a changelog and steps on how it's compiled:

https://github.com/Koenkk/Z-Stack-firmware/blob/develop/coordinator/Z-Stack_3.x.0/CHANGELOG.md

https://github.com/Koenkk/Z-Stack-firmware/blob/develop/coordinator/Z-Stack_3.x.0/firmware.patch

https://github.com/Koenkk/Z-Stack-firmware/blob/develop/coordinator/Z-Stack_3.x.0/COMPILE.md

@Koenkk Perhaps you would be willing to futher summarize how your Z-Stack 3.x.0 coordinator FW builds differ from TI's default?

Summary from changelog shortened:

• Increase memory heap
• Turn on/off leds when joining is enabled/disabled
• Fix Xiaomi E1 devices not (fully) working
• Allow setting transmit power for CC2652P/CC1352P greater than 5dBm (max 20dBm), default transmit power is set to 9dBm
• Increase MAC buffers, increases performance on message burst and reduces MAC_TRANSACTION_OVERFLOW errors
• LED control
• Fix joining not working when joining is only permitted on specific router
• Forward message to host even when profileID does not match
• Optimize network parameters (according to https://www.ti.com/lit/an/swra650b/swra650b.pdf)
• Change default CC2652R/CC2652RB/CC1352P-2/CC2652P transmit power from 0dBm to 5dBm
• Potential fix for Hue end devices disconnecting
• Expose AssocAdd function
• Allow support for Samsung SmartThings PGC410EU presence sensor (link)
• Fix commands to long sleeping end devices failing when directly connected to coordinator (e.g. Xiaomi JTYJ-GD-01LM/BW)
• Expose AssocRemove function
• Remove and rediscover route on source route failure (should fix issues with e.g. Hue enddevices dropping off) (more info)
• Fix devices not able to reconnect when attempt unsecured rejoin (more info)
• Enable parent announce, fixes devices not reachable when changing parents while coordinator is down.
• Increase max number of Zigbee 3.0 devices that can join to 200
• Increased group command buffer

• upstream fixes from Texas Instruments SimpleLink SDK:

https://software-dl.ti.com/simplelink/esd/simplelink_cc13xx_cc26xx_sdk/5.30.01.01/exports/changelog.html

This pull request introduces 7 alerts when merging 7dd394a783907b587a4bd4f706e961891fb1edc8 into 2318aa53121be9ad96dc063b9a77bba280805eef - view on LGTM.com

new alerts:

• 4 for Dereferenced variable may be null
• 2 for Spurious Javadoc @param tags
• 1 for Useless comparison test

My setup:

• Slae.sh CC2652 Stick with firmware CC2652RB_coordinator_20210708 from Koenkk
• Aqara Mini Switch
• Philips Hue Dimmer switch

Current status:

• The Aqara switch gets found but not fully discovered. This could maybe be a weak battery and I will retest it with a new one soon.

FYI, the latest firmware from Koenkk's develop branch contains a fix for newer Aqara E1 / Xiaomi E1 devices + TI's upstream fixes:

https://github.com/Koenkk/Z-Stack-firmware/tree/develop/coordinator/Z-Stack_3.x.0/bin

https://github.com/Koenkk/Z-Stack-firmware/blob/develop/coordinator/Z-Stack_3.x.0/CHANGELOG.md

Update! Z-Stack 3.x.0 20211217 release has now been copied to their master branch and as such should be seen as stable:

https://github.com/Koenkk/Z-Stack-firmware/tree/master/coordinator/Z-Stack_3.x.0/bin

https://github.com/Koenkk/Z-Stack-firmware/blob/master/coordinator/Z-Stack_3.x.0/CHANGELOG.md

Note however that new firmware does however not specifically mention the even newer Aqara T1 / Xiaomi T1 series of devices.

PS: Regardless, Aqara and Xiaomi devices (as well as Tuya manufactured Zigbee devices) do not make for a good reference as they are infamously known for deviating from standard Zigbee Cluster Library specification causing interoperability/compatibility issues.

I'm interested in this PR. Has there been any more progress?

@t-8ch Any news/updates on this PR for Z-Stack 3.0 Zigbee Coordinator driver support (to be used in openHAB ZigBee Binding)?

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

@t-8ch Any chance to get this merged?

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 that he now picked up the development 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 so hopefully once he feels 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 there is no real need to cross post this everywhere. I'm in discussion about this already and we don't really need spam posts everywhere which doesn't add anything!

I'm interested in this PR. Has there been any more progress?

@NathanSweet I have a working development going on in https://github.com/zsmartsystems/com.zsmartsystems.zigbee/pull/1352

@leonschenk Thanks for the ping. While I'd love to be able to interface with ZB directly using Java, it's so low level that for me it would need to work out of the box. I ended up using zigbee2mqtt, which has been working very well and has good support. It's a little annoying to run a node process but at least the API via MQTT makes interfacing with it very easy.

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.