Are Zigbee groups really that advantageous?

Configuration Zigbee
, ,
21

My explanation/theory is an (over)simplification, in skimming the linked document along with some additional ChatGPTing:

  • Zigbee has 4 routing protocols (Broadcast, Multicast, Unicast and Coordinator discovery) - the example above only uses 2.
  • Multicast is used for groups.
  • However multicast falls back to broadcast - additionally even when operating “normally” multicast differs from broadcast in how effective the “filtering” is.
  • There are going to be some retries.
  • Embedded devices are made to a price point, so they likely have limited memory for managing unicast and multicast routing tables.
  • Overall performance is going to be specific to your setup / RF conditions.

I have been using “fuzzy” words like “small”, “large” and “effective”, which leads to obvious follow up requests for definitions of those terms.
However we are quickly going to come back to: It’s going to depend upon your setup / conditions - which is why I am not defining said terms.

We can make some generalizations:

  • For “small” Zigbee setups - this discussion likely doesn’t matter - because the network will have enough bandwidth that it can waste time transmitting and the user won’t notice.
  • There is likely an upper limit so for very “large” networks, performance will likely degrade whatever your do.

TL;DR - My explanation is not accurate, but it’s likely accurate enough that for most people the guidance is going to be - if you are having issues, try removing unnecessary groups and see if things improve.

The documentation says that broadcast messages are transmitted 3 times.

Unicast messages are acknowledged so under good conditions, there will be at least twice (2 times) the number of messages I listed previously, if more retries are required it could be 3, 4, 5, 6 … times that number of messages.

So again an accurate answer is going to require knowledge of your specific setup - if we assume that on average unicast messages are transmitted 3 times then the ratio 3:3 is going to be preserved so my (over)simplification may be good enough.

Given the amount of generalizations I have stated here, a quick eyeballing of the routing map and saying it looks like most devices are around 3 hops away from the coordinator is probably good enough.

1 Like
22

This is so confusing that it’s hard to choose :face_with_diagonal_mouth:.

After reading more, I think Multicast is the way to go, but like @dtrott said, it’s dependent on your devices. It’s possible unicast works better for you.

Unicast

What it looks like for a unicast message:

Home Assistant → Coordinator → Mesh → Device → Mesh → Coordinator

Then it does another roundtrip message (application acknowledgment) which I think is the device saying “I’m in this state”:

Device → Mesh → Coordinator → Mesh → Device

With unicast, you traverse the mesh 4 times for a single unicast message (2 roundtrips). If you have 4 devices, that’s 16 messages back and forth.

Still, Unicast isn’t that bad

What matters the most is this:

Message → Coordinator → Mesh → Device

At the point you hit a device, the state can change. Even if 3 other acknowledgment messages are going to occur, the light already turned on.

Zigbee Groups are better in theory

With Zigbee groups, you can avoid all these back-and-forth messages because multicast and broadcast messages function differently. They only send out a single message to every device on the entire network.

Multicast is the same as broadcast with more advanced filtering (see below).

The lights turn on at the same time with multicast because they all receive the same message at around the same time rather than 2 separate unicast messages.

Timing shouldn’t technically be different

All-in-all, the timing should actually be very similar in both cases, but they differ in the acknowledgment. From what I understand, unicast messages that fail need to be resent at the originator (device or coordinator).

Multicast and broadcast messages that fail only have to go back to the last hop. That’s a lot more efficient if you discount the fact that you might’ve had to hit every device on the mesh.

Multicast is different from Broadcast

How Broadcast works

Broadcast, in the 0xFFFF method, will hit every Zigbee device in the mesh:

image
image752×261 14.6 KB

If your coordinator has 32 connected devices, it will have to send out 32 messages. With Unicast, it would only have to send out 1 for each light. Broadcast messages are obviously network-intensive no matter how you look at it.

The big difference is the coordinator only has to receive acknowledgment from its direct children, not from every device in the mesh.

How Multicast works

Each device keeps the list of its multicast group memberships in a table called the multicast/group table.

It looks like multicast avoids sending messages more than necessary.

