From my experience using both Zigbee2MQTT and ZHA, as well as too many other zigbee systems, the best setup to work with Home Assistant is to run Zigbee2MQTT in a separate docker container from Home Assistant, as well as a MQTT broker in a docker container separate from Home Assistant. This allows you to upgrade/modify your Home Assistant setup without your Zigbee and MQTT systems going up and down. Additionally, Zigbee2MQTT is clearly the leader in devices, support and community.
The tight coupling of ZHA and Home Assistant should be a plus, however from my experience as stated above, it is not. It’s kind of like a good bicycle manufacture that also has an aircraft division, and a pretty small overall staff
Using Zigbee’s direct connection between devices can be a positive from both a speed and reliability stand point. However, for most setups (especially as I described above, solid and isolated docker based Zigbee2MQTT and MQTT broker) adding these direct connections often adds a new level of spaghetti to our already often big bowl of spaghetti home automation setups. You may find yourself scratching your head for long periods asking ‘how did that turn on?’
After reading all this, it sounds like my 368 device (all bulbs and light strip controllers) wound best setup with a multiple Zigbee2MQTT setup, all communicating back to a single MQTT broker that works with my single HA setup. Does this sound right, @dproffer?
I have my 2.4GHz wifi system setup to use only channel 1 and 6, meaning Zigbee should be in the clear with 21, 22, 23, 24, 25, and 26. That means I could, theoretically, have 6 separate Zigbee networks running, meaning 55 to 65 bulbs per network. That sounds a hell of a lot more manageable from a size perspective.
Let’s say my thinking is right and I do this. This means, what? I need:
6x: Pi (with Zigbee2MQTT docker container) + SkyConnect
Nope. Not at all. It is three very densely routed networks (dense networks perform well.) I run networks with 100 devices in both zigbee and ZWave all the time. (and why I included the math on how I got to the numbers I did) especially if you pick one of the better coordinators that support 64 direct connect nodes on the first hop. Each can then have uo to four children. So 64 direct connect nodes + 64 x 4 (basically 64 x 5) is 320 - its i range of your number but stresses they standard so cut it i half and you can do it in two. (but three is better)
If you use a coordinator that supports 32 then it’s 160, you NEED two to get to 320, and a third would give you 1/3 excess capacity on each of the three networks.
The problem with cutting it up TOO Much is then you start diluting the density and risk poor mesh. (yes it’s a balance game)
Either way you don’t need 6.
Pick good well behaved devices and plan your networks carefully. You’re playing a balance
Off-topic tip; consider looking into smart switches and smart dimmers (or smart switch modules / smart dimmer modules that convert dumb switches into smart switches) as an alternative to smart lightbulbs.
As long as you only need dimming and not RGB then I personally think that smart dimmers and smart dimmer modules connected to multiple dumb lightbulbs are a much better option than have multiple smart lightbulbs. I myself have multiple recessed cealing spotlights in every room controlled by a single smart dimmer module in each room that has converted the existing dumb wall switch into a smart switch, and the only major change I had to do is to replace all the spotlights with better quality dimmable LED MR10 or GU10 dumb lights models (Philips Hue Warm Glow series), which is not only cost less but also made for a less complexed setup and network. Overall I control beween 4 to 16 spotlights with each smart dimmer module (using that same type of solution in 10 rooms so believe we there have over 80 dumb spotlights that is control via only 10 smart dimmer switches).
PS: I too have a mix of Zigbee and Z-Wave devices that togther total almost 300, (as well a quire a few more devices using other protocols), but I have not yet reached 200 of a single protocol, and I am hoping newer radio adapters that can handle more devices will become before I do.
For z2m, the general consensus is to use a TI cc2652p zstack based coordinator.
Z2M was developed around the TI zstack family, and the z2m dev Koenkk also maintains the community firmware used on virtually all cc2652p sticks. I suspect the zstack chip family will always be first among peers for z2m.
I currently use the Sonoff ZBDongle-P at multiple locations with good results. Some say there are QC issues with the ZBDongle-P, but I have to wonder if reports are simply amplified by the number of Sonoff sticks in the wild. I don’t really know, but I wouldn’t be surprised if there are more ZBDongle-P sticks around than all other cc2652p sticks combined. I’d wager substantially more.
If buying today I would probably future proof a little (and support a more community based company) by looking at the TubesZB or Zigstar UZG-01 cc2652p7 based coordinator. The P7 has about twice the ram and flash of the cc2652p2 used in most other sticks. I’m not really sure the firmware fully exploits the additional ram yet, but it is there for the future. The makers are also active in the forums.
SkyConnect, Sonoff’s ZBDongle-E, and the Conbee III are based on SI Labs EFR32 chip. The EZSP firmware for the chip support in z2m is still technically considered “experimental” at this point. Many use it and report good results, but proper backup/restore functionality is still missing.
IMO, the biggest advantage of the EFR32 is it supports the multiprotocol addon and can be shared with Thread.
As always in tech, there are next gen chips announced from both TI and SI Labs, but I don’t think anything on the market yet.
I think you are going down the best path. If you are not up to speed with docker, I would spend a little time setting up some test containers. I use Portainer as GUI to docker with good success. Get solid on how USB devices pass thru to docker from host. I use the by serial mapping so it does change on usb changes, example below. Python TIO serial program is good tool to install on docker host : ‘tio -L’ does nice job of showing USB names. Also network port mapping in docker containers, for your connection to MQTT broker.
I would start with two Zigbee2MQTT docker containers and a Mosquitto MQTT container. I decide how you are going to partition your devices to the different zigbee2mqtt instances and do a first pass with ‘partition one’ of devices to the first zigbee2mqtt, don’t rush, reset and add small groups of devices to this first instance and see how things perform. I would use the second zigbee2mqtt as your permanent test zigbee network. As you ramp up, use this network to test odd device and interactions without futzing with one of your production networks. FYI, your first pass at your partitioning, may not work the way you want as you get into it, so be prepared to backout and do a revision 2 and 3… that’s why are important tools to have in your quiver as you go down this adventure. Make sure to remember that each of your zigbee2mqtt instances need a unique MQTT base topic from the others. that is in the zigbee2mqtt configuration.yaml file.
Naming of your devices is an important topic. I stick with the raw MAC addresses for my devices, it works, but not ideal. If you do go down the custom name path, spend some time thinking this thru . I don’t like spaces and fancy characters in my MQTT topic names. Make sure to write down your naming rules, as it is easy to forget down the road, and I think useful to be very consistent with name patterns. For example using ‘01, 02, 03…10, 11’ in names rather than 1,2,3…10, 11.
I’ve been successful with the TubeZB Ti chip set based devices, I did not use the ethernet connected option of these devices, but it seems a useful option to try. However don’t over spend.
Good hunting!
user@docker-01:~$ user@docker-01:~$ tio -L
/dev/serial/by-id/usb-ITead_Sonoff_Zigbee_3.0_USB_Dongle_Plus_5cf90e3b6229ec119a9a6d7840c9ce8d-if00-port0
/dev/serial/by-id/usb-1a86_USB_Serial-if00-port0
/dev/serial/by-id/usb-1a86_TubesZB_971207DO-if00-port0
Make sure to document the MAC address and that some unique part of it is easy to identify in your USB device name for the coordinator. You do not want to get your coordinator dongles mixed up between zigbee2mqtt instances. That will make for a real mess.
Zigbee firmware for CC2652P7 chips does not utilize +20dB amplification, only +5dB. So they are technically (so far) even worse than CC2652P2 chips that utilize +20dB amplification on the firmware level.
If you spend extra money for nothing, it’s good to go with CC2652P7.
Moreover, as an owner of both versions, CC2652P and CC2652P7, I had some tests. And, for example, Aqara temp and humidity sensor WSDCGQ11LM works well with the CC2652P coordinator but does not work AT ALL with CC2652P7 - e.g., I cannot connect it. I have 5 of them in my setup, and they do not connect. So it looks like it is too early to say that the P7 chip is the one for recommendation at all, considering both facts above.
Also, I see an available device based on Zigbee chip CC2674P10 (SLZB-06p10 device), but the story is the same - kinda overmarketed - read that information by my link above.
