Un seul Beacon est facile à oublier une fois collé au mur. Le problème commence à l’échelle : un entrepôt de 500 beacons, un hôpital de 2000, un campus de 8000. Quand l’un meurt, on ne le remarque qu’une zone s’assombrit. Cet article couvre comment garder une flotte de Beacon observable : télémétrie, alertes batterie, état online/offline et pousser la config à des milliers d’unités sans les toucher.
Ce qu’un Beacon doit remonter
Chaque Beacon géré doit émettre un petit battement de santé à côté de son advertising, par connexion ou via un gateway qui écoute et relaie :
- Tension / pourcentage batterie : le meilleur signal d’alerte précoce.
- Dernier RSSI et Tx power de référence : détecte radio défaillante ou unité déplacée.
- Uptime et cause de reset : un beacon qui reset chaque heure a un défaut d’alim ou firmware.
- Version firmware : pour savoir ce qui est sur le terrain.
- Compteurs paquets/adv : un compteur gelé signe un stack bloqué.
Gardez le battement petit : quelques octets toutes les heures suffisent ; on suit des tendances, on ne streame pas.
Seuils d’alerte batterie
Un Beacon en CR2477 à intervalle 1 s démarre vers 3.0 V et chute lentement, puis falaise près de 2.4 V. Fixez deux seuils :
| Niveau | Tension | Action |
|---|---|---|
| Sain | > 2.7 V | aucune |
| Avertissement | 2.5-2.7 V | remplacement sous 60 jours |
| Critique | < 2.5 V | remplacez maintenant, marquez lieu |
N’attendez pas 2.0 V : à ce stade le beacon lâche déjà des paquets par intermittence et donne de fausses positions.
Détection online / offline
Le cœur du dashboard est de savoir qui vit. Un Beacon qu’un gateway n’a pas entendu sur N intervalles est « stale » ; un non vu depuis M minutes est « offline ». Typique : stale après 3 intervalles manqués (~3-15 s), offline après 10-30 min. Gatez l’alerte sur offline, pas stale, pour éviter les faux positifs d’un trou momentané du gateway.
Push de config en masse
Quand vous changez l’intervalle ou les major/minor sur toute la flotte de Beacon, ne visitez pas chacun. Deux motifs marchent :
- Relais gateway : le gateway reçoit un blob de config par MQTT/HTTP et le relaie aux beacons proches par connexion ou commande broadcast (voir article downlink). Une commande atteint des centaines.
- Self-fetch planifié : chaque beacon se réveille, connecte et tire sa config d’un serveur en planning décalé, évitant une tempête.
Authentifiez chaque commande : un push sans signature est le rêve d’un attaquant.
Cycle de reconfig à distance
Un déploiement discipliné de Beacon traite la config comme un état versionné :
1. Autorisez config v2 dans la console (intervalle, tx power, payload).
2. Canary : poussez à 1% de la flotte, surveillez resets ou pics offline.
3. Déployez le reste en planning décalé.
4. Gardez v1 pour rollback instantané si les métriques chutent.
C’est la même discipline de livraison progressive du cloud, appliquée à de petites radios.
Sécurité de la télémétrie
Données de santé = données. Un Beacon qui rapporte batterie et position est un bon side channel pour un attaquant qui cartographie votre plan. Envoyez la télémétrie sur canal chiffré et authentifié, et signez la config pour qu’un gateway rogue ne usurpe pas le propriétaire.
Construire le dashboard
Le dashboard n’a besoin que de quatre vues : carte online/offline, histogramme batterie, répartition version firmware et flux d’alertes récentes. La plus grande valeur est dans l’histogramme batterie : il dit aujourd’hui la charge de remplacement du mois prochain.
Une flotte de Beacon bien instrumentée transforme « quelque chose cloche quelque part » en « l’unité 4821 du rayon 7 tombe sous 2.5 V mardi prochain » : c’est la différence entre une équipe de maintenance et une alarme incendie.