I finally got the idDHT22 library for Spark working. It is an interrupt driven, non-blocking version of the DHT22 library. The library can be found on my github 
7 Likes
Very cool, thanks for sharing! Iāve got 2 RHT03 sensors that Iām testing with, they both seem to be providing some strange values - temperature is around -40C, humidity at 43.9%. I also seem to be hitting checksum errors nearly every second request. Have you experienced any issues like this?
emc2, Iāve found that not all DHT22/RHT03 sensors are happy at 3.3V. I use the raw 3.3V line on the Spark and not the filtered line because the voltage is below 3.3V and my DHT22s donāt work. Make sure you have a pull-up resistor and that you donāt draw too much current from the 3.3V regulator on the Spark.
Good tip, thanks. 10k pullup already there, moved power to raw railā¦ sensor is responding much better!
1 Like
Iām having trouble with this.
I have this working with the blocking firmware no problem.
When I run this firmware it hangs at āRead sensor:ā.
Itās definitely blocked because I have to reset the core to flash firmware.
I donāt have a pullup resistor in place but this same circuit works perfectly with the blocking firmware. Is this more sensitive somehow?
Edit: With a couple of extra debug lines, I can see itās stuck in the acquiring while loop forever.
kareem613, my experience with DHT22s has shown me that not all are created equal! I use a 4.7K pull-up but it is not always necessary. Nonetheless, I suggest you use one because the non-blocking code is sensitive to the DHT22 data output rise time and the resistor helps. Another thing is the voltage used for the DHT22. I do not suggest powering off the 3.3*v line since it is lower that 3.3V and I have found a lot of DHT22s that will not work at anything even slightly lower than 3.3V.
Try the pull-up and let me know how it goes.
I got passed that infinite loop without the pullup. I got mixed up when switching pins.
FYI. If youāve got the wrong data pin set, it results in an infinite loop.
I now get checksum errors.
To confirm. Pullup goes between Data and 3.3v right?
Yes, that is correct.
Ok. I tried both a 9k and 5k pull up. Still checksum errors.
Bah. Back to infinite loop. When I test 3.3V and 3.3*V I get a 3.25V reading for both.
You can try a 2.2K resistor. Timing is everything in the non-blocking version and I found that sometimes it does not work with all DHT22s. The timing in the code is based on the datasheets and a bit of experience but may not work in all cases. The blocking version may be your only option. Besides, you donāt really need to sample that sensor very often do you?
True. This isnāt necessary I guess. Tried a lower resister. Still no luck. I guess Iāll just revert back to the blocking one.
Thanks for the help!
I have no idea how I missed this topic. Iām back to the DHT22, so Iām going to give this a whirl!
@peekay123, you should have kicked me and let me know. 
I forked your repo, changed the files and directories to line up with the proposed Spark library format, and submitted a pull request. It validates, too! Hopefully you wonāt mind much.
2 Likes
@peekay123, Hi I just tried the example as well and even when i power the 
with 5V and I hook up my DHT22 to the 5V with a pull up of 5K ( 2 10Kās in parrallel) I get a reading of 70% humidity, which is exat the same as my livingroom says. The only strange thing I also see is that the temperatures are negative values of -39.00 for C and -38.20 for F. Any suggestion ?
Thanks @peekay123, iāll cross check tonight the sensor on an adafruit library on Arduino as well to make sure the sensor is not the issue here, Iāll be back.
@peekay123, Hi, When I use the DHT22 sensor on an Arduino like in https://learn.adafruit.com/dht/using-a-dhtxx-sensor then I get normal temperatures, not negative. So are you sure it is not something in the library ?
KR,
Rudy
@rudyvan, it was a problem with the library! I tweaked the timing a bit and now it seems to read correctly at both 5V and 3.3V supplying the DHT22. I posted v0.0.2 of the IDDHT22 library on the web IDE. Give it a shot!
Working great for me 
1 Like
If Iām understanding this, the asynchronous data read of 40 bits from the sensor takes a max of 80 * 40 us = 3.2ms. But thereās a 10ms blocking delay in the call to acquire() - so the bulk of the time is spend blocking.
It might be a good idea to make the 10ms delay asynchronous also, so the call to acquire() returns almost immediately.