ITead's "Sonoff Zigbee 3.0 USB Dongle Plus" (model "ZBDongle-P") based on Texas Instruments CC2652P radio SoC/MCU

@Hedda @jerrm

Thanks for all the information.
I actually played around a little, placing the devices and following your advice.
I must say, I would have expected that Zigbee is a little bit more stable and not that fragile. I wonder how people can successfully cover a full house with just buying stuff from IKEA or Phillips but anyhow. My Basement is well build which makes it a perfect cage for any wireless signals. I struggled with WIFI already so I decided try placing my Sonoff stick in the first floor using a looooooong USB cable :slight_smile:
Did that with my Homematic stuff already, which works great.

Besides that, I found a position for a router in the first floor which reliably connects to the coordinator and therefor lets devices take part in the network. I start understanding things and also tested Zigbee2MQTT which for now I am not a fan off - too complicated right now :wink:

THANKS

Well, while most Zigbee Coordinator adapters are relatively extremely sensitive to electromagnetic interference your Zigbee network mesh as a whole should still be generally stable as long as you have enough mains-powered Zigbee Router devices that have permanent power so are always available.

It is really a matter of combining quantity and quality. Most newer mains-powered devices from IKEA or Phillips usually work very good as Zigbee Router devices, (some others brands are unfortunately not). Try to spread out your known good Zigbee Router devices, and make sure to update their firmware too.

Personally, I generally recommend starting out a large Zigbee installation by installing at least one IKEA Trådfri Signal Repeater on each floor as they are inexpensive and a very good Zigbee Router device.

https://www.ikea.com/us/en/p/tradfri-signal-repeater-30400407/

https://www.ikea.com/gb/en/p/tradfri-signal-repeater-80424255/

https://www.ikea.com/se/sv/p/tradfri-signalfoerstaerkare-10400408/

Alternatively if you care more about function than esthetics then buy additional “Sonoff Zigbee 3.0 USB Dongle Plus” adapters, reflash them with the latest Zigbee Router firmware and use with USB charger.

https://github.com/Koenkk/Z-Stack-firmware/tree/master/router/Z-Stack_3.x.0/bin

Tip is to hide your Zigbee Router devices regardless so no humans unplug or move them by accident.

Another general tip is to try to make sure that Zigbee Router devices as not accidentally turned OFF (which is a common human error when using Zigbee lightbulbs still connected to wall or cord switches).

PS: Remember that Zigbee is low-power (weak signals) and being on the 2.4GHz band its higher frequency does not have good penetration power through denser and dampening building materials:

https://www.signalbooster.com/blogs/news/how-much-which-building-materials-block-cellular-wifi-signals

3 Likes

I did some reading too in the last days / weeks :smiley: and came to the same conclusions :slight_smile:
I just wonder how “normal people” get there Zigbee networks working reliable in a crowded area like cities etc. But perhaps it is like you said, all that counts is the network itself which is stable and the proper grouping of devices. Which normally the coordinator takes good care of especially if you look at the user interface of Tradfri and Hue Gateways :wink: they just hide most of the things I see and start caring about.

Sometimes less is more :smiley:

Anyhow, thanks for the tips, I must get the Zigbee network up and running anyhow, because for the reason I starting this CO Sensor and Smoke Sensor, there are no good WIFI options, no homematic options for CO sensor and Z-Wave would be an option, but because HA started to integrate Zigbee into Amber and IKEA jumped onto Zigbee too, I thought this is the way to go :wink: and I found smoke and CO sensors for this purpose.

And the next use case, of having “switches” lie around for different purpose, this is also something a) where WIFI (shelly button) is not really responsive, they are too slow b) homematic is too expensive to lose them :wink: and c) zigbee is the only cheap option to have a couple of them for different purpose.

THANKS and hoping that the upcoming firmware for the sonoff is improving overall usage experience :smiley:

Personally, I currently use two CC2652 based USB adapters (one Sonoff Plus USB dongle and one ZZH USB dongle right now) to the same Home Assistant instance myself at home in order to utilize both the ZHA integration and Zigbee2MQTT for different Zigbee devices, (so one dedicated USB dongle per Zigbee platform, with both connected to the same computer with Home Assistant OS).

I primarily use the ZHA integration for the majority of my Zigbee devices because its component is natively integrated into Home Assistant (so do not have to deal with MQTT for it) and only use Zigbee2MQTT for a couple of newer non-standard devices that do not have full support in ZHA yet.

One of the main downsides with using both solutions at the same time is that I need to have a baseline of at least a few Zigbee Router devices in both of those totally separate Zigbee networks/meshes.

