So ~ 100 to 130 bulbs per setup/channel doesn’t give you the twiches? 
1 Like
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.
2 Likes
All makes sense, @NathanCu!
Regarding this:
Is there a coordinator you recommend? And remember that 100% of my system is always-on bulbs.
Yep, totally. Something I considered when building the house but I’m sorta obsessed with color temp so I went with bulbs.
Look at the recommendations on the Z2M page. I think @Hedda has a recommendation on the site somewhere but I can’t remember where off top of my head.
1 Like
Hi, @Hedda! Looking through the docs: Getting started | Zigbee2MQTT and supported coordinators: Supported Adapters | Zigbee2MQTT and I’m not seeing where one supports 64 direct vs 32. Do you have a “best of the best” that supports 64 that you’d recommend?
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.
Thanks so much! Just picked up a few UZG-01s. Can’t wait to get my Zigbee network working as it should!!
I can personally the Sonoff ZBDongle-P from ITead (basd on TI CC2652P) with updated firmware for Zigbee2MQTT
But do follow all the tips
2 Likes
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
1 Like
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.
1 Like
If using haos, you get two “easy” z2m instances using the standard and edge addons.
Adding more z2m addons isn’t difficult using a little git magic. I’m at three instances under haos currently.
1 Like
Which Mosquitto docker is recommended? I’m using HA in docker and so the suggestion add-on won’t do.
Nevermind! Found the standalone docker container: Docker
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.
Check out this comparison table -
(source https://smlight.tech/ (mid of the page).
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.
3 Likes
In another group someone advised me to add a router, I have added and that sensor started to work with my P7 too)