I suspect its probably some other generic device. ZBDongle-P should show up with manufacturer strings, something like:
/dev/serial/by-id/usb-ITead_Sonoff_Zigbee_3.0_USB_Dongle_Plus_xxxxxxxx_if00-port0
No I suspect it is probably a Sonoff ZBDongle-P from very first batch that ITead released as not any other manufacturers I know of uses the CP2102N USB-to-Serial bridge chip. It is well known that ITead missed writing their custom USB description to the EEPROM of that chip in the very first batch and they even released a script that write that to it, for more details on that see Community help wanted to whitelist all compatible Zigbee and Z-Wave dongles/adapters for automatic USB Discovery in Home Assistant and there is also more on that if dig in the the Sonoff ZBDongle-P thread at ITead's "Sonoff Zigbee 3.0 USB Dongle Plus" (model "ZBDongle-P") based on Texas Instruments CC2652P +20dBm radio SoC/MCU
Not many zigbee dongles use it (apart from SkyConnect ), but it is fairly common in other devices, for example users of ESPHome probably come across it quite often in various dev kits etc.
For those using my RCP Multipan firmwares, I am testing a new way to distribute firmware updates.
This is a fork of the official Silabs Flasher HA Addon, but is shipped with my firmware builds. Once configured, It will automatically update dongle firmware on next reboot of HA, or you can manually run it after installing/updating. Currently supports ZBDongle-E and a few others.
If you test it now, it will install the 4.3.1 firmware update, released yesterday.
If you have any issues with it please create an issue here:
4 Likes
Just started my setup and was wondering if it’s safe to update the Dongle-E to the latest firmware before connecting Zigbee devices.
If using the native ZHA integration then it does automatic backups of your Zigbee network so it os always ”safe” to upgrade the firmware, however if using Zigbee2MQTT (Z2M) then you should do a manual backup your of your Zigbee network before upgrading firmware because Zigbee2MQTT does not yet fully support backup and restore of Silicon Labs EZSP based Zigbee Coordinator adapters.
With Zigbee2MQTT you can stop it and use zigpy-cli as a stand-alone command line tool for manual backup and restore of your Zigbee network from Zigbee Coordinator adapter as a workaround until it can do it → GitHub - zigpy/zigpy-cli: Command line interface for zigpy
Note that the Sonoff ZBDongle-E ships woth a very stable firmware so should not need to upgrade firmware unless get issues that following the best practices does not solve, read this → Zigbee networks: how to guide for avoiding interference and optimize for getting better range + coverage
I use Z2M intergration but my Sonoff ZB-Dongle E is now running on 6.10.3 and I was wondering if there’s any benefits to upgrade it to 7.2.3 before starting to connect devices to prevent bugs that may appear.
If using Zigbee2MQTT then this is not the best place to ask as it depends on their EZSP implementation and not the physical adapter, so better if you read and follow the development discussion in this zigbee-herdsman issue → [WIP]: EFR32 EZSP adapter implementation and test · Issue #319 · Koenkk/zigbee-herdsman · GitHub and if you get a specific problem in Zigbee2MQTT then post a new discussion in that community here → Koenkk/zigbee2mqtt · Discussions · GitHub
Newer firmware will probably have better device compatible but also introduce new bugs that no one else have stumbled onto yet, so if using newer firmware than most other then be prepared to act as a beta tester and help report issues to Zigbee2MQTT developers.
@netregha check out the experimental fork official Silabs Flasher HA Addon linked above by @darkxst for updating inside HAOS, or use Universal Silicon Labs Flasher (by Nabu Casa) for manual off-line update, e.i. disable Zigbee implementation then removing dongle to update on another computer. There are also other tools and methods mentioned + linked in my original post in this thread.
1 Like
thank you, i will take a look 
@Hedda
Using the dongle-E as a router at the moment. I have a network in ZHA based on dongle-P, it is pretty stable, I have around 60 router devices, 2 Sonoff Ps and 1 Sonoff E as routers, the rest are Ikea bulbs, tuya/samsung/sonoff switches.
Any reason to migrate to the Sonoff E as the main coordinator since I am on ZHA? Also will using the migrate feature actually mean I cant use the sonoff P as a coordinator again? I read somewhere around IEEA address constraints with the dongle E, couldnt find the post again, wasnt sure if it was only for 1 particular scenario.
Thanks in advance and apologies if this was already answered before
If things are stable, I’d leave it be.
The only advantage of the E isyou can potentially use it with the multiprotocol stack for thread. It’s not worth risking zigbee stability to test a few thread devices if you ever get any. Just use the E as a second thread specific controller.
Changing the ieee address on the SILabs chip is a one time, almost irreversible process. Supposedly it can be reset using a jtag programmer, but it is probably easier and less expensive to just buy a new E at that point.
The replaced P could still be used as a new router though. Unlike SILabs, the TI chip address can be changed repeatedly using normal firmware update software tools.
Anecdotally, I found the P to be the more stable coordinator, but there have been firmware updates since then.
2 Likes
Thanks @jerrm
I was planning on getting another E to be specific for thread/matter, having 2 protocols on one sounds like trouble 
Seeing more on the forum people complaining of stability when they have it enabled.
The have both dongles as routers but seems like the E has a better connections compared to the P. I am on the new router firmware for the P dongle and have tried multiple power levels but they dont really make any difference.
I’ll leave it alone for now, enough tinkering , there are still some IKEA Styrbar battery remotes that become unavailable after 24h for some reason. They still work though when I press them, not sure why this is the case. I thought signal was the issue but might be something else.
1 Like
Because of these same issues, I’m rethinking to re-flash the E to a coordinator and the current P as Router. The P coordinator is quite a disappointment atm due to the low LQI and disconnecting routers and end devices. Using the Zstack 20221226 P coordinator firmware.
IMHO, if using ZHA then there should not be any reason to migrate from ZBDongle-P to ZBDongle-E or vice versa, they should be equally good as each other. As mentioned the only reason is if absolutely want to use a Multi-PAN RCP with Zigbee and Thread on a single dongle, but I personally recommend against that as it is much better to use a separate dedicated radio for each wireless protocol (just make sure that not using the same channel frequency on two different radios).
Try to follow all these tips first → Zigbee networks: how to guide for avoiding interference and optimize for getting better range + coverage
2 Likes
Same for me. With Dongle P, I had very low LQI, and devices kept dropping off. With Dongle E, everything is super stable, and also, I have very good LQI all over.
Do you have a link where the process is explained? If the IEEE can be changed during the “Migrate Radio” process, why isn’t it possible to simply revert back?
How do you do change the power level? Recompiling is beyond my current skill level and the Sonoff documentation doesn’t explain much about doing this via serial port (using what software? is that change persistent? etc.) If that process is described somewhere, I’d appreciate a link to it.
For the jtag? No. Never had the need to pursue personally.
You’d have to ask SI Labs. Maybe to sell more chips?
It is a chipset limitation, not specific to the ZBDongle-E, SkyConnect suffer the same issue.
When migrating to an SI Labs coordinator, HA does throw up a not-scary-enough warning about the address change being permanent.
zha:
zigpy_config:
source_routing: true
znp_config:
tx_power: 12
ota:
ikea_provider: true # Auto update Trådfri devices
ledvance_provider: true # Auto update LEDVANCE/OSRAM devices
salus_provider: true # Auto update SALUS/Computime devices
otau_directory: /config/ota_ha
I believe as long as you are on the latest firmware, what you need is the tx_power under znp_config entity.
I didnt notice any difference though so I am not sure if this really works
Later ZHA works around this limitation so it should be a non-issue if using latest ZHA.
That works when using as a Zigbee Coodinator. Changing power on a Zigbee Router is only possible with ZBDongle-P as routers.
1 Like