I have 18 or my 30 Blues installed and linked to z2m and in Home Assistant. In HA, it created 132(!) entities per switch, which is a lot. Of those, most in the “Controls” section are enabled, most in the “Sensors” section are disabled, and only 1 of the 4 in the Diagnostic section is enabled.
I believe having this many entities enabled is creating issues with communication between z2m and HAs MQTT integration. In fact, when I tried to restart the latest time, the MQTT integration took a vey long time to load, and when it did finally load, I could still control the devices but couldn’t read any info. So for example I could turn a light on or off, but the current state of the light would never show.
I went through and disabled all but a few of the entities on all the switches, and everything has been behaving great. Also, on reboots, the MQTT integration loads very fast now. I believe that something has to be changed in how this switch is setup in z2m (or maybe HA?) to state that when added all but a few key entities are disabled, and they can be enabled by users when and if they wish to use them.
I did not change any power reporting settings and still have found great success with these changes I made.
This will show which entities I’ve allowed to stay enabled for all my switches (keep in mind the by default, more than half of all entities for each switch are enabled):
Theres no “quick” way. The best way I found was to go the the Devices of the mqtt integration and select one of your switches. Pick on of the entities you want to disable (i.e. DefaultLed1ColorWhenOn), and then open another window/tab for mqtt integration->Entities. In the search, look for the key part of the entity_id which would apply to all switches, then tap the “check all” checkbox, and then disable.
There are certain entities where it can do more than one at a time, but many can only do that single entity at a time (just for all the switches).
Hope this helps, but its still a process. And I would recommend handling all your current switches before installing more or you’ll run into many more dramatic issues as you add even more to it.
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:
the energy reporting that floods the ZigBee network itself with traffic
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 ?
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.
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.
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.
@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.