DHT22 not ready without power

[mitra42]

I'm seeing a consistent issue with a DHT22 sensor

When I flash it, it resets and then reports Sensor Not Ready - and stays in that state

If I then power cycle it, it starts reporting correctly.

This is consistent behavior - i.e. every reprogram and every power cycle.

Note - Reseting with the Reset button is not sufficient, it needs an actual power cycle.

Any ideas ?

[RobTillaart]

I'm seeing a consistent issue with a DHT22 sensor When I flash it,

How do you flash an DHT22? I assume you don't flash the sensor but some board.
Which board?
Which pins are used for flashing?
Which pins connect to the DHT22?

Any ideas ?

Hypothesis I - power

The DHT22 has 3V3 power line (assumption) which is just too low.

Measure with a DMM and/or put the power to 5V.

Hypothesis II - pull up resistors

• missing or too large
• too small

Very unlikely as one would expect it would affect more than just the first reading.

Hypothesis III - unwanted pulses on the line

The DHT22 gets one or more pulses during the flashing of the board.
As a consequence it starts its handshake.
As the board does not respond the sensor gets stuck somewhere in the protocol.
Note that in the protocol the sensor switches from waiting for input to generating output.

Have a logic analyzer on the DHT22 data line to see if there are pulses during startup.

[mitra42]

Thanks for the detailed reply:

How do you flash an DHT22? I assume you don't flash the sensor but some board.
Which board?
Lolin D1 Mini - ESP8266, but I get exactly the same result flashing a Lolin C3 Pico with a ESP32

Board is https://www.aliexpress.com/item/1005006223885039.html? which appears to be following the standard DHT design.

Which pins are used for flashing?
Via the USB in both cases, and note these cards are designed for those boards, so not using the USB pins etc. - See https://lastminuteengineers.com/wemos-d1-mini-pinout-reference/ Scroll down to `Which GPIOs are safe to use D4 has to be pulled high at boot - which it is by the DHT22 card.

Which pins connect to the DHT22? - D4 for data 3.3V and Gnd - I'll check this, but this appears to be the 'standard' design. i.e. https://oshwlab.com/adrirobot/dht-shield-for-wemos-d1-mini

Hypothesis I - power
**The DHT22 has 3V3 power line (assumption) which is just too low.
Measure with a DMM and/or put the power to 5V.

Will do the measurement but can't really be editing boards - to cut power lines.

• but note this is the off-the-shelf D1 mini card - standard pin layout, i.e. presumably same layout other people D1 DHT22's should have.

Hypothesis II - pull up resistors
missing or too large
too small
*Very unlikely as one would expect it would affect more than just the first reading. **

My thinking as well - this is more likely something to do with timing.

Hypothesis III - unwanted pulses on the line
The DHT22 gets one or more pulses during the flashing of the board.
As a consequence it starts its handshake.
** As the board does not respond the sensor gets stuck somewhere in the protocol. **
** Note that in the protocol the sensor switches from waiting for input to generating output. **

Possible - though not sure how it gets those pulses. On D1 and D2

Have a logic analyzer on the DHT22 data line to see if there are pulses during startup.

I don't have a logic analyzer unfortunately.

My guess was that its a timing thing - that after programming its coming up quicker than with a physical reset or power cycle, and maybe the library is starting the process when the SHT22 is in the wrong state. but that doesnt quite make sense since by the time it does the first read on the SHT22 is after its connected to WiFi.

Given the cycle - at the end of the read process the physical device should be in the right space for whatever you are doing during the first read after re-flash? Unless you do something different the first time on the presumption the board has just been powered up.

[RobTillaart]

Possible - though not sure how it gets those pulses. On D1 and D2

electric fields, induction, just the power on sequence can give a glitch on pins before they stabilize.

and maybe the library is starting the process when the SHT22 is in the wrong state

You have to wait 2 seconds before the first measurement of the DHT22 But I have connected and disconnected runtime and the library always picked up the sensor, sometimes one faulty read, sometimes without.

Given the cycle - at the end of the read process the physical device should be in the right space for whatever you are doing during the first read after re-flash?

If I understand your question correctly, yes, after a successful read the device should be ready for the next read just like after a power on start (after the 2 seconds mentioned before) .

At the moment no clue what is causing this.

[mitra42]

The only thing that I can currently think of is that the pulling of D4 high during boot, which https://lastminuteengineers.com/wemos-d1-mini-pinout-reference/ refers to is putting the DHT22 into a strange state ?

