DHT 22 errors - 0 and nan reading

Archives GrovePi
, ,
1

Hi,

I have a script that does a temperature and humidity measurement every minute.
I now logged every error and besides the known ‘nan’ errors there are a lot of wrong readings resulting in a temperature of 0. Also the humidity sometimes reads a 0.
It is random.
On one day I have about 100 errors or about 8% of all readings.
I have it on 2 systems, so it is not hardware related.
I used your script but modified it slightly to be able to detect the error and write it to an error log of my own.
Is an error rate of 8% normal? I also have a pressure sensor on the same board that I also consult every minute and there no errors at all occur. My DHT port is number 2.

Thanks for your reply,

Freddy

2

What do you mean by error?

3

Hi cluckers,

I’ll asume the following:

  1. You have either have the RaspbianForRobots image or the Jessie (with the required dependencies from our repo installed)

  2. You have installed the firmware on the GrovePi

Now, what you’re describing is a symptom of the following:

  • Grove cable not properly connected to the board
  • Bad port selection.

For starters, I’m suggesting you to check the port you’re using from the python script, because I’m afraid you have a port mismatch. Also, check the DHT module on D4 and see how it goes. Might be a good idea to take a screenshot of what you get and post it here.

The next suggestion is to check your cable connections - might be a good idea to give your connections a small nudge, just to be sure they’re plugged in.

This is all for now.

Thank you

4

Hi Kevin and Robert,

With errors I mean wrong readings like ‘nan’ (not a number) or a zero value when there is normally 20 °C.

I have RaspbianForRobots and the latest firmware.
I had checked the cables, replaced them and even connected them to a different. I does not help.

Be aware that I do have correct readings in 90% of the cases, but those errors are annoying when one wants tp plot the results in a graph or use it to make decissions based on those readings.

Kind regards,
Freddy

5

Hi cluckers,

I find 8% to be quite too big as an error rate.
I would have said that 0.1 - 1.0% is okay, but this seems a lot.

I’m suggesting you one thing: if you have some

to clean the connectors on both the GrovePi and the DHT sensor. Please do it with the board powered down, since otherwise you risk getting shorts. Use a tissue or a cotton fiber (you can get it at any store).

It’s common to experience bad readings if the connectors don’t fit properly or if they don’t oxidize.

DeOxit really does the job and if you’re from US (I’d say buy it from radio shack) buy it, but at the end all of them are good.

After you’re done doing this, please take a look at this post and try out that script.
It would be great to let us all know how it goes.

Thank you

6

Hi,

I did all the cleaning with alcohol, but it did not cured the problem.
Also it is no matter of wrong reading and taking an average…
It all of a sudden provides a zero value at random intervals.
Again I only have this with the DHT, and not with the other sensors.

Kind regards and thanks for the reply,
Freddy

7

Hi cluckers,

Since there’s only an 8% error rate, it’s quite hard for us to replicate such a situation.

The only thing I can think of is still about electrical connectivity.
Have you tried with a different cable?
Different port?
Added delay between readings?

The idea is to try all the imaginable variations you have at hand.
For us, it’s harder to test such things, because we aren’t there with you, so because of this, we can only give advice here and there.

Please read this post and see that there’s someone else who also encounters errors on the same sensor, but much less frequent (this lesser frequency of encountering errors makes me think there’s something with the cabling).
I’ve written him a script which tries to eliminate the noise. I suggest you try it.

Finally, I’m waiting for your answer as to how it went.

Thank you!

8

Hi Robert,

Thanks for your fast reply.

I changed the cables without solving the problem.
I have a delay of 1 second before the actual reading.
I will change ports tomorrow but it would surprise me if this would help.
Here is my code (just for info).
Sorry for some comments in Dutch

Read Temp en Humidity

def d_ReadTH():
global str_t
global str_h
global temp
global e_errorMess

str_tnu = str_t
str_hnu = str_h
e_errorMess = 'Sensor: DHT sensor'	
time.sleep(1)
[temp,hum] = dht(dht_port,dht_sensor_type)		#Get the temperature and Humidity from the DHT sensor	

str_t = str(temp)
str_h = str(hum).split('.')[0]

if str_t == 'nan' or str_h == 'nan':
	##### - In fout log schrijven - oude waardes gebruiken?
	e_errorMess = 'Sensor: DHT nan fout'
	print 'Fout: [' + str_t + '] - [' + str_h +']'
	WriteFout()
	str_t = str_tnu
	str_h = str_hnu
