50대 Zigbee 네트워크 진단 및 안정화: 실제 사례 연구
도시의 좁은 아파트에 조명, 센서, 릴레이, 블라인드 등 50개의 Zigbee 기기가 빽빽하게 들어차면서 전형적인 문제가 발생했습니다: 20~30개 기기에서 링크 품질이 0~20으로 낮음, 조명 그룹 지연(0.5~3초), 명령어 손실, 밤에 성능 저하, 모션 센서 이벤트 누락. 구성은 메쉬 라우터가 많았고, 모서리에 WBE2R-R-ZIGBEE v.2 코디네이터, 3m 거리의 Wi-Fi 라우터, 주변 2.4GHz 네트워크가 있었습니다. 처음에는 모든 기기가 직접 연결(Permit join = all, z2m v2.5.1)되었지만, 메쉬가 자동으로 균형을 맞추지 못했습니다.
토폴로지 재구축: 혼란에서 깔끔한 트리 구조로
첫 번째 단계: 트리 구조로 전환—가장 가까운 라우터를 코디네이터에 직접 연결, 방당 1~2개, 나머지는 이를 통해 체인 연결. 이렇게 코디네이터의 직접 연결과 라우팅 테이블 부하를 줄여 신뢰성을 높였습니다. z2m 네트워크 맵에서 시각적으로 개선이 보였고, 증상이 급격히 줄었습니다.
물리적 조정(예: 금속 캐비닛 문)은 거의 효과가 없었습니다—링크 품질이 1~4포인트만 변동.
데이터 처리 병목 현상 발굴
더 깊이 파고들어보니 Wiren Board 컨트롤러의 CPU가 wb-rules와 시스템 스크립트(/usr/share/wb-rules-system/rules/wb-zigbee2mqtt.js)로 380~400% 과부하 상태였습니다. 이로 MQTT 처리가 막히면서 링크 품질과 무관하게 지연과 이벤트 손실이 발생했습니다.
이 스크립트를 제거하니 CPU 부하가 정상화되고 Node-RED 자동화의 결함이 해결되었습니다.
무선 채널 및 하드웨어 최적화
Wi-Fi 스캔 결과 채널 1, 6, 11이 혼잡했습니다. Zigbee를 2.4GHz 대역 상단 채널 26으로 전환하고 tx_power 20dBm으로 설정하니 약간 개선되었으나, 간섭이 주 원인이 아니었습니다.
Wiren Board 가이드에 따라 코디네이터 펌웨어 업데이트로 약간의 이득을 봤으나, 포럼에서는 필수라고 합니다(설정 백업 필수).
주요 업그레이드: Raspberry Pi 5에 Sonoff Dongle Plus E (EFR32MG21)를 설치하고 Zigbee2MQTT v2.9.2 실행. 코디네이터를 중앙에 배치, 채널 11, transmit_power: 127. Pi에서 MQTT 기반 자동화를 Node-RED로 처리.
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
아직 댓글이 없습니다.