DHT22 report null after a while

[Magnus-rosenborg]

### BUG DESCRIPTION Get null for both humidity and temperature on AM2302, DS18B20 works fine. Running on Wemos D1 R2, Tasmota 6.5.0(sensors) ### REQUESTED INFORMATION _Make sure these boxes are checked before submitting your issue. Thank you_ **FAILURE TO COMPLETE THE REQUESTED INFORMATION WILL RESULT IN YOUR ISSUE BEING CLOSED** - [X] Read the [Contributing Guide and Policy](https://github.com/arendst/Sonoff-Tasmota/blob/development/CONTRIBUTING.md) and [the Code of Conduct](https://github.com/arendst/Sonoff-Tasmota/blob/development/CODE_OF_CONDUCT.md) - [X] Searched the problem in issues (https://github.com/arendst/Sonoff-Tasmota/issues) - [X] Searched the problem in the wiki (https://github.com/arendst/Sonoff-Tasmota/wiki/Troubleshooting) - [X] Searched the problem in the forum (https://groups.google.com/d/forum/sonoffusers) - [X] Searched the problem in the chat (https://discord.gg/Ks2Kzd4) - [X] Device used (i.e. Sonoff Basic) : _Sensor works on sonoff Basic but not on Wemos ____ - [X] Tasmota binary firmware version number used : 6.5.0, self compiled____ / (pre-compiled or self-compiled ?) - [X] Development IDE - Compiler / Upload tools used :platformio ____ / http____ - [X] Provide the output of command ``status 0`` : ``` STATUS 0 OUTPUT HERE: 00:53:59 MQT: stat/80/STATUS = {"Status":{"Module":18,"FriendlyName":["Wemos","Wemos2","Wemos3","Wemos4"],"Topic":"80","ButtonTopic":"KNAPP80","Power":0,"PowerOnState":3,"LedState":1,"SaveData":1,"SaveState":1,"SwitchTopic":"SWITCH80","SwitchMode":[2,0,0,0,0,0,0,0],"ButtonRetain":1,"SwitchRetain":1,"SensorRetain":0,"PowerRetain":1}} 00:53:59 MQT: stat/80/STATUS1 = {"StatusPRM":{"Baudrate":115200,"GroupTopic":"sonoffs","OtaUrl":"http://insidan.us.to/sonoff/firmware80.bin","RestartReason":"Software/System restart","Uptime":"0T00:09:47","StartupUTC":"2019-04-10T22:44:12","Sleep":50,"CfgHolder":4617,"BootCount":64,"SaveCount":296,"SaveAddress":"F9000"}} 00:53:59 MQT: stat/80/STATUS2 = {"StatusFWR":{"Version":"6.5.0(sensors)","BuildDateTime":"2019-04-11T00:17:47","Boot":31,"Core":"2_3_0","SDK":"1.5.3(aec24ac9)"}} 00:53:59 MQT: stat/80/STATUS3 = {"StatusLOG":{"SerialLog":0,"WebLog":2,"SysLog":0,"LogHost":"","LogPort":514,"SSId":["lj3m",""],"TelePeriod":60,"Resolution":"558180C0","SetOption":["000080E9","280500000100000000000000000000000000","00000000"]}} 00:53:59 MQT: stat/80/STATUS4 = {"StatusMEM":{"ProgramSize":547,"Free":456,"Heap":15,"ProgramFlashSize":1024,"FlashSize":4096,"FlashChipId":"164020","FlashMode":3,"Features":["0000041D","0FDEE3B4","0001A004","B7FFBFCC","005ABBC0"]}} 00:53:59 MQT: stat/80/STATUS5 = {"StatusNET":{"Hostname":"80-5893","IPAddress":"192.168.200.220","Gateway":"192.168.200.254","Subnetmask":"255.255.255.0","DNSServer":"192.168.200.1","Mac":"60:01:94:56:D7:05","Webserver":2,"WifiConfig":4}} 00:53:59 MQT: stat/80/STATUS6 = {"StatusMQT":{"MqttHost":"192.168.200.1","MqttPort":1883,"MqttClientMask":"DVES_%06X","MqttClient":"DVES_56D705","MqttUser":"scriptuser","MqttCount":1,"MAX_PACKET_SIZE":1000,"KEEPALIVE":15}} 00:53:59 MQT: stat/80/STATUS7 = {"StatusTIM":{"UTC":"Wed Apr 10 22:53:59 2019","Local":"Thu Apr 11 00:53:59 2019","StartDST":"Sun Mar 31 02:00:00 2019","EndDST":"Sun Oct 27 03:00:00 2019","Timezone":"+02:00","Sunrise":"07:07","Sunset":"20:35"}} 00:53:59 MQT: stat/80/STATUS10 = {"StatusSNS":{"Time":"2019-04-11T00:53:59","ANALOG":{"A0":8},"DS18B20":{"Temperature":1.0},"AM2301":{**"Temperature":null,"Humidity":null},"TempUnit":"C"}}** 00:53:59 MQT: stat/80/STATUS11 = {"StatusSTS":{"Time":"2019-04-11T00:53:59","Uptime":"0T00:09:47","SleepMode":"Dynamic","Sleep":50,"LoadAvg":48,"POWER1":"0","POWER2":"0","POWER3":"0","POWER4":"0","Wifi":{"AP":1,"SSId":"lj3m","BSSId":"E4:F0:42:E6:0A:85","Channel":6,"RSSI":100,"LinkCount":1,"Downtime":"0T00:00:06"}}} ``` - [x] Provide the output of console when you experience your issue if apply : _(Please use_ ``weblog 4`` _for more debug information)_ ``` CONSOLE OUTPUT HERE: under väntan startsignal hög puls = means timeout during wait for start signal high puls 00:57:24 DHT: Timeout under väntan startsignal hög puls 00:57:26 DHT: Timeout under väntan startsignal hög puls 00:57:28 DHT: Timeout under väntan startsignal hög puls 00:57:30 MQT: tele/80/STATE = {"Time":"2019-04-11T00:57:30","Uptime":"0T00:13:18","SleepMode":"Dynamic","Sleep":50,"LoadAvg":30,"POWER1":"0","POWER2":"0","POWER3":"0","POWER4":"0","Wifi":{"AP":1,"SSId":"lj3m","BSSId":"E4:F0:42:E6:0A:85","Channel":6,"RSSI":100,"LinkCount":1,"Downtime":"0T00:00:06"}} (bevarad) 00:57:30 MQT: tele/80/SENSOR = {"Time":"2019-04-11T00:57:30","ANALOG":{"A0":8},"DS18B20":{"Temperature":1.0},"AM2301":{"Temperature":null,"Humidity":null},"TempUnit":"C"} 00:57:30 DHT: Timeout under väntan startsignal hög puls 00:57:32 DHT: Timeout under väntan startsignal hög puls 00:57:35 DHT: Timeout under väntan startsignal hög puls 00:57:36 DHT: Timeout under väntan startsignal hög puls 00:57:38 DHT: Timeout under väntan startsignal hög puls 00:57:40 DHT: Timeout under väntan startsignal hög puls 00:57:41 WIF: Kontrollerar anslutning... 00:57:41 WIF: Ansluten 00:57:42 DHT: Timeout under väntan startsignal hög puls ``` ### TO REPRODUCE Nothing it happens all time, works after reboot for a minute then it starts to get null more and more null. After som hour or so only null values. ### EXPECTED BEHAVIOR Get both values. ### SCREENSHOTS _If applicable, add screenshots to help explain your problem._  ### ADDITIONAL CONTEXT Not sure if needed but AM2302 is connected to GPIO14 and my DS18B20 is connected to GPIO2. **(Please, remember to close the issue when the problem has been addressed)**

