ESP32: need a module DHT21/22/AM2301

[LDmitryL]

Missing feature

Need the library to support reading the sensors of the type DHT21/22/AM2301

Justification

This is the most convenient and easy way to get humidity.
And most importantly low cost!
Which is very important for home automation.

Workarounds

API for module dht from ESP8266 good

---

Subset of API from ESP8266.

dht.read2x(pin)

Read a DHT21/22/AM2301 sensor at given pin.
Returns status, temp, humi, temp_dec, humi_dec with repsective support for float and integer build.

dht.read11(pin)

Read a DHT11 sensor at given pin.
Returns status, temp, humi, temp_dec, humi_dec with repsective support for float and integer build.

[devsaurus]

I'd propose to use the RMT peripheral to implement the low-level protocol for talking to this family of sensors. An RX channel can capture data bits from the sensor in read direction and decoding to '0' and '1' is done based on the duration between the signal edges. This worked very well for the ow protocol.

The start impulse in TX direction can be done with simple gpio writes, roughly timed by vTaskDelay().

[devsaurus]

Had a look at the existing dht module. API seems to be ok, although I don't plan to implement dht.readxx() since the detection of DHT11 vs. DHT21/22 etc. appears to be unreliable in my opinion.

[devsaurus]

There's a draft version available in my repo over at https://github.com/devsaurus/nodemcu-firmware/tree/dev-esp32-dht

I've tested it with an AM2302 sensor that happened to be in my stock. Checking against a DHT11 is still required before merge to upstream since this variant triggers substantially different paths in the code.

[LDmitryL]

@devsaurus
Noticed a compile error if you remove the option UART console auto baud detection in platform config in component config

CC user_main.o
C:/msys32/home/LDL/nodemcu-firmware/components/base_nodemcu/user_main.c: In function 'app_main':
C:/msys32/home/LDL/nodemcu-firmware/components/base_nodemcu/user_main.c:160:19: error: 'CONFIG_CONSOLE_BIT_RATE_AUTO' undeclared (first use in this function)
cfg.auto_baud = CONFIG_CONSOLE_BIT_RATE_AUTO;
^
C:/msys32/home/LDL/nodemcu-firmware/components/base_nodemcu/user_main.c:160:19: note: each undeclared identifier is reported only once for each function it appears in
make[1]: *** [/home/LDL/esp-idf/make/component_wrapper.mk:177: user_main.o] Error 1
make: *** [C:/msys32/home/LDL/esp-idf/make/project.mk:386: base_nodemcu-build] Error 2

[devsaurus]

Thanks for reporting @LDmitryL! I'll have a look.

[devsaurus]

Running the contained functions triggers an error message in the RMT driver code. I've reported this to Espressif and suggested a fix with espressif/esp-idf#492.

Furthermore, there appear to be interoperability issues between this module and the ow module: Executing dht.read*() kills the RMT channels of the onewire protocol implementation (see espressif/esp-idf#486). This will become even worse with the ws2812 module from #1896. I need to wait for Espressif's response until I can proceed.

@jmattsson:
What would be the best way to include the fix from espressif/esp-ifd#486 into our code base before they ran it through their development mill? Is it acceptable to temporarily reference the sdk/esp32-esp-idf submodule from my PR branch? Or can I place a .patch file somewhere in our repo which is applied before compilation starts?

[LDmitryL]

Yes, indeed there is a bug in the module DHT module in conjunction with the OW. Separately they work but together no.

[0;31mE (153312) rmt: RMT[5] ERR [0m
[0;31mE (153312) rmt: status: 0x14140180 [0m
[0;31mE (153312) rmt: rmt_set_tx_thr_intr_en(347): RMT EVT THRESH ERR [0m

the message after the call dht.read2x(port). After that just reset.

[devsaurus]

Noticed a compile error if you remove the option UART console auto baud detection in platform config in component config

Fixed in dev-esp32 branch.

[devsaurus]

Module merged into dev-esp32 branch.

[zelll]

I tried to build a release version, but got

...
CC dht.o
D:/tmp/msys32/home/0j/nodemcu-firmware/components/modules/dht.c: In function 'ldht_read_generic':
D:/tmp/msys32/home/0j/nodemcu-firmware/components/modules/dht.c:75:29: error: 'humi' may be used uninitialized in this function [-Werror=maybe-uninitialized]
   int humidec = (int)((humi - (int)humi) * 1000);
                             ^
D:/tmp/msys32/home/0j/nodemcu-firmware/components/modules/dht.c:74:29: error: 'temp' may be used uninitialized in this function [-Werror=maybe-uninitialized]
   int tempdec = (int)((temp - (int)temp) * 1000);
                             ^
cc1.exe: some warnings being treated as errors

BTW, I did not select dht module.
# CONFIG_LUA_MODULE_DHT is not set

[devsaurus]

I ran a build on dev-esp32 branch just the other day without issues.
This error happened for you on this branch as well?

[zelll]

I meant choosing build for release in menuconfig, not master branch for 8266...

[devsaurus]

I see.

The error was correct and I just pushed a fix for it. Strangely it's not reported for a debug build...

[LDmitryL]

@devsaurus Managed to overcome the problem with RMT?

[devsaurus]

Interoperability with onewire remains problematic since espressif/esp-idf#486 is still waiting for a resolution.

[LDmitryL]

@devsaurus I noticed that the problem with RMT was fixed. (message Yes, was fixed by #492, closing. in espressif/esp-idf#473 ). Which, in turn, referred to the problem with the ws2812 module. #1896
Does this mean that the problem is fixed and this module too?
Last update is not working with nodemcu module DHT21/22/AM2301 and OW at the same time. The system hangs without displaying any messages.

[devsaurus]

No, the root cause for that is espressif/esp-idf#486.
Hope that concrete fix with espressif/esp-idf#669 is considered now quickly.

[devsaurus]

I updated to latest esp-idf which contains a fix for espressif/esp-idf#486. Waiting for a response to espressif/esp-idf#719.

[LDmitryL]

@devsaurus This fix is already included?