SkyConnect with a LARGE Zigbee System (vs Deconz)

I believe this is probably a case of ‘what the spec says’ v what is actually possible.

Like the spec SAYS I should get 100’ between routing nodes. And I’ve never had reliable comms on any zigbee products past about 50’ (half the spec)

I’m interested in Heddas input too but. I’m splitting this one. Even split you have enough density to have a really solid mesh and I don’t see what keeping them together buys you except not having to manage two z2m installations. I’m surprised anything is remotely reliable at 300+

2 Likes

I’d be ripping it all out with those kind of issues.

You don’t have to do it all at once. Start by testing out ZHA and z2m with a few devices. Decide which you like best, then try slowly migrating, maybe room by room.

You may hit a point where Deconz becomes stable and can leave a chunk of it there untouched.

1 Like

How would splitting work? I thought only one Zigbee system could be used in HA at a time.

And from a Zigbee perspective: one uses one channel and another system another?

1 Like

Not sure how you have groups of devices interacting with each other. However, yes while zigbee handles a pretty large network of devices, one of it’s fundamental flaws is having a single coordinator with no redundancy/fail over. Not only is the single coordinator device a weak point, but IMHO the more stability reducing is the software stack that sits on top of the coordinator, if it fails or has issues, it does not matter if your lower level zigbee network continues to work fine (bout the only solid setup here is to have your zigbee devices bound together at the zigbee level in smaller clusters). As I understand it, the single coordinator issue, this is addressed in Matter (not that that helps your setup). So, it seems to me in your setup, if possible based on your device connections and interactions, slowly migrating to a setup with multiple Zigbee2MQTT setup with the Zigbee2MQTT stack and coordinators either running on separate machines, or in isolated docker containers. I’ve had very good experience with multiple Zigbee2MQTT systems running on a single machine in docker containers, not to the scale you have though. In the multiple Zigbee2MQTT path, while I have found Mosquitto MQTT broker to be very reliable, you will probably want to look at some type of redundancy in the MQTT broker as well.

You might read and post a query at the Zigbee2MQTT forum to see if you can find other folks at the same scale you are and how they are setup.

Good hunting!

1 Like

You can do it in different ways. Mix Deconz + ZHA/Z2M, Mix ZHA/Z2M, run several Z2M (either external from you HA or stable / development on the same HA). You’ll need more than one coordinator stick of course.

Yes, run them on different channels.

1 Like

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.

1 Like

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.

2 Likes

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.

2 Likes

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.

4 Likes

Even then, I have to wonder if 368 might not be pushing it on a 1.2 net. IIRC, isn’t there only 250kbs bandwidth on the channel?

A lot of sleepy end devices would be one thing, but OP has almost all chatty mains router devices. At some point congestion will be an issue.

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.

It might be off topic in this thread but I do have a question about ZHA compared to zigbee2mqtt.

With ZHA, does it go down when Home Assistant is restarted?

I’m running zigbee2mqtt add-on now but I was tempted to try ZHA since it was built in to Home Assistant.

Thanks.

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.

https://www.sciencedirect.com/topics/computer-science/zigbee-device-object

1 Like

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 :wink:

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?’ :wink:

Good hunting!

1 Like

Thanks, everyone! Especially @dproffer, @Hedda, @fleskefjes, and @NathanCu! All fantastic information.

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

Is that right?

2 Likes

Personally I think you can do it in Half that many. But basically yeah.

So ~ 100 to 130 bulbs per setup/channel doesn’t give you the twiches? :slight_smile:

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.