Class for DHT11, DHT21 and DHT22 (temperature & humidity)

Hi,

Nice library. However, it does not work correctly for negative temperatures. I'm using version 0.1.04. When a negative temperature is measured the class will return DHTLIB_ERROR_CHECKSUM. The problem is at line 74 in dht.cpp. Here bits[2] is modified, which makes the checksum calculation incorrect. There are, of course, many ways to fix the problem. I have fixed it by changing the code in the following way.

Old Code:

        int sign = 1;
        if (bits[2] & 0x80) // negative temperature
        {
                bits[2] = bits[2] & 0x7F;
                sign = -1;
        }
        temperature = sign * word(bits[2], bits[3]) * 0.1;

New Code:

        if (bits[2] & 0x80) // negative temperature
        {
                temperature = word(bits[2]&0x7F, bits[3]) * 0.1;
                temperature = -1.0 * temperature;
        }
        else
        {
                temperature = word(bits[2], bits[3]) * 0.1;
        }

Thanks for the library, and with this fix it is just perfect for me!

Thanks for this feedback, I'll fix it a.s.a.p.

updated the playground article to include the patch above.

Thanks again!

No idea why someone wants to write code if there already exists a perfectly fine library... but... I just checked in a DHT library with the following features:

  • Support for DHT11 and DHT22, AM2302, RHT03
  • Auto detect sensor model
  • Very low memory footprint
  • Very small code

Maybe useful for someone - feel free to report bugs.

Well done Mark,

Looked at your code and it looks like a decent piece of work. It is similar to a version I'm working on and yes I better stop with that version :wink:

The difference between your code and mine is that your code encapsulated an individual sensor while mine encapsulates the handshake so multiple sensors use one instance.
Footprint will differ too but not measured. I like the auto-detect functionality, well done

There is one improvement I want to propose to your class which I had build in my draft. If there is a time-out I would return the previous values instead of NaN. The error flag should still be the same. To do this the results temperature & humidity should have class scope.

If the program requests the temperature too fast it just gets the prev value which is seldom far from the actual value (instead of a NaN)

something like this

DHT::DHT_t DHT::read()
{
  // don't poll the sensor too often
  // - Max sample rate DHT11 is 1 Hz   (duty cycle 1000 ms)
  // - Max sample rate DHT22 is 0.5 Hz (duty cycle 2000 ms)

  unsigned long startTime = millis();
  if ( (startTime - lastReadTime) < getMinimalDelay()  )   // use the internal function
  {
   results.error = ERROR_TOO_QUICK;
   return results;  // returns previous temperature and humidity
  }
  lastReadTime = startTime;

  results.error = ERROR_NONE;
  results.temperature = NAN;
  results.humidity = NAN;
  // Request sample
  ...

the way I coded the interface was 3 public functions

float DHT::getHumidity()
{
  if ( millis() - lastReadTime > 2000 || status != ERROR_NONE )  // time to refresh or to retry
  {
    status = read();  // fetch new hum & temp
  }
  else 
  {
    lastReadTime  = millis();
  }
  return humidity;
}


float DHT::getTemperature()
{
  if ( millis() - lastReadTime > 2000 || status != ERROR_NONE ) 
  {
    status = read(); // status and read() are private
  }
  else 
  {
    lastReadTime  = millis();
  }
  return temperature;  // private member
}

float DHT::getStatus()
{
   status = read();  // fetch new data
}

typing this you could also add the "retry" condition.

my 2 cents,
regards / groeten,
Rob

Just a few questions while checking both DHT versions:

Rob:

  • Has a delay of 20msec for both DHT11 and DHT22.
  • Uses a counter in the while to break out of the while in case the pin does not change

Mark:

  • Has a delay of 18msec for the DHT11 and 800usec for the DHT22.
  • Uses an endless while loop, so if the pin does not change --> Arduino in endless loop!

Further:

  • I am using multiple DHT22's on different pins. Which library would be most RAM efficient?
  • Is the 800usec the right delay for the DHT22? If so, it saves me 5*19msec = 75msec of doing nothing, which is a lot using NilRTOS/ChibiOS RTOSses...

Please comment 8)

