"Sensor not ready," meaning
Opened this issue · 24 comments
Hi, I've been trying to get readings from a DHT11 sensor using the DHTNew library and am consistently running into a problem.
When trying the sketch dhtnew_test, the 0.2.0 version returns "Timeout_error", and the version 0.3.3 returns "Sensor not ready," from what I understood this means the sensor does not return fast enough for the code to get readings. I've used a 5.1k Ohms pull-up resistor (as the datasheet recommends), as the cables are less than 20 meters long (just a few cm long in fact). I've tried using both an analog and digital pin, the results are the same. The sensor is lit red though, so I assume it is correctly powered and grounded.
I don't know what may be going wrong or how to interpret this returned error, should I try to modify the code or is the problem coming from the connections ?
Hi,
A few questions pop up:
- which platform are you using? UNO / ESP etc? Some DHT sensors have trouble with 3.3 volt.
- are there other devices connected?
- have you tried upgrading to the latest version 0.3.3 ?
- have you tried another lib to see if the sensor is OK e.g. one from Adafruit?
Hi, thanks for the quick reply.
Here are the details:
- Platform : UNO
- An LCD 16x2 screen is also connected
- I did, the dhtnew_test sketch returns "Sensor not ready,"
- The DHT library from Adafruit returns expected sensor values
I'm quite busy this week and will try to recreate your problem.
How is the lcd connected? I2C or parallel?
Did some testing with an DHT22 + UNO and got same problem.
Last issues were timing related on ESP32 so it seems I did too few regression tests.
Can you comment line 212 noInterrupts(); in dhtnew.cpp and give it a try?
int DHTNEW::_readSensor()
....
// DISABLE INTERRUPTS when clock in the bits
// noInterrupts(); When I commented that line it worked better - dhtnew_endless.ino sketch -
However too much errors still on UNO so I need to check the timing constraints on those errors.
Testing with UNO and DHT22 works well, 15500+ reads zero fails.
TIM CNT STAT HUMI TEMP TIME TYPE
15606676 15540 OK, 41.5, 23.6, 4, 22
15607677 15541 OK, 41.5, 23.6, 5272, 22
15608684 15542 OK, 41.5, 23.6, 12, 22
15609686 15543 OK, 41.5, 23.6, 5264, 22
15610693 15544 OK, 41.5, 23.6, 8, 22
15611695 15545 OK, 41.5, 23.6, 5268, 22
15612701 15546 OK, 41.5, 23.6, 8, 22
15613703 15547 OK, 41.6, 23.6, 5120, 22
15614710 15548 OK, 41.6, 23.6, 4, 22
15615712 15549 OK, 41.8, 23.6, 5228, 22
OK CRC TOA TOB TOC TOD SNR BS UNK
15549 0 0 0 0 0 0 0 0
ESP32 with DHT22 runs now 8500+ reads with zero fails
TIM CNT STAT HUMI TEMP TIME TYPE
8710925 8690 OK, 40.9, 24.1, 2, 22
8711925 8691 OK, 41.0, 24.1, 5002, 22
8712930 8692 OK, 41.0, 24.1, 2, 22
8713930 8693 OK, 41.0, 24.1, 4996, 22
8714935 8694 OK, 41.0, 24.1, 2, 22
8715935 8695 OK, 41.0, 24.1, 5004, 22
8716940 8696 OK, 41.0, 24.1, 2, 22
8717940 8697 OK, 41.1, 24.1, 5100, 22
8718945 8698 OK, 41.1, 24.1, 2, 22
8719945 8699 OK, 41.2, 24.1, 5049, 22
OK CRC TOA TOB TOC TOD SNR BS UNK
8699 0 0 0 0 0 0 0 0
Will start with DHT11 a.s.a.p.
DHT11
Measured the timing of a DFrobotics DHT11 and the reaction time after the wake up delay is way beyond specification. I got times between 6000-10000 us instead of the 20-40 us mentioned above.
I patched the lib and started a test that will run for a few hours to see if other problems occur.
ESP32 + DHT22
TIM CNT STAT HUMI TEMP TIME TYPE
65448152 65290 OK, 54.2, 20.6, 2, 22
65449152 65291 OK, 54.2, 20.6, 2, 22
65450152 65292 OK, 54.2, 20.6, 5150, 22
65451157 65293 OK, 54.2, 20.6, 2, 22
65452157 65294 OK, 54.2, 20.6, 2, 22
65453157 65295 OK, 54.2, 20.7, 5249, 22
65454162 65296 OK, 54.2, 20.7, 2, 22
65455162 65297 OK, 54.2, 20.7, 2, 22
65456162 65298 OK, 54.3, 20.7, 5151, 22
65457167 65299 OK, 54.3, 20.7, 2, 22
OK CRC TOA TOB TOC TOD SNR BS UNK
65299 0 0 0 0 0 0 0 0
UNO + DHT11
TIM CNT STAT HUMI TEMP TIME TYPE
53681651 53290 OK, 36.0, 22.0, 4, 11
53682653 53291 OK, 36.0, 22.0, 11700, 11
53683666 53292 OK, 36.0, 22.0, 4, 11
53684668 53293 OK, 36.0, 22.0, 10604, 11
53685680 53294 OK, 36.0, 22.0, 8, 11
53686681 53295 OK, 36.0, 22.0, 11696, 11
53687695 53296 OK, 36.0, 22.0, 4, 11
53688696 53297 OK, 36.0, 22.0, 10660, 11
53689709 53298 OK, 36.0, 22.0, 16, 11
53690711 53299 OK, 36.0, 22.0, 10704, 11
OK CRC TOA TOB TOC TOD SNR BS UNK
53299 0 0 0 0 0 0 0 0
Looks pretty stable now, will publish a new release today
Problems identified
- noInterrupts blocked too long on AVR to keep timing of micros() correctly.
- DHT11 does not behave according to the datasheet, it wait way longer before waking up.
- A problem with wakeupDelay, in case type was not detected and setType was used.
In case you're seeing this on an ESP8266:
Tried this library on an ESP-01 (=ESP8266), also received 'Sensor not ready' every now and then. First thought it was due to timing issues. Swapped out with another DHT-22, same issue. Then tried another DHT library that claims to be optimized for ESPs, same error. It only worked after disconnecting the VCC from the sensor, rebooting the ESP and then connect the VCC.
After a search it turns out that GPIO0, GPIO2 and GPIO15 from the ESP8266 do something special during boot time which seems to confuse the DHT sensor.
Changed pin to GPIO3 and haven't seen the issue anymore.
Would be nice if the DHT it has such a feature. Haven't seen anyone suggesting that though in the threads that I've seen. Here is another one from the Tasmota project, also suggesting to avoid those aforementioned GPIO pins.
Currently the DHTNEW lib has powerUp() powerDown() which effectively only set the datapin to LOW to reduce some (minimal) power consumption. It is possible to extend this in the following way
void DHTNEW::setVCCpin(uint8_t pin)
{
_vccPin = pin;
};
int DHTNEW::getVCCpin() // convenience
{
return _vccPin;
};
void DHTNEW::powerUp()
{
_power = true;
if (_vccPin >= 0) digitalWrite(_vccPin, HIGH);
digitalWrite(_dataPin, HIGH);
// do a dummy read to sync the sensor
read();
};
void DHTNEW::powerDown()
{
_power = false;
if (_vccPin >= 0) digitalWrite(_vccPin, LOW);
digitalWrite(_dataPin, LOW);
}
bool DHTNEW::isPowerUp()
{
return _power == true;
}
+ some initialization in constructorOf course this only works when the DHT sensor is powered by a digital pin and not by VCC directly.
I do not know how much current it draws from my head and I think powering directly from IO pin is
not recommended.
Opinion?
First of all, it seems that the DHTs draw around 2.5mA current and ESP8266 can provide max 12mA on the pin so in theory it' is possible. But it is not recommended. Instead, use eg a transistor to control the power through a pin.
Secondly, the power on/off functionality isn't part of the DHT sensor. It's more a generic switch functionality so I don't think it should be part of your library. Would otherwise make things more confusing.
So my opinion: ppl should just avoid those GPIO pins. If there's no other option they can use the Arduino switch library to control the DHTs power.
OK, I can add some notes in the readme.md file
update: added note in master. no new release made.
Great, thanks a lot!
I am getting only Sensor Not Ready on ESP8266 (NodeMCU) and DHT11
With VCC connected to 3V3 pin, data to D1 (GPIO 5)
22:04:21.069 -> TIM CNT STAT HUMI TEMP TIME TYPE
22:04:21.069 -> 233536 220 SNR, -999.0, -999.0, 36168, 0
22:04:22.170 -> 234608 221 SNR, -999.0, -999.0, 36126, 0
22:04:23.210 -> 235681 222 SNR, -999.0, -999.0, 36134, 0
22:04:24.280 -> 236754 223 SNR, -999.0, -999.0, 36117, 0
22:04:25.360 -> 237826 224 SNR, -999.0, -999.0, 36130, 0
22:04:26.429 -> 238899 225 SNR, -999.0, -999.0, 36148, 0
22:04:27.529 -> 239971 226 SNR, -999.0, -999.0, 36127, 0
22:04:28.569 -> 241044 227 SNR, -999.0, -999.0, 36036, 0
22:04:29.662 -> 242116 228 SNR, -999.0, -999.0, 36151, 0
22:04:30.723 -> 243189 229 SNR, -999.0, -999.0, 36128, 0
No change if I disconnect the data pin.
If I connect VCC to V5 (VIN) instead of 3V3, I get only DHTLIB_ERROR_TIMEOUT_A instead of SNR.
I get the same results with two different DHT11 modules.
I have tried pins:
D1 GPIO 5
D9 GPIO 3
D6 GPIO 12
I have not yet tested any other libraries. Will do that next.
@DaleSchultz
Thanks for reporting the issue. It is better to create a new issue instead of reopening one that is this old.
Things you should check
- the power supply, 3V3 is at the edge of what works according the datasheet. Better is to power the sensor with 5V.
You should measure it with a DMM - a pullup resistor, typical 4K7 and depending on length of the wires you might need to use a smaller one.
For 3V3 you might also need to use a smaller one. 3K3 or even 2K2
You might also start with short wires. - if you have a scope or a logic analyzer you can check if there is communication on the data line.
You can make a simple line sniffer with an Arduino. - if you have a scope you can even check the quality of the wave form.
- you might need to check the datasheet of the 8266 which pins are bidirectional. Some might be input only.
- you can run the dhtnew_pulse_diag.ino example. to see the timing of the sensor.
(you need to adjust the wakeup time in the code for the DHT11)
thanks, does the pullup go on the data line? The ESP8266 has built-in pullups, but perhaps the code is not telling it to use the pullup.
I am using short wires (on a breadboard), pins are bidirectional.
I don't have a scope.
I'll try the diagnostic sketch.
many thanks.
Internal pullups are much larger e.g. 50 K
The pullup should indeed between data an 3V3
dhtint_pulse_diag.ino crashes with, and without, a 2k resistor and, with, and without, noInterrupts();
18:21:09.862 -> dhtint_pulse_diag.ino
18:21:09.862 ->
18:21:09.862 -> awake
18:21:13.075 -> --------------- CUT HERE FOR EXCEPTION DECODER ---------------
18:21:13.075 ->
18:21:13.075 -> Soft WDT reset
18:21:13.075 ->
18:21:13.075 -> >>>stack>>>
18:21:13.075 ->
18:21:13.075 -> ctx: cont
18:21:13.075 -> sp: 3ffffdc0 end: 3fffffc0 offset: 01a0
18:21:13.075 -> 3fffff60: 402015d0 3ffee520 3ffee518 402012eb
18:21:13.075 -> 3fffff70: 402015d0 00000001 00000005 40100f30
18:21:13.122 -> 3fffff80: 3fffdad0 00000000 3ffee6d4 3ffee73c
18:21:13.122 -> 3fffff90: 3fffdad0 00000000 3ffee728 402014a1
18:21:13.122 -> 3fffffa0: feefeffe feefeffe 3ffee728 40201e50
18:21:13.122 -> 3fffffb0: feefeffe feefeffe 3ffe85dc 40100c11
18:21:13.122 -> <<<stack<<<
18:21:13.122 ->
18:21:13.122 -> --------------- CUT HERE FOR EXCEPTION DECODER ---------------
18:21:13.122 ->
18:21:13.122 -> ets Jan 8 2013,rst cause:2, boot mode:(3,6)
18:21:13.122 ->
18:21:13.122 -> load 0x4010f000, len 3460, room 16
18:21:13.169 -> tail 4
18:21:13.169 -> chksum 0xcc
18:21:13.169 -> load 0x3fff20b8, len 40, room 4
18:21:13.169 -> tail 4
18:21:13.169 -> chksum 0xc9
18:21:13.169 -> csum 0xc9
18:21:13.169 -> v00042460
18:21:13.169 -> ~ld
18:21:13.216 -> dhtint_pulse_diag.ino
18:21:13.216 ->
18:21:13.216 -> awake
18:21:16.413 -> --------------- CUT HERE FOR EXCEPTION DECODER ---------------
I have found that I am not getting a full 5V to the VCC pin so I am going to try a better supply next.
I tried a different library....
3V3 supply, no resistors using SimpleDHT
18:37:20.418 -> Sample OK: 28 *C, 55 H
18:37:21.926 -> =================================
18:37:21.926 -> Sample DHT11...
18:37:21.926 -> Sample OK: 28 *C, 55 H
18:37:23.432 -> =================================
18:37:23.432 -> Sample DHT11...
18:37:23.432 -> Sample OK: 28 *C, 54 H
18:37:24.938 -> =================================
18:37:24.938 -> Sample DHT11...
18:37:24.985 -> Sample OK: 28 *C, 54 H
@DaleSchultz
OK, does this working library solves your issue?
dhtint_pulse_diag.ino crashes with, and without, a 2k resistor and, with, and without, noInterrupts();
Very strange as it has only basic operaters like digitalWrite/Read and pinMode.
Should work on Arduino compatible platform but I have never tested it with a ESP8266 myself.
analysis crash dhtint_pulse_diag.ino
Runs at least to the line - Serial.print("awake ");
As a software watchdog kicks in It looks like it got stuck in one of the while (digitalRead(_dataPin) == HIGH); lines forever, meaning the sensor does not pull the line HIGH enough. Otherwise we would have seen Serial.print("2 ");
Possible causes
- datapin incorrect
- pull up incorrect
- wiring incorrect
- sensor failure
The latter seems unlikely as sensor works with another library. Other three cannot be eliminated as cause.
yes, something is timing out as it runs for more than 2 seconds after the "awake"
LOL, after 7 months I could get back to this project and forgot how far I was, so I started over. Found the same issues, tried all sorts of things, then googled "sensor not ready" with ESP8266 and found this thread... scrolled down to find my own posts about it!
Very recognizable, sort of deja vu experience.