DHT22 stopped working after 20190830 update

[Quart666]

I updated two of my ES8266 Wemos D1 today. Both of them have a DHT22. And after upgrade the values says NaN on both Wemos D1

[TD-er]

See: https://github.com/letscontrolit/ESPEasy/issues/2569

Test build ESPEasy_mega-20190830-4-PR_2582

[mackowiakp]

The same problem with DTH22 on nodeMCU 8266 4M test build. NaN instead readouts. 20190827 works correctly.

[TD-er]

And with the latest build?

[mackowiakp]

I try 20190903, Nan instead readouts.

[uzi18]

debug log please

[mackowiakp]

Strange. I try to load from GitHub 20190903 again to "catch" the logs but 20190903_252_test_4M disappear from zip file.

[uzi18]

try any other 4M bin

[mackowiakp]

But I wanted to collect logs from the device and software on which I found a malfunction. Only then I will be sure of the logs collected. One of the connected sensors is the PMS dust sensor, supported only by the "test" version.

[TD-er]

It is renamed to ..._4M1M Since there is now also a test build for _4M2M with a different flash layout. (currently only for IR-build)

Also a file will not be included if it is too large to be used.

[mackowiakp]

OK, if _4M1M is equivalent for former "test" version for 4M flash, so still there is no in zip file named ESP_Easy_mega-20190903_normal_core_252_ESP8266_4M1M.bin

[uzi18]

so now question is what image did you flashed

[mackowiakp]

