I am using the original firmware - some devices pair but not all. It seems to ignore all my aqara temp sensors.
Has anybody had success creating groups? I’m trying to add 2 hue bulbs to a group via the zigbee2mqtt UI and they just wont show up despite getting the green ‘ok’ dialog after adding.
I understand switching to hardware flow control mode on this ITead Sonoff Zigbee 3.0 USB Dongle Plus adapter is done via the dip-switch on the board, so not by using a different firmware (like more usual).
You then need to enable hardware flow control in the software application like Zigbee2MQTT or ZHA:
https://www.zigbee2mqtt.io/information/configuration.html
# Optional: RTS / CTS Hardware Flow Control for serial port (default: false) rtscts: true
https://www.home-assistant.io/integrations/zha/#configuration—gui
Press
Submitto save radio type and you will get a new form asking for port settings specific for this radio type. In the pop-up:
- Serial device path
- port speed (not applicable for all radios)
- data flow control (set to “software” or “hardware” ´for software/hardware flow control)
Hardware flow control should make for more stable serial communication in theory since flow control is off-loaded from the application and the system CPU to the MCU, but not sure if it will be more stable in the real world. Know I read that openHAB’s Zigbee developer recommended it for commercial use.
As noted before, please read + follow these docs tips on best practices for avoiding pairing difficulties:
For unique device-specific pairing tips also check out individual blakadder and Zigbee2MQTT pages:
https://zigbee.blakadder.com/search.html
https://www.zigbee2mqtt.io/information/supported_devices.html
However before that I recommend following my general tips here on improving Zigbee network range:
https://github.com/home-assistant/home-assistant.io/pull/18864
Note that those tips are really generic Zigbee best-practice guidelines so applies to all Zigbee solutions.
Did you try the firmware that is linked on the Zigbee2mqtt website? This one:
CC1352P2_CC2652P_launchpad_coordinator_20210708.zip
I’m considering ordering one, but if the firmware is as buggy as mentioned in this review. I’d rather pay a bit more.
Be carefull, the firmware he flashed was the wrong one - and the sonoff sensors he tried to pair are know to have issues with zigbee2mqtt.
Problem is : a lot of CC2625P sticks use the same firmware, including TubeZ, ZigStar, TI LAUNCHXL-CC1352P-2, CircuitSetup.us Zigbee Stick, Egony Stick V4 (RFSTAR ver.), cod.m Zigbee CC2652P RPi Module, cyijun OpenZ3Gateway
and about the review , read his github issue :
Might be confusing since several different versions of firmware but the README.md state which to use:
| Adapter | TI Chip/Module Used | Firmware to Flash | BSL Trigger Pin (1) | Auto-BSL (2) | RF Switch Control Pins (3) | LED(s) |
|---|---|---|---|---|---|---|
| SONOFF Zigbee 3.0 USB Dongle Plus | CC2652P | CC1352P2_CC2652P_launchpad_*.zip | ? | No | ? | N/A |
https://github.com/Koenkk/Z-Stack-firmware/tree/master/coordinator/Z-Stack_3.x.0/bin
Koenkk have now even specifically added “SONOFF Zigbee 3.0 USB Dongle Plus” to README.md
Tried to install my Sonoff dongle
I had just the same problem this evening using Zigbee2mqtt.
Always error could not open serialport
/dev/serial/by-id/usb-Silicon_Labs_CP2102N_USB_to_UART_Bridge_Controller_0edf89633693eb118b6b214f3d98b6d1-if00-port0
Then I tried simply /dev/ttyUSB0 and Zigbee2mqtt started ?
Is the description too long ?
Running good here with /dev/serial/by-id/
Maybe a “supervisor” issue?
Install on bare metal on Raspbian Bullseye on a Pi1. No Home Assistant on that Pi.
Bare metal here, no issues. 
Firmware must support hardware flow control. Currently, we don’t have that.
Section 2 explains
https://sonoff.tech/wp-content/uploads/2021/09/Zigbee-3.0-USB-dongle-plus-firmware-flashing-1-1.docx
Is this issue affecting only zigbee2mqtt and can someone explain what flow control is and it’s use?
I just ordered the stick and now I’m wondering if that was a bad idea lol. I only use zha.
This is one of the best zigbee coordinators that I’ve used. Stable and good LQI’s
As far as flow control, zha and z2m has always used software vs hardware AFAIK. SZD 3.0+ is the only coordinator that I’ve seen with a switchable option. As for a bad idea purchasing, I don’t think so.
Read this post ITead Sonoff Zigbee 3.0 USB Dongle Plus adapter based on Texas Instruments CC2652P - #61 by Hedda
My network (80 devices)
Did you flash it with a specific firmware or the one that came with the stick? i have this stick sitting in my drawer based on a review i saw on YouTube .
I flashed it with the new CC1352P2_CC2652P_launchpad_coordinator_20210708 firmware.
It came with CC1352P2_CC2652P_launchpad_20210120 firmware, and worked.
How do you know what firmware is on it?
Do you think I can use this tool to backup my nortek and restore it on the sonoff zigbee stick?
They all (SZD3.0+) come with Koenkk’s CC1352P2_CC2652P_launchpad_20210120 firmware preinstalled. ( I confirmed via z2m frontend)
As for backing up your Nortek HUSBZB-1, I have no idea never had one.
Just to clearify, “hardware flow control” or not is not really an “issue” (as in a problem), it is an optional feature that should not be needed for a majority of users and use-case scenarios. It is also an optional feature that to my knowledge does not exist in any of the other readily available Zigbee USB dongles that are compatible with ZHA and Zigbee2MQTT today as all the others only support .“software flow control”. The only real “issue” I see is that ITead is marketing it as a feature before firmware to actually use that feature for it has been released for general availability and download by end-users.
That is, this ITead Sonoff Zigbee 3.0 USB Dongle Plus adapter has pins/paths connected for it between the dongles SoC and its UART-to-USB bridge chip + a dip-switch on the board which can enable or disable “hardware flow control” (which is a physical switch on the board that is set to disable the feature bý default). Note also that you need a screwdriver to open the case just to be able to flick the switch to enable hardware flow control mode, so that alone should be an indicator that it is not meant to be used by every end-user.
By default it will instead use “software flow control” and what was said above is that we can not simply flip the dip-switch and set the ZHA or Zigbee2MQTT software to use “hardware flow control”, as we would also have to flash it with an other firmware image than standard which has been configured to use “hardware flow control”, and so far no one we know of has compiled and shared a such firmware image.
Flow control is used to stabilize serial communication, and you can either not use it (i.e. none == “no flow control”), “software flow control” meaning applications/operating system uses system CPU to handle it, or “hardware flow control” meaning that the USB dongle firmware uses the MCU (microcontroller unit) to handle.
“Hardware flow control” should in theory make for a more stable serial communication between the application and the Zigbee USB dongle when the system CPU is overloaded as flow control has been off-loaded to the MCU, however on the other hand no one is known to have any real issues with the default “software flow control” used by default today so might be there is no real-world reason to use “hardware flow control” other than it being something new that we have not really tested before.
So it’s more like; Oh, “hardware flow control” is a shiny new feature, that is cool, let us try it for kicks and if it works then we should at least on paper have a more stable hardware setup when using it.
You can not use only that tool and instructions alone since it only describes backup and restoring using the same Zigbee stack (as both Nortek dongle and Sonoff ZBBridge are based on Silabs chips).
While you can usually without much trouble backup an older Silabs based Zigbee chip (like Nortek adapter based on a Silabs Ember 358x chip) and restore it to a newer Silabs based Zigbee chip (like Sonoff ZBBridge or the other ITead Zigbee 3.0 USB Dongle which are both based on a Silabs EFR32 chip) that are in practical terms just running a newer version of same Silabs Zigbee stack firmware, there is normally a different story when migrating between totally different Zigbee stacks.
You first need to understand that the Nortek adapter you mention is based on a Silicon Labs chip and runs Silabs EmberZNet Zigbee stack firmware while this new Sonoff Plus dongle is based on a Texas Instruments chip and runs TI’s Z-Stack Zigbee stack, so backup images would normally look differently.
However, puddly (zigpy developer) is together with castorw (Zigbee2MQTT/zigbee-herdsman developer) working on an “Open ZigBee Coordinator Backup Format” with a theoretical goal of generating backup images which could be universally compatible with all supported Zigbee stacks (primarly Silabs ↔ TI).
So today the backup images made with bellows CLI for Silicon Labs EmberZNet stack (using Silabs EZSP serial interface) uses that same “Open ZigBee Coordinator Backup Format” as the zigpy-znp CLI for Texas Instruments Z-Stack (TI ZNP serial interface), and those they can restore each other’s backup image files.
https://github.com/zigpy/bellows
https://github.com/zigpy/zigpy-znp
If you are willing to act as a migration tester then suggest testing it and if you run into any issues then try asking the zigpy developers about backup and restoring problems between different types of Zigbee stacks here → zigpy/zigpy · Discussions · GitHub or perhaps post it as a new question under issues here → Issues · zigpy/open-coordinator-backup · GitHub
Believe I read somewhere that they managed to migrate back and forth between Silabs and TI stacks.
PS: Regardless, before starting would recommend backup your existing dongle ‘as-is’ and save that.
