Same experience for me too.
Moved from a Conbee II and Deconz to Z2m with the E dongle. Nothing but issues with pairing, and the ones that did pair would keep dropping off the network.
I replaced it with the P and its been rock solid for months.
A lot of fixes for EZSP in z2m in the past couple of months, and a lot of that was around pairing, so hard to say where the fault really was.
Just noting the general EZSP experience in z2m “months” ago is much different than today. Not discounting @srwhite’s issues at all, which were more recent.
But even in ZHA, I find pairing a lot smoother with the Dongle-P than the Dongle-E. I would need another EFR32MG21 based stick to compare with to determine if the differences were more about EZSP vs being Dongle-E specific.
I haven’t had issues with the Dongle-E mesh, but have only had the “E” on my test nets with a relative handful of devices.
Very good point. I still have the E, may give it another go.
I’d probably wait unless your just tinkering. I was just checking recent z2m github issues to decide if I wanted to install 1.29 yet, and there are a few recent dongle-E posts. Hard to tell how anecdotal they are at this point.
1 Like
All of the issues I had with the Dongle-E were on build 1.29.0. I had similar issues with connectivity drops and response lag with the same dongle using the native ZHA integration. I wouldn’t benchmark Z2M’s stability with EZSP based exclusively on the Dongle-E without trying a different brand of dongle first.
I think you were clear; You migrated to ZHA first, but you did not try to setup ZHA from scratch without migration, however you did setup Zigbee2MQTT from scratch. Point is that you did not test to setup ZHA from scratch with a reset adapter and that Zigbee2MQTT is not recommend for this adapter, only ZHA recommends it. And I think that migration from CC253X in ZHA should maybe have a warning and perhaps a recommnation to setup from scatch instead.
Suggest not making any conclusions based on experince with Zigbee2MQTT since it only have experimental support and this adapter is therefor not recommend for Zigbee2MQTT. And I think it is a bad idea to make deffinitive conclusions based on migration setup since migration is not fool proof, especially if migrated from old CC253X adapter which uses and old chip from a different manufacturer and a older Zigbee stack that is not Zigbee 3.0 compatible so migration to a newer adapter will be hacky. Migration can be a great tool if it works but I think there should be warnings about relying on it when migrating from older CC253x adapters.
My conclusion what that either the migration was corrupted or you dongle hardware is faulty. That could howver not be ruled out since you only tried to setup Zigbee2MQTT from scratch (which again only has experimental support for this adapter). Only if the same problem could be seen in ZHA setup from scratch with adapter reset to factory settibgs would I conclude that your adapter most likley have a hardware fault.
So what I meant is that you should have tried to ZHA from scratch without migration instead of Zigbee2MQTT, since Zigbee2MQTT’s ezsp adapter is experimental and known to be unstable, while ZHA is known to be very stable with this adapter, at least when setup is done from scratch instead of migration.
While there is no warning when migrating from CC253X there should maybe be warnings as I understand that the combination of cross-manufacturer and cross-generation is more or less a hack when migrating from CC253x, especially when using with old Z-Stack 1.2 firmware before and want to migrate to a new Zigbee 3.0 stack wierd issues have been reported, some migration due to bugs which have been fixes but others that could not be fixed due to for example old corrupt configuration on the older adapter.
Why I wrote: ” might not see same problem in ZHA with a greenfield setup instead of migration, some others reported migrations from CC253x seeing wierd issues due to previous configurations, howver then not having issues with greenfield setup from scratch after firmware reset, but understand that Zigbee2MQTT could maybe have such issues anyway even in greenfield setup as their ezsp adapter code is experimental”
For reference, I tried ZHA with the E dongle from scratch and had the same pairing issues that I had in Z2M.
I’m going to have another play with the E dongle and a few spare lights next weekend.
Regrettably, ZHA is singleton so that wasn’t an option however I don’t think that a corrupt migrations or bad NVM data would cause UART (serial) errors. I respectfully disagree that the lack of a test with ZHA invalidates the conclusions to the remainder of the testing I did. This is a hardware issue and based on the reports from others since my first post, not likely isolated to my stick.
I respect your dedication to Zigbee and Home Assistant. However, I’m not sure why you are so defensive about a piece of hardware. I am not new at this and have been doing Zigbee for more than a decade. This is a device that obviously has some issues that need to be worked out. And based on the reports that have followed, I am not alone.
1 Like
My experiences are very similar to both srwhite and WhimsySpoon.
I came from using a conbee II with Z2M, so in early December I figured I’d try the E dongle out. general instability and pairing issues all round. Eventually I resorted to a clean installation on ZHA. While I do think it stability was a bit better, I still had pairing issues and binding remotes directly to lamp groups just didn’t work at all. Aka showstopper as it would not pass the wife acceptance factor.
As I already spend well over 12 hours by then I grudgingly reverted to my old setup Z2m/conbeeII setup. The dongle-e has been gathering dust ever since.
I use a lot (60+) of Aqara end device, so it might just be attributed to that. I think the contact sensors specifically refused to pair. I observed this on both Z2M and ZHA. The conbeeII is rock solid with all of those though, so I’d still point to the dongle-e as the culprit.
2 Likes
I am experiencing literally the same thing, and unable to flash firmware
EDIT
I have been trying to follow everyones guides for TI based chips, should have realized that wouldnt work because I have ‘ezsp’ in my Z2M config.
I bought this specifically to run z2m, had no idea there was two variants until now 
i’ve had the dongle E and have found all my devices go offline after 8 or so hours. I am trying a new usb cord today.
I do have the Dongle P - (brand new from ittead) not sure if i need to flash it but i may move over to that. it’s hard to tell what the best action is.
I see there is migration tool tho which seems cool (I have about 40 zigbee devices)
Depends if you are using the ZHA integration of Zigbee2MQTT as EZSP (e.i. ZBDongle-E) only has experimental support in the later.
Z2mqtt. It’s been annoying having to fix it every morning so I’m willing to put the effort to re pair everything. Just not sure if I change the radio will I have to rename everything again not the end of the world as I can write it all down to ensure I get the names exactly right.
I bought the dongle.pc about 5 months ago. Also not sure if I need to flash it at all will check
So if i have both the dongle e and dongle p - reading this thread in more detail it seems I should use dongle p?
For zigbee2mqtt - yes. z2m ezsp (ZBDongle-E) support is still a work in progress.
ZHA support for ezsp is more mature. HA’s own Skyconnect stick uses the same chip as the ZBDongle-E, so if there are any issues with ZHA, they should be addressed relatively quickly.
1 Like
Yes both variants work great in Home Assistant’s own Zigbee integation (ZHA) but if using Zigbee2MQTT then should buy the ”ZBDongle-P” variant instead for now since they do not yet have great support for Silicon Labs based Zigbee Coordinator radio adapters.
Regardless note that while you can address issues with Home Assistant’s ZHA integration to the Home Assistant’s core developers, you need to address issues with Zigbee2MQTT to the Zigbee2MQTT project and their zigbee-herdsman developers.
So turns out I was using the IKEA repeaters that came with the fyrtur blinds as they don’t get used when you connect the blind to zigbee network.
I noticed that my dongle E had issues after I added these.
I removed from network. Never updated dongle.e firmware. And now my network is solid. Before it was just dropping once a day (all devices not responding.). It’s been just over a day so hopefully it lasts.
I have good other repeaters in my network.
1 Like
Hi all
Is there a simple way to move from -E to -P version using Zigbee2mqtt without loosing all connected devices?
Thanks
Not sure, maybe, better if you ask here → https://github.com/Koenkk/zigbee2mqtt/discussions
See it is already discussed here → https://github.com/Koenkk/zigbee2mqtt/discussions/16478
Perhaps it is possible these days to migrate from an EZSP adapter to an Z-Stack adapter and/or vice versa but even if is then will probably have to re-pair all your devices in Zigbee2MQTT. Read Z2M FAQ:
https://www.zigbee2mqtt.io/guide/faq/#how-do-i-migrate-from-one-adapter-to-another
and
https://www.zigbee2mqtt.io/guide/faq/#what-does-and-does-not-require-repairing-of-all-devices
Anyway, I do not believe that Zigbee2MQTT/ zigbee-herdsman already has support for cross-manufacturer Zigbee network backup and restore as of yet and that is what would allow be needed for migration without re-pairing all devices, (so far I believe the EZSP adapter code in the zigbee-herdsman library only supports Zigbee network backup but not restore, while in comparison the z-stack adapter in the zigbee-herdsman library does support Zigbee network backup and restore).
Note that Zigbee2MQTT is dependent on what the zigbee-herdsman library support and do not support (though note it is mainly the same developers who code both Zigbee2MQTT and the zigbee-herdsman library) → https://github.com/Koenkk/zigbee-herdsman
PS: More on Z2M EZSP support → https://github.com/Koenkk/zigbee-herdsman/issues/319
1 Like
Thanks
I will try to read all the info in the links you sent me to understand what I can do.