No one is arguing that there aren’t uses for all of these technologies. But all of these technologies come at a price (added complexity). I’d be interested to hear how you’re monitoring all of your BLE devices around the house? Yet another server installed nearby reporting back to HA?
As for Sidewalk, I’ve turned it off, I’d rather not trust Amazon to manage who has access to my wireless network. Doesn’t mean there isn’t a use for it. But you’re trading security for convenience.
I’m using an esp32 flashed with OpenMQTTGateway to monitor my Xiaomi LYWSD03MMC Temp & Humidity sensors. And I prefer Zigbee over Zwave. With over 100 Wifi devices and 40 Zigbee devices in the house, can’t say I have drop-offs.
You are correct, there is another dimension that has to be factored in… move to a single server/hub or have multiple server/sub-server and hubs.
To my joke and reality ‘Life sucks and then we die.’
Yes, I struggled with bluetooth low energy for a month. Bottom line, it’s implementation on Linux SUCKS!!! I have a solution that seems to run for multiple months (hoping for years, which is what I expect from Unix/Linux) as a raspberry pi/linux collector ‘hub’, but was it hard, yes. But have a found a better sensor end device than the BLE units, NO. So in balance… are they Linux python solutions, yes, are there ESP32 solutions yes. But I can tell you, based on experience, Wifi and Zigbee temperature / humidity solutions SUCK SUCK!!! So I have a bluetooth with a raspberry pi in my mix, will it play out as a long term solution, TBD. But it filled a price/performance/quality gap that I was unable to fill with any other tech mentioned, so it was add it to my toolbox. Growing…
Sidewalk, I am not going to debate, yes a whole corporate / privacy issue. But, you did not mention LoRa, which seems to be a positive ‘pretty open’ technology that addressed the use cases I mentioned. Of which, bluetooth, wifi, zigbee, zwave (maybe??) cannot address. And if Amazon increases the universe of hardware for LoRo, by pushing their own proprietary software on top of the same hardware I can use for LoRa, should I complain?
Okay we can open the whole LTE, 4G, 5G can of SPAM now too 
Life sucks and then back to work integrating
@netregha] You do not need to flash Zigbee devices other that updating firmware on them if available.
Suggest that you try out ZHA first and if it does not fit your needs then try out Zigbee2MQTT later. This as ZHA is super easy to get started with but it is not stand-alone so not as flexible as Zigbee2MQTT.
I do however not recommend starting out with Tuya and Xiaomi/Aqara devices as they do not quite follow the standard Zigbee specifications and as such can be less stable than Zigbee devices from example IKEA and Sonoff.
Also research before buying a Zigbee coordinator, as some are compatible with more integration software than others and some are more powerful, regardless make it a USB dongle and not a bridge:
Recommend read advice on Zigbee range extending as well as it uses network mesh technology:
No. But choose your coordinator hardware wisely.
No. But take a look the the supported devices before you buy.
Curious why you recommend a USB dongle over a bridge solution. Other than the pain to flash the Sonoff Zigbee bridge with Tasmota, in my testing I have found it to work pretty well with ZHA. Silicon Labs, the maker of the zigbee module in the Sonoff bridge seem to be leading in terms of function and market share. Getting a good USB stick with the Silicon Labs hardware would solve the Tasmota flashing step and perhaps better communication between the zigbee processor and host software. But so far, the wifi serial connection between my HA server and the Sonoff bridge is working well. The added benefit of this model is that it allows you to place the Sonoff Zigbee bridge in a location where you can optimize coverage of the coordinator module. And to that point, if you do go down the USB dongle route, I think using a USB extension cable to get the zigbee device away from noise generated by you host computer is a must. I sense a number of folks have had an unsuccessful start to their zigbee experience because they USB dongle was plugged directly into a noisy host computer. Especially, a host with USB 3.0, as someone the forums recently experienced.
On your point about noncompliant devices and the frustration this can cause, I completely agree. Unfortunately, based on my experience and reading some others, I think the problem is far greater than Tuya and Xiaomi/Aqara, though they may be some of the worst. However for example in my own testing, two items I have found, and believe there are more:
Ikea switch will not stay online (and visible, this is the key part, it totally disappears from network, and will not comeback without a re-add) when connected via LEDVANCE wall socket module. Ikea switch works fine when connected directly to coordinator.
Sonoff SNZB-02 EwElink temperature and humidity module, when added via a CentraLight RZHAC appliance plug, reports temperature, humidity and battery levels fine. But as far as the ZHA coordinator is concerned, the SNZB-02 has no network links paired with ANY device on the network, it floats out there in isolation in the network diagram. But as I said, has been reporting data just fine since day one.
Zigbee is a very useful technology for home automation, but even with it’s long history(in tech years) it still suffers from ‘walled garden’ syndrome (aka Hue devices with Hue hub, Ikea devices with Ikea hub, Aqara devices with Aqara hub, work better and grudgingly, at best, support adding other vendor devices to the garden). And even though it was offered as an open standard, it seems there are far more cases of ‘this device will not connect with that device’, than say bluetooth or wifi. Not to say those don’t have same issues, just IMHO, zigbee comes in third in this race.
I now see you post on this new dongle, interesting. Other than the flash, I still think there are pluses and minuses for both bridge and dongle. An ethernet connected bridge would be another interesting option, and I see some folks are working this. To the bridge connection options, based on my ownership the following info, in my LAN both wired and wireless bridges have worked fine:
Phillips Hub - ethernet connected but has wifi option that I think was never turned on (which is interesting)
Aqara Hub - wireless only
Ikea Hub - ethernet only
Samsung hub - both ethernet and wifi option (perhaps it is not fair 2 call this device a ‘hub’ but rather a host with direct connect zigbee coordnator processor)
Lutron hub - ethernet (but totally different wireless frequencies for devices)
I run around 60 IKEA bulbs, 8;remotes and 4 IKEA motion sensors. All are reliable and after 2 years I’m only just changing batteries in some of the remotes.
Just created a setup from scratch, using Raspee II and Zigbee2mqtt. Currently 41 devices of various brands (IKEA, Innr, Osram, Philips).
The mesh took about 1-2 days to optimize routing, since then it‘s running flawlessly.
My one take away w/ zigbee is its worth it to start out with a strong coordinator adaptor and not the CC2531. See Supported adapters | zigbee2mqtt.io. I got the one from Slaesh and its great!
The main reason is that especially the EmberZNet serial protocol that Silicon Labs based products uses does not do a good job at handling the loss of serial packages (serial communication faults) which could be caused by WiFi interference if network packages are lost or if WiFi goes down.
bellows library for zigpy which ZHA uses has posted this warning about using Zigbee to WiFi bridges.
https://github.com/zigpy/bellows#warning-about-zigbee-to-wifi-bridges
Warning about Zigbee to WiFi bridges
zigpy requires a robust connection between the zigpy radio library and the serial port of the Zigbee radio. With solutions such as ITEAD Sonoff ZBBridge or a Ser2Net serial proxy connection over a WiFi network it is expected to see NCP entered failed state. Requesting APP controller restart in the logs. This is a normal part of the operation and indicates there was a drop in communication which caused packet loss to occurred between the zigpy radio library and the Zigbee radio. The use of serial network proxies/bridges/servers over WiFi is therefore not recommended when wanting a stable Zigbee environment with zigpy.
I would advise against using internal GPIO/HAT adapters like the Raspbee or Elelabs Zigbee Shield because the risk of interferance from being so close to the board, and especially if if you also plan on using WiFi and/or Bluetooth on that same board as those operate on the same frequencies.
One of the more commonly asked questions about using Zigbee with Home Assistant are regarding to improving or extending signal reception/transmission or resolving problems with poor link quality, thus here are gathered a few possible options to resolve most problems related to range extension.
The fact is that bad signal reception can be due to many different things and experienced Zigbee users in the community will normally advise that there are a few simple fundamental things that you should really attemt to do first in order to better optimize your Zigbee devices equipment which can resolve many basic problems related to signal strength or interferance issues. Note that there are always exceptions, however, if possible to try follow at least some of these general recommendations before you take more advanced steps like reporting issues to developers and submitting debug logs.
Just following these simple tips below should help improve signal strength and reduce signal interference which can normally many problems with a Zigbee network.
If you want an adapter with stronger RF radio and are willing to wait then a tip is that several people are currently working on designing new Zigbee adapters with integrated + 20 dBm Power Amplifiers using latest SoC chips from both Silicon Labs (EFR32MG21) and Texas Instruments (CC2652P or CC1352P). You should expect to see many different such new adapters released before this summer if not sooner.
True. But for that reason on that Raspberry Pi Bluetooth and Wifi are disabled by appropriate entries in /boot/config.txt
Much better though would be if all future versions of internal GPIO/HAT adapters like the RaspBee or Elelabs Zigbee Shield would come with an uFL/I-PEX-connector to allow the use of external antenna instead (external 2.4GHz antenna via example an IPEX/uFL-connector to SMA-connector converter).
Example Zigbee PiHAT which does have a Power Amplifier but is based on the older CC2538 MCU:
I also believe Electrolama is working on a zoe2 version of zoe with CC1352P and IPEX/uFL-connector
Already have slae.sh’s CC2652R stick on my desk, but changing the coordinatore requires re-pairing of all devices. Something I don’t want to do without need.
FYI, a zigpy developers is looking into a possible universal backup and restore solution for that here:
Getting back to the OP…
I just installed a cheap Chinese no-name-brand Zigbee smart plug in a shed about 10 meters from the house, and probably 12 meters from the nearest other Zigbee smart plug, through a few walls.
It connected immediately. By the time I got to checking the mesh using the ZHA visualization, it had established a good connection to both the nearest other plug, AND the HUSBZB USB stick on my Raspberry Pi, buried in the center of the house behind a few more walls.
For me, this Zigbee stuff has been dead simple to install, configure and use. My WiFi components demand a lot more attention. Even though I love tinkering, I keep reminding myself that my HA is a “production” system, not a toy. I rely on it to monitor my house when I’m away. So many very expensive things could go wrong that reliability is at least as important as having fun. I’m reading all the negative experiences and will watch for problems, but so far I’ve been pleasantly surprised by how well Zigbee has worked for me.
Thank you all for the advice, really interesting reading. I’m gonna try a small sonoff zigbee setup and see how it goes 
This is as good a place as any to report the results of my first testing with a Sonoff Zigbee mini smart switch, model MINIZB.
I wired in a new switch box for a flood light I’ve always wanted to install on the far side of the barn. There’s no good place for a manual light switch, so I thought this would be a great test. I already have one of my cheap-o no-name smart plugs nearby, so this should only strengthen the mesh.
The MINIZB is a tiny form factor, easy to tuck into a light switch box. I wired it up, turned the breaker back on and mashed the button in ZHA to detect new devices. It popped up in a few seconds, did the “interview” and moments later I was able to give it a name and start using it.
This stuff is just dead simple. I’ve now got 15 devices from 7 different manufacturers, all talking happily together on a mesh that’s been rock-solid reliable. All with zero configuration, beyond giving each device a name as they were added, and customizing the entity icons where I wanted something other than the default.
I know. I’m starting to sound like a real Zigbee fan boy. I’m starting to feel like one too. And to make things worse, I’ll put in a plug for these Sonoff MINIZBs. In addition to the regular smart switch functionality, they also have two terminals for a manual switch. So while I was wiring up the mains power, I connected those switch terminals to a regular wall switch using some old speaker wire I had lying around. Now it looks and acts just like a “regular” wall switch, but also allows HA control. And if that’s not enough, you could wire one of these up to a pair of three-way switches, even if the switch loops have no neutral.