thank you - sounds like an excellent diagnostic next step - will give it a try… later
had to hard power off NAS as it had totally hung - I thought maybe it was stuck after trying to reboot it once - so held powere button again - this time I’m giving it ‘as long as it wants’ and will leave it overnight.
I can here the drives rumbling away on and off - so it’s ‘alive’ but LCD screen still says ‘Booting’ and it wont respond to pings 
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 
the TTYUSB0 is showing up - I guess the drivers are still there until it next updates
on
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
Hmmmmmmmmm
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…)
Thanks
A Zigbee devices can only be connected to 1 Zigbee coordinator. So either your Hue hub or the Zigbee dongle, not both.
@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:
https://www.qnap.com/en/software/virtualization-station
https://www.synology.com/en-global/dsm/feature/virtual_machine_manager
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:
https://www.home-assistant.io/integrations/homekit/
https://www.home-assistant.io/integrations/homekit_controller/
https://www.home-assistant.io/integrations/hue/
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:
https://www.zigbee2mqtt.io/guide/configuration/adapter-settings.html
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.
Hi,
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 ?
Thanks
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 https://github.com/home-assistant/home-assistant.io/pull/18864 as well as those here https://www.home-assistant.io/integrations/zha#best-practices-to-avoid-pairingconnection-difficulties to workaround all different sources of signal interference.
Short summary:
Even shorter summery; just assume that all Zigbee adapters are extremely susceptible to interference!
PS: Appreciate if thumbs up this PR → Update ZHA documentation with tips on improving Zigbee network range by Hedda · Pull Request #18864 · home-assistant/home-assistant.io · GitHub
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: