Conectar múltiples dispositivos Bluetooth a un servidor/app: Arquitecturas e implementación

Conectar múltiples periféricos Bluetooth a un único dispositivo central (teléfono, Pi, PC, gateway) requiere elegir la **topología** y la **configuración de pila** adecuadas.

Opciones de topología

1. Central/Periférico (Estrella / Maestro-Esclavo) — Clásico

  • Central (tu servidor/app) se conecta a **múltiples Periféricos** (sensores, wearables, etiquetas).
  • Máximo de conexiones concurrentes: Bluetooth 4.x: 3–7; 5.0+: **hasta 20+** (depende del controlador).
  • Los Periféricos **no pueden hablar entre sí**—todo el tráfico pasa por Central.
  • Simple, ampliamente soportado, latencia determinista.

2. Bluetooth Mesh — Muchos a Muchos

  • Todos los nodos retransmiten mensajes (inundación gestionada). No se necesita coordinador central.
  • Escalable: Cientos de nodos (luces, interruptores, sensores).
  • Autosanable: Las rutas rodean nodos fallidos.
  • Latencia mayor**, menor rendimiento (~10–20 kbps efectivo). No para streaming.
  • Requiere **firmware capaz de mesh** en todos los nodos (Nordic, Silicon Labs, ESP32, Zephyr RTOS).

3. Sin conexión / Transmisión (Beacon / Publicidad)

  • Los Periféricos **publicitan** datos (iBeacon, Eddystone, personal). Central **escanea**—sin conexión.
  • Escáneres ilimitados, ultra bajo consumo (el periférico duerme el 99%).
  • Unidireccional (periférico → central). Sin acuse de recibo, sin seguridad (a menos que la carga esté cifrada).

Pasos de implementación (Modelo Central/Periférico)

  1. Habilitar Bluetooth en central (Linux: `bluetoothctl power on`; Android: `BluetoothAdapter.enable()`; iOS: `CBCentralManager`).
  2. Escanear y filtrar por UUIDs de servicio / nombres / MACs objetivo.
  3. Emparejar / Vincular cada periférico (MITM, OOB, o Just Works). Almacenar claves para reconexión automática.
  4. Conectar y descubrir servicios (`connectGatt` / `connectPeripheral`). Almacenar manejadores en caché.
  5. Habilitar Notificaciones/Indicaciones en CCCD de característica (0x2902) para datos en tiempo real.
  6. Multiplexar: Usar **clientes GATT separados / colas por dispositivo** en tu app. Bucle de eventos maneja devoluciones de llamada.
  7. Gestionar parámetros de conexión: Solicitar **intervalo de conexión** (mín/máx), **latencia esclava**, **tiempo de supervisión** por rol del dispositivo (alta tasa para IMU, baja para temp).
  8. Manejar desconexiones/reconexiones: Retroceso exponetivo, claves de vinculación persistentes.

Pilas de código

  • Linux/Pi: **BlueZ (API D-Bus)** + Python `bleak` / `dbus-next` / `bluezero`.
  • Android: `BluetoothGatt`, `BluetoothLeScanner` (Kotlin Flow/RxJava).
  • iOS/macOS: **CoreBluetooth** (`CBCentralManager`, `CBPeripheral` — basado en delegado).
  • Multiplataforma: **Flutter `flutter_blue_plus`**, **React Native `react-native-ble-plx`**, **.NET `BluetoothLE`**.
  • Central integrado: **Zephyr RTOS** (Host + Controlador Bluetooth), **ESP-IDF** (NimBLE/Bluedroid).

Problemas críticos

  • Límite de conexión: Verifica especificación del controlador (Nordic nRF52: 20; nRF53: 32; ESP32: 3–7). Exceder → `CONN_FAILED`.
  • Rendimiento: 1 conexión @ 30 Hz notify ≈ 10 kbps. 10 dispositivos = 100 kbps — OK. 20 @ 100 Hz = saturación.
  • Coexistencia: Wi-Fi 2.4 GHz mata el rendimiento BLE. Usa **AFH (Adaptive Frequency Hopping)**, coloca antennas separadas, prefiere Wi-Fi 5 GHz.
  • Energía: Central escaneando/conectado = corriente alta. Ciclo de escaneo.

Elige **Central/Periférico** para <10–20 sensores con flujos confiables. Elige **Mesh** para 50+ nodos de iluminación/edificio. Elige **Beacon** para telemetría de ultra bajo consumo.