Large Zigbee Network Experiences

If I may ask, what are you running HA on? I remember when the 2-1 blues first came out there was a discussion about the number of entities created with those switches and Z2M and the amount of overhead / updates on the entities or something. Are you seeing any issues with that?

I’m going to be rebuilding my 180 device Zigbee Mesh from scratch and need to pick a lane…

I’m running a SBC Odroid N2+ and have never seen it taxed, but don’t do any cameras or or super taxing processes (-from my perspective).



I moved my light controls out of HA for that reason. The amount of entities and keeping updates will all the things, when in default mode, was a lot of overhead. When I was on ZHA and using HA, I disabled unneeded entities to limit the amount of data flowing. Now I am using NodeRed with NRCKHKB to build custom Apple Homekit devices. Our primary interface is Apple Home and this works great as I can integrate the 2-1 switch controls and the color light options for Hue into a single entity that stays in sync across all devices.

For my setup, I actually run a 3 “server” proxmox cluster with high availability tied to a small Synology array. That way I have fault tolerance and can run multiple VMs. These boxes are Intel NUC 11s. Works great, probably overkill, but allows me to tinker with lots of things. Also a great reason for the network Zigbee devices as I can move the VM between devices without issue.

Good luck on the new network buildout!

Thanks Chris,
That’s insightful! I’ve got a Intel NUC (13) in the box waiting for a rainy day (someday). If I’m following you, that’s also the beauty of running Z2MQTT, is your Zigbee mesh is not platform or interface dependent. It’s stand-alone and you can call it from anything. I’m currently on Home Assistant with ZHA, using Node-Red to build out all automations and porting over to Homekit via a HA bridge for my primary and most of my family’s GUI interface. I’m just doing it backward from you with probably a lot of unneeded overhead.

Thanks again, I appreciate the insight.
I like your approach and may mimic it.

(Dear goodness, if someone reads this thread they’re likely going to say how far down the rabbit hole did these guys go?, -there are a lot of acronyms in this thread! :slight_smile: )

1 Like

I have reached what I consider the maximum supported network size. At 340 devices. Beyond that limit, I need to pull the power after the device joins so that it does not leave the network. With the MGM24 device from TubesZB I have a very stable and fast network. Also testing the new EZSP v14 with 8.0.0 firmware to see about that, but going to split this network into two so that I have two very stable and fast networks. Good luck to all if you have been following this thread.


This is amazing…
Thanks so much for continuing to send your feedback.

I keep waiting / hoping for a firmware update that will take me from 90 stable devices to ~180 with my buggy Juno downlights, so fingers crossed that happens soon.

Question, on the TubesZB MGM24, how / what have you been using to update the firmware on that device? What SDK version are you currently running, and if you updated it, what repository did you get it from? Just curious.


for latest production firmware:

I use universal-silabs-flasher to update the firmware. 7.4.3 (from the link above) has been very stable for me. 8.0.0 is very new and buggy. That is not yet released, but I have some testing firmware that I would NOT share at this point.