[DarthKegRaider]

How many hours did it take to come up with that theory Turimo? I desoldered DHT22 yesterday from a production NodeMCU module because it was still displaying Null after 8 or so hours (usually less than 24 hours) on build 8.2.0.3. I will install it into a test rig today, but I don't hold much hope for it, as the problem has been plaguing my systems since build v6.5. I usually keel the dht22 devices for other systems, and the dht11 and bme280 for tasmota.

[jnt2007]

I have a decision in my case. Just replaced my Asair AM2302 to another brand Aosong AM2302. More than 1 month problem not reproduced

[tumiro]

I thougt I could help, because nobody had mentioned Tasmota 8.2.0.3. Anyway. So long no nulls. Regards..

[abnoba12]

I had this issue. I updated to 8.2.0.4 I have been running for two days now with no issues.

[abnoba12]

I had this issue. I updated to 8.2.0.4 I have been running for two days now with no issues.

It ran for a few days with no issues, but now I am getting NULLs again. I cycled the power and the came right back.

I just updated to 8.2.0.5, I'll see if the minor revision does anything.

[tferegotto]

Hello I have same problem with an AM2302. With a custom firmware written by me based on dhtnew library, and compiled with arduino, was working perfectly. I think that the readings frequency is too high. Is there a command or a way to reduce it?

