In theory. I’m gonna let this project go until after Christmas. The 988 is back in service and the mesh has settled down such that I hardly even see any concurrency messages in the logs now. All of the versions are variants of 6.10.3 with the 988 running the official iTead release. I tried iTeads official 6.10.3 firmware that shipped on the stick plus grobasozs’ 6.10.3 build.
I think the transmit power (-20dB) could actually be overpowering and causing interference to the network. I do not believe it’s possible to adjust the power in the config.
I have another theory that the high gain antenna on the E might be picking up interference through the antenna itself. The 988 dongle just has a negative gain trace antenna that should be considerably more “deaf” than the E. I may try another swap after Christmas is over.
FYI, the 9888010100045 board hardware has no electromagnetic shielding (plus it is said by many in the community to have a poorly designed circuit board antenna) and it has become infamously known for being extremely sensitive to electromagnetic interference (a.k.a. EMF/EMI/RMI), especially on the receiving side. So far that many people want to lengths to try to add at least some basic DIY electromagnetic shielding to the board by wrapping everything on the 9888010100045 board (with the exception of the circuit board antenna) in first a layer of Kapton-tape (which is not conductive) and then on top of that a layer of conductive copper-tape or other conductive metallic-tape which is grounded to the USB plug to prevent EMF/EMI/RMI to affect the sensitive components on the board directly.
Regardless of which Zigbee Coordinator USB adapter you use be sure to read and follow the best practice tips in regard to avoiding sources of EMF/EMI/RMI by getting the Zigbee Coordinator USB adapter as far as possible away from all electronic devices/appliances/cables/wires/antennas, etc. by for starters using it via a longer shielded USB extension cable (tip is that thicker cables ussually are better shielded) connected to a USB 2.0 port or USB 2.0 hub (and absolutely not to a USB 3.0 port as USB 3.0 ports and USB 3.0 devices are infamously known for being a serious source of EMF/EMI/RMI that will very strongly affect all low-energy digital radios that uses 2.4GHz frequency band like Zigbee, Thread, and Bluetooth. See:
I took a quick look at the source code and didn’t spot anything to configure that but I will dive into that more after the holidays.
Mine is wrapped in kaptan tape covered with a layer of aluminum foil tape. The trace antenna is not covered, of course. Those type of antennas operate with negative gain meaning instead of amplifying power it’s attenuated. I don’t see anything in the trace antenna design that would cause it to pick up any more interference. I think that device is victim of poor shielding over its own components and thats where the noise is getting in. The Dongle-E with its external high gain antenna is more susceptible to receiving interference thats the 988 would be. It’s called front-end overload, and it’s essentially out-of-band RF (i.e. EMI) that raises the entire noise floor such that the receiver cannot discriminate the noise from the actual signal. I don’t see anything in terms of band-pass filtering on the 988, so that could be why this is happening, but looking at photos of the DongleE PCB I have a similar opinion on it as well.
As mentioned in an earlier post, I kept the both Zigbee sticks in the same location, connected by the 12 foot shielded USB cable to a USB2 port. I also installed a ferrite choke on each end to reduce any radiated interference picked up by the USB cable.
That said, 6 days of using the Dongle-E I could not stabilize the network after the transition. About 32 hours after going back to the 988 the mesh is stable and concurrency errors are gone.
I think the concurrency errors are a major clue. The E simply couldn’t process messages as fast as the 988… But I have no idea why. Thats the weird part of all this.
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.