Rob:

  • Has a delay of 20msec for both DHT11 and DHT22.
  • Uses a counter in the while to break out of the while in case the pin does not change

The counter makes the loop fool proof.
The 20 mSec is to make code as similar as possible for both sensors, Mark optimizes the code to the detail of the datasheet which is good better :wink:

I am using multiple DHT22's on different pins. Which library would be most RAM efficient?

Not tested, I expect the lib from mark be smaller for a single sensor but my lib can support multiple with one instance. Somewhere there must be a break even point.
It would be very informative if you could provide some numbers

  • Is the 800usec the right delay for the DHT22? If so, it saves me 5*19msec = 75msec of doing nothing, which is a lot using NilRTOS/ChibiOS RTOSses...

800usec - check datasheet.

In an RTOS one should schedule another thread when delay is called, to return /test later. In pseudocode

delay(uint32_t ms)
{
  wakeUpThisThread(ms);
  switchThread();
}

This way one could always use the waiting time effective. (disclaimer, no RTOS expert)

Thanks Rob for your suggestions. I just commited a new version of the library with the following changes:

  • Removed ERROR_TOO_QUICK. If you poll too often, you just get cached data
  • Removed read() and added getTemperature() and getHumidity(). This gives a much cleaner interface for the users.
  • Fixed DHT11 detection. Removed the detection from the class constructor to a seperate setup()

Code example:

#include "DHT.h"

DHT dht = DHT(2); // data pin 2, auto detect DHT model

void setup()
{
  dht.setup();
}

void loop()
{
  delay(dht.getMinimalDelay());

  Serial.print(dht.getHumidity(), 1);
  Serial.print("\t");
  Serial.println(dht.getTemperature(), 1);
}

MarsWarrior:
Just a few questions while checking both DHT versions:

Rob:

  • Has a delay of 20msec for both DHT11 and DHT22.
  • Uses a counter in the while to break out of the while in case the pin does not change

Mark:

  • Has a delay of 18msec for the DHT11 and 800usec for the DHT22.
  • Uses an endless while loop, so if the pin does not change --> Arduino in endless loop!

Further:

  • I am using multiple DHT22's on different pins. Which library would be most RAM efficient?
  • Is the 800usec the right delay for the DHT22? If so, it saves me 5*19msec = 75msec of doing nothing, which is a lot using NilRTOS/ChibiOS RTOSses...

Please comment 8)

  • 800usec for a DHT22 is according to the datasheets I found. And it works.
  • My library won't hang. The endless loop you mention has a return statement which is called after 85 usec.
  • Per DHT instance, you need 18 bytes of data~~, perhaps a little more overhead, I would need to measure to give a hard number~~. So no problem to run a lot of DHT sensors (tried two myself). The advantage of having an instance per sensor is that you can read out them in parallel. On the other hand, it would be straightforward to alter setup() to something like setup(pin, model) and then you could reuse the instance. But not sure if the effort is worth the 18*(sensor-1) bytes...

