ConBee II network becoming unresponsive

As part of investigating #273 I managed make my remotes (pressing a button wouldn’t be reported in the Z2M logs) and network (MQTT requests to switch lights on and off wouldn’t work) unresponsive. All my remotes that used binding (meaning they don’t go through the coordinator), including the ones controlling lights I tried to switch off through MQTT, are still working in that situation. The Zigbee2MQTT logs in non debug mode are just silent in that case.

I will try to reproduce the issue over the next few days, once I have backup remotes bound to all of my rooms and do not lose control of my lights late in the evening (which happened lots of time over the past months).

What I have tried so far (see my comments in #72):

• unpaired my Hue motion sensor and re-pairing it with the Hue hub, then pairing it with my network again
• removing my Hue motion sensor from my network altogether
• repair my whole network

The commands I am sending to my group when the remote is pressed:

{
  "state": "ON",
  "brightness": 254,
  "color_temp": 366,
  "color": {
    "rgb": "255,205,120"
  },
  "transition": 0.4
}

Even though I am using a group, this will send 4 commands as each of these need to be sent separately, which may be why I am overwhelming my network. I am also running with delays set to 0 as described in #273 which may be a factor too.

As I mentioned, I am opening up this issue to describe the symptoms and investigate the issue myself, if anyone else sees this too please share your experience.

I use a Conbee II with firmware 0x26680700.

[MattWestb]

One known good UK reference: https://github.com/zsmartsystems/com.zsmartsystems.zigbee/issues/1096 Its possible digging deeper but its not necessarily then the fact its one limeting in the under layer of the network protocolls.

[MattWestb]

The satrt is https://github.com/dresden-elektronik/deconz-rest-plugin/issues/1261#issuecomment-739313960 the findings done by ZHA devs in deCONZ git 😃)

The broadcast limiting is in the underlying IEEE 802.15.4 but i cant finding the exact writings for the moment but its there and well known in Zigbee and other IEEE 802.15.4 networks.

Sending commands to groups is technical being made with broadcast in the IEEE 802.15.4 layer that making the commands can going around broken routes that is not being fixed of the mesh. Unicast is direct addressed commands to one device and must being routed thru the mesh and if is having router problems its failing or being delayed then the mesh is finding the new open route for delivering the command.

The “unicast group commands” is false then groupe commands is always broadcast in zigbee.

Using groups for lights and sending groupe command from binded controlling devices is the core part of zigbee lights and its also making the controlling is working then the coordinator is offline. If trying using unicast for all commands its domed then the first failing route is happening in the network (can being some temporary radio interference or failing router devices) but can working well if having one very stabile mesh with good routers (no old OSRAM and so on).