Or that the process of flashing is leaving the pin in a strange state - e.g. with a pullup, or output when it should be input or something like that, and the library code is presuming its in a default state.

[RobTillaart]

Normally one would have a pull up of 2k2-4k7 or so on the data pin (== D4) so I would not expect problems from the sensor.

[mitra42]

There's a 10K on it.

[mitra42]

Ok - so some more info -

After a power-cycle or flash D4 is ~3.2V, presumably because of the 10K pullup.

Two scenarios:
After power cycle - D4 starts at ~3.2V
First read is OK but leaves D4 at 0V
Second read fails "Sensor not Ready" and leaves D4 at ~3.2V
Third and subsequent reads Sensor not Ready

After flash - D4 starts at ~3.2V
First read Sensor not Ready - and leaves D4 at 0V
Second read fails "Sensor not Ready" and leaves D4 at ~3.2V
Third and subsequent reads Sensor not Ready

Let me capture some debugging info

[mitra42]

Here's the first run - after the flash its reporting each time _type is set, and the first number is the Line number in the code after the println's are added.

13:10:39.443 -> 51 _type = 0
13:10:39.443 -> Subscribing to: dev/lotus/esp8266-85ea2b/ledbuiltin
13:10:39.639 -> FrugalIoT Starting Loop
13:10:39.639 -> DHT on 2   143 _type = 22
13:10:39.639 -> 166 _type = 11
13:10:39.705 -> 177 _type = 70
13:10:39.705 -> 187 _type = 0
13:10:39.705 -> Sensor not ready,	
13:10:39.705 -> MQTT publish dev/lotus - esp8266-85ea2b
13:10:39.869 -> MQTT incoming: dev/lotus/esp8266-85ea2b/ledbuiltin - 1.0
13:10:49.676 -> DHT on 2   143 _type = 22
13:10:49.676 -> 166 _type = 11
13:10:49.742 -> 177 _type = 70
13:10:49.742 -> 187 _type = 0
13:10:49.742 -> Sensor not ready,	
13:10:59.743 -> DHT on 2   143 _type = 22
13:10:59.743 -> 166 _type = 11
13:10:59.776 -> 177 _type = 70
13:10:59.776 -> 187 _type = 0
13:10:59.776 -> Sensor not ready,	

[mitra42]

And after power cycle

13:13:20.220 -> 51 _type = 0
13:13:20.220 -> Subscribing to: dev/lotus/esp8266-85ea2b/ledbuiltin
13:13:20.385 -> FrugalIoT Starting Loop
13:13:20.385 -> DHT on 2   143 _type = 22
13:13:20.385 -> OK,	35.8°C	63.7%
13:13:20.385 -> MQTT publish dev/lotus/esp8266-85ea2b/temperature - 35.8
13:13:20.385 -> MQTT publish dev/lotus/esp8266-85ea2b/humidity - 63.7
13:13:20.385 -> MQTT publish dev/lotus - esp8266-85ea2b
13:13:20.582 -> MQTT incoming: dev/lotus/esp8266-85ea2b/ledbuiltin - 1.0
13:13:30.385 -> DHT on 2   Sensor not ready,	
13:13:40.391 -> DHT on 2   OK,	35.8°C	63.5%
13:13:40.391 -> MQTT publish dev/lotus/esp8266-85ea2b/humidity - 63.5
13:13:50.406 -> MQTT publish dev/lotus - esp8266-85ea2b
13:13:50.406 -> DHT on 2   OK,	35.8°C	61.8%
13:13:50.406 -> MQTT publish dev/lotus/esp8266-85ea2b/humidity - 61.8
13:14:00.413 -> DHT on 2   OK,	35.7°C	61.5%

[mitra42]