[eku]

I think that the readings frequency is too high.

No, that's not the problem. I changed the initial delay from 1us to 20us (equal to DHT11) and have no problems since then.

[johination]

How can i chance the initial delay?

[eku]

@johination change DHT driver and compile your own binary of Tasmota.

[arendst]

If it's a matter of changing the init timing why not select DHT11 instead of AM2301. That way you use the 19mSec init timing and use the same other timings as AM2301.

Easy fix and no need to re-compile.

EDIT: Won't work as the calculation is different. I'll see what I can do....

[arendst]

I revisited the specs and the AM2302 is supposed to react within 1mSec so the delay of 2mSec should be more than enough.

Do other users have issues too with their AM2302?

I cannot test as my AM2301 works just fine.

[eku]

@arendst I own several DHT22 of one batch. I run one of them with Tasmota and the others with Ethersex. The sensor on Tasmota runs for about 12-20 hours and after that it doesn't give any more values. A powercycle is needed. But if I use the timings that Ethersex also uses, the DHT22 with Tasmota works for weeks without dropouts.

Tasmota could react a little more tolerant to manufacturing tolerances of the sensors and we would save ourselves many similar error reports.

[arendst]

I understand completely but...

If you go up in this issue you'll find reports of users having other issues. In fact during the cause of this issue I provided 5 different versions of the driver and in the end the current driver (v5) made it for all.

So restarting the discussion and tweaking the timers again will open the can of worms once more.

[rlajos]

I revisited the specs and the AM2302 is supposed to react within 1mSec so the delay of 2mSec should be more than enough.

Do other users have issues too with their AM2302?

I cannot test as my AM2301 works just fine.

I just would like to help with sharing my experience with this issue... I have bought some AM2302 units and had trouble with even starting the tests with them. (Wemos D1 mini, Tasmota 8.3.1 sensor, GPIO2 input) I could not have any results, just "null" values, whatever device - AM2301, SI7021 I was setting and by normal Wemos start. The only workaround I found, is power cycling only the AM2301 unit pulling out and in the Vcc wire of the sensor, while the Wemos is running. After soft restart there are "null" values again... I hope it can help, I truly appreciate the Tasmota work!

[PabloVogel]

My experience is that when the DHT11 starts outputting only nulls is because its hang, thus only power cycle brings it back to life, for a while. I did some debuging and muy units didn't respond to the handshake, so it's not a protocol problem. Some batch seems to be unstable, and can be upset by small spikes or other noise.

[tferegotto]

I have exactly the same problem using a nodemcu, an AM2302 and tasmota 8.3.1. The sensor reports NaN after 2 days more or less.. but it's not an electric problem. With the same hardware I tried to build a small application written in C with arduino code and DHTNEW library and working perfect for 10 days with a reading every 10 seconds.

[tekelectron]

