Gestionar un solo Bluetooth Beacon es trivial. Gestionar 500 en 30 tiendas es ingenieria. Cada beacon funciona con una pila de boton, no tiene interfaz de red, y solo puede comunicarse en una direccion la mayor parte del tiempo. Cuando un beacon muere, se silencia, o se desvia de frecuencia, nadie lo nota hasta que una funcion orientada al cliente deja de funcionar. Este articulo cubre la ingenieria practica de la gestion de flota de beacons: como configurar remotamente dispositivos que no tienen canal de retorno, como enviar actualizaciones de firmware a 500 dispositivos sin brickearlos, como monitorear la vida de la bateria solo con datos de escaneo, y como construir el pipeline de telemetria que lo integra todo.
1. El Problema de la Gestion de Flota
Una flota de beacons es fundamentalmente diferente de una flota de dispositivos WiFi o celulares. La restriccion clave: los beacons son solo de transmision por defecto. Emiten paquetes de advertising y vuelven a dormir. No hay conexion TCP, no hay broker MQTT, no hay heartbeat. La unica forma de saber que un beacon esta vivo es escanearlo.
1.1 Que Puede Fallar a Escala
| Modo de Fallo | Tiempo de Deteccion (Sin Monitoreo) | Tiempo (Con Monitoreo) | Impacto |
|---|---|---|---|
| Agotamiento de bateria | Dias a semanas | < 1 hora | Beacon se silencia, funcion falla |
| Cuelgue de firmware | Nunca (hasta que la bateria muera) | < 15 min | Fallo silencioso, sin advertising |
| Deriva de frecuencia | Nunca | Horas (via analisis RSSI/escaneo) | Conexiones perdidas, rango reducido |
| Desplazamiento fisico | Dias | < 30 min | Datos de ubicacion erroneos, riesgo de seguridad |
| Corrupcion de configuracion | Nunca | < 1 hora | Payload de advertising incorrecto |
| Interferencia RF | Dias | < 15 min | Rango reducido, paquetes perdidos |
Con 500 beacons y una vida de bateria de 2 anos, pierde aproximadamente 0.27 beacons por dia solo por agotamiento de bateria. Sin monitoreo, acumula fallos silenciosos hasta que una masa critica de beacons muertos rompe la experiencia del cliente.
1.2 La Pila de Monitoreo de Tres Capas
Capa 3: Dashboard en la Nube (estado de flota, alertas, analiticas)
|
Capa 2: Red de Gateway/Escanner (escaneo BLE, reenvio de datos)
|
Capa 1: Flota de Beacons (advertising, telemetria en payload)
La Capa 1 son los beacons mismos. La Capa 2 es una red de escaners BLE (tipicamente Raspberry Pi o hardware de gateway dedicado) distribuidos por el sitio de despliegue. La Capa 3 es la plataforma en la nube que agrega datos de escaneo, ejecuta analiticas y dispara alertas.
2. Arquitectura de Configuracion Remota
2.1 El Problema del Canal de Retorno
Los beacons no pueden recibir comandos mientras estan en modo solo advertising. Para enviar cambios de configuracion, necesita uno de tres enfoques:
| Enfoque | Mecanismo | Latencia | Complejidad | Fiabilidad |
|---|---|---|---|---|
| Conexion GATT | El escanner se conecta al beacon, escribe caracteristica de config | Segundos | Media | Alta (bidireccional) |
| Respuesta de escaneo cifrada | Config embebida en respuesta de escaneo | Minutos | Baja | Media (unidireccional) |
| Datos del fabricante | Config codificada en rotacion de payload | Minutos | Media | Media (unidireccional) |
2.2 Configuracion Basada en GATT (Recomendada)
La mayoria de los beacons modernos exponen un servicio de configuracion GATT. Un escanner cercano se conecta, autentica y escribe nuevos parametros:
| Caracteristica | UUID (comun) | Acceso | Proposito |
|---|---|---|---|
| Intervalo de advertising | 0x2A04 | Lectura/Escritura | Frecuencia de emision |
| Potencia TX | 0x2A07 | Lectura/Escritura | Potencia de transmision |
| Nivel de bateria | 0x2A19 | Lectura | Monitoreo de bateria |
| Version de firmware | 0x2A26 | Lectura | Seguimiento de version |
| Datos del fabricante | 0x2A3D | Lectura/Escritura | Config de payload personalizado |
| Intervalo de conexion | 0x2A04 | Lectura/Escritura | Optimizar velocidad de conexion |
Sesion de configuracion tipica:
1. El escanner descubre el beacon por MAC/UUID
2. El escanner inicia conexion (30-100ms)
3. El beacon requiere autenticacion (AES-128 challenge-response)
4. El escanner escribe nuevos valores de configuracion
5. El beacon valida y aplica
6. El beacon envia confirmacion
7. El escanner se desconecta
Tiempo total: 200-500ms por beacon
2.3 Codificacion de Payload de Configuracion
Para configuracion eficiente over-the-air, empaquete parametros en un formato binario compacto:
Paquete de Config (24 bytes):
[0] Version de config (1 byte)
[1] Flags: bit0=adv_interval, bit1=tx_power, bit2=payload, bit3=channel_map
[2-3] Intervalo de advertising (2 bytes, unidades de 100ms, 0=sin cambio)
[4] Potencia TX (1 byte, dBm, con signo, 0=sin cambio)
[5-20] Datos de payload (16 bytes, 0xFF=sin cambio)
[21] Mapa de canales (1 byte, bitmask ch37/ch38/ch39)
[22-23] CRC16 (2 bytes)
Con 24 bytes por paquete, un escanner puede configurar aproximadamente 2 beacons por segundo (incluyendo overhead de conexion). Para 500 beacons: ~4 minutos total si todos estan en rango.
2.4 Ventanas de Configuracion Programada
Para minimizar disrupciones, programe cambios durante periodos de bajo trafico:
| Ventana | Hora | Razon |
|---|---|---|
| Retail | 02:00-05:00 | Tienda cerrada, sin impacto al cliente |
| Museo | 02:00-06:00 | Horas cerradas |
| Almacen | 12:30-13:00 | Almuerzo, trafico reducido |
| Hospital | 03:00-04:00 | Movimiento minimo de pacientes |
3. Estrategias de Actualizacion OTA de Firmware
3.1 El Riesgo de Brickear
Las actualizaciones OTA son la operacion mas riesgosa en gestion de flota. Una actualizacion fallida puede brickear un beacon permanentemente, requiriendo reemplazo fisico. A 500 beacons, una tasa de brick del 1% significa 5 reemplazos — costoso si estan montados en techos de 4 metros.
3.2 OTA de Banco Dual (Seguro)
El enfoque mas seguro usa almacenamiento de firmware de banco dual:
Layout de Flash (nRF52832, 512KB):
0x00000-0x01000 Bootloader (4KB)
0x01000-0x26000 Banco A: Firmware activo (156KB)
0x26000-0x4B000 Banco B: Buffer de descarga (156KB)
0x4B000-0x4D000 Config y calibracion (8KB)
0x4D000-0x50000 Ajustes del bootloader (12KB)
Proceso de actualizacion:
1. El escanner se conecta al beacon via GATT
2. El beacon reporta flash disponible y version de firmware actual
3. El escanner transfiere nuevo firmware al Banco B (fragmentado, 20 bytes por escritura GATT)
4. El beacon verifica CRC32 de la imagen descargada
5. El beacon intercambia bancos: Banco B activo, Banco A rollback
6. El beacon reinicia con nuevo firmware
7. Si el nuevo firmware falla al iniciar (timeout de watchdog), el bootloader revierte automaticamente al Banco A
| Parametro | Valor |
|---|---|
| Tamano de imagen de firmware | ~140KB |
| MTU GATT | 23 bytes (20 payload) |
| Escrituras por OTA | 7,168 |
| Tiempo por escritura | ~15ms (intervalo de conexion 15ms) |
| Tiempo total de OTA | ~107 segundos |
| Overhead de reintentos (10%) | ~12 segundos |
| Tiempo total OTA con reintentos | ~120 segundos por beacon |
3.3 Estrategia de Despliegue Escalonado
Nunca actualice todos los beacons simultaneamente. Use despliegue escalonado:
| Etapa | Porcentaje | Cantidad (500 beacons) | Periodo de Espera | Accion en Fallo |
|---|---|---|---|---|
| 1 | 1% | 5 | 24 horas | Detener, investigar |
| 2 | 5% | 25 | 48 horas | Detener si >1 fallo |
| 3 | 20% | 100 | 48 horas | Detener si >2% fallo |
| 4 | 50% | 250 | 72 horas | Detener si >2% fallo |
| 5 | 100% | 500 | — | Monitorear 1 semana |
3.4 Presupuesto de Tiempo OTA para 500 Beacons
Con 10 conexiones de escanner concurrentes:
Etapa 1: 5 beacons / 10 escaners = 1 lote x 2 min = 2 min
Etapa 2: 25 beacons / 10 escaners = 3 lotes x 2 min = 6 min
Etapa 3: 100 beacons / 10 escaners = 10 lotes x 2 min = 20 min
Etapa 4: 250 beacons / 10 escaners = 25 lotes x 2 min = 50 min
Etapa 5: 500 beacons / 10 escaners = 50 lotes x 2 min = 100 min
Tiempo activo OTA total: ~178 min (todas las etapas)
Tiempo total calendario (con esperas): ~9 dias
4. Monitoreo y Prediccion de Vida de Bateria
4.1 Lectura del Nivel de Bateria
Tres metodos para obtener el voltaje de la bateria:
| Metodo | Precision | Overhead | Cuando Disponible |
|---|---|---|---|
| Servicio de Nivel de Bateria (GATT 0x2A19) | ±5% | Requiere conexion | Durante sesiones de config/OTA |
| Medicion ADC en payload de advertising | ±2% | 50uA por medicion, 2 bytes payload | Cada advertisement |
| Inferencia de voltaje desde RSSI | ±20% | Ninguno (pasivo) | Solo datos de escaneo |
4.2 Codificacion de Voltaje de Bateria en Payload
Inserte el voltaje de la bateria en el campo de datos del fabricante:
Datos del Fabricante (4 bytes):
[0-1] ID de compania (0x0059 = Nordic)
[2] Voltaje de bateria (1 byte, unidades de 20mV, offset 1.6V)
Ejemplo: 0x33 = 51 = 51*20mV + 1600mV = 2620mV = 2.62V
[3] Flags de estado: bit0=bateria_baja, bit1=ota_listo, bit2=config_pendiente
Una CR2032 nueva lee ~3.0V (0x4C = 76). Fin de vida util ~2.0V (0x14 = 20). Esto da 56 niveles discretos en el rango util — suficiente para monitoreo.
4.3 Modelo de Prediccion de Vida de Bateria
Usando datos de escaneo, construya una curva de agotamiento para cada beacon:
Caida de voltaje diaria = (V_hoy - V_ayer) / dias_transcurridos
Vida restante (dias) = (V_actual - V_fin_vida) / caida_voltaje_diaria
Ejemplo para un beacon con intervalo de advertising de 1 segundo:
| Dia | Voltaje (mV) | Caida Diaria (mV) | Vida Predicha (dias) |
|---|---|---|---|
| 1 | 3020 | — | — |
| 30 | 2985 | 1.17 | 841 |
| 90 | 2920 | 1.18 | 783 |
| 180 | 2810 | 1.22 | 664 |
| 365 | 2540 | 1.30 | 415 |
| 500 | 2280 | 1.43 | 196 |
| 600 | 2010 | 2.70 | 4 |
Note el agotamiento acelerado cerca del fin de vida debido al aumento de la resistencia interna. El modelo de prediccion debe usar un promedio movil de los ultimos 14 dias para suavizar fluctuaciones diarias (temperatura, frecuencia de escaneo).
4.4 Dashboard de Bateria a Nivel de Flota
| Metrica | Objetivo | Umbral de Alerta |
|---|---|---|
| Voltaje promedio de flota | > 2.7V | < 2.5V |
| Beacons por debajo de 2.4V | 0 | > 2% de la flota |
| Reemplazos predichos (30 dias) | 0 | > 5 |
| Costo mensual de reemplazo de bateria | < $50 | > $200 |
5. Verificacion de Salud y Deteccion de Anomalias
5.1 Deteccion de Heartbeat
Un beacon se considera vivo si al menos un escanner lo ha visto dentro del intervalo esperado. Defina ventanas de heartbeat basadas en el intervalo de advertising:
| Intervalo de Advertising | Timeout de Heartbeat | Razonamiento |
|---|---|---|
| 100ms | 30 segundos | 300 paquetes perdidos = anomalia |
| 1 segundo | 5 minutos | 300 paquetes perdidos = anomalia |
| 10 segundos | 30 minutos | 180 paquetes perdidos = anomalia |
5.2 Deteccion de Anomalias Basada en RSSI
RSSI es una señal ruidosa, pero cambios repentinos indican problemas:
| Anomalia | Patron RSSI | Causa Probable |
|---|---|---|
| Beacon movido | RSSI cae > 15dB de repente en todos los escaners | Desplazamiento fisico |
| Fallo de escanner | RSSI cae en un escanner, estable en otros | Problema de hardware del escanner |
| Interferencia RF | Varianza RSSI aumenta > 6dB | Nueva fuente de interferencia |
| Bateria baja | RSSI cae gradualmente 3-5dB en semanas | Potencia TX reducida a bajo voltaje |
| Obstaculo | RSSI cae en un escanner, retraso en otros | Nueva barrera fisica |
5.3 Umbrales Estadisticos
Use una ventana movil (1 hora, 3600 muestras a 1s) para calcular:
RSSI promedio: mu = sum(RSSI_i) / N
Desv. Estandar: sigma = sqrt(sum((RSSI_i - mu)^2) / N)
Alertar si: |RSSI_actual - mu| > 3 * sigma (99.7% confianza)
Para un beacon con mu = -65dBm y sigma = 4dBm, alertar si RSSI sube de -53dBm o baja de -77dBm.
5.4 Monitoreo de Intervalo de Advertising
Algunos beacons desvian su intervalo debido a tolerancia del cristal o bugs de firmware. Detecte midiendo el tiempo entre llegadas de paquetes:
Esperado: 1000ms +/- 50ms (spec BLE permite +/- 50ms jitter)
Medido: tiempo entre escaneos consecutivos del mismo beacon
>1100ms o <900ms consistente: problema de firmware
Varianza alta (>200ms stddev): inestabilidad del oscilador
6. Pipeline de Datos de Telemetria
6.1 Estimacion de Volumen de Datos
Para 500 beacons a 1Hz, escaneados por 20 gateways:
Paquetes por beacon por segundo: 1 (3 canales, escanner ve ~1/3)
Paquetes por gateway por segundo: 500 / 3 = 167 (aprox)
Paquetes por flota por segundo: 167 * 20 = 3,340
Paquetes por dia: 3,340 * 86,400 = 288,576,000
Por paquete (JSON): ~200 bytes
Volumen diario: 288,576,000 * 200 = 57.7 GB raw
Con deduplicacion (mantener primero por ventana 30s por beacon por gateway):
Paquetes unicos: 500 * 2 * 86,400 = 86,400,000
Despues dedup: 500 * 1 * 2,880 = 1,440,000
Volumen dedup: 1,440,000 * 200 = 288 MB/dia
6.2 Arquitectura de Pipeline Recomendada
Beacons
|
Gateways (escaneo BLE, dedup, buffer)
|
MQTT (TLS, QoS 1)
|
Message Broker (Mosquitto/EMQX)
|
Stream Processor (Kafka/Faust/Python)
|---> Time-Series DB (InfluxDB/ClickHouse)
|----> Alert Engine (Prometheus/Grafana)
|---> Object Storage (S3/MinIO, archivos comprimidos)
6.3 Stack de Software del Gateway
| Componente | Tecnologia | Proposito |
|---|---|---|
| Escanner BLE | Python + bleak / C + BlueZ | Escanear paquetes de advertising |
| Filtro de dedup | Custom (ventana 30s por beacon) | Eliminar escaneos duplicados |
| Buffer local | SQLite / Redis | Sobrevivir cortes de red |
| Cliente MQTT | paho-mqtt / Eclipse Paho | Reenviar a la nube |
| Agente de salud | watchdog systemd | Auto-reiniciar en fallo |
6.4 Esquema de Datos
{
"beacon_id": "AA:BB:CC:DD:EE:01",
"timestamp": "2026-08-23T01:00:00.123Z",
"rssi": -67,
"gateway_id": "gw-lobby-01",
"battery_mv": 2780,
"temperature_c": 24.5,
"adv_interval_ms": 1000,
"firmware_ver": "2.3.1",
"payload_hash": "a1b2c3d4"
}
7. Comparacion de Plataformas de Gestion de Dispositivos
| Plataforma | Soporte Beacon | OTA | Limite de Flota | Modelo de Precio | Self-Hosted |
|---|---|---|---|---|---|
| Kontakt.io Panel | Completo (beacons Kontakt) | Si | 100,000+ | Por beacon/mes | No |
| Estimote Cloud | Completo (beacons Estimote) | Si | 50,000+ | Por beacon/mes | No |
| RadBeacon Dashboard | Completo (solo RadBeacon) | Si | 10,000+ | Gratis (lock-in hardware) | No |
| BeeCastle / BlueUp | Completo (propietario) | Si | 5,000+ | Por beacon/mes | No |
| Custom (Open Source) | Cualquier beacon con GATT | Custom | Ilimitado | Costo de infra | Si |
7.1 Decision Build vs Buy
| Factor | Buy (Plataforma Gestionada) | Build (Custom) |
|---|---|---|
| Tiempo de setup | 1-2 dias | 2-4 semanas |
| Costo mensual (500 beacons) | $250-500/mes | $50-100 (infra nube) |
| Flexibilidad | Limitada a features de la plataforma | Control total |
| Soporte multi-vendor | Usualmente single-vendor | Cualquier beacon GATT |
| Fiabilidad OTA | Gestionada por vendor | Su responsabilidad |
| Propiedad de datos | Hosted por vendor | Propiedad total |
Para flotas de vendor mixto o requisitos de telemetria custom, construir una plataforma custom es a menudo la mejor opcion a largo plazo.
8. Consideraciones de Seguridad para Gestion de Flota
8.1 Autenticacion de Configuracion
Todas las escrituras de configuracion deben autenticarse. Recomendado: AES-128 challenge-response:
1. El escanner envia challenge (16 bytes aleatorios)
2. El beacon calcula HMAC-SHA256(challenge, shared_key), trunca a 16 bytes
3. El beacon envia respuesta
4. El escanner verifica
5. Sesion de config cifrada procede (AES-128-CCM)
8.2 Rotacion de Claves
Rote las claves de flota anualmente o tras cualquier cambio de personal:
| Tipo de Clave | Alcance | Periodo de Rotacion | Mecanismo |
|---|---|---|---|
| Clave auth de config | Por beacon | 12 meses | Comando de rotacion OTA |
| Clave de firma OTA | Por flota | 6 meses | Actualizacion de firmware con nueva clave |
| Clave API de gateway | Por gateway | 3 meses | Rotacion via dashboard en la nube |
| Certificado MQTT broker | Por gateway | 12 meses | Auto-renovacion de certificado |
8.3 Deteccion de Beacon Rogue
En una flota gestionada, detecte beacons no autorizados que imitan su UUID:
| Check | Metodo | Condicion de Alerta |
|---|---|---|
| Allowlist de MAC | Comparar MAC escaneada con lista registrada | MAC desconocida emitiendo UUID de flota |
| Firma de payload | HMAC en datos del fabricante | Firma invalida |
| Geofence RSSI | Comparar RSSI con rango esperado | RSSI inconsistente con ubicacion |
| Version de firmware | Leer via GATT | Version de firmware desconocida |
9. Automatizacion de Despliegue
9.1 Configuracion Pre-Despliegue
Antes de la instalacion fisica, configure beacons en lote:
Workflow:
1. Conectar beacon via dock USB (cargador de lote de 10)
2. Leer direccion MAC
3. Asignar ID de beacon y ubicacion del plan de despliegue
4. Escribir configuracion (UUID, major, minor, intervalo, potencia TX)
5. Escribir clave de autenticacion
6. Verificar configuracion escaneando
7. Registrar en base de datos de inventario
8. Marcar como "listo para despliegue"
Tiempo por beacon: 15-20 segundos
Lote de 10: ~3 minutos
500 beacons: ~2.5 horas
9.2 Verificacion de Instalacion
Despues de la instalacion fisica, recorra el sitio con una app escanner:
Para cada beacon:
1. Escanear en ubicacion esperada
2. Verificar RSSI dentro del rango esperado (-40 a -80 dBm)
3. Verificar payload de advertising correcto
4. Verificar voltaje de bateria > 2.8V
5. Marcar como "instalado y verificado"
Tiempo por beacon: 30 segundos (tiempo de caminata)
500 beacons en 30 ubicaciones: ~4-6 horas
9.3 Verificacion de Salud Post-Despliegue
Verificacion automatizada de 24 horas despues del despliegue:
| Check | Umbral | Accion en Fallo |
|---|---|---|
| Todos los beacons vistos | 100% | Investigar beacons faltantes |
| RSSI dentro del rango | 95% dentro de +/- 10dB | Verificar colocacion |
| Voltaje de bateria > 2.8V | 100% | Reemplazar baterias bajas |
| Intervalo de advertising correcto | 100% | Reconfigurar |
| Sin beacons rogue | 0 MACs desconocidos | Investigar |
10. Caso de Estudio: Despliegue Retail de 500 Beacons
10.1 Configuracion
- Beacons: 500 unidades, nRF52832, CR2032, advertising 1 segundo
- Ubicaciones: 30 tiendas (15-20 beacons cada una)
- Gateways: 60 unidades (2 por tienda), Raspberry Pi 4 + dongle BLE
- Caso de uso: Marketing de proximidad + navegacion indoor
- Monitoreo: Plataforma custom (Python + MQTT + InfluxDB + Grafana)
10.2 Metricas Operativas (Ano 1)
| Metrica | Valor | Notas |
|---|---|---|
| Total beacons desplegados | 500 | En 30 tiendas |
| Beacons reemplazados (bateria) | 12 (2.4%) | Promedio 380 dias a reemplazo |
| Beacons reemplazados (defecto) | 3 (0.6%) | 2 cuelgues de firmware, 1 fallo hardware |
| Actualizaciones OTA enviadas | 2 | Parches menores de firmware |
| Fallos OTA | 0 | Rollback de banco dual funciono una vez |
| Uptime promedio | 99.6% | 4.2 beacons offline en cualquier momento |
| Tiempo medio de deteccion | 8 minutos | Via monitoreo de heartbeat |
| Tiempo medio de reparacion | 2.5 dias | Tecnico con reemplazo |
| Costo mensual de monitoreo | $85 | AWS (EC2 + RDS + S3) |
| Costo mensual de gateway | $60 | Backhaul celular (60 x $1) |
10.3 Lecciones Aprendidas
1. La redundancia de gateway es critica: Un gateway por tienda causaba puntos ciegos durante reinicios. Dos gateways con cobertura superpuesta elimino esto.
2. La prediccion de bateria funciona: El modelo de promedio movil de 14 dias predijo 10 de 12 fallos de bateria dentro de 7 dias del fallo real.
3. El cuelgue de firmware es el asesino silencioso: 2 beacons se colgaron con watchdog deshabilitado. Se anadio watchdog externo (IC de reset por hardware) en hardware v2.
4. Geofencing RSSI detecto 1 robo: Un beacon fue movido a otra tienda. El cambio de patron RSSI disparo alerta en 30 minutos.
11. Checklist de Gestion de Flota
- [ ] Plan de despliegue con ID de beacon, ubicacion y config para cada dispositivo
- [ ] Workflow de configuracion en lote pre-despliegue (dock USB + script de automatizacion)
- [ ] Red de gateways con cobertura superpuesta (minimo 2 por ubicacion)
- [ ] Broker MQTT con TLS y QoS 1
- [ ] Base de datos de series temporales para datos de escaneo (InfluxDB o ClickHouse)
- [ ] Monitoreo de heartbeat con timeout configurable por intervalo de advertising
- [ ] Seguimiento de voltaje de bateria con prediccion de promedio movil de 14 dias
- [ ] Deteccion de anomalias RSSI (ventana movil de 3-sigma)
- [ ] Pipeline de alertas (email/SMS/Slack) con reglas de escalacion
- [ ] Configuracion remota basada en GATT con autenticacion AES-128
- [ ] OTA de banco dual con despliegue escalonado (1% / 5% / 20% / 50% / 100%)
- [ ] Clave de firma OTA y calendario de rotacion de claves
- [ ] Deteccion de beacon rogue (allowlist MAC + firma de payload)
- [ ] Verificacion de instalacion con app escanner
- [ ] Verificacion automatizada de salud 24 horas post-despliegue
- [ ] Dashboard de flota mostrando estado, bateria y alertas de anomalias
- [ ] Inventario de beacons de repuesto (5% del tamano de flota)
- [ ] Procedimiento de despacho de tecnico con objetivos SLA
- [ ] Reporte mensual de salud de flota (uptime, fallos, tendencias de bateria)
- [ ] Rotacion anual de claves y auditoria de seguridad
12. Resumen
La gestion de flota de beacons es un problema de ingenieria de sistemas, no un problema de hardware. Los beacons son simples; la infraestructura a su alrededor es compleja. Puntos clave:
1. Los datos de escaneo son su unico canal de retorno. Diseñe su pipeline alrededor de lo que puede observar pasivamente.
2. OTA de banco dual es innegociable para cualquier flota mayor de 50 beacons. La red de seguridad de rollback se paga sola la primera vez que una actualizacion falla.
3. La prediccion de bateria desde tendencias de voltaje es precisa dentro de 7 dias si usa un promedio movil de 14 dias. Reemplace beacons proactivamente antes de que se silencien.
4. Monitoreo de heartbeat con timeout de 5 minutos detecta el 95% de los fallos en 15 minutos.
5. Despliegue OTA escalonado (1% a 100% en 9 dias) previene brickeo de toda la flota.
6. Redundancia de gateway (2 por sitio con cobertura superpuesta) elimina puntos ciegos durante mantenimiento.
Para organizaciones que despliegan infraestructura de Bluetooth Beacon a escala, la plataforma de gestion de flota es donde ocurre la verdadera ingenieria. Los Beacons son commodities; el pipeline de monitoreo, configuracion y OTA es lo que diferencia un despliegue que se autogestiona de uno que requiere intervencion manual constante.
