DHT22 - Failed après plusieurs heures

International Français
1

Bonjour à tous,

Pour mon projet de domotique je souhaite équiper ma maison de 15 DHT22. Avant de les intégrer je fais quelques test pour valider la bonne remontée des infos.

Matériel : Eedomus mega 2560 + 15x DHT22

Si dessous les test fait en même temps sur différentes PIN, arduino branché sur le pc en USB, alimente directement les sondes en 5V :

Test 1 : Montage classique avec résistance 4.7Kohm, Câble de sonde 20cm, relevé toute les 5 secondes -> Essai sur 48h parfait

Test 2 : Montage classique avec résistance 4.7Kohm, Câble de sonde 15M, relevé toute les 5 secondes -> Quelques rare fois ou l’info ne remonte pas dans les première 5h, arrêt complet de la remonté d’info après 5h (environ) ;

Test 3 : Montage classique avec résistance 4.7Kohm + condensateur 100nF, Câble de sonde 15M (câble PTT), relevé toute les 5 secondes -> Idem test 2, je n’ai pas réussi a voir si cela tenait plus longtemps, mais ça coupe au bout de quelques heures;

Test 4 : Montage classique avec résistance 4.7Kohm + condensateur 100nF, Câble de sonde 30M (câble PTT), relevé toute les 5 secondes -> idem test 2 et 3, mais a tenu moins longtemps (3 ou 4 heures ?) ;

Quand je débranche et rebranche le arduino, cela re démarre correctement et répète les scénarios des 4 tests ci-dessus.

Savez-vous d’où peux venir cet arrêt de remonté d’information au bout de quelques heures de fonctionnement ?

  • J’ai éliminé l’hypothèse du code (peut-être à tort) car cela fonctionne très bien avec le petit câble et dans les première heures sur les grands..
  • J’ai essayé de réduire ou d’augmenté les périodicité de mesures mais même problème ;
  • La mise en place de condensateur entre le + et – n’a rien changé
  • Le pb de longueur de câble semble logique, mais pourquoi cela fonctionne bien quelques heure et après arrêt total ? (j’ai alterné les sondes et les pins pour les vérifier) Plus le câble est long, plus le signal se coupe vite ?
  • J’alimente 4 sondes avec l’arduino, est-ce trop pour lui? Pertes de tension au bout d’un moment?

Je peux vous fournir le code si vous pensez que cela vient de là.

Merci par avance :slight_smile:

2

Des éléments de réponse ici :

My main question though is how long can the cables be on these sensors. 
I need to run them at a minimum of about 12 meters. Is this possible?


For the TMP36 definitely not, for the DHT22 probably not. 

The TMP36 is an analog sensor and this signal will take up lots of electrical noise even if the cable 
is only 1 or 2 meters. You won't get a usable value with long cables even if you put some caps in 
place to filter out some of the noise.

The DHT22 uses a digital protocol to transmit it's sensor data, so it's much more immune to taking 
up electrical noise but for 12 meters of cable you probably need a differential signal as RS485.

One possible solution is to take an additional Arduino, put it near the sensors and connect the two 
via some MAX485 chips (RS485 drivers).

Essaie de torsader tes fils de 15 mètres : est-ce que ça change ?
Sinon, la solution proposée est d'ajouter un driver RS485 (20 centimes chez Ali)

3

J'avais pourtant trouvé pas mal de retour d'expérience avec des longueurs de câbles plus importantes pour le Dht22.
Je vais essayer sur mon cable ptt de 25m de mettre le + et - sur la même torsade, et le data seul sur une autre torsade.

On verra bien je croise les doigts :slight_smile:

merci

4

Indépendamment des problèmes logiciel ou de saturation mémoire je te propose d'améliorer la réalisation électronique pour des grandes longueurs.

C'est quoi ton câble "PTT"

  • du 600 ohms ou du 100 ohms ?
  • du plat (pas terrible) ou du rond (meilleur)

