Question about the dht module (and maybe some more)

Roberthh · Post by **Roberthh** » Sat Nov 30, 2019 4:17 pm

The data sheet (at least the one I have) shows an Pull-Up resistor of 1KOhm. That is good for longish wires. The internal pull-up of the ESP8266 has a value of at least 30kOhm. That is good for a desk test, but not sufficient for longer wires. So adding an external pull-up is recommended.

MostlyHarmless · Post by **MostlyHarmless** » Sat Nov 30, 2019 7:18 pm

To summarize, first commit 033c32e fixed a glitch in i2c by switching the pin to IN when OPEN_DRAIN+HIGH is requested, which apparently broke some use cases of DHT22s. Then commit 18d3a5d brought back the previous behavior of mp_hal_pin_od_high() as mp_hal_pin_od_high_dht().

Note that since commit 033c32e the esp8266 port's behavior of mp_hal_pin_od_high() is identical to pin_set() when in OPEN_DRAIN mode . Note also that the esp32 port behaves different right now as it really uses OPEN_DRAIN mode and just toggles the pin's output value without changing IN/OUT at all.

I think it would be bad to leave the two ports in incompatible default behavior. My proposal is to make the esp8266 port use mp_hal_pin_od_high() by default and add a flag that lets the user specify to use mp_hal_pin_od_high_dht() instead. Something like flags=ALT_HIGH. More flags can be added if we encounter more DHT22 flavors in the future.

Going to create a new branch with that implemented.

Regards, Jan

MostlyHarmless · Post by **MostlyHarmless** » Sat Nov 30, 2019 7:52 pm

Roberthh wrote: ↑
Sat Nov 30, 2019 4:17 pm
The data sheet (at least the one I have) shows an Pull-Up resistor of 1KOhm. That is good for longish wires. The internal pull-up of the ESP8266 has a value of at least 30kOhm. That is good for a desk test, but not sufficient for longer wires. So adding an external pull-up is recommended.

The one I am using had an on-board 5K1 pull-up, which I since removed for testing purposes. Works with or without it. These things really seem to be all over the map. Using two different boards and two different sensors one apparently gets 5 different behaviors.

Regards, Jan

MostlyHarmless · Post by **MostlyHarmless** » Sat Nov 30, 2019 9:32 pm

How about this?

https://github.com/wieck/micropython/tr ... stom-delay

MostlyHarmless · Post by **MostlyHarmless** » Sun Dec 01, 2019 7:27 pm

MostlyHarmless wrote: ↑
Sat Nov 30, 2019 9:32 pm
How about this?

https://github.com/wieck/micropython/tr ... stom-delay

Forget that.

I combined it all into one commit, added the necessary documentation changes and create a pull request.

https://github.com/micropython/micropyt ... 49f5ef85dd

Best Regards, Jan

random-builder · Post by **random-builder** » Sat Apr 02, 2022 12:05 am

Another solution for a similar problem (random timeout errors in DHT):
re-implement driver in viper for total control of DHT protocol parameters.
https://github.com/micropython/micropyt ... 1086420730

MicroPython Forum (Archive)

Question about the dht module (and maybe some more)

Re: Question about the dht module (and maybe some more)

Re: Question about the dht module (and maybe some more)

Re: Question about the dht module (and maybe some more)

Re: Question about the dht module (and maybe some more)

Re: Question about the dht module (and maybe some more)

Re: Question about the dht module (and maybe some more)