I think because Zigbee2MQTT still has a larger/broader community it does tend to get faster support for less common and odd niche Zigbee devices that deviate further from Zigbee standard specifications and therefore needing custom quirks/converter code for each individual device and function/attributes.

By the way, If you can code/script and prefer Python over JavaScript/TypeScript then suggest you use ZHA instead of Zigbee2MQTT, and vice versa, that way you can at least edit your own quirks/converters and contribute them back to the community, but if you can not code/script then suggest that you try out both, even at the same time (which again will require you to buy an additional Zigbee Coordinator adapter).

I actually started out my smart home journey with Z-Wave myself almost 10-years ago and today still have more “Z-Wave Plus” devices than Zigbee devices since most my Z-Wave devices still work great.

Z-Wave devices are relatively much more expensive however in my experience their build quality is generally great, and since Z-Wave specification has stricter certification standards their interoperability and compatibility is usually excellent, plus operating on the ISM radio band frequencies their lower frequency allow much better wall penetration and range, so it is easier to start out with a small setup.

What I like more about Zigbee is the very low price of most devices that enable a much wider adoption.

I personally believe that the new “Matter” (“Matter over Thread” and “Matter over WiFi”) standard is the future and my guess that given the time span of maybe 10 years from now it will eventually have out-competed all others existing standards as a choice when companies bring brand new products on the market as prices for those products drop because of competition, but think it will take many years before there is a large selection of devices at a similarly low price point available, so both Zigbee and Z-Wave still got quite a few more years before getting obsolete, (and your already bought devices will, of course, keep working in Home Assistant unless their hardware break).

Considering that being a brand new standard and Matter also requiring stricter certification to achieve better interoperability/compatibility (similar to Z-Wave Plus), I assume that most first-to-market “Matter over Thread” products will probably not be cheap as Zigbee devices, at least not the next few years.

Since Matter of Thread currently also only operate over the 2.4GHz band and not (yet) over lower frequencies like the ISM radio band it will also have the same wall penetration issues as Zigbee, but unlike Zigbee which is limited to only one Zigbee Coordinator I understand that with “Matter over Thread” will be possible to add more than one “Thread Border Router” devices and support fail-over by default to possibly remove that single-point-of-failure.

1 Like

I had the same Issue in the past with the Conbee 2 stick and deCONZ, the network was not reliable.

But after switching to Sonoff dongle (and Zigbee2MQTT), the devices just worked better. The signal strength appears to be increased and I am not having failures (for example not to be able to turn on the light).

The Zigbee network looks like this now.

I have the same amount of repeaters and the location of the dongle is more or less in the same place.

Anyone with experience on the new firmware released for 2022?

I have been running coordinator variant of the Z-Stack_3.x.0 20220219 version fine for two months now:

https://github.com/Koenkk/Z-Stack-firmware/tree/master/coordinator/Z-Stack_3.x.0/bin

Very important is to also update firmware if using Zigbee Router firmware to use these as repeaters:

https://github.com/Koenkk/Z-Stack-firmware/tree/master/router/Z-Stack_3.x.0/bin

The latest upstream bug-fixes from Texas Instruments contain many important fixes for Z-Stack Router:

https://software-dl.ti.com/simplelink/esd/simplelink_cc13xx_cc26xx_sdk/5.40.00.40/exports/changelog.html

https://software-dl.ti.com/simplelink/esd/simplelink_cc13xx_cc26xx_sdk/5.30.01.01/exports/changelog.html

http://software-dl.ti.com/simplelink/esd/simplelink_cc13x2_26x2_sdk/5.10.00.48/exports/changelog.html

http://software-dl.ti.com/simplelink/esd/simplelink_cc13x2_26x2_sdk/4.40.00.44/exports/changelog.html

http://software-dl.ti.com/simplelink/esd/simplelink_cc13x2_26x2_sdk/4.40.00.44/exports/changelog.html

1 Like

I upgraded to zigbee2mqtt 1.25.0 and the 20220219 firmware in a Sonoff 3.0 dongle. I am seeing some of my devices on this network having trouble connecting and staying connected after the upgrade.

Am I correct that there have been no firmware changes for CC25xx devices, in terms of any TI zigbee stack functionality? I am not clear if the TI 5.30.xx SDK is used with the CC25xx devices. Either by Koenkk or PTVO.

The issues I am seeing since the upgrade :

  1. Sengled E11-N14A bulb would not connect to network until I did a reset of the bulb.

  2. ptvo.info based CC25xx (TI and eByte) no longer seem to be doing routing functions. I have not reset these devices as yet, they connect to coordinator, but do not seem to act as routers as they were before.

  3. without the CC25xx routing devices, the network pretty much collapses, as the various end devices struggle to direct connect to coordinator without intermediate routers. The zigbee end devices include : ptvo.info CC25xx (real and clone), Xiaomi, SmartThings, Tuya.

