ITead’s “Sonoff Zigbee 3.0 USB Dongle Plus V2” (model "ZBDongle-E") based on Silicon Labs EFR32MG21 +20dBm radio SoC/MCU

FYI, ITead just released a new “ZBDongle-E” adapter as an improved version of their old/previous barebone Silabs EFR32MG21 based Zigbee 3.0 USB adapter from ITead and this new variant is to be sold side-by-side as an alternative to ITead’s TI CC2652P based “Sonoff Zigbee 3.0 USB Dongle Plus (which is now renamed to “ZBDongle-P”), meaning they will continuously sell both variants and while both type of radio SoC chips practically have the same specifications on paper, they use different Zigbee stack firmware which will affect compatibility/support with different Zigbee gateway application implementations, thus the developers of various Zigbee gateway applications will have different recommendations on the preferred variant.

https://itead.cc/product/zigbee-3-0-usb-dongle/

https://sonoff.tech/product-review/sonoff-zigbee-3-0-usb-dongle-plus-tutorials/

https://sonoff.tech/wp-content/uploads/2022/08/SONOFF-Zigbee-3.0-USB-dongle-plus-firmware-flashing-.pdf

This can be a little confusing as both this “ZBDongle-E” variant and the “ZBDongle-P” variant can act as either a Zigbee Coordinator (by default) or Zigbee Router device (if flashed with such firmware instead), and if flash OpenThread/Spinel Radio Co-Processor (RCP) firmware also Thread network protocol for the upcoming Matter/CHIP standard (Project Connected Home over IP). As Silicon Lab and Texas Instruments adapters offer different compatibility ITead will now sell both of these so users will now have more options as different DIY home automation software applications offer might not be fully compatible with one or the other (Home Assistant’s ZHA integration is however fully compatible with both so based in just the specification they should in theory offer similar performance on paper).

Comparing “ZBDongle-P” vs. “ZBDongle-E” vs. barebone EFR32MG21 dongle

image verses image versus image

Feature/Model ZBDongle-P ZBDongle-E 9888010100045
Radio SoC/MCU chip Texas Instruments CC2652P Silicon Labs EFR32MG21 Silicon Labs EFR32MG21
Zigbee Stack (Serial Interface Protocol API/CLI) Z-Stack v3 (ZNP 3) EmberZNet (EZSP v8) EmberZNet (EZSP v8)
Optional Zigbee Router firmware Yes (9dBm firmware available from Koenkk) Yes (20dBm firmware available from ITead) Yes (20dBm firmware available from ITead)
USB to UART/Serial Converter Chip CP2102 or CP2102N CH9102F CH340
USB EEPROM Product Description ID SONOFF Zigbee 3.0 USB Dongle Plus SONOFF Zigbee 3.0 USB Dongle Plus V2 (first need to run update script if from first hardware batch shipped) None (no USB chip EEPROM)
Home Assistant USB Auto Disovery Yes Yes (but way need to run update script if from first hardware batch shipped) Not possible
Flow Control None by default (Hardware flow control optional with alternative firmware and flipped dip-switch) Software flow control Software flow control
RF Transmit Output Power 9dBm (firmware hardcoded), Max: 20dBm 20dBm (default) 20dBm (default)
Antenna External (rotatable and tiltable) External (rotatable and tiltable) Onboard circuit board antenna
Enclosure/case Aluminum all-metal shell casing Aluminum all-metal shell casing None
Length 63mm 52mm ?
Packaging Retail-box with manual Retail-box with manual Anti-static bag only
Home Assistant ZHA Supported Supported Supported
Zigbee2MQTT Supported Still experimental and no full feature-parity yet support as EZSP adapter development for Z2M is still ongoing in zigbee-herdsman library, see https://github.com/Koenkk/zigbee-herdsman/issues/319 Still experimental and no full feature-parity yet support as EZSP adapter development for Z2M is still ongoing in zigbee-herdsman library, see https://github.com/Koenkk/zigbee-herdsman/issues/319
IoBroker Supported Still experimental and no full feature-parity yet support as EZSP adapter development for Z2M is still ongoing in zigbee-herdsman library, see https://github.com/Koenkk/zigbee-herdsman/issues/319 Still experimental and no full feature-parity yet support as EZSP adapter development for Z2M is still ongoing in zigbee-herdsman library, see https://github.com/Koenkk/zigbee-herdsman/issues/319
OpenHAB ZigBee Binding Not yet, see request and discussion Supported Supported
Domoticz Zigbee Plugin Supported Supported Supported
Jeedom Zigbee Plugin Supported Supported Supported

