Collegare più dispositivi Bluetooth a un server/app: architetture e implementazione
Collegare più periferiche Bluetooth a un singolo dispositivo centrale (telefono, Pi, PC, gateway) richiede di scegliere la giusta **topologia** e **configurazione dello stack**.
Opzioni di topologia
1. Centrale/Periferica (Stella / Master-Slave) — Classica
- Centrale (il tuo server/app) si connette a **multiple Periferiche** (sensori, indossabili, tag).
- Max connessioni concorrenti: Bluetooth 4.x: 3–7; 5.0+: **fino a 20+** (dipende dal controller).
- Le Periferiche **non possono parlare tra loro**—tutto il traffico passa attraverso il Centrale.
- Semplice, ampiamente supportato, latenza deterministica.
2. Bluetooth Mesh — Molti-a-molti
- Tutti i nodi relayano i messaggi (flood gestito). Nessun coordinatore centrale necessario.
- Scalabile: Centinaia di nodi (luci, interruttori, sensori).
- Autoguarigione: Le route aggirano nodi guasti.
- Latenza più alta**, throughput inferiore (~10–20 kbps effettivi). Non per streaming.
- Richiede **firmware mesh-capable** su tutti i nodi (Nordic, Silicon Labs, ESP32, Zephyr RTOS).
3. Senza connessione / Broadcast (Beacon / Advertising)
- Le Periferiche **pubblicizzano** dati (iBeacon, Eddystone, custom). Il Centrale **scansiona**—nessuna connessione.
- Scanner illimitati**, consumi estremamente bassi (la periferica dorme 99%).
- Unidirezionale (periferica → centrale). Nessun ack, nessuna sicurezza (a meno che payload criptato).
Passi di implementazione (Modello Centrale/Periferica)
- Attiva Bluetooth sul centrale (Linux: `bluetoothctl power on`; Android: `BluetoothAdapter.enable()`; iOS: `CBCentralManager`).
- Scansiona e filtra per UUID servizio target / nomi / MAC.
- Associa / Lega ogni periferica (MITM, OOB, o Just Works). Conserva le chiavi per riconnessione automatica.
- Connetti e scopri servizi (`connectGatt` / `connectPeripheral`). Memorizza i handle.
- Abilita Notifiche/Indicazioni su caratteristici CCCD (0x2902) per dati in tempo reale.
- Multiplex: Usa **client GATT separati / code per dispositivo** nella tua app. Loop di eventi gestisce i callback.
- Gestisci parametri di connessione: Richiedi **intervallo di connessione** (min/max), **slave latency**, **supervision timeout** per ruolo dispositivo (alta frequenza per IMU, bassa per temperatura).
- Gestisci disconnessioni/riconnesse: Backoff esponenziale, chiavi di bonding persistenti.
Stack di codice
- Linux/Pi: **BlueZ (API D-Bus)** + Python `bleak` / `dbus-next` / `bluezero`.
- Android: `BluetoothGatt`, `BluetoothLeScanner` (Kotlin Flow/RxJava).
- iOS/macOS: **CoreBluetooth** (`CBCentralManager`, `CBPeripheral` — basato su delegate).
- Cross-platform: **Flutter `flutter_blue_plus`**, **React Native `react-native-ble-plx`**, **.NET `BluetoothLE`**.
- Centrale Embedded: **Zephyr RTOS** (Host Bluetooth + Controller), **ESP-IDF** (NimBLE/Bluedroid).
Trappole critiche
- Limite di connessione: Controlla specifiche controller (Nordic nRF52: 20; nRF53: 32; ESP32: 3–7). Superamento → `CONN_FAILED`.
- Throughput: 1 connessione @ 30 Hz notify ≈ 10 kbps. 10 dispositivi = 100 kbps — OK. 20 @ 100 Hz = saturazione.
- Coesistenza: Wi-Fi 2,4 GHz uccide il throughput BLE. Usa **AFH (Adaptive Frequency Hopping)**, posiziona antenne distanti, preferisci Wi-Fi 5 GHz.
- Energia: Scansione/connesso centrale = alta corrente. Duty-cycle della scansione.
Scegli **Centrale/Periferica** per <10–20 sensori con flussi affidabili. Scegli **Mesh** per 50+ nodi illuminazione/edificio. Scegli **Beacon** per telemetria ultra-basso consumo.