David, was experiencing something similar. I was upgrading the firmware to 20222919 during the weekend (did not change Z2M, was already on 1.25.0).
After the FW upgrade everything looked perfect. The devices were getting visible again as reporting. After 4 hours everything looked good and all devices was reporting “keep alive” and things was working (I belived).
The next day my kids were complaining that 2 specific switches was not working, one being a Tuya and one a Aqara mini.
First checked in Z2M, and both switches had reported battery state and “last seen” only a short time ago. However, even pressing the buttons, the “last seen” would not update. Tried to “re-pair” the switches, however did not make any difference.
Solution was to delete the device from Z2M, and then pair them as new devices in Z2M (easy as all automation will continue to work if you rename to the same device name). Then everything was back to normal. Might be worth a try on your devices.

Luckily this was only 2 switches, and not all my 70+ devices:-)

Thanks for sharing @khvej8 ! With your large network, good example of the challenge of change vs. happy where we are issues. I have down graded my firmware back to the 20211217 release. Have kept the zigbee2mqtt version at 1.25.0. Things are running ‘better’ but I think not as stable as when I was on 1.23 and 1.24. I had one crash of my zigbee2mqtt 1.25 with the 20220219 firmware after I posted. This was the driver to start the down grade path. The CC25xx routers seem to be continuing to work after about 8 hours with 1.25.0 and 20211217 firmware. I am going to let it run for a while more before considering posting a bug report.

To your recommendation. I did do some of what of subset of your recommendation with the Sengled bulbs. However, I did not delete and re-add my CC25xx PTVO routers. I did power cycle these devices and they were routing for about an hour or two before my zigbee2mqtt docker image crashed with the error below . I am pretty non-plused on the idea that I have to delete and re-add devices after a coordinator upgrade. I have been messing around with a number of zigbee systems for a pretty long while now. These latest issues with zigbee2mqtt and the coordinator firmwares, is rather concerning to me, far more issues with upgrades in last week vs. upgrades over many years of other systems (and older cc25xx based zigbee2mqtt system) :

Error: SREQ '--> ZDO - extRouteDisc - {"dstAddr":24409,"options":0,"radius":30}' failed with status '(0xc7: NWK_TABLE_FULL)' (expected '(0x00: SUCCESS)')
    at Object.func (/app/node_modules/zigbee-herdsman/src/adapter/z-stack/znp/znp.ts:322:27)
    at Queue.executeNext (/app/node_modules/zigbee-herdsman/src/utils/queue.ts:32:32)

Can’t get the Dongle to go into bootloader. Not sure if it’s just bad or what. Anyway to reset it back to factory defaults?

Try get into bootloader mode via software using → https://github.com/JelmerT/cc2538-bsl/

For ITead SONOFF Zigbee 3.0 USB Dongle Plus: For the CC2652P based “SONOFF Zigbee 3.0 USB Dongle Plus” (model “ZBDongle-P”) adapter from ITead you need to invoke toggle to activate bootloader with --bootloader-sonoff-usb if you do not want to open its enclosure to manually start the bootloader with the boot button on the PCB.

Read more tips on that here → https://github.com/JelmerT/cc2538-bsl/pull/114

Note that need to download the project from GitHub and not from PyPI as that has not been updated!

Alternative is to use Python script from ITead which will only put it into bootloader mode and not update:

https://github.com/JelmerT/cc2538-bsl/files/7476867/uartLog.txt

https://github.com/JelmerT/cc2538-bsl/files/7504452/uartLog.zip

https://github.com/JelmerT/cc2538-bsl/issues/113

Not sure what you mean exactly. You can reset the NVRAM configuration in the application firmware to default via zigpy-znp tools (i. e. the Z-Stack firmware), but if your bootloader is corrupt so will not load then only way to recover is to flash manually via a “cJTAG” adapter as mentioned a few times above.

https://community.home-assistant.io/t/iteads-sonoff-zigbee-3-0-usb-dongle-plus-based-on-texas-instruments-cc2652p-20dbm-radio-mcu-now-sold-for-14-99/340705/263

There is no reason that two Sonoff dongles flashed as routers cannot connect to the same coordinator with ZHA, right?

I’m biting the bullet and trying Zigbee again after major frustration with constant network issues a couple of years ago. Because of my past frustration and the very good price of the Sonoff dongles, I want to set up a couple as routers from the start. I will mostly have battery powered end devices.

I have successfully flashed (with Koenkk’s firmware) and set up one Sonoff dongle as a coordinator and another as a router. Both are added in ZHA and are working fine.