This new Silabs based dongle also targets users of multiple open-source home automation software applications so it comes pre-flashed with a firmware known to be stable and compatible with several popular DIY projects. Physically the dongle features the same external antenna + metal-enclosure too as ITead’s TI based dongle does, as well as shipping in similar retail packaging to make it more attractive for sale in brick and mortar stores.

Both their Silicon Labs and Texas Instruments adapters are compatible out-of-the-box with Home Assistant’s ZHA integration which supports Silabs EZSP (EmberZNet Serial Protocol) as well as TI Z-Stack Serial Interface and even more manufacturers Zigbee adapters, so different benefits are that the same Silicon Labs EFR32MG21 based adapter is also used by Home Assistant SkyConnect USB Stick (as well as ITead’s Sonoff ZBBridge and ZB-GW03 eWeLink Ethernet Zigbee Gateway which with Zigbee Coordinator NCP firmware they are compatible with OpenHAB’s ZigBee Binding, Zigbee Plugin for Domoticz, and Zigbee Plugin for Jeedom, while the Texas Instruments CC2652P based adapter is also fully compatible with Zigbee2MQTT (a.k.a. Z2M) and IoBroker while their zigbee-herdsman library currently only has experimental support for Silicon Labs based adapters.

Again, both variants still look to be great value for premium hardware that is sold for a low price.

As both are sold at a lower price it is assumed ITead hope to make money on attach rate sales, so if you are new to Zigbee also recommend to buy some of their other Sonoff branded Zigbee devices as well:

https://itead.cc/?s=zigbee&post_type=product&type_aws=true

I personally recommend Sonoff battery-operated Zigbee door/motions/temperature sensors and button. Suggest reading the articles by NotEnoughTECH if want independent reviews of those Sonoff sensors:

https://notenoughtech.com/featured/sonoff-zigbee-sensors/

Also, I can personally recommend using a few of their USB adapters flashed as Zigbee Routers too.

Zigbee 3.0 USB Dongle Plus - ZBDongle-E variant

https://itead.cc/product/zigbee-3-0-usb-dongle/

It uses the same EFR32MG21A020F768IM32 SoC used on the first ITead Zigbee 3.0 USB Dongle based on EFR32 Mighty Gecko Series 2, as well as on CoolKit Technologies “SM-011 V1.0” module used in the ITead Sonoff ZBBridge Zigbee Bridge and in Tuya ZS3L and Tuya ZSLC5 SoC modules. It includes a 80 MHz ARM Cortex-M33 core, 768 Flash Storage, 64 RAM, in a QFN32 package, which radio has + 20 dBm maximum power output and receive sensitivity of -104 (250 kbps O-QPSK DSSS) dBm.

TIPS!

FIRMWARE UPGRADE REQUIREMENTS AND FLASHING SOFTWARE LINKS

For flashing Silabs EFR32MGxx chips like EFR32MG21 checkout these different methods:

Note! Need to first install WCH CH9102F (CH34x/CH91xx) device drivers in your operating system.

New “official firmware images” for ZBDongle-E (a.k.a. “Dongle-E”/“Dongle-E”) as linked to by ITead:

New unofficial community firmware images for ZBDongle-E (e.i. not supported by ITead/Sonoff):

If someone here is feeling a little brave and in the mood to experiment with newer firmware untested by ITead then you have the option to try flashing one of the unofficial alternative EmberZNet Zigbee firmware images for EFR32MG21 from independent community firmware developers as those should at least on paper also be compatible with ITead’s “ZBDongle-E” (and already have features such as touchlink/touchlinking enabled which ITead has missed enabling), but they might have not yet have specifically tested on ITead’s “ZBDongle-E” hardware or with all Zigbee applications. See for example this related discussion about ZBDongle-E firmware compatibility here:

Be aware that the CC2652P based “ZBBridge-P” (a.k.a. “Dongle-P”/“Dongle-P”) as well the old firmware for the previous/older EFR32MG21 based ITead Zigbee 3.0 USB Dongle Model: 9888010100045 (Hardware Revision Version 1.3) is also linked to by ITead on same of those pages, and those might do not use the same firmware (at least not the ones for Texas Instruments CC2652 based products like the “ZBBridge-P”).

https://sonoff.tech/product-review/sonoff-zigbee-3-0-usb-dongle-plus-tutorials/

https://sonoff.tech/wp-content/uploads/2022/08/SONOFF-Zigbee-3.0-USB-dongle-plus-firmware-flashing-.pdf

Elelabs EZSP Firmware Upgrade Utility can be used to flash the firmware to a newer or older version:

https://github.com/Elelabs/elelabs-zigbee-ezsp-utility/

This firmware upgrade tool has also been packaged by walthowd in a docker image to make it easier:

https://github.com/walthowd/husbzb-firmware https://github.com/walthowd/husbzb-firmware/issues/44https://github.com/walthowd/husbzb-firmware/pull/45

Unofficial community resources:

Dongle firmware upgrade prerequisites key points are:

  • Use a USB extension cable (due to USB plug on the dongle being very short it might not be fully inserted physically on some chassis/enclosures unless use USB extension cable with longer plug).

FYI! Basically the serial protocol API for EmberZNet Zigbee coordinator application running on the Silicon Labs SoC/MCU does not deal well with unexpected loss of communication caused by network drops. The reason Ember remote bridges over serial-to-IP proxy server is not recommended is that clients using the EZSP serial protocol requires a robust connection between the EmberZNet Zigbee stack running on EFR32 MCU and the serial port of the Zigbee radio. With solutions such as ITEAD Sonoff ZBBridge or a Ser2Net serial proxy connection over a WiFi network it is expected to see NCP entered failed state. Requesting APP controller restart in the logs. This is a normal part of the operation and indicates there was a drop in communication which caused packet loss to occurred between the zigpy radio library and the Zigbee radio. The use of serial network proxies/bridges/servers over WiFi is therefore not recommended when wanting a stable Zigbee environment with Silicon Labs Ember based Zigbee radios. The developers of the bellows radio library for the zigpy project has more information about this if needed.

20 Likes

fwiw, the efr32 chip they are using is the same as the one used in the original WiFi bridge and on the SM-011 module. not sure if it’s pin compatible.

Screen Shot 2022-08-02 at 11.16.42 AM

1 Like

Here is by the way link to FCC filing/report for the new “ZBDongle-E” (a.k.a. “ZBD-E” ) adapter which contains copy of the user manual + a lot more detailed + many more internal and external pictures:

https://fccid.io/2APN5ZBD-E

https://fccid.io/2APN5ZBD-E/User-Manual/User-Manual-6012461.pdf

https://fccid.io/2APN5ZBD-E/Internal-Photos/Internal-Photos-6012455

https://fccid.io/2APN5ZBD-E/External-Photos/External-Photos-6012451

1 Like

I have not received mine yet but got a reply from ITead now that the USB “product description id” written to the EEPROM of the CH9102F USB-to-UART/serial chip on this new ZBDongle-E dongle is “SONOFF Zigbee 3.0 USB Dongle Plus V2”, hopefully that added “V2” in combination with the rest ill allow for unique identification which can enable ZHA developers to add automatic discovery?

https://www.home-assistant.io/integrations/zha#discovery-via-usb-or-zeroconf

https://community.home-assistant.io/t/community-help-wanted-to-whitelist-all-compatible-zigbee-and-z-wave-usb-adapters-for-automatic-discovery-in-home-assistant-os/344412

As seen on this previous pull request will also need the standard VID and PID used for CH9102F chips:

https://github.com/home-assistant/core/pull/62171

My follow-up question to ITead was if they themselves will be submitting a pull request to Home Assistant core repository for unique USB discovery using the “product description id” of this new ZBDongle-E dongle, as that is what they eventually did for their other Zigbee USB dongle:

FYI, I asked ITead was got the reply that the pinout definition for the EFR32MG21 SoC chip on the new model ZBDongle-E board is the same as the original first-generation barebone Zigbee 3.0 USB Dongle model 9888010100045, but they answered that the new model ZBDongle-E adapter can still not use the exact same firmware images as their old barebone model 9888010100045 adapter, so I guess that must mean that they do not use the exact same EFR32MG21 SoC chip model or?

https://github.com/xsp1989/zigbeeFirmware/blob/4533c8daa1e571801a2c49dca8498a1b1b79f54f/firmware/Zigbee3.0_Dongle/EZSP/README.md

I also asked ITead about the default RF output power configuration and was told that the new ZBDongle-E adapter currently ships with Zigbee NCP 6.10.3 firmware that has enabled 20 dBm output RF power default, however is not hardcoded in the firmware so users/applications can choose to lower output RF power if they want.

In addition, got part of Configuration Parameter values Table for Silicon Labs EmberZNet PRO Zigbee networking protocol stack:

Configuration Parameter Value
EMBER_APS_UNICAST_MESSAGE_COUNT 32
EMBER_PACKET_BUFFER_COUNT 250
EMBER_NEIGHBOR_TABLE_SIZE 26
EMBER_SOURCE_ROUTE_TABLE_SIZE 200
EMBER_ADDRESS_TABLE_SIZE 32

It does not mention “Child Table Size” but I guess that is probably configured to 32 same as for old model 9888010100045 as per zigbeeFirmware/firmware/Zigbee3.0_Dongle/EZSP/README.md at 4533c8daa1e571801a2c49dca8498a1b1b79f54f · xsp1989/zigbeeFirmware · GitHub or?

Dear fellow Home Assistant ethusiasts,

I am considering replacing my existing Conbee II running on a rpi4 with ZHA with the Sonoff ZBDongle-E Zigbee 3.0 USB dongle.
The location of the HASS hardware is not optimal, but have had some improvement by adding two of Tube’s routers.

  1. Will migrateing to a new main coordinator require the whole zigbee network to be reconfigured from scratch or is it possible to backup the current network and add it to the new coordinator (ZHA)

  2. Any thoughts on going for the new Sonoff coordinator vs. one of Tubes coordinators:
    CC2652P2 based Zigbee to Ethernet/USB or EFR32 Pro Ethernet/USB Serial Coordinator Version 2?

I moved from a ConBeeII to a Sonoff ZBDongle-P and had nothing but issues. I am very tempted to migrate once again to the ZBDongle-E but I am somewhat unsure on which one is actually better. Should I trust Silicon Labs firmware more than Koenkk’s firmware? After all he is directly involved with Home Assistant related projects so may have our interest as a top priority which is unlikely for Silicon Labs… but it is also a corporation Vs a one man development.

Also, from a chip perspective, I would like to be ready for Matter / Thread. The E version inspires more confidence in that regard, but I have nothing solid to prefer SI over TI.

@Hedda You seem to be very experienced on Zigbee. What do you think about picking the E version over the P version? I made a mistake trying to change channel to 25 and ended up on 15 again so having to nuke my poorly performing mesh anyway, it would be a good time to move to ZBDongle-E… but is that the best choice? I run ZHA on HA OS.

My experience is somewhat the opposite, I moved from the Nortek (an SI Labs chip, I assume an older generation) to the Sonoff Dongle-P, and ALL of my persistent issues disappeared. I was having weekly or even daily issues, and since the swap my zigbee has been rock solid.

I’m sure others can offer an opposing anecdotes. I can only report my experience. I suspect the intricacies of what makes one chip perform better than another may be largely dependent on the specific environment/device mix.

I don’t see the @Koenkk vs SI Labs firmware as a big issue. @Koenkk’s firmware is really Texas Instruments firmware + additional patches. So it’s more like corporate with customization vs corporate. There is always the risk @Koenkk could lose interest or be pulled away from maintaining the builds, but with such a large community of cc2652 users I feel someone would pick up the mantle.

When thread finally becomes a real player, I’ll get a second dongle or other device to manage it. There’s no chance in heck I’ll mess with my stable zigbee network of 70+ devices. I might feel differently if I only had a handful of devices.

The biggest pro ZBDongle-E argument, especially for a ZHA user, is it’s the same chip (to my understanding) used in the Yellow and the upcomming HA Branded dongle. I think it will inevitably get more love from the HA/ZHA devs.

3 Likes

@jerrm Thanks for the insight. You bring up a good point about messing up the zigbee network when thread comes along, but I figured that having both on the same dongle was actually best so they won’t supposedly interfere with each other.

You also make a good point on HA having chosen that chip… all I really care for is a stable network so going with a chip they chose for their own hardware should add some assurances. I too am managing a large and growing network of 90 zigbee devices so any tiny benefit may actually be quite relevant.

I think the “ZBDongle-E” might offer slightly better performance if the environment setup parameters is otherwise exactly the same, however, both “ZBDongle-E” (EFR32MG21) and the “ZBDongle-P” (CC2652P) models have very similar specifications and either should work great with Home Assistant’s ZHA integration as long as you try to follow all the general best practices tips, including using a long USB extension cable with proper shielding to place the Zigbee adapter away from interference.

However, if you are using the Zigbee2MQTT (Z2M) application instead of ome Assistant’s ZHA integration then know that Zigbee2MQTT software code for EZSP (EmberZNet Serial Protocol) support for Silabs based adapters is not yet mature and still listed as “experimental”. It is my understanding that they need more developers or testers actively working on their ezsp code in the zigbee-herdsman library that Zigbee2MQTT depends on. So, for now, Texas Instruments CC2652 and CC1352 based adapters is the way to go for a stable experience if use Zigbee2MQTT for “production” at home.

Therefore if you already own a relatively modern Zigbee USB adapter and do not yet have over 50+ Zigbee devices then taking actions to avoid interference by optimizing your Zigbee adapter placement, etc. and adding more Zigbee Router devices will in practice have a much larger impact on your overall experience than migration to another modern Zigbee USB adapter with similar specifications.

I can recommend buying several more Zigbee USB adapters to use a Zigbee Router devices, but the only reason I would recommend migrating from one relatively modern Zigbee adapter to another type of relatively modern Zigbee adapter is if your existing Zigbee Coordinator is not in a Zigbee USB dongle format but instead a Raspberry Pi Shield/HAT format or otherwise built-in so you can not simply move it away from the computer by using a long USB extension cable in order to avoid interference.
Regardless, be sure to read and follow all the general tips here to optimize your setup/environment:

https://github.com/zigpy/zigpy/wiki/Generic-best-practice-tips-on-improving-Zigbee-network-range-and-general-stability

Silicon Labs and Texas Instruments both release new official Zigbee SDK versions regularly which contain many bug-fixes from upstream so the general recommendation is to update firmware often, however maybe stay behind a few months behind the community releases to avoid teething issues:

grobasoz (Gary Robas) community EmberZNet firmware builds for Silicon Labs based adapters:

https://github.com/grobasoz/zigbee-firmware

Koenkk (Koen Kanters) community Z-Stack firmware builds for Texas Instruments based adapters:

https://github.com/Koenkk/Z-Stack-firmware

Both the “ZBDongle-P” (EFR32MG21) and the “ZBDongle-P” (CC2652P) models will be able to support Matter over Thread in the future by flashing OpenThread firmware as those already supported on these chips by the chip manufacturer, but be prepared to use a separate dedicated radio adapter for each wireless protocol, as even if “multi-protocol” sounds cool to able to simultaneously run Zibee and Matter/Thread concurrently on the same it will not be optimal to do so on a single radio adapter if you want to add a lot of devices with both those wireless protocols/stands.

I am sure that using a separate dedicated radio adapter for each wireless protocol if possible will become the general recommendation unless you are just starting out and only have a few devices.

It will depend on your specific house/environment but it is generally recommended to just use a Zigbee USB adapter with a very long USB extension cable as a directly attached adapter will ensure a more reliable serial communication that is not dependent on serial tunnel bridge/proxy over your local network.

Zigbee network bridges are very convenient (and stable enough for home use as long as they use a wired Ethernet connection and not Wi-Fi), but for most people, it will be simpler just direct attach a very long USB extension cable which can be up to a normal 5-meter in length if it is properly shielded, and you can even use an even longer USB extension cable if it has a built-in active USB repeater/booster (and again is properly shielded).

Yes the Nortek GoControl QuickStick Combo Model HUSBZB-1 is based on an obsolete Silicon Labs EM3581 SoC chip, so it is unfair to compare apples against oranges, instead, it would be fair to compare it with the older Texas Instruments CC2530/CC2531 SoC chip.

To compare apples against apples you should compare Silicon Labs EFR32MG21 against Texas Instruments CC2652P.

I don’t recommend adapters based on older Silabs EM35x/EM35x SoC chip or CC2530/CC2531 today.

Check out the relevant discussions here:

If you are already using the ZHA integration with your existing ConBee/RaspBee, Silicon Labs, or Texas Instruments based Zigbee adapter (and not using Zigbee2MQTT or deCONZ with it) and have also updated the Zigbee firmware to the latest available version, then I believe that ZHA in the upcoming Home Assistant 2022.9 release will offer independent hardware backup and cross-hardware restore options for all ConBee/RaspBee, Silicon Labs, and Texas Instruments based Zigbee adapters in order to migrate to a brand new Zigbee adapter as long as it has not already formed a network.

I am however not sure exactly about how the step-by-step backup and restore procedure will upcoming Home Assistant 2022.9 release in order to migrate to a new adapter, but suspect that you will have to first run the backup and then it will either ask if you want to perform a restore of your Zigbee network backup if you plug-in a brand new Zigbee dongle (that does not already have a Zigbee network configured on it) or if you maybe have to remove the whole ZHA integration after backup is done before installing the ZHA installation again and having it performed the restoration of your Zigbee network backup for you?).