Problem seems to be that on the flashed run - between line 143 where it correctly sets the type to 22, and line 166 where it sets it back to 11.

  _type = 22;
    Serial.print(__LINE__); Serial.print(" _type = "); Serial.println(_type); #143
  _wakeupDelay = DHTLIB_DHT_WAKEUP;
  int rv = _read();
  if (rv == DHTLIB_OK)
  {
    //  see issue #102, #104
    //  test high humidity bits to check for KY015/ DHT11 encoding
    //  in DHT22 encoding humidity cannot be over 100.0 % == 0x03E8
    //  so the high bits cannot be over 0x03
    //  test can incorrectly fail if there is an extreme low humidity
    //  note desert air still has about ~20% RH
    if (_bits[0] <= 0x03)
    {
      return rv;
    }
    //  KY015 as DHT11
    _type = 11;
      Serial.print(__LINE__); Serial.print(" _type = "); Serial.println(_type); #166

[mitra42]

That error from read() is DHTLIB_ERROR_SENSOR_NOT_READY which only comes from the sensor not going low around line 423, I tried changing the WAITFORSENSOR time and it didn't fix it. Also tried lengthening DHTLIB_DHT_WAKEUP and that also didn't work.

I also tried using setType(22) and get same issues - the _readSensor comes back with DHTLIB_ERROR_SENSOR_NOT_READY, again failing after a flash but succeeding after a power-cycle.

[mitra42]

And one confirmation - if I go back to DHT11 (same shield manufacturer I think - I bought from different AliExpress store, but looks like identical board layout & printing.) then it comes up correctly and doesn't have this problem.

[RobTillaart]

Two scenarios:
After power cycle - D4 starts at ~3.2V
First read is OK but leaves D4 at 0V
Second read fails "Sensor not Ready" and leaves D4 at ~3.2V
Third and subsequent reads Sensor not Ready

After flash - D4 starts at ~3.2V
First read Sensor not Ready - and leaves D4 at 0V
Second read fails "Sensor not Ready" and leaves D4 at ~3.2V
Third and subsequent reads Sensor not Ready

So it effectively always give "Sensor not ready" except once after power cycle.

D4 = 3.2V

What is the voltage the sensor gets?
Datasheet states 3-5.5V but in practice it prefers 5V

[RobTillaart]

Problem seems to be that on the flashed run - between line 143 where it correctly sets the type to 22, and line 166 where it sets it back to 11.

Line 143 is the first guess.
Type 22 has a short wake up time (~1 ms) so that is tried first.
If that fails it assumes it must be a type 11 which has a long wakeup time (~18 ms)
Recently changed the logic slightly to get that KY015 board detected.
The latter analyzes part of the bit patterns it fetched.

[RobTillaart]

And one confirmation - if I go back to DHT11 (same shield manufacturer I think - I bought from different AliExpress store, but looks like identical board layout & printing.) then it comes up correctly and doesn't have this problem.

So it could be just a different (good/bad) batch of sensors?

[RobTillaart]

First read Sensor not Ready - and leaves D4 at 0V

The pull up should pull it to 3.2V,
Has the board bad soldering near the pull up?

[mitra42]

Sorry - big mistake above - I was trying lots of things and keeping notes that changed as I learned more. On power cycle it only gives one Sensor Not Ready, the 2nd read (corrected below)

The sensor is connected to 3.3V (all the DHT and SHT shields I found ran at 3.3V)

I don't think its a good/bad batch of sensors, though I can't prove it, as the only difference for DHT22 is on flash vs power-cycle. While DHT11 works fine on both flash and power-cycle

The board soldering is fine - the powerup is on a machine made board, and I've checked it - its ONLY 0V on the 2nd read (in either power cycle or flash scenario) I think its something in your sequence but I've gone thru the code line by line (with copious print statements) and can't find anything odd.

    Two scenarios:
    After power cycle - D4 starts at ~3.2V
    First read is OK but leaves D4 at 0V
    Second read fails "Sensor not Ready" and leaves D4 at ~3.2V
    Third and subsequent reads OK

    After flash - D4 starts at ~3.2V
    First read Sensor not Ready - and leaves D4 at 0V
    Second read fails "Sensor not Ready" and leaves D4 at ~3.2V
    Third and subsequent reads Sensor not Ready

[RobTillaart]

So your measured voltage at start does not make a difference.

No ideas how to proceed

[mitra42]

Correct, the voltage pattern seems to be the same in both cases, and understand there may be no obvious route forward to debug this.

I do notice that the first read leaves it driven to 0V which might not be a good thing, but doesn't appear to be causing this problem. And I've tried various things prior to the first read - like a digitalWrite Low or High to that pin, with no change to behavior.

I've switched back to DHT11's for now - its unfortunate cos I'm heading out to do the pilot trials in a week, was originally going to use SHT30's but they had an overheating problem with the enclosure I was using (reading too hot, and too dry), probably due to vicinity to main board and not enough air-flow, so I'd bought a bunch of DHT22's because they are external to the box - don't have time to source DHT11 shields before traveling.