I have been having the same issue, I purchased a lot of 10x am2302 sensors and I came to use them this evening and ended up here. They worked for several hours or several minuets worse case. The didnt work after a software restart but would recover on hard power restart. I was using GPIO 2 and I have just changed it (soldered to the chip in my case as I'm using an ESP 01 which only has GPIO 2 accessible on its header) to GPIO 14 and now the sensor works even on restart. So the issue for me was basically any GPIO that is not 14 in combination with the AM2302 will not work properly with the Tasmota FW on my ESP's however if I write code in Arduino yes it works fine on any pin.

[rlajos]

I can confirm, (thank you @tekelectron) when I have changed AM2302 form GPIO2 to GPIO14 the unit works like a charm. Tasmota recognizes the sensor right after the boot, and runs 4 days without any problem. There must be some GPIO specific symptom during the boot process on the Wemos which prevents the port readout. More important, it works on GPIO14!

[cairnsie13]

I have this issue if I have 2 DHT 22 connected to one tasmota device. I have replicated this on the D1 mini and sonoff basic. The devices can be stable for weeks at a time or only hours but eventually read null on one of the sensors. Only a power cycle will fix the issue. I have tried version 6.5 up to the latest version to try and rectify this issues to no avail. I originally had a bme 280 and DHT 22 on my sonoff basic, which was completly stable. I replaced the BME due to self heating issues with a DHT 22 and caused the instability I previously observed in the d1 mini with 2 sensors. Any device with only 1 DHT 22 has been stable for months and months.

[LurchiStromberg]

Hi! Having 5 of that AM2302 and same Issues.

Will there ever come a fix or is it giving up and i can toast the AM2302??? I ordered AM2301 but sadly they deliver AM2302 from China....

EDIT: I forgot. Its also a Wemos D1 Mini Board i use. Yesterday i installed another DHT22 at a sOnOff Basic at IO2 with a 4,7 KOhm Pullup. Till now its running... (not 24 hours till now) Strange

[rlajos]

I can confirm, (thank you @tekelectron) when I have changed AM2302 form GPIO2 to GPIO14 the unit works like a charm. Tasmota recognizes the sensor right after the boot, and runs 4 days without any problem. There must be some GPIO specific symptom during the boot process on the Wemos which prevents the port readout. More important, it works on GPIO14!

My initial happiness was to early, yes it seems to have a bug indeed. (I use Wemos D1 mini, good linear PSU...) the symptom is returning after few days of working even with GPIO 14. I will give it a shot and change the firmware TO AN ESPHome and will describe the result.

[JorgeMaTeixeira-zz]

I'm having the same problem, and this happen with a wemos d1 mini using latest tasmota. There's any way to reboot the 5vdc when we get null?

[LurchiStromberg]

I also changed the Sensor now and cut Cable to the Sensor to about 20cm. First i thought its running, but after 3 Days i also have the null Values again. No matter at what GPIO the Sensor is connected, its still buggy.

I connected another 2301 / DHT22 to a sOnOff Basic. That one is working since 6 Days now without faults and null Values.

I think there is Problem with Tasmota and Wemos D1 Mini!

I am curoius about the Reply of @rlajos if he has more success with different Firmware like ESPeasy.

[wongnam]

To increase the stability of the sensor suggests that you add a 10K resistor to pull up the signal line to the VCC line for it and should use 3.3V only. Please refer to the illustration below.

[LurchiStromberg]

I already use a 4,7 K Ohm Resistor. Should i try it with a 10 K Ohm ? I will look or just order some....

But its strange so or so, that at a sOnOff ESP8266 its working and at a Wemos D1 mini not.....

[wongnam]

@LurchiStromberg Wemos D1 Mini does not have gpio pull up resister but some gpio of some Sonoff devices have it.

[tferegotto]

I also changed the Sensor now and cut Cable to the Sensor to about 20cm. First i thought its running, but after 3 Days i also have the null Values again. No matter at what GPIO the Sensor is connected, its still buggy.

I connected another 2301 / DHT22 to a sOnOff Basic. That one is working since 6 Days now without faults and null Values.

I think there is Problem with Tasmota and Wemos D1 Mini!

I am curoius about the Reply of @rlajos if he has more success with different Firmware like ESPeasy.

I don't use a wemos, I'm using a NodeMCU and I had the same issues with Tasmota 8.3. In the same hardware and same connected pins, I've writed a custom firmware with arduino DHTNEW library an it's working perfecty for several months.

[LurchiStromberg]

I also changed the Sensor now and cut Cable to the Sensor to about 20cm. First i thought its running, but after 3 Days i also have the null Values again. No matter at what GPIO the Sensor is connected, its still buggy. I connected another 2301 / DHT22 to a sOnOff Basic. That one is working since 6 Days now without faults and null Values. I think there is Problem with Tasmota and Wemos D1 Mini! I am curoius about the Reply of @rlajos if he has more success with different Firmware like ESPeasy.

I don't use a wemos, I'm using a NodeMCU and I had the same issues with Tasmota 8.3. In the same hardware and same connected pins, I've writed a custom firmware with arduino DHTNEW library an it's working perfecty for several months.

Thats cool... Interessting Part would be what you changed? Would you be so kind at make your bin File public?

[solarsnoop]

Hi I have a work around and use this also for my 18b20 sensors. Just use a other Gpio as output instead of the 3.3V out. And before u start detect the dht22 sensor set the gpio high. After messure set the gpio low. In this case the dht22 or 18b20 get an reset after every measurement. For me that works stabil

[LurchiStromberg]

HI! I have no Idea why, but since 27 Days mine is running. I didnt change anything till now. I ordered new Resistors that arrived about 1 Week later. But since those Days i didnt change the 4.7 kOhm. Just started the Device new.... Well as long it runs i wont change anything.. Curious how long it will work. For now about 1 Month is nice 👍

[vzmuda]

Hello, I have the same problem. New informations from me:

• after disconecting main power and conecting back everything works
• if everything works ( I see values) and I make soft reset ( from tasmota webpage) , I have null values... I think, watchdog randomly make reset of the device and then i have null values until I make reset - disconecting from power.

( Sonoff mini, GPIO2, pull-up 4k7,standart tasmota 9.1.0 )

Can anybody, if have same problems, when see values,make soft reset and confirm my situation?

[LurchiStromberg]

HI! At me it was nearly one Month the DHT was running at my Wemos. Then, a few Days ago i had also that "Null" Values Problem again. Soft Reset never worked and you need to disconnect the Wemos to have Values again.

Now i changed the Resistor to a 10 K Ohm Version.

I can make a soft Reset now and Values are still shown.

So lets see if that was the Main Issue...

[vzmuda]

Hello, I have the same problem. New informations from me:

* after disconecting main power and conecting back everything works

* if everything works ( I see values)  and I make soft reset ( from tasmota webpage) , I have null values...
  I think, watchdog randomly make reset of the device and then i have null values until I make reset - disconecting from power.

( Sonoff mini, GPIO2, pull-up 4k7,standart tasmota 9.1.0 )

Can anybody, if have same problems, when see values,make soft reset and confirm my situation?

So a few new informations: -adding capacitor 100 uf without changes

• using new AM2302 without changes -resistor 1k - 10k without changes

When I use the same components on wemos D1 mini, everything works fine

So I think, only the difference is that Sonoff mini uses chipset ESP8285 and my wemos D1 mini ESP 12F

[hoepps2802]

Same problem with sonoff mini on gpio 2. main power on off fix the null value. I will try yo give vcc from dht22 on gpio and power on in intervals

[tayhall]

Same issue with NodeMCU and Tasmota 9.1 or 9.2 I had the same setup using ESPHome and didnt have an issue with the temp sensor. However I wanted Tasmota accross all my devices as I prefer it to ESPHome. I can get the temprature to work for a few days and then it stops. Needs a hard power reset to start again. Ive tried on a few different GPIOs

[LurchiStromberg]

We can cry Rivers here... If Theo wont take a look on it nothing will change. Its of course an Issue with the Firmware. Coz as you all said its running very well with ESPeasy. I think it has something to do with internal Pullup or else...

I have same Issues with Pulse Counter of my S0 Powermeter.

With Tasmota the counts are random. Same config with ESPeasy runs like a charme since nearly one Year.

[Danifont]

Same problem ... two identical configuration with Tasmota on sonof RF bridge with ASAIR AM2302 sensors on GPIO 4 ... one of them running for near two weeks without problem, the other report nulls after some hours of working. Do hard reset and works for some more hours ..., waiting for the next null reporting. Looks like a desyncronization problem ...

[LurchiStromberg]

Can a Mod open this Issue again? Coz it dont looks like its fixed!

Or should we better start a new one?

[leranp]

Same here, with 3 sensors connected to wemos d1 mini. Work for months any lately become unstable , i think because i upgraded the version to 9.2

[UBWH]

This is not a solution ... but a workaround.

EDIT ...Rules corrected

I have an AM2301 (DHT21) connected to VCC/GND/GPIO0 of a Shelly1. Works great .... until it doesn't.

As others have said, a software reset of Tasmota does not help.

So I took advantage of the relay to wire as follows

GPIO Header GND ----------------------------------------------AM2301 GND
GPIO Header GPIO0 --------------------------------------------AM2301 DATA
GPIO Header 3V3 --------------------[RELAY] ------------------AM2301 3V3

And then used these RULES

ON AM2301#Temperature==null DO BACKLOG ADD1 1 ;EVENT gotnull=%var1% ENDON
ON EVENT#gotnull>60 DO BACKLOG var1 0;power1 off;delay 10;power1 on;var1 0 ENDON

Not saying these RULEs are elegant, or ideal.... but they work for me.

[ascillato]

Hi,

Thanks for sharing your work.

Do you have set a pulsetimer and your relay is inverted?

Also, a Shelly device don´t have enough power for maintaining a sensor. That seems to be the issue, in your case that your sensor hangs.

I have several of those working since 3 years now outside in my home. They never show this behaviour. They are being powered from nodeMCUs. It is known that there is a batch of those sensors that are faulty. May be you have one of those OR your sensor is not receiving enough energy. For testing, try to power your sensor with a separated 3.3v power source.

[UBWH]

My AM2301 has run for over 1 month before hanging. I don't think the 3V3 power source from the Shelly1 is the issue.

BTW - the AM2301 datasheet says it draws only 500 micoAmps with a 5V supply = 2,5 mW.

[ascillato]

The power source of the Shelly was designed only for powering itself. I have tested this and whatever connected to the 3.3v of the shelly can fail or make the shelly to fail and restart. For testing, please, try to power your sensor with a separated 3.3v power source.

[Rubiconline]

This is not a solution ... but a workaround.

EDIT ...Rules corrected

I have an AM2301 (DHT21) connected to VCC/GND/GPIO0 of a Shelly1. Works great .... until it doesn't.

As others have said, a software reset of Tasmota does not help.

So I took advantage of the relay to wire as follows

GPIO Header GND ----------------------------------------------AM2301 GND
GPIO Header GPIO0 --------------------------------------------AM2301 DATA
GPIO Header 3V3 --------------------[RELAY] ------------------AM2301 3V3

And then used these RULES

ON AM2301#Temperature==null DO BACKLOG ADD1 1 ;EVENT gotnull=%var1% ENDON
ON EVENT#gotnull>60 DO BACKLOG var1 0;power1 off;delay 10;power1 on;var1 0 ENDON

Not saying these RULEs are elegant, or ideal.... but they work for me.

Brilliant. I had the same issue with 2 Sonoff Dual and 3 sensors asair AM2302. I've trying esphome/easp easy/tasmota and always got the null% after one or 2 days.

The solution for me was to plug the AM2301 3.3V on the TX of the sonoff. GPIO Header GND ---------------------------------------------------AM2301 GND GPIO Header GPIO1 (RX) --------------------------------------------AM2301 DATA GPIO Header GPIO3 (TX) --------------------------------------------AM2301 3V3 And in the configuration, I've created a dummy relay on GPIO3.

When the sensors cashes, I just have to switch off/on the relay and the sensor starts again.

[UBWH]

Could you please post:

1. Your config
2. Your rules :-)

