La consommation des capteurs IoT
Découvrez comment réduire la consommation énergétique des capteurs IoT LoRaWAN et prolonger leur autonomie grâce aux bons réglages.
La faible consommation énergétique est l’un des principaux avantages des capteurs IoT utilisant la technologie LoRaWAN. Conçus pour fonctionner plusieurs années sur batterie, ces équipements sont particulièrement adaptés aux applications industrielles, au Smart Building ou encore aux villes intelligentes. Cependant, leur autonomie dépend de nombreux paramètres : fréquence des transmissions, qualité du réseau, classe LoRaWAN ou encore Spreading Factor. Comprendre les facteurs qui influencent la consommation des capteurs IoT est donc essentiel pour optimiser leur fonctionnement et prolonger leur durée de vie.
Comprendre la consommation des capteurs IoT
Les facteurs de consommation
Un capteur IoT ne consomme pas la même quantité d’énergie en permanence. Sa consommation varie selon les opérations réalisées et le temps passé dans chaque état de fonctionnement. On distingue quatre phases principales :
- La veille (Deep Sleep) : le capteur désactive la majorité de ses composants afin de réduire au maximum sa consommation énergétique. C’est généralement dans cet état qu’il passe le plus de temps, entre deux mesures ou transmissions, afin de préserver sa batterie.
- La mesure : le capteur active ses composants pour relever une information, comme la température, l’humidité ou la concentration en CO₂. La consommation dépend du type de capteur, de la technologie de mesure et de la fréquence des relevés.
- L’émission (Tx) : le module radio transmet les données collectées vers le réseau LoRaWAN. Cette opération nécessite un courant relativement important, dont l’impact sur la batterie dépend notamment de la puissance d’émission et de la durée de transmission.
- La réception (Rx) : le capteur active son récepteur radio pour écouter les éventuelles réponses du réseau. Cette phase consomme également de l’énergie, notamment lors des mises à jour FUOTA qui nécessitent la réception de nombreuses trames. Cette fonctionnalité n’est toutefois pas disponible sur tous les capteurs.
La fréquence de transmission joue également un rôle majeur dans l’autonomie des capteurs IoT. Un capteur envoyant une mesure toutes les minutes sollicitera davantage sa batterie qu’un équipement transmettant toutes les heures, puisque chaque communication nécessite une phase d’émission et, selon la classe LoRaWAN, des périodes de réception. Il est donc essentiel d’adapter cette fréquence aux besoins réels de l’application afin de limiter la consommation énergétique et de prolonger la durée de vie de la batterie. Cela peut rapidement être critique.
Le Spread Factor
Le Spreading Factor (SF), ou facteur d’étalement, est un paramètre de la modulation LoRa qui influence la portée radio, le débit de transmission et la consommation énergétique. En Europe, les communications LoRaWAN utilisent couramment des canaux de 125 kHz, correspondant à la largeur de la bande de fréquences utilisée pour transmettre un signal, avec des facteurs allant de SF7 à SF12.
Plus le SF est élevé, plus le signal est robuste et peut être reçu dans des conditions difficiles. En contrepartie, le débit diminue, la transmission dure plus longtemps et consomme davantage d’énergie.
Le Spreading Factor représente donc un compromis entre débit de transmission et fiabilité de la communication.
| Spreading Factor | Portée potentielle | Temps de transmission | Consommation par trame |
|---|---|---|---|
| SF7 | Plus faible | Très court | Très faible |
| SF8 | Faible à modérée | Court | Faible |
| SF9 | Intermédiaire | Modéré | Modérée |
| SF10 | Importante | Long | Élevée |
| SF11 | Très importante | Très long | Très élevée |
| SF12 | Maximale | Le plus long | La plus élevée |
Les classes LoRaWAN
La technologie LoRaWAN définit trois classes de fonctionnement : A, B et C. Contrairement au Spreading Factor, qui influence principalement les caractéristiques de transmission, la classe LoRaWAN détermine les périodes pendant lesquelles un capteur peut recevoir des données du réseau.
Classe A : la plus économe en énergie. Le capteur reste en veille et ne s’active que pour transmettre ses données, puis ouvre deux courtes fenêtres de réception (Rx1 et Rx2). Idéale pour les capteurs sur batterie.
Classe B : un compromis entre autonomie et réactivité. En plus du fonctionnement de la classe A, le capteur ouvre des fenêtres de réception programmées pour recevoir des commandes du réseau.
Classe C : la plus énergivore, mais aussi la plus réactive. Le capteur reste presque constamment en réception, permettant au réseau de communiquer à tout moment. Principalement adaptée aux équipements alimentés sur secteur.
| Critère | Classe A | Classe B | Classe C |
|---|---|---|---|
| Consommation | Faible | Modérée | Élevée |
| Autonomie batterie | 5 à 10 ans et + | 2 à 5 ans | Quelques mois à 2 ans |
| Uplink | À l'initiative du capteur | À l'initiative du capteur | À l'initiative du capteur |
| Downlink | Après chaque uplink | Après uplink + fenêtres programmables | Quasi permanent |
| Utilisation recommandé | Capteurs sur batterie | Commandes périodiques | Commandes en temps réel |
Les bonnes pratiques
Au-delà des caractéristiques techniques, la configuration et les conditions de déploiement jouent un rôle essentiel dans la consommation énergétique des capteurs IoT. Plusieurs bonnes pratiques permettent de limiter les dépenses énergétiques inutiles.
Le piège de l'activation
Il est recommandé de mettre en service la gateway LoRaWAN avant d’allumer les capteurs.
Contrairement à un appareil WiFi, un capteur LoRaWAN ne se connecte pas directement à une gateway. Il transmet ses trames radio sans savoir si une passerelle est présente pour les recevoir.
Lors d’une activation OTAA (Over-The-Air Activation), le capteur envoie une demande d’adhésion au réseau (Join Request) et attend une réponse (Join Accept). Ainsi, si la gateway n’est pas opérationnelle, le capteur peut répéter ses tentatives d’activation selon sa configuration, consommant inutilement de l’énergie.
De même, un capteur déjà activé peut continuer à émettre ses trames sans qu’aucune gateway ne les reçoive. Selon son fonctionnement, l’absence de réponse peut également entraîner des retransmissions ou des tentatives de réactivation.
Il est donc important de vérifier la couverture radio, le fonctionnement de la gateway et sa connexion au serveur réseau avant de déployer les équipements.
Adapter la configuration aux besoins réels
Pour préserver l’autonomie des capteurs IoT, plusieurs paramètres peuvent être optimisés :
Adapter la fréquence de transmission : éviter les envois trop fréquents lorsque l’application ne les nécessite pas.
Privilégier la classe A : limiter les périodes de réception pour les équipements sur batterie.
Optimiser le Spreading Factor : utiliser l’ADR lorsque les conditions radio et la mobilité du capteur le permettent.
Assurer une bonne couverture radio : positionner correctement les gateways et les antennes afin de limiter les pertes de communication.
Éviter les retransmissions inutiles : limiter les messages confirmés aux données nécessitant réellement un acquittement.
Ces réglages permettent de réduire le temps d’activité du module radio et de préserver l’énergie disponible dans la batterie.
Maintenir les capteurs à jour grâce au FUOTA
Le FUOTA (Firmware Update Over The Air) permet de mettre à jour à distance le logiciel d’un capteur IoT, sans intervention physique. Ces mises à jour peuvent corriger des anomalies, optimiser la gestion des communications et des modes veille, et ainsi améliorer l’autonomie de la batterie.
Même si une mise à jour nécessite des échanges radio et consomme de l’énergie, elle peut être plus avantageuse à long terme que de conserver un capteur avec un firmware obsolète, notamment lorsque la nouvelle version apporte des optimisations énergétiques.
Les produits
EM300-TH de Milesight
Vivid de Tektelic
WT101 de Milesight
Cela peut vous intéresser aussi
Tout savoir sur sur les VPN industriels
Tout comprendre sur la géolocalisation par radiofréquence
Tout comprendre sur les certifications ATEX
Comment anticiper la fin de la 2G et de la 3G
Double-SIM vs Double module
