Arduino DHT11 code : tutoriel

Programmer un capteur DHT11 avec Arduino ouvre l’accès à la mesure de la température et de l’humidité pour une multitude de projets domotiques, de surveillance et d’expérimentation. Le composant semble simple, pourtant son protocole de communication impose une gestion rigoureuse du timing, sous peine d’obtenir des valeurs erronées.

Ce tutoriel propose un code Arduino prêt à l’emploi, des explications claires ligne par ligne, ainsi que les bonnes pratiques matérielles pour fiabiliser les mesures. De la première lecture de données jusqu’aux optimisations plus avancées, chaque étape prépare le terrain pour des montages plus ambitieux et des capteurs plus évolués.

Comprendre le capteur DHT11 avant d’écrire une ligne de code Arduino

Le DHT11 est un capteur numérique combinant un capteur de température et un capteur d’humidité relative dans un même boîtier. Il transmet les données via une ligne de données unique selon un protocole propriétaire de type 1-Wire (différent du bus 1-Wire Dallas/Maxim standard).

Ce capteur convient aux projets pédagogiques, aux prototypes rapides et aux montages à faible coût. Son utilisation avec une carte Arduino nécessite cependant une compréhension minimale de ses limites, de ses caractéristiques électriques et de sa cadence d’échantillonnage.

22 septembre 2026

Code erreur E03 sur un lave-linge Candy : 3 contrôles avant d’appeler un réparateur

0 commentaires

Caractéristiques techniques du DHT11 à connaître

Les spécifications du DHT11 conditionnent directement la structure du code Arduino et la fréquence d’appel des fonctions de lecture. Voici les principaux paramètres :

• Tension de fonctionnement : 3,3 à 5,5 V, compatible directement avec la plupart des cartes Arduino (UNO, Nano, Mega).
• Courant de fonctionnement : 0,3 mA en mesure, 60 µA en veille, avec des pointes proches de 2,5 mA.
• Température : plage typique de 0 à 50 °C, résolution de 1 °C, précision ±2 °C, répétabilité ±1 °C.
• Humidité relative : plage 20 à 90 % RH (versions étendues 5 à 95 % RH), résolution 1 % RH, précision ±5 % RH, hystérésis ±1 % RH, stabilité annuelle autour de ±1 % RH/an.
• Période d’échantillonnage : intervalle minimal conseillé supérieur à 2 secondes entre deux lectures.
• Temps de réponse : entre 6 et 30 s pour la température, 6 à 15 s pour l’humidité.

La mécanique de lecture reflète ces contraintes : une requête toutes les 200 ms ne donne pas plus de d’informations mais surcharge le microcontrôleur et produit des valeurs inutiles.

Structure interne du signal numérique DHT11

Le DHT11 communique par une trame de 40 bits. Chaque mesure fait transiter successivement :

• 8 bits pour l’humidité entière,
• 8 bits pour l’humidité décimale (souvent 0 sur le DHT11),
• 8 bits pour la température entière,
• 8 bits pour la température décimale,
• 8 bits de checksum (somme des quatre octets précédents).

Le capteur transmet chaque bit par une impulsion de durée variable. Le microcontrôleur doit mesurer cette durée afin de déterminer si le bit est un 0 ou un 1. Le protocole impose une précision temporelle stricte, ce qui explique les difficultés rencontrées avec du bit-banging manuel.

« Le DHT11 est simple à utiliser avec une bibliothèque adaptée, mais son protocole exigeant en timing produit des lectures corrompues lorsqu’il est piloté avec des fonctions de délai trop imprécises ou dans des boucles lourdes. »

Pour contourner ces contraintes, l’approche la plus robuste consiste à utiliser une bibliothèque éprouvée plutôt qu’un code maison basé uniquement sur les fonctions delay() et digitalRead().

Branchements Arduino DHT11 : câblage fiable et bonnes pratiques

Avant de rédiger le code Arduino, le câblage doit être correct. Un branchement approximatif génère des valeurs incohérentes ou des capteurs figés sans message d’erreur évident.

21 septembre 2026

Code erreur sur un lave-linge Bosch : décoder la panne et éviter une réparation inutile

0 commentaires

