dtoverlay=dht11?

[knute]

When I first tried using the dht11 overlay a while back, I had some difficulty getting it to work with a DHT22. I needed to set up some temperature sensors and so thought I would try again and it appears to work OK now with a DHT22. I am having one issue and that is what I think are conflicts with the system writes to the data storage location and my software's reads. I get two different error messages back from a cat of the storage location or the sensor value:

[email protected]:/sys/bus/iio/devices/iio:device0 $ cat in_temp_input
cat: in_temp_input: Input/output error
[email protected] ocalhost:/sys/bus/iio/devices/iio:device0 $ cat in_temp_input
cat: in_temp_input: Connection timed out
[email protected]:/sys/bus/iio/devices/iio:device0 $ cat in_temp_input
27000
[email protected]:/sys/bus/iio/devices/iio:device0 $ cat in_temp_input
27000

Is there some sort of file locking mechanism or do I just have to put up with the occasional failed read?

I have hunted around for documentation and code for the overlay but have not found anything. Is the code for the overlay public? There must be some more documentation somewhere because I had the location of the data in my notes from long ago but I can't find it anywhere other than in forum posts now.

Thanks

[jdb]

The "protocol" used by the DHT sensors is a bit tedious. They respond with a variable-length pulse-position modulated signal that has quite a small timebase - 20uS - and the Pi sometimes misses these pulses resulting in a failed decode.

A while ago I did try submitting an upstream patch that increased decoding reliability somewhat, but after a couple of weeks back-and-forth with the maintainers of the relevant kernel driver(s) it didn't get accepted.

I would suggest repeatedly reading the sensor value at a 2-second interval and discarding any IO errors. The returned data word is protected by a CRC so this practically guarantees that any read result that does not have an IO error is the value the sensor reported.

[joan]

The DHTxx series use a simple checksum rather than a CRC.

For a reliable reader try http://abyz.me.uk/rpi/pigpio/examples.html#pdif2_DHTXXD

[knute]

I would suggest repeatedly reading the sensor value at a 2-second interval and discarding any IO errors. The returned data word is protected by a CRC so this practically guarantees that any read result that does not have an IO error is the value the sensor reported.

So I've been reading the file every few minutes and if I get an exception I wait 400ms and read it again. I do 5 attempts this way and if I don't get good data I move on. Should I spread out the interval to 2 seconds? Does reading the data file trigger a read of the device?

I haven't been able find any documentation on this overlay other than how to enable it so I really don't know how it works.

These sensors are on Pi 1Bs. Do you think it would work better on faster Pis?

Thanks

[knute]

The DHTxx series use a simple checksum rather than a CRC.

For a reliable reader try http://abyz.me.uk/rpi/pigpio/examples.html#pdif2_DHTXXD

Thanks Joan, I looked at your code and I and have written a C program using the pigpio library that works pretty well too. I used Java for the program I'm working on because I wanted to send some emails on temperature readings and that is really easy to write in Java (and I know it pretty well). Reading a file location for the temperature/humidity is pretty simple as well.

Thanks