Un fournisseur vous dira qu’un capteur LoRaWAN fonctionne dix ans sur une seule pile. Ce chiffre peut être exact. Il peut aussi être faux d’un facteur cinq pour exactement le même matériel, parce que la durée de vie de la pile en LoRaWAN dépend de la configuration, pas d’une caractéristique matérielle. La réponse honnête à “combien de temps tiennent ces piles” se situe entre environ un an et près de dix ans, et l’endroit où vous tombez dans cette fourchette dépend de la fréquence à laquelle l’appareil émet, de sa distance à un gateway, et de la possibilité laissée au réseau de régler la radio à votre place.
La vraie question de planification n’est donc pas “combien de temps tient la pile”. C’est “qu’est-ce que je demande à cet appareil de faire, et combien cela coûte en énergie”. Si vous vous trompez, soit vous surdimensionnez avec des piles plus grosses dont vous n’aviez pas besoin, soit vous déployez des capteurs qui s’éteignent sur le terrain un an avant la date prévue. Voici ce qui détermine réellement ce chiffre, ce que change l’Adaptive Data Rate, et comment repérer une pile qui faiblit avant qu’elle ne laisse un appareil hors service.
Ce qui vide vraiment une pile LoRaWAN
Un capteur basse consommation passe l’essentiel de sa vie en veille, à ne presque rien consommer. L’énergie part lors de l’émission. Donc tout ce qui augmente la durée ou la fréquence d’allumage de la radio vous coûte cher.
La fréquence des uplinks est le plus gros levier que vous contrôlez directement. Un capteur qui remonte une donnée une fois par heure durera plus longtemps que le même capteur remontant une donnée toutes les minutes, souvent de plusieurs années, parce qu’il consacre soixante fois moins d’efforts à émettre. La taille du payload compte pour la même raison : un message plus long met plus de temps à partir, et un temps d’antenne plus long, c’est plus d’énergie.
La distance au gateway détermine le spreading factor, et le spreading factor détermine le temps d’antenne. Un appareil proche d’un gateway peut fonctionner en SF7, expédier un message vite, et se rendormir. Poussez-le en limite de couverture et il grimpe en SF12, où le même message reste bien plus longtemps à l’antenne et consomme bien plus d’énergie, de l’ordre de vingt fois plus pour une seule émission. Un capteur qui “se connecte encore” en limite de portée est souvent celui qui meurt en premier.
Les messages confirmés ajoutent un second coût. Quand un appareil demande au réseau d’accuser réception de chaque uplink, il doit garder son récepteur ouvert pour écouter le downlink, et les downlinks obligent le gateway et l’appareil à des échanges supplémentaires. Les fenêtres de réception coûtent moins cher que l’émission, mais elles ne sont pas gratuites, et le trafic confirmé sur chaque message s’accumule vite. La plupart des capteurs de terrain n’ont pas besoin d’une confirmation à chaque relevé.
La température est le facteur discret. Les cellules au lithium perdent de la capacité utile dans le froid, et une chimie qui paraît saine sur un banc à température ambiante se comporte autrement sur un toit en hiver ou dans un boîtier cuit par le soleil. Les extrêmes des deux côtés raccourcissent la durée de vie réelle sous le chiffre de la fiche technique.
Ce qu’est l’ADR et pourquoi il compte
L’Adaptive Data Rate, c’est le réseau qui décide à votre place des réglages radio les moins gourmands qu’un appareil peut adopter tout en restant audible. Le serveur réseau surveille la qualité de signal des derniers uplinks d’un appareil. Si l’appareil arrive avec un signal fort, le serveur lui dit de descendre à un spreading factor plus bas et une puissance d’émission plus faible. Un spreading factor plus bas, c’est un temps d’antenne plus court. Une puissance plus faible, c’est moins d’énergie par émission. Les deux économisent la pile, et l’appareil continue son travail.
Si cela fonctionne, c’est que beaucoup d’appareils fonctionnent bien plus prudemment qu’il ne le faut. Un capteur fixé à un mur à cent mètres d’un gateway sur un toit pourrait émettre en SF10 par précaution alors que le SF7 passerait sans problème. L’ADR repère cette marge et la récupère. Pour un appareil fixe avec une couverture stable, activer l’ADR revient à de la durée de vie de pile quasi gratuite, et c’est le réglage le plus important à bien régler.
L’ADR est conçu pour les appareils qui ne bougent pas et dont les conditions radio restent stables. C’est là qu’il excelle, et c’est là que vous devez l’activer par défaut.
Quand l’ADR aide et quand il ne peut rien
L’ADR fonctionne en apprenant de l’historique, il suppose donc que le passé récent prédit le futur proche. Cette hypothèse tient pour un capteur fixe et tombe pour un capteur en mouvement.
Un appareil sur un actif mobile, un camion, une palette, une personne, voit ses conditions radio changer plus vite que l’ADR ne peut les suivre. Le serveur règle l’appareil à la baisse pour un emplacement à signal fort, l’actif se déplace vers un emplacement faible, et l’appareil émet désormais trop bas pour être entendu. Pour les appareils mobiles, la spécification LoRaWAN recommande de laisser l’ADR désactivé et de laisser l’appareil gérer lui-même son data rate, en général prudemment.
L’ADR ne peut pas non plus corriger une mauvaise couverture. Si un appareil est vraiment en limite, coincé derrière du béton ou loin de tout gateway, il n’y a aucun réglage plus bas à lui donner. Le serveur le maintiendra au spreading factor élevé dont il a besoin, et la pile en paie le prix. L’ADR optimise dans la couverture dont vous disposez. Il ne crée pas de couverture. Un appareil bloqué en SF12 parce qu’il se trouve dans une zone morte est un problème de couverture, et la solution est un gateway mieux placé ou supplémentaire, pas un réglage radio.
Étapes concrètes pour prolonger la pile
L’énergie la moins chère est le message que vous n’envoyez jamais. Commencez par là.
Ralentissez l’intervalle de remontée jusqu’à la cadence la plus lente que votre cas d’usage tolère. Un relevé de température toutes les quinze minutes au lieu de toutes les minutes est une grosse économie pour une mesure qui évolue rarement aussi vite. Émettez sur changement ou sur seuil quand les données le permettent, pour qu’un appareil reste muet tant qu’il ne se passe rien.
Gardez des payloads courts et désactivez les messages confirmés sauf si le relevé doit vraiment être accusé réception. Réservez la confirmation à la poignée d’événements qui comptent, pas à la télémétrie de routine. Activez l’ADR sur chaque appareil fixe, et laissez-le désactivé pour tout ce qui bouge. Placez bien les gateways pour que les appareils tiennent un spreading factor bas, car la hauteur et le placement des gateways font plus pour la durée de vie des piles d’une flotte que n’importe quel réglage appareil par appareil. Et dimensionnez la pile pour le bas de la plage de température que l’appareil verra réellement, pas pour le banc d’essai.
Surveillez la pile avant qu’elle ne meure
Tout ce qui précède fixe la durée de vie théorique d’une pile. Rien de tout cela ne vous dit quand un appareil précis sur le terrain est sur le point de lâcher, et c’est cette panne qui coûte un déplacement sur site et un trou dans vos données.
La plupart des appareils LoRaWAN remontent l’état de leur pile dans leur statut, sous forme de niveau ou de tension, en même temps que leurs relevés. TagoIO ingère cette télémétrie de pile de la même façon que n’importe quelle autre variable, via son LoRaWAN network server et ses intégrations MQTT, et la stocke par appareil. À partir de là, vous la posez sur un dashboard, pour qu’une flotte de capteurs affiche d’un coup d’œil l’état actuel des piles et qu’une courbe de tendance montre lesquelles déclinent. Ce qui évite vraiment le déplacement, c’est l’alerte : fixez un seuil, et TagoIO vous prévient quand un appareil le franchit, bien avant que la cellule soit à plat. Vous remplacez une pile lors d’une visite planifiée au lieu de découvrir un capteur mort une fois que la donnée a déjà disparu.
TagoIO est agnostique en matière de connectivité et côté plateforme, donc une flotte mixte d’appareils LoRaWAN et cellulaires remonte la pile au même endroit avec une seule configuration d’alerte. La plateforme est certifiée ISO 27001 et alignée GDPR pour les équipes qui en ont besoin. La radio décide combien de temps la pile dure. La plateforme s’assure que vous le voyez venir.
