So I got around to installing a sniffer and I am by no means a Zigbee expert. I recorded roughly 60 seconds of data and ended up having close to 5000 messages sent during that time with the bulk broadcasts across the whole network. I have no idea what would be considered to be normal but that seems like a lot and I know that network broadcasts tend to significantly slow down the network.
I have to say my zigbee network has been noticibly slower since installing my Blue Switches and I was wondering if they were flooding the network some how. Using Zigbee2mqtt with HA.
So after slowly playing around with this over a few days, Iāve figured out how to help decrease the flooding. Everything is back to being snappy again. 2 parts I noticed. In the exposes tab on z2m, disabling power reporting and setting high values for power reporting reduces the packet size of the spamming. On the reporting tab, set your minimum to 1800 which is 30 minutes and max to 3600 which is a hour for every reporting value on every individual blue switch. This has knocked down my cpu usage from 6-18% to 2-3%. My zigbee network also isnāt getting flooded anymore. If the action has a ā1ā it will report or send payload when the switch state is changed. Hopefully this helps some of you get everything under control.
@Eric_Inovelli I know youāre busy but reading through routing / signaling thread; seems like a lot of people are having issues with network flooding and not defective hardware. Whatās posted above should help a good amount. The config in z2m defaults to a ā0ā reporting value which tells the switch to report as much as possible causing the flooding.
5 Likes
Thatās interesting, because a setting of 0 for parameters 18, 19 and 20, the power reporting parameters, is supposed to disable the reporting. Is z2m interpreting that value incorrectly?
EDIT: According to a lower post from @epow, there is a difference between setting the reporting interval and setting the reporting parameters. What I posted here pertains to the PARAMETERS, not the INTERVAL.
Iāve noticed that my replacement Blues all have a minimum reporting interval of 1 for seMetering and haElectricalMeasurement. Iāve always seen this default value across multiple versions of z2m and the Inovelli.js converter. Just to be safe, I set these minimums to 1800 and also disable reporting via the parameters (exposes) page. Never had a flooding issue this wayā¦ add a switch, tell it to shut up, and then proceed to configure it. Rinse, repeat.
Edit: I have 11 installed Blues at this point, so maybe I havenāt hit the threshold where Iād see a spam issue. 3 of them have bindings to other devicesā¦ so far so good on that front.
1 Like
Iāve got all my switches set at 0 for all power reports and Iām still experiencing significant slow downs. Iāve also had frequent random switch resets. I think itās a good start got Iām still not sure thatās the whole story
Are the switches still reporting power set to 0?
Just to be clear, did you set the reporting interval to a high value as well?
1 Like
Reporting interval is set to 0 after discussion with Eric to turn off. I wanted to see what happens if I unbind some of my devices but I canāt at this point as the switches unbind request times out.
Reporting interval of zero is different from setting the reporting parameter on the Exposes tab to zeroā¦ reporting interval of zero tells the switch to go ahead and report any change. Set this to a high value, like 1800. On the Exposes tab, setting the parameters for power and energy reporting to 0 is supposed to disable the reports completely
3 Likes
Any way you can share a screenshot of where the interval setting is?
*Update right in front of me under the reporting tab 
Will try these out though Iām wondering if my main problem is with the broadcast messages from binding
1 Like
Yup change those two minimum reporting intervals to big #s and hopefully itāll help.
2 Likes
Cautiously optimistic. Went around and air gapped all of my switches and made this change for each one. So far the network seems to be much more stable and I donāt seem to have the restart issues with the switches. No errors in my logs either and bindings seem to be more stable. 
. Thank you so much for the suggestion, Iāll post here tomorrow for follow up to see if this corrected the issue
1 Like
anyone know of a way to do this in ZHA?
You will still get some logs but it should be spaced out and not receiving 5 every second.
As far as ZHA, I havenāt used it so Iām not sure. Poke around and see if thereās anywhere you change the reporting interval.
So far so good. This has turned my network from unusable to working again. Bindings work, network is responsive and no more random resets of the switches.
Very appreciative of the community and @epow for the advice! Hopefully in future z2m versions the update interval can be changed to a new default. Thanks again!
1 Like
@epow Out of curiosity, if you set the PARAMETERS all to 0, will that alone remedy it so you donāt have to tinker with the min/max reporting intervals?
The min/max reporting intervals seem redundant to the Parameter settings.
Honestly I have no ideaā¦ seems like they should use one or the other. The reporting interval settings are more universal, and are likely baked in features of the zstack running on the MG21. Seems like the more reliable betā¦ otoh, I understand the intent behind the custom parameters on the Exposes tab. Makes sense to have all valuable config on a single page. Unfortunately it seems like something is screwyā¦ based on reports it doesnāt sound like the custom parameters are working correctly.
3 Likes
The interval settings on the reporting is the only thing that slows the reports. Completely an assumption from playing with it butā¦in the reporting tab for interval, it has an action state to report. Anytime the switch has an active load or varying power consumption, it starts reporting in a feed back loop with the default settings.
2 Likes
At this point I think Iāll declare victory. Network remains stable without issue!
5 Likes