@jon Pull-up resistors help condition the signal with better edges on the transitions. For another test I went back and tried my DHT_Simple application on a clean core wired up with one DHT22 on pin D3 and nothing else. I get the expected behavior - normal readings and the humidity started at 17% and moved up when I breathed on it. I have my sensors laying flat on the board.
Do you have several sensors? Can you try another? Could you post a picture of the setup?
What you are describing seems very odd. I would not expect the behavior you are experiencing. Which example from the PietteTech_DHT library are you using?
@mtnscott I have two DHT22 sensors (and a DHT11 on a small circuit board that I have not tried yet), both give the same result. I an using the DHT_Simple application since I have only one sensor attatched and I like to get it working first. I am attatching pictures of my setup and a screen dump of the readings when I breathe on the sensor.
Not clearly visible but the 1K resistor is situated between power and data pin. No connections are made to the pin between data and ground.
The readings are off, and when I breathe on the sensor humidity goes down to 1% and then recovers back to around 17%. As I just restarted the board (had it running without resistor for 24H but with no improvement) humidity is slowly climbing and will level out at 24%. So my āhackā humidity = (100 - DHT.getHumidity()) - 25 actually gives a reading that goes up when I breathe on it and shows correct values. Not really production material thoughā¦
I realoaded your sample āUse this sampleā and re-flashed the Spark before taking pictures. I have had my Spark running for several hours in this setup before I started trying the other sensor (same result), no pull-up and with my hack. The only change I made to your sample is to comment out the prints of Kelvin, Farenheit and Dew point for better readability after checking that it is the acquireAndWait that does the read from the sensor. The readings are now as I write this at 22.60% humidity and temp at 23.50.
NB I have checked that I flash with #define DHTTYPE DHT22 and #define DHTPIN 3
@jon This must be utterly frustrating. Sorry you are having so much trouble. Iām at a loss as to what is going on with your configuration. I have tested this with DHT22 sensors from multiple vendors, DHT11 sensors and AM2302 sensors. All purchased at different times and from different vendors. They all produce the expected behavior - breathing on them increase the humidity output. I canāt seem to reproduce what you are experiencing.
I hate to ask ā¦ but is it possible you got a bad batch of DHT22 sensors? Did you order them at the same time and from the same vendor? Is your DHT11 from that same vendor? Would it be difficult to try the DHT11?
Iām feeling your pain, this has been dragging out way too long. I purchased my sensors from SparkFun, Adafruit, eBay, and Amazon.
@mtnscott thank you for taking this wierdness seriously, yes you can imagine I feel pretty stupid. I will try the DHT11 in a day or two. I got my DHT22s from SparkFun but I ordered a couple of new ones from dx.com in pure frustration when this started. Yes, I guess I just had really bad luck with my sensors. Given that they were not totally dead I didānt whant to give up on them
@jon The Dallas 1-wire spec is not what the DHT sensors use. If you want to add the DS18B20 temperature sensor to your configuration you can use the onewire library that is available in the IDE. Iām not sure what you would use the DS2480 for if you have 1-wire directly supported via the Spark library.
Let me know what you discover from trying the DHT11
@mtnscott today is a good day! The DHT11 is working and humidity rises and falls as it should. Finally I can move on. The readings are a couple of % off on temp and humidity so Iām looking forward to use the new DHT22 sensors I ordered when they arrive.
DS2480 is a driver for the Dallas 1-wire protocol. It offloads the microcontroller (and developer) the timings and much of the low level bits of the 1-wire protocol. It just makes me as a developer more productive. Itās kind of a API for both the hardware and the protocol. I have looked at the Spark lib for 1-wire but I am still tempted to use DS2480 (plus I had some issues regarding responsibilities between the OneWire lib and the Temperature lib that made it less suited to extend to more sensor types).
But maybe now I will stick with Spak-single-purpose WiFi sensors and acutators as I got it working. My goal is to extend the Spark cloud which is good at bridging cores to cloud to a more sensor to cloud implementation with sensor discovery and orchestration of scenarios on Windows Azure. I have looked at using Google Blockly to build scenarios for my sensor API. If I get going I will post a project.
@jon, Iām glad you got it working. Iāve built an object wrapper for sensors. It makes managing the variety of sensors connected to a Spark much simpler and modular. Let me know if that would be something of interest.
@jon So the concept is that my object class library provides standard information related to the data it contains. For example you can read the data, what type of data it is, metrics like max, min and resolution, you can assign a name for the sensor such as āTempā and associate it with an sensor_id. Itās modeled from Adafruitās Unified Sensor Library which was modeled from Andriod.
I was not happy with how the Adafruit library handled multi-value sensors such as DHT and BMP, so I modified it to support only one data value per object. This means you will have to create one object class for the low level driver on the sensor such as PietteTech_DHT, then you can create two instances of the PietteTech_Sensor object, one for Temp, the other for Humidity and finally these can all exist in an array of PietteTech_Sensor. Then you just iterate thru the array to get the values.
Because I use multiple Sensor objects for each sensor (one for each value) its more memory intensive (ok on Spark, not so on Arduino)
So far I have it working with DS one wire sensors, BMP and DHT sensors. Iām also working on an object class that will allow you to publish your data from one Spark to another but that seems to panic occasionally - still debugging.
There is also database interface that allows you to easily publish your data to the SparkFun Phant server.
Iām currently working on the back end visualization of the sensor data. I hope to publish a project share of an environmental monitoring station when I get it all working. I still want to add ambient light, wind direction and speed.
@mtnscott that sounds great, and ambitious to pull of on a micro controller level. In my C# lib for sensors Iām taking a similar approach but where I treat Spark as one of several possible sensor providers that publishes sensors and their data in a common collection of typed sensors cross providers. In this way with one interface one can read, ITemperature data for example, from several different named sensors and providers.
ā¦if I would like to get the readings of all Spark temperature sensors in the bathroom (in case I had many ) My goal is to easy orchestrate scenarios based on sensor readings in a high level graphical interface on top of this.
Iām looking forward to try out your lib for sensor abstraction on the Spark client.
Grove DHT22 = 21C / 47% (1" away from VR)
Oregon THGR 122 NX = 17.8C / 66% (6" in front of voltage regulator VR)
I waited a few hours after moving the breadboards near because it takes a while for everything to warm up and give readings away from ambient.
I find the ambient temperature and humidity of the SHT15 are within 0.5C / 1% of the oregon. Ambient DHT22 is typically 1C or 2C away and within 2 or 3% of the oregon.
Basically the SHT15 doesnt behave much differently than the DHT22 when its near the hot VR - so changing to a different sensor isnt going to help that much.
Previously I had the Grove DHT22 on the right hand side because it was simple to add there due to wire lengths. I decided to move all the components around to get the Grove DHT22 far away from the voltage regulator.
This is what it looks like now :
The Grove DHT22 now has reasonably accurate temperature readings, but the humidity is still very wrong. My 3 other sensors all correlate OK with each other, but this is wrong by 3% - 11% humidity - I think it is just faulty.
@mtnscott@peekay123 - an idea I just had. We could replace the DHT22 with a 4-pin female header. I think 0.100" is the same as a breadboard - which the DHT22 plugs right into. If there is a problem with the DHT22 or it breaks long term it could just be swapped out for $3. Also, this raises it off the board reducing heat transfer - if its placed right at the edge of the board it could be tilted away from the PCB.
@mtnscott@peekay123
I asked at smart citizen why they replaced the DHT22 with the HTU21D in the next version.
The reply was that the HTU21D is more accurate and faster to respond.
Probably the reason the DHT22 is slow to respond is because the components are embedded in a chunk of plastic so that has to warm up before you get a change - I have found that too in comparison to the SHT15.
If I had the skills to make a bunch of boards and see what worked I would do that, but Iām still fine with using the DHT22.
) My goal is to easy orchestrate scenarios based on sensor readings in a high level graphical interface on top of this.