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)**

[wongnam]

you should separate the issue by try to connect only the AM2302 first and see if it will work or not. I am using AM2302 without any issue.

[ascillato2]

Hi, sorry. I can't reproduce your issue. Please, could you recheck your wirings?

[Magnus-rosenborg]

Ok, god plint. I Will do that right now. Will return later how It workt out

Med vänlig hälsning, Magnus

11 apr. 2019 kl. 06:17 skrev Wongnam notifications@github.com:

you should separate the issue by try to connect only the AM2302 first and see if it will work or not. I am using AM2302 without any issue.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or mute the thread.

[Magnus-rosenborg]

Now i’ve the DS18B20 disconnected but still get the null values. Could it be something in my compilation?

11 apr. 2019 kl. 10:22 skrev Adrian Scillato notifications@github.com:

Hi, sorry. I can't reproduce your issue. Please, could you recheck your wirings?

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/arendst/Sonoff-Tasmota/issues/5619#issuecomment-482017641, or mute the thread https://github.com/notifications/unsubscribe-auth/AvNQqe9KF648tJW6I44EHnT0vRJFfVYgks5vfvC7gaJpZM4coa1b.

[ascillato]

You can try with another AM2302 and you can also try the precompiled bins.

[dcbo]

Same for me, I have four Nodemcu running Tasmota 6.5.0 (precompiled Version sonoff-DE.bin)

Three Modules are configured only with one DHT11-Sensor on D5 GPIO14 and all three works fine.

The forth is equipped with:

• Switch1 (9) on D2 GPIO3
• Relay2 (22) on D1 GPIO5
• Relay1 (21) on D6 GPIO12
• AM2301 (2) on D5 GPIO14 and it worked for some time.

I think after the first Reboot (Software reset, without Power-Cycle) it shows "AM2301 Temperatur null°C, AM2301 Feuchtigkeit null%". Any additional Software reset without Power-Cycle doesn't change the behavior.

After Power-Cycle the AM2301 works again.

[Magnus-rosenborg]

Hi, Could it be that the esp8266 has to much to do so it’s at timing issue on the 1-wire bus? If so why on the AM2302 and not on the DS18B20? I have tried 2 different AM2302 same problem. Next step is try the precompiled sensor version.

12 apr. 2019 kl. 10:39 skrev Dario notifications@github.com:

Same for me, I have four Nodemcu running Tasmota 6.5.0 (precompiled Version sonoff-DE.bin)

Three Modules are configured only with one DHT11-Sensor on D5 GPIO14 and all three works fine.

The forth is equipped with:

Switch1 (9) on D2 GPIO3 Relay2 (22) on D1 GPIO5 Relay1 (21) on D6 GPIO12 AM2301 (2) on D5 GPIO14 and it worked for some time. I think after the first Reboot (Software reset, without Power-Cycle) it shows "AM2301 Temperatur null°C, AM2301 Feuchtigkeit null%". Any additional Software reset without Power-Cycle doesn't change the behavior.

After Power-Cycle the AM2301 works again.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/arendst/Sonoff-Tasmota/issues/5619#issuecomment-482490204, or mute the thread https://github.com/notifications/unsubscribe-auth/AvNQqWzAH18hjsBNVvqI-mJH7XL3o3E6ks5vgEY_gaJpZM4coa1b.

[Jason2866]

I dont think so. "LoadAvg":48 is a value which indicates no problems with CPU load

[Dreamoffice]

Hi i have the same problem with the DHT22

[Magnus-rosenborg]

Now running on precompiled version 6.5 still have the null problem. Any idea??

13 apr. 2019 kl. 10:11 skrev Dave notifications@github.com:

Hi i have the same problem with the DHT22 https://user-images.githubusercontent.com/35889916/56076721-835ef880-5dd4-11e9-9ad6-d83326d5f677.png — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/arendst/Sonoff-Tasmota/issues/5619#issuecomment-482787713, or mute the thread https://github.com/notifications/unsubscribe-auth/AvNQqbJNjaP6nI_N4LMcdznxqdl0XaaEks5vgZFEgaJpZM4coa1b.

[ascillato]

Which version type did you upload?

The basic does not have all sensors support. You have to use the latest full version http://thehackbox.org/tasmota/sonoff-sensors.bin

