With the support of @jdubrow42, I can confirm that a port of Adafruit’s DHT library is working with my core. I have it wired as follows:
There is also a 10k resistor connecting Pin 1 (VCC) and Pin 2 (Spark Core D2).
I’ve uploaded the code to https://gist.github.com/wgbartley/8301123.
<edit timestamp=“2013-01-08 10:04:00”> Updated code link to point to a Gist instead of a full-blown repository. </edit>
This is awesome!
Would you be up for sharing the process you went through in porting?
Rather than post a bunch of libraries I’d like to have ported, i was hoping you could teach me how to fish…
Hi and many thanks for this.
Is this a port of the synchronous/blocking or the asynchronous (interrupt driven) library? If the latter, do the other activities the spark core is carrying out (wifi stuff) interfere with the timing when reading from the sensor?
As far as I can tell after a quick look, it’s almost copy/paste from the adafruit library. Since there is no support yet for libraries the typical way, you have to include everything in one file. So just take the content from your *.h and *.cpp files and combine them at the top of your sketch. You can also remove most of the conditional compiler directives that attempt to test the ARDUINO version, and header guards like:
#ifndef DHT_H
#define DHT_H
#if ARDUINO >= 100
#include "Arduino.h"
#else
#include "WProgram.h"
#endif
I don’t know if it makes sense to do this for a bunch of libraries though, because the Spark Team is working on a way to include libraries soon.
It’s about 99% copy+paste of the Adafruit library. The only real changes are:
#define cli noInterrupts
#define sei interrupts
#define NAN 999999
The rest is pretty much just cleaning up the tabs and braces to my preferred coding style, and removing the Serial.print stuffs.
@BDub, I partially agree about the bunch of libraries stuff. Once the Spark Team has library support, we’ll just need to break this code back into the .h and .c counterparts again. The hard work of porting the code to compile on the Spark Core architecture is the important part.
Reading the Adafruit library code on github, this library is a synchronous or blocking version. It disables interrupts and uses delay commands. So when your code requests the humidity reading, things are held up for two or three hundred milliseconds while the data is retrieved from the sensor. Any interrupts during this period could be missed. For most applications, this will be fine.
There is also available an asynchronous or non-blocking library available for Arduino. This has the advantages that your code can carry on doing something else while the reading is being taken and retrieved from the sensor, and interrupts are not disabled, so will not be missed.
For the application I have in mind, I am going to need the non-blocking version, because I will have other sensors generating interrupts that I dont want to miss, for example a windspeed sensor.
So when my core finally arrives, I can use your version for testing, but ultimately I will need to work on converting the non-blocking version.
Alternatively, I may use an SHT21 sensor. This has a similar spec to a DHT22 (more accurate than DHT11) but has an i2c interface.
Paul
Do you have a link to a non-blocking version off the top of your head (or bookmarks menu)? Since I have my Core in hand already, I can give porting it a try. I'll change the post topic and label this as the blocking version. Thanks for the clarification!
Thanks, that would be great!
Here’s the link: Interrupt driven DHT11 Lib (idDHT11)
Now I’ve had another look, I realise this library supports only DHT11 and not DHT22. This is a shame!
What we all really need is a non-blocking, interrupt driven library that supports both DHT11 and 22.
Paul
I haven’t looked at the non-blocking code yet, but it may be possible to merge the two together to get the best of both worlds. With some if’s and switch’s, I don’t see why not.
Yes, I’m hoping so. Willing to help if I can. I don’t have a core yet (tracking number email arrived yesterday though) but I do have a DHT11 (but not a DHT22).
I’m not 100% sure this “library” is working correctly. It seems to work, but the temperature reading is high. I don’t have a thermometer on-hand here at work to verify, but I know it’s definitely not 79.16F in the office. In fact, my analog thermistor, DS18B20, and DHT22 all read in the 79-80F range. Hrmm…
@wgbartley This is a known issue that's on our backlog to fix. See this thread:
@zach, I didn’t think it would affect the digital thermometers like the DHT22 and DS18B20. Although, it is strange that all 3 sensors (analog thermistor, DHT22, and DS18B20) all report roughly the same temperature. Hopefully I can get a chance to test all 3 sensors in the same loop to get more accurate anamolies.
Keep in mind, temperature varies wildly in a room depending on where the sensor is. It could be under an air vent, it could be close to the Core itself which will be quite a bit warmer than ambient. If even the digital sensor is reading 79, it might very well be within 5 degrees of that!
@wgbartley hey! I have the DHT22, do you guys have the libraries successfully ported over? I am lost on how to get the sensor to work and output the temperature and humidity.
My temp readings seem to be okay, but I get rather low humidity readings ~20% - should be about 45.
Could it be due to the ADC sampling time that @zach mentions?
OT: Is coresoftware(firmware?) automatically updated OTA? or does one have to manually flash it as of now?
Hi @wgbartley, I can confirm your code works fine with DHT11. Thanks again for your work on this so far. Temp & humidity readings match the other sensors I have attached to a nearby Arduino. I’m reading the values over serial. Next learning step for me is to expose the variables to the cloud and see them on a web page.
.
Yes! It's a ported version of Adafruit's library. Unfortunately, I stripped out a bunch of comments since it's still awkward to work with these "libraries" in the web build IDE. I posted what I've used to a Gist at Class for reading DHT22 values on a Spark Core · GitHub.
@wgbartley Thanks for the port of the library. I have it hooked up to a DHT11. The first reading I get is good, but all subsequent readings produce the same output unless I do a reset. Any thoughts on why? Cheers!
Not off the top of my head, unfortunately. I do know that you need to let a DHT22 sit idle for about 2 seconds before you get another reading. I've never tried with a DHT11, but I assume it's probably similar. Now that I look back at the code, not having at least a delay(2000); inside the loop() is probably a bad idea. Maybe try adding in the delay and see if that helps?