ITead's "Sonoff Zigbee 3.0 USB Dongle Plus" (model "ZBDongle-P") based on Texas Instruments CC2652P +20dBm radio SoC/MCU

I’d suspect “something wrong with those drivers”. Even without assuming malice, you’re downloading random binaries that will run with complete privilege on your system from someone with an obscure satirical 1970s French superhero as an avatar and no other meaningful identifying information.

It’s probably not mining bitcoin, but… it also might just plain not be right.

it’s fair - I’ve removed the QPKG

I’ll plug the stick in now - how do I get the driver in Linux without my QPKG helping me :slight_smile:

the TTYUSB0 is showing up - I guess the drivers are still there until it next updates


stty -a -F /dev/zigbee

I get “stty: command not found”

on lsusb - I get:

Bus 001 Device 002: ID 10c4:ea60 Cygnal Integrated Products, Inc. CP210x Composite Device

When I try to add the ZHA integration - I get “Failed to connect” as an error in the GUI


I tried to setup a VM - which is irritating, as it should work fine as a container - when I did, I shutdown the old container - logged in etc

tried to connect to pass through the USB device to the VM (and double checked the Container was stopped) and got the following error:

“Warning - This USB device is being used by another VM. (1201)”

This sounds promising. You might not need driver because you could see something with lsusb already. Cygnal and CP210x sounds familiar to me with this USB stick.

I suppose the next step being you introduce that USB dongle from your qnap box into your conatiner.

I do VM, so not much help here… Am passing through USB devices into VM… GUI makes this relatively easy under Virtualization Station.
But I’m sure other users here could help.

So I couldn’t see the device until I installed the QPKG

so I do need to do the driver properly i think

the VM method was very painless to setup and I like that you can do the back-ups etc - so I might stick with that now

I just need to figure out what else is taking the USB dongle!

I suspect “stopping the container” is not enough, but I don’t know - not enough specifics.

My impression on QNAP’s implantation of Container Station is that they’re with good intent but limited and incomplete, (FWIW dockers in Synology is no better), and QNAP’s Virtualization Station implementation is much better. My experience is pretty painless - no restart nor reboot anywhere; no driver for either QNAP or HAOS

That said, this is where you should consult QNAP forum or tech support instead, on how other QNAP users handles USBs under container / VM.

Well the long boot time thing hasn’t gone away, (maybe next time!) but i was able to get it all going again after much patience

booted the VM (very easy) - then stuck the stick in - this time no crashes and passed through to VM and worked first time!

Can this be run alongside a HUE hub and share the HUE equipment’s mesh or do you need to remove the HUE hub from your system to get HUE kit to join on here? (dealbreaker for me as the wife and kids use the Hue and Homekit apps…but would be useful to use the Hue bulbs, switches, PIRs etc as repeaters…)


A Zigbee devices can only be connected to 1 Zigbee coordinator. So either your Hue hub or the Zigbee dongle, not both.

1 Like

@francisp Thanks for clarifying that. I was kind of hoping there would be a way around it, but I guess I will have to keep my HUE separate from the my other ZigBee. Thanks!

If your NAS has an x86-64 (Intel x86 compatible 64-bit CPU) processor and it features a virtualization hypervisor that supports running VMs (virtual machines) then I highly recommend running Home Assistant under a VM (virtual machine) instead of under Docker directly in the NAS operating-system.

If you do that then you do not need to install any device drivers under the NAS operating-system as instead you only enable pass-through for that USB-port to the VM in the virtual machine management administrator software. You then install either the Home Assistant OS (HAOS/HASSIO) distro for x86-64 or any other Linux OS distrobution for x86-64 in that virtual machines, after that you can install the needed device drivers in that operating system running on the virtual machine, (instead of having to install custom device drivers directly under a native NAS operating system).

For example, newer x86-64 based QNAP and Synology NAS:es has their own official VM virtualization:

PS: It is generally recommended to install a dedicated VM with only Home Assistant Operating System:

As mentions, any Zigbee device can only be connected to a single Zigbee Coordinator, so devices can never be connected to two Zigbee Coordinators (adapters/hubs/bridges/gateways) at the same time.

You might however be able to achieve some of what you want by combining different integrations, but not all as the official Philips Hue App only support connecting to the official Philips Hue Bridge so the compromise would have to be to not use the Philips Hue App for all other devices). Check out:

Huge thread, but I wish it were easier to find information. I’ve heard that the original firmware is stuck at 5dB of gain. So I flashed to 20211217 but do I get +20dB gain automatically? or is there a setting somewhere?

nevermind, found the setting here:


FYI, the newer firmware will set the transmission power to +9dBm by default, however, with that newer firmware you can configure transmission power up to +20dBm via ZHA/Zigbee2MQTT software config / settings, but you could consider before doing so as could get a worse result because it will only make the Zigbee Coordinator “shout louder”, not “listen better”, so reply signals from some devices with weaker radios might not be strong enough to send a clear signal back to the Zigbee Coordinator.

1 Like

