홈으로 돌아가기

Zigbee 네트워크가 불안정: 50개 장치 진단

50개 Zigbee 장치 사례에서 불안정은 CPU 과부하, 열악한 토폴로지 및 레거시 코디네이터로 인함. 해결책: 트리 메쉬, wb-rules 스크립트 제거, Sonoff Dongle E와 z2m v2.9.2를 사용한 Raspberry Pi 5로 이전. 안정 작동을 위한 상세 단계 및 설정.

50+ 장치에서 Zigbee 안정화 방법: 사례
Advertisement 728x90

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포인트만 변동.

Google AdInline article slot

데이터 처리 병목 현상 발굴

더 깊이 파고들어보니 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으로 설정하니 약간 개선되었으나, 간섭이 주 원인이 아니었습니다.

Google AdInline article slot

Wiren Board 가이드에 따라 코디네이터 펌웨어 업데이트로 약간의 이득을 봤으나, 포럼에서는 필수라고 합니다(설정 백업 필수).

주요 업그레이드: Raspberry Pi 5에 Sonoff Dongle Plus E (EFR32MG21)를 설치하고 Zigbee2MQTT v2.9.2 실행. 코디네이터를 중앙에 배치, 채널 11, transmit_power: 127. Pi에서 MQTT 기반 자동화를 Node-RED로 처리.

Zigbee2MQTT 설정:

Google AdInline article slot
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

Advertisement 728x90

다음 읽기