Central-hub mode: startup full refresh floods the hub with ~1000 concurrent master/proxy/get, all time out (error 901) — needs throttling/batching

[zealllot]

Describe the Bug / 描述问题

In central hub gateway mode, every Home Assistant startup (and occasionally a spontaneous periodic full refresh) sends ~1005 master/proxy/get requests in one burst to the central hub gateway. The hub cannot answer them in time, so all of them time out (error 901, on mips request timeout), flooding the log with ~1005 ERROR lines per startup and hammering the hub for nothing.

We verified the LAN path is not the problem: TCP handshake from the HA host to the hub's local MQTT port (8883) is 1.1–1.6 ms, 0/20 packet loss. The bottleneck is the hub having to proxy ~1000 property reads to end devices over zigbee/BLE mesh radio — it simply cannot absorb an unthrottled burst of that size.

中文摘要:中枢网关模式下,每次 HA 启动集成会一次性向中枢发约 1005 个 master/proxy/get 全量属性查询,中枢(需经 zigbee/BLE mesh 逐个代理到末端设备)处理不过来,整批 901 超时刷屏。实测 HA 主机到中枢 8883 端口 TCP 握手 1.1–1.6ms 零丢包,网络无辜,是无限流的突发请求超出中枢处理能力。

Home: 291 devices / ~10,800 entities before trimming, 3 central hub gateways (integration binds one of them, xiaomi-gateway-hub1).

On v0.4.2 this also flagged devices unavailable (whole-house churn); v0.4.7's #1579 fixed the flagging — thank you — but the flood itself remains.

How to Reproduce / 复现步骤

1. Large home with central hub gateway mode enabled (hundreds of devices behind one hub).
2. Restart Home Assistant.
3. Watch the log ~10–15 min into startup: a burst of ~1000 901, on mips request timeout, ..., master/proxy/get errors.

Expected Behavior / 预期结果

The full refresh should be throttled/batched — e.g. a concurrency cap or queue on master/proxy/get requests to the hub, spreading the refresh over time instead of a single burst. Failed reads already recover via later retries, so pacing the initial burst should not lose data.

Reproduce Time / 问题复现的时间点

2026-07-23 12:05 (burst right as startup completes; HA restarted 11:51). Also observed spontaneous bursts (e.g. 07:50 same day) without any restart.

Home Assistant Logs / 系统日志

2026-07-23 11:17:39.448 ERROR (8dc6d0530669bad2) [custom_components.xiaomi_home.miot.miot_client] 901, on mips request timeout, 3752910648, master/proxy/get, {"did": "1189446350", "siid": 2, "piid": 1}
2026-07-23 11:17:39.448 ERROR (8dc6d0530669bad2) [custom_components.xiaomi_home.miot.miot_client] 901, on mips request timeout, 3752910649, master/proxy/get, {"did": "2076769630", "siid": 2, "piid": 1}
2026-07-23 11:17:39.449 ERROR (8dc6d0530669bad2) [custom_components.xiaomi_home.miot.miot_client] 901, on mips request timeout, 3752910650, master/proxy/get, {"did": "2079812943", "siid": 2, "piid": 1}
... (~1005 lines per startup; count is stable across restarts: 1005 / 1006 / 1005 / 1005)
2026-07-23 11:17:39.444 WARNING (Thread-1 (_monitor)) [homeassistant.util.logging] Module custom_components.xiaomi_home.miot.miot_client is logging too frequently. 200 messages since last count

Log Timezone / 日志时区

UTC+8 (Asia/Shanghai)

Home Assistant Core Version / Home Assistant Core 版本

2026.1.3

Home Assistant Operation System Version / Home Assistant Operation System 版本

Docker container (host: Debian 12, UGREEN NAS)

Xiaomi Home Integration Version / 米家集成版本

v0.4.7 (also reproduced on v0.4.2)

Additional Context / 其他说明

• Central hub gateway local MQTT reachable at 1.1–1.6 ms TCP handshake, 0/20 loss — measured from the HA host during the issue window, ruling out the network path.
• The burst size (~1005) matches the whole-house property count, suggesting an unthrottled full-property sweep.