Random Delays and Timeouts with Zigbee Shelly Relays

Configuration Zigbee
,
1

I’m having an issue with my smart home Zigbee setup and hoping someone might have suggestions. I’m running Home Assistant in a VirtualBox VM with Zigbee2MQTT and Mosquitto, all on the most current stable versions. My coordinator is an SLZB-06P10 (CC2674P10) connected via Ethernet and placed in a central position. The devices are 44 Shelly 1 Gen 4 relays in Zigbee mode, each controlling an outdoor power point, spread evenly around the coordinator. There are no nearby Wi-Fi access points or other obvious interference sources (the closest is more than 200m away).

The problem I’m facing is that the relays will randomly time out or take a long time to respond. This happens consistently across the entire network, regardless of distance from the coordinator. Even devices close to the coordinator sometimes have the same delays, so it doesn’t appear to be a range issue.

So far, I’ve confirmed that there’s no obvious Zigbee interference, verified the coordinator’s placement, and ensured that all software and firmware are fully up to date. The issue persists whether I control a single relay or several at once.

My questions are: could this be a network scaling issue, with 44 relays being too many for the coordinator to manage on its own? Do Shelly 1 Gen4 devices work reliably as Zigbee routers, or do I need to add dedicated router devices like smart plugs or repeaters to stabilize the mesh? Are there known limitations with the SLZB-06P10 CC2674P10 when handling large device counts, and are there Zigbee2MQTT settings I should be looking at?

Any advice or shared experience would be much appreciated.

Z2M log, 3 different errors:
[2025-09-08 18:29:06] error: z2m: Publish ‘set’ ‘state’ to ‘Campsite 17’ failed: ‘Error: ZCL command 0xccba97fffec4c49c/1 genOnOff.on({}, {“timeout”:10000,“disableResponse”:false,“disableRecovery”:false,“disableDefaultResponse”:false,“direction”:0,“reservedBits”:0,“writeUndiv”:false}) failed (Timeout - 29557 - 1 - 8 - 6 - 11 after 10000ms)’

[2025-09-08 18:33:46] error: z2m: Publish ‘set’ ‘state’ to ‘Campsite 8’ failed: ‘Error: ZCL command 0xa085e3fffec1f7cc/1 genOnOff.off({}, {“timeout”:10000,“disableResponse”:false,“disableRecovery”:false,“disableDefaultResponse”:false,“direction”:0,“reservedBits”:0,“writeUndiv”:false}) failed (–> ‘SREQ: ZDO - extRouteDisc - {“dstAddr”:53518,“options”:0,“radius”:30}’ failed with status ‘(0xc7: NWK_TABLE_FULL)’ (expected ‘(0x00: SUCCESS)’))’

[2025-09-08 18:33:51] error: z2m: Publish ‘set’ ‘state’ to ‘Campsite 16’ failed: ‘Error: ZCL command 0xa085e3fffeb6e6bc/1 genOnOff.off({}, {“timeout”:10000,“disableResponse”:false,“disableRecovery”:false,“disableDefaultResponse”:false,“direction”:0,“reservedBits”:0,“writeUndiv”:false}) failed (Data request failed with error: ‘No network route’ (205))’

2

Hi everyone,

Same problem here. This week I received my first Shelly 2PM Gen4 to test it under Zigbee and I’ve run into the same weird behaviour:

  • If I send several state changes in a row, the first one usually works, but after two or three the relay becomes unresponsive for a few seconds.
  • Then, all the queued commands arrive at once and the light starts toggling quickly.

I’ve already applied the usual checklist (clean 2.4 GHz channel, USB extender for the coordinator, etc.). For comparison, my Aqara T2 works perfectly even with faster bursts of state changes, which makes me think this issue might be related to the Shelly Gen4 firmware and its Zigbee support. Maybe it’s still a bit unstable/immature.

Environment:

  • Shelly 2PM Gen4 with latest firmware as of today → 1.7.1
  • Home Assistant → 2025.9.4 (latest stable)
  • Zigbee2MQTT tested on both stable and edge: 2.6.1-dev (commit 87c474d2)

Has anyone else experienced this? Could this be a firmware issue on Shelly’s side?

Thanks!

3

I’m having the same issue, super laggy on phyiscal switch press and constant restarts. The device is constantly in safe mode too

4

I have experienced similar issues (timeouts) when deploying 17+ Third Reality plugs. Considering I am using a SLZB-MRU4 (CC2674P10), I don’t think it’s a coordinator issue but more down to the smart plug itself. I have over 110+ ZigBee devices and nothing else seems to be having issues.

5

I had similar issues after adding zigbee power relays into my zigbee network, but also upgraded from a SLZB-06M (EFR32MG21) to a SLZB-MR4U (EFR32MG26 or CC2674P10) coordinator around the same time that I added the relays.

I’ve always heard that Texas Instruments (TI) chipsets were the more “proven” brand of chipset (as opposed to the newer Silicon Labs (SI) brand), so I used the TI CC2674P10 chipset as my coordinator when making the switch and repaired all of my zigbee devices to the new chipset.

What I found was the TI chipset constantly encountered issues, which would require a zigbee chipset reset (via the web page GUI) or physical power reset of the SLZB-MR4U at least once a day. After lots of research, I am confident this is not a problem with the coordinator itself, but the TI chipset was being used.

After fighting this problem for a few weeks, I convinced myself I’d need to repair all my zigbee devices again and switch to the SI EFR32MG26 chipset, since my older zigbee coordinator never seemed to experience these issues in my previous zigbee network. Everything now works perfectly.

I can’t say with 100% confidence that switching from TI to SL for your zigbee coordinator will fix your issue, but in my personal experience I have found that “noisy” zigbee devices (or those that send many messages, such as nodes that include energy monitors) to cause instability on TI chipsets, despite this being the opposite of what I was expecting from the “proven” brand of chipsets. The issue caused by noisy zigbee devices may still persist in my network, but SL just seems to be able to manage them much better and remains operational without any perceivable lag.

Hope some of this information helps someone in the future.