Note that you can already today temporarily just move your Zigbee adapter to another computer and manually perform a backup of your Zigbee adapter with zigpy-cli (command line interface for zigpy) and then manually restore that backup to another Zigbee adapter if you do not want to wait for the upcoming Home Assistant 2022.9 release. zigpy and zigpy-cli (which ZHA is based on) now support independent hardware backup and cross-hardware restore options for all ConBee/RaspBee, Silicon Labs, and Texas Instruments based Zigbee adapter as long as the Zigbee network was formed using the ZHA integration and you already you the latest Zigbee firmware for that adapter.

1 Like

FYI, the developers Zigbee2MQTT, the popular stand-alone Zigbee to MQTT bridge application (together with developers of IoBroker as both are based on zigbee-herdsman open-source library) are currently planning to soon remove the “experimental” tag from Silicon Labs EFR32-based Zigbee adapters on their “Supported Adapters List” and working to instead list them as “Recommended” and “stable” for everyday use just like Texas Instruments CC2652 based adapters are today.

https://www.zigbee2mqtt.io/guide/adapters/

The main argument that the lead developer of their Silicon Labs EFR32 “EZSP” adapter implementation has is that keeping Silabs based adapters listed as “Not recommended” by the Zigbee2MQTT community discourages any users and new developers from actively trying it out and assisting in the development of the Silicon Labs EFR32 “EZSP” adapter implementation by reporting all bugs/issues or helping out with the development, thus hindering the development of support for other adapter implementations than those based on Texas Instruments Zigbee chips.

