This is technically different from “groupcasting” in the Zigbee specification and is not available on all stacks.
UNICAST vs BROADCAST IN THE ZIGBEE SPECIFICATION
Zigbee offers both “unicasts,” a message intended for a specific device and passed along a route to that device. And “broadcasts,” which are delivered to ALL devices in the network and it is up to each device to decide what to do with that message.
It should be obvious that a unicast uses many fewer network resources and generates less potential interference than a broadcast, so unicasts are generally preferred.
ZIGBEE GROUPS
Zigbee does have the concept of groups, but to be honest they’re pretty primitive compared to some other protocols. Each device can only be in one group, which is just identified with a number. Some device manufacturers preassign a group at the time of manufacture, some let you change it later.
ZIGBEE GROUPCASTS: A TYPE OF BROADCAST
A “groupcast” is a type of broadcast in Zigbee. It is still sent to every device on the network, it just has a group number attached. Each device has to check and see if it is in that group. If it is, it acts on the message.
https://www.eetimes.com/zigbee-applications-part-4-zigbee-addressing/#
Again, a lot of resources are used. Still, this is popular in Zigbee lighting implementations. Only SmartThings has never used it much, preferring to send a series of unicast messages, which is why you can see a “popcorn effect” for ST scenes.
That decision isn’t uncommon in platforms that support the use of a lot of battery powered devices like sensors. Do you really want to use up battery life on every sensor in the network every time you utilize a lighting scene? On every Zigbee lock? Sometimes the answer is yes, sometimes the answer is no, but it’s understandable if a consumer system like ST decides no.
GROUP MULTICASTING IS DIFFERENT FROM GROUPCASTING
“Group multicasting” is something else again, and is NOT part of the Zigbee specification, but can be added to a specific platform in the application layer if desired. (I may be mistaken, but I believe Control 4 uses a version.)
In this, instead of sending your group message to every device on your network, you send it only along routes that have devices in that group. This is harder than it sounds. Essentially you have to keep a record of origin nodes to use for the broadcast route and assign them to specific groups. This is doable for a professionally installed system with meticulous device placement and limited device selection (so that every device handles group assignment the same way), but I’ll be honest, I don’t think it’s practical for a DIY home system with lots of devices from different brands.
MY OWN THOUGHTS
So…personally, I would like to see ST improve the groupcasting options available to end users, particularly being able to see which group a Zigbee device is in, to change that group if possible on that device model, and to issue a groupcast if we desire, maybe specified at the scene level.
I don’t expect to ever see ST add group multicasting unless they add a commercial services division for hotels and office buildings, but you never know.
@garrett.kranz @posborne @blueyetisoftware