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?
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:
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.
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)
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 SL 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.
@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:
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:
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.
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.
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:
@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.
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
@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
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
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.
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:
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).
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.
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.
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.
I want flash router firmware. I tried that but unfortunately TI smartRF 2 cant open router firmware .gbl file. And there is no target device for EFR32MG21.