ESP_Easy_mega-20190830_test_core_252_ESP8266_4M.bin. But can not test any equivalent for release 20190903 because I need PMS dust sensor driver. And 20190903 contains some fix`s for DTH.

[uzi18]

try normal build without pms and report if dht works and if you need i can later prepare bin for you with pms to test both sensors

[mackowiakp]

Be so kind to prepare such build. In my meaning there is a sens to "catch" logs in the same configuration on which I found a malfunction

[uzi18]

firmware.bin.zip

[mackowiakp]

Seams to work properly. But give me 24 h for final assumption.

[skylineboy20000]

firmware.bin.zip My DHT22 also stopped responding - NaN, tried all the 4m files in the 20190903 to no avail but this custom build seems to be working so far. Will monitor and report back also.

[uzi18]

@TD-er build env dependent issue?

[mackowiakp]

It looks so. Maybe this is not exactly the same situation, but I installed 20190903 build on other nodeMCU with DTH11 sensor. NaN occurs. But custom FW works properly both with DTH22 and DTH11. But I think that reboots accrues more frequently comparing to 20190827. But it is too short period of time to say it for sure. Maybe it is WiFi calibration related issue, because both units use ADC for another sensor.

[uzi18]

All reports about problems with DHT, was resolved so maybe your problem is related to something different. My build have just some dev plugins disabled by default (in facts it is dev_ESP8266_4M1M)

What if you disable PMS device task?

Please add printscreens of your controller and devices configuration.

[TD-er]

And note the used core version.

[mackowiakp]

First I have to say that configuration of sensor is a little bit complicated, so it may cause some unwanted interactions . I have connected to this unit such set of sensors:

• BMP180
• DTH22
• PMS7003
• photo-resistor connected to ADC
• generic sensor - uptime DTH22, generic sensor and ADC sends readouts do Domoticz just from task directly. In case of PMS and BMP180, readouts are sending via SendToHttp from rule. Its because BMP readouts are sometimes nonsensical like pressure 2500 hPa or temp 200 C. or both. It is already rapport as a bug in issue list. So before sending readout to Domoticz, first values are checked for correctness and then send to Domoticz. PMS laser diode has life time 8000 h of continuous work (less than one year). So to increase lifespan, I turn on sensor from rule every 10 min for 30 sec time period, reset, run task for readouts and SendToHTTP results from role too of course. Today PMS driver has no such facility itself. Core version used in custom FW is ESP82xx Core 2.6.0-dev, NONOS SDK 2.2.2-dev(38a443e), LWIP: 2.1.2 PUYA support The temperature readings between the sensors differ because one is mounted outside and the other inside the winter garden. But the length of the cables for DTH is about 15 cm (thin wall). The 99% humidity indication is correct. Because I live 5 km in a straight line from the Baltic coast and here at this time it is always like this. Below screenshots.

[mackowiakp]

Just updated above post.

[mackowiakp]

Can confirm that using this custom build, reboots accures much more frequently. Revert to 20190827

[TD-er]

Can confirm that using this custom build, reboots accures much more frequently. Revert to 20190827

Just to be clear. What custom build exactly? This one @uzi18 made ?

@uzi18 How did you make it, in Linux or Windows?

[uzi18]

@TD-er as always:

[linaja@pldmachine ESPEasy-mega_test]$ ~/bin/platformio --version
PlatformIO, version 4.0.3

[linaja@pldmachine ESPEasy-mega_test]$ git describe 
mega-20190903-1-g359fecff

[linaja@pldmachine ESPEasy-mega_test]$ uname -a
Linux pldmachine 5.2.10-1 #1 SMP Mon Aug 26 20:47:00 CEST 2019 x86_64 Intel(R)_Core(TM)_i5_CPU_______M_520__@_2.40GHz PLD Linux

[linaja@pldmachine ESPEasy-mega_test]$ git log
commit 359fecff112669f1a15bf57969940a76e2052e6b (HEAD -> patch12, uzi/patch12)
Author: Bartlomiej Zimon 
Date:   Thu Sep 5 19:26:28 2019 +0000

    [Dummy] small fix for save action fix for #2600

commit b5fd0e0ed12889cd1005c8dc5dd250cf84ba6f18 (tag: mega-20190903, origin/mega, origin/HEAD)
Author: ESPEasy release bot 
Date:   Tue Sep 3 04:00:13 2019 +0200

    automatically updated release notes for mega-20190903

[mackowiakp]

Just to be clear. What custom build exactly? This one @uzi18 made ?

Yep.

[skylineboy20000]

Just to be clear. What custom build exactly? This one @uzi18 made ?

Yep.

Just to add, @uzi18's build for me has been online c.35hrs now with no issues, stable and no NaN errors.

[mackowiakp]

In my case there was not NaN readouts too. But more reboots.

[uzi18]

reboots could be related to different core used

[mackowiakp]

But formerly, before installing custom FW, it works a lot better. But for shure formerly I use core 2.4.2 but custom FW based on 2.6.0. When I revert to 20190827 (2.5.2), reboots still occurs that is like in custom FW. Strange.

[uzi18]

will try to prepare 2.4.2 build for test, time is not on my side today as we have a long trip to family

[Roos-AID]

With ESP_Easy_mega-20190903_normal_core_242_ESP8266_1M.bin my DHT22 gets NaN after roughly 1 day. It appears that an unscheduled reboot occurred at 13:00 CET. Log attached All_2019-9-6-23_58_39.csv.zip

A warm reboot does not solve the problem, only after a cold boot the DHT22 responds again.

Is the fix from PR_2571 in this build ? As that fix seemed to have fixed this.

 

[TD-er]

PR_2571 was before the change that may have caused these issues to (re)appear.

I think you're looking at several issues you just described.

• Watchdog reboots (lots of reports of them the last 18 months)
• NaN readings of the DHT22
• DHT22 not being able to recover from a fault state.

The NaN readings are cause of too critical timings needed for this plugin. DHT22 not recovering is something I have no idea about its cause. Watchdog reboots are caused by numerous issues and we're tackling them one at a time as soon as it is clear what is causing them. (not related to this topic)

[uzi18]

@TD-er got only one idea - timings are not accurate, but need to check it with logic analyzer

maybe add +1 of first delay can resolve it, in datasheet 18ms is minimum so maybe delay(19) will. do the job

[TD-er]

maybe add +1 of first delay can resolve it, in datasheet 18ms is minimum so maybe delay(19) will. do the job

That sounds rather time critical :)

[uzi18]

maybe it is and we don't know how esp clock is accurate

[TD-er]

I know there is quite a range of "accuracy' among nodes. The quality of the crystals may differ a lot. That's also one of the reasons I added the "drift" log when the NTP updates. I've seen updates on some nodes which were close to 1% off (> 10 msec/sec correction) and that should not happen with even really low quality crystals.

[uzi18]

see my comment in code with minimum from datasheet only start condition is critical, next we check timing of data from. sensor

[TD-er]

Link?

[uzi18]

so guess it is start condition fail here

[uzi18]

@TD-er https://github.com/letscontrolit/ESPEasy/blob/b5fd0e0ed12889cd1005c8dc5dd250cf84ba6f18/src/_P005_DHT.ino#L153-L159

for. DHT12 it is 200ms for compatibility with supported I2C

[Roos-AID]

Any news on

NaN readings of the DHT22 DHT22 not being able to recover from a fault state.

I can easily reproduce it, when I do a Tools/Reboot then NaN readings from DHT22. As long as there is no warm boot (either invoked manually or by watchdog) the readings are fine.

[haldi4803]

I have the same issue here... Used a chinese Board which goes to GPIO-2 and was wonderwing why i only get NaN on 20191003_normal_ESP8266_1M. So i've switched to the 20190827_normal_ESP8266_1M and without further configuration it just worked.

[mackowiakp]

I use 20190928 1M4M. Works OK both with DTH11 and DTH22. Another issue I had using 20191003 was not working SentToHTTP so revert to 20190928.

[dpomt]

Wemos D1 Mini with DHT22 - always getting NaN and DHT:NoReading. Tried different firmwares (20191123, 20191108, 20190928 etc.), different resistors (3k3, 4k7, 10k) as well as +5V vs. +3.3V Always the same: NaN and DHT NoReading in log.

Any ideas?

[TD-er]

@dpomt Have you also tried the version mentioned in the title of this issue, where it was supposed to be working? Just to make sure your hardware setup is not to blame here.

[dpomt]

@TD-er: yes, I currently have 20190827 with no success. Using D5 (GPIO-14).

[dpomt]

@TD-er: I have re-wired and retested - on a Wemos D1 Mini and on a Wemos D1 Mini Pro. Both work perfect with 20190827!! But does not work with actual release. Any chance to get this fixed in an actual release?

Thanks so much for this great stuff.

[Grovkillen]

Just my quick response: have you tried saving the settings to make sure it's not a settings error?