Stability problems with GrovePi

I am building a temp / humidity tracking and fan control system with GrovePi, various grove sensors and a RasPi B. My py code basically is built from files in the examples directory supplied with the GrovePi, obviously modified to provide the functionality I need.

The program runs in a continuous loop, sampling and reporting every 60 sec. After some period of running (I am time stamping and trying to determine how long), the program crashes with a not very meaningful (to me) math error or an error that some constant doesn’t iterate.

In a separate post I talked about 1-wire sensors, but I’ve removed those and am working only with the temp / humidity pro sensor, a couple of LEDs and 2 relays. Same issue arises with and without the 1-wire sensors, so it’s not a result of that issue.

I will get exact text and approx duration of successful running - will post once I have that. Has anyone had this kind of experience? I’m still digging around the forum, but figured I should ask if this sounded familiar.

I do have firmware 1.1 - unit recently purchased, and I checked for “1.1” in version.txt.

Tx,

Robert

Here is one of the two types of error messages that I have seen with this device. The first 3 lines are output from my program, and are printed out every 60 seconds as long as the program is running. The error starts with line 4:

Sample time = Mon Aug 11 16:10:48 2014
Inside temp = 59.3 F
Inside humidity = 52.3 %
IOError
Traceback (most recent call last):
File “./GrovePi/Software/Python/hutch_manager.py”, line 68, in <module>
[inTemp,inHumidity] = grovepi.dht(insideTempHumid,1) # Inside temp and humidity
TypeError: ‘int’ object is not iterable

This time the program ran for almost 3 hours. I launched it in the background (&) on my Pi, as I operate the Pi via vSSH from my mac.

Also I am starting to disbelieve the temp reading from this device. I’m doing the C -> F conversion in the code. It’s been reading 58-59F since early this morning, and the room is closer to 70-75. It doesn’t seem to respond when I hold the sensor in my hand for a couple of minutes. I’ll get one of those indoor thermometers from Lowe’s to compare readings. Will post that also.

Just want to confirm that you are using this sensor: http://www.seeedstudio.com/wiki/Grove_-_Temperature_and_Humidity_Sensor_Pro .

This sensor gives the output value in Celsius. Can you try out this example code just to see if the sensor is working properly or not https://github.com/DexterInd/GrovePi/blob/master/Software/Python/grove_dht_pro.py . For us the sensor does give correct readings.

For the error that you are getting, even we have seen that. It’s mostly because of an occasional error in communicating with the GrovePi or getting data from the DHT sensor. You can just add another exception handling statement at the end and it should pretty much take care of it. Something like:

except TypeError:
   print &quot;Error&quot;

This should solve your problem.

-Karan

Hi Karan,

Yes that is the sensor that I’m using. Thanks for checking!

I have added the TypeError exception and restarted the program. I’ll let that run and see what happens. My program was built from grove_dht_pro.py and bits from other examples. I’m getting readings, but dead steady at 58-60F (I’m converting in my code - but the Celsius readings before I added the conversion were equally stable.) I’ll pick up a cheap digital house temp / humidity box today.I just don’t think it’s 58F in this room!!

I saw a new non-normal situation just now that did not throw an error. Both the temp and humidity values came back “nan”, but that didn’t cause a fatal error. I noticed the problem when those values displayed on my LCD. I checked the console, and had the same thing there. It happened on the second sensor read after I restarted the program and has not happened again yet. Whatever the error condition, it did not trigger either of my exceptions IOError or TypeError. I got the IOError from your example code. Curious thing is that I have received error messages that printed IOError to the console, but the print statement in the exception never triggered. Dunno what that is about.