PLEASE do not use the idDHT22 library

The idDHT22 library has proven unreliable and can cause a Core to hang. As such it has been deprecated. The library cannot be removed from the IDE since it is still being used.

It is EXTREMELY recommended that the newer, better, reliable PIETTETECH_DHT library (also in the web IDE) be used as a replacement (it is essentially a fixed idDHT22!). :smile:


Can we “just” switch the library or we need to change the code for that?

@itayd100, you will need to make some adjustments but the examples will guide you. It is very straight forward.

1 Like

I agree.

Neither library is perfect, because the DHT22 itself is pretty unreliable, but at least the PIETTETECH_DHT library will not lock up your processor. I am running it on the Photon and it works well,

Temperature / Humidity at my house using the NEW library:

1 Like

Perhaps some comments can be added to the bad library until it can be removed?


I would like to echo @peekay123’s sentiments. I am made the mistake of using the wrong library recently and it delivered unexpected results. (Weird measurements and unexpected Photon lockups.)

To @Bspranger, there is a comment on the library IDE page recommending that you use the other library. I missed the comment (user error although I wrote the code ages ago and wonder if the new library was not available yet, but I digress) and it resulted in the weird problems as mentioned above. The new library is rock solid and works perfectly, in my limited experience.

I’m using a Core and the DHT22 to monitor my garage temperature. It is very unreliable. I’ve re-written the DHT22 library to accommodate its unreliability. Including the ability to “reboot” the DHT22 by turning off power to it when it acts up, and then turning it back on. This works for me, but it is pretty much a hack. Won’t be using any more DHT22s as I wire up the rest of my house.

Anyway, if anyone wants my re-write, let me know and I’ll send it to them. I don’t really want to post it as it isn’t code I’m proud of, and I don’t want to spend the time to clean it up.

1 Like

@rvnash, by using the Piettetech_DHT library, those problems go away. It is not a problem with the DHT22s but my now deprecated library!

Thanks. I’ll try the new library. It should be easy for me to drop it in and run it for a day or two. I’ll let you know if my problem clears up. I sure would like to get all that junky handling of DHT22 hangs out of my code.

1 Like

I was asked to post the code that I am using to read a DHT22 and post to ThingSpeak.
My programming ability is at a Kindergarten level, please be kind.
I use ‘ThingSpeak’ because it has some very straightforward triggers, which I use to eventually get a text message on my phone if the readings stop for a certain time, or if the temperature gets outside of a specific range.

(Edit) This code is currently running on a Photon.

There is a ‘control’ pin that I am using to set the Photon to ‘deep sleep’ between 15 minute readings for battery operation and power savings. If you don’t have a way to bypass deep sleep, you can not reprogram the Photon because it won’t hear you.

// This #include statement was automatically added by the Spark IDE.
#include "PietteTech_DHT/PietteTech_DHT.h" //This is for DHT-22 Temperature and Humidity sensor.

// ThingSpeak is a simple but very powerful data collection service, with comprehensive
// 'triggers' that can be used to display and automate data responses.

String writeAPIKey = "abcdefghijklmnopo123456"; //The ThingSpeak feed ID

TCPClient client; // SPARK built in TCP/IP client.

float tempC = 0;
float tempF = 0;
float humidity = 0; // An example variable to send to ThingSpeak
float feelsLike; // The 'feels like' temperature adjusted for humidity.
int ledD = D7;  // Use the built-in LED as a rudimentary status indicator
int controlPin = D6; // Ground for battery operation, high for continuous and reprogramming.
boolean control; // contains choice of power source, 0=battery, 1=line voltage 
long sampleTime = 15; //Sample time in minutes
unsigned long lastMeasureTimer = 0; // How much time in milliseconds has passed since  last measurement.
#define DHTPIN 4     // what pin we're connected 
#define DHTTYPE  DHT22       // Sensor type DHT11/21/22/AM2301/AM2302

void dht_wrapper(); // must be declared before the lib initialization
PietteTech_DHT dht(DHTPIN, DHTTYPE, dht_wrapper);

void setup()
    pinMode(controlPin, INPUT); // Set the power source pin 
    pinMode(ledD, OUTPUT); // Set the status LED as an output so we can use it as a status indicator
    Spark.variable("var1", &tempF, DOUBLE);  //Store tempF as var1 on the Spark website
    Spark.variable("var2", &humidity, DOUBLE);
    lastMeasureTimer = millis() + (sampleTime*60*1000) + 1000; //Advance the timer to allow for an immediate initial measurement.
    delay (3000); //Allow things to settle down with the Spark Core connection

