AM2302 sensor trouble

[AlbertWeterings]

I am struggling with a AM2302 (DHT22) sensor on a ESP01. The data line is connected to IO2 the firmware is correct.

This sensor has a internal pull up of 4k7. And gets 3v3 supply.
In the first setup I was having a additional pull up of 10k connected and the device was working but after a few days I got timeout in the measurements. Debug gives me error no 3
In the second setup I removed the 10k pull up resistor. At that point the device is working for days now without loosing the sensor readings. But this time a new symptom appears, when I disconnect power and power up again there is a sensor timeout debug gives error 3. If then I just disconnect the and reconnect the sensor it starts working again.

Does anyone have seen these symptoms before? And do you know a solution?

[AlbertWeterings]

The problem is also on SonOff TH. after a few day's the AM2302 is not reading values anymore. I dismantled the TH device and found there are two resistors 10K from 3v3 to IO14 additional the AM2302 has a internal resistor of 4k7 resulting in a total pullup of 2k4. Also the input IO pin has pullup enabled by firmware. I thought this is to less so removed 1 of the 10K resistors from the TH device but still the same problem. Only difference is that at power up the sensor is detected and working.

still I have no clue what is going on. only thing I could find is that min voltage of the AM2302 sensor is 3v3 and typical operating voltage is 5v so maybe with a 3v3 supply that is the issue... Lets add a regulator and try that.

[AlbertWeterings]

An update why this sensor is not working from boot on ESP-01 GPOI-2
The problem with this setup is that on GPOI-2 during boot some pulses come by that put the sensor into a mode that it will not respond anymore. I experimented for a log time and was not able to reset or bring the sensor into a working state without having to remove the supply from the sensor.

A good solution to have the AM2302 working on the ESP-01 is connecting it to GPIO-3 and disable serial debugging. There is no pullup resistor needed on the data line the pullup inside the sensor is doing it's work.

[AlbertWeterings]

And again a update. Today I hooked 5 AM2302 sensors to 5 different sonoff TH devices and started to monitor them for sensor timeouts. Did not have to wait long and the first device started to spit out errors. As I was already experimenting with timing settings in ESPURNA I found the problem was not there to be found so I connected my oscilloscope to the data line of the sensor and again not found anything odd other than at some times the data line fliped low after the start signal from the ESP for 60us and then went high for over 1500us causing the timeout.

Then I moved to check for any noise on the power supply... It's not the nicest 3v3 I have seen when the sonoff TH is getting power from the net, so I connected it to a stable supply and checked if it helps getting rid of the sensor time-outs. And also that action was unsuccessful.

Reading in the hardware.h file I note it is very simple to bring IO-4 outside the sonoff TH so I thought well let's see what happens when I connect this sensor to this IO-pin. I did on the first failing device from the day and it is now already running for more than 10 hours without having a single timeout error in the logging.

So my next step is doing the same modification on the other 4 test devices and see if they are giving me the same result. If so it is time to mod also my already installed sonoff TH units.

I found the reason for this sensor not working on a ESP-01 GPIO-2 but why it is not working GPIO-14 is not clear to me. Does anyone know? And why is GPIO-14 on the jack as IO port while looks like it is not a stable port?

[AlbertWeterings]

@xoseperez a question I connected at a few of my devices the am2302 to io-4 now and with the original file DHTSensor also on IO-4 is see timeout failures coursed by going over the limit of 100 stated in line 170. I changed this now to 1000 and until now no errors appear. This 1000 value I found in the old adafruit DHTSensor library. Very resend adafruit has changed their library, they added for ESP8266 yield() before and direct after InterruptLock and even more recent they removed yield() again.

So what is yield() doing? What is the real time limit if in line 170 we send 100 in the function _signal? And why for dht-22 (am2302) do we pull the io line low for 500us in line? It looks like it works but I can't find this value anywhere.

[xoseperez]

Hi @AlbertWeterings,
back to your first post: maybe adding a reset pulse will help. According to some sources a 20ms low pulse will reset the sensor, so try adding this lines at the end of the begin method in the sensor class and test it:

digitalWrite(_gpio, LOW);
nice_delay(20);
digitalWrite(_gpio, HIGH);

[AlbertWeterings]

@xoseperez I'm still experimenting with a bunch of AM2302 sensors. At the moment I have good results with a BS170 (fet) in the negative supply line. The gate of this fet is connected to GPIO14 data of the sensor is at GPIO4.

I changed the routine "if (++_errors > DHT_MAX_ERRORS)" in a way it pulls the gate of the fet LOW for a second then brings it up again wait's a second and start reading again. (did this the dirty way as I could not properly assign GPIO14 as power pin for this purpose in hardware.h)

At the moment this bunch of sensors is running over 2 day's and only 1 has showed errors going over the DHT_MAX_ERRORS limit. After the routine has power cycled the sensor it was running again for hours. In total I have seen this happening twice.

The strange part of the story is the DHT_MAX_ERRORS routine is not called on one of the other sensors so they stay working now due to the FET in the negative supply line. I would not be surprised if just place a signal diode (1n4148) in the negative supply line this has the same result. So that is what I want to test during the weekend on a few sensors. I will also test your proposed solution but therefore I have to go back to the original hardware setup that gave me uncountable errors.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed in 7 days if no further activity occurs. Thank you for your contributions.

[stale]

This issue will be auto-closed because there hasn't been any activity for two months. Feel free to open a new one if you still experience this problem.