Gerer un seul Bluetooth Beacon est trivial. En gerer 500 sur 30 magasins, c’est de l’ingenierie. Chaque beacon fonctionne sur une pile bouton, n’a pas d’interface reseau, et ne peut communiquer que dans un sens la plupart du temps. Quand un beacon meurt, se tait, ou derive en frequence, personne ne le remarque jusqu’a ce qu’une fonctionnalite cote client cesse de fonctionner. Cet article couvre l’ingenierie pratique de la gestion de flotte de beacons : comment configurer a distance des dispositifs sans canal de retour, comment pousser des mises a jour de firmware vers 500 dispositifs sans les bricker, comment surveiller la duree de vie de la batterie uniquement a partir des donnees de scan, et comment construire le pipeline de telemetrie qui relie tout.
1. Le Probleme de la Gestion de Flotte
Une flotte de beacons est fondamentalement differente d’une flotte de dispositifs WiFi ou cellulaires. La contrainte principale : les beacons sont en emission seule par defaut. Ils diffusent des paquets d’advertising et retournent en veille. Il n’y a pas de connexion TCP, pas de broker MQTT, pas de heartbeat. La seule maniere de savoir qu’un beacon est vivant est de le scanner.
1.1 Ce Qui Peut Mal Tourner a Grande Echelle
| Mode de Panne | Temps de Detection (Sans Monitoring) | Temps (Avec Monitoring) | Impact |
|---|---|---|---|
| Epuisement batterie | Jours a semaines | < 1 heure | Beacon se tait, fonction cassee |
| Blocage firmware | Jamais (jusqu’a batterie morte) | < 15 min | Panne silencieuse, pas d’advertising |
| Derive de frequence | Jamais | Heures (via analyse RSSI/scan) | Connexions manquees, portee reduite |
| Deplacement physique | Jours | < 30 min | Donnees de localisation erronees |
| Corruption de configuration | Jamais | < 1 heure | Payload d’advertising incorrect |
| Interference RF | Jours | < 15 min | Portee reduite, paquets perdus |
Avec 500 beacons et une duree de vie de batterie de 2 ans, vous perdez environ 0,27 beacons par jour rien que par epuisement de batterie. Sans monitoring, vous accumulez des pannes silencieuses jusqu’a ce qu’une masse critique de beacons morts casse l’experience client.
1.2 La Pile de Monitoring a Trois Couches
Couche 3 : Dashboard Cloud (statut flotte, alertes, analytique)
|
Couche 2 : Reseau Gateway/Scanner (scan BLE, transfert de donnees)
|
Couche 1 : Flotte de Beacons (advertising, telemetrie dans payload)
La Couche 1 correspond aux beacons eux-memes. La Couche 2 est un reseau de scanners BLE (generalement Raspberry Pi ou hardware de passerelle dedie) distribues sur le site de deploiement. La Couche 3 est la plateforme cloud qui agrege les donnees de scan, execute des analyses et declenche des alertes.
2. Architecture de Configuration a Distance
2.1 Le Probleme du Canal de Retour
Les beacons ne peuvent pas recevoir de commandes en mode advertising seul. Pour pousser des changements de configuration, vous avez besoin de l’une de trois approches :
| Approche | Mecanisme | Latence | Complexite | Fiabilite |
|---|---|---|---|---|
| Connexion GATT | Le scanner se connecte au beacon, ecrit la characteristic de config | Secondes | Moyenne | Elevee (bidirectionnelle) |
| Reponse de scan chiffree | Config integree dans la reponse de scan | Minutes | Faible | Moyenne (unidirectionnelle) |
| Donnees specifiques constructeur | Config codee dans la rotation du payload | Minutes | Moyenne | Moyenne (unidirectionnelle) |
2.2 Configuration Basee sur GATT (Recommandee)
La plupart des beacons modernes exposent un service de configuration GATT. Un scanner a proximite se connecte, s’authentifie et ecrit les nouveaux parametres :
| Characteristic | UUID (commun) | Acces | Objectif |
|---|---|---|---|
| Intervalle d’advertising | 0x2A04 | Lecture/Ecriture | Frequence de diffusion |
| Puissance TX | 0x2A07 | Lecture/Ecriture | Puissance d’emission |
| Niveau de batterie | 0x2A19 | Lecture | Surveillance de batterie |
| Version firmware | 0x2A26 | Lecture | Suivi de version |
| Donnees constructeur | 0x2A3D | Lecture/Ecriture | Config de payload personnalise |
| Intervalle de connexion | 0x2A04 | Lecture/Ecriture | Optimiser la vitesse de connexion |
Session de configuration typique :
1. Le scanner decouvre le beacon par MAC/UUID
2. Le scanner initie la connexion (30-100ms)
3. Le beacon exige l'authentification (AES-128 challenge-response)
4. Le scanner ecrit les nouvelles valeurs de config
5. Le beacon valide et applique
6. Le beacon envoie confirmation
7. Le scanner se deconnecte
Temps total : 200-500ms par beacon
2.3 Codage du Payload de Configuration
Pour une configuration OTA efficace, compactez les parametres dans un format binaire compact :
Paquet de Config (24 octets) :
[0] Version de config (1 octet)
[1] Flags : bit0=adv_interval, bit1=tx_power, bit2=payload, bit3=channel_map
[2-3] Intervalle d'advertising (2 octets, unites de 100ms, 0=inchangé)
[4] Puissance TX (1 octet, dBm, signe, 0=inchangé)
[5-20] Donnees de payload (16 octets, 0xFF=inchangé)
[21] Carte des canaux (1 octet, masque binaire ch37/ch38/ch39)
[22-23] CRC16 (2 octets)
Avec 24 octets par paquet, un scanner peut configurer environ 2 beacons par seconde (y compris le overhead de connexion). Pour 500 beacons : ~4 minutes si tous sont a portee.
2.4 Fenetres de Configuration Programmee
Pour minimiser les perturbations, planifiez les changements pendant les periodes de faible trafic :
| Fenetre | Heure | Raison |
|---|---|---|
| Commerce de detail | 02h00-05h00 | Magasin ferme |
| Musee | 02h00-06h00 | Heures de fermeture |
| Entrepot | 12h30-13h00 | Pause dejeuner, trafic reduit |
| Hopital | 03h00-04h00 | Mouvement minimal de patients |
3. Strategies de Mise a Jour OTA du Firmware
3.1 Le Risque de Brickage
Les mises a jour OTA sont l’operation la plus risquee en gestion de flotte. Une mise a jour echouee peut bricker un beacon de maniere permanente, necessitant un remplacement physique. Avec 500 beacons, un taux de brickage de 1% signifie 5 remplacements — couteux si montes au plafond a 4 metres.
3.2 OTA a Double Banque (Sur)
L’approche la plus sure utilise un stockage de firmware a double banque :
Layout Flash (nRF52832, 512Ko) :
0x00000-0x01000 Bootloader (4Ko)
0x01000-0x26000 Banque A : Firmware actif (156Ko)
0x26000-0x4B000 Banque B : Buffer de telechargement (156Ko)
0x4B000-0x4D000 Config et calibration (8Ko)
0x4D000-0x50000 Parametres du bootloader (12Ko)
Processus de mise a jour :
1. Le scanner se connecte au beacon via GATT
2. Le beacon signale le flash disponible et la version firmware actuelle
3. Le scanner transfere le nouveau firmware vers la Banque B (par morceaux, 20 octets par ecriture GATT)
4. Le beacon verifie le CRC32 de l’image telechargee
5. Le beacon permute les banques : Banque B active, Banque A de secours
6. Le beacon redemarre avec le nouveau firmware
7. Si le nouveau firmware echoue au demarrage (timeout watchdog), le bootloader revient automatiquement a la Banque A
| Parametre | Valeur |
|---|---|
| Taille de l’image firmware | ~140Ko |
| MTU GATT | 23 octets (20 payload) |
| Ecritures par OTA | 7.168 |
| Temps par ecriture | ~15ms (intervalle de connexion 15ms) |
| Temps total OTA | ~107 secondes |
| Overhead de retries (10%) | ~12 secondes |
| Temps total OTA avec retries | ~120 secondes par beacon |
3.3 Strategie de Deploiement Echelonne
Ne mettez jamais a jour tous les beacons simultanement. Utilisez un deploiement echelonne :
| Etape | Pourcentage | Nombre (500 beacons) | Periode d’attente | Action en cas d’echec |
|---|---|---|---|---|
| 1 | 1% | 5 | 24 heures | Arreter, investiguer |
| 2 | 5% | 25 | 48 heures | Arret si >1 echec |
| 3 | 20% | 100 | 48 heures | Arret si >2% echec |
| 4 | 50% | 250 | 72 heures | Arret si >2% echec |
| 5 | 100% | 500 | — | Surveiller 1 semaine |
3.4 Budget de Temps OTA pour 500 Beacons
Avec 10 connexions de scanner concurrentes :
Etape 1 : 5 beacons / 10 scanners = 1 lot x 2 min = 2 min
Etape 2 : 25 beacons / 10 scanners = 3 lots x 2 min = 6 min
Etape 3 : 100 beacons / 10 scanners = 10 lots x 2 min = 20 min
Etape 4 : 250 beacons / 10 scanners = 25 lots x 2 min = 50 min
Etape 5 : 500 beacons / 10 scanners = 50 lots x 2 min = 100 min
Temps OTA actif total : ~178 min (toutes etapes)
Temps total calendaire (avec attentes) : ~9 jours
4. Surveillance et Prediction de Duree de Vie de Batterie
4.1 Lecture du Niveau de Batterie
Trois methodes pour obtenir la tension de la batterie :
| Methode | Precision | Overhead | Quand disponible |
|---|---|---|---|
| Service de niveau de batterie (GATT 0x2A19) | ±5% | Requiert connexion | Pendant les sessions config/OTA |
| Mesure ADC dans le payload d’advertising | ±2% | 50uA par mesure, 2 octets payload | Chaque advertisement |
| Inference de tension depuis RSSI | ±20% | Aucun (passif) | Donnees de scan seulement |
4.2 Codage de la Tension de Batterie dans le Payload
Donnees du constructeur (4 octets) :
[0-1] ID societe (0x0059 = Nordic)
[2] Tension batterie (1 octet, unites de 20mV, offset 1,6V)
Exemple : 0x33 = 51 = 51*20mV + 1600mV = 2620mV = 2,62V
[3] Flags de statut : bit0=batterie_faible, bit1=ota_pret, bit2=config_en_attente
Une CR2032 neuve lit ~3,0V (0x4C = 76). Fin de vie utile ~2,0V (0x14 = 20). Cela donne 56 niveaux discrets dans la plage utile — suffisant pour le monitoring.
4.3 Modele de Prediction de Duree de Vie de Batterie
En utilisant les donnees de scan, construisez une courbe d’epuisement pour chaque beacon :
Chute de tension quotidienne = (V_aujourdhui - V_hier) / jours_ecoules
Duree de vie restante (jours) = (V_actuel - V_fin_de_vie) / chute_tension_quotidienne
Exemple pour un beacon avec intervalle d’advertising de 1 seconde :
| Jour | Tension (mV) | Chute Quotidienne (mV) | Vie Predite (jours) |
|---|---|---|---|
| 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 |
Notez l’epuisement accelere pres de la fin de vie due a l’augmentation de la resistance interne. Le modele de prediction doit utiliser une moyenne mobile sur 14 jours pour lisser les fluctuations quotidiennes.
4.4 Dashboard de Batterie au Niveau Flotte
| Metrique | Objectif | Seuil d’Alerte |
|---|---|---|
| Tension moyenne de flotte | > 2,7V | < 2,5V |
| Beacons sous 2,4V | 0 | > 2% de la flotte |
| Remplacements predits (30 jours) | 0 | > 5 |
| Cout mensuel de remplacement | < 50 $ | > 200 $ |
5. Verification de Sante et Detection d’Anomalies
5.1 Detection de Heartbeat
Un beacon est considere vivant si au moins un scanner l’a vu dans l’intervalle attendu :
| Intervalle d’Advertising | Timeout Heartbeat | Raisonnement |
|---|---|---|
| 100ms | 30 secondes | 300 paquets manques = anomalie |
| 1 seconde | 5 minutes | 300 paquets manques = anomalie |
| 10 secondes | 30 minutes | 180 paquets manques = anomalie |
5.2 Detection d’Anomalies Basee sur RSSI
| Anomalie | Motif RSSI | Cause Probable |
|---|---|---|
| Beacon deplace | RSSI chute > 15dB soudainement sur tous les scanners | Deplacement physique |
| Panne de scanner | RSSI chute sur un scanner, stable sur les autres | Probleme hardware du scanner |
| Interference RF | Variance RSSI augmente > 6dB | Nouvelle source d’interference |
| Batterie faible | RSSI chute progressivement 3-5dB sur semaines | Puissance TX reduite a basse tension |
| Obstacle | RSSI chute sur un scanner, retarde sur autres | Nouvelle barriere physique |
5.3 Seuils Statistiques
Fenetre glissante (1 heure, 3600 echantillons a 1s) :
RSSI moyen : mu = sum(RSSI_i) / N
Ecart-type : sigma = sqrt(sum((RSSI_i - mu)^2) / N)
Alerte si : |RSSI_actuel - mu| > 3 * sigma (99,7% confiance)
5.4 Surveillance de l’Intervalle d’Advertising
Certains beacons derivent leur intervalle en raison de la tolerance du cristal ou de bugs firmware :
Attendu : 1000ms +/- 50ms (spec BLE permet +/- 50ms de gigue)
Mesure : temps entre les scans consecutifs du meme beacon
>1100ms ou <900ms de maniere constante : probleme firmware
Variance elevee (>200ms ecart-type) : instabilite de l'oscillateur
6. Pipeline de Donnees de Telemetrie
6.1 Estimation du Volume de Donnees
500 beacons a 1Hz, scannes par 20 gateways :
Paquets par beacon par seconde : 1
Paquets par gateway par seconde : 500 / 3 = 167
Paquets par flotte par seconde : 167 * 20 = 3.340
Paquets par jour : 3.340 * 86.400 = 288.576.000
Par paquet (JSON) : ~200 octets
Volume quotidien : 57,7 Go brut
Avec deduplication :
Apres dedup : 1.440.000
Volume dedup : 288 Mo/jour
6.2 Architecture de Pipeline Recommandee
Beacons
|
Gateways (scan 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)
6.3 Stack Logicielle du Gateway
| Composant | Technologie | Objectif |
|---|---|---|
| Scanner BLE | Python + bleak / C + BlueZ | Scanner les paquets d’advertising |
| Filtre de dedup | Custom (fenetre 30s par beacon) | Eliminer les scans dupliques |
| Buffer local | SQLite / Redis | Survivre aux coupures reseau |
| Client MQTT | paho-mqtt / Eclipse Paho | Transferer vers le cloud |
| Agent de sante | watchdog systemd | Redemarrage auto en cas de panne |
6.4 Schema de Donnees
{
"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. Comparaison des Plateformes de Gestion de Dispositifs
| Plateforme | Support Beacon | OTA | Limite de Flotte | Modele de Prix | Self-Hosted |
|---|---|---|---|---|---|
| Kontakt.io Panel | Complet (beacons Kontakt) | Oui | 100.000+ | Par beacon/mois | Non |
| Estimote Cloud | Complet (beacons Estimote) | Oui | 50.000+ | Par beacon/mois | Non |
| RadBeacon Dashboard | Complet (RadBeacon uniquement) | Oui | 10.000+ | Gratuit (lock-in hardware) | Non |
| BeeCastle / BlueUp | Complet (proprietaire) | Oui | 5.000+ | Par beacon/mois | Non |
| Custom (Open Source) | Tout beacon avec GATT | Custom | Illimite | Cout d’infra | Oui |
7.1 Decision Build vs Buy
| Facteur | Buy (Managed) | Build (Custom) |
|---|---|---|
| Temps de setup | 1-2 jours | 2-4 semaines |
| Cout mensuel (500 beacons) | 250-500 $/mois | 50-100 $ (infra cloud) |
| Flexibilite | Limitee aux fonctionnalites de la plateforme | Controle total |
| Support multi-vendor | Generalement single-vendor | Tout beacon GATT |
| Fiabilite OTA | Geree par le vendeur | Votre responsabilite |
8. Considerations de Securite pour la Gestion de Flotte
8.1 Authentification de Configuration
Toutes les ecritures de configuration doivent etre authentifiees. Recommande : AES-128 challenge-response :
1. Le scanner envoie un challenge (16 octets aleatoires)
2. Le beacon calcule HMAC-SHA256(challenge, cle_partagee), tronque a 16 octets
3. Le beacon envoie la reponse
4. Le scanner verifie
5. Session de config chiffree proceede (AES-128-CCM)
8.2 Rotation des Cles
| Type de Cle | Portee | Periode de Rotation | Mecanisme |
|---|---|---|---|
| Cle d’auth de config | Par beacon | 12 mois | Commande de rotation OTA |
| Cle de signature OTA | Par flotte | 6 mois | Mise a jour firmware avec nouvelle cle |
| Cle API de gateway | Par gateway | 3 mois | Rotation via dashboard cloud |
| Certificat MQTT broker | Par gateway | 12 mois | Renouvellement auto |
8.3 Detection de Beacon Rogue
| Verification | Methode | Condition d’Alerte |
|---|---|---|
| Allowlist MAC | Comparer MAC scannee avec liste enregistree | MAC inconnu emettant l’UUID de flotte |
| Signature de payload | HMAC dans les donnees constructeur | Signature invalide |
| Geofence RSSI | Comparer RSSI avec plage attendue | RSSI inconsistent avec l’emplacement |
| Version firmware | Lire via GATT | Version firmware inconnue |
9. Automatisation du Deploiement
9.1 Configuration Pre-Deploiement
Workflow :
1. Connecter le beacon via dock USB (chargeur de lot de 10)
2. Lire l'adresse MAC
3. Attribuer l'ID du beacon et l'emplacement du plan de deploiement
4. Ecrire la configuration (UUID, major, minor, intervalle, puissance TX)
5. Ecrire la cle d'authentification
6. Verifier la configuration par scan
7. Enregistrer dans la base de donnees d'inventaire
8. Marquer comme "pret pour deploiement"
Temps par beacon : 15-20 secondes
500 beacons : ~2,5 heures
9.2 Verification d’Installation
Apres installation physique, parcourir le site avec une app scanner :
Pour chaque beacon :
1. Scanner a l'emplacement attendu
2. Verifier RSSI dans la plage attendue (-40 a -80 dBm)
3. Verifier le payload d'advertising correct
4. Verifier la tension de batterie > 2,8V
5. Marquer comme "installe et verifie"
Temps : 500 beacons / 30 emplacements : ~4-6 heures
9.3 Verification de Sante Post-Deploiement
Verification automatisee de 24 heures apres deploiement :
| Verification | Seuil | Action en cas d’Echec |
|---|---|---|
| Tous les beacons vus | 100% | Investiguer les beacons manquants |
| RSSI dans la plage | 95% dans +/- 10dB | Verifier le placement |
| Tension batterie > 2,8V | 100% | Remplacer les batteries faibles |
| Intervalle d’advertising correct | 100% | Reconfigurer |
| Pas de beacons rogue | 0 MAC inconnus | Investiguer |
10. Etude de Cas : Deploiement Retail de 500 Beacons
10.1 Configuration
- Beacons : 500 unites, nRF52832, CR2032, advertising 1 seconde
- Emplacements : 30 magasins (15-20 beacons chacun)
- Gateways : 60 unites (2 par magasin), Raspberry Pi 4 + dongle BLE
- Cas d’usage : Marketing de proximite + navigation interieure
- Monitoring : Plateforme custom (Python + MQTT + InfluxDB + Grafana)
10.2 Metriques Operationnelles (Annee 1)
| Metrique | Valeur | Notes |
|---|---|---|
| Total beacons deployes | 500 | 30 magasins |
| Beacons remplaces (batterie) | 12 (2,4%) | Moyenne 380 jours au remplacement |
| Beacons remplaces (defaut) | 3 (0,6%) | 2 blocages firmware, 1 panne hardware |
| Mises a jour OTA poussees | 2 | Correctifs mineurs de firmware |
| Echecs OTA | 0 | Rollback double banque a fonctionne une fois |
| Uptime moyen | 99,6% | 4,2 beacons hors ligne a tout moment |
| Temps moyen de detection | 8 minutes | Via monitoring de heartbeat |
| Temps moyen de reparation | 2,5 jours | Technicien avec remplacement |
| Cout mensuel de monitoring | 85 $ | AWS (EC2 + RDS + S3) |
| Cout mensuel de gateway | 60 $ | Backhaul cellulaire (60 x 1 $) |
10.3 Lecons Apprises
1. La redondance de gateway est critique : Un gateway par magasin causait des angles morts pendant les redemarrages. Deux gateways avec couverture chevauchante a elimine cela.
2. La prediction de batterie fonctionne : Le modele de moyenne mobile sur 14 jours a predit 10 des 12 pannes de batterie dans les 7 jours precedant la panne reelle.
3. Le blocage de firmware est le tueur silencieux : 2 beacons se sont bloques avec watchdog desactive. Watchdog externe (IC de reset hardware) ajoute dans le hardware v2.
4. Le geofencing RSSI a detecte 1 vol : Un beacon a ete deplace vers un autre magasin. Le changement de motif RSSI a declenche une alerte en 30 minutes.
11. Checklist de Gestion de Flotte
- [ ] Plan de deploiement avec ID de beacon, emplacement et configuration pour chaque dispositif
- [ ] Workflow de configuration en lot pre-deploiement (dock USB + script d’automatisation)
- [ ] Reseau de gateways avec couverture chevauchante (minimum 2 par emplacement)
- [ ] Broker MQTT avec TLS et QoS 1
- [ ] Base de donnees de series temporelles pour les donnees de scan (InfluxDB ou ClickHouse)
- [ ] Monitoring de heartbeat avec timeout configurable par intervalle d’advertising
- [ ] Suivi de la tension de batterie avec prediction de moyenne mobile sur 14 jours
- [ ] Detection d’anomalies RSSI (fenetre glissante de 3-sigma)
- [ ] Pipeline d’alertes (email/SMS/Slack) avec regles d’escalade
- [ ] Configuration a distance basee sur GATT avec authentification AES-128
- [ ] OTA a double banque avec deploiement echelonne (1% / 5% / 20% / 50% / 100%)
- [ ] Cle de signature OTA et calendrier de rotation des cles
- [ ] Detection de beacon rogue (allowlist MAC + signature de payload)
- [ ] Verification d’installation avec app scanner
- [ ] Verification automatisee de sante 24 heures post-deploiement
- [ ] Dashboard de flotte montrant le statut, la batterie et les alertes d’anomalies
- [ ] Inventaire de beacons de remplacement (5% de la taille de flotte)
- [ ] Procedure de dispatch de technicien avec objectifs SLA
- [ ] Rapport mensuel de sante de flotte (uptime, pannes, tendances de batterie)
- [ ] Rotation annuelle des cles et audit de securite
12. Resume
La gestion de flotte de beacons est un probleme d’ingenierie systeme, pas un probleme de hardware. Les beacons sont simples ; l’infrastructure autour d’eux est complexe. Points cles :
1. Les donnees de scan sont votre seul canal de retour. Concevez votre pipeline autour de ce que vous pouvez observer passivement.
2. L’OTA a double banque est non negociable pour toute flotte de plus de 50 beacons. Le filet de securite du rollback se rentabilise des la premiere mise a jour echouee.
3. La prediction de batterie a partir des tendances de tension est precise a 7 jours pres si vous utilisez une moyenne mobile sur 14 jours. Remplacez les beacons de maniere proactive avant qu’ils ne se taisent.
4. Le monitoring de heartbeat avec timeout de 5 minutes detecte 95% des pannes en 15 minutes.
5. Le deploiement OTA echelonne (1% a 100% sur 9 jours) previent le brickage de toute la flotte.
6. La redondance de gateway (2 par site avec couverture chevauchante) elimine les angles morts pendant la maintenance.
Pour les organisations deployant une infrastructure de Bluetooth Beacon a grande echelle, la plateforme de gestion de flotte est la ou se fait le veritable ingenierie. Les Beacons sont des commodites ; le pipeline de monitoring, de configuration et d’OTA est ce qui differencie un deploiement qui se gere de lui-meme d’un deploiement necessitant une intervention manuelle constante.
