@peekay123, because the sensor only needs a 1ms low pulse (10us works too), what else can we send to them to send data? In the picture you see the added 4 NiMh batteries for 5V power support. More results tomorrow …
Your driver software is a very nice piece of work. I just tried to figure out why the sensor doesn’t send any data. The approach of use a pin to power the sensor is a good hack. Hopefully it is not neccessary.
@digixx, I would love to take credit for that library but I only adapted from a great Arduino library by Scott Piette. I don’t know why the DHT22 seems to work then stall. I have tried it at 3.3V and 5V and it does the same thing with the library. So I am writing a library that can recover when it does stall. A lot of folks using it on the rPi have had the same issue and no one knows why. Possibly a voltage fluctuation on the supply line was one theory.
I found a big issue
Wow - this is a great thread on the DHT Non-Blocking interrupt library I ported back in Jan. @peekay123 has done a great job along with @digixx and @v8dave debugging it and trying to figure out how to keep it from hanging.
@peekay123 Since you have the library on Spark IDE, I forked your library and was going to add support for DHT11 sensors as well as add code to support returning the old data if you issue a read request within 2 seconds and issue a pull request. Turns out part way I found this thread and stopped the changes.
Does someone have a current up to date library? @peekay123 your repo is 4 months stale. @digixx and @v8dave can you make your libs available?
In the spirit, I actually took this library from https://github.com/niesteszeck/idDHT11 I just checked his repo and it had not changed other than adding a two sensor example.
So I am happy to pick it up again and try and merge in the changes suggested on this thread -
What do you all think?
Scott
@mtnscott, the non-blocking DHT22 library is stale because I and other members have been experiencing sensor “stalling” with the current code. I have been thinking about redesigning the entire library to use timer interrupts for sampling the DHT data in order to create a new non-blocking library. I was not able to identify the conditions which cause the sensor stall. Now I realize that the SparkTimerLibrary may not be playing nice with other firmware or hardware bits so I have to research that.
I appreciate you enthusiasm and applaud any changes/improvements you may make to the code. 
Hmm Ive been noticing some strange issues with that library too.
Apparently they have been having problems reading data back from the DHT22 with the AirPi - they have written some additional code to deal with it.
Code is on GitHub :
http://www.raspberrypi.org/forums/viewtopic.php?f=37&t=72911
@Rockvole I have reworked the library to address the reliability. I have made significant progress. It works reliably now with all the DHT line of sensors. I have taken many of the suggestions on this thread and incorporated them into the DHT library. I am currently running long term tests and will publish an updated version of this library with new examples shortly.
It has been running for 16 hours, I have taken 11,800 samples from two sensors (one DHT11 and one DHT22) and only had one error.
These sensors have critical timing and the timing parameters vary by manufacturer. I have tested samples from two different manufacturers.
@francisdb Are you using one sensor or two? I have the library working with one sensor and next will be getting it working with multiple sensors.
single sensor, a RHT03
Did you already publish your version of the lib?
@peekay123, @francisdb, @digixx, @v8dave I have published a newer version of this library. Feel free to try it and let me know how well it works. The class name changed but the methods should be the same.
