Hello!

Forgive me this newbie question, but I was wondering if you could guide me in how to flash the Z2M firmware onto my Zigstar shield. I will be using the z-stack firmware as suggested on the Zigstar Shield page.

I was wondering on how to enable the programming mode. Because with the USB stick it is clear you need to push the BSL button when plugging it in, but not sure how to get there with the shield.
I was hoping to be able to program the device using the python cc2538-bsl.py script from the raspberry pi itself without the need of an external programmer. Perhaps I was to optimistic :-)

Warm regards

Hacor

@mercenaruss 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(s) 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/

@mercenaruss continuing the request/suggestion for a general ZigStar community discussion forum from home-assistant/home-assistant.io#20320

Recommend enable GitHub Discussions https://docs.github.com/en/discussions to allow "ZigStar discussions" under its own community repo like https://github.com/zigstar/zigstar_community_resources/discussions or alternatively in one of your other exisitng GiHub repos and use that "discussion section" to use as a general ZigStar communication forum.

PS: Yes I know that you have a dedicated forum thread in the HA community forum but I think it would be best to have your own "discussion" space here on where people can create separate threads for different topics so it is not all in one thread. Plus there will sooner of later be people from other communities than HA that will use ZigStar products if you market them as usable with Zigbee2MQTT, Home Assistant, and iOBroker (as well as later maybe also OpenHAB once they add support for TI Z-Stack 3 in their Zigbee Binding).

Re-post idea from HA community -> https://community.home-assistant.io/t/zigstar-zigbee-coordinators-and-routers/338586/6

Please consider switching the design to an other USB-to-Serial converter chip with its own writable EEPROM as a 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

and also see pull request example for whilelisting USB devices for ZHA home-assistant/core#56201

That unique customized USB description string could be something like ex.; "ZigStar USB Stick version 4 hardware revision 2.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.

Hi there, thanks for the nice design! I bought one of them from ebay. It is working as a coordinator but unfortunately the range is very poor. max ~2m line of sight. Do you have any suggestions where to start tweaking to improve the range? Could a software update help?

Thanks!

Very nice project, thanks for sharing.
I'm looking at the 4.0 version of CH340E.
Could you post the CPL file that is needed for the SMT assembly through jlcpcb?

Hello,
First off just wanted to thank you for the project, recently received a zigstar4 that is currently being used a router and I am loving the range. I was hoping it would be possible for you to share the easyeda project files used to generate the gerber files. I am hoping to add a few components, specifically a temperature/humidity sensor and potentially a light sensor. I have no plans to mass produce any result as it would be simply a hobby project. The easyEDA project files would give me some starting points in designing the PCB.

Please let me know if this is possible.

I flashed this router firmware.
It works well, but how do I re-pair to other coordinator?
I pressed the reset button but nothing happened.

@mercenaruss to continue the "ZigStar Stick" name change discussion from home-assistant/home-assistant.io#20320

I changed "ZigStar Stick v4" to just "ZigStar Stick" in the initial home-assistant/home-assistant.io#20320 pull request for ZHA docs but otherwise, I think would be best to leave 'as is' for now and then do new PR just changing that small detail in the ZHA docs after you have updated all your sites to use the new name chosen because right now can see that they all still old "ZigStar Stick v4" name.

Thus it will certainly be more confusing to change the name in ZHA docs first when you have not already changed it upstream. So be sure to change the name on all sites upstream first:

https://zig-star.com/projects/zigbee-stick-v4/

https://www.tindie.com/products/zigstar/zigstar-stick-v4/

https://github.com/mercenaruss/zigbee-stick-v4

Also remember that users have the option to reflash these sticks with Zigbee Router firmware and use them as Zigbee routers instead Zigbee coordinators. Thus personally I think you should leave the name as "ZigStar Stick" or use other similar general suffix (like ex. "ZigStar USB Stick", "ZigStar USB Dongle", or "ZigStar USB Adapter" which all work well as generic suffixes in product name).

Thanks a lot for your great work developing this board and presenting it here.
I have a suggestion for an improvement in future releases or similar projects:
The USB port is not always the best solution for everyday operation.
Many automation systems are running on a server or computer not beeing located at the best location regarding the needs of RF wave propagation.
So, an ethernet interface is a good supplement.
This can be done using a commercially available converter such as USR-TCP232-T2 or similar.
I hand-modified your module to attach such an add-on.
Unfortunately I had to cut a trace and to make some ugly solder mods.
In future versions it would be highly appreciated if you could support such alternative signal paths by exosing the serial signals to the (extented) border connector. It could be as

• tap the connection between cc2652P module Txd to CH340 RxD and connet it to an additional connector pin
• connect the cc2652P module RxD to an additional connector pin
• connect the CH340 TxD to an additional connector pir
• connect the cc2652 RxD to the CH340 TxD by a removable link such as a jumper or a resistor which could be removed
• if possible and space left, connect the +5V to an additional connector pin

I modified your board by cuttin and adding some wires.

It looks ugly like this but it works.

I have more images and a description in the ioBroker forum (German language) https://forum.iobroker.net/post/601380 .

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.

Excellent work. Thank you!
However, the wiki does not answer the question of what firmware to flash?