[wongnam]

@Magnus-rosenborg Try to add a pull up resistor to the sensor.

[Jason2866]

Seems the self compiled is buggy...

[Magnus-rosenborg]

I downloaded the sensor version. I had a resistor first then tried without but it wasn’t a 10k resistor, try that tomorrow. So no different the precompiled and home compiled sensor-versions..

14 apr. 2019 kl. 11:54 skrev Jason2866 notifications@github.com:

Seems the self compiled is buggy...

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/arendst/Sonoff-Tasmota/issues/5619#issuecomment-482939489, or mute the thread https://github.com/notifications/unsubscribe-auth/AvNQqTyDKRLxfSHgFOo00sAfdF2JbEzVks5vgvragaJpZM4coa1b.

[ascillato]

Hi,

Any news on this?

[Magnus-rosenborg]

Yes, the new is that i had tried everything but not getting it to work without null values sometimes, very strange maybe hardware failure I do not know. I give up on that sensor for now, Installed a BME280 and it’s working fine. Thanks for att help guys. Best Regards Magnus

17 apr. 2019 kl. 04:35 skrev Adrian Scillato notifications@github.com:

Hi,

Any news on this?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/arendst/Sonoff-Tasmota/issues/5619#issuecomment-483914275, or mute the thread https://github.com/notifications/unsubscribe-auth/AvNQqVoNUI6SsDqJGHQoh_EhaQ7w9-uJks5vhohtgaJpZM4coa1b.

[DasUrmel]

Hello *,

I have the same problem with my sonoff basic and DHT22 (the red module on the pic above, with integrated resistor) from china running 6.6.0.3. After some time (hours, days) I get null values from sensor. So I attached 3 sensors to one sonoff via GPIO1, 2 and 4 and a breed board to test what helps after the error occurs.

The results are confusing: If one or two sensors show null, one or two other may keep reporting good values! Reboot of sonoff does not help at all. Hard reset (Power off / on) of sonoff always works. Power reset (3.3V off / on) of a sensor only SOMETIMES works. Data reset (pull cable and replug) of sensor works almost always. -> If data reset (on ONE sensor) works, all other null sensors will start reporting good values as well!

Thorsten

[DarthKegRaider]

I have the same issue with the DHT22 (AM2301). I have several of these sensors around the house and gardens and they work perfectly on the NodeMCU style of 8266 with Tasmota (6.5.0.13). The only times that I have issues with the DHT22 sensors on the WeMos D1 Mini devices. For now, I am just using the AM2301 devices exclusively on the NodeMCU modules and using my DHT11 sensors on the WeMos D1 modules.

I'm no engineer, so I don't know the difference between the D1 and the MCU, but I'm sure there has to be something other than size in the difference for these modules to start displaying NULL after about 12 hours of use. It isn't very fun when you have these devices tucked up in obscure places.

[DasUrmel]

I bought 3 of the Sonoff Basic. Only 1 seems to work fine with 1 (out of 5) DHT22. Running now for 10 days. For the others.... I also changed to I2C and BME280 sensors. No problems at all with that combination.

[retroip]

Hello there, same issue tasmota 6.5 bought esp01-S with dht22 (3 pieces). Temp and Humidity is shown after real on off. Rest button or others not working, and leading to null values. Going to test with suggested pullup and parallel also upgrade to v.7

[kiwichrish]

Just adding to the comments, getting the same issue with three DHT22 devices. Two on-PCB from different batches/suppliers and the third he larger wired AM2302. All three on esp01-s running self-compiled tasmota, 6.6.0.13. They run for 2-3 days then start returning null. Need to power-off to get data, soft and hard reset do not return to service. Sensors running on 3V3 rail. Currently all running but will hook up a scope to the next one that fails and see what I can see, so to speak.

[kiwichrish]

Reading around a bit more about this.. All of the ones I have are 'asair' branded. Apparently the Asong ones are better quality / more reliable? Can someone who has no issues with their DHT22's comment on what brand they are?

[ascillato]

Mine are ASAIR and I don't have that issue. May be the power is not enough? the resistor is not correct? I have 1K pull up.

[kiwichrish]

