[DHT22 no longer working in release 20220427]

[wdonker]

After upgrading from release 20220328 to 20220427 DHT22 is no longer working. The log states 'DHT protocol timeout'. 20220328 was working fine (and is again after downgrade).

[TD-er]

I wonder if anyone else can also verify this behavior. The strange thing is that the code for this plugin was not changed since Feb 9, so it is hard to imagine why it now suddenly is no longer working (and again working when downgrading)

Is this with builds made by us, or self built? If self built, please share the used SDK (shown on the sysinfo page) and perhaps other relevant info like what build flags used.

Is this on ESP8266 or ESP32? If using ESP32, are you using IDF4.4? (sysinfo page)

[wdonker]

Sorry, I should have copied all info from the forum thread.

It's an ESP8266, used binary files ESP_Easy_mega_20220427_normal_ESP8266_4M1M.bin and ESP_Easy_mega_20220328_normal_302_ESP8266_4M1M.

I have tested some more: the unit that has the problem also has a SSD1306 display attached. On a unit that has only a DHT22 connected it is working ok. So maybe it is the combination with the SSD1306 / I2C.

[TD-er]

What plugin do you use for the OLED? Can you have a look at the timing stats page?

[wdonker]

I use the normal OLED plugin, not the Framed. The timing stats look like this, but vary very much when I refresh:

To pinpoint the problem I tried the following:

• removed the 1306 device from the config. No change.
• copied the config.dat from the working unit to the non-working one. No change.
• swapped the units (NodeMCU) from their cases to see if there is maybe a difference in connections (although they use the same PCB). Again, no change.

Maybe it is a problem in only this particular NodeMCU. I will try a fresh one.

Edit: even with a fresh NodeMCU the problem stays....

[tonhuisman]

even with a fresh NodeMCU the problem stays....

So, the problem is with the DHT22... meaning that adding timing configuration to the plugin could help in fine-tuning this particular sensor. This has been discussed before, see #691 and #2745, where the proposed solution is to add fine-grained timing settings to help in adjusting for 'timing-sensitive' sensors. That hasn't been picked up yet, AFAICS.

[TD-er]

The timingstats have to be enabled in the tools->Advanced page. After each reload of the timing stats page, the statistics are reset.

[wdonker]

Ok, here's the timing stats of 20220427:

and the stats of 20220328:

[TD-er]

I think you should let them run for a bit longer, as the run on the March build didn't even have a single call to PLUGIN_READ for the OLED display and the top one only got 1 call to that function.

What does look 'odd' is that the READ call for the DHT plugin on the March build took longer than the longest one on the April build. But it is hard to base it on only a single call to that function on the March build.

[wdonker]

Ok, here's timing stats for a longer period:

[TD-er]

And that's the timing stats of the one that fails, or the 20220328 build?

[wdonker]

Sorry, it is of the failing unit with 20220427 build.

[TD-er]

Do you also have one from a running build, so we can clearly see the differences on the READ call for this plugin? You did show one before which did run at least for a single call to this function, which took significantly longer to read the sensor. Also I don't see any alarming blocking code in your last timing stats on the failing code.

So we have to check on what may have changed in this build, but the strange part is that the code for that plugin has not changed since Feb.

[wdonker]

Sorry, that will have to wait since I do not have access to the unit for about a month.

[TD-er]

Well I don't think it will matter much. We may have to look in seemingly unrelated code. Like I said, the code of that plugin was not changed.

[toast1234]

Hi, just browsing and saw this issue. I did noticed the exact same on the builds mentioned. E.g. DHT22 stop working on latest build. However it is not always as I have more than 1 setup with DHT22 and not all stopped working. I will see if i can bring some update when in front of a computer.

[TD-er]

That may suggest the timings of this sensor are awfully critical. I think I have to take a closer look at it using a logic analyzer (and datasheet), like I did for the Dallas sensors.

[toast1234]

Honestly, these are very old installations. The one that stopped working is the oldest. So wemos is maybe 10+ years old and also the DHT22 (not even sure, it can be an AM23xx). As you see the one that has to run the older release to work also have DS18B20. ESP Chip ID: 9390471 (0x8F4987) # ESP_Easy_mega_20220328_normal_ESP8266_4M1M ESP Chip ID: 1648092 (0x1925DC) # ESP_Easy_mega_20220427_normal_ESP8266_4M1M

[TD-er]

Well, since now 2 users have confirmed the sensor is no longer working when changing from 20220328 and 20220427, I don't think the age of the sensors will be playing a role here. And to be honest, those older ESP boards seem to have less issues (at least regarding WiFi) compared to later boards as those often have poor designed voltage regulators and/or bad designed PCB antennas. So I do prefer those older boards myself.

[mannema]

I had the same issue with a DHT11 on a NodeMCU-ESP8266-V2-4MB version. The sensor is working on 20220328 but not working on 20220427 anymore.

[TD-er]

Which exact build/bin file are you using for the april build?

[mannema]

I was using this one: ESP_Easy_mega_20220427_normal_ESP8266_4M1M.bin

[TD-er]

Hmm that one is still using core_2_7_4 I thought it might have something to do with using core 3.0.x, but apparently not.

[mariolazarov]

Here is same DHT11 on ESP-1s whit normal built 1M

[freeesty]