Tu peux essayer la manip suivante qui va consister à adapter la ligne que forment tes fils.
Un câble PTT à une impédance caractéristique généralement égale à 600 ohms. Le câble éthernet lui est 100 ohms.

Ces câbles sont prévus pour être attaqués avec un générateur dont l'impédance est égale à l'impédance caractéristique du câble.
Idem pour la réception le récepteur doit présenter une impédance égale à celle du câble.

Remarques :

  1. la liaison data du DHT22 est bidirectionnelle on ne pourra pas adapter dans les deux sens il faudra faire un choix.
    Les signaux importants sont dans le sens DHT vers arduino, c'est ce sens que l'on va améliorer.

  2. un signal c'est deux fronts et un plat. Le plat correspond à un signal continu, les fronts a des signaux hautes fréquences.
    On ne va donc essayer d'adapter que les fronts.

Pour cela je te propose coté arduino de placer en dérivation entre l'entrée de la pin arduino et la masse une résistance de 600 ohms avec un condensateur en série (100 nF devrait être suffisant).

5

Bonsoir,

Ces sondes ont un microcontrôleur et c'est lui qui plante. Comme son reset n'est pas accessible et que le concepteur n'a pas mis de watchdog :sob: , on perd le contrôle de la sonde...

Pour augmenter la longueur du câble vous pouvez aussi essayer de diminuer la résistance de 4k7. Cela limitera l'influence de la capacité du câble. On peut descendre jusqu'à 600Ohms, proche de l'impédance caractéristique du câble PTT (8mA sous 5V). Cela peut aussi remplacer l'adaptateur proposé par 68tjs.

Je n'ai pas bien saisi où était cette capa de 100nF

classique avec résistance 4.7Kohm + condensateur 100nF,

Enfin, pour utiliser les paires, le mieux est de mettre sur la même paire ("torsade") signal et GND. Les alims et le GND sur une autre paire.

Bonne bidouille,

MicroQuettas

6

Je n'ai pas bien saisi où était cette capa de 100nF

Je propose de brancher un dipôle Résistance + condensateur en série avec la résistance entre l'entrée du micro et la masse.

Comme cela je n'intervient pas sur le continu mais pendant les deux flancs montée et descente le câble voit 600 ohms.

7

Oula merci pour vos nombreux retours et vos pistes de solutions.

J ai lancé ce soir un test avec mon câble ptt de 25m rond en mettant les alimentations sur la même torsade, au bout de 4 heures ça tient toujours avec zéro erreur.

Le condensateur est entre le + et le - pour répondre à la question.

Mon objectif (secret) est de mettre mon arduino dans mon amoire elec au sous sol de ma maison et de me raccorder sur les 4 départs de ligne ptt qui vont vers 4 prises téléphonique repartis dans ma maison pour éviter de tirer trop de câbles. Pour optimiser encore plus je souhaite mettre en commun pour plusieurs sondes le même câble + et - pour câbler plusieurs sondes.

Mon objectif n étant plus secret je vais décrypter vos pistes de solution (un peu du chinois) et les mettre en œuvre.

8

Avec plusieurs sondes attention au_X fil_S de masse.

  • La définition de la masse est d'être une référence de tension. C'est à dire qu'en tous points de la Masse on a exactement le même potentiel.
  • La réalité d'un fil de cuivre c'est qu'il est résistif, certes très légèrement mais il l'est. D'où des chutes de tension provoquées par la loi d'ohms dans le fil qui théoriquement parlant n'est plus une masse.

Il faut faire attention à ne pas utiliser le même fil de liaison de masse pour plusieurs capteurs si un ou plusieurs ne sont pas à consommation constante ou consomment beaucoup.
Cas ultra classique du LM35 couplé avec un autre capteur avec quelques mV de perdu dans le fil de liaison vers la masse du micro.
Le résultat sera désastreux avec un couplage par impédance commune de masse.

