esphome / issues

Issue Tracker for ESPHome
https://esphome.io/
290 stars 34 forks source link

DHT22 can't read values after software/button restart - works perfect when connecting power again #239

Closed Coren4 closed 4 years ago

Coren4 commented 5 years ago

Operating environment/Installation (Hass.io/Docker/pip/etc.):

Hass.io on Ubuntu 18.x in Docker

ESP (ESP32/ESP8266, Board/Sonoff):

NodeMcu v3 LoLin Affected component:

https://esphome.io/components/sensor/dht.html DHT22

Description of problem: When I'm connecting power wire to my NodeMcu everything works perfect. But when I will restart device with onboard button, or while uploading new firmware, it doesn't works and in logs I get: [20:52:22][E][sensor.dht:197]: DHT reports invalid data. Is the update interval too high or the sensor damaged? [20:52:22][W][sensor.dht:076]: Invalid readings! Please check your wiring (pull-up resistor, pin number).

I have step-up resistor 4k7 Ohm, I tried all available Dx pins, and I found similar issue -> https://github.com/micropython/micropython/issues/2651 -they suggest waiting little bit with reading after boot

Problem-relevant YAML-configuration entries:

PASTE YAML FILE HERE
esphome:
  name: esp_home_node_01
  platform: ESP8266
  board: nodemcuv2

wifi:
  ssid: "ssid"
  password: "pass"

# Enable logging
logger:

# Enable Home Assistant API
api:

ota:

sensor:
  - platform: dht
    pin: D1
    temperature:
      name: "Salon - Tempertura"
    humidity:
      name: "Salon - Wilgotnosc"
    update_interval: 30s

binary_sensor:
  - platform: gpio
    pin: D0
    name: "Salon - Ruch"
    device_class: motion

Traceback (if applicable):

Additional information and things you've tried:

I have step-up resistor 4k7 Ohm, I tried all available Dx pins, and I found similar issue -> https://github.com/micropython/micropython/issues/2651 -they suggest waiting little bit with reading after boot

OttoWinter commented 5 years ago

That would only explain why a first reading is failing. If that were the reason, starting with the 2nd measurement everything would be working fine.

Please double check your wiring. The DHTs are pretty timing-sensitive, even small things like wires with too high capacitance or just a flakey connections will lead to this error.

genlink commented 5 years ago

I have the same issues with Sonoff T1 US 3 gang. It could not read values after restart by button or software. I have to disconnect power and reconnect again then it works well

mario-tux commented 5 years ago

The same for me with a DHT22 on Sonoff Basic (R2) on GPIO01 (with software pull-up but also with an external resistor). The readings (even the first) works on a fresh power-on. It doesn't at all on software reset or upon an OTA flashing. I disabled the serial logging as GPIO01 would be involved.

genlink commented 5 years ago

I have the same issues with Sonoff T1 US 3 gang. It could not read values after restart by button or software. I have to disconnect power and reconnect again then it works well

I never had problem with Tasmota before

mario-tux commented 5 years ago

I would add some details on my case (Sonoff Basic R2) so they could help to debug the problem. I'm connecting the DHT output pin to the GPIO01 (the TX pin). It works (on each reading) after a cold boot. As reported by others, the sensor reading fails (forever) after a soft-reboot or OTA flash.

Other information: the same DHT sensor doesn't work at all if connected on the GPIO03 (the RX pin) of the Sonoff Basic. It could depends on the momentary pull-up of such GPIO during the boot.

It could be useful to know the specific GPIO used in the other cases with similar devices. Finally it is interesting to raise that the devices look to work with Tasmota (never tried in my case).

sensor:
  - platform: dht
    pin:
      number: GPIO01
      mode: INPUT_PULLUP
    temperature:
      id: kitchen_temperature
    humidity:
      id: kitchen_humidity
      filters:
        - offset: -10.10
    update_interval: 60s
    model: DHT22
qistoph commented 4 years ago

I'm having similar issues with my DHT22 on a Wemos D1 mini. I have a pull-up resistor of 3.2kOhm.

Model        | After       | Reading
------------------------------------
Auto (DHT22) | Upload      | nan
Auto (DHT22) | Reset       | nan
Auto (DHT22) | Deep sleep  | nan
Auto (DHT22) | Power cycle | nan
DHT11        | Upload      | nan
DHT11        | Reset       | nan
DHT11        | Deep sleep  | nan
DHT11        | Power cycle | nan
DHT22        | Upload      | 21.9°C/54%
DHT22        | Reset       | nan
DHT22        | Deep sleep  | nan
DHT22        | Power cycle | nan

I tried the patch from #926. Since only explicitly configuring model: DHT22 got me any result, I've retested with that setting. This didn't fix the issue unfortunately:

Model        | After       | Reading
------------------------------------
DHT22        | Upload      | 20.7°C/57%
DHT22        | Reset       | nan
DHT22        | Deep sleep  | nan
DHT22        | Power cycle | nan

I haven't had any issues reading this DHT22 with the same hardware, when using the Arduino core with the Adafruit DHT22 library for a few months.

Edit: relevant config

deep_sleep:
  id : deep_sleep_1
  run_duration: 10s
  sleep_duration: 1min

sensor:
  - platform: dht
    model: DHT22
    pin: GPIO0
    update_interval: 10min
    temperature:
      name: "Bedroom Temperature"
      retain: false
    humidity:
      name: "Bedroom Humidity"
      retain: false

Edit2: Apparently GPIO0/D3 is flipping states during boot. My assumption is it has to do with the special purpose of GPIO0. Still don't understand why this wasn't an issue before. However, changing my schematic to use GPIO4/D2 has solved the issue for me.

Some details on that behavior I've just found: https://bbs.espressif.com/viewtopic.php?t=2101

xsnoopy commented 4 years ago

I had a problem with DHT 22 and ESPhome too. I finally got it work with the Custom Component.

See attached file for the config folder of your epshome.

my_custom_sensor .h.txt

YML.txt

LukeHandle commented 4 years ago

@qistoph thanks! I tried the DHT22_TYPE2 but it didn't resolve using D4/GPIO2. Per that link, it seems we should avoid GPIO0, GPIO2 and GPIO15 for their special boot properties (possible "common" knowledge). Using D7/GPIO13 worked for me.