Not as a Bluetooth controller, no. There is currently no way to use Bluetooth on this hardware, and I believe that the SDK from Silicon Labs do not offer a full Bluetooth stack so it can not be used as a Bluetooth controller. As I understand the SDK from Silicon Labs only enable it with limitations in Bluetooth devices and Matter devices to use it for commisioning. Bluetooth in it is limited and not a full BLE stack so can not even be used in a Matter controller. If developers make a Matter controller using an EFR32MG21 then they still also need to have a seperate Bluetooth radio as well for BLE commisioning and that needs that do have a full Bluetooth, like for example an EFR32BG21.
Hi.
Which FW i need to use for my ZBDongle-E?
There is (https://github.com/darkxst/silabs-firmware-builder/tree/main/firmware_builds/zbdonglee) are:
- ncp-uart-hw-v7.3.2.0-zbdonglee-115200.gbl
- ncp-uart-hw-v7.3.2.0-zbdonglee-230400.gb
- ncp-uart-hw-v7.3.2.0-zbdonglee-none-115200.gbl
What’s the real difference?
And why are they labeled as “ncp-uart-hw-v*” even though ZBDongle-E definitely doesn’t support Hardware Flow Control?
As wrote in just a few posta above, for the Zigbee Coordinator firmware you can either choose to use the 6.10.3.0 version from ITead/Sonoff which is mature and as such is known to be very stable or you can choose to use the much newer 7.3.x.x versions which many have reported as working well but has not yet proven itself.
You have to test and see if a version and variant works good for you. Regardless, those are all experimental so use at your own risk.
The speeds are just the serial speed so the faster one of those should be better in theory since the this chips on this dongle can handle it but you then propneed to manually enter the higher speed in the software configuration.
Not sure what ”hw” means here as I do not think that pins for hardware flow is connected (and if so it should hopefully just fall back to software flow control). Hardware flow control would be better if this board supported it.
I assume that ”none” means no flow control but then do not know why it also sais ”hw”.
Suggest post those questions in the GitHub repo that @darkxst has for it.
Thanks for your reply.
“hw” in fw filename usually means the RTS/CTS flow control. But also fw usually fall back to no flow control at all, if board does not support requested hw control.
We can assume that the lack of flow control is worse than sw control.
But I’m probably wrong somewhere.
The filenames are generated from the silabs project name, which is ncp-uart-hw. For ZBDongle-E these images are patched to use Software flow control (this is the setting that the official firmware uses). the “none” firmware are patched to disable flow control completely.
ncp-uart-hw-v7.3.2.0-zbdonglee-115200.gbl is the recommended firmware and the one that is selected in the webflasher (once I update it to latest release soon)
Don’t worry to much about flow control or the lack of it. ZBDongle-E with no flow control performs much better than ZB-GW04 v1.2 with hw flowcontrol!
1 Like
Thank you for your clarifications.
I previously had firmware “ncp-uart-sw_7.3.1.0_115200.gbl” from another repository. Everything was working stable. But then I bought a device that is unstable and it needs to send multiple messages at a time for it to do what is required of it.I decided to experiment with firmware.
I installed “ncp-uart-hw_7.3.1.0_460800.gbl” from the same repository hoping that high speed and hw flow control will help me. But I started to notice that messages from sensors are not received (especially noticeable on motion sensors). Then I found out that hw flow control doesn’t work on my device.
Can you tell me why in your repository there is no ncp-uart firmware that would work at 460800 speed for dongle-e? Theoretically that would be better…
I’m currently testing “rcp-uart-802154-v4.3.2-zbdonglee-460800.gbl”. Everything seems to work stable (a couple of times I noticed some oddities, like pressing a button didn’t produce a result, but I’m not sure if that’s because of the firmware yet). But also subjectively I’ve noticed that the response of devices has become slower than on ncp firmware. Is this possible?
PS: I am using RPi 4 (2 GB RAM) with Sonoff ZBDongle-E.
Zigbee network itself is limited to 250kbps itself. NCP firmware is only relaying commands and data so in actual fact is going to need much less. I dont think there is any evidence that anything higher then 115200 for NCP will be better. theoretically 230 might be slightly better.
RCP multipan firmware is a different beast. Now you are offloading the coordinator role to your host for processing. That means the serial connection is now transferring the raw zigbee/thread data. you now need to keep up with the 250kbps, you also now have 2 networks (zigbee and thread) sharing the radio, which probably creates some overhead over the 250.
What sort of response time are you talking? Multipan is sharing the radio between thread and zigbee so will never likely be as fast as dedicated ncp zigbee firmware. That said with small networks it shouldnt add noticeable delay.
1 Like
Subjectively I have time to walk longer in a dark room before the lamp (zigbee relay) is triggered by the motion sensor (also zigbee). Accordingly, delays can be in any of the following places: signal from the sensor to the coordinator, signal processing in HA, signal from the coordinator to the relay…
I have about 25 zigbee devices in total (most of them are routers).
Multipan still sharing radio even if I don’t have Thread devices and I disabled thread router in the “Silicon Labs Multiprotocol” addon config?
If you are going to disable thread there is no real reason to run multipan firmware 
From a technical perspective I not sure what happens when otbr is disabled, but I suppose zigbee should get exlusive use of the radio then.
It seems to me to be a better approach where the adapter is only responsible for the physical layer and the application is responsible for everything else. This also organizes faster and easier delivery of updates.
well it does make swapping out the dongle slightly easier, but still no way to automatic failover on dongle failure.
Updates are a pain, as versions of dongle and multiprotocol addon must be kept in sync. A dongle with 4.2.x RCP wont work with multiprotocol 4.3.x!
1 Like
Hi
7.3.2.0 and all other one seams to be with hardware flow control.
I had try them but it crashed my dongle E. so I had manually to restore SW firmware.
Which firmware you are using ?
Hi. Please read last ~10 posts in this thread. Most of them about HW Flow Control on Dongle-E…
Hello
I have big issues with the ZNDongle-E firmware flashing.
I tried to flash the rcp-uart-802154-v4.3.2-zbdonglee-460800.gbl using an Ubuntu VM on VirtualBox in Windows.
This because I want to use both Zigbee and Matter/Thread.
Firstly I tried the web-flasher but with no success, tried on three different window computers.
So I moved to use a Ubuntu VM on windows, and following the instructions on this page (Flashing the Sonoff ZBDongle-E to enable Matter, Thread and Zigbee on Home Assistant | Dialedin) the flashing was NOT working, I got some error messages related to permissions errors.
So I used another tutorial, using Elelabs_EzspFwUtility and it worked fine, the flashing was successfull, but after the flashing, when the utility was rebooting the dongle, the message “couldn’t communicate with the adapter…” appeared
2023/11/22 19:09:40 Elelabs_EzspFwUtility: Couldn't communicate with the adapter in Zigbee (EZSP) mode, Thread (Spinel) mode or bootloader mode
2023/11/22 19:09:47 Elelabs_EzspFwUtility: Successfully restarted into X-MODEM mode! Starting upload of the new firmware... DO NOT INTERRUPT(!)
2023/11/22 19:09:59 Elelabs_EzspFwUtility: Failed to restart into bootloader mode. Please see users guide.
From that moment it’s impossibile to re-update or use the adapter.
Any help?
Thanks!
On windows, you can do it using the web flasher - just click on “FLASH” just below the image on that web page:
.
When you change from the Zigbee Router Firmware to the multiprotocol RCP Firmware, the protocol changes - you need to use the multiprotocol add-on.
Hey everyone, I just changed from my Conbee2 to the Sonoff -E dongle and flashed the lastest firmware through the web flasher. My need for now is only zigbee.
However, with Z2M, some devices don’t really work well. Indeed if I want to turn on a plug for example, Z2M sends some errors on the logs. The switch works after a couple of seconds or minutes.
For those who made the switch and where the firmware ncp-uart-hw-v7.3.2.0-zbdonglee-115200.gbl works fine, how did you make the migration? Did you re-pair every device?
Thanks!
FYI, EZSP adapter support is still experimental in Zigbee2MQTT’s zigbee-herdsman → [WIP]: EFR32 EZSP adapter implementation and test · Issue #319 · Koenkk/zigbee-herdsman · GitHub (so if want more stable then it is recommended to instead buy a CC2652 based adapter like ITead’s TI CC2652P based “Sonoff Zigbee 3.0 USB Dongle Plus” which was renamed to “ZBDongle-P .
Regardless of the adapter used, be sure you first read and try follow all tips/advice here before troubleshooting any deepder → Zigbee networks: how to guide for avoiding interference and optimize for getting better range + coverage
Exact same issue, trying to go to the Sonoff official router firmware. Have tried so many methods, this being the last in a series. Ever get a solution?
I was not having any luck trying to flash my E dongle as a router until I realized the firmware file I downloaded was not actually the correct file.
Make sure you go all the way to this page: https://github.com/itead/Sonoff_Zigbee_Dongle_Firmware/blob/386820120e2d1e5a18c0c45235adbc5bc94cd00b/Dongle-E/Router/Z3RouterUSBDonlge_EZNet6.10.3_V1.0.0.gbl
Then download the “raw” file from one of the buttons on the upper right. The file size should be about 280K.
Hope this helps someone feel less foolish than I did!
3 Likes
Arghhhhhhhh I am such an idiot!!
I saw the .gbl file, and figured I had it - meanwhile I’m trying to flash a $%#@ webpage to it!!
You truly are a star - thank you!
Worked first crack on my latest attempt with using the Elelabs python utility.
I’m surprised I didn’t brick it as I’ve tried to upload that damn webpage to this thing with so many uploader systems.
Honestly I’ve come across all the same error messages in Googling, trying to follow leads that I had on all the various method’s failures - so I’m guessing there’s probably more than just the two of us out there - so hopefully this helps others.
Thanks again - I’m now stepping back slowly into the hedge.
2 Likes