[Rubiconline]

Could you please post:

1. Your config
2. Your rules :-)

Hello, the tweak is to create a relay 3 on GPIO1

I'm not using rules but scripting (I've build a firmware with sensor and scripts). I've added a 20 sec timer to give time to the sensor to restart. I don't know if it's usefull.

[mkjustuk]

Could you please post:

1. Your config
2. Your rules :-)

Hello, the tweak is to create a relay 3 on GPIO1

I'm not using rules but scripting (I've build a firmware with sensor and scripts). I've added a 20 sec timer to give time to the sensor to restart. I don't know if it's usefull.

That's awesome, but can I check, you say that the relay should be Gpio1 but the connections you mention above have the 3.3v to Gpio3?

[mkjustuk]

Don't worry, I figured it out, it's Gpio1 to 3.3v on the sensor.

[Saur0o0n]

So any real solution for that problem? Can anyone state if this is sensor issue (and power off/on sensor helps) or this is Tasmota issue? I'm having (somewhere since Tasmota 8) problem with two Sonoffs mini + DHT22. Like many posts above, Tasmota restart creates the problem (for example - update), and more restart doesn't help - only physical restart solve the issue.

[mkjustuk]

The above GPIO 1 'trick' above has been working on a troublesome Sonoff basic since May. I have several other Sonoff basics that never give a null value without this trick, so I believe it's hardware related somehow.