Schéma de câblage typique du DHT11 avec Arduino

Le DHT11 existe sous deux formes :

• version brute à 4 broches (VCC, DATA, NC, GND),
• module monté sur PCB avec résistance de pull-up intégrée et parfois une LED.

Pour un DHT11 classique en boîtier 4 pins, le câblage standard avec une Arduino UNO ressemble à ceci :

• VCC → 5 V (ou 3,3 V selon la carte et le montage global),
• GND → GND Arduino,
• DATA → pin numérique 2 (par exemple),
• Résistance de pull-up de 4,7 kΩ à 10 kΩ entre DATA et VCC.

Le capteur reste sensible aux perturbations sur la ligne de données. Un câblage propre, des longueurs de fil raisonnables et une bonne masse commune réduisent les problèmes aléatoires.

Orientation des broches et erreurs fréquentes

Les boîtiers DHT11 possèdent des dimensions compactes (environ 15,5 x 12 x 5,5 mm) avec un espacement de broches de 2,54 mm. Selon les fabricants, l’ordre des broches peut varier légèrement, surtout pour les modules déjà montés.

Les erreurs classiques proviennent :

• d’une inversion VCC/GND, fatale pour le composant,
• d’une mauvaise identification de la broche DATA,
• d’une absence de pull-up externe lorsque le module ne l’intègre pas d’origine.

Une courte consultation de la fiche technique fournit le schéma exact du brochage. Cette étape évite de devoir diagnostiquer un problème logiciel qui provient en réalité d’un simple câble mal positionné.

21 septembre 2026

Erreur L11-06 sur Livebox 4 : 4 vérifications avant d’appeler Orange

0 commentaires

Arduino DHT11 code simple avec bibliothèque : la méthode la plus fiable

Le moyen le plus stable d’utiliser un DHT11 sur Arduino repose sur une bibliothèque spécialisée. Ces bibliothèques gèrent le timing, le protocole et la vérification du checksum, ce qui limite les lectures corrompues et réduit la charge CPU.

Installation de la bibliothèque DHT pour Arduino

Sous l’IDE Arduino classique, l’installation suit un parcours direct :

• Ouvrir Outils > Gérer les bibliothèques…,
• rechercher DHT sensor library (Adafruit, par exemple),
• cliquer sur Installer,
• ajouter éventuellement la bibliothèque Adafruit Unified Sensor si la version retenue en dépend.

Une fois installée, la bibliothèque propose plusieurs exemples préconfigurés, souvent nommés DHTtester ou équivalents. Ces exemples servent de base solide pour construire un code adapté au projet.

Code Arduino DHT11 minimal fonctionnel

Voici un exemple complet et commenté de code Arduino pour lire la température et l’humidité avec un DHT11 sur la broche numérique 2 :

#include <DHT.h>

#define DHTPIN 2        // Broche de données du DHT11
#define DHTTYPE DHT11   // Type de capteur utilisé

DHT dht(DHTPIN, DHTTYPE);

void setup() {
  Serial.begin(9600);
  dht.begin();
}

void loop() {
  // Respecter un délai d'au moins 2 secondes entre deux lectures
  delay(2000);

  float humidity = dht.readHumidity();
  float temperature = dht.readTemperature(); // Température en °C par défaut

  if (isnan(humidity) || isnan(temperature)) {
    Serial.println("Erreur de lecture DHT11");
    return;
  }

  Serial.print("Humidite: ");
  Serial.print(humidity);
  Serial.println(" %");

  Serial.print("Temperature: ");
  Serial.print(temperature);
  Serial.println(" *C");
}

Ce code fournit une base saine. Il respecte le délai minimal entre deux lectures et gère les cas d’échec via le test isnan(). Ce contrôle évite d’exploiter des valeurs fantaisistes dans le reste du programme.

Adaptation du code à d’autres broches ou à plusieurs capteurs

Pour utiliser une autre broche numérique, il suffit de modifier la constante DHTPIN. La bibliothèque gère indifféremment les broches numériques classiques, sous réserve d’éviter les broches déjà utilisées par d’autres modules sensibles (interruptions, bus, etc.).

Pour plusieurs DHT11, l’approche consiste à instancier plusieurs objets DHT avec des broches distinctes :

