My system is not in an electronically noisy environment, and the lead connecting the DHT to the GrovePi shield is quite short (about 20cm), so I wouldn't expect much interference. I guess it could be picking up interference from the Pi or its power supply, but I would have expected this to cause the checksum to fail rather than return a spurious reading.
To give some additional information, here is the humidity plot for the same time range as my earlier temperature plot:
Looking at the underlying data:
Here is the low reading around 22:40 pm. 38.8 is exactly half of 77.6:
We can see other examples of readings representing half the true value around 0:40 am, 2:40 am and 6:05 am.
Here is the zero reading around 1:06 am. Note that it shows as -0.0, whatever that means:
You can see several other zero values in the graph.
I've noticed the library code returns NaN (not a number) if the values are out of range. Here's the relevant line from the dht() function in grovepi.py:
if t > -100.0 and t <150.0 and hum >= 0.0 and hum<=100.0:
return [t, hum]
My code, which was based on the sample code, was ignoring these errors and just going round the loop again. Looking at the data, I can see a few instances where samples have been missed. For example here we have a 20 second gap between 20:42:40 and 20:43:00 which indicates that the sample at 20:42:50 was missed:
So I suspect I'm getting occasional NaN results returned, which indicate that the value was out of range.