DHT sensor


#1

Hi,

I am playing with my neat, new GrovePi+ Starter Kit. I especially love the backlit RGB display!

I have never seen sensible values reported by the DHT sensor. With it plugged into port D7, this happens:

>>> from grovepi import * >>> dht(7,1) [-0.0, -1.694739530317379e+38]

This seems different from other questions in this forum on this sensor.

This is fresh clone from the GrovePi github repo. And, following a suggestion in an earlier question about this sensor, I did a firmware update.

The sensor itself has “Temperature&Humidity Sensor v1.2” printed on the back.

Is this a bad sensor? Bad board? A sesnor version not supported by the software?

Thanks!
B


#2

Hey,
The Humidity and temperature sensor comes in different variant. Do check this post: http://www.dexterindustries.com/forum/?topic=537-6c-displayed-in-home-weather-project/#post-4485 and let us know if it helps.

-Karan


#3

Turns out that the DHT11 that came in my GrovePi+ Starter Pack is defective. When the dht function was called with the correct arguments, read_i2c_block would always return a list with every element set to 254. Oh well.

I had one of these lying around – http://www.adafruit.com/products/393 – so I attached it to a 4-pin connector and gave it a try. Worked out the starting gate. Should have tried that before asking my question!

Thanks for answering on a Saturday, though! The information about the different sensor types and the argument for the DHT function was very useful. Perhaps that could be made clearer to the someone opening the Start Kit box for the first time…

Cheers,
B


#4

Hi,

Not sure I should create another topic or follow this one,…
I’m polling my DHT sensor in a Python loop and sometimes got errors (see http://www.dexterindustries.com/forum/?topic=issue-with-analog-ports-reads/#post-4790).
My problem is that, in case or error, grove_dht() return -1 (single int value) where it returns [temp, humidity] (float tuple) when reading is OK.
I’m no Python guru, I don’t know how to handle the two different kind of return values.
Should I modify grovepi.py to return [float(‘nan’), float(‘nan’)] is case or error? Then what about upward compatibilty with futures versions of grovepi.py?

Benoit


#5

Hi Benoit,

You want to use python’s exception handling mechanism.

In this case you would want to test the type of the return value. If it is equal to -1 (or if it’s type is ‘int’), then pause for a fraction of a second and try reading the sensor again. If the type is ‘list’, then test you can break out of the “try” block.

I’m at work right now and don’t have access to my RPi, but when I get home I’ll try to remember to post my actual solution.
B


#6

Hi,

I did something like if type(ReturnValue) == types.IntFloat: do process the valid readings only.
Thanks for the help.

Benoit


#7

Hi Benoit,

I found it useful to break the dht() function down into its prts. That made it easier to do effective exception handling. Here’s what I did:

This little program almost always writes a useful value to STDOUT, although it sometimes takes several seconds.

HTH,
B


#8

Hey Tartiflette,
We just updated the GrovePi library on Github so it should not return a tuple [-1,-1] in case of errors which should be easier for handling the errors.

Please update your local repo and run sudo python setup.py install to install the library.

-Karan


#9

Thanks Karan (again) for this improvement.

Benoit


#10

Nice piece of code, Bruce. I’ll try it tonight.

Benoit


#11

Benoit,

You could do the same trick of using a try/except block inside of a “while True” block using the higher level dht() function. I found it was a bit more efficient to wrap up the lower-level function calls. Doing so also made it easier for me to understand what was actually going wrong when one of the functions for the i2c bus was not returning the expected value. It’s all a bit crufty, though – for instance, I hardwired the port addresses.

The “while True” block at the end dealt with the somewhat common situation of getting proper responses from the i2c bus, but having values that resulted in enormous and negative values for temperature and humidity.

It sometimes takes 10 or 15 seconds for everything to line up and return a sensible value. That time doesn’t much matter since I am running it as a cron job.

Just for fun, here’s the end result, which is a log of T and H in my greenhouse using the DHT sensor and the analog temperature sensor that comes in the Starter Kit: https://s3.amazonaws.com/bruce-ravel-site/weewx/DHT.html

Cheers,
B


#12

Hey bruceravel,
The project that you have up and running to grow the plants looks awesome. We are glad that GrovePi helped you to make it and would love to get some feedback about the GrovePi and any improvements that you would like.

Also, do share your project with us. It would also be great if you could share details and pictures of your project with the community. We have an Instructables contest running too http://www.dexterindustries.com/forum/?topic=pie-day-contest, so you can post your project there and you might end up winning some awesome goodies.

-Karan


#13

Hi Karan,

The Instructables contest looks like fun. I’ll think about it.

I am still poking at the details of my project. The solution I chose involves a python script on the RPi which writes text to stdout. I then call the script via scp from the computer where I maintain the database and parse the text. (I’m a unix guy from way back :slight_smile: That’s kind of an awkward way of doing things, mostly because there are timing and timeout issues involving the 12c bus and the ssh connection that have to be managed correctly. Happily, it’s working better now than earlier in the week! And several of my eggplant seeds sprouted last night!

I was actually thinking of offering a pull request with some more robust exception handling in the python. That’s sort of more my speed than entering a contest.

Anyway, I’ve been having a lot of fun with my GrovePi toys. It’s all very neat.

If I had one request, I would like to know if it is possible to do some kind of software reset of the GrovePi board. In my playing, I occasionally get into a state where the GrovePi board is unresponsive but the RPi is still working fine. Then I have to walk out to the garage and power cycle the RPi.

Cheers,
B


#14

Hey,
Glad to hear that GrovePi is working well for you and hope that your eggplants are doing well too.

There is a way to reset the GrovePi. The reset pin is tied to CE0 pin (GPIO8) on the Raspberry Pi. You can simply toggle it to reset the GrovePi (reset should be low). So you should give gpio mode 8 out gpio write 8 0 gpio write 8 1 to reset the MCU on the GrovePi, but you might have to reset the I2C connection that is used in the code, before you start using it again.

If you want to use this from the python code, then using subprocess library might make sense.

Do keep us updated about your greenhouse and if you ever find some time to write about it, do share it with us.

-Karan


#15

Grovepi+ reliability when getting values.

I am just testing the grovepi+ with the humidity sensor (DHT11). I am reading temperature and humidity but sometimes I get -1 or nan. I do not have problems to filter this, but I am concerned of the reason why we are getting such values.
Is there any prob
lem with the board or the driver?

Note: I just updated the libraries but it does not change.
I tested the sensor on a standart arduino board and never receive a bad value.

I intend to devellop applications using up 6 DHT sensors with 20 meters câbles and would like to understand why we are getting such bad values.

Can it make the board or raspberry crash?

Is it a software or an hardware problem when I am getting nan with a standart cable of 20 cm long?

Regards


#16

Hey,
The -1 reading is because of IOErrors and are caused when the PI is having some difficulties talking to the GrovePi. It is not a hardware or a software problem and is more about the setup that you have. There might be times when you are polling the sensor too fast and the sensor is unable to cope up with the speed, the I2C buffer gets filled up and you get a wrong value back, errors from the sensor itself. We have been working to make it as reliable as we can can but some errors are still there. We just recommend people to use exception handling to take care of that.

I am not sure if the DHT sensors would work with a 20m long wire. These sensors work on 5V logic and there is a very big possibility that they might not work with a 20m cable. You might have to use use modbus and have a dedicated controller over each end to have communication over that long range or you could tinker with something like this http://www.seeedstudio.com/depot/DevDuino-Sensor-Node-V2-ATmega-328-AAA-battery-holder-p-1850.html?cPath=19_22 to make the communication possible.

-Karan