else:
	if initN == 0:	
		if abs(float(str_t)) == 0.0 :
			e_errorMess = 'Sensor: DHT temp 0 fout'
			WriteFout()
			print '    Sensor T:',str_t
			print '    Sensor str_tnu:',str_tnu
			if abs(float(str_tnu)) > 1:
				str_t = str_tnu
				
		if abs(float(str_h)) == 0.0:
			e_errorMess = 'Sensor: DHT hum 0 fout'
			WriteFout()
			print '    Sensor H:',str_h
			print '    Sensor str_hnu:',str_hnu
			if abs(float(str_hnu)) > 2:
				str_h = str_hnu
9

Hi cluckers,

You’ve made me test the DHT sensor too and I got nothing suspicious at all.

In order to eliminate any software suspicion I recommend you do the following things:

Part I

Update your GrovePi firmware. So, open a terminal and follow this commands (I know you’ve said you have the latest firmware, but I want to be sure)

cd ~/Desktop/GrovePi/Firmware
sudo bash firmware_update.sh

Part II

Use our DHT example program. The reason I’m suggesting this example program is because you’ve written your program slightly different and I’m not sure of the consequences.

#!/usr/bin/env python

import grovepi
import math
# Connect the Grove Temperature & Humidity Sensor Pro to digital port D4
# This example uses the blue colored sensor.
# SIG,NC,VCC,GND
sensor = 4  # The Sensor goes on digital port 4.

# temp_humidity_sensor_type
# Grove Base Kit comes with the blue sensor.
blue = 0    # The Blue colored sensor.
white = 1   # The White colored sensor.

while True:
    try:
        # This example uses the blue colored sensor. 
        # The first parameter is the port, the second parameter is the type of sensor.
        [temp,humidity] = grovepi.dht(sensor,blue)  
        if math.isnan(temp) == False and math.isnan(humidity) == False:
            print("temp = %.02f C humidity =%.02f%%"%(temp, humidity))

    except IOError:
        print ("Error")

I hope these suggestions will solve your problem.
I’m waiting for your input, cluckers.

Thank you!

10

Hi Robert,

Today I changed the software to the proposed code and used another port.
I still got some faulty readings.
It is the same problem as with Roy wich you solved by statistic code using standard deviation.

Next week I will try to implement your code into my program.
I never used a thread in Python so I will give it a try.
Can I just change your ‘main’ routine into another name and just call it from my code?

I convert my data into a string because that is what the iOT site ask me to do.
My code is far from being sophisticated.
I am really a hobbyist, so I do not fully understand your code.
However I fully understand the maths behind it.

Many thanks for your continuous support.

Kind regards,
Freddy

11

Hi cluckers,

I still got some faulty readings

Does this mean that the rate of errors you get in a period of time lowered (like under < 8%)?

If you want to use the Main function somewhere else, then you have to remember the following:

  • the Main function can be called once only (at least in this case)

  • when you want to terminate your program, you must go through this instruction : event.set() - this instruction basically stops the while loop and lets the thread (aka the other process) to finish, hence you can end your program. Otherwise, it will hang indefinitely

  • when I wrote the example script I hadn’t had in mind the term reuseability, so porting what I have done might be more difficult

So, I’m suggesting you go with the script I’ve posted and leave it unaltered and only after you’re sure your not getting any more bad readings, then you can start implementing your own solution.

I’m waiting to see how it goes for you.
If there’s anything you want to be clarified, please let me know :slight_smile: .

Thank you!

12

Hi Kevin,

Yes it is now below 8%. Around 2 % yesterday.

As porting your routine into my program might be difficult, I doubt that I are capable of doing so.
I will try your script separately and come back to you with my results.
I will modify it slowly so that I am able to provide you with some statistics.

Kind regards,

Freddy

13

Hi Kevin,

I have tested your program and it is working perfect.
However, I now need to integrate it into my project.
Any idea how I should manage that?

I would just like to have a call for the results???

Kind regards,

Freddy

14

Hi cluckers,

I know this isn’t the usual way of doing things, but I think I can come up with something more portable in a few days.

This way you’ll be able to use it in your code, as well as others that want a solution for themselves.

Does this sound good to you?

Thank you!

15

Hi Robert,

I sounds wonderful to me.
Many thanks.

Freddy

1 Like
16

I have faced the error while installation of this and I think it was due to the iTunes Error 590624 that has already occurred in the device I am using. But will fixing it solve the error?