Espeasy: 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?

[TD-er]

Any chance to get this fixed in an actual release?

There is quite a big chance it will be fixed, but not sure when, as I'm also working on a lot of other issues myself.

[uzi18]

@dpomt please try to change gpio and save new settings and/or delete dht task and configure it one more time
waiting for feedback

[uzi18]

try this build: normal_ESP8266_4M1M.bin.zip

[haldi4803]

Update here...
I've updated to the "ESP_Easy_mega-20191119_normal_ESP8266_1M.bin". No Reset, kept settings. On one of my 3 ESP8266 DHT22 sensors and it works fine.
Maybe the issue can be circumvented if you flash the old version and if it works update to a newer one. Or it just works with this version.
It's running fine now for 1day 12 hours.

BUT Same as on the old version if i press the reset button, OR use software reset via Web Interface i get NaN until i replug the Power. Not sure if this is a hardware specific issue of this chinese board.

[uzi18]

have tested on my own with DHT22 and after reboot from website have no NaN values

[TD-er]

BUT Same as on the old version if i press the reset button, OR use software reset via Web Interface i get NaN until i replug the Power.

And what if you just press submit on the task configuration page?
This does trigger a new init of the plugin.
Maybe the sensor is brought into some undefined state it can only get out of by power cycle, or more time to initialize?

[haldi4803]

Nope, pressing Submit doesn't help.
Only Powercirlce helps. Is Probably a Hardware issue and not Software related.

[Roos-AID]

@uzi18

try this build: normal_ESP8266_4M1M.bin.zip

After loading this build, the ESP is dead. It cannot connect to Wifi anymore. I had to flash blank_1MB.bin and an older version to get the chip up and running again.

ESP board
ESP Chip ID: | 2497917 (0x261D7D)
ESP Chip Frequency: | 80 MHz
ESP Board Name: | PLATFORMIO_ESP01_1M

With this ESP01S board and the DHT22 as mentioned here https://www.ebay.ch/itm/AM2302-DHT22-ESP8266-Temperature-Humidity-Sensor-Wifi-Wireless-Module-ESP-01-01S/273598617288
the problem of NaN after Warm Boot remains with all latest firmwares.

Only a Power off-on cycle makes it working. Pressing the reset button on the DHT22 board does not help.

I strongly believe this is a hardware problem with this DHT22 module.

@uzi18 if you want I can mail the ESP01 and DHT22 board to you for your testing. I have multiple on stock (Netherlands).

Regards, Rob

[uzi18]

@Roos-AID please contact me via https://gitter.im/uzi18

my image was for module with 4M flash

[Roos-AID]

I have been debugging this issue and found something interesting.

The problem is with the GPIO 2 line on the ESP01.

When a (cold or warm) boot is performed, then the GPIO 2 line gives exactly the same data as the TX line for the first 36 msec. After this the GPIO 2 line is polling the DHT22 with a 2mS low after which the DHT22 correctly responds.
The strange thing is, that after a cold boot, the DHT22 responds correctly to the 2mS low signal. After a warmboot, the DHT22 is with the TX data set in a strange state and cannot be reset other than with a power off-on.

So, I decided to use the GPIO0 line available on the ESP01. This does not get the TX data when booting.
When we use GPIO0 on the ESP01 the DHT22 gives the correct data and no NaN after warmboot.

I hope above is clear. I can make some pics from my logic analyser show this.

[TD-er]

@Roos-AID
Does look like the same findings as reported here

[haldi4803]

So, I decided to use the GPIO0 line available on the ESP01. This does not get the TX data when booting.
When we use GPIO0 on the ESP01 the DHT22 gives the correct data and no NaN after warmboot.

Makes sense now thanks.
Any idea how i'd do that on this cheap boards that are hard wired?
https://www.ebay.ch/itm/AM2302-DHT22-ESP8266-Temperature-Humidity-Sensor-Wifi-Wireless-Module-ESP-01-01S/273598617288?_trksid=p2485497.m4902.l9144

[TD-er]

The strange thing is, that after a cold boot, the DHT22 responds correctly to the 2mS low signal. After a warmboot, the DHT22 is with the TX data set in a strange state and cannot be reset other than with a power off-on.

I just re-read your comment and this part now does kinda make sense to me.
From a cold boot, the DHT22 is probably not yet "booted" in the first several msec.
Maybe the change in 20190830 was also a change of the core library, which now outputs a different string in the first 36 msec or the GPIO2 was in other builds switched sooner to "normal" behavior.

[CONSULitAS]

Maybe the change in 20190830 was also a change of the core library, which now outputs a different string in the first 36 msec or the GPIO2 was in other builds switched sooner to "normal" behavior.

No, this is output of the boot rom and is found on every ESP8266 device. 😢

Analysis and solution (hardware) see https://github.com/letscontrolit/ESPEasy/issues/2569#issuecomment-688901549

[TD-er]

This can also be closed. See #2569 for more information.