OK.. Cheap USB analyzer on a working DHT11 and DHT22 using sigrok/pulseview Decodes the 11 pulsetrain fine, can't decode the 22. Can someone point an analyzer at an Asong DHT22 and see what they get with a software decoder? Will leave things hooked up and wait for it to crash and see what I get.

[kiwichrish]

Thanks @ascillato The External one I assume has a pullup included. Power is a possibility, will find the PSU for my scope and see if the power rail is sagging. (I know I used it not that long ago.... :-) )

[ascillato]

Mine didn't have the pull up. I have to add it.

[kiwichrish]

OK, interesting, will pop apart one of the leaded ones and see if there is a pullup inside, might be using the weak internal pullup on the ESP8266, which would probably be flaky. That does not explain the commercially made modules with the ESP on them that fail after a while as well though.. It has a 10k pullup... More food for thought.

[kiwichrish]

The rail dips about 10mv with a ring to 25mv or so on the first pulse after the start pulse from the micro.. Other than that it's stable.. Still running at this stage so wont mess with it till it stops working now.

[kiwichrish]

Sneaked out of the house to have a bit of a play (Kids messing about with new Xmas stuff inside..). With one of the leaded Asair branded sensors connected to a Arduino Uno, using internal pullup I get 100% decode with the same logic analyzer / software on 5 and 3.3V. So something up with the pulse timing. So something is slightly different with the Tasmota / ESP IO levels, timing etc..

[kiwichrish]

The ESP / Tasmota is using a ~ 20ms start pulse, whereas the Arduino default library uses ~1.1ms. (1us sampling, vague on-screen cursor tests). 20ms is the longest pulse allowed in the spec I found for the protocol, and the response from the DHT22 is different between the two.. With the Arduino 1.1ms start pulse the response is per the docs I found for the device, but with the 20ms pulse the response is not correct.... More experimentation follows. :-)

[kiwichrish]

To clarify.. My thinking is that the 20ms start pulse is at the edge of valid values, so if there is a tolerance or drift issue may cause invalid or no replies to come back from the the DHT22.

[arendst]

@kiwichrish what happens if you select SI7021 instead of DHT22. This will change the 20mSec into 0.5mSec.

  if (GPIO_SI7021 == Dht[sensor].type) {
    delayMicroseconds(500);
  } else {
    delay(20);
  }

and probably solves your issue.

[kiwichrish]

Hi Theo,

Just had one lock up on a wemos D1 and had a look at the code. Seeing the start pulse but no response from DHT22. Found that line and also further down in the same file, starting line 93:

  noInterrupts();
  digitalWrite(Dht[sensor].pin, HIGH);
  delayMicroseconds(40);
  pinMode(Dht[sensor].pin, INPUT_PULLUP);
  delayMicroseconds(10);

This does not meet the protocol spec either. The release time for the bus is 20us min, 30 typical, so the pin high, 40us delay, then switching to input is probably causing issues as the start of the reply typically happens during that 40us delay, and the DHT22 is trying to pull the pin low against the output of the ESP8266. This explains the ~20us supply rail glitch I was seeing.. This could certainly cause issues after a few hours..

The 10us settling / rise delay is sensible though..

Removed the explict high and 40us delay so it's just:

 pinMode(Dht[sensor].pin, INPUT_PULLUP);
 delayMicroseconds(10);

Testing, and now seeing 20us release, 80us low / high cycle per the spec.. Will do some testing on DHT11 as well before suggesting the change as the same library is used for them and they are pretty popular devices.

Merry Xmas. :-)

[kiwichrish]

Should have checked the Adafruit library first..

Their start delay code is now:

  pinMode(_pin, OUTPUT);
  digitalWrite(_pin, LOW);
  switch (_type) {
  case DHT22:
  case DHT21:
    delayMicroseconds(1100); // data sheet says "at least 1ms"
    break;
  case DHT11:
  default:
    delay(20); // data sheet says at least 18ms, 20ms just to be safe
    break;
  }

[kiwichrish]

Another finding for the Wemos D1.. If you use D4 / GPIO2 the DHT22 will not work through a reset cycle unless the power is cycled. D4 is connected to the internal LED on the esp8266 and there's a burst of async comms on restart (not looked into if this is the boot loader or tasmota). After that burst the DHT22 becomes unresponsive untill you cycle power. Guessing the startup delay for the DHT22 means that it does not see the burst of async data. Wondering if the ESP01 is the same as the D4 seems to be the go-to and if the ESP01 restarted (watchdog?) it would have the same effect. Will check into that one tonight, off out on a retail expedition with the daughter now. :-)