DHT dht1(2, DHT11);
DHT dht2(3, DHT11);

void setup() {
  Serial.begin(9600);
  dht1.begin();
  dht2.begin();
}

void loop() {
  delay(2000);
  float h1 = dht1.readHumidity();
  float t1 = dht1.readTemperature();
  float h2 = dht2.readHumidity();
  float t2 = dht2.readTemperature();
  // Traitement des données...
}

Chaque capteur impose son propre délai minimal entre deux mesures. Mieux vaut organiser la boucle principale en conséquence, surtout dans un système contenant déjà des tâches périodiques (relevé de capteurs, envoi réseau, gestion d’affichage).

Code Arduino DHT11 sans bibliothèque : bit-banging et gestion du timing

Certains projets exigent un contrôle total du protocole ou un fonctionnement sans dépendance externe. Dans ce contexte, une implémentation manuelle du dialogue DHT11 avec Arduino reste possible, mais présente plusieurs pièges.

Principe du protocole DHT11 en bit-banging

La séquence de communication suit une chronologie stricte :

• L’Arduino force la broche DATA à l’état bas pendant 18 ms environ.
• Il relâche la ligne en entrée (état haut via pull-up).
• Le DHT11 répond par une séquence d’impulsions de synchronisation.
• Le capteur envoie ensuite 40 bits, chacun sous forme d’une impulsion dont la durée détermine la valeur (0 ou 1).

L’Arduino doit mesurer des impulsions de quelques dizaines de microsecondes, avec une précision suffisante pour distinguer les deux états logiques. Une boucle while qui bloque le processeur et monopolise le CPU durant toute la lecture est courante dans ce type d’implémentation.

« La lecture du DHT11 via bit-banging provoque parfois une charge CPU de 100 % pendant plusieurs millisecondes, avec à la clé des lectures corrompues lorsque d’autres interruptions interfèrent avec le timing. »

Avant de choisir cette voie, il vaut mieux évaluer l’impact sur les autres parties du programme : communications série, gestion d’afficheurs, servomoteurs pilotés par interruptions, etc.

Exemple simplifié de code manuel (approche pédagogique)

L’exemple qui suit illustre le principe, sans viser une robustesse industrielle. Il sert surtout de support pour comprendre les étapes internes gérées habituellement par la bibliothèque.

#define DHTPIN 2

uint8_t data[5];

void setup() {
  Serial.begin(9600);
}

bool readDHT11() {
  uint8_t i = 0;
  uint8_t j = 0;

  // Réinitialisation du buffer
  for (i = 0; i < 5; i++) data[i] = 0;

  // Signal de démarrage
  pinMode(DHTPIN, OUTPUT);
  digitalWrite(DHTPIN, LOW);
  delay(20); // 18 ms minimum
  digitalWrite(DHTPIN, HIGH);
  delayMicroseconds(40);
  pinMode(DHTPIN, INPUT_PULLUP);

  // Attente de la réponse du capteur (séquence de synchronisation)
  // Cette partie nécessite en pratique une gestion de timeout rigoureuse.

  // Lecture des 40 bits
  for (i = 0; i < 40; i++) {
    // Attente du front montant
    while (digitalRead(DHTPIN) == LOW);

    // Mesure de la durée de l'impulsion haute
    unsigned long t = micros();
    while (digitalRead(DHTPIN) == HIGH);
    unsigned long duration = micros() - t;

    // Seuil arbitraire à ajuster selon le capteur et la fréquence
    if (duration > 40) {
      data[i / 8] |= (1 << (7 - (i % 8)));
    }
  }

  // Vérification du checksum
  if ((uint8_t)(data[0] + data[1] + data[2] + data[3]) != data[4]) {
    return false;
  }
  return true;
}

void loop() {
  delay(2000);
  if (readDHT11()) {
    int humidity = data[0];
    int temperature = data[2];

    Serial.print("Humidite: ");
    Serial.print(humidity);
    Serial.println(" %");

    Serial.print("Temperature: ");
    Serial.print(temperature);
    Serial.println(" *C");
  } else {
    Serial.println("Erreur DHT11 (checksum ou timing)");
  }
}

