Un solo Beacon es fácil de olvidar una vez pegado a la pared. El problema empieza a escala: un almacén con 500 beacons, un hospital con 2000, un campus con 8000. Cuando uno muere no te das cuenta hasta que una zona se queda a oscuras. Este artículo cubre cómo mantener una flota de Beacon observable: telemetría, alertas de batería, estado online/offline y empujar config a miles de unidades sin tocarlas.
Qué debe reportar un Beacon
Cada Beacon gestionado debe emitir un pequeño latido de salud junto a su advertising, por conexión o vía gateway que escucha y reenvía:
- Voltaje / porcentaje de batería: la mejor señal de alerta temprana.
- Último RSSI y Tx power de referencia: detecta radio fallida o unidad movida.
- Uptime y causa de reset: un beacon que reinicia cada hora tiene fallo de energía o firmware.
- Versión de firmware: para saber qué hay en campo.
- Contadores de paquetes/adv: un contador congelado significa stack colgado.
Mantenga el latido pequeño: unos pocos bytes cada horas basta; vigila tendencias, no hace streaming.
Umbrales de alerta de batería
Un Beacon con CR2477 a intervalo 1 s arranca cerca de 3.0 V y cae lento, luego precipicio cerca de 2.4 V. Ponga dos umbrales:
| Nivel | Voltaje | Acción |
|---|---|---|
| Sano | > 2.7 V | ninguna |
| Aviso | 2.5-2.7 V | reemplazo en 60 días |
| Crítico | < 2.5 V | reemplace ya, marque ubicación |
No espere a 2.0 V: para entonces el beacon puede ya soltar paquetes intermitentes y dar posiciones erróneas.
Detección online / offline
El trabajo central del dashboard es saber quién vive. Un Beacon que un gateway no oye en N intervalos está «stale»; uno no visto en M minutos está «offline». Valores típicos: stale tras 3 intervalos perdidos (~3-15 s), offline tras 10-30 min. Cierre la alerta en offline, no stale, para evitar falsas por un hueco momentáneo del gateway.
Empuje de config en lote
Cuando cambia el intervalo o los major/minor en toda la flota de Beacon, no visita cada uno. Dos patrones funcionan:
- Relé por gateway: el gateway recibe un blob de config por MQTT/HTTP y lo reenvía a beacons cercanos por conexión o comando broadcast (ver artículo downlink). Un comando llega a cientos.
- Auto-obtención agendada: cada beacon despierta, conecta y jala su config de un servidor en horario escalonado, evitando una estampida.
Autentique cada comando: un empuje sin firma es el sueño de un atacante.
Ciclo de reconfiguración remota
Un despliegue disciplinado de Beacon trata la config como estado versionado:
1. Autoriza config v2 en la consola (intervalo, tx power, payload).
2. Canary: empuja al 1% de la flota, vigila resets o picos offline.
3. Despliega al resto en horario escalonado.
4. Conserva v1 para rollback instantáneo si las métricas caen.
Es la misma disciplina de entrega progresiva del software cloud, aplicada a radios pequeñas.
Seguridad de la telemetría
Datos de salud son datos. Un Beacon que reporta batería y ubicación es un buen side channel para un atacante que mapea su planta. Envíe telemetría por canal cifrado y autenticado, y firme la config para que un gateway rogue no suplante al dueño de la flota.
Construir el dashboard
El dashboard necesita solo cuatro vistas: mapa online/offline, histograma de batería, desglose de versión de firmware y feed de alertas recientes. La mayoría del valor está en el histograma de batería: dice hoy la carga de reemplazo del mes que viene.
Una flota de Beacon bien instrumentada convierte «algo anda mal en algún lado» en «la unidad 4821 en el pasillo 7 cae bajo 2.5 V el próximo martes»: esa es la diferencia entre un equipo de mantenimiento y un incendio.