The protocol allows far more than your hardware will hold
Ask how many devices a ZigBee network supports, and the honest answer has two layers. The protocol layer, IEEE 802.15.4 addressing and ZigBee's network layer, permits networks of essentially arbitrary size, tens of thousands of nodes in principle. The hardware layer, the coordinator gateway sitting in your hallway, has fixed amounts of memory, and that memory is carved into tables with hard rows.
The tables that matter are the neighbour table, the routing table, and the child table. The neighbour table lists the routers within radio range of a given node. The routing table holds the paths in active use. The child table lists the battery devices that have attached themselves to a specific parent. Every one of these tables has a row count fixed at design time, and when the rows run out, no error message appears anywhere. Devices simply stop joining, or join and drop, and the network looks flaky instead of full.
This is why a smart home that worked beautifully at forty devices starts behaving strangely at sixty. The protocol never ran out of room. The tables in the gateway and in the wall switches did.
Three roles, and why the wall switches are the backbone
A ZigBee network contains three kinds of members, and the distinction explains most of the strange behaviour people blame on range or firmware.
The coordinator is the network itself. There is exactly one, usually inside the hub or gateway. It formed the network, holds its security keys, and every other device joins to it. Lose the coordinator and the network is gone, which is why a dead gateway is not the same event as a dead WiFi router, where devices carry on independently.
Routers are mains-powered devices. Every mains-powered ZigBee device, every wall switch, every smart socket, every wired-in module, is a router, whether the box advertises it or not. Routers are always listening, always available to relay, and always able to accept children of their own. They are the backbone of the network's shape and capacity.
End devices are battery-powered devices. Sensors, buttons, battery thermostats. They sleep, wake briefly to report, and cannot relay anything. Critically, an end device does not talk to the network in general, it talks to one specific parent, the router or coordinator it joined through, and it relies on that parent to hold its messages while it sleeps.
This architecture means that adding a smart socket to a distant room does something a WiFi repeater never does: it adds a new router and a new parent into the mesh at exactly the location where you plugged it in. It is the single most effective structural fix for a struggling ZigBee network, and it is available for the price of a socket.
The child limit is why your furthest sensor is the flakiest
Every router and the coordinator can support only a limited number of child devices, commonly somewhere in the range of twenty to thirty per parent depending on the silicon. A battery sensor must have a parent. When the nearest router's child table is full, the sensor attaches to whatever parent will accept it, which may be a router two rooms further away through a worse wall.
The symptom signature is precise: the same sensor, or the same small group of sensors, drops offline periodically while the rest of the network is stable. Rejoining the device fixes it for days or weeks, because rejoining resets it onto a fresh parent search, which lands it back on the crowded nearby router, and the cycle repeats.
A related symptom appears after adding many battery devices to a small network. The first fifteen sensors pair instantly and hold. The sixteenth pairs, appears in the app, and then vanishes overnight. Nothing about the sixteenth sensor is wrong. The parent it chose has no child slot left, and its parent search is not smart enough to walk the house looking for the emptiest router.
The neighbour table and the range myth
When people blame "range" for ZigBee problems, they are usually observing a neighbour table or a parent selection problem through the wrong lens.
A router maintains its neighbour table by periodically exchanging messages with the routers around it. The table has a fixed number of rows. In a dense installation, many switches clustered along one hallway, the table fills with strong neighbours, and the router then cannot record a weaker but still useful neighbour at the far end of the house. The far end is effectively unreachable through that router even though the radio could reach it, because the router has no free row to hold the relationship.
The mesh also has a depth limit. Messages hop from router to router, and the number of hops a message may take is bounded, commonly around five or so. A large house with a single gateway at one end can be within radio range overall but beyond hop depth at the other end. The fix, again, is a mains device in the middle, which halves the path for everything beyond it.
The practical takeaway is that ZigBee coverage problems are usually topology problems. The radio usually can span the house given a chain of routers. What it cannot do is span the house when all the routers are clustered at one end and the tables are full.
Two networks in one band, and the channel question
ZigBee lives in the same 2.4 GHz band as WiFi, and the two interfere in ways that produce intermittent, weather-like symptoms.
The band is divided. WiFi occupies channels 1, 6, and 11 in most homes. ZigBee channels sit between and across them, numbered roughly 11 through 26. The classic advice holds: a ZigBee network on a channel that overlaps the busiest WiFi channel will suffer, and a ZigBee channel chosen to sit between WiFi channels 1 and 6, or between 6 and 11, will coexist far better.
The interference signature is different from a full table. Interference shows up as high latency and lost messages across the whole network at times when WiFi traffic peaks, in the evening in a family home, during video calls, during large downloads. A full table shows up as specific devices dropping regardless of the hour. Distinguishing the two saves hours of pointless device re-pairing.
Most gateways choose their ZigBee channel at network formation time and never revisit it. A home whose WiFi layout changed after the ZigBee network was formed, a new mesh system, a channel change on the router, may have silently landed its ZigBee network on top of a now-busy WiFi channel. Rebuilding the ZigBee network, with its painful full re-pairing of every device, is the only reliable correction, which is a good reason to get the channel question right at installation time rather than later.
A field guide to the three failure shapes
Stable operation punctuated by one or two devices dropping offline is a parent or child-table problem. Move a mains device partway toward the flaky device, or re-pair the device while standing next to a different router, and the problem usually resolves.
New devices pairing but never holding, especially after a growth spurt in battery sensors, is a child-table saturation problem. The network needs more routers, distributed through the house rather than clustered.
Whole-network sluggishness and message loss at specific times of day is an interference problem. Check the WiFi channels, and expect to rebuild the ZigBee channel if they overlap.
A network that loses everything at once and recovers after a gateway reboot is a coordinator problem, and if it recurs, the gateway is either underpowered for the device count or has a genuine fault.
Buying for the network you will have in three years
The device count on a ZigBee gateway box is a marketing number until you know what it counts. The questions worth asking are what the coordinator's table limits are per category, how many end devices each router class supports, whether the firmware implements parent migration so that a battery sensor can move to a better parent without dropping off, and whether the hub offers a wired backhaul option for spreading additional routers across a large property without loading the mesh itself.
These are specification questions with real answers, and the answers describe the difference between a network that celebrates its hundredth device and one that starts degrading at fifty.
On the sourcing side, we manufacture ZigBee switches, sockets, and gateways as one programme, which matters because the switch and socket fleet is what gives a mesh its shape, and the gateway's table sizes are what give it its ceiling. The smart gateway range covers the standard builds, and the automation system manufacturing programme is documented on the home automation system manufacturing page. For volume and OEM enquiries, the manufacturer site and the contact page are the direct route.
Top comments (0)