Recently, I started seeing intermittent delays in my home. E.g. when I click a Zigbee remote, it takes a few seconds before the light turns on. Same for motion sensors. What stands out is that the delay is not always present and the duration is random. Sometimes the light goes on or off immediately, like it always has. Sometimes there’s a small delay of less than a second. And sometimes it takes mutliple seconds, up to tens of seconds.
I have been making changes to my setup, recently, so it can very well be that one of those changes caused this. However, undoing those changes one by one to triage the problem is not an option.
So, I was wondering, is there any way I can study delays in Home Assistant? Is there a way I can trace an event from the button press until the turning on of the bulb? I hope to be able to find the cause of the delay and mitigate it.
I recently switched from ZHA to Z2M. One of the differences I noticed is that Z2M seems to never drop an event. With ZHA sometimes an event just didn’t succeed, with Z2M it seems an event will always be delivered eventually, even if the delay is huge.
Check the Z2M logs. Typically this error is due to poor coverage or interference. You have done the usual steps (coordinator on an extension cord and so on)?
I see you changed the topic title. However, I’m not really sure yet it’s a Z2M issue. It could be, but I also have Shelly devices and I see delays with them too. (However, it can still be a Z2M-only issue: I have no single lamp that has no Zigbee, but some of my switches use Shelly’s.)
W.r.t. the Z2M logs. I did tail -f on /root/config/zigbee2mqtt/log/2025-01-07.09-48-26/log.log. The output was quite overwhelming! Do you have some tips for me on how to digest these logs? It seems the level is set to debug at the moment. Is that useful? Should I increase the level to make it more manageable? What’s the best way to filter specific devices? Any tips would be highly appreciated!
I changed the title from “intermittent delays” to the current title, you did not mention with a single word that this was not only related to Zigbee2MQTT until now.
What hardware are you running on? And did you look at my previous post?
As said, I checked the logs but found those to be a bit intimidating and did not know where to start. If you have any tips in that regard, I’d be very grateful.
I’ve installed a SLZB-06 in a location that is far away from any source of interference.
Not all corners of my house have a good direct connection to the SLZB-06, but via one or two hops in the mesh network, all devices should be reachable. My network map confirms that.
I’m using mqtt intensively either for z2m or for integration of wifi Shelly devices.
I can confirm that I also experience
a lag from time to time. very rarely though.
It happens for wifi devices too (ie when turning off all lights with single click I can experience a few secs delay).
So I would say it might be an issue with mqtt or how HA handles it. It might appear more after HA restart. but I didn’t debugged it yet since it’s occurrence is very sporadic
An update after just waiting a couple of more days. It seems to me that I got less and shorter delays over time. So maybe this effect was just the new Zigbee network needing some time to “settle”. I’ll keep an eye on it and post here if anything notable happens.
When I moved 100+ devices from Deconz to Zigbee2MQTT I experienced small delays as well as remote controls that only reacted the 2nd time I pressed a button.
It is pretty normal that a Zigbee network has to self heal after major updates.
And never ever have router devices like bulbs being powered on and off. Everytime a router is turned off, a number of clients need to find a new route. And some battery powered devices will not do that until you press the button a couple of times. Some Aqara are know to never find a new route from the one it got paired to.
I believe I remember the same when I moved from Philips Hue to Deconz.
I have also had some early IKEA lightbulbs that were terrible routers and made other devices slow or disconnect. No firmware upgrade available - so I smashed them and bought new. Same with 8 Osram smartplugs. They sucked in Philips Hue. They sucked in Deconz. And now they suck in a landfill or were recycled into plastic bags. It can be hard to identify these devices that just suck because of bad firmware. And surely bad routers will cause delays.
My personal suggestion is to disable debug logging and set it back to info level.
Monitor for a couple of days and report back. If your MQTT broker is being overwhelmed by all the debug messages, that would explain why also your Shellies are affected. Debug is only meant to be used for short periods for…debugging.
But if you notice that a device is sluggish or does not react, try and use the mapping feature to see how it is routed. It can either be the device itself or a router that causes a problem. If the router is far away you can try and re-pair the device while enabling permit join only for 1 router near it. You may have to disconnect it and reconnect it to make it change its preferred route.
Philips Hue devices are usually among the best routers. Old IKEA with old firmware can be picky. Osram smart plugs are dumb plugs. Aqara battery device really need to be paired to a single good router. I discovered my old Ikea bulb was a poor router because lights in my living room were often not responding, and always with the Ikea bulb as their “mate”. Swapping that Ikea bulb with a Hue fixed it. It was one of the early that could not chane from warm to cold white. So I tossed it in the bin. I have excellent experience with the Hue smart plugs. Modern Ikea lights with updated firmware are good too.
The Philips Hue 4-button switches take their time to find a good router. They can be tricked to reconnect by holding all 4 buttons for many seconds until the LED flashes red and green. Repeat if needed.
Note that Aqara window/door sensors have excellent battery life… until they loose their router. Then they scream “mama” till the battery is dead while often still saying 100% battery. If you hold the pairing button to re-connect they flash red but the minute it transmits on its radio it dies and never connects… Cure is new battery and reconnect with permit join just for a single router near it.
Last. A zigbee device can be acting bad because of RF interference. You hopefully know to put a 1-2 meter USB extention cable for the coordinator to move it away from the computer. Think the same with zigbee devices. If some electronic device with high speed circuits is near, you can get interference. Move them away from each other. Even 50 cms can make a difference. If a lamp is right next to something with wifi, move them apart. It may be a router device that is disturbed that causes another device to be unstable.
And again. Most devices find a better partner to route through simply by waiting a day and using the network.
Last. Always create groups in Zigbee2MQTT and control these in your HA automations. Do not use HA groups for this. If you mix wifi devices with Zigbee then you can use HA groups in which you add the zigbee group. Zigbee groups are controlled by a single message. HA groups sends a message to each bulb causing massiv traffic on the zigbee network
Thanks for the elaborate answer, this is very helpful! As said, I’m already experiencing that my Zigbee network is becoming more stable now. However, I still have a few problematic devices, and this is very helpful in trying to resolve that.
Regarding this:
You may have to disconnect it and reconnect it to make it change its preferred route.
Am I right that battery powered end-devices only connect to one router and that routers can have multiple routes? At least, this is what I deduce from looking at the network map in Z2M: routers have routes to “siblings”, but end devices only have one route to their “parent”.
If I use “permit join” to a specific device, and (re)join a battery device, is it guaranteed to stay using that route? I noticed one of my battery devices changed it’s route and now is performing poorly. Apart from the permit join option, are there other way to force a device to take a specific route?