So if you want to help out the Zigbee2MQTT and IoBroker (both based on zigbee-herdsman) developers then please consider testing Silabs EFR32 based adapters with those applications. See discussions:

https://github.com/Koenkk/zigbee-herdsman/issues/319

and

https://github.com/Koenkk/zigbee2mqtt/discussions/13373#discussioncomment-3309655

1 Like

@Hedda I have exhausted all the other options you recommend. The only option left which I tried, and failed to do, was changing channel to 25. For some reason my edit adding the YAML needed to do so was not saved and I only noticed after reforming and readding all devices. I will now clear the NVRAM on my stick and reform the network using CLI commands via SSH. I am under the understanding that with the zigpy_config YAML in place to change channel in configuration.yaml, when the network reforms it should be on ch25… however I do not know how to verify it as everything I’ve found online was either for another implementation of zigbee or did not work.

As for the stick, got it. I will stay with what I have for now (CC2652P) and consider using a separate coordinator for Thread. I actually have 2 Sonoff ZBDongle-P so maybe I can use one for Zigbee and one for Thread. The issue will be what channels to use given I already use all 3 main Wifi channels across my 5 APs.

EDIT: I figured out how to run a backup of the coordinator, change the channel to 25 (it was indeed on 15) and restore the backup. I had to re-pair all devices but even at 90 it went quite fast (because the inclusion process was working well). Time will tell if this solves my issues… fingers crossed.

