zsmartsystems
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
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 )
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
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 https://github.com/openhab/org.openhab.binding.zigbee/issues/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).
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.
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?
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.
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?
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. 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.
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.
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.
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.
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
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
@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?
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
...
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.
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.
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
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:
https://github.com/Koenkk/zigbee2mqtt/issues/1445
https://github.com/Koenkk/zigbee2mqtt/issues/211
https://github.com/Koenkk/zigbee2mqtt/issues/1429
FYI, Tasmota Zigbee2Tasmota/Z2T project which previously only supported Z-Stack Home 1.2 also added support for Z-Stack 3:
https://github.com/arendst/Tasmota/pull/11016
Zigbee compatibility with CC2652 ("The initialization sequence is now using SYS_OSAL_NV_READ/WRITE instead of SAPI_READ/WRITE_CONFIGURATION")
https://github.com/arendst/Tasmota/pull/11034
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 zstack_driver.
Do you have any concrete pointers about what still needs to be done?
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.
@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?
https://github.com/arendst/Tasmota/pull/11016/commits/62886b566a6799534495480b9077ed8b2f46fed0 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"
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.
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
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 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.
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.
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.