[Submission] Updated Non-blocking Interrupt Driven DHT Sensor Library


#1

I have published an updated version of the DHT interrupt driven sensor library. It now supports DHT22 and DHT11 sensors. It has been published it as PietteTech_DHT in the libraries. The source is located at my github https://github.com/piettetech/PietteTech_DHT It includes updated samples, including one that shows timing information while reading two different sensors. As this library is very sensitive to timing I recommend a 1K pull-up resistor on the data line. It has been tested running at 3.3v with both DHT11 and DHT22 sensors mounted on a breadboard. I have not done any testing on longer wire runs. Remember to terminate the data line on any long wire run at the sensor with a 1K pull-up to 3.3v

NOTE: I’m having some problems with what appears to be memory overrun. I recommend for now you keep the timing debug buffer in the object to increase stability. (this is the default)

Interrupt driven DHT 11/21/22 sensor library for Spark
Supports reading DHT22/DHT21/DHT11 sensors without disabling interrupts

Scott Piette, Piette Technologies - scott.piette@gmail.com
Jan 18, 2014 - Initial port to Spark Core
Oct 1, 2014 - Added DHT11/21 support, fixed timing issues, enhanced examples
VERSION: 0.2
PURPOSE: Interrupt driven non-blocking library for DHT sensors
LICENSE: GPL v3 (http://www.gnu.org/licenses/gpl.html)

BASED ON:
DHT11 interrupt library https://github.com/niesteszeck
DHT11 library http://playground.arduino.cc/Main/DHT11Lib

Wiring diagram for Spark Core with DHT22 Sensor

DATASHEETS:
DHT11 : http://akizukidenshi.com/download/ds/aosong/dht11.pdf
DHT22 : https://www.sparkfun.com/datasheets/Sensors/Temperature/DHT22.pdf


Non-blocking interrupt driven DHT22 library
Wrong reading value for DH22 & get stuck after running for a while
Custom Shield - Indoor Air Quality Monitor
[Resolved] blocking DHT22 Library causing issue [use non blocking version]
Case of the Missing Variables
TCPClient + idDHT22 = Hard fault
#2

Very nice, thank you very much!

I only see one small aspect with room for improvement, the ability to use an I/O pin as VCC so you can reset it when it times out, I think it was on the roadmap for @peekay123’s lib as he was reporting timeouts, not sure what became of that.


#3

@henriquepss I thought about that, however in my experience when the device goes into its weird state the main loop does not get executed. The spark seems to hang and eventually recover. So having access to the Vcc on the DHT will not help much because by the time you could actually use it you don’t really need it anymore. But - I am open to explore that if needed. Thanks!


#4

Works correctly with my RHT03 :slight_smile: Let’s see how it does over time.

165 : 9.40s : E=0/165, Retrieving information from sensor: Read sensor A: OK

Seems that my hard fault issue was related to something else after all.


#5

I’m not sure you are getting a good response. The two numbers after the “E=0/165” indicate you are having errors with the Spark. The first number represents errors generated by sensor read “0” so that seems OK - you are not getting any sensor data read failures, the second number “165” tells me that your loop is taking longer then the expected “LOOP_DELAY” time of 5 seconds. For iteration 165 it was 9.4s and it appears every loop is taking longer than 5s. Maybe you are doing other things in your loop that are causing the delay?


#6

@mtnscott yes, I’m also sending data to xively in the loop


#7

@francisdb OK, that’s probably why it takes longer than 5s thru the loop.


#8

@mtnscott, I’ve been running the code with a DHT22 and had the core go into a death loop after a 2.5K readings. I am running it again to see if it fails again or if it was some other factor causing the issue. Then I will run the code without the debug buffer to see if it fails more often.


#9

@peekay123 oh - that’s not good. Let me know how your tests go. @ 5s / sample, 2.5K samples is about 3 1/2 hours. Does your core recover (hang for about 60s, reconnect w/ cloud and then re-enter loop) or just die (no loop activity but breathing cyan)? What is your pullup value?


#10

@mtnscott, a couple of things may have happened, one being the cloud going down, another being some weird error. If I recall (don’t bet on that though!), I was getting red flash (three I think), green, blue, cyan in that cycle. The core did NOT recover. The loop is running at 2.5s intervals (DHT_simple.ino) and it is now up to 4555 samples and still going.

At some point, I will add a second DHT22 and run the DHT_2sensor.ino code to see how that goes as well :smiley:


#11

@peekay123 Ah yes, was that about 4 hours ago?

all my live cores went into 3 red flashes, flashing green and cyan and then back into 3 red flashes.

I started a test with two sensors, one DHT11 and one DHT22 and I’ll let run overnight.


#12

@mtnscott, it may have been overnight but I was not paying enough attention! I’ll be more vigilant if it crashes again. :smile:


#13

@mtnscott, firmware ran all night (20,709 samples) without a glitch. I’ll continue testing without the debug buffer :smile:

UPDATE: The non-debugging version ran for 97 samples before hanging. When I reset and ran a second time, it has been running for 14,105 samples without a glitch. One thing to note is that I am running all tests with NO pullup resistor on the DHT22. :smile:

UPDATE #2: The non-debug version has been running for 35,970 samples without any failures. I will now add Spark.publish and Spark.function to “strain” the WiFi/Cloud connection a bit more. :smile:


#15

Was this run from a cold reboot, or after a reset on a hung state?


#16

@mtnscott, the run was from a reset only. I introduced a Spark.publish after the serial.print lines to publish the values and it ran overnight for 7689 samples until it hung. It was working again after a reset (no power off) so the DHT22 (RHT03) was not stalled it seems. I’ll see how long that runs. Remember that this is running without debug enabled. Another test I want to do is to do a publish BEFORE the sampling to see if that affects performance. :smile:


#17

@mtnscott, I let the code (including the Spark.publish) run all night and it has not stopped. I see the cloud connection dropping every now and then but it seems to recover and continue running. It is been going for 31,405 readings and publishes now. Next, I will move the publish to see if sampling while publishing affects anything. :smile:


#18

@peekay123 that’s good news. I have had a sensor setup with two DHTs and two DS18Bs posting to the cloud every 10 mins running for several days. I have seen a few cloud connection failures, but the data still gets posted on time. I think one delay took 47s to reconnect. My pushes to a Phant server in Spain are reliable.


#19

@mtnscott, nice work on this updated library! During testing I experienced another crash with a single-sensor configuration and though the serial output stalled, the cloud connection and Spark.publish() kept functioning.

I would like to add a comment in my published library that redirects folks to your new library as I believe yours is more stable. One thing missing in the examples is a non acquireAndWait example that shows non-blocking sampling. :smile:


#20

Great suggestion. I just updated DHT_example.ino to not block on the acquisition of the sensor data.


#21

@mtnscott - Thank you for this! I can now put my small handful of DHT22 sensors to work! I’ve polled it well over 2,000 times or so now with no errors!