Non-blocking interrupt driven DHT22 library

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 :smile:

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. :wink: 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

@wgbartley, itā€™s all good dude. Weā€™re all on the same team :wink:

2 Likes

@peekay123, Hi I just tried the example as well and even when i power the :spark: 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 ?

@rudyvan, Iā€™ll setup a DHT22 and do some tests and get back to you. :smile:

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! :smile:

Working great for me :slight_smile:

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.