[kiwichrish]

Same issue with the ESP-01s modules.. The ones sold on ebay etc with the DHT22 on them use D4 and there's a burst of data on D4 on soft restart, hangs up the DHT22 and requires a power cycle to fix. This is on soft or hard reset. Modules like this thing, which must be really common:

The test one on the wemos D1 with modified code has been up for two days now, no glitches, and I've just re-flashed an ESP-01 as well.. If the ESP does not restart due to brownout etc I'm sure it'll last as well.. I've got some Aosong DHT22's coming from a local supplier to try out as well and will update my comments here and tidy up the patch and do a pull request when I've tested with them as well.. Happy new years every one.

[arendst]

Great! To you too.

Looking forward for your PR.

[kiwichrish]

The Aosong Sensors turned up. They do not hang / lock when the bootloader on the ESP sends the diagnostic string. I found a reference to the string here: https://github.com/espressif/esptool/wiki/ESP8266-Boot-ROM-Log So it's not Tasmota, it's something in the expressif code, which does not surprise me. Also noticed the Aosong sensors seem to be closer to other sample sensors for Humidity, the Asair ones are all 15-25% high compared to DHT11 and BME280 devices I've tested with. Per the sceenshot.

(The sensors are about 100mm apart on my desk..)

[KrzysztofPrzygoda]

IMO, the root-cause of the problem are both: 1) DHT22 bad timings and 2) noInterrupts() that was switched on too late (should be on at the very beginning of the protocol). My AM2302 (with SONOFF Basic R2) has been working stable for 3 days now with PR #7468. Previously it hung (null readings) every few hours with power cycle as a remedy.

[KrzysztofPrzygoda]

@kiwichrish More on sensors tests and comparision: http://www.kandrsmith.org/RJS/Misc/Hygrometers/calib_many.html

[kiwichrish]

Hi @KrzysztofPrzygoda, I found that page when looking around for reference information... Lots of good information there, and a lot of effort to do all that testing!

[kiwichrish]

Hi-ho,

Back to this again, been too busy back at work for the last wee while.

Put in a PR for the start pulse change, I ran a couple of different DHT22's for a week on this code, and it seems to fix them failing when the ESP does not restart. The restart issue is model/brand specific and is still there. Probably a documentation update is the option for that, will take a look at how I do that, I'm a bit of a github newb. :-)

The issue this fixes is illustrated by the screen-grabs from the cheap-o USB scope. This is starting at the end of the start pulse from the ESP. The 'before' shot shows the line pulled to 3.3V by the micro, then ~20us later the DHT22 tries to pull it low hence the 'step'. The after shows the same device post the code change, pin is released to INPUT_PULLUP instead of driven high and held and there is no 'step'. I'm guessing this was causing over-current / heating issue in the sensor, not sure of the exact failure mechanism as I don't know anything about the internals of the sensor.

Before:

After:

[ghost]

Thanks to everyone who is trying to fix this problem! Will there be a tasmota update that fixes this problem, or is there a way I can fix it myself? With kind regards, Nicolas

[ascillato]

There is an open PR #7468 we are testing.

[johination]

I have the same problem with all my dht22 sensors

[arendst]

Try latest development release.

[PabloVogel]

Hello having had that problem with one DHT22, and checking adafruit library, I think you are never supposed to assert a high. You either signal a low or let the gpio on input pull-up. That is why the circuit requires a resistor.

[DasUrmel]

I tested V4 with my problematic DHT22 and it worked fine for the last 3d19h. Just flashed V5.... let's see how it works.

[jnt2007]

I flashed v8.1.0.9 and problem still reproduced. After 2-3 days sensors reporting null. Restart does not affect. I must reboot Sonoff Basic by powerup or disconnect and connect back DHT22. My sensor is ASAIR AM2302

[tumiro]

1 hour ago updated with Tasmota 8.2.0.3 Program Version	8.2.0.3(3a4cf26-tasmota)

2020-04-15T17:00:36 Problem seems to be solved