same with lates build and dht22. was working with ESP_Easy_mega_20220328_energy_ESP32_4M316k.bin

[TD-er]

See also reported issue on the forum

[TD-er]

Found the (very likely) cause for this as it is almost certainly the same reason why Dallas 1wire plugins no longer worked on ESP32 in the last build.

It will be fixed when this issue will be fixed: https://github.com/letscontrolit/ESPEasy/issues/4165

[TD-er]

Can anyone here please test this PR: https://github.com/letscontrolit/ESPEasy/pull/4166

GitHub Actions build (must be logged in to download the Binaries ZIP file)

N.B. I have not yet tested it myself with any DHT module as right now I cannot find any to test with. Will have another look tomorrow morning as I'm sure I must have some.... somewhere.

[toast1234]

I tested on a board with one DHT22 and one DHT11:

Upgrade to - ESP_Easy_mega_20220730_normal_ESP8266_4M1M.bin - No values for DHT22 or DHT11. DS18B20 is working

Rollback to - ESP_Easy_mega_20220616_normal_ESP8266_4M1M.bin - Working with all 3 sensors

Repeated twice with same result.

[TD-er]

OK, thanks. Back to the drawing board, or at least I now have to really find those DHT modules and hook them up to the logic analyzer.

Do you happen to have some ultrasonic distance units laying around? Those should also be "acting different" (I almost wrote "fixed" ....) as the intended code change was to make them show less jitter.

[toast1234]

Nooe, sorry, not really anything but temp sensors.

[TD-er]

Great! So you're my tester for when I fixed this DHT stuff :)

Now I really got to start digging for these sensors as it is apparently not enough to model whats happening in my head.

[TD-er]

By the way, do you see anything in the logs?

[TD-er]

Added a delay to it right after waking the sensor. This test build is related to that change.

[toast1234]

Only on mobile for the day. But did a quick load of the newer build. Still the same. No values for dht.

[TD-er]

When this GitHub Actions build is finished, can you try again?

I am now very confident it will work :)

And if not, please show the debug log. Something like this:

194866 : Debug  : DHT  : Avg Low: 54.00 usec 5 bytes: 0x1 0xFC 0x1 0x9 0x7 timings: 65 27 55 27 55 27 54 26 55 27 55 74 54 75 54 73
194870 : Info   : DHT  : Temperature: 26.50
194873 : Info   : DHT  : Humidity: 50.80
196865 : Debug  : DHT  : Avg Low: 54.00 usec 5 bytes: 0x1 0xF5 0x1 0x9 0x0 timings: 65 26 54 27 55 27 55 27 55 27 55 27 55 27 54 26
196870 : Info   : DHT  : Temperature: 26.50
196873 : Info   : DHT  : Humidity: 50.10
198866 : Debug  : DHT  : Avg Low: 54.00 usec 5 bytes: 0x1 0xF7 0x1 0x9 0x2 timings: 66 27 54 26 55 27 55 27 54 26 54 27 56 73 55 28

The timing values are in usec of the last byte of the stream. 54 usec average low duration is perfectly fine according to the DHT22 datasheet. Low values of 26 and high values of 72 usec are also perfect. The first one (byte separator) of 67-ish usec is also according to specs.

Here the main problem:

White line: Signal on DHT22 pin Brown line: Signal on debug pin for me to keep track of what was happening in the ESP32.

That pulse of 227 usec was during debugging, where I set another pin high when starting to call pinMode(INPUT_PULLUP) and low right after that was finished. As you can see, the first 80 usec "low" signal of the DHT to indicate it was there, was completely lost. (not always) Ton also tested on his module and the same code did work on his (official) DHT22 module. But on mine it wasn't working.

So, now I am using direct GPIO calls to set the pinMode to input, which takes between 4 and 8 usec.

Now I am quite confident this DHT code will be quite resilliant for many of these modules. But please test with the cheapest garbage modules you can find :)

[toast1234]

Yes, tested on 5 different units and all DHT devices are working! :-)

[TD-er]

Great!

[tonhuisman]

Tested with DHT22 on multiple ESP32 revisions and on an ESP32s2. All working without any issue so far.

[TD-er]

The original report was done on an ESP8266, so that still needs to be tested too.

[toast1234]

Mine are all on wemos 8266

[TD-er]

Great! So now I only need to test the ultrasonic units before merging that PR. With that done, I only need some confirmation on the AP issue working again and then we can make a new build :)

[tonhuisman]

Now also tested on ESP8266, and working as intended. Also tried on an ESP32 using GPIO 12, but that is a pin to avoid, it seems (has the warning icon in the GPIO selector, like GPIO 0, 2 and 15), works fine on other pins.

[TD-er]

GPIO-12 is rather tricky as its state during boot indicates the flash voltage. So depending on the module it must be low or high during boot or else the module may not run stable due to low flash voltage, or fry your flash chip. Since the DHT needs a pull-up resistor, this is really tricky.

I think I will add a plugin device flag to indicate whether a plugin needs a pull-up resistor and then not list the GPIO-12 pin as a possible option to choose as input pin. Or maybe even make it impossible to pick as an input pin at all. Have to check if ESP32-S2 has the same.

[tonhuisman]

On ESP32-S2 GPIO 12 doesn't have a warning icon, and works as intended with the DHT22.

ESP32-S2 has other GPIO pins with warnings, so that's already properly taken care of 😃