Oh men, i’m experiencing so much issues with this dongle-e. I had a hell of a time moving everything from deConz to Z2M, because when there was a FW update oid for a device, other endpoint devices wouldn’t join (took me a while to draw this conclusion).
I have a few devices (Aqara multi sensor or door sensor) which cannot join on the same location as they did join with deConz (with same router locations). Some devices couldn’t join after being removed from deConz (mostly powerplugs). Had to rejoin them to deconz to try again. Even after rebooting Z2M and everything, they just wouldn’t join, after joining to deConz, removing and trying again to join to Z2M it started to join.
So after a very painful transition period I thought it was getting more stable, but now after a week or two, today most of the devices were offline. Rebooting Z2M solved most offline messages but my Aqara opple devices left the network without notification. It did this twice today. And nothing has changed in my meter cupboard.
I also often get red error messages saying it is trying to reconfigure aqara light sensors. This fails, but the devices seem to be working.
Example:
Failed to configure ‘Kantoor_light_lux’, attempt 1 (Error: Bind 0x04cf8cdf3c787550/1 msIlluminanceMeasurement from ‘0xe0798dfffe718659/1’ failed ({“address”:8795,“clusterId”:32801,“sequence”:35} after 10000ms) at Timeout._onTimeout (/app/node_modules/zigbee-herdsman/src/utils/waitress.ts:64:35) at listOnTimeout (node:internal/timers:559:17) at processTimers (node:internal/timers:502:7))
All in all i’m not really happy with this device.
I’m using a decent USB extension cable, connected to USB2.0. Z2M is 1.28.4 (which is the latest I’m assuming) and the FW i’m using is 6.10.3.0 build 297 on my dongle-e, also latest official supported. All connected to a HP T620 with Hassio, all latest version’s too (2022.12.8)
I honestly don’t know what I need to do to get this more reliable, should I switch to the dongle-p or even just push my conbee2 sick into z2m (and migrate everything over again). Or should I try a experimental built and if yes; which one is best?
Or try ZHA, but even then in my limited testing, the 2652 still seems to perform better. I’m sure there are situations one may be better than the other. Maybe my device mix just prefers the TI chip.
If want to use the ZBDongle-E with Zigbee2MQTT then you should switch the Z2M dev branch (also known as as ”edge” version) and report issues to zigbee-herdsman instead of here as it still experiment in it in so know to be a bit unstable there.
I switched back from edge to stable because of the 1.28.4 update, it held some EZSP updates and hoped it would resolve my issues.
I just tried switching back to the EDGE, but it didn’t start. It tries starting but in the end nothing happens. I’ll look in to this next year deleting and reinstalling the edge solved it. So now back on EDGE.
With experimental FW I meant for the dongle, but as far as I can tell it is still recommended to stay on the official FW. Weird thing though, in the latter link of your post it says it supports touchlink, but as far as i can tell, it only supports this in experimental FW builds.
That is correct. Itead/Sonoff has confirmed that they missed enabling Touchlink in their currently available official firmware. So they are aware and next official should have it enabled, but for now you must use unofficial firmware if you absolutly need to have Touchlink today. Thus the hardware do support Touchlink but you need a firmware build with it enabled.
Hi All, I am completely new to HA and just started setting up my system a few days ago, but today I ran into an issue with this dongle. I apologize in advance, if this exact issue has been covered somewhere else in the forum, I tried my best to go through the seemingly relevant posts, but did not find the answer to my question. (found only this thread where the guy ended up with a clean install of HA)
I am running Home Assistant with the OS installation on a Linux VM (Oracle Virtualbox). When I plugged in the dongle initially, it discovered it automatically and I managed to configure the device flawlessly via ZHA. Today, however, I noticed that devices went offline and surely enough when I looked into devices & integrations I saw that the ZHA integration threw some error (PFA screenshot)
To go around this I thought I would remove and re-add the integration, but looks like the device is not getting auto-discovered. If I am trying to locate the hardware itself, looks like HA no longer sees it.
VM and even the host (W11 desktop) have been both restarted, dongle has been physically unplugged and plugged in again. Windows seems to discover the device, it also appears in VB, but strangely not in HA.
Sounds like a USB pass-through issue with the virtual machine in Oracle Virtualbox virtualization hypervisor and not an issue with Home Assistant operatingsystem.
Hopefully that will help you narrow down the problem but not much more we can help with that here as probably not issue specifically related to Home Assistant, as Home Assistant at least need to be able to see the dongle hardware as a serial port.
Better find a other forum that instead deal with configuring USB passthrough with Oracle Virtualbox.
It’s been a couple weeks since I last posted about this issue. In the time since I have done extensive testing with the Dongle-E as have come to the conclusion that I do not recommend this adapter for more than an a handful of services due to a flaw with the UART. Here’s a recap…
I decided to replace the 988 dongle with the Dongle-E, in part because the 988 is no longer recommended for use with ZHA for stability reasons. I used the ZHA migration tool to flawlessly migrate to the Dongle-E, and flashed the recommended 6.1.3 firmware prior to migration. After migrating to the Dongle-E ZHA would gradually slow down and then stop responding altogether. I gave up after 24 hours.
The migration tool was used again to migrate back to the 988 dongle, and again the transition was flawless. Within minutes of completing the migration ZHA was once again stable. I left it this way through Christmas.
Following the holidays, I once again used the migration tool to switch over to the Dongle-E. Before attempting this, I flashed one of the community firmware builds. This time I replaced the 12 foot USB extension and used a different USB port on the server, just in case either of these could be a factor. Still no change. Within an hour or two ZHA was barely responsive (10-20 second lag). To rule out interference I used a USB over CAT6 extender to move the Dongle-E about 30 feet from the servers. Still no change. HA logs were full of concurrency errors but nothing else.
The migration too was used once again to migrate back to the 988, and again within a few minutes the Zigbee network stabilized.
Thinking ZHA might be at fault, I stood up an instance of Zigbee2Mqtt on a spare Raspberry PI 4 using the Dongle-E on the 12 foot USB extension. With this option, I placed the PI in my Attic, 3 floors above the HA server and began to migrate some devices from ZHA to Z2M on the Pi for testing. Serious issues were present right away with Z2M crashing during the interview process. At the time I dismissed that as a facet of the experimental EZSP support. It wasn’t until about 40 devices were moved over to Z2M when I started noticing Z2M crashing every few hours. The symptoms of this were quite obvious with Zigbee outlets momentarily cycling off and on at random times.
The next step in the process was to build a similar test bed using the Dongle-P with a second instance of Z2M on the Raspberry Pi using a different Zigbee channel. Another 50 devices of a similar mix of device type swere moved from ZHA to the Z2M instance using the Dongle-P, and another 10 to the Z2M instance using the Dongle-E. (By this point I was sick of re-pairing devices). The instance with the Dongle-P was rock solid, while the Z2M instance with the Dongle-E frequently crashed.
Herdsman logging was enabled and a console session was left running to capture any crash data. That did not take long. The logs were revealing.
zigbee2mqtt_ch12 | 2023-01-05T03:36:22.222Z zigbee-herdsman:adapter:ezsp:ezsp Close ezsp
zigbee2mqtt_ch12 | 2023-01-05T03:36:22.222Z zigbee-herdsman:adapter:ezsp:driv Close driver
zigbee2mqtt_ch12 | 2023-01-05T03:36:22.223Z zigbee-herdsman:adapter:ezsp:erro Reset error Error: Error while closing serialport 'Error: Port is not open'
zigbee2mqtt_ch12 | at SerialPort.<anonymous> (/app/node_modules/zigbee-herdsman/src/adapter/ezsp/driver/uart.ts:314:40)
zigbee2mqtt_ch12 | at SerialPort._error (/app/node_modules/@serialport/stream/dist/index.js:76:22)
zigbee2mqtt_ch12 | at /app/node_modules/@serialport/stream/dist/index.js:83:37
zigbee2mqtt_ch12 | at processTicksAndRejections (node:internal/process/task_queues:77:11)
zigbee2mqtt_ch12 | 2023-01-05T03:36:22.224Z zigbee-herdsman:adapter:ezsp:driv Pause 10sec before try 1
zigbee2mqtt_ch12 | 2023-01-05T03:36:22.225Z zigbee-herdsman:adapter:ezsp:ezsp Close ezsp
zigbee2mqtt_ch12 | 2023-01-05T03:36:22.225Z zigbee-herdsman:adapter:ezsp:driv Close driver
zigbee2mqtt_ch12 | 2023-01-05T03:36:22.226Z zigbee-herdsman:adapter:ezsp:erro Reset error Error: Error while closing serialport 'Error: Port is not open'
zigbee2mqtt_ch12 | at SerialPort.<anonymous> (/app/node_modules/zigbee-herdsman/src/adapter/ezsp/driver/uart.ts:314:40)
zigbee2mqtt_ch12 | at SerialPort._error (/app/node_modules/@serialport/stream/dist/index.js:76:22)
zigbee2mqtt_ch12 | at /app/node_modules/@serialport/stream/dist/index.js:83:37
zigbee2mqtt_ch12 | at processTicksAndRejections (node:internal/process/task_queues:77:11)
Following the burst of errors in the log Z2M would most of the time, automatically restart and reconnect to the dongle without any issue. On a couple occasions I had to restart the docker container to get Z2M to come back up. All the while, the Z2M instance with the Dongle-P was rock solid.
In conclusion I believe there is a flaw in the UART chip on the Dongle-E. I believe this was also the cause of the Dongle-E’s inability to reliably process the message traffic when used with ZHA, Those Concurrency Errors were essentially queued commands that Zigpy could not offload to the radio, so they were queued for future delivery. It’s quite possible that the dongle is just plain defective, but the stability of the device seemed to be inversely proportional to the number of devices on the network.
A second Dongle-P will be arriving today. It will replace the Dongle-E used on the Z2M instance. If that bring stability I’ll stay with the bifurcated Zigbee networks and move the remaining devices off of ZHA. It’s been a lot of work, but I am impressed with the stability and responsiveness of Z2M with the Dongle-P.
@srwhite my conclusion based on your symtoms would be different since no one else have the exact same symptoms as you in ZHA or Zigbee2MQTT.
That is, sorry that you are having a bad experince but I will not stop recommening this adapter due to your bad expence when I and so many others is not having a bad expeince with this adapter.
At least I still assume that the root cause cause of your unique problem must either be faulty hardware or currupt migration (e.i. 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).
So guess is either just currupt migration (meaning migration will never work for you) or faulty hardware (e.g. broken ZBDongle-E board, antenna, or perhaps even something else like buggy CPU or system RAM) or something unique to your configuration like bad device drivers if not using Home Assistant operating system.
Rwgardless your exact problem symtoms seems to be unique to you so far.
To be clear I wasn’t suggesting that you or anyone else stop recommending this adapter… I am saying that I will not recommend it based on my experience.
I apologize if I wasn’t clear, but when I set up a new instance of Z2M I formed a new network on a new channel… Nothing was migrated. Thats when I was finally able to capture the UART errors during the spontaneous reboots of Z2M… Again, all on a newly formed network. Nothing to do with the migration utility in that test case.
I also neglected to mention that I flashed the NVM erasure firmware before setting up Z2M, as part of the process of flashing the 6.10.3 community firmware. I’m certainly willing to consider a faulty device, but the inverse relationship of traffic to stability doesn’t make that assumption nearly as clear.
Also remember, my experience with this dongle on ZHA was with it connected to one of my Intel servers. The problem carried over to the Raspberry PI, so with all due respect, it’s not a systems hardware, RAM, or buggy CPU… I’ve tried a ton of test cases over the past week with different hardware and software. The problem has carried over to them all.
The conclusion can only be that either I have a bad ZBDongle-E, or the stick is crippled (at least for large systems) by a faulty serial interface.
I have had similar experience with the E as @srwhite . I can’t say the exact because I’m not so tech savvy as he is.
I have been using a Conbee2 stick with deConz for a couple of years. I wanted to upgrade and decided to go for the Dongle-E (latest and greatest I assumed). I was aware of the experimental flag still there, but I like to live on the edge a bit.
My Zigbee network is 74 devices, of which 47 are endpoint devices. I choose to go for Z2M because of the GUI OTA and for some weird reason I really like MQTT. The conbee 2 was connected to my Pi4, the Dongle-E I connected to my HP T620 which runs HASSIO. I installed the edge version of MQTT, which was an early build of 1.28 back then. Later on I updated to 1.29. Devices are connected with 3mtr USB extension cords. No migration, since I moved from deConz to Z2M.
While transferring devices I immediately noticed some devices wouldn’t connect to the network of the Dongle-E, even though the routers we’re already in place and those devices were working on the exact same place with the conbee2, this happened mostly with Aqara door sensors, but some multi sensors of Aqara too. After a while I started noticing it was impossible to join devices when a FW upgrade was being installed on any of the devices. I had a few devices which didn’t want to join the Dongle-E network and I needed to add them back to the conbee and try again. Only after this it was able to join them to the Dongle-E.
After a long time finally all my devices we’re connected. Now weirdness started to happen. I have 3 opple switches. They just disappeared from the network from time to time, sometimes only one, sometimes 2 and sometimes all three. The button’s just didn’t work anymore and when looking them up in the console, they weren’t there. Doing a rejoin gave a remove and rejoin message. After that 9/10 times it worked again, sometimes I had to repeat. Sometimes 75% of my devices were just offline. Nothing happened, just offline. Rebooting the Z2M addon most of the time solved this, but always every time after this reboot the opple switches we’re gone again. This was really annoying when I wasn’t home and just my wife or children were.
After a lot of trying and finger crossing, looking through logs and reading up on the internet, I decided to try the dongle-P. The joining of the devices worked like a charm, no issues at all. And it has been running a couple of days without any issues or weirdness. Even the Roller E1 of Aqara now works great.
So I won’t be recommending this device either. Hopefully a patch/ new FW will solve these issues in the future, but I’m now going to stick to the P. Just my 2 cents
I mean for me the issue was a non-issue actually, I did not set up the USB filters properly in Virtualbox, which means that after a reboot of the VM, the USB was not passed through. After reading up on Virtualbox a bit more, this seems like a pretty basic “problem” that can be easily fixed by knowing the environment a bit better. So in my case this was certainly a user-issue.
I’m convinced there is something amiss with the Dongle-E, or at least the one I have. The second Dongle-P arrived last night so I wiped out the Zigbee2MQTT instance last night and reformed a second network using it. The dongle was connected using the same USB cable, same USB port, to the same Raspberry PI. All of the same 50 devices were reset and reconnected. Not a single crash of Z2M, no failures in pairing any of the 50 devices, nor in 18 hours has any of them dropped off.
I’ve used a ton of Zigbee hubs & sticks over the past decade (Iris V1 & V2, SmartThings V2 & V3, Hubitat C3 C4 C7, HUSBZB-1, Sonoff WiFiBridge, 9888010100045, Dongle-E, Dongle-P, Conbee, XBee, plus a ETRX357 development board). The Dongle-E has been the only one in the group I couldn’t build a stable mesh on. Again, I’m willing to consider a defective stick, but I have neither the time nor desire to pursue this the matter any further. Its going back to Amazon.
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.
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.
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.