// This wrapper is in charge of calling
// mus be defined like this for the lib work
void dht_wrapper() {

void loop()
control = digitalRead(controlPin);

if (control == HIGH ){ 
    if (millis()-lastMeasureTimer>sampleTime*60*1000) {
        lastMeasureTimer = millis();

else if (control == LOW) {
    Spark.sleep(SLEEP_MODE_DEEP, sampleTime*60);


void ThingSpeak(String tsData) {
    if (client.connect("", 80)) // Try to connect to ThingSpeak
        client.print("POST /update HTTP/1.1\n"); // Required info
        client.print("Host:\n"); // Required info
        client.print("Connection: close\n"); // Required info
        client.print("X-THINGSPEAKAPIKEY: "+writeAPIKey+"\n"); // Required info
        client.print("Content-Type: application/x-www-form-urlencoded\n"); // Required info
        client.print("Content-Length: "); // Required info
        client.print(tsData.length()); // Required info
        client.print("\n\n"); // Required info
        client.println(tsData); // Required info
        delay(100); // Allow time for data to be processed before closing connection 
        ledStatus(3, 50);  // Flash LED 3 times quickly to indicate success!    

        // Connection failed
        ledStatus(3, 2000); // Flash LED 3 times slowly to indicate failure to connect.

    client.flush(); //required TCP housekeeping
    client.stop(); //required TCP housekeeping

void ledStatus(int x, int t)
    for (int j = 0; j <= x-1; j++)
        digitalWrite(ledD, HIGH); // LED ON
        delay(t); //Wait some time
        digitalWrite(ledD, LOW);  //LED OFF
        delay(t); //Wait some time

void postToThingspeak(){
    	while (dht.acquiring())
	humidity = dht.getHumidity();
   	tempC = dht.getCelsius();
    tempF = dht.getFahrenheit();
    if (tempF > 80)  
        feelsLike = -42.379 + 
               2.04901523 * tempF + 
              10.14333127 * humidity +
              -0.22475541 * tempF*humidity +
              -0.00683783 * (tempF * tempF) +
              -0.05481717 * (humidity * humidity) + 
               0.00122874 * (tempF * tempF) * humidity + 
               0.00085282 * tempF* (humidity * humidity) +
              -0.00000199 * (tempF * tempF) * (humidity * humidity);
    else feelsLike = tempF;      

    if (tempC != 0 ) ThingSpeak("field1="+String(tempF,1)+"&field2="+String(humidity,0)+"&field3="+String(feelsLike,1)); //Set a text value to send to ThingSpeak as data, and call the function tp send the data.
    Spark.publish("temperature", String(tempF,1));

// End of code

I dont think its fair to call the DHT22 unreliable - I have used the PietteTech library for many months on several devices and had very high reliability with readings.
There are other factors which may affect your perception of reliability.

  1. Clean power - if you dont have a good power source you will get very innacurate readings.
  2. DHT22 is made by more than one manufacturer, I believe the quality of the sensor varies among them. I have had very good results with the ones which say AOSONG on them.
  3. Wire length - I have heard reports that if the wire length to the DHT22 is too long you can get poor readings.
  4. Taking readings too often. The reliability seems to be higher with long intervals (e.g 10 mins). At 1 min intervals I started to see more dropped readings.
  5. Affected by other components. If the sensor is near any component which generates heat you will get poor quality temperature AND humidity readings.

If those issues are a dealbreaker then you can try the SHT15 instead which has higher accuracy and is much less prone to the effects above (except 5 which is about the same).


I switched to using the Piettetech_DHT library about 12 hours ago, and my Core has been reading the temperature every minute for the last 12 hours without a failure. See chart.

This is far longer than I ever got constant readings with the previous DHT22 library. Perhaps I was hasty in declaring DHT22’s unreliable. It appears with the right software it behaves reliably.

Thanks a ton, @peekay123.


@rvnash, super glad it is working for you!! You really need to thank @mtnscott for creating a great library! :smiley:

A few other people continuing to post that they have been having trouble with their DHT22’s prompted me to check if mine was still going.

Thanks @mtnscott for the library. It has now been sampling every minute for 12d with no failed reads whatsoever. I’d say it’s solid.


Should those using the ADAFRUIT_DHT library also switch to PIETTETECH_DHT?

Not sure about those, since I’ve heard some success stories about that as well. The Piettetech one has proven to be reliable for many months so far, and is non-blocking. Use the one that works best for you.

Ok, thanks. I’ve been using the adafruit library for the past day on a photon with no issues.

I have got an arduino due running the adafruit_dht lib and a photon and a spark running the piettech_dht lib.
A 2 second read delay (non-blocking of course) seems to be the way forward depending on what else is going on.
The spark has a dht11 connected and reports an almost constant 75% humidity. The temperature is much more accurate.
The due and photon humidity readings are 50.8 and 63.0 percent right now as I look at them. Both are on identical DHT22s. Both report identical temperatures.
This seems wildly out of the accuracy range quoted for the sensor. I will try to swap them, maybe it is just variance in the sensors.