zigbee-herdsman: 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.

About this issue

Original URL
State: closed
Created 4 years ago
Comments: 19 (1 by maintainers)

Most upvoted comments

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 on Dec 23, 2020

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).

MattWestb on Dec 23, 2020

2 problems with your storming the mesh: The network layer is limiting broadcast to around 1.2 / secund (its not zigbee its the network under it that have it implanted for not getting the network killed of broadcast storm) and Silabs (IKEA. tuya, sonoff and new Philips with BT and so on) have one bug that can killing the network stack in router device then receiving parent announcement (its one broadcast then being send then one router device is coming back in the network). ZHA have one dev killing its network by switching power of and on half of its network and some router devices was getting in locked state. Then one other was flooding his network (after implanting folding function in ZHA) and was able triggering the bug after some minutes. The but is fixed for some weeks ago in the SKD but the company’s have not implanting it yet. So be little careful then “storming” your network !

Good work done !!!

MattWestb on Dec 23, 2020

The 0x0017880108da33aa is not one IKEA devices but one Philips HUE one as of the prefix 0x00178801XXX and is not one status request its one rejoining of one device (I have one HUE motion sensor that is making that very often and on other that is not making it for the moment).

MattWestb on Dec 22, 2020