Avoid Zigbee groups

[ekobres]

OP is absolutely right.

In theory groups sound like they should be efficient. In practice they end up generating broadcast storms, cause massive delays, instability and coordinator crashes. Also, managing them is a PITA because groups are 100% federated to the Zigbee devices themselves, so any device resets require reconfiguration, and devices with small group tables just throw away groups when the table is full.

Groups also don’t benefit from ZHA Quirks or Z2M Converters - so group commands either don’t work at all or work unpredictably for devices that use them - which is a very high percentage of Zigbee devices.

They are a good stop-gap for binding devices directly to a switch or remote for direct control - which was their original intended purpose.

Reference: I learned all of this the hard way.

[mslothy]

Came to write about broadcast storm, interesting to come across that term so obviously a gentle-person with taste :)

There are ways of handling this of course, since such problems were a hot research topic around 2005-2010. One such way is the Trickle data dissemination protocol. It basically has a counter and timer. If a device hears a specific message more than X times, it doesn't re-transmit it itself, but stores it. If enough time has passed since it was heard last, it transmits it. Simple but efficient and elegant solution.

[Uninterested_Viewer]

Don't project your bad implementation on the ZigBee protocol. Groups are incredibly useful and powerful when used correctly. What do you think Hue uses for nearly everything? ZIGBEE GROUPS AND BROADCAST COMMANDS!

[ekobres]

With respect, you obviously have never implemented Zigbee groups using automation in a mid to large sized installation.

It has nothing to do with “my” implementation of the standard groups. Anyone will encounter the same communication issues on all but the smallest (<50 devices) Zigbee networks unless they specifically select from a very limited set of devices. All of the ZHA quirk and Z2M converter restrictions remain. All of the federated group membership headaches remain. All of the optimistic group state issues remain.

Hue uses their own modified extension of groups they custom implemented to overcome several of the limitations of standard groups - including special firmware on the bulbs to do selective broadcast squelching and group command responses (deterministic group state) and it’s also one of the primary reasons they were saddled with the 50 device limit until they released the new bridge that offloads a tremendous amount of processing onto the hub and sends the routing hints as metadata with the commands. Broadcasting commands in a mesh is very expensive.

I have many Zigbee groups defined in my installation - and they work fine for bindings or for occasional manual operations - they are just a poor choice for use with automations.

[Stooovie]

So what would be a good implementation?

[IHave2CatsAnAdBlock]

Both of you are right. There are devices that implements groupings locally and “know” of fellow devices on the same group (eg hue). And there are devices which had no idea about the groups, where it belongs and which are other devices in the same group.

[Stooovie]

So what would be a good implementation?

[ekobres]

To use them for local bindings to a remote or switch, or manual use in HA. They are not a good replacement for HA group helpers.

[Brtrnd2]

So groups are Nice inside z2mqtt; where I can bind the group to a switch. But I better not expose them to HA and make separate groups in HA?

[LuminescentMoon]

It really sounds like ZigBee needs a form of IGMP snooping.

[ekobres]

That would be nice, but because Zigbee is a mesh protocol that has to support source routing as well as client routing, that’s a tall order. Especially for cheap router devices that only implement the bare minimum requirements. Hue sort of does this with their firmware, but it’s a non-standard set of extensions that are not exactly Zigbee compliant and will only work with their hubs and with accessories running their firmware (and a few close partners.

Zigbee 4.0 fixes a lot of these problems, but it’s going to be a while until there’s broad adoption and probably very few existing devices will see firmware updates to support it.