While the Zigbee specification supports changing channeI on an existing Zigbee network I do not think that ZHA support that feature yet? See → https://www.home-assistant.io/integrations/zha/#defining-zigbee-channel-to-use

The feature ability to change Zigbee channel without re-pairing devices is discussed with zigpy developers here → Is it (technically) possible to change ZigBee channel without having to re-pair every device? · zigpy/zigpy · Discussion #908 · GitHub

If zigpy config for ZHA in YAML is not working as it should to set prefered channel the report issue to HA core → Issues · home-assistant/core · GitHub

1 Like

And for reference, if using zigbee2mqtt instead of ZHA, there’s the GUI for you to change your channel:

1 Like

@Hedda @k8gg I am now on ch25 using the backup/restore method and everything appears to work way better! Sensors that just could not stay online now do… I’ll stick with ZBDongle-P for now at least… but I will monitor this thread in case there are new reasons to go with ZBDongle-E :wink:

I am looking new zigbee router for extending singal.
Right now I use Ikea Tradfri repeater. It is placed on top of the wardrobe. And sensor is outside, about 30m away, almost line of sight.

But I need move sensor a few meter, but then I cant reach with Ikea repeater.

Which model is better for extending signal farther?
As I understand Sonoff ZBDongle-E is a little bit powerful because it has default output gain 20dBm vs Sonoff ZBDongle-P default 5dBm, adjustable 20dBm

