RPI dht22 with flask: Unable to set line 4 to input - Timed out waiting for PulseIn message RPI dht22 with flask: Unable to set line 4 to input - Timed out waiting for PulseIn message flask flask

RPI dht22 with flask: Unable to set line 4 to input - Timed out waiting for PulseIn message


Short answer

Remove debug=True and enjoy. :-)

What was going on?

This problem drove me nuts but I think I found the root cause! In my case, I was encapsulating the DHT22 object in another object, like so:

...class DHT22Custom:    def __init__(self):        print("**** BUILDING by {0}!".format(threading.currentThread().getName()))        self.dht_device = adafruit_dht.DHT22(board.D17)...

My main.py looked like:

import RPi.GPIO as GPIOfrom sensor.config.app_config import create_appif __name__ == '__main__':    app = create_app()         # builds DHT22Custom inside    app.run(debug=True)    print("Cleaning up GPIO before exiting...")    GPIO.cleanup()

And look what an interesting output I got:

root@05600e5:/app# python -m sensor.main**** BUILDING by MainThread! * Serving Flask app "FlaskWS" (lazy loading) * Environment: production   WARNING: This is a development server. Do not use it in a production deployment.   Use a production WSGI server instead. * Debug mode: on * Running on http://127.0.0.1:5000/ (Press CTRL+C to quit) * Restarting with stat**** BUILDING by MainThread!Unable to set line 17 to input

The MainThread was initializing my object twice! How was that? Well, if you look at the documentation of Flask's run(), you'll see the following:

If the :attr:`debug` flag is set the server will automatically reload for code changes and show a debugger in case an exception happened.

So, it seems that Flask just relaunches the application or something like this. Not clear to me, to be honest. But well, if you just remove debug, you'll see something like:

root@05600e5:/app# python -m sensor.main**** BUILDING by MainThread! * Serving Flask app "FlaskWS" (lazy loading) * Environment: production   WARNING: This is a development server. Do not use it in a production deployment.   Use a production WSGI server instead. * Debug mode: off * Running on http://127.0.0.1:5000/ (Press CTRL+C to quit)

I hope this helps. Happy coding!


Locating the process libgpiod_pulsein and killing it resolved the issue.

In your terminal, search for the process ID:

pgrep libgpiod_pulsein

and

kill <PID> (found from above - you might have more than one running)


I was experiencing the exact same thing with the DHT11. In my situation I had to kill the process: libgpiod_pulsein.

Worked on the first try when on fresh boot, but then subsequent executions would fail. Changing the GPIO I was using and running the program had the same effect, worked the first time and subsequent attempts would fail with example:

Unable to set line 4 to input

Timed out waiting for PulseIn message

Timed out waiting for PulseIn message ...


BlockquoteIn my case, pgrep libgpiod_pulsein returned nothing. But changing pin to D18 solved the issue. Seems to me like something else is blocking GPIO4, but no idea what. – Slav Apr 4 at 18:03

thanks,with the pin 18 its ok

but it is strange:

The pin 4, only run it: (version deprecated of adafruit)> runing before:

sudo modprobe w1-gpio

sudo modprobe w1-therm

#!/usr/bin/pythonimport sysimport Adafruit_DHTwhile True:    humidity, temperature = Adafruit_DHT.read_retry(11, 4)    print 'Temp: {0:0.1f} C Humidity: {1:0.1f} %'.format(temperature, humidity)