Comme toujours en électronique des masses il faut faire usage de réflexion et trouver le bon compromis entre la théorie et la réalité du terrain.

9

Petit retour de mes tests:

Delay= 10000ms, condensateur 100uf + résistance 4.7Kohm

  • SONDE N°1
    Câble PTT 25m rond neuf (câble enroulé par terre)
    Zéro erreur sur 24h
    J'ai cablé le 5V et le GND sur la même torsade. Le data sur une autre torsade seul

  • SONDE N°2
    Câble PTT 12M rond (câble installé il y'a 20 ans dans ma maison, relis une prise téléphonique à mon armoire élec)
    J'ai cablé idem au dessus.
    8 erreurs sur 5 heures de test. Toujours pas de plantage.
    Beaucoup moins d'erreurs qu'avant quand le 5v et GND n'étaient pas sur la même torsade.

La longueur du câble ne semble pas être un problème. Par contre celui de la sonde 2 passe dans les murs (avec les 230V) puis dans la gaine technique avec tout les câbles elec de la maison pour aller dans le sous-sol.

Pensez vous que ce sont les autres câbles ont générés mes 8 erreurs (sur 1800mesures)? En sachant que la journée les seuls câbles qui font passer du courant sont ceux de ma VMC et du frigo.

Y'a t'il une solution pour régler ce problème?

Je peux blinder artisanalement le câble dans la gaine technique car accessible, mais je ne sais pas trop comment, ni si c'est utile.
Est ce que diminuer la résistance comme proposé par Microquettas aidera sur ce point?

J'ai le sentiment d'être très proche du perfect. :slight_smile:

10

Il y a aussi un autre point très important : le choix de la bibliothèque.
Parce que jusqu'à présent tu parlais de plantage et maintenant d'erreur pour moi ce n'est pas la même chose.

Un plantage c'est franc.
Des erreurs c'est plus subtil.

Le DHT22 est un circuit rapide et il faut le lire rapidement. Ses constructeurs ont même jugé nécessaire d'introduire une somme de contrôle pour valider la transmission.

Toutes les bibliothèque qui utilisent la fonction arduino digitalRead() sont mauvaises et provoquent des "cheksumm error".
Il faut choisir une bibliothèque qui lit directement les registres du micro. Avec les registres on lit plus de 10 fois plus vite.

Comme bibliothèques tu as celle de Rob Tilaart. Adafruit qui est resté très longtemps sur du digitalRead() a désormais forké celle de Rob.
Mais attention où tu la charge, de nombreux sites n'ont fait de mise à jour et proposent toujours l'ancienne.

11

Le plantage survient après de nombreuses heures de fonctionnement, en gros le message d'erreur Failed to read from DHT #6 remonte indéfiniement.
Quand je dit erreur c'est que de temps en temps ce message remonte, mais la mesure reprend sur l'intervalle suivante.

Voici la librairie utilisée pour le dht, est ce que c'est bon?:

/* DHT library

MIT license
written by Adafruit Industries
*/
#ifndef DHT_H
#define DHT_H

#if ARDUINO >= 100
 #include "Arduino.h"
#else
 #include "WProgram.h"
#endif


// Uncomment to enable printing out nice debug messages.
//#define DHT_DEBUG

// Define where debug output will be printed.
#define DEBUG_PRINTER Serial

// Setup debug printing macros.
#ifdef DHT_DEBUG
  #define DEBUG_PRINT(...) { DEBUG_PRINTER.print(__VA_ARGS__); }
  #define DEBUG_PRINTLN(...) { DEBUG_PRINTER.println(__VA_ARGS__); }
#else
  #define DEBUG_PRINT(...) {}
  #define DEBUG_PRINTLN(...) {}
#endif

// Define types of sensors.
#define DHT11 11
#define DHT22 22
#define DHT21 21
#define AM2301 21


class DHT {
  public:
   DHT(uint8_t pin, uint8_t type, uint8_t count=6);
   void begin(void);
   float readTemperature(bool S=false, bool force=false);
   float convertCtoF(float);
   float convertFtoC(float);
   float computeHeatIndex(float temperature, float percentHumidity, bool isFahrenheit=true);
   float readHumidity(bool force=false);
   boolean read(bool force=false);

 private:
  uint8_t data[5];
  uint8_t _pin, _type;
  #ifdef __AVR
    // Use direct GPIO access on an 8-bit AVR so keep track of the port and bitmask
    // for the digital pin connected to the DHT.  Other platforms will use digitalRead.
    uint8_t _bit, _port;
  #endif
  uint32_t _lastreadtime, _maxcycles;
  bool _lastresult;

  uint32_t expectPulse(bool level);

};

class InterruptLock {
  public:
   InterruptLock() {
    noInterrupts();
   }
   ~InterruptLock() {
    interrupts();
   }

};

#endif

Derniers relevés:
La sonde N°2 qui passe par mon réseau téléphonique à planté hier soir après avoir fonctionné 5 ou 6 heures avec peu d'erreur. :confused:

La sonde 1 fonctionne parfaitement depuis 30h sans aucune erreur.

On peu définitivement en conclure qu'un câble de 25m ne pose pas de problème avec le dht22 dans ma configuration de câblage. La seul chose qui différentie les deux montages c'est le passage du câble de la sonde qui merdouille à proximité des câbles 230V.
Qu'est ce qui peut perturber la mesure, et que faire pour améliorer cela? :cold_sweat:

68tjs:
Le DHT22 est un circuit rapide et il faut le lire rapidement. Ses constructeurs ont même jugé nécessaire d'introduire une somme de contrôle pour valider la transmission.

Dois je comprendre qu'il faut que je diminue le délai de relevé d'info? (actuellement 10 secondes)
J'ai lu la fiche constructeur et rien n'est mentionné sur la mise en oeuvre et le paramétrage.

12

Le fichier que tu met en copie n'est pas le fichier de la bibliothèque mais le fichier *.h qui l'accompagne.

Je suis très loin d'être un spécialiste de la programmation mais je me renseigne et je m'insurge quand je vois la confusion entretenue entre inclure un fichier d'en tête et le vrai fichier bibliothèque.

Le vrai fichier est le fichier *.cpp

Pour bien comprendre je te suggère de suivre un vrai tuto de C/C++.
Quand tu saura comment est constitué un fichier C/C++ avec ses déclaration de fonctions pour le compilateur et sa fonction main() tout deviendra plus clair.
La programmation avec l'IDE arduino suit les règles du C/C++, simplement l'IDE fait certaines actions obligatoires dans ton dos en te faisant croire que seules les fonction setup() et loop() sont nécessaires.

Une bibliothèque c'est deux fichiers : un fichier *.cpp et un fichier *.h qui fait les déclarations obligatoires pour le compilateur.
Le code se trouve dans le fichier cpp

La bibliothèque dont je te parle est ici : Arduino/libraries/DHTlib at master · RobTillaart/Arduino · GitHub

Et le point essentiel dont je te parle est ici :

// replace digitalRead() with Direct Port Reads.
// reduces footprint ~100 bytes => portability issue?
// direct port read is about 3x faster

Ce n'est que 3 fois plus rapide parce que l'auteur veux continuer à utiliser les dénomination arduino des E/S.
Si on utilise les dénominations d'Atmel, fabricant du micro, la lecture est entre 8 et 10 fois plus rapide.

13

Ah désolé pour cette confusion, le code .cpp:

/* DHT library

MIT license
written by Adafruit Industries
*/

#include "DHT.h"

#define MIN_INTERVAL 2000

DHT::DHT(uint8_t pin, uint8_t type, uint8_t count) {
  _pin = pin;
  _type = type;
  #ifdef __AVR
    _bit = digitalPinToBitMask(pin);
    _port = digitalPinToPort(pin);
  #endif
  _maxcycles = microsecondsToClockCycles(1000);  // 1 millisecond timeout for
                                                 // reading pulses from DHT sensor.
  // Note that count is now ignored as the DHT reading algorithm adjusts itself
  // basd on the speed of the processor.
}

void DHT::begin(void) {
  // set up the pins!
  pinMode(_pin, INPUT_PULLUP);
  // Using this value makes sure that millis() - lastreadtime will be
  // >= MIN_INTERVAL right away. Note that this assignment wraps around,
  // but so will the subtraction.
  _lastreadtime = -MIN_INTERVAL;
  DEBUG_PRINT("Max clock cycles: "); DEBUG_PRINTLN(_maxcycles, DEC);
}

//boolean S == Scale.  True == Fahrenheit; False == Celcius
float DHT::readTemperature(bool S, bool force) {
  float f = NAN;

  if (read(force)) {
    switch (_type) {
    case DHT11:
      f = data[2];
      if(S) {
        f = convertCtoF(f);
      }
      break;
    case DHT22:
    case DHT21:
      f = data[2] & 0x7F;
      f *= 256;
      f += data[3];
      f *= 0.1;
      if (data[2] & 0x80) {
        f *= -1;
      }
      if(S) {
        f = convertCtoF(f);
      }
      break;
    }
  }
  return f;
}

float DHT::convertCtoF(float c) {
  return c * 1.8 + 32;
}

float DHT::convertFtoC(float f) {
  return (f - 32) * 0.55555;
}

float DHT::readHumidity(bool force) {
  float f = NAN;
  if (read()) {
    switch (_type) {
    case DHT11:
      f = data[0];
      break;
    case DHT22:
    case DHT21:
      f = data[0];
      f *= 256;
      f += data[1];
      f *= 0.1;
      break;
    }
  }
  return f;
}

//boolean isFahrenheit: True == Fahrenheit; False == Celcius
float DHT::computeHeatIndex(float temperature, float percentHumidity, bool isFahrenheit) {
  // Using both Rothfusz and Steadman's equations
  // http://www.wpc.ncep.noaa.gov/html/heatindex_equation.shtml
  float hi;

  if (!isFahrenheit)
    temperature = convertCtoF(temperature);

  hi = 0.5 * (temperature + 61.0 + ((temperature - 68.0) * 1.2) + (percentHumidity * 0.094));

  if (hi > 79) {
    hi = -42.379 +
             2.04901523 * temperature +
            10.14333127 * percentHumidity +
            -0.22475541 * temperature*percentHumidity +
            -0.00683783 * pow(temperature, 2) +
            -0.05481717 * pow(percentHumidity, 2) +
             0.00122874 * pow(temperature, 2) * percentHumidity +
             0.00085282 * temperature*pow(percentHumidity, 2) +
            -0.00000199 * pow(temperature, 2) * pow(percentHumidity, 2);

J'ai eu la mauvaise surprise ce midi de constaté que la sonde 1 (câble de 25m enroulé) ne remonte plus l'information. Donc ça a tenu environ 60h, sans erreur ponctuel de remonté d'information. :frowning:

J'ai une sonde sur un petit câble monté sans condensateur de 20cm qui elle tient toujours depuis 60h.

Je vais tenter de croiser le GND et le data pour voir si ca améliore le problème.

14

2eme partie du code:

  if((percentHumidity < 13) && (temperature >= 80.0) && (temperature <= 112.0))
      hi -= ((13.0 - percentHumidity) * 0.25) * sqrt((17.0 - abs(temperature - 95.0)) * 0.05882);

    else if((percentHumidity > 85.0) && (temperature >= 80.0) && (temperature <= 87.0))
      hi += ((percentHumidity - 85.0) * 0.1) * ((87.0 - temperature) * 0.2);
  }

  return isFahrenheit ? hi : convertFtoC(hi);
}

boolean DHT::read(bool force) {
  // Check if sensor was read less than two seconds ago and return early
  // to use last reading.
  uint32_t currenttime = millis();
  if (!force && ((currenttime - _lastreadtime) < 2000)) {
    return _lastresult; // return last correct measurement
  }
  _lastreadtime = currenttime;

  // Reset 40 bits of received data to zero.
  data[0] = data[1] = data[2] = data[3] = data[4] = 0;

  // Send start signal.  See DHT datasheet for full signal diagram:
  //   http://www.adafruit.com/datasheets/Digital%20humidity%20and%20temperature%20sensor%20AM2302.pdf

  // Go into high impedence state to let pull-up raise data line level and
  // start the reading process.
  digitalWrite(_pin, HIGH);
  delay(250);

  // First set data line low for 20 milliseconds.
  pinMode(_pin, OUTPUT);
  digitalWrite(_pin, LOW);
  delay(20);

  uint32_t cycles[80];
  {
    // Turn off interrupts temporarily because the next sections are timing critical
    // and we don't want any interruptions.
    InterruptLock lock;

    // End the start signal by setting data line high for 40 microseconds.
    digitalWrite(_pin, HIGH);
    delayMicroseconds(40);

    // Now start reading the data line to get the value from the DHT sensor.
    pinMode(_pin, INPUT_PULLUP);
    delayMicroseconds(10);  // Delay a bit to let sensor pull data line low.

    // First expect a low signal for ~80 microseconds followed by a high signal
    // for ~80 microseconds again.
    if (expectPulse(LOW) == 0) {
      DEBUG_PRINTLN(F("Timeout waiting for start signal low pulse."));
      _lastresult = false;
      return _lastresult;
    }
    if (expectPulse(HIGH) == 0) {
      DEBUG_PRINTLN(F("Timeout waiting for start signal high pulse."));
      _lastresult = false;
      return _lastresult;
    }

    // Now read the 40 bits sent by the sensor.  Each bit is sent as a 50
    // microsecond low pulse followed by a variable length high pulse.  If the
    // high pulse is ~28 microseconds then it's a 0 and if it's ~70 microseconds
    // then it's a 1.  We measure the cycle count of the initial 50us low pulse
    // and use that to compare to the cycle count of the high pulse to determine
    // if the bit is a 0 (high state cycle count < low state cycle count), or a
    // 1 (high state cycle count > low state cycle count). Note that for speed all
    // the pulses are read into a array and then examined in a later step.
    for (int i=0; i<80; i+=2) {
      cycles[i]   = expectPulse(LOW);
      cycles[i+1] = expectPulse(HIGH);
    }
  } // Timing critical code is now complete.

  // Inspect pulses and determine which ones are 0 (high state cycle count < low
  // state cycle count), or 1 (high state cycle count > low state cycle count).
  for (int i=0; i<40; ++i) {
    uint32_t lowCycles  = cycles[2*i];
    uint32_t highCycles = cycles[2*i+1];
    if ((lowCycles == 0) || (highCycles == 0)) {
      DEBUG_PRINTLN(F("Timeout waiting for pulse."));
      _lastresult = false;
      return _lastresult;
    }
    data[i/8] <<= 1;
    // Now compare the low and high cycle times to see if the bit is a 0 or 1.
    if (highCycles > lowCycles) {
      // High cycles are greater than 50us low cycle count, must be a 1.
      data[i/8] |= 1;
    }
    // Else high cycles are less than (or equal to, a weird case) the 50us low
    // cycle count so this must be a zero.  Nothing needs to be changed in the
    // stored data.
  }

  DEBUG_PRINTLN(F("Received:"));
  DEBUG_PRINT(data[0], HEX); DEBUG_PRINT(F(", "));
  DEBUG_PRINT(data[1], HEX); DEBUG_PRINT(F(", "));
  DEBUG_PRINT(data[2], HEX); DEBUG_PRINT(F(", "));
  DEBUG_PRINT(data[3], HEX); DEBUG_PRINT(F(", "));
  DEBUG_PRINT(data[4], HEX); DEBUG_PRINT(F(" =? "));
  DEBUG_PRINTLN((data[0] + data[1] + data[2] + data[3]) & 0xFF, HEX);

  // Check we read 40 bits and that the checksum matches.
  if (data[4] == ((data[0] + data[1] + data[2] + data[3]) & 0xFF)) {
    _lastresult = true;
    return _lastresult;
  }
  else {
    DEBUG_PRINTLN(F("Checksum failure!"));
    _lastresult = false;
    return _lastresult;
  }
}

// Expect the signal line to be at the specified level for a period of time and
// return a count of loop cycles spent at that level (this cycle count can be
// used to compare the relative time of two pulses).  If more than a millisecond
// ellapses without the level changing then the call fails with a 0 response.
// This is adapted from Arduino's pulseInLong function (which is only available
// in the very latest IDE versions):
//   https://github.com/arduino/Arduino/blob/master/hardware/arduino/avr/cores/arduino/wiring_pulse.c
uint32_t DHT::expectPulse(bool level) {
  uint32_t count = 0;
  // On AVR platforms use direct GPIO port access as it's much faster and better
  // for catching pulses that are 10's of microseconds in length:
  #ifdef __AVR
    uint8_t portState = level ? _bit : 0;
    while ((*portInputRegister(_port) & _bit) == portState) {
      if (count++ >= _maxcycles) {
        return 0; // Exceeded timeout, fail.
      }
    }
  // Otherwise fall back to using digitalRead (this seems to be necessary on ESP8266
  // right now, perhaps bugs in direct port access functions?).
  #else
    while (digitalRead(_pin) == level) {
      if (count++ >= _maxcycles) {
        return 0; // Exceeded timeout, fail.
      }
    }
  #endif

  return count;
}
15

D'après ce que j'ai vu rapidement la bibliothèque mixte la lecture sur les registres et la lecture avec digitalRead()
L'impression que je ressens est que l'auteur a voulu s'inspirer des modifs comme celles de Rob Tillaart mais qu'il a oublié de modifier des lignes en cours de route.
Impression de pas sérieux.

D'autre part qu'est ce qu'on a fiche de la température de rosée et pire des degrés fahrenheit qui ne font pas partie du système d'unité international !

16

Je pensais que c'était la bibliothèque "officiel" que j'avais téléchargé. Je vais en cherché une autre peut être plus optimisé :slight_smile:
Si je ne trouve pas je tenterai la chose moi même.

Après est ce que c'est cela qui explique que ça ne fonctionne plus après 60h? Pas certain :frowning:

En tout cas merci pour ton aide 68tjs :slight_smile:

17

Attention je n'ai pas dit que tout le problème provient de la bibliothèque, je dis simplement qu'il en existe une qui fonctionne bien et autant mettre toutes les chances de son coté.

Il n'existe pas de bibliothèque officielle dans aucun système.
C'est à l'utilisateur de faire le bon choix. Pour le DHT22 il se trouve que j'ai bien regardé le sujet et je me suis fait mes propres fichiers mais ils ne sont pas sous forme de bibliothèque. C'est de l'ajusté à la demande, en particulier je lis directement les registres, c'est ultra rapide mais si une autre pin est utilisée il faut modifier le source des fichiers, c'est efficace mais lourd.

Il y a eu une remarque comme quoi le plantage peut aussi provenir du micro interne au DHT22.
Sur le site de Sigrok on peut lire que le micro est un STM8S103F3, c'est du ST donc à priori du sérieux mais rien ne peut être éliminé par principe.
https://sigrok.org/wiki/Protocol_decoder:Am230x

Un DHT22 ne consomme pratiquement rien il est possible de l'alimenter à partir d'une sortie du micro.
Quand tu détecte un plantage tu peux essayer de couper automatiquement l'alim du DHT et de le réalimenter afin de provoquer une RAZ automatique du micro.

Edit : le DHT22 s'appelle aussi AM2302