feat: emberAdapter: add SEND_MULTICASTS_TO_SLEEPY_ADDRESS stack config.

[adriweb]

Note: several commercial Zigbee stacks/coordinators use this option.

P.S. This happens to be a "solution" to Koenkk/zigbee2mqtt#30247.

Tested successfully on a SONOFF Dongle-M coordinator.

[Nerivec]

Per Silabs source:

This can be changed, but doing so is not ZigBee Pro Compliant and is possibly NOT interoperable.

Also, this is hardcoded in a lot of converters (since this is spec compliance), even with this, the error in the linked issue would still be thrown.
So, while this bypass would be effective at the stack level (to unknown effect), Z2M would still reject. Would need a much larger refactor, which at first glance due to the unknown effects, is probably not a good idea (e.g. could end up with plenty of routers just dropping these messages...). Probably best kept as a "done in custom firmware build" for tinkerers.

[adriweb]

Yep, I noted the non-compliance thing in the commit I have locally for the zigbee2mqtt doc if this ends up being merged.

Anyway, I mean, I've been testing it with zigbee2mqtt with several brands of routers and end devices, so far so good.
And for instance both Somfy and Screen Innovations are doing this so it must not be so broken 😅

It seemed fine to me as a custom optional user option only toggleable in a json config file. Do you know of specific issues that this would trigger on the z2m side so I could look into it?

[Nerivec]

Every converter in ZHC with a hardcoded group reject would not work, even with this, since it rejects long before it reaches the adapter. The whole codebase is treating this as impossible, so, bits that won't work are going to be spread all over.

It has the potential to break entire networks (takes just one router discarding these messages to make a mess), so, very tricky in my opinion. Can't rely on what a brand is doing to judge if it's safe, way too many are doing custom stuff, as long as it works with their hub...

Anyhow, without compatibility overhaul on Z2M side, it wouldn't work. We can't even be sure if it is properly wired "everywhere" in the Silabs stack, since that's a custom that would always be disabled in internal testing. 🥵

[adriweb]

Oh, well, yes it would definitely be much more manageable if this was done some other more standard-friendly way, I'm just not aware of anything else now.
Even without that, it could also be maybe some kind of group-scoped property so users could adjust it accordingly when then know the devices in the group are actually listening often-enough / aren't really sleepy devices like sensors (I've seen some poll control stuff that are very weird, out there anyway... probably not passing any kind of certification lol).

In fact, I wonder if this stack option is toggleable on the fly (i.e. what if we try to enable it right before sending out a command to such a special flagged group, then disable it back afterwards), I haven't checked...

Note for context: several people (me included) tried to group window-covering devices (some of them battery-powered, so those are definitely not routers), and we see that the battery ones don't get group commands (or multicast in general, as expected) but they are still kind of always listening anyway (very frequent poll) since they are controllable individually just fine. With this option turned on, it does work fine for group too. Anyway, I'm sure you understood where this came from.

Anyway, is there any hope of having this merged if we insist that "this is an option that might at best not work, at worst break stuff, and it shouldn't be used unless you know what you're doing and assume all responsibility yourself for whatever happens" or something like that? Or should the PR just be closed for now (until a zigbee2mqtt overhaul to better handle the consequences of that - in which case, we should probably know a bit more about what that involves)?