It’s like an Ethernet switch with the MAC/ARP table. Each device knows what’s connected and where to throw around data. Once all those devices are hit, it stops there. Like if it knows there’s no device in that group after router X, then it stops the message right there.

Multicast sounds really efficient compared to Broadcast.

From the perspective of your coordinator, instead of sending out 32 messages to 32 connected devices, you only have to selectively send out messages to those devices that will eventually touch the members of that group.

Just like with broadcasts, if a message doesn’t send, it doesn’t go back to the coordinator, it’s up to the nearest router to resend the message.

SUPER efficient!

Conclusion

Since my mesh is very large, you’d think Multicast would be bad, but it’s actually Broadcast that’s bad. Multicast, provided devices have enough memory to store the locations of every device in every group, would be the best option out of all these.

Which makes me think the ZBT-2 might have an advantage here over the ZBT-1, but I really have no way to know.

Next steps for me

For now, I’m gonna leave my Zigbee groups alone. If you have issues, you don’t have to remove Zigbee groups, you could try sending Unicast messages to your group instead. If not, you might be running into multicast memory limitations and you have too many Zigbee groups or too many Zigbee devices in groups.

23

I agree its complex/confusing, so coming to a definitive conclusion is difficult however I did read several points differently.

No - In the case of Broadcast the message will only be sent once - but it will be received 32 times.

Broadcasting is extremely efficient - it’s re-transmission that is expensive.
If all of your devices were directly connected to the co-ordinator only 1 message would be needed.

Saying that another way I don’t think Broadcast and Unicast are transmitted at different power levels, so either type consumes network bandwidth.

There is no explicit acknowledgment for Broadcast messages - instead the relaying of the message is considered to be the acknowledgement.

I wasn’t able to figure out if Multicast works the same way as Unicast or Broadcast - with respect to acknowledgements.

If a router chooses to send a Multicast message it is broadcast to all nodes in range.

The “filtering” of Multicast is performed by each receiving router, as they have a choice to either:

  • Re-transmit the message - in which case it will be another broadcast.
  • Drop the message - hence not send it to anyone.

It appears the the algorithm is cautious in that if the router doesn’t know it will choose to transmit - if all routers do that, effectively the message will be broadcast to all routers.

No Zigbee is a wireless protocol, every time a router transmits all receiving devices (in range) will “hear” the transmission - it’s up to those devices to choose what they do with the message - for unicast, only the targeted device (or intermediate router will take action).

Hence every transmission uses some of the available radio spectrum.
A network switch can choose to send a packet down only a subset of the connected wires.

I think Multicast will never be worse than broadcast (at using RF capacity).
However is not clear to me that it will be significantly better, the X factor here is how many of the routers (on average) choose to repeat the message.

As noted previously in broadcast the coordinator only sends 1 message - actually maybe 3 messages - because I read it transmits it 3 times (I am not clear if it always sends 3 times or only when no-one retransmits)

I think Multicast works the same way from the coordinators perspective.

This is unclear, because no router has full visibility into the network and they dynamically update their view ** - hence it’s unclear how often Multicast needs to fall back to Broadcast.

** - There is no concept of replicating routes in the Zigbee protocol - each node just figures it out based on traffic it has seen recently.

2 Likes
24

Yes, you’re completely right. I was thinking in terms of physical hardwires, not wireless. That’s why many of my assumptions were wrong.

When you “broadcast”, you only send one message omnidirectionally, so all devices hear it. If the coordinator notices another broadcast from a connected device, then it knows the broadcast went through! It’s actually super efficient :slight_smile:.

Not so much in Ethernet land.

Then yes, I agree that unicast isn’t as good as multicast when dealing with wireless devices so long as battery-powered devices (that don’t care) won’t wake up to hear these multicast messages, but they will hear it, they’ll just filter it out.

But I do wanna point out this is a direct quote from the Silicon Labs site:

Each device keeps the list of its multicast group memberships in a table called the multicast/group table.

Now that I re-read it, it’s saying a Zigbee group member understands which multicast groups it’s a part of, so when it gets a valid multicast message, it goes ahead and “turns on the light” because it knows that message was for it.