-
-
Notifications
You must be signed in to change notification settings - Fork 15
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
"Sensor not ready," meaning #31
Comments
Hi,
|
Hi, thanks for the quick reply.
|
I'm quite busy this week and will try to recreate your problem. |
Did some testing with an DHT22 + UNO and got same problem. 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 - |
Testing with UNO and DHT22 works well, 15500+ reads zero fails.
ESP32 with DHT22 runs now 8500+ reads with zero fails
Will start with DHT11 a.s.a.p. |
ESP32 + DHT22
UNO + DHT11
Looks pretty stable now, will publish a new release today Problems identified
|
fix #31 DHT11 on AVR + refactor more strict timing
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 constructor Of course this only works when the DHT sensor is powered by a digital pin and not by VCC directly. 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)
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: I have not yet tested any other libraries. Will do that next. |
@DaleSchultz Things you should check
|
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 |
dhtint_pulse_diag.ino crashes with, and without, a 2k resistor and, with, and without, noInterrupts();
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....
|
@DaleSchultz
Very strange as it has only basic operaters like digitalWrite/Read and pinMode. analysis crash dhtint_pulse_diag.inoRuns at least to the line - As a software watchdog kicks in It looks like it got stuck in one of the
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. |
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 ?
The text was updated successfully, but these errors were encountered: