Inovelli Blue series flooding Zigbee network

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 :grin:
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. :crossed_fingers:. 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