M5 Atom Lite 및 WIZnet W5500(ATOM PoE)을 사용한 Home-Assistant 블루투스 프록시
이 프로젝트는 M5Stack Atom Lite와 **WIZnet AtomPoE (W5500 이더넷 확장)**를 사용해 ESPHome 기반 BLE 프록시 노드를 구성하고,
이를 Home Assistant + Bermuda BLE 환경에서 안정적으로 동작시키는 방법을 정리한 가이드입니다.
프로젝트 개요
이 프로젝트는 M5Stack Atom Lite와 **WIZnet AtomPoE (W5500 이더넷 확장)**를 사용해 ESPHome 기반 BLE 프록시 노드를 구성하고,
이를 Home Assistant + Bermuda BLE 환경에서 안정적으로 동작시키는 방법을 정리한 가이드입니다.
기존 커뮤니티 자료(예: Reddit)에서는 PoE/W5500 조합이 잘 정리되어 있지 않아,
설정 오류, Wi-Fi/Ethernet 충돌, BLE 스택 과부하 등으로 불안정하게 동작하는 사례가 많았습니다.
이 프로젝트는 그런 문제들의 원인과 안정적인 설정/운영 방법을 포함합니다.
구성요소
| 항목 | 설명 |
|---|---|
| MCU | M5Stack Atom Lite (ESP32 기반 BLE + 사용자 로직) |
| PoE/Ethernet 확장 | AtomPoE 모듈 + WIZnet W5500 (하드웨어 TCP/IP) WIZnet Makers |
| 펌웨어/통합 | ESPHome (ESP32 BLE 프록시 + Ethernet) |
| 스마트홈 백엔드 | Home Assistant + esp_home 통합 |
| Presence/위치 | Bermuda BLE (다중 BLE 프록시 수집 기반) |
🔍 왜 이 조합이 어려웠나?
❗ 1) Wi-Fi + Ethernet의 공존 문제
ESPHome은 원래 Wi-Fi 중심으로 설계되어 있어,
Wi-Fi와 Ethernet 설정이 동시에 들어가는 예제가 많습니다.
하지만 실전에서는 Wi-Fi + Ethernet 동시 사용은 안정적으로 동작하지 않습니다.
PoE/W5500 노드에서는 반드시 wifi: 블록을 제거하고 ethernet:만 사용해야 합니다. esphome.io
⚠ 2) ESPHome BLE 스택의 리소스 요구
ESPHome BLE Proxy는 ESP32 BLE 스택과 함께 상당한 RAM/CPU를 소비합니다.
이 BLE 작업과 다른 기능(특히 네트워크/ISR/ESPHome API)이 충돌하면,
간헐적 끊김, API 타임아웃, 스캔 정지 같은 불안정 증상이 발생할 수 있습니다. esphome.io
⚠ 3) 인터럽트 기반 Ethernet (W5500) 문제
ESPHome 기본 W5500 지원은 인터럽트(IRQ) 기반 처리가 기본입니다.
하지만 BLE Proxy 및 ESPHome의 다른 작업 스케줄링과 경쟁하면
IRQ 지연/누락 현상이 발생, TCP 연결 타임아웃, 끊김, watchdog 리셋 같은 문제가 생길 수 있습니다.
이런 이유로 polling 방식(polling_interval)을 사용하는 설정이,
실전 환경에서는 훨씬 안정적인 동작을 보입니다.
📌 안정적인 설정/운영 요약
다음은 이 프로젝트에서 권장하는 필수/운영 설정 포인트입니다.
✔ ESPHome 설정 기준
• Wi-Fi 제거 → Ethernet 전용
W5500 인터럽트/폴링 구성을 명확히 함
polling_interval 설정으로 IRQ 유실/지연의 영향을 최소화
→ BLE/인터럽트 경쟁 환경에서 실제 안정성 확보
✔ BLE Proxy 설정
BLE Proxy는 Home Assistant가 주변 BLE 광고를 수신하게 함
스캔 파라미터는 BLE 성능/CPU 점유율에 영향을 줌 esphome.io
✔ Home Assistant + Bermuda
여러 AtomPoE/W5500 BLE Proxy 노드를 배치하면
Bermuda는 RSSI를 기준으로 Room-level Presence가 가능해짐
💡 왜 polling_interval을 쓰는가?
ESPHome에서 polling_interval은 인터럽트 대신 주기적 상태 확인을 강제하는 옵션입니다.
인터럽트는 이론적으로 효율적이지만
BLE Proxy 등 CPU 점유율이 큰 작업과 경쟁할 때 지연/유실이 발생
polling_interval은 이를 방지해서 실제 운영 안정성을 올립니다
즉,
사용자의 환경에서 CPU 경쟁/IRQ 경쟁이 발생하면
polling 방식이 더 안정적으로 동작하는 선택지입니다.
이런 안정성 개선 포인트는 단순 예제만 소개하는 커뮤니티 자료에서는 잘 다뤄지지 않습니다.
🧪 흔한 증상과 해결 포인트
| 증상 | 원인 | 해결 |
|---|---|---|
| BLE Proxy 동작 중간에 끊김 | IRQ/CPU 경쟁 | polling_interval: 10ms |
| Home Assistant API 타임아웃 | Ethernet IRQ 유실 | polling/esp-idf |
| BLE 데이터 누락 | 스캔 파라미터 부적합 | interval/window 조정 |
| 노드가 HA에서 장치가 다르게 보임 | MAC 변화 | HA 재등록 |
📌 기타 팁
사용 권장 환경: PoE 전원 공급이 가능한 유선 설치
BLE 리시버 배치: 물리적으로 BLE 센서 근처에 설치
Bermuda 최적화: ESS scan parameter 튜닝으로 RSSI 품질 향상 GitHub
📌 부록: WIZnet W5500 소개
W5500은 하드웨어 TCP/IP 이더넷 컨트롤러로 MAC/PHY와 TCP/IP 오프로드를 내장해 ISP 없이도 안정적인 유선 통신을 구현합니다. (주)위즈네트
📌 결론
이 프로젝트는 단순히 “AtomPoE/W5500이 Home Assistant에 붙는다”는 수준을 넘어서,
실제로 안정적으로 동작하는 설정/운영 방법을 공개하는 레퍼런스입니다.
ESPHome의 기본 예제와 달리
→ Wi-Fi/Ethernet 혼합 제거
→ polling 방식으로 안정성 개선
→ BLE 스택 충돌 예방
→ Bermuda Presence 지원
이걸 그대로 따라하면 PoE/W5500 BLE Proxy 노드를 처음부터 끝까지 안정적으로 구성할 수 있습니다.