I asked before about the 32 zigbee limit. I understand i can overcome this limit once i have some repeaters but the part i dont understand is, once i reach the 32 limit of direct zigbee hub connections (this is including the repeater plugs if any) how do i pair other zigbee devices????
Just like i normally do?
That parts is the one that confuses me the most because when i read that theres a limit but then they say "yes you have a limit of 32 direct connect zigbee devices to your hub but you can go over the 32 limit with repeaters" where do the other devices go? do they just stay in limbo and take another devices place when that device is off the grid????
To me is like an oxymoron.... Plus my OCD can't make heads or tails of it LOL
Correct
They pair with the hub, just like any other device. It is just that the traffic has to go through another device to get there.
Zigbee builds a route table. The hub (and each repeater) can only talk DIRECTLY to x number of devices. If they need to send a message to a device that is not in their direct list, they use the routing table to figure out which device they do have direct contact with that can get the message to the end device for them.
Same in reverse (more or less, technically it is a bit different).
Don't worry about it. Just add as many zigbee devices as you want. It is all taken care of in the background.
In any home automation scenario I could think of, you would be adding repeaters well before you reach 32 zigbee devices. Why? It's because repeaters help you build out and strengthen your mesh, which is what you need to do if you want zigbee devices in rooms other than the room your hub is in. This happens way before 32 devices have been added.
With that said, some thought should be given to how you deploy your zigbee mesh and where you place repeaters. But this is done for the purposes of building a strong mesh and not for concern around a 32 device limit.
so in other words the HUB only talks directly to his 32 immediate neighbors (Devices) but if you are neighbor (Device) #33 even though you have the same address as neighbor #1 the HUB is being a snobbish a$$hole and even though he sees you at the elevator and water cooler every day he sends neighbor #1 to give you a message instead of talking directly to you?
Every device has a unique address. The addressing doesn't go 1-32 at all, and it doesn't start over like your example.
The routing table is more like slots that have the addresses in them (it is literally just a list of addresses). So if the hub has 32 address slots, it fills them until it is out of slots. But it knows what is in the slots of other repeating devices, too. That is how it can figure out how to talk to a device that isn't directly connected to himself.
Pretend the hub and each repeater could only talk to 3 other devices... That would be a super shitty mesh, but it makes trhe example easier. 
Hub talks to A and B (C, D, E, and F are all out of its range so it doesn't see them)
A talks to Hub and C and D
B talks to Hub and E and F
If hub wanted to talk to device F, it knows it can only talk to device A and B directly. So it would look at A and Bs route table (it already has those cached, so the lookup is quick) to see if either of them can talk to device F.
It would see that device B can, so it would tell the message to go: hub --> B --> F.
5 Likes
Yes, but that scenario never happens in home automation because you don't have 32 devices in the same room as the hub. So device 33 is several rooms away, which makes the going through device #1 a better communication choice.
3 Likes
Also true. My example above was intentionally over simplified.
There are other things in the routing calculation like speed, latency, etc that helps the hub make the most efficient routing decision it can. The algorithms aren't perfect, but they work well enough in practice.
4 Likes
I understood your explanation perfectly. I was just confused because of the "32 Limit".
I might know a lot about other things but this home automation is just kicking my arse lol
It also doesn't help that i just discovered zigbee and zwave never even knew these existed before i started down this road. For some reason i understood the mesh part of zigbee it was clear as day the first time i was reading about it but not the limit part.
1 Like
Is there a reason why the zigbee mesh seems easier to manage than a zwave mesh? Purely the frequency?
I’ve only got a few zigbee devices and most are wireless. They seem to work without any issues and are spread widely throughout the house. My zwave on the other hand I have had to double the devices compared to ST and despite being all wired are challenged.
I assume both antennas are both equally smaller than ST and the frequency just naturally travels further(?) but are there other reason a zigbee mesh seems to need less oversight?
Just looking to understand, not debating why one buys zwave over zigbee.
The reason for the limit of directly connected Zigbee end devices highlights one of the fundamental differences between Zigbee and Z-Wave networks. Actually the whole notion of 'directly connected' only has meaning in the Zigbee domain.
A Zigbee end device 'child' uses a set of dedicated store and forward message buffers that reside in its 'parent' device. It chooses its parent when joined to the network (the parent can be the hub or an always-powered Zigbee device/router); that relationship persists until it is told to leave the network or has radio link issues communicating with its parent (in which case it transparently attempts to find another one).
Whenever the hub sends a message to a Zigbee end device, the message always gets written to one of the parent's dedicated buffers for that child; it sits there until the child wakes up (which it does so periodically, on predetermined interval) and asks for it. Likewise when a Zigbee child device has a message for the hub (like a sensor event to report), it only communicates directly with its parent and tells it to store the message and route it for delivery. The Zigbee end device has no knowledge of the network topology; the parent is responsible for that.
A Z-Wave sleepy device has no specific parent; merely neighbors that can hear a message being sent and that choose to retransmit it if that neighbor's own ID is part of the routing field of that message. The Z-Wave sleepy device needs to be able to determine and report to the hub (during Z-Wave repair) who its nearest neighbors are so that the hub (which maintains lists of adjacent nodes) can build routes which include those neighbors, and then tell the sleepy device to remember those routes and use them when it wants to talk back to the hub. Messages aren't buffered in any particular Z-Wave repeater along the way except in the case of 'beaming' devices, which keep blasting away until their intended target (like a Z-Wave lock) wakes up and acknowledges receiving them. If the hub talks to a Z-Wave sleepy device when it's asleep, oops, the message gets ignored... try again later.
The dedicated resources-- the send/receive buffers for each potential Zigbee child device and all the protocol timing and tracking overhead devoted to communicating with each of them periodically-- needed to support 'X' number of child devices is the reason why the number of directly connected devices is limited.
Zigbee is a fairly complex protocol; not suited to the 8-bit 8051 cores that all Z-Wave devices prior to the 700 series were saddled with (every Zigbee device uses some version of 32-bit ARM Cortex). But it makes handling things like locks easy to do (beaming is unnecessary). And the hub doesn't need to track a Zigbee sleepy device's wakeup interval; its message will be buffered in the always-on parent for that device. Other things like network wide inclusion also come for free. Not to pile on, but (in my opinion) the 90's era Z-Wave architecture has seen a lot of its chickens come home to roost, resulting in a kludge of patches and enhancements to stay relevant.
6 Likes
Way to make my super simplistic version sound idiotic. 
1 Like
Makes you feel better I liked your version 
2 Likes
Aw shucks... 
2 Likes
@Tony @JasonJoel Thanks guys!!! Really cool of both of you to spell this out. It’s one of the favorite things about this community for me.
I’m sure I will come up with some other things to automate but right now I’m really trying to get what I have working really well. Understanding how it works (at least at a high level) I think is an important step that I should take. Thanks for dropping some knowledge on us.
3 Likes