Une telle approche exige des garde-fous : gestion des timeouts, prise en compte des interruptions, calibrage du seuil de durée, etc. Elle convient davantage à un exercice de compréhension de protocole qu’à une application de production.

Gestion des erreurs et fiabilisation des mesures Arduino DHT11

Un code qui se contente d’afficher des valeurs sur le moniteur série reste incomplet. Sur un projet réel, la gestion des erreurs et la validation des mesures jouent un rôle central pour éviter des actions inadaptées basées sur une lecture aberrante.

Types d’erreurs courantes avec un DHT11

Les dysfonctionnements rencontrés se répartissent en plusieurs catégories :

• Lecture invalide : la bibliothèque renvoie NaN pour la température et/ou l’humidité.
• Checksum incorrect : l’addition des quatre premiers octets ne correspond pas au cinquième, ce qui signale une trame corrompue.
• Valeurs physiquement impossibles : humidité négative, supérieure à 100 %, ou température très éloignée des conditions réelles.
• Blocage temporel : le code reste coincé dans une boucle d’attente sur la ligne DATA lors d’une implémentation maison.

Un câblage propre évite une partie de ces symptômes, mais certains relèvent de la gestion logicielle et des contraintes propres au composant.

Stratégies logicielles pour des mesures stables

Plusieurs techniques renforcent la fiabilité des données exploitées :

• Filtrage simple : rejeter une lecture unique aberrante en la comparant à la moyenne des dernières valeurs.
• Relance de la lecture : en cas de NaN, retenter jusqu’à un nombre limité de fois avant de signaler une erreur au système global.
• Sécurité temporelle : ne pas interroger le DHT11 plus d’une fois toutes les 2 secondes, pour respecter l’intervalle recommandé.
• Validation physique : borner la plage acceptée (par exemple 0–50 °C et 10–90 % RH) et écarter tout échantillon en dehors de ces limites.

Ces garde-fous limitent l’impact d’un parasite ponctuel, d’une variation de tension ou d’un timing légèrement dégradé.

Aller plus loin : exploitation des mesures DHT11 dans des projets Arduino

Une fois le code fonctionnel et stabilisé, les valeurs de température et d’humidité alimentent de nombreux scénarios : contrôle de ventilation, suivi de serre, gestion d’humidificateur, alerte de condensation, etc.

Affichage local des données (LCD, OLED, LED)

Un projet pédagogique courant associe le DHT11 à un afficheur LCD 16×2 ou à un module OLED I2C. La boucle principale lit les valeurs toutes les 2 à 5 secondes et met à jour l’écran sans saturer la liaison série.

Un exemple de structure :

• lecture DHT11 toutes les 2 s,
• mise à jour de l’afficheur toutes les 2 s ou toutes les 10 s,
• affichage d’un message d’erreur en cas de lecture invalide.

L’utilisation d’un bus I2C pour l’écran limite le nombre de broches consommées, ce qui libère des entrées/sorties pour d’autres capteurs ou actionneurs.

Automatisation et logique de contrôle

Les mesures du DHT11 se combinent avec des actionneurs pour mettre en place une régulation simple :

• activation d’un ventilateur au-dessus d’un certain seuil d’humidité,
• commande d’un relais pour lancer un déshumidificateur,
• déclenchement d’une alerte lorsque la température dépasse une consigne définie.

Le code Arduino intègre alors une logique conditionnelle basée sur les lectures filtrées et validées. Une hystérésis logicielle (par exemple, enclenchement à 60 % RH et extinction à 55 % RH) évite les cycles marche/arrêt trop fréquents.

Comparer le DHT11 avec d’autres capteurs de température et d’humidité

Pour un projet de formation ou une expérience ponctuelle, le DHT11 répond à de nombreux besoins. Dès que les contraintes de précision, de plage de mesure ou de robustesse augmentent, d’autres capteurs offrent des caractéristiques plus adaptées.

Tableau comparatif DHT11, DHT22, BME280, DS18B20, AHT20, LM35

Des tests comparatifs montrent que le DHT22 offre un écart inférieur à 0,5 °C par rapport à des références plus haut de gamme, avec une courbe similaire. Un BME680 par exemple produit des mesures de température plus fluides mais reste sur un comportement global proche d’un DS18B20, avec un écart autour de 2 °C selon les conditions.