[quote author=Mark Ruys link=topic=58531.msg1274792#msg1274792 date=1370985148]

  • 800usec for a DHT22 is according to the datasheets I found. And it works.
    [/quote]Nice. Will try with the current lib I'm using!
  • My library won't hang. The endless loop you mention has a return statement which is called after 85 usec.
  • Per DHT instance, you need 18 bytes of data~~, perhaps a little more overhead, I would need to measure to give a hard number~~. So no problem to run a lot of DHT sensors (tried two myself). The advantage of having an instance per sensor is that you can read out them in parallel. On the other hand, it would be straightforward to alter setup() to something like setup(pin, model) and then you could reuse the instance. But not sure if the effort is worth the 18*(sensor-1) bytes...

Ah! You are right, I misread some of the C++ code :zipper_mouth_face:
18 bytes is not very much indeed. Thanx!

Rob Tillaart suggested that I created a another thread for the new library, so I did: Efficient and simple DHT library - Sensors - Arduino Forum. This way we keep this thread focussed on Rob's great work.

I reworked my library and just commited all my changes for some more features.

Hello Rob,
I tried this library on Arduino Due and it seems since its SAM series processor the includes for AVR wont work (avr/io.h etc).
Can you suggest changes to make this library compile and work on Arduino Due boards .

Thanks for the help

Added support for the DHT21 (AM2301) today - Arduino Playground - DHTLib -

datasheet DHT21: - http://www.electrodragon.com/w/images/6/6f/DHT21.pdf -
Seen at: - DHT21 Digital Temperature & Humidity Sensor (AM2301) – ElectroDragon -

The DHT21 has the same handshake as the DHT11 and DHT22. The translation to real values (TEMP/RH) is different again.
As I do not have the sensor yet I have not tested it, so all feedback is welcome.

As always remarks and feedback is welcome.

Sorry for the late reaction, I missed it somehow.

sanhardik:
Hello Rob,
I tried this library on Arduino Due and it seems since its SAM series processor the includes for AVR wont work (avr/io.h etc).
Can you suggest changes to make this library compile and work on Arduino Due boards .

Thanks for the help

I have no Due operational, but you should check the private read() function.
It uses a #define TIMEOUT 10000 which is tuned for the 16Mhz UNO. so it will trigger too fast on an DUE.
As the Due is 84 MHz ==> 5.25 x as fast, you should adjust the TIMEOUT to 60000 (at least)

A more permanent solution should derive a clock dependant timeout like this

#define TIMEOUT (F_CPU/1600)

please give it a try.

update:
Got mail today, DHT21 testing is in progress, the code in the lib seems not to decode right.

The decoding was based upon this hint from the datasheet:
"DATA=8 bit integral RH data+8 bit decimal RH data+8 bit integral T data+8 bit decimal T data+8 bit check-sum "
HEX dumps of received bytes have a correct CRC. A new decoding scheme is derived from the dumps and currently under test.

I have some problems with the library.
I have an arduino due and an am2301 sensor (DHT21).
The temperature at the moment that I tested the sensor was more or less 22 degrees.
I set up: #define TIMEOUT 52500 in dht.cpp

Data showned in dht_test.ino is:
Humidity 2.3
Temperature 0.9

Any idea??
Thanks!

wifialex:
I have some problems with the library.
I have an arduino due and an am2301 sensor (DHT21).
The temperature at the moment that I tested the sensor was more or less 22 degrees.
I set up: #define TIMEOUT 52500 in dht.cpp

Data showned in dht_test.ino is:
Humidity 2.3
Temperature 0.9

Any idea??
Thanks!

Yes, the code for the support of the DHT21 is experimental, based on hints in a datasheet (link see a few pages above) and just does not work yet.

Can you please access the DHT21 as if it was a DHT22 so use read22(pin) instead of read21(pin)?

I have strong indications that the formula for DHT21 and DHT22 are identical although the datasheet hinted otherwise.
I have no confirmation yet and maybe you can confirm (as I do not have the DHT21 myself).

When my assumption is confirmed I can update the code.

I have just checked it using dht22 read.
The measures are closed to real but there are errors:
Humidity is lower than real
Temperature is higher than real

Can you give exact figures, lower and higher are too subjective.

Low humidity is often mentioned as problem with the DHT sensors, temperature can depend on air flow but should be within 3C. In your code you can add an offset to adjust the temp to the real value. For humidity this will probably not work.

First of all, sorry for my delayed answer, but I was very busy.
The first one pic sensor was calibrated two months ago, so it should be very accurate.
The second one pic is DHT21 data