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)
1 Like
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.
2 Likes
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.
1 Like
I was able to backup my HUSBZB-1 and transfer it to the Sonoff ZIgbee 3.0 Dongle Plus using these steps: Backup of HUSBZB-1 not working · Discussion #90 · zigpy/zigpy-znp · GitHub. The new dongle has been performing significantly better than the Nortek one.
2 Likes
Thank you for the detailed response I’ll look into that.
That’s amazing I’ll definitely back up my stick first just in case. It will be great if I don’t need to repair 110 devices. Those instructions are very detailed I appreciate that. I would be terrified otherwise without the details to edit anything in the root ssh.
Checking in, also running the Sonoff Dongle flashed with the latest Zigbee2mqtt coordinator firmware from Koenkk. Running 5 Linkind sensors and 1 Hue motion sensor so far and all working just fine on my end (hassOS on intel NUC).
I am having an issue getting Zigbee2mqtt running with the ITead Sonoff Zigbee 3.0 dongle. Port being used is /dev/ttyUSB0 which to me appears correct. I am running Supervised HA within docker on a NUC. Any assistance would be appreciated. From the log I have extracted:
[12:39:52] INFO: Handing over control to Zigbee2mqtt Core …
Socat startup parameters:
Options: -d -d
Master: pty,raw,echo=0,link=/tmp/ttyZ2M,mode=777
Slave: tcp-listen:8485,keepalive,nodelay,reuseaddr,keepidle=1,keepintvl=1,keepcnt=5
[12:39:52] INFO: Starting socat process …
2021/10/29 12:39:52 socat[313] N PTY is /dev/pts/0
2021/10/29 12:39:52 socat[313] W ioctl(7, IOCTL_VM_SOCKETS_GET_LOCAL_CID, …): Not a tty
2021/10/29 12:39:52 socat[313] N listening on AF=2 0.0.0.0:8485
> [email protected] start
> node index.js
Zigbee2MQTT:error 2021-10-29 12:39:55: Error while starting zigbee-herdsman
Zigbee2MQTT:error 2021-10-29 12:39:55: Failed to start zigbee
Zigbee2MQTT:error 2021-10-29 12:39:55: Check Frequently asked questions | zigbee2mqtt.io for possible solutions
Zigbee2MQTT:error 2021-10-29 12:39:55: Exiting…
Zigbee2MQTT:error 2021-10-29 12:39:55: Error: Error while opening serialport ‘Error: Error Resource temporarily unavailable Cannot lock port’
- at SerialPort. (/app/node_modules/zigbee-herdsman/src/adapter/z-stack/znp/znp.ts:146:28)*
- at SerialPort._error (/app/node_modules/zigbee-herdsman/node_modules/@serialport/stream/lib/index.js:198:14)*
- at /app/node_modules/zigbee-herdsman/node_modules/@serialport/stream/lib/index.js:242:12*
[12:39:55] INFO: Handing over control to Zigbee2mqtt Core …
> [email protected] start
> node index.js
Dongle installed on the local Pi ? Then disable socat.
Thanks Francis for the reply. I am running both a Pi4 and NUC. Closing down the Pi4 following your response fixed my issue. i am still getting errors in the log though, posted below and slightly different than before. Any suggestions?
Zigbee2MQTT:error 2021-10-29 17:22:59: Error while starting zigbee-herdsman
Zigbee2MQTT:error 2021-10-29 17:22:59: Failed to start zigbee
Zigbee2MQTT:error 2021-10-29 17:22:59: Check | Zigbee2MQTT for possible solutions
Zigbee2MQTT:error 2021-10-29 17:22:59: Exiting…
Zigbee2MQTT:error 2021-10-29 17:22:59: Error: Error while opening serialport ‘Error: Error Resource temporarily unavailable Cannot lock port’
at SerialPort. (/app/node_modules/zigbee-herdsman/src/adapter/z-stack/znp/znp.ts:146:28)
at SerialPort._error (/app/node_modules/zigbee-herdsman/node_modules/@serialport/stream/lib/index.js:198:14)
at /app/node_modules/zigbee-herdsman/node_modules/@serialport/stream/lib/index.js:242:12
[17:22:59] INFO: Handing over control to Zigbee2mqtt Core …
[email protected] start
node index.js
error-resource-temporarily-unavailable-cannot-lock-port :
FYI, Koenkk from Zigbee2MQTT now stated that current firmware does not yet support +20 dbm output:
https://github.com/Koenkk/zigbee2mqtt/discussions/8840#discussioncomment-1550449
That means that this CC2652P based Sonoff Zigbee 3.0 USB Dongle Plus adapter with its current firmware version only operate at +5 dBm output, so no wonder it does not perform better when compared to Electrorama’s zzh dongle which is based on CC2652R that physically only capable of +5 dBm output. Thus only once we get a new community firmware with correct RF switch configuration activated will enabling 20 dBm output transmit power in Zigbee2MQTT or ZHA applications setting actually work for any CC2652P or CC1352P based Zigbee coordinators.
chiakikato also manually tested Sonoff Plus dongle hardware and confirms it support +20 dBm output:
https://github.com/Koenkk/zigbee2mqtt/discussions/8840#discussioncomment-1550148
Guess that means that Mat will have to do another test and update his review when get new firmware.
2 Likes
I can attest that the dongle works pretty well (Using ZHA). I have it plugged in an Ubuntu i5-4570 instance. I’m coming from a Philips Hue hub for my lights and a few remotes (Philips and IKEA branded). Only thing I notice is it is slightly slower than my old hub. I have never owned a USB Zigbee dongle before so another thing I notice it takes a few more seconds after rebooting HA for it to be able to get status/control my Zigbee devices. The visualization looks cool but I have no idea how to fine tune things with that information yet. Overall, pretty happy with it.
I’d love to test out the new firmware when it rolls out hopefully not too far from now.
Understand and remember that with the way Zigbee network mesh technology works you can not tune the layout of the mesh connections via software configuration/settings. Instead, if you are having problems with one or more devices then you can utilize the visualization to find where a bottleneck or interfering router device may lie, and then you will need to physical either move around your devices and add more Zigbee router devices or remove troublesome devices. Checkout tips posted in this PR:
https://github.com/home-assistant/home-assistant.io/pull/18864
It might perhaps be a little slower connecting to all devices after reboot depending on your computer hardware and operating system, but once Home Assistant and chosen Zigbee integration are fully up-and-running your devices should not be slow to respond to a state change like turning a light on or off. If they are slow then something in your setup is probably wrongly configured or the message takes a long detour due to how your LAN and/or internet is designed. As the technology behind an implementation with correct setup works, switching on and off a light when on the local network should be just as fast as Philips HUE Hub.
1 Like