I got my Sonoff Dongle last week, installed the latest firmware on it and honestly, I am really disappointed with the range of Zigbee. I have changed the wifi settings to free the channel, but with my smoke detector I do not get more then 120 LQI and with 2 meters away I am at around 40 LQI with ZHA. Tested Zigbee2MQTT and it looked better, but want to use ZHA because fo the better integration.

How and where is the transmission power configured with ZHA ?


Also, know that all Zigbee devices and especially Zigbee Coordinator adapters are known to be very susceptible to Radio Frequency Interference (RFI) / Electromagnetic interference (EMI) / Electromagnetic Fields (EMF) caused by different signal interfering sources, so all the tips to try to reduce interference are extremely important to follow even if they may sound silly.

It is really standard with any Zigbee Coordinator adapter today to need to follow all the best practice tips and tricks posted in PR as well as those here to workaround all different sources of signal interference.

Short summary:

  1. Upgrade to the latest firmware on the Zigbee Coordinator adapter (whichever adapter you have).
  2. Connect the Zigbee Coordinator adapter to a longer USB extension cable to get it a bit way, if possible use a very long and preferably thicker double or triple-shielded USB extension cable.
  3. Be sure that Zigbee Coordinator adapter is connected to USB 2.0 port (or via USB 2.0 hub).
  4. Shield any computers and USB 3.0 peripherals like hard drives by making sure to only use metal enclosures/chassis/chasings that have are properly grounded and/or electronically shielded.
  5. Make sure Zigbee Coordinator adapter and devices is not close to WiFi router or access-points.
  6. Zigbee devices do not have long-range (or good radio signal penetration) on their own so begin by successively adding more mains-powered Zigbee Router devices (a.k.a. Zigbee signal-repeaters/range-extenders) closer to the Zigbee Coordinator adapter and then in each room building outwards to form a stable Zigbee network mesh before adding devices further way.
  7. Afting adding mains-powered Zigbee Router devices pair all the other devices where you plan to have them permanently installed and do not move them around afterwards.
  8. If still have issues change Wi-Fi channel(s) on your WiFi router or access-points to do not conflict with Zigbee → ZigBee and Wi-Fi Coexistence | MetaGeek

Even shorter summery; just assume that all Zigbee adapters are extremely susceptible to interference!

PS: Appreciate if thumbs up this PR → Update zha.markdown with tips on improving Zigbee network range by Hedda · Pull Request #18864 · home-assistant/ · GitHub

1 Like

All of @Hedda’s advice is valid and should be taken to heart, but I would say don’t worry too much about the reported LQI unless you’re having real world, day to day operational issues.

120-130 seems to be about as good as it gets with the Sonoff. I personally believe their is something off in the way the firmware calculates the number. I’m not sure it matters as long as it is internally consistent.

I had great reported LQIs , well over 200+, with my fully updated Nortek sticks(SI Labs based). I also had weekly, if not daily issues. The Sonoffs have been 100% stable and operational for the past 60 days or so since I swapped my sticks out. Not a single (noticed) dropped event or device with the Sonoffs, I can’t say either for the Norteks.

All this is anecdotal of course, I would be curious for a comparison of cc2652 sticks to see if the LQI numbers are a hardware or firmware issue.

As to the ZHA vs Z2M issue, grab another stick and run both side by side for a while. I started with ZHA and was happy, but recently got a second stick to test Z2M with a device ZHA didn’t support. Somewhat surprisingly, I found I liked Z2M better. Pros and cons to both, but I had a couple devices that I had had to poke and google around to figure out appropriate zha service calls for device configuration options in ZHA, but in Z2M the configuration options were exposed as easy to set entities.

The Sonoff sticks aren’t very expensive, and once you’re sure between ZHA and Z2M, the extra stick can be repurposed as a router. Personally, I recently moved the last of my devices to Z2M, but will keep ZHA installed and active to test any future devices with, and to keep track of the inevitable changes and improvements. I’d be completely open to switch back if it makes since.


LQI numbers are a pure matematical value generated by the stick. It is not showing any actual link quality, just a representation of the signalstrength time something, hence the number is not comparable between coordinators. I have a similar story as jerrm. Early I was running a small conbeeII network with a few sensors and no mains. All devices was having 255 in LQI, however frequently missed actions like door open etc. After including a number of mains I got lower LQI, however solid and stable mesh (except for the know problem with conbee when changing a lot of devices at once, some misses). So, LQI numbers do not really tell anything, at least that is my conclusion.

Lately I have created a new zigbee mesh using a Sonoff 3.0 dongle and Zigbee2Mqtt. Like jerrm I created it for the fun and test, however I like the Zigbee2Mqtt implementation better. Yesterday I move the last few devices, so my ZHA network is empty.
My Sonoff network shows LQI in the range from 10-130, however being rock solid and faster than ZHA based on conbeeII (LQI, in range from 150-255).


Also know that LQI is not a universal standard with a unified scale. So different Zigbee stacks, different manufacturers, and even different Zigbee devices and firmware versions calculate LQI differently. See:


Hi Hedda, Fully agree, it was actually my point, you can NOT compare. Have to admit, re-reading my own post, it could be misunderstood. :slight_smile: