zhc:tuya: Failed respond to version response

[u15jtau]

What happened?

Tuya MCU version request fails with timeout errors, e.g.:

zhc:tuya: Failed respond to version response '0xa4c138018b819df8' (Error: ZCL command 0xa4c138018b819df8/1 manuSpecificTuya.mcuVersionRequest({"seq":2}, {"timeout":10000,"disableResponse":false,"disableRecovery":false,"disableDefaultResponse":false,"direction":0,"reservedBits":0,"writeUndiv":false}) failed (Delivery failed for '30694'.))

When the full network (~70 devices, mostly Zemismart ZMS-206US-4 end devices) is powered on, the adapter runs out of buffers:

error 2025-09-10 17:12:19zh:ember:ezsp: The adapter has run out of buffers, causing general malfunction. Remediate network congestion, if present. Last Frame: [FRAME: ID=52:"SEND_UNICAST" Seq=103 Len=10]. - should I log another issue for this? I'm getting several of these after I power on approx 1/3rd of my devices (I turned the power off at the fuse box then powered on 1 at a time with a 3 minute gap). I disabled mqtt in home assistant, reinstalled the firmware, power cycled unbuntu server and adapter and still getting these messages. I think it started when home assistant sent 69 messages at once and it hasn't recovered.

The fix suggested in issue #23874 does not resolve the problem.

With the error "The adapter has run out of buffers," I filtered out the following on configuration.yaml thinking this might have been the cause
mqtt:
base_topic: zigbee2mqtt
server: mqtt://localhost:1883
serial:
port: tcp://x.x.x.x:6638
adapter: ember
baudrate: 115200
rtscts: false
disable_led: false
advanced:
log_level: debug
log_output:
- console
- file
channel: 25
network_key:
- 152
- 113
- 193
- 1
- 102
- 180
- 91
- 170
- 211
- 108
- 10
- 24
- 131
- 201
- 186
- 41
pan_id: 21740
ext_pan_id:
- 72
- 193
- 107
- 141
- 206
- 8
- 1
- 37
queue_rate_limit: 5
cache_state: true
last_seen: ISO_8601
elapsed: true
transmit_power: 13
network_key_distribute: true
frontend:
enabled: true
port: 8080
homeassistant:
enabled: true
external_converters:

• ext_converter.js
  device_options:
  debounce: 5
  throttle: 60
  filtered_attributes:
  • backlight_brightness
  • backlight_mode
  • child_lock
  • countdown_l1
  • countdown_l2
  • countdown_l3
  • countdown_l4
  • delay_off_schedule
  • indicator_status
  • last_seen
  • linkquality
  • voltage
  • name_l1
  • name_l2
  • name_l3
  • name_l4
  • relay_status_l1
  • relay_status_l2
  • relay_status_l3
  • relay_status_l4
  • state
  • state_l1
  • state_l2
  • state_l3
  • state_l4
  • switch_color_off
  • switch_color_on
  • linkquality
  • voltage
  • current
  • power
  • energy
  • illuminance
  • illuminance_average_20min
  • illuminance_maximum_today
  • elapsed
  • battery
  • battery_low
  • countdown
  • indicator_mode
  • power_outage_memory
  • update
  • detection_delay
  • fading_time
  • maximum_range
  • minimum_range
  • radar_sensitivity
  • target_distance
  • cleaning_reminder

What did you expect to happen?

The Tuya MCU version requests should succeed, and the EZSP adapter should handle the network without buffer exhaustion, even with all devices powered on.

How to reproduce it (minimal and precise)

Set up a Zigbee network with approximately 70 devices, about 60 of which are Zemismart ZMS-206US-4 end devices.

Use the SLZB-MR4 (EFR32MG26) coordinator with firmware 20240602 connected via Ethernet.

Power on all devices and observe logs.

Use zigbee2mqtt dev branch.

Zigbee2MQTT version

2.6.1-dev

Adapter firmware version

20240602

Adapter

SLZB-MR4 (EFR32MG26) connected via Ethernet.

Setup

Intel NUC with proxmox and unbuntu server running both zigbee2mqtt and mqtt broker

Device database.db entry

