egony / cc2652p_cc1352p_rf-star Goto Github PK

I have a v4 stick based on RF-STAR with firmware 20210902.
While using this stick zigbee2mqtt crashes every few hours with the following error:

Sep 27 14:55:16 lily.vampik.net npm[4040342]: Error: SREQ '--> AF - dataRequestExt - {"dstaddrmode":2,"dstaddr":"0x000000000000fffd","destendpoint":242,"dstpanid":0,"srcendpoint":242,"clusterid":33,"transid":122,"options":0,"radius":30,"len":6,"data":{"type":"Buffer","data":[25,123,2,11,254,0]}}' failed with status '(0x10: MEM_ERROR)' (expected '(0x00: SUCCESS)')
Sep 27 14:55:16 lily.vampik.net npm[4040342]:     at Object.func (/opt/zigbee2mqtt/node_modules/zigbee-herdsman/src/adapter/z-stack/znp/znp.ts:315:27)
Sep 27 14:55:16 lily.vampik.net npm[4040342]:     at Queue.executeNext (/opt/zigbee2mqtt/node_modules/zigbee-herdsman/src/utils/queue.ts:32:32)

Downgrading to firmware 20210320 has solved the issue.
According to koenkk, this is a known issue with SDK 5.20.00.52: Koenkk/zigbee2mqtt#8885 (comment)

@egony Can you please consider providing OpenThread Border Router (OTBR) "RCP mode" firmware images well as "NCP mode" firmware images (with support for the OpenThread spinel+hdlc+uart protocol) and preferably using the latest SDK for this Texas Instruments CC2652 based adapter so that it will be compatible with the "OpenThread Border Router Add-on" that Home Assistant developer agners (Nabu Casa employee Stefan Agner) is currently developing? Check out:

https://github.com/home-assistant/addons-development/tree/master/openthread_border_router

https://github.com/openthread/ot-br-posix/

https://github.com/agners

https://community.home-assistant.io/u/agners/summary

https://groups.google.com/g/openthread-users/

OTBR should be a "Thread Certified Component" Texas Instruments CC2652 based chips:

https://github.com/openthread/ot-cc13x2-cc26x2/blob/main/src/cc2652/README.md

https://github.com/openthread/ot-cc13x2-cc26x2

https://github.com/openthread/openthread/tree/main/examples/platforms

https://dev.ti.com/tirex/explore/node?node=APzU0zOtgnQIe0sFnHCfxg__BSEc4rl__LATEST

https://openthread.io/vendors/texas-instruments

https://www.threadgroup.org/What-is-Thread/Thread-Benefits#certifiedproducts

https://training.ti.com/thread-cc2652-cc1352

The main reason for this request is that an "RPC" firmware with OTBR (OpenThread Border Router) support will make your adapter will be compatible with upcoming Thread based "Matter" (Project CHIP / Connected Home over IP) devices if used in Home Assistant with their other add-ons for the that is also in development. This addon by agners requires that the radio hard a firmware in "RPC" mode instead of the no traditional "NCP" mode:

https://github.com/home-assistant/addons-development/tree/master/chip_controller_repl

https://github.com/home-assistant/addons-development/tree/master/chip_tool

https://github.com/project-chip/connectedhomeip

https://buildwithmatter.com

https://csa-iot.org/all-solutions/matter/

Also having optional OpenThread "NCP" border router firmware would allow users to alternatively use other existing OpenThread applications that use "NCP" mode instead of the newer "RPC" mode which require additional component running on the host. Ex:

https://github.com/openthread/wpantund

Note that so far agners has only worked with Silicon Labs based adapter with OpenThread "RPC" firmware for Thread based Matter (as well as ESP32-C3 based devkit for Matter over WiFi) and that is only because it is a Silabs EFR32MG21 chip based adapter that will ship inside the official Home Assistant Yellow (formerly Home Assistant Amber) hardware:

zigpy/zigpy#894

https://github.com/home-assistant/addons-development/tree/master/silabs-multiprotocol

https://www.home-assistant.io/blog/2021/09/13/home-assistant-yellow/

https://www.crowdsupply.com/nabu-casa/home-assistant-yellow

PS: By the way, you might be interested in the the "Matter" workshop that Home Assistant is holding on the 15th of June even if they are in that specific workshop will not use a Thread based controller or devices and instead use a WiFi (+ Bluetooth) based "Matter" devices:

https://www.home-assistant.io/blog/2022/05/29/matter-in-home-assistant-workshop-announcement/

https://www.youtube.com/watch?v=9fOHBl5w0_k

https://community.home-assistant.io/t/matter-in-home-assistant-workshop-announcement/426129/

Hi all!

I recently obtained a couple of Lan Zigbee devices from China, and my goal is to designate one of them as a coordinator and the other as a router. I successfully flashed the coordinator and the router firmware. The coordinator started functioning well, being able to detect new devices without any issues.

However, I'm encountering difficulties connecting the router. Unfortunately, there are no instructions provided on how to switch it to pairing mode. Since the device only has one button, I suspect that I need to long-press it. However, despite my attempts, I haven't had any luck. The router doesn't appear in the zigbee2mqtt addon on my HA server.

I would greatly appreciate any suggestions or advice!

I have flashed newest available router firmware:

