Patrón: ESPHome BLE Proxies distribuidos¶
Patrón de antenas distribuidas para extender el range BLE de HA. Boards ESP32 baratos (~$5-30 c/u) corriendo firmware ESPHome con el component
bluetooth_proxy, distribuidos por la casa. HA recibe data de devices BLE sin importar dónde estén físicamente.
Contexto¶
BLE tiene range corto (~5-10m con paredes). Sin proxies, HA solo ve devices BLE cercanos al adapter del host. Con proxies distribuidos, cualquier device BLE en la casa es accesible a HA — incluyendo SwitchBot Bot, sensores Xiaomi, Govee thermometers, etc.
Cuándo aplica¶
- Tenés devices BLE distribuidos en la casa.
- O querés agregar devices BLE futuros (sensors temp baratos, SwitchBot retrofit).
- Tu hub HA (Yellow / mini-PC) no llega físicamente a todos los cuartos.
Cuándo NO aplica¶
- Todo tu BLE está en una habitación cerca del hub → el adapter built-in alcanza.
- No tenés devices BLE (solo Zigbee + WiFi) → no necesitás esto.
Implementación¶
Step 1 — Elegir hardware¶
| Tier | Board | Slots | Cost |
|---|---|---|---|
| Premium | Olimex ESP32-PoE-ISO | 4 ethernet | ~$30 |
| Standard | ESP32 dev board (cualquier flavor) | 3 WiFi | ~$5-10 |
| Compacto con display | M5StickC Plus2 | 3 WiFi | ~$15-20 |
3-4 boards alcanzan para casa típica (100-150m²).
Step 2 — Config ESPHome¶
Por cada board (en el repo git, bajo esphome/ble-proxy-living.yaml, etc.):
substitutions:
name: ble-proxy-living # cambia por board
esphome:
name: ${name}
esp32:
variant: esp32
framework:
type: esp-idf
wifi:
ssid: !secret wifi_ssid
password: !secret wifi_password
logger:
api:
ota:
platform: esphome
esp32_ble_tracker:
bluetooth_proxy:
active: true
Step 3 — Flash inicial¶
Conectar por USB la primera vez. Después updates van vía OTA.
Step 4 — HA discovery¶
HA descubre el ESPHome device automáticamente (mDNS). Settings → Devices & Services → ESPHome → Configure.
Tras agregar, HA "Bluetooth integration" automáticamente usa este proxy como otro adapter.
Step 5 — Placement¶
- Centro de cuarto mejor que esquina.
- Lejos de routers/switches (≥3m según docs).
- Cobertura overlapping: 2 proxies cuyos rangos se superponen = redundancia ante crash de uno.
- No en racks ni cerca de microondas / baby monitors.
Step 6 — Validate¶
En HA Developer Tools → States, buscar entities BLE conocidas (ej. Xiaomi sensor). Last_updated debería actualizar.
Logs ESPHome (vía API o esphome logs): ver "Found device" messages cuando un device BLE entra en range.
Trade-offs¶
| Pro | Con |
|---|---|
| Cobertura BLE full casa por <$30/cuarto | Adds N+ dispositivos a mantener (firmware updates) |
| Funciona con cualquier device BLE de HA | Connection slots limitados (3-4 por proxy) |
| Local-first, no cloud | Consume WiFi airtime |
| OTA updates standard ESPHome | Si todos los proxies caen, BLE entero down |
Mitigaciones a los con¶
- Mantenimiento: el agente AI del Q10 strategy puede manejar updates OTA programados.
- Slots: distribuir devices BLE entre proxies. Devices "always connected" (medic, etc.) en proxies dedicados.
- WiFi airtime: usar Ethernet proxies si tenés cable.
- Single point of failure: ≥2 proxies con coverage overlap.
Monitoring del stack proxy¶
| Métrica | Cómo | Alerta |
|---|---|---|
| Proxy online (mDNS responde) | Gatus check IP del proxy | offline >5 min |
| BLE device last_updated | Prometheus hass_last_updated_time_seconds |
>threshold |
| Memoria libre del ESP32 | ESPHome native sensor esp.free_memory |
<30 KB |
Relaciones¶
- Base de: ../entities/bluetooth-le (cómo se hace en práctica).
- Habilita: ../entities/switchbot (retrofit BLE necesita proxies).
- Apoyado por: ../sources/esphome-bluetooth-proxy (docs oficial con config verbatim).
- Conecta con: ../analysis/failure-mode-sensor-stale (un proxy caído = sensores stale en cluster).
Abierto / gaps¶
- ¿Hay equivalente para BLE classic (no LE)? — Per docs, no. BLE classic se queda fuera.
- ¿Coexistencia con ESP32 multi-purpose (LD2410 presence + bluetooth_proxy en el mismo board)? — Probable que sí pero validar.
- Patrón OTA batch para 4+ proxies actualizados juntos.