{"id":3,"type":"Router","ieeeAddr":"0xa4c138a59041fb58","nwkAddr":1506,"manufId":4417,"manufName":"_TZE204_wwaeqnrf","powerSource":"Mains (single phase)","modelId":"TS0601","epList":[1,242],"endpoints":{"1":{"profId":260,"epId":1,"devId":81,"inClusterList":[4,5,61184,0],"outClusterList":[25,10],"clusters":{"genBasic":{"attributes":{"65503":"\u0016\u0000\u0000\u0000i\u0016\u0000\u0000\u0000i\u0017\u0000\u0000\u0000i\u000f\u0000\u0000\u0000i\u000f\u0000\u0000\u0000i\u000f\u0000\u0000\u0000i\u0010\u0000\u0000\u0000i\u0010\u0000\u0000\u0000i\u0011\u0000\u0000\u0000i\u0011\u0000\u0000\u0000i\u0011\u0000\u0000\u0000i\u0012\u0000\u0000\u0000i","65506":56,"65508":0,"65534":0,"modelId":"TS0601","manufacturerName":"_TZE204_wwaeqnrf","powerSource":1,"zclVersion":3,"appVersion":74,"stackVersion":0,"hwVersion":1,"dateCode":""}}},"binds":[],"configuredReportings":[],"meta":{}},"242":{"profId":41440,"epId":242,"devId":97,"inClusterList":[],"outClusterList":[33],"clusters":{},"binds":[],"configuredReportings":[],"meta":{}}},"appVersion":74,"stackVersion":0,"hwVersion":1,"dateCode":"","zclVersion":3,"interviewCompleted":true,"interviewState":"SUCCESSFUL","meta":{"configured":332242049},"lastSeen":1757489653487}

Debug log

Example devices
0xa4c13864c184120c
database.db entry
{"id":112,"type":"Router","ieeeAddr":"0xa4c13864c184120c","nwkAddr":8152,"manufId":4417,"manufName":"_TZE204_wwaeqnrf","powerSource":"Mains (single phase)","modelId":"TS0601","epList":[1,242],"endpoints":{"1":{"profId":260,"epId":1,"devId":81,"inClusterList":[4,5,61184,0],"outClusterList":[25,10],"clusters":{"genBasic":{"attributes":{"65503":"\u0003\u0000\u0000\u0000i\u0004\u0000\u0000\u0000i\u0004\u0000\u0000\u0000i\u0004\u0000\u0000\u0000i\r\u0000\u0000\u0000i\r\u0000\u0000\u0000i\r\u0000\u0000\u0000i\u000f\u0000\u0000\u0000i\u000f\u0000\u0000\u0000i\u000f\u0000\u0000\u0000i\u0010\u0000\u0000\u0000i\u0010\u0000\u0000\u0000i","65506":56,"65508":0,"65534":0,"stackVersion":0,"dateCode":"","manufacturerName":"_TZE204_wwaeqnrf","zclVersion":3,"appVersion":74,"modelId":"TS0601","powerSource":1}}},"binds":[],"configuredReportings":[],"meta":{}},"242":{"profId":41440,"epId":242,"devId":97,"inClusterList":[],"outClusterList":[33],"clusters":{},"binds":[],"configuredReportings":[],"meta":{}}},"appVersion":74,"stackVersion":0,"hwVersion":1,"dateCode":"","zclVersion":3,"interviewCompleted":true,"interviewState":"SUCCESSFUL","meta":{"configured":332242049},"lastSeen":1757489653542}

0xa4c138a59041fb58
database.db entry
{"id":3,"type":"Router","ieeeAddr":"0xa4c138a59041fb58","nwkAddr":1506,"manufId":4417,"manufName":"_TZE204_wwaeqnrf","powerSource":"Mains (single phase)","modelId":"TS0601","epList":[1,242],"endpoints":{"1":{"profId":260,"epId":1,"devId":81,"inClusterList":[4,5,61184,0],"outClusterList":[25,10],"clusters":{"genBasic":{"attributes":{"65503":"\u0016\u0000\u0000\u0000i\u0016\u0000\u0000\u0000i\u0017\u0000\u0000\u0000i\u000f\u0000\u0000\u0000i\u000f\u0000\u0000\u0000i\u000f\u0000\u0000\u0000i\u0010\u0000\u0000\u0000i\u0010\u0000\u0000\u0000i\u0011\u0000\u0000\u0000i\u0011\u0000\u0000\u0000i\u0011\u0000\u0000\u0000i\u0012\u0000\u0000\u0000i","65506":56,"65508":0,"65534":0,"modelId":"TS0601","manufacturerName":"_TZE204_wwaeqnrf","powerSource":1,"zclVersion":3,"appVersion":74,"stackVersion":0,"hwVersion":1,"dateCode":""}}},"binds":[],"configuredReportings":[],"meta":{}},"242":{"profId":41440,"epId":242,"devId":97,"inClusterList":[],"outClusterList":[33],"clusters":{},"binds":[],"configuredReportings":[],"meta":{}}},"appVersion":74,"stackVersion":0,"hwVersion":1,"dateCode":"","zclVersion":3,"interviewCompleted":true,"interviewState":"SUCCESSFUL","meta":{"configured":332242049},"lastSeen":1757489653487}

log.log

[Koenkk]

Fixed!

