IoT: un capteur de température connecté (2e partie)
Pour la suite du développement de notre capteur de température autonome, on va se focaliser sur la suppression du câble restant: l’alimentation. Il existe plusieurs solutions à base de pile, batterie, panneau solaire; nous allons ici privilégier la simplicité de mise en oeuvre.
Matériel nécessaire:
Niveau montage, cela se fera très simplement en raccordant la pile sur les entrées 3,3V et GND du NodeMCU (attention à débrancher l’USB du PC !). Pour simplifier les connexions, on peut aussi se brancher au niveau des fils rouge et noir du capteur.
Par contre, si on ne change rien côté logiciel, la durée de vie de notre pile risque d’être très courte. En effet, la carte reste alimentée en permanence et continue de gérer ses entrées/sorties et autres, même pendant les appels à ‘delay()’.
Deep-sleep mode
La première amélioration que l’on va apporter est de passer la carte en ‘deep-sleep mode’. Cette fonction permet d’endormir pendant une durée spécifique la quasi-totalité des fonctions de la carte. Ne reste plus que celle permettant de réveiller la carte au moment opportun.
Cette fonction nécessite de modifier le code, ainsi que de relier les pins ‘D0’ et ‘RST’ (reset) pour pouvoir réveiller la carte.
Niveau code, nous allons utiliser une librairie haut-niveau facilitant la mise en veille; il suffit juste de déclarer l’appel à l’objet “TaskManager” à la fin de notre boucle principale.
Limitation des appels réseaux
Effectuer un appel réseau est très couteux en terme de consommation batterie; il faut instancier le wifi, envoyer des données, attendre la réponse puis se déconnecter. Il y a le coût de la communication elle-même (envoyer des ondes Wifi nécessite de la puissance) ainsi que le fait que la carte va rester allumée longtemps pour finaliser cette opération.
Une solution ici est de jouer sur la granularité des données que l’on souhaite recueillir. On va tout d’abord éviter d’envoyer une donnée de température si celle-ci n’a pas changé. En poussant plus loin, il faut se demander si on veut avoir une mise-à-jour dès que la température bouge de 0.01°. Si je veux mesurer la température d’une chambre, toute variation en-dessous de 0.5° semble superflue.
Cela se fera donc en stockant dans l’eeprom de la carte la dernière valeur ‘utile’ récupérée. Tant que la différence entre la nouvelle valeur et cette référence est inférieure à un seuil donné, on ne fait rien.
Il est recommandé de rajouter un garde-fou permettant d’envoyer les données, qu’elles que soient leurs variations, après un certain délai (ou nombre de réveil) pour s’assurer que le capteur est toujours ‘vivant’.
Optimisations additionnelles
L’utilisation du deep-sleep et de mises à jour conditionnelles permet de multiplier par 100 l’espérance de vie de nos batteries, passant de quelques jours à plusieurs mois. Les valeurs précises dépendront du matériel utilisé, de l’environnement (température, humidité, proximité de la borne wifi) ainsi que des réglages choisis sur la mise à jour des données.
Il est possible de gagner encore un peu d’espérance de vie, avec une difficulté de mise en oeuvre très variable. L’opération la plus simple sera de désactiver les logs (appel à “Serial” dans le code) afin de gagner quelques appels systèmes.
Niveau hardware, on peut (délicatement) retirer la led de notification qui clignote au démarrage et lors d’appel réseau; celle-ci peut se révéler énergivore suivant les modèles. Cette opération peut se faire avec un simple cutter.
Enfin, si tout cela ne suffit pas, il faudra envisager de passer sur un autre type de puce supportant un protocole de communication dédié “IoT”, tel que le Bluetooth Low Energy.
Notre capteur est maintenant prêt à fonctionner de manière autonome. Grâce à la remontée du niveau de batterie dans les données, on pourra surveiller la consommation et anticiper le remplacement de la pile.
Merci pour votre lecture 👩💻
Vous avez aimé cet article ? Cliquez sur 👏 en bas de page pour que d’autres lecteurs puissent le trouver !