Or is there a better alterative router for get signal farther?

You need to confirm the router firmware for the “E” is 20db. If so, it might be the easier choice.

The “P” router firmware can be changed to 20db, but it may require re-compiling yourself, or maybe jus some google skills. I think someone else has posted a 20db build, but @Koenkk doesn’t post one on his github.

Remember those + numbers only relate to how loudly the router itself is transmitting. The router’s +5 or +20 rating won’t impact how loud the endpoint transmits. Neither router may be able to hear your endpoint.

With the current goal from Home Assistant’s founders/members of streamlining experiences, I am hopeful that we will also get more and more GUI setting/configuration options in ZHA’s UI/frontend now that Nabu Casa has hired @puddly (tip is to follow puddly on GitHub) who is one of the developers of ZHA and zigpy to work full time on improving the native Zigbee experience.

https://www.home-assistant.io/blog/2022/01/19/streamlining-experiences/

At least existing zha/zigpy YAML features for ZHA could probably be moved to UI without any issue(?).

I know puddly is currently working Zigbee network backup and restore features, inc. GUI options for it.

Personally, I would also love to see more ZHA UI functions for Zigbee OTA updates in UI to update device firmware via GUI prioritized if possible.

FYI, in related news to prioritization of Zigbee/ZHA in Home Assistant; the same type of Silabs EFR32MG21 SoC chip will also be used in the official “Home Assistant SkyConnect USB Stick”, see:

