Hi, folks. Some advice would be really appreciated.
I have a very large Zigbee setup: 351 Hue bulbs and 17 FLS-CT lp strip controllers, plus 65 Phoscon groups (rooms), all using Deconz via Docker with a ConbeeII stick. It’s temperamental, especially after container restarts, updates, etc. Weird thing happens like rooms coming on when they shouldn’t, Deconz closing without warning, Deconz appearing to be working but no lights can be controlled (requiring restart), frequent issues that appear to be caused by too-frequent updates (automated color temp changes, etc.), etc., etc.
Bottom line: while well within Zigbee specs, Deconz as currently designed doesn’t seem able to handle it. It sounds like a complete refactoring is going to help a lot (see this reply to a long tread over on their forums) but the family is impatient and I’m not 100% convinced that all the problems will go away.
So… my question: is the SkyConnect, which I recently purchased as a potential solution, and the associated software more capable of better handling traffic and device confirmations as they should (see the forum posts for how the current Deconz works)? In other words: is there confidence that SkyConnect could mitigate some of my issues if I go through the effort of switching?
350+ devices is a lot. You might be better running this on separate networks. Closest thing I can think of is the UZG-01 that supports 300. UZG Gateway - ZigStar UZG
The ConbeeII with Deconz supports up to 500, so moving to something less isn’t helpful. The Zigbee spec itself supports up to 64,000 nodes per network although I’m sure lots of realities would limit that significantly.
Again, it works, just not as cleanly as I’d like. Really just curious if there is better software management vs Deconz (per that great answer in the Deconz support thread linked above). I just don’t want to take the migration plunge without some solid “oh yeah, we handle that sort of thing better/differently than Deconz does so you’re likely to have a better exprience” answer… if it exists.
To me it sounds like you already have hit a limit on the number of devices you run. I don’t think you will solve this by moving to another stick, I think you might be better off splitting it up. Maybe @Hedda has some input here?
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+
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.
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.
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.
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
