Zigbee 网络不稳定：诊断 50 个设备

50 台 Zigbee 设备网络诊断与稳定实战案例

在一间拥挤的城市公寓里，塞满了 50 台 Zigbee 设备（灯具、传感器、中继器、窗帘），经典问题接踵而至：30 台设备链路质量差（0–20 分），灯光组延迟 0.5–3 秒，命令丢失，夜间性能恶化，动静传感器事件遗漏。配置包括大量网状路由器，角落里的 WBE2R-R-ZIGBEE v.2 协调器，10 英尺外的 Wi-Fi 路由器，以及邻居的 2.4 GHz 网络。最初，所有设备直连协调器（Permit join = all，z2m v2.5.1），但网状网络未自动均衡。

重建拓扑：从混乱到清晰树状结构

第一步：切换到树状结构——最近的路由器直连协调器，每间房 1–2 台，其他通过它们链式连接。这减轻了协调器的直连和路由表负担，提升了可靠性。z2m 网络图视觉上略有改善，但症状急剧减少。

物理调整（如金属柜门）几乎没效果——链路质量仅提升 1–4 分。

揭开数据处理瓶颈

深入挖掘发现 Wiren Board 控制器 CPU 超载 380–400%，源于 wb-rules 和系统脚本（/usr/share/wb-rules-system/rules/wb-zigbee2mqtt.js）。这阻塞了 MQTT 处理，导致延迟和事件丢失，与链路质量无关。

移除这些脚本后，CPU 负载恢复正常，Node-RED 自动化故障消失。

优化无线信道与硬件

Wi-Fi 扫描显示 1、6、11 信道拥堵。将 Zigbee 切换到 26 信道（2.4 GHz 频段顶部），tx_power 20 dBm，有所帮助——干扰并非主因。

按 Wiren Board 指南更新协调器固件，收益有限，但论坛称必做（备份设置）。

重大升级：换成 Sonoff Dongle Plus E（EFR32MG21），运行在 Raspberry Pi 5 上，Zigbee2MQTT v2.9.2。将协调器置于正中央，信道 11，transmit_power: 127。Pi 上的 Node-RED 处理 MQTT 自动化。

Zigbee2MQTT 配置：

version: 4
mqtt:
  base_topic: zigbee2mqtt
  server: mqtt://localhost:1883
serial:
  port: /dev/ttyUSB0
  adapter: ember
  baudrate: 115200
  rtscts: false
advanced:
  log_level: info
  channel: 11
  network_key: GENERATE
  pan_id: GENERATE
  ext_pan_id: GENERATE
  transmit_power: 127
frontend:
  enabled: true
  port: 8080
  dashboard: false
homeassistant:
  enabled: false

v2.9.2 的网络图超级直观，EFR32MG21 远比 CC2652P 稳定。

关键稳定步骤

• 拓扑：树状结构取代直连协调器。
• 数据处理：丢弃 wb-rules 脚本，迁移到 Pi + Node-RED。
• 硬件：中央放置，Sonoff Dongle E，最新 z2m v2.9.2 固件。
• 无线：信道 26/11，最大 tx_power，Wi-Fi 扫描。
• 监控：跟踪链路质量、CPU 负载、MQTT 日志。

核心经验

• wb-rules 脚本 CPU 超载会掩盖无线问题，伪装成 Zigbee 不稳。
• 协调器放角落导致过多“长跳”网状路径。
• 树状拓扑适合 50 台以上设备，卸载协调器负担。
• EFR32MG21（Sonoff）在拥挤频谱中胜过 CC2652P。
• z2m 2.9.2 + Pi5 突破旧硬件极限。

真正稳定源于拓扑优化、硬件升级与软件瓶颈清除的综合。

— Editorial Team