https://community.home-assistant.io/t/home-assistant-skyconnect-usb-stick-announced-will-be-compatible-with-both-zigbee-and-thread-including-matter-chip-over-thread/433594

You can submit your interest in the official “Home Assistant SkyConnect USB Stick” here if want to get mailed updates:

https://docs.google.com/forms/d/e/1FAIpQLScEjHSBJszUZfgO3MIDO51IHr3Oeohcs8BLpRIjY1liJ58IpA/viewform

The exact same Silicon Labs EFR32MG21 SoC is by the way also built-in to “Home Assistant Yellow” (formerly “Home Assistant Amber”):

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

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

Highly recommend you begin by reading and following these essential tips before buying anything:

https://github.com/zigpy/zigpy/wiki/Generic-best-practice-tips-on-improving-Zigbee-network-range-and-general-stability

Personally I normally just recommend that people new to Zigbee who have big houses and large areas or buildings with dense building materials make it easy for themselves and just buy a bunch of “IKEA Trådfri Signal Repeater” devices from the start to get them a good mesh network backbone as a baseline. This is because while not as strong as these Zigbee USB dongles with an external antenna, the “IKEA Trådfri Signal Repeater” comes with good firmware by default and are very inexpensive, so you can make up for them not having the highest performance by simply buying more of them, (and they are still more powerful than almost all other commercial Zigbee products that are not designed to be a dedicated Zigbee Router device).

