Inovelli Blue series flooding Zigbee network

I’ll have to give it a try. I want to verify myself or have someone else verify than I’ll update the post with your solution so it can help out people. I’m surprised that there wasn’t more threads about this but I think people are also confusing it with the hardware issue with the first batch.

Just to somewhat clarify: this thread seems to track two, mostly unrelated issues:

  1. the energy reporting that floods the ZigBee network itself with traffic

  2. the amount of entities created and updated in HA via MQTT/Z2M

#1 fix is to change the reporting interval as has been discussed. I’ve been able to monitor my actual ZigBee network traffic (via a Sonoff stick flashed with sniffing firmware) to verify that this does fix the flooding issue on the actual ZigBee network w.r.t. the energy reporting. Hopefully this can be addressed in firmware at some point.

#2 is annoying, absolutely - but does not have any impact to the ZigBee network itself (as far as I can observe). This is purely between Z2M/MQTT/HA and does not cause any flooding or increased traffic in the ZigBee network itself.

Does this track with your thinking on these issues @Jorge ?

3 Likes
  1. It may not be the energy reporting that’s causing it to consistently send out payloads to the network. Something is definitely causing it but I can’t say for sure it’s the energy reporting at least for z2m.

  2. Is definitely an issue and it may help congestion on the network by not reporting every single entity on each switch. The payload report is fairly big because of this. I don’t know if it’s necessary for the switches to report every single state.

Changing the reporting interval solves 1. and 2. If 1. Is making rapid reports and 2. Is sending huge log reports, both contributes to congestion.

If 1. Is making rapid reports and 2. Is sending huge log reports, both contributes to congestion.

I guess I’m trying clarify that 1 (the energy reporting) is sent over the ZigBee network itself, while 2 (the large amount of recurring data for things like “led 3 color when on”) does not go over the ZigBee network: it is purely being sent from Z2M to MQTT/HA. Therefore, 2. cannot lead to ZigBee network congestion, but 1 can and does. At least, this is my understanding and what I’ve observed by monitoring my ZigBee network traffic.

2 Likes

up to 23 of my 30 switches now in z2m and HA and still no issues once all extra entities disabled

I used this python script to disable most of the entities in HA

I posted an example config for this script on this gist that disables all of the extra entities except for light, update, action, energy, and power.

3 Likes

Mind if I ask, what all do you have adjusted to keep things moving? Do you have just the power turned off in Z2M (the 3 exposes settings and the 2 on the reporting tab set to 1800), and do you have any/all the entities turned off in MQTT?

I have 18 switches and my system is very much not happy. I have the Z2M power settings adjusted, and most but not all entities turned off in MQTT. I plugged in 3 switches a week ago ago and everything zigbee related quit working. I had to airgap half my switches to get Z2M to be responsive and even allow me to open the z2m GUI to adjust the power stuff. I turned all the power settings off, but Z2M still goes unresponsive at times (wont open the gui but automations are still happening, occasionally it quits talking to MQTT and I have to restart)…

@mbrink on the reporting tab, change the min value to 1800 and max to 3600. I haven’t been able to mess with the entities yet. I’m not sure how the software/hardware stack works to know if removing entities works, and I haven’t been able to test it yet. I do know increasing the reporting length on every switch in the reporting tab and on the expose tab disable power reporting and setting high values for everything else in the exposes tab for power/reporting helps.

Not sure if this is related, however, I have Hubitat and it seems binding works and then sometimes in a 4-way switch scenario one of the switches drops out of the binding until it’s air gap is pulled. Happens almost daily.

Zigbee network appears slow. The more switches added, the slower the network appears.

Also when adding new switches, pairing fails many times before finally getting it paired. The network is definitely much less usable the more switches are installed. So either it’s because the switches are flooding the network (maybe like a loop), or routing is still failing on the switches.

I’m thinking this is a firmware issue, maybe its multicasting too much stuff. No idea.

I prefer to alter the min W and kWh change to reduce the amount of messages sent. I’ve seen fluctuations as much as 2.2W on a constant load. I have found 2.5W and 0.1kWh works for me so far.

2 Likes

@Eric_Inovelli @EricM_Inovelli is there going to be some sort of firmware change which modifies these default behaviors? It doesn’t seem prudent to have people need to manually fix all of their switches to stop them from flooding the Zigbee network with aggressive reporting.

1 Like

Which version of z2m are you using? We submitted a PR to fix the issue but maybe it hasn’t hit your system yet?

1 Like

Ran into same problem with the flooding the network. For HA using Z2M, I created a home assistant script Home Assistant Configure Inovelli Blue Script · GitHub to configure all my dimmers.

3 Likes

Nice script!
Need to get better at things like that so I can do it for ZHA…
Thanks for the insight @ajeun !

-Jonathan

After some experimenting, I prefer disabling the values in Z2M rather that in HA. Example Z2M config for disabling all the extra entities: Zigbee2Mqtt Inovelli Config · GitHub

I have 28 switches installed now and am starting to see a slowdown. Going to try to this and see if it helps.

Is there a place we can go to see what each of these mean?

Also, is there a faster way to do this than one by one?

For your code, is it just a matter of copying it and putting it in the z2m configuration.yaml file that I’m currently using in my instance?

You will need to restart Z2M after copying and if you have an existing device_options: section in your configuration.yaml then you will need to merge it.

1 Like

OK so I did this for the 28 switches I’ve installed and I’ve noticed significantly less zigbee network traffic in logs. Also, my devices to seem more responsive.

So the winning combination seems to be disabled most entities (like I showed above) and setting these under the Reporting tab for each switch (wish it wasn’t a one by one process).

Hi group,
Any progress or updates from anyone experiencing this?

I’m trying to build a mesh with ~46 blue switches and about 75 Juno Connect Tunable wafers.
First 30 devices, things go fine. Then slowly I see more and more issues trying to add devices. By the time I’m at 70 devices, I can’t seem to add any additional devices reliably and I get severe network instability through home assistant).

I will say that groups and binding set up as the network is built work flawlessly (leading me to believe a coordinator/traffic issue).

I was having issues with the Sonnoff itead ZBDongle-E version. So I swapped it to the skyconnect usb dongle I have on hand (and tried to rebuild the mesh from scratch). This seems better, but I still have:

  1. Severe issues adding devices as the device count goes up.
  2. Black Box messages in Home assistant that my network has issues. Transmission tried 3x, failed, Network busy

Any input or thoughts. I realize it’s a big mesh, but I would think this should all work.