You can only run one system per coordinator, but you can run multiple coordinators.
It is entirely possible to have deconz, zha, and multiple z2m instances all on one haos install. I personally run ZHA and two z2m instances on my HA.
In your case, since you already have a SkyConnect, just plug it in, let it autodetect(unless you got one out of the bad batch), then go to settings->devices & services and set up ZHA to play with. It won’t conflict with the Conbee, but I would make sure it is on a different channel.
Then later on you can disable ZHA and load up the z2m addon to test with.
For you I’d probably be strategically putting a pi running Z2M in a few strategic locations and hang a coordinator off it the use MQTT to connect back to HA.
The limitations on multiple copies of an addon only apply for actual addons, not things connecting through MQTT. If you’re running Z2M remotely connected through MQTT I don’t think there’s actually a limit. So you could run two like that easily as long as each had its own coordinator. Yes that means two networks so plan the channels to not overlap. Use a channel for each that’s relatively close to each other but not overlapping and engineer your Wifi space to cut a hole around them both
As people already mentioned - if you want it all on your HA box then you can mix software like Deconz/Z2M or ZHA/Z2M or ZHA/Deconz.
The trick would be if you’re using groups you won’t be able to group on separate networks so plan carefully to avoid splitting your groups across coverage areas.
Yes thousands of devices are technically doable but most coordinatorsbhave a direct connect limit between 32-64 nodes and most vendors only handle 4-6 nodes per routing device and max 4 hops. So… Realistic top end is something like 32 x 4 x 4 (512) but you’re doing a LOT of hopping around the network to make that work.
Cut hops in half and you’re in the 256 node territory but you’ll still stress the direct connection number.
Cut hops again to target no more than two hops from the coordinator and you’re at 128 per network. (which covers you in two networks) double that of your coordinator is verified to work with 64 direct nodes. (most aren’t)
Also NEVER max out a spec. Those are for marketing people. Engineering - cut it by half immediately.
And for how long anything takes. The Commander Montgomery Scott principle applies. Don’t ever tell the Captain how long it takes. Double it and double it again.
You guys have to difference Zigbee 3.0 devices with older Zigbee devices. All modern Zigbee Coordinator adapters can handle thousands of older Zigbee devices but only about 200 Zigbee 3.0 devices because their security has a much larger overhead that require more RAM and faster CPU in the Zigbee radio SoC.
Conbee 2 / RaspBee 2 are based on a slightly older Zigbee radio SoC that have less RAM and slower CPU than the ERF32MG21 SoC that the Home Assistant SkyConnect is based on.
If the Conbee 2 / RaspBee 2 have more devices then it is either because those are not Zigbee 3.0 devices or the devices are connected via a other non Zigbee 3.0 profilen which many Zigbee devices can do for backwards compatiblity, but then they are not able to make use of the better security that the Zigbee 3.0 profile offers.
In summery; due to the much higher security requirements in Zigbee 3.0, Zigbee 3.0 coordinators can only support a limited amount of Zigbee 3.0 devices. For Zigbee 1.2 coordinators there is no limit on the max number of Zigbee 3.0 devices that can join as they will join using a backwards compatible profile. ConBee 2 and RaspBee 2 happen to not be Zigbee 3.0 coordinators, while Silicon Labs EFR32MG21 and Texas Instruments CC2652/CC1352 (and newer) are Zigbee 3.0 coordinators.
Note! I should add that around 200 is only around the maximum of Zigbee 3.0 devices on the current commonly used generation of Zigbee SoCs, i.e. the Silicon Labs EFR32MG21 or Texas Instruments CC2652 and CC1352 which have relatively similar specifications of Flash Storage, RAM and CPU on their MCU SoC.
Both Silabs and TI have released newer generations of SoC, with the EFR32MG24 (and EFR32MG22) from Silicon Labs and the CC2674 + CC1354 from Texas Instruments, all of which have more Flash Storage, more RAM and faster CPU than previous generations. It is just that no one has yet made any commercial Zigbee USB adapters based on those, however, my guess is that it is only a matter of time before newer adapters based on those later SoCs will start to appear.
The amount of Zigbee 1.2 devices should not be a problem if have enough Zigbee Router devices, but could get worse latency performance if there are too many jumps to a device. A possible workaround for that is to enable ”source routing” but then need to be sure to have great Zigbee Router devices and there is a risk of the network becoming unstable if a Zigbee Router goes down or is not fully up to task, which is why ”source routing” is not generally recommend (and has to be enabled manually).
Regardless, I would also be sure to utilize Zigbee Groups as much as possible for direct control.
Partially, ZHA (as a built-in Zigbee Gateway host application) does go down and as such Zigbee devices that you have not bound via Zigbee binding directly or via a Zigbee Group can not not control other devices while Home Assistant and/or ZHA is being restarted if the Zigbee Coordinator looses power or you use Home Assistant automations as ZHA contains the ZDO, but Zigbee devices that you have bound can still communicate and control each other directly even when the Zigbee Coordinator and Zigbee Gateway host application is not available. However that part is the same for Zigbee2MQTT. So be sure to utilize both Zigbee Bindings and Zigbee Groups regardless of which Zigbee Gateway host application that you are using.
Those are really Zigbee 101 questions so you are really best of by educating yourself on how Zigbee actually works.
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.