https://www.google.com/search?q=IKEA+Tradfri+Signal+Repeater

Most importantly please understand that in a true mesh network topology like Zigbee uses it will always be much better to get many weaker Zigbee Router devices than it is to get only one or two very powerful/strong Zigbee Router devices. That way you can in practice get a redundant fully connected network (with the exception of the Zigbee Coordinator which in Zigbee 3.0 can only be one per Zigbee network). Otherwise, you will risk that powerful/strong Zigbee Router device becoming a single-point-of-failure so all devices that only connect to it will go down if it does.

https://www.ecstuff4u.com/2018/03/zigbee-topology.html

You could always try replacing the antenna and test different placement/orientations of it, but simply adding more and more Zigbee Router devices is really the best way to extend range and coverage in a single Zigbee network. Zigbee Home Automation uses wireless mesh network and wireless private area network (WPAN / Wireless PAN) technologies and is really meant to be used in a smaller mesh network in a relatively small area (e.i. within a single house/building).

However, if your devices as really far away in secluded/isolated areas with no reception to a single network might not be a good option, instead you might be better of adding a second Zigbee Coordinator connected to a separate secondary Home Assistant ZHA or Zigbee2MQTT instance at that location and then share the device to your primary Home Assistant instance over a wired LAN (local area network) via either HomeKit or MQTT message protocols.

Alternatively, go for devices that use a different technology than Zigbee in that specific remote location, choosing a device protocol which can support multiple connections/routes via LAN, (such as example Wi-Fi, LoRa/LoRaWAN, or Thread, inc. the new/upcoming Matter/CHIP standard over Thread).

That is correct. Again, the Zigbee SoC/MCU chips used inside the ZBDongle-E and ZBDongle-P have very similar specifications on paper if you just look at their data sheet, meaning the real-world performance difference will probably come down to the circuit-board/antenna design implementation and the firmware configuration.

I do not know if the current Zigbee Router firmware image that ITead released for the ZBDongle-E is also configured to use 20 dBm RF transmit power by default or if that makes any difference, but the default Zigbee Router firmware image for the ZBDongle-P is set to only use 5 dBm RF transmit power and is not configurable, for more information see this related feature request → https://github.com/Koenkk/Z-Stack-firmware/issues/341

ITead project manager can probably answer if the Zigbee Router firmware image for the ZBDongle-E is configured to use 20 dBm RF transmit power by default, however, the best way will be to do real-world testing of both with Zigbee Router device firmware in the different locations in your home for longer period of time and then switch places between them to be able to compare the results.

Absolutely correct, we normally say that it only shouts louder but it does not listen any better, but several different people still reported a better experience for them when using a Zigbee Router firmware image and/or Zigbee Coordinator firmware than have a higher than 5 dBm RF transmit power config.

1 Like

FYI, looks like Home Assistant will soon support automatic USB discovery for the new ITead’s “Sonoff Zigbee 3.0 USB Dongle Plus V2” model “ZBDongle-E” based on Silicon Labs EFR32MG21 if merge:

/homeassistant/components/zha/manifest.json

  {
      "vid": "1A86",
      "pid": "55D4",
      "description": "*sonoff*plus*",
      "known_devices": ["sonoff zigbee dongle plus v2"]
    },

/homeassistant/generated/usb.py

    {
        "domain": "zha",
        "vid": "1A86",
        "pid": "55D4",
        "description": "*sonoff*plus*"
    },

The board of this new ZBDongle-E adapter uses a WCH CH9102F USB-to-UART/Serial converter chip (and CH9102/CH340 device drivers) which has VID (Vendor ID) "1A86 " and PID (Product ID) 55D4 as well as the new USB product description identifier “sonoff zigbee dongle plus v2” on this variant.

https://www.home-assistant.io/integrations/zha#discovery-via-usb-or-zeroconf

https://community.home-assistant.io/t/community-help-wanted-to-whitelist-all-compatible-zigbee-and-z-wave-usb-adapters-for-automatic-discovery-in-home-assistant-os/344412