ThingsLog a organisé un webinaire consacré à la surveillance IoT basse consommation, l’un des sujets les plus critiques pour les déploiements sur des sites distants ou sans alimentation électrique. Comment vérifier réellement la faible consommation d’un appareil ? Comment calculer l’autonomie d’une batterie en conditions réelles ? Quels sont les modes d’économie d’énergie disponibles sur les technologies NB-IoT et LoRaWAN ? Cet enregistrement de webinaire répond à ces questions essentielles pour tous ceux qui déploient des solutions IoT dans des environnements contraignants.
Table des matières
- Que signifie vraiment “basse consommation” en IoT ?
- Formule de calcul d’autonomie batterie
- Explication du mode PSM (Power Saving Mode)
- Chiffres de consommation réels des enregistreurs ThingsLog
- Quand la basse consommation est essentielle
- Questions fréquentes
Que signifie vraiment “basse consommation” en IoT ?
Dans le marketing des produits IoT, le terme “basse consommation” est souvent utilisé sans définition précise. Pour les ingénieurs et techniciens qui déploient des solutions sur le terrain, la réalité est beaucoup plus nuancée. Un appareil IoT a deux états principaux de consommation : le mode veille (sleep) et le mode transmission (active). En mode veille, un véritable appareil basse consommation consomme quelques microampères (µA) — typiquement 5 à 50 µA. En mode transmission, la consommation monte à plusieurs dizaines ou centaines de milliampères (mA) pendant quelques secondes.
La consommation moyenne d’un appareil IoT se calcule en pondérant ces deux états par leur durée respective dans le cycle de reporting. Si un appareil transmet une fois par heure pendant 2 secondes et reste en veille le reste du temps, la transmission représente 2/3600 = 0,056 % du temps. Même si la consommation en transmission est de 150 mA, sa contribution à la consommation moyenne est faible. C’est la consommation en veille qui détermine en grande partie l’autonomie sur batterie.
Les appareils qui ne sont pas vraiment “basse consommation” peuvent consommer 1 à 10 mA en veille — ce qui paraît faible mais représente des dizaines de fois plus qu’un vrai dispositif optimisé. La différence entre 20 µA et 2 mA en veille est un facteur 100 sur l’autonomie batterie. Un appareil qui devrait durer 10 ans sur batterie avec 20 µA de veille ne tiendra que 5 à 6 semaines avec 2 mA en veille, ce qui illustre l’importance critique de ce paramètre.
Formule de calcul d’autonomie batterie
Le calcul de base de l’autonomie batterie d’un appareil IoT repose sur une formule simple : Autonomie (heures) = Capacité batterie (mAh) / Consommation moyenne (mA). Pour une batterie de 19 000 mAh (taille D, lithium) et une consommation moyenne de 25 µA (0,025 mA), le calcul donne : 19 000 / 0,025 = 760 000 heures, soit environ 87 ans. En pratique, on applique un facteur de correction pour tenir compte de l’autodécharge de la batterie (environ 1-2 % par an pour le lithium), de la variation de capacité selon la température, et des marges de sécurité.
La consommation moyenne se calcule en tenant compte du duty cycle : si l’appareil consomme 150 mA pendant 3 secondes (transmission NB-IoT) toutes les heures, la contribution de la transmission est (150 mA × 3 s) / 3600 s = 0,125 mA·h/h = 0,125 mA en moyenne. Si la consommation en veille est de 19 µA, la consommation totale moyenne est environ 0,144 mA. Avec une batterie de 19 000 mAh : 19 000 / 0,144 ≈ 132 000 heures ≈ 15 ans — en ligne avec les promesses des fabricants de qualité.
Il est important de mesurer la consommation en veille avec un outil adapté — un multimètre standard n’est pas assez précis pour mesurer des courants en µA. ThingsLog recommande l’utilisation d’un analyseur de courant de type Nordic Semiconductor PPK2 ou OTII Arc pour valider les chiffres annoncés et détecter d’éventuels problèmes firmware (réveils intempestifs, timeouts réseau qui empêchent l’entrée en PSM).
Explication du mode PSM (Power Saving Mode)
Le PSM (Power Saving Mode) est un mécanisme standardisé dans les réseaux cellulaires NB-IoT et LTE-M (défini dans les spécifications 3GPP Release 12 et suivantes). Il permet à l’appareil de s’inscrire auprès du réseau, de négocier une période de veille profonde pendant laquelle le réseau ne lui enverra pas de messages, puis de s’éteindre presque complètement jusqu’à son prochain réveil programmé. Pendant la période PSM, l’appareil est invisible du réseau et consomme seulement quelques µA (courant de maintien du RTC et du microcontrôleur en deep sleep).
Le PSM se configure via deux paramètres AT : T3412 (durée de la période de tracking area update, pendant laquelle l’appareil reste “visible” du réseau) et T3324 (durée du timer actif après lequel l’appareil entre en PSM). Ces timers sont négociés avec le réseau opérateur et peuvent varier selon les opérateurs et les pays. ThingsLog configure ses appareils NB-IoT pour maximiser l’utilisation du PSM en fonction de la fréquence de reporting souhaitée par le client.
Pour LoRaWAN, le Class A (le mode par défaut) offre un comportement équivalent au PSM : l’appareil n’écoute le réseau que brièvement après chaque transmission, puis se rendort. C’est la classe la plus économique en énergie, idéale pour les applications de reporting périodique. Les Classes B et C permettent une plus grande réactivité aux commandes descendantes (downlink) mais au prix d’une consommation plus élevée.
Chiffres de consommation réels des enregistreurs ThingsLog
Les enregistreurs de données ThingsLog sont conçus dès le départ pour minimiser leur consommation en veille. En mode PSM actif sur NB-IoT, la consommation en veille profonde est de l’ordre de 19 µA — un chiffre validé par des mesures sur des appareils de production. En mode transmission NB-IoT (envoi d’une trame de données), la consommation pic est d’environ 150 mA pendant 1 à 3 secondes selon la qualité du signal réseau (un signal faible exige plus de tentatives de transmission et consomme plus d’énergie).
Pour LoRaWAN Class A, la consommation en veille est encore plus faible : autour de 5-15 µA selon le microcontrôleur et le design du circuit. La transmission LoRa consomme environ 40-120 mA selon la puissance d’émission et le spreading factor. Ces chiffres permettent d’envisager des autonomies de 5 à 15 ans selon la fréquence de reporting et la taille de la batterie embarquée. ThingsLog propose des batteries de 3 500 mAh (AA lithium) à 19 000 mAh (D lithium) selon les modèles et les besoins d’autonomie.
Quand la basse consommation est essentielle : cas terrain
La surveillance basse consommation est indispensable dans plusieurs types de déploiements. Les compteurs d’eau enterrés dans des bouches à clé ou des regards de trottoir n’ont généralement pas d’alimentation électrique disponible. L’enregistreur doit fonctionner sur batterie pendant 5 à 10 ans pour que le modèle économique du déploiement soit viable (coût d’intervention pour remplacement de batterie prohibitif). Les enregistreurs ThingsLog sont particulièrement adaptés à ces environnements contraignants.
Les capteurs agricoles (humidité du sol, débit d’irrigation, niveau de nappe phréatique) dans des zones sans électricité nécessitent également une autonomie maximale. Une station météo IoT dans un champ peut être alimentée par un panneau solaire de petite taille, mais la batterie de secours doit tenir plusieurs semaines sans ensoleillement. Les enregistreurs ThingsLog peuvent être interfacés avec des capteurs agricoles standard (4-20 mA, SDI-12) pour ces applications.
Les sites de pompage isolés, les stations de mesure piézométrique (niveau de nappe), les capteurs de pression en réseau d’eau dans des zones rurales — tous ces cas de figure bénéficient directement de la basse consommation des enregistreurs ThingsLog. La capacité à fonctionner pendant des années sans maintenance est un critère de sélection décisif pour les ingénieurs qui dimensionnent ces déploiements.
| Thème | Élément clé |
|---|---|
| Veille ThingsLog NB-IoT | ~19 µA en deep sleep PSM |
| Transmission NB-IoT | ~150 mA pic, 1-3 secondes |
| Formule autonomie | Capacité (mAh) / Consommation moyenne (mA) |
| Mode PSM | Standard 3GPP — négocié avec le réseau opérateur |
| Cas d’usage clés | Compteurs enterrés, agriculture, sites isolés sans électricité |
Questions fréquentes
Comment vérifier que l’appareil IoT est vraiment en mode basse consommation et non juste en veille partielle ?
La seule façon fiable de vérifier la consommation réelle en veille est de mesurer directement le courant avec un analyseur de courant de précision comme le Nordic PPK2 ou l’Otii Arc. Ces outils enregistrent le courant en continu avec une résolution µA et affichent les profils temporels de consommation. On peut ainsi vérifier l’entrée effective en PSM (chute de courant à quelques µA), détecter des réveils intempestifs (spikes réguliers révélant un problème firmware) et calculer la consommation moyenne sur un cycle complet. Les valeurs annoncées dans les fiches techniques doivent être validées sur des appareils de série en conditions réelles.
Quelle est l’autonomie typique d’un enregistreur ThingsLog en reporting horaire ?
En reporting horaire sur NB-IoT avec une batterie D-size de 19 000 mAh, l’autonomie typique d’un enregistreur ThingsLog est de 8 à 12 ans dans des conditions normales (température de 10 à 25 °C, bonne couverture réseau). Ce calcul tient compte d’environ 19 µA en veille et de 150 mA pendant 2 secondes par heure pour la transmission. La température est un facteur clé : à -10 °C, les batteries lithium perdent 20 à 30 % de leur capacité nominale, réduisant l’autonomie dans les installations extérieures en zones froides.
Peut-on augmenter la fréquence de reporting sans sacrifier l’autonomie batterie ?
Augmenter la fréquence de reporting a un impact direct sur l’autonomie, mais cet impact est modéré tant que la consommation en veille reste dominante. Passer de 1 transmission par heure à 4 transmissions par heure (toutes les 15 minutes) quadruple la contribution de la transmission à la consommation moyenne, mais si la veille représente 99 % du temps, l’impact global reste limité à quelques dizaines de pourcents d’autonomie en moins. ThingsLog offre une flexibilité de configuration : on peut choisir entre un enregistrement local toutes les 15 minutes (stocké en mémoire) et une transmission horaire ou quotidienne vers le cloud, permettant une granularité fine sans compromettre l’autonomie.
