Étude de cas : sondes de température

Cette étude de cas retrace la construction de la sonde de température qui alimente ProbeHarbor : pourquoi un simple thermomètre extérieur ne suffisait pas, comment deux zones DHT22 et une moyenne de synthèse ont été retenues, et ce qui a changé entre la première installation sur platine d’essai et la révision connectée au réseau qui sert aujourd’hui du JSON en direct à ce site.

Le défi

L’objectif était concret, pas théorique : savoir si un garage attenant approchait du risque de gel, si l’humidité montait assez pour faire rouiller les outils, et si les conditions différaient près de la porte et au fond du garage. Les applis météo grand public ne donnent que l’air extérieur à la station la plus proche, qui peut s’écarter d’environ 5 °C (10 °F) ou plus de l’intérieur d’un garage isolé par un après-midi d’hiver ensoleillé.

Un seul capteur aurait masqué les écarts qui comptent. Ouvrir la porte de garage, garer un véhicule encore chaud ou le soleil de l’après-midi sur un mur exposé à l’ouest font évoluer différentes parties de l’espace à des vitesses différentes. L’intérêt de plusieurs sondes était évident avant même la première soudure.

L’environnement

L’espace surveillé est un garage attenant typique : une grande porte basculante, une dalle en béton, une isolation limitée par rapport aux pièces à vivre, et des variations saisonnières dues autant à l’ensoleillement et aux infiltrations d’air qu’à la température extérieure. En été, la zone côté porte est plus chaude ; en hiver, la dalle et le mur nord suivent les minimales extérieures avec plusieurs heures de retard.

• Zone du mur nord : évolue plus lentement ; utile pour suivre la tendance des minimales nocturnes.
• Zone de la porte : grimpe dès que la porte s’ouvre ; révèle les infiltrations rapides.
• Zone de l’établi : représente l’endroit où l’on travaille vraiment, à hauteur d’épaule.

La démo interactive des sondes modélise ces trois zones pour vous montrer comment le soleil et l’état de la porte font diverger les relevés, sans installer de matériel.

Démarche et matériel

Chaque sonde utilise un capteur numérique d’humidité et de température DHT22 relié par un câble court à un Arduino Uno. Le firmware lit les deux capteurs à intervalle régulier, refait une tentative en cas d’erreur passagère du bus, calcule un avg des sondes en bon état et sert un JSON compact sur le réseau local via un shield Ethernet. Un écran LCD 16×2 sur la carte affiche les valeurs en direct pour vérifier sur place sans ordinateur portable.

L’emplacement suit les règles du guide des sondes de température : à l’écart des taches de soleil direct et des extracteurs, à peu près à hauteur d’épaule, avec un montage ventilé pour que l’air circule autour de la tête du capteur. Dans le dashboard, des libellés associent les clés JSON 0 et 1 à des noms de zone lisibles.

Étapes de la construction

1. Mise en route sur l’établi : les journaux série ont confirmé les lectures du DHT22, l’affichage LCD et des clés JSON temp stables avant que la carte ne quitte le bureau.
2. Révision un dans le garage : a prouvé que les écarts entre sondes étaient réels : la zone de la porte s’écartait régulièrement du mur nord aux heures des trajets domicile-travail.
3. Flux JSON réseau : l’Ethernet a évité d’apporter un portable à chaque vérification ; le site pouvait récupérer le même document que celui déjà affiché par l’écran LCD.
4. Révision deux : empilement plus propre du shield Ethernet, connecteurs de sonde améliorés et logique de redémarrage compatible watchdog pour les rares blocages réseau.
5. Intégration au site : les pages Astro associent les flux à des cartes ; l’historique des utilisateurs connectés enregistre des instantanés pour analyser les tendances et exporter en CSV.

Ce que les données ont montré

Après un cycle complet hiver-été, les sondes se sont révélées utiles là où un relevé unique serait passé à côté :

• Près de la porte, la température pouvait varier de 4 à 7 °C (8–12 °F) quelques minutes après l’ouverture de la porte de garage, alors que le mur du fond bougeait à peine.
• Les minimales nocturnes près du mur nord suivaient le risque de gel de façon plus fiable que les seules prévisions extérieures.
• L’humidité augmentait après de longues vagues de froid, quand la dalle tardait à se réchauffer : utile pour savoir quand faire tourner un déshumidificateur.
• La moyenne calculée lissait le bruit des graphiques d’historique, tandis que les cartes par sonde de la page d’accueil gardaient le détail de chaque zone.

Les relevés passent de la sonde au dashboard selon le chemin décrit dans flux de données de bout en bout. Quand il a fallu du TLS en bordure, un relais Python a mis en cache le JSON amont sans reporter cette complexité sur le microcontrôleur.

Leçons retenues

• L’emplacement compte plus que le prix du capteur : un DHT22 bien monté a toujours fait mieux qu’un capteur haut de gamme mal placé.
• Nommez les zones dans le logiciel : des clés JSON stables et des libellés dans le dashboard ont permis de garder firmware et site faiblement couplés.
• Attendez-vous à des trous : redémarrages et micro-coupures réseau créent de courtes lacunes ; distinguez-les d’une mauvaise configuration grâce aux guides sur les relevés obsolètes.
• Prévoyez d’itérer : la révision un sur platine d’essai a évité de remonter à l’échelle quand le brochage a changé.

Pour aller plus loin

Poursuivez avec la présentation des sondes de température, le guide des sketches Arduino, ce qui fait varier les relevés et l’utilisation des données historiques dans le dashboard. Code source du firmware : arduino-network-json-temperature-sever.

FAQ

Quelle est la conclusion de l’étude de cas sur les sondes ?
Des sondes multizones associées à des seuils de gel repèrent des épisodes de froid qu’un capteur unique manque, surtout près des portes et des murs non isolés lors des vagues de froid polaire.