CC1352P2_CC2652P_launchpad_router_20220125

unfortunately router is not joining network. What could be the problem with this stick type? Previous firmware used worked, yet suffered from memory leak:
https://github.com/ptvoinfo/zigbee-configurable-firmware

FYI, Koenkk has now uploaded an experimental firmware for CC2652P/CC1352P with a default set to 9 dBm (and a max of 20 dBm):

Koenkk/Z-Stack-firmware#323

He mentions in Koenkk/zigbee2mqtt#8885 that he does not have RF measurement equipment so cannot confirm RF output power.

Would be great if you can test and verify Koenkk experimental firmware for CC2652P configurable up to 20 dBm TX power output.

Hey thanks for this great open source project!
I just received my shield I purchased of elekitsorparts.

I have an ODROID N2+ (same GPIO pinout as Rpi) running home assistant OS. I plug the shield in but don't seem to be getting any connection to it.

I've done a bit of searching but can't find any docs on how I can communicate with the shield (have the system recognise it). So that I can then set it up with zigbee2mqtt.

Any help or reference to useful docs is greatly appreciated!

Will you consider making CC2674/CC2674P/CC2674R and/or CC1354/CC1354P Zigbee adapters for developers and early adopters?

Check out this developer discussion in Koenkk's Z-Stack firmware repository -> Koenkk/Z-Stack-firmware#476

There is no community firmware from Koenkk yet but that is probably partially because no one made a CC2674 or CC1354 adapter yet.

Chicken or the egg, what comes first, early prototype adapters that Koenkk can test or firmware built in the blind?

FYI, E72-2G4M20S1C (CC2674P10) radio module from Ebyte/Cdebyte is already available for prototyping and first-to-market devices:

https://www.cdebyte.com/products/E72-2G4M20S1C

According to LSagiroglu this new CC2674P10 based module is is pin to pin compatible with their CC2652P based module:

https://www.cdebyte.com/products/E72-2G4M20S1E

PS: No news so far from RFstar if they are working on CC2674P or CC1354P radio modules yet.

@egony Please consider switching design to other USB-to-Serial converter chip with its own writable EEPROM as hardware feature.

This would allow you to add your own custom "Product Description String" as a unique identifier for it via the USB interface, and the reason for wanting a unique identifier via the USB interface is in order to enable the possibility for it to support automatic USB discovery of Zigbee USB adapters.

The whole point of this is to make it possible for developers to make the initial installation of Zigbee solution plug-and-play friendly and easier for different home automation software to automatically USB discover and initiate a setup without end-user interactions.

Support for USB discovery was recently added to Home Assistant OS (formerly HASSIO) and the ZHA integration for it, see here:

https://community.home-assistant.io/t/unique-friendly-name-description-for-automatic-zigbee-usb-adapter-discovery-in-home-assistant-zha-using-dongle-vendor-product-ids/337077

That unique customized USB description string could be something like ex.; "Egony RF-Star CC2652P Zigbee Stick v5 hardware revision 5.0.0".

The unique "description" string for each USB adapter can then be added to HA via a PR like this -> home-assistant/core#56201

As I understand it, cheaper CH340 series (example CH340C and CH340E) by WCH which unfortunately does not support this feature.

UPDATE! It has now been confirmed that the CH340B variant does have an EEPROM that support "Product Description String", etc.

http://www.wch-ic.com/products/CH340.html

I understand that more expensive chips like FT231 chips by FTDI and CP210x chips by Silicon Labs / Silabs do support this feature:

https://ftdichip.com/products/ft231xs/
https://ftdichip.com/products/ft231xq/

FT231X/FT231XS: "Key Hardware Features" "Fully integrated 2048 byte EEPROM for storing device descriptors and CBUS I/O configuration."

https://www.silabs.com/interface/usb-bridges/classic/device.cp2102
https://www.silabs.com/interface/usb-bridges/classic/device.cp2104
https://www.silabs.com/developers/usb-to-uart-bridge-vcp-drivers
https://www.silabs.com/documents/public/data-sheets/cp2102n-datasheet.pdf
https://www.silabs.com/documents/public/application-notes/an197.pdf
https://www.silabs.com/documents/public/application-notes/an978-cp210x-usb-to-uart-api-specification.pdf
https://www.silabs.com/documents/public/application-notes/AN571.pdf

"The CP2102N devices have the following features" "Internal 960-byte programmable ROM for vendor ID, product ID, serial number, power descriptor, release number, and product description strings"

"The CP2102N includes an internal electrically erasable programmable read-only memory (EEPROM). This memory may be used to customize the USB Vendor ID (VID), Product ID (PID), Product Description String, Power Descriptor, Device Release Number and Device Serial Number as desired for OEM applications. If the EEPROM is not programmed with OEM data, the default configuration data shown in the table below is used."

"Product String The Product String is an optional string that describes the product. It is limited to 126 characters."

PS: I understand that a bonus feature in of chips like FT231 and CP210x is to add the ability to allow users to auto-reset and put the device in bootloader mode via the DTR/RTS pins exposed will enable much easier firmware upgrades for the end-users as they will no longer need to press any buttons to enter bootloader mode, and then bootloader mode could be activated via software from the firmware flasher program software which could make the OTW (Over-The-Wire) firmware upgrade procedure more user-friendly.