I’ve flashed the same router firmware onto another dongle (a few times to check), but I cannot get it to add with ZHA. Nothing shows in the log.

Any suggestions for how to troubleshoot this?

Thanks.

I have two as routers, but with z2m.

After flash router firmware they will act just like any other Zigbee 3.0 router device, so can have as many as your Zigbee coordinator can handle, (which is a maximum 200 Zigbee 3.0 devices if using Z-Stack 3.x.0 on a CC2652 based Zigbee Coordinator like ITead’s Sonoff Zigbee 3.0 USB Dongle).

Suggest physically optimising set-up placement for both coordinator and routers to avoid interference, as well as locate them in the optimal location for best signal range based on physicial obstacles.

Recommend read and follow the setup tips in green part here → https://github.com/home-assistant/home-assistant.io/commit/970295a277e8f01d3ee39eeeaacf453625b988d3 from my ZHA docs pull request → https://github.com/home-assistant/home-assistant.io/pull/18864

Also read and follow these best practices → https://www.home-assistant.io/integrations/zha#best-practices-to-avoid-pairingconnection-difficulties

Thanks a lot for the reply, @hedda. I had actaully read the best practices and thought that I was following them. But, I’ve now decided that I just have unrealistic expectations about Zigbee range–or maybe just a house that is particularly hostile to Zigbee.

I tried paring the second router next to the coordinator and, sure enough, it was discoverd right away. I’ve ordered a bunch of Zigbee smart plugs to put one in each room. I’ll remove everything except the coordinator from Home Assistant and then rebuild what I’m thinking of as the network backhaul using the routers and plugs according to the guidelines before adding any battery powered end devices.

For future reference, is there any way to get a log directly from a Zigbee dongle configured as a router? For example could you connect the router to a Pi and get a log over serial? That would have helped me to know that faulty flashing or something else with the dongle itdelf was not at fault here.

Thanks again.

Btw, consider giving PR thumbs up → https://github.com/home-assistant/home-assistant.io/pull/18864

I generally recommend that people who think they are going to build a Zigbee network that will cover many rooms should start out by buying at least three “IKEA Tradfri Signal Repeater” to use as Zigbee router devices right at the beginning and place those so get a good backbone in your Zigbee network.

And I agree and Zigbee having poor wall penetration is a fact. Coming from mostly using Z-Wave devices over 868-920MHz + legacy RF-based IoT devices over 315-433MHz (and mostly high-powered WiFi routers / access-points for home use) myself, I know and understand that it can be hard at first to grasp is comparatively poor wall signal penetration + short distance requirements for good Zigbee connectivity as well as how relatively sensitive Zigbee communication is to EMF/EMI/RMI interference for a stable Zigbee network.

The higher the frequency range the worse wall penetration you get, and battery-operated devices are normally limited in hardware or configured to not use high radio power amplification to save battery.

Zigbee network relies on mesh networking technology so with its poor wall penetration you will need to spread many Zigbee router devices that repeat all messages in order to get coverage to your devices.

Also remember that all Zigbee radios are weak as designed for low-voltage and low-bandwidth so they have very tight constraints on power and bandwidth, meaning signals are not strong and send very short messages. For those reasons, close proximity and an interference-free environment are important.

https://en.wikipedia.org/wiki/Zigbee

https://en.wikipedia.org/wiki/Mesh_networking

Believe what you instead is a “zigbee sniffer” which allows using Wireshark to sniff Zigbee traffic. See:

https://www.zigbee2mqtt.io/advanced/zigbee/04_sniff_zigbee_traffic.html

Zigbee packet sniffing with Wireshark will allow you to eavesdrop on Zigbee communication (and record for later analyzing) between Zigbee devices without being part of that Zigbee network. That can be perticular usefull for developers and advanced users to troubleshoot pairing and connection issues.

Or do you mean connecting via JTAG instead of flashing via USB/serial? You can flash CC2652 via cJTAG but that is really only a recovery option if the bootloader is corrupt or failed (which gives you option to flash via USB/serial) as JTAG/cJTAG does not really give you any more information. See:

https://electrolama.com/radio-docs/advanced/flash-jtag/

Personally, I use cc2538-bsl by JelmerT for flashing over USB and think it gives enough information:

https://github.com/JelmerT/cc2538-bsl/

2 Likes

Great tips. Thanks a lot.

Exactly the kind of thing I was looking for. Thanks again. I hadn’t though about capturing the activity OTA.

Some one has firmware ROUTER CC1352P2_CC2652P_launchpad_router_20220125.zip with more that 9db? The standard firmware is “only” 9db. official link Thanks a lot