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:
Press Submit to 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.
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
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.
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 .
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.
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.