Changes will be available in the dev branch in a few hours from now and in the next release which is every 1st of the month.

[GiladShoham]

Thanks, the fix worked for me @Koenkk

[warrenarnold]

Persistent commandMcuSyncTime spam from Tuya 4-gang switches causes congestion and BUFFER_FULL

Hi @Koenkk,

I’m experiencing a persistent issue with multiple Tuya TS0601 (_TZE204_08qc13ct and similar) 4-gang wall switches.
They continuously spam commandMcuSyncTime requests, which appears to overwhelm the coordinator and contribute to frequent BUFFER_FULL and route errors.

---

Environment

• Zigbee2MQTT version: 2.6.2 (latest Home Assistant addon)
• Coordinator hardware tested:
  • Sonoff Zigbee 3.0 Dongle-P (ZStack3x0 20250321 firmware)
  • Nabu Casa SkyConnect (Silicon Labs, EmberZNet 7.4.2.0)
• Host: Home Assistant Green
• Network size: ~79 devices (majority Tuya wall switches acting as routers)
• Config tweaks tried:
  • adapter_delay tested 132–1000ms
  • adapter_concurrent tested 1–5
  • disable_concentrator: true/false
  • transmit_power adjustments

---

Symptoms

• Logs flood with commandMcuSyncTime events across nearly all switches.
• Coordinator quickly hits BUFFER_FULL.
• Device commands delayed or dropped.
• Route errors fill logs (ROUTE_ERROR_MANY_TO_ONE_ROUTE_FAILURE, ROUTE_ERROR_SOURCE_ROUTE_FAILURE).

---

Sample Logs

[2025-10-04 16:56:47] debug: z2m: Received Zigbee message from 'Switch_GF_Kitchen', type 'commandMcuSyncTime', cluster 'manuSpecificTuya', data '{"payloadSize":234}'
[2025-10-04 16:56:47] debug: z2m: Received Zigbee message from 'Switch_GF_Frontdoor', type 'commandMcuSyncTime', cluster 'manuSpecificTuya', data '{"payloadSize":235}'
[2025-10-04 16:56:47] debug: z2m: Received Zigbee message from 'Switch_UF_Master', type 'commandMcuSyncTime', cluster 'manuSpecificTuya', data '{"payloadSize":233}'

Even when suppressing via custom converter:

[2025-10-05 16:04:30] debug: [TUYA SPAM BLOCK] Suppressing commandMcuSyncTime from 0xa4c138a71122f30c
[2025-10-05 16:04:30] debug: [TUYA SPAM BLOCK] Suppressing commandMcuSyncTime from 0xa4c1389091e763b3

And shortly after, route errors begin:

[2025-10-05 19:45:47] info: zh:ember:ezsp: Received network/route error ROUTE_ERROR_MANY_TO_ONE_ROUTE_FAILURE for "30534"
[2025-10-05 19:45:47] info: zh:ember:ezsp: Received network/route error ROUTE_ERROR_SOURCE_ROUTE_FAILURE for "40299"

---

Attempts so far

• Disabled all external converters → issue persists.
• Tried both Sonoff and SkyConnect coordinators → same behaviour.
• Power-cycled entire house (to clear routes) → spam resumes on boot.
• Lowered concurrency to 1–2 → still fails once devices resume time sync.

---

Request

Would it be possible to handle this at converter/core level?
Perhaps by:

1. Responding once at startup, then ignoring repeated syncs, OR
2. Allowing suppression of time-sync requests unless explicitly enabled (similar to OTA polling).

At the moment the devices seem never satisfied with the time response and keep hammering the network, which makes the entire mesh unreliable.

Any guidance or patch would be hugely appreciated.
Thanks again for all your amazing work on Zigbee2MQTT!

[Koenkk]

_TZE204_08qc13ct is not an officially supported device, so please submit a PR in case you have an ext converter.

Could you make a PR by clicking here?

Setting timeStart: off will disable the response (example) but we cannot prevent the device from sending the time request.

[warrenarnold]

_TZE204_08qc13ct is not an officially supported device, so please submit a PR in case you have an ext converter.

Could you make a PR by clicking here?

Setting timeStart: off will disable the response (example) but we cannot prevent the device from sending the time request.

Thanks for your response

My apologies I got the wrong device codes

I am using:
3 gang: _TZE204_k7v0eqke, TZ3000_qewo8dlz
4 gang: _TZE204_wwaeqnrf, _TZE284_wwaeqnrf

I believe, these are supported out of the box since the recent releases, they are now working with my original converters removed, but have this time request spam.

Is there a way to set timeStart off on these?

[Koenkk]

Maybe we should actually respond to these messages? (because otherwise they device may keep asking for it?) Try with timeStart: "2000"