Connecter plusieurs périphériques Bluetooth à un serveur/appli : architectures et implémentation

Connecter plusieurs périphériques Bluetooth à un périphérique central unique (téléphone, Raspberry Pi, PC, passerelle) nécessite de choisir la bonne topologie et la bonne configuration de pile.

Options de topologie

1. Central/Périphérique (Étoile / Maître-Esclave) — Classique

• Central (votre serveur/appli) se connecte à plusieurs Périphériques (capteurs, wearables, tags).
• Connexions simultanées max : Bluetooth 4.x : 3–7 ; 5.0+ : jusqu'à 20+ (dépend du contrôleur).
• Les périphériques ne peuvent pas communiquer entre eux — tout le trafic passe par le Central.
• Simple, largement supporté, latence déterministe.

2. Bluetooth Mesh — Multidirectionnel

• Tous les nœuds relaient les messages (inondation gérée). Pas de coordinateur central nécessaire.
• Évolutif : Des centaines de nœuds (ampoules, interrupteurs, capteurs).
• Auto-réparation : Contourne les nœuds défaillants.
• Latence plus élevée, débit plus faible (~10–20 kbps effectif). Pas pour le streaming.
• Nécessite un firmware compatible Mesh sur tous les nœuds (Nordic, Silicon Labs, ESP32, Zephyr RTOS).

3. Sans connexion / Broadcast (Beacon / Advertising)

• Les périphériques annoncent des données (iBeacon, Eddystone, personnalisé). Le Central scanne — pas de connexion.
• Scanners illimités, consommation ultra-faible (périphérique en sommeil 99 %).
• Unidirectionnel (périphérique → central). Pas d'acquittement, pas de sécurité (sauf payload chiffré).

Étapes d'implémentation (Modèle Central/Périphérique)

1. Activer Bluetooth sur le central (Linux : bluetoothctl power on ; Android : BluetoothAdapter.enable() ; iOS : CBCentralManager).
2. Scanner et filtrer pour UUIDs de services ciblés / noms / adresses MAC.
3. Appairer / Lier chaque périphérique (MITM, OOB, ou Just Works). Stocker les clés pour reconnexion auto.
4. Connecter et découvrir les services (connectGatt / connectPeripheral). Mettre en cache les handles.
5. Activer notifications/indications sur les CCCD caractéristiques (0x2902) pour données temps réel.
6. Multiplexer : Utiliser des clients GATT / files d'attente séparés par périphérique dans votre appli. Boucle d'événements gère les callbacks.
7. Gérer les paramètres de connexion : Demander intervalle de connexion (min/max), latence esclave, timeout de supervision selon le rôle (haute fréquence pour IMU, basse pour température).
8. Gérer déconnexions/reconnexions : Backoff exponentiel, clés de liaison persistantes.

Piles de code

• Linux/Pi : BlueZ (API D-Bus) + Python bleak / dbus-next / bluezero.
• Android : BluetoothGatt, BluetoothLeScanner (Kotlin Flow/RxJava).
• iOS/macOS : CoreBluetooth (CBCentralManager, CBPeripheral — basé délégué).
• Multi-plateforme : Flutter flutter_blue_plus, React Native react-native-ble-plx, .NET BluetoothLE.
• Central embarqué : Zephyr RTOS (Hôte + Contrôleur Bluetooth), ESP-IDF (NimBLE/Bluedroid).

Pièges critiques

• Limite de connexions : Vérifier la spec du contrôleur (Nordic nRF52 : 20 ; nRF53 : 32 ; ESP32 : 3–7). Dépassement → CONN_FAILED.
• Débit : 1 connexion @ 30 Hz notify ≈ 10 kbps. 10 périphériques = 100 kbps — OK. 20 @ 100 Hz = saturation.
• Coexistence : Wi-Fi 2,4 GHz tue le débit BLE. Utiliser AFH (Adaptive Frequency Hopping), séparer antennes, privilégier Wi-Fi 5 GHz.
• Alimentation : Central en scan/connexion = courant élevé. Duty-cycle du scan.

Choisir Central/Périphérique pour <10–20 capteurs avec flux fiables. Choisir Mesh pour 50+ nœuds éclairage/bâtiment. Choisir Beacon pour télémétrie ultra-basse consommation.