Saltar a contenido

Bluetooth Low Energy (BLE)

Cuarto protocolo de facto del smart home (junto a Zigbee, Matter/Thread, WiFi). Battery life excelente, range muy corto (~5-10m con paredes). Se compensa el range con ESPHome Bluetooth Proxies distribuidos — boards ESP32 baratos en cada cuarto que actúan como antenas remotas hacia HA. Es el protocolo de retrofit (SwitchBot Bot/Curtain/Lock) y de devices nicho (sensores Xiaomi/Govee, fitness, beacons).

Contexto

Falta documentado en el CLAUDE.md del proyecto: "Devices: Zigbee, BLE, WiFi". BLE estaba implícito pero sin página propia. Esta página la corrige. Para el setup del usuario, BLE es el cuarto wheel — útil para devices que Zigbee no cubre, pero no debería ser primario en essentials por latencia y range.

Contenido

Stack

  • Radio: 2.4 GHz, distinta de IEEE 802.15.4 (que es la base de Zigbee/Thread).
  • Modelo: advertisements (broadcasts) + connect-on-demand. La mayoría de sensores broadcastean state sin necesitar conexión activa.
  • Range típico: 5-10m con paredes. Mucho menos que Zigbee/WiFi.
  • Battery: superior a casi todo — años en sleepy devices que sólo broadcastean.

Integración con HA

Tres modos:

  1. HA Bluetooth integration con adapter local (en el Yellow o en el host de HA Container): cubre devices cercanos al hub. Limitado por range — sólo devices en la misma habitación o adyacente.
  2. ESPHome Bluetooth Proxy (recomendado): boards ESP32 baratos ($5-10) corriendo firmware ESPHome con la component bluetooth_proxy. Se distribuyen por la casa, escuchan BLE local, mandan los datos a HA vía WiFi. Solución estándar 2026 para extender cobertura BLE.
  3. Vendor-specific hubs (SwitchBot Hub 2+, Xiaomi Gateway, etc.): bridge BLE → WiFi/Ethernet. Local-first si el hub tiene LAN API (verificar por modelo).

Patrón canónico: BLE proxies distribuidos

HA (Yellow / Container)
   │ WiFi
   ├─── ESPHome BLE Proxy [living room]
   │       ↕ BLE
   │       SwitchBot Curtain, Xiaomi sensor, ...
   │
   ├─── ESPHome BLE Proxy [cocina]
   │       ↕ BLE
   │       Govee thermometer, SwitchBot Bot, ...
   │
   └─── ESPHome BLE Proxy [dormitorio]
           ↕ BLE
           Xiaomi sensor, SwitchBot Lock, ...

Costo: ~$5-15 por proxy × 2-4 proxies en una casa típica = $20-60 total.

Beneficio: cobertura completa + redundancia (si un proxy cae, los devices se siguen viendo desde otro adyacente si hay overlap).

BLE vs Zigbee — cuándo cada uno

Dimensión BLE Zigbee
Range per device 5-10m 30-100m con mesh routing
Mesh routing No Sí
Battery (sleepy device) Excelente Muy buena
Latencia (apretar botón) 1-3 segundos típicamente < 500ms
Devices retrofit (Bot, Curtain) Sí — único No (no hay equivalente)
Ecosistema sensores temp/hum OK (Xiaomi, Govee) Mejor (Aqara, IKEA, etc.)
Cobertura proxy required Sí (ESPHome proxies) No (basta coordinator + mesh)
Para essentials (luces, locks) No ideal Sí

BLE vs WiFi (devices alimentados)

WiFi gana en throughput y range pero pierde en battery — por eso para sensors battery-powered, BLE es mejor que WiFi. Los devices WiFi son típicamente line-powered (cámaras, ESPHome boards, plugs).

Failure modes específicos de BLE

A registrar en el catálogo:

  1. Proxy ESPHome cae → devices que sólo eran visibles desde ese proxy desaparecen de HA. Síntoma: entities "unavailable" en cluster por habitación.
  2. Interferencia 2.4 GHz: WiFi + Zigbee + BLE comparten banda. Saturación = packets perdidos. Mitigación: WiFi en 5 GHz para todo non-IoT.
  3. Re-pairing tras factory reset del device: BLE no preserva binding como Zigbee. Si re-pareas, puede aparecer como entity nueva — confusión de entity_id histórico.
  4. Devices con encryption rotativa (algunos Xiaomi nuevos): requieren extraer bind keys vía app; sin ese paso, el device no decodifica.

Relaciones

  • Complementario de: zigbee (mejor para retrofit y devices nicho), matter (BLE usado sólo para commissioning).
  • Implementación principal en HA: ESPHome Bluetooth Proxy (gap: página propia por crear).
  • Vendor primario en BLE: switchbot (también IKEA, Xiaomi, Govee, Aqara FP200).
  • Documentado en: ../analysis/sensor-recommendations-2026 (categoría "lo que sí, lo que no").

Citas / evidencia

  • Patrón "ESPHome Bluetooth Proxies" es estándar de facto 2026 en HA community (sin source ingerido todavía; gap registrado).

Abierto / gaps

  • Ingerir docs de ESPHome bluetooth_proxy component como source canónico.
  • Catalogar failure modes de BLE propiamente (los 4 de arriba son seed).
  • Mapping de coverage: cuántos proxies necesita una casa típica de N m² y M habitaciones.
  • Devices BLE con encryption rotativa (Xiaomi nuevos): patrón de extracción de keys via Mi Home / Xiaomi Bluetooth Mesh.
  • ¿El HA Yellow tiene Bluetooth radio built-in? (sí, vía el ZBT-1 que soporta Zigbee + BT + Thread). Documentar cómo se habilita.