Thank you for the detailed reply @Hedda. I’ll give it a chance with the “E” dongle then and start replacing my deCONZ setup.
Note that everyone here can also help the developers make this dongle more stable in Zigbee2MQTT.
If you stumble into issues that seem related to this or other Silicon Labs EFR32 based Zigbee dongles then try to help the developer of the ezsp adapter for Zigbee2MQTT’s zigbee-herdsman code by providing detailed descriptions of your problem and logs needed for troubleshooting and debugging. See → https://github.com/Koenkk/zigbee-herdsman/issues/319
Note! If feeling brave then also consider upgrading to the latest unofficial 7.1.x community firmware builds on the ZBDongle-E to help them with testing the updated EZSP v9 interface with Zigbee2MQTT.
Regardless be sure to follow these generic best practice guidelines which apply for all Zigbee Coordinator USB adapters regardless of Zigbee implementation (including Zigbee2MQTT and the ZHA integration) → https://github.com/zigpy/zigpy/wiki/Generic-best-practice-tips-on-improving-Zigbee-network-range-and-general-stability
1 Like
I’ve upgraded to this firmware on my dongle and it resolved the issues I was (ironically) having with pairing SONOFF contact and movement sensors. After the upgrade, they finally paired and finished the interview process. The older firmware would just fail to finish the interview.
Edited to add that I’m using the xsp1989 firmware and used the Elelabs Python script.
2 Likes
Thanks for the info. I already have it up and running and added a few devices…so far so good. I do have a small issue with a thermostat device though, but I don’t think it’s related to the ezsp adapter specifically. Where would I log an issue related to device configuration? (the issue is that the climate sensor shows the wrong temperature sensor used for temp control)
Suggest first report Zigbee2MQTT issues to https://github.com/Koenkk/zigbee2mqtt/issues/ but can be they will referer that fix is needed in zigbee-herdsman-converters https://github.com/Koenkk/zigbee-herdsman-converters/issues as that is what Zibee2MQTT uses to parse messages to and from devices, read → https://www.zigbee2mqtt.io/advanced/support-new-devices/01_support_new_devices.html
For anyone reading this, I managed to understand how to flash a newer firmware on the ZBDongle-E using SecureCRT.
Do not follow this guide since it is horrible, instead follow this guide that is slightly better, to understand at least.
- Download SecureCTR here
- Get the .gbl firmware for router here or coordinator here
- Dismantle ZBDongle-E
- Start SecureCRT
- Press the Boot loader button and keep holding it in, see picture here
- Insert the ZBDongle-E in your USB port and keep holding for ~10sec, should be a red light.
- Press File tab > Quick Connect >
- Settings should look like this
- Press connect
- Once you see the bar on SecureCRT blinking press “Enter”, a menu should pop up.
- Press key “1” and “Begin upload CCCC” will start loading.
- Press Transfer tab > Send Xmodem > Select the downloaded firmware
- Once finished it will say “Serial Upload Complete”
- Unplug ZBDongle-E
Done.
I got my ZBDongle-E yesterday and I had the latest version so i didn’t need to upgrade:
Firmware: 6.10.3-41
EZSP v8
Hope you find this helpful!
12 Likes
I’m a little bit lost atm. Yesterday I received my Dongle-E, immediately I flashed with the above mentioned coordinator firmware (Sonoff_Zigbee_Dongle_Firmware/Dongle-E/NCP at master · itead/Sonoff_Zigbee_Dongle_Firmware · GitHub).
I have a lot of issues currently. Devices not responding which were on my deconz/conbeeII installation and devices not being able to link to the stick. Now I’m wondering which FW would be best. Is it really the mentioned above one, or should I switch back to the original.
Where is the latest FW for Dongle-E? The link I mentioned is a 5 month old FW. Other FW’s i can find are ~2 / 3 months old. Since this is a pretty new dongle I’d imagine the latest FW should be more recent, right?
No the firmware is the latest for Dongle E… in fact the dongle e was released with the latest firmware so there was no need to update. I have no idea how frequently Sonoff plan to update the firmware…
As far as not resonding… just make sure of the following:
If you are running the dongle on USB 3 make sure you have a USB extention cable as USB 3 gives off major electrical interference…
As far as I know you can also use a USB port with little to no interference.
I have been running the Sonoff E dongle for about 2 months now and i have had zero issues with it,
(USB 3 with 1.5 meter USB extention)
ZHA or Z2M?
Also what fw?
I am running Z2M, I did try ZHA which worked great but I have a few Ikea Air Purifiers and ZHA does not report all sensors…At the moment I am sticking to Z2M… at least until there is new firmware from silicon labs for our Sonoff for the new multiradio add on…meaning Zigbee and Openthread on one stick.
My Sonoff Stick is FW version 6.10.3.0 which is the current (5 month old) version.
I have been running it on Z2B and overall pretty happy. It can be hard to pair Xiaomi’s devices but i had the same issue with my Conbee 2.
I find it faster and more stable than the Conbee 2.
Right that clears things up. Thanks. So to my understanding the latest official fw is the one from my link, so 5 months old and this is thé recommended FW.
And to be clear; it is not recommended to flash to a community FW as I have read above: zigbeeFirmware/firmware/Zigbee3.0_Dongle-NoSigned/EZSP at master · xsp1989/zigbeeFirmware · GitHub or zigbee-firmware/EFR32MG2x-768k at master · grobasoz/zigbee-firmware · GitHub unless you are testing stuff.
And to check, my dongle-e is on this version, which is the latest:
Coordinator type: EZSP v8
Coordinator revision 6.10.3.0 build 297
1 Like
That is correct, there are a few people who have compiled there own, and have updated EZSP to version v9 with a Coordinator version of 7.1.x. the problem they have found is there is no downgrade/rollback option to 6.10.3… which means you would be stuck on the alpha firwmare.
At the moment I am not that brave. So my suggestion is to keep up to date with development and wait for the stable version to come out.
1 Like
Great thanks! Much appreciated.
Unfortunately my Aqara Door sensors whoam connect just fine to my old Conbee2 / Deconz environment just won’t connect to this. Or atleast not through a routed connection. I’ll see if I can find more information about this.
Hi @DENightOne Quick question, I am thinking of purchasing ZBD-E (since it’s the only one in stock) can you please confirm if OTA update and groups are working with this dongle? as per github page, it is still under “TODO”.
Thank you,
I can confirm that OTA works fine…but I only have Ikea bulbs…Ikea Air Purifier and remotes…there have been about 3 OTA updates so far since I have been using the ZBD-E…I aslo have Philips Hue bulbs but there has been no update since I installed ZBD-E so I cant say for sure that it works…what I can say is that the updates take quiet a lot longer then my old Ikea Zigbee Gateway…but it does work without problems. I have only set up one group with the dongle to control 4 ikea bulbs and that worked fine as well… (Zigbee2MQTT)
1 Like
I can conform both
1 Like
Noticed as well zigbee-herdsman have added initial support for “Backup” as merged, so believe that “Restore” should be the biggest feature still missing for Silicon Labs EZSP support in Zigbee2MQTT(?):
https://github.com/Koenkk/zigbee-herdsman/issues/319
TODO:
- Improving the stability work of the network
- Groups
- Touchlink
- Backup / Restore
- OTA update
- Tests
- ZGP (Zigbee Green Power)
I then guess that extending “Backup” and “Restore” interoperability in the zigbee-herdsman library will then also be another related big feature for migration compatibility in order to allow backup and restore between different manufacturers’ Zigbee Coordinator stacks in Zigbee2MQTT(?). That is, being able to backup a Texas Instruments-based Zigbee Coordinator with Z-Stack/ZNP firmware in Zigbee2MQTT and then restore from the backup files to a Silicon Labs based Zigbee Coordinator with EmberZNet/EZSP firmware in Zigbee2MQTT, or vice versa migrations, in order to update to a newer Zigbee Coordinator adapter inside the Zigbee2MQTT application.
The use case for such cross-manufacturer backup and compatibility feature in zigbee-herdsman is primarily wanted by Zigbee2MQTT users who currently have an old TI CC253x (CC2530/CC2531) based Zigbee Coordinator adapter and want to migrate to a newer EFR32MGxx (EFR32MG13/EFR32MG21) based Zigbee Coordinator adapter. Same for those with old Silabs EM358x /ETRX357US based Zigbee Coordinator adapter wanting to migrate to a newer TI CC2652/CC1352 based Zigbee Coordinator adapter.
So just to update to a newer Zigbee Coordinator adapter inside Zigbee2MQTT or IoBroker without having to re-pair or configure any devices.
I believe that both of those migration paths should be possible to achieve someday within Zigbee2MQTT? It relies on the “Open ZigBee Coordinator Backup Format” specs. for hardware-independent backups → GitHub - zigpy/open-coordinator-backup: Open Zigbee coordinator backup format
1 Like
Could you give me a step-by-step instruction how to do it?
I’m finding that the 9888010100045 dongle is better suited for larger Zigbee networks than the newer ZBDongle-E. Here’s my story;
The older dongle has an issue where once or twice a month it seems to disconnect and require a restart of HA to restore ZHA. It seems (seemed) the ZBDongle-E had become established over the past year so I decided to take the chance and order it. The migration to the new dongle was seamless using the migration tool in the ZHA integration.
But post migration is where the issues started to show… There were “Out of Memory” startup errors thrown by ZHA in the logs when the integration attempted to set CONFIG_APS_UNICAST_MESSAGE_COUNT to 64. I dropped it down to 32, but eventually was able to get it to 48 after flashing one of the community firmware images. The same errors were also true when trying to set CONFIG_ROUTE_TABLE_SIZE to 32. It turns out that 26 was as high as I could get that to go without throwing an error.
The show stopper was that ZHA started off good after a restart then the system eventually stopped responding altogether. The logs were full of messages of maximum concurrency reached like these…
DEBUG (MainThread) [zigpy .application] Max concurrency (48) reached, delaying request (3144 enqueued)
Thousands of messages queued up? I also noticed commands sent to devices 20-30 minutes prior would eventually work.
It’s worth noting that I kept the both Zigbee sticks in the same location, connected by a 12 foot shielded USB cable to a USB2 port with a ferrite choke on each end. WiFi interference is ruled out a scan shows no utilization on Channel 1 (Mesh uses Zigbee ch 12).
Tonight I migrated back to the 9888010100045 dongle and the concurrency messages still intermittent but the number of mesage enqueued was usually between 1-4.
DEBUG (MainThread) [zigpy .application] Max concurrency (64) reached, delaying request (1 enqueued)
Responsiveness is still a quite a bit laggy compared to the near instant response that I saw before the migration to the ZBDongle-E, but migrating back to the 9888010100045 stick mostly solved backlogged message queue.
I think part of that is driven by the fact the older dongle can do 64 concurrent messages where the E can only do 48, but that still doesn’t explain why the backlog of message went into the thousands with the E, but never goes higher than 3-4 on the older stick.
As a disclaimer, I have 214 Zigbee devices with about 70ish Zigbee outlets reporting power usage, so the network is busy.
Curious if anyone or any of the Zigbee devs might have additional thoughts or insights.
1 Like