Choisir le bon capteur pour son projet Arduino

Quelques repères pour orienter le choix :

• Projet de base ou pédagogique : DHT11 pour son coût réduit et son intégration simple.
• Surveillance plus exigeante : DHT22 pour une meilleure précision en température et humidité.
• Projet météo complet : BME280 pour l’ajout de la pression atmosphérique et une interface I2C/SPI plus robuste.
• Mesure de température seule : DS18B20 en environnement difficile (version étanche) ou LM35 en analogique.
• Intégration I2C moderne : AHT20, pratique lorsque le projet utilise déjà un bus I2C pour l’affichage ou d’autres capteurs.

La recommandation générale penche vers des capteurs I2C ou SPI pour des systèmes évolutifs. Ces interfaces supportent plusieurs modules sur le même bus, améliorent la fiabilité des échanges et s’intègrent bien dans une architecture plus large mêlant capteurs, afficheurs, modules réseau et relais.

Intégration du DHT11 dans une architecture matérielle plus large

Dans une installation domotique ou un système de monitoring, le DHT11 s’intègre dans un ensemble plus vaste : alimentation, protections, câblage basse tension, parfois même en lien avec le tableau électrique principal du logement.

Gestion de l’alimentation et protections électriques

Une carte Arduino qui pilote plusieurs capteurs, relais et modules de communication Wifi ou Ethernet doit disposer d’une alimentation stable, correctement dimensionnée. La ligne 5 V ne doit pas être saturée par des relais gourmands ou des modules radio puissants.

Un montage soigné isole les circuits de commande (Arduino + DHT11) des circuits de puissance (chauffages, ventilateurs, pompes). Pour se familiariser avec l’organisation d’une distribution électrique cohérente, le contenu de la page schéma tableau électrique 100m² offre un cadre méthodologique utile, même si le DHT11 reste un composant basse tension.

Prise en compte des dispositifs différentiels et des circuits commandés

Lorsqu’un Arduino pilote des charges connectées au réseau domestique via des relais ou des modules SSR, chaque circuit doit être protégé par un dispositif adapté. Même si le microcontrôleur et le DHT11 fonctionnent en basse tension, les actionneurs reliés au 230 V se retrouvent dans le champ des protections différentielles et des disjoncteurs.

Pour approfondir le choix des protections en fonction des circuits commandés (ventilation, chauffage d’appoint, déshumidification), la ressource disjoncteur différentiel choix offre des repères concrets pour adapter la sélectivité et la sensibilité des dispositifs.

Améliorations possibles autour du code Arduino DHT11

Une fois la lecture de base opérationnelle, le code Arduino bénéficiera de quelques évolutions orientées vers la robustesse, la maintenance et la réutilisation.

Structurer le code et isoler la logique de capteur

Regrouper la logique DHT11 dans une fonction ou une classe dédiée simplifie la réutilisation du capteur dans d’autres projets. Par exemple :

• une fonction bool readDHT(float &t, float &h) qui renvoie true ou false,
• un module séparé dht11.cpp / dht11.h pour centraliser la gestion du capteur,
• des messages d’erreur clairs dans le moniteur série ou via un affichage local.

Cette structuration améliore la lisibilité pour un travail en équipe ou pour une maintenance différée. Le code orienté capteur reste indépendant de la logique métier (pilotage de relais, calculs de consigne, envoi de données à un serveur).

Ajout de fonctionnalités logicielles autour du DHT11

Plusieurs compléments renforcent l’intérêt du montage :

• calcul du point de rosée à partir de la température et de l’humidité,
• enregistrement des données sur carte SD ou en mémoire interne,
• transmission des mesures vers une interface web ou une API (ESP8266, ESP32, Ethernet),
• graphique temps réel sur un tableau de bord externe (InfluxDB, Grafana, Node-RED, etc.).

Le DHT11 sert alors de capteur d’entrée dans une chaîne plus vaste de traitement et de visualisation. L’architecture logicielle prend progressivement de l’ampleur, mais le cœur reste le même : un code Arduino fiable qui multiplie les lectures cohérentes, filtrées et tracées dans le temps.