Tasmota 8.1.0.7: DHT11 Temp =NULL & Humid = NULL

[adharyanto]

PROBLEM DESCRIPTION

_A clear and concise description of what the problem is._

After upgrade OTA from 8.1.0.6 to 8.1.0.7, the DHT11 sensor gives Temp = NULL deg C, and Humidity = NULL %. I know that to use the old sensor must insert USE_DHT_OLD, but the problem; this insertion can not be done remotely (OTA).... need to go to the site, open the esp8266 compartment and flash manually... I am thinking that this additional (USE_DHT_OLD) should be done remotely (OTA) as well, no need to flash manually...

REQUESTED INFORMATION

_Make sure your have performed every step and checked the applicable boxes before submitting your issue. Thank you!_

• [ ] Read the Contributing Guide and Policy and the Code of Conduct
• [ ] Searched the problem in issues
• [ ] Searched the problem in the docs
• [ ] Searched the problem in the forum
• [ ] Searched the problem in the chat
• [ ] Device used (e.g., Sonoff Basic): Sonoff Basic_____
• [ ] Tasmota binary firmware version number used: 8.1.0.7_____
  
  
  
  • [ ] Pre-compiled
  
  
  • [ ] Self-compiled
  
  
  • [ ] IDE / Compiler used: OTA_____
  
  
• [ ] Flashing tools used: OTA_____
• [ ] Provide the output of command: Backlog Template; Module; GPIO 255:

  Configuration output here:

• [ ] If using rules, provide the output of this command: Backlog Rule1; Rule2; Rule3:

  Rules output here:

• [ ] Provide the output of this command: Status 0:

  STATUS 0 output here:
13:12:16 CMD: status 0
13:12:16 MQT: PintuGerbang/stat/STATUS = {"Status":{"Module":18,"FriendlyName":["Pintu Gerbang","Sonoff2","Sonoff3","Sonoff4"],"Topic":"PintuGerbang","ButtonTopic":"0","Power":0,"PowerOnState":3,"LedState":1,"LedMask":"FFFF","SaveData":1,"SaveState":1,"SwitchTopic":"0","SwitchMode":[0,0,0,0,0,0,0,0],"ButtonRetain":0,"SwitchRetain":0,"SensorRetain":0,"PowerRetain":0}}
13:12:16 MQT: PintuGerbang/stat/STATUS1 = {"StatusPRM":{"Baudrate":115200,"SerialConfig":"5N1","GroupTopic":"sonoffs","OtaUrl":"http://thehackbox.org/tasmota/tasmota-minimal.bin","RestartReason":"Software/System restart","Uptime":"0T00:09:49","StartupUTC":"2020-02-11T06:02:27","Sleep":50,"CfgHolder":4617,"BootCount":799,"BCResetTime":"2020-02-11T10:45:45","SaveCount":23005,"SaveAddress":"F9000"}}
13:12:16 MQT: PintuGerbang/stat/STATUS2 = {"StatusFWR":{"Version":"8.1.0.7(9814468-tasmota)","BuildDateTime":"2020-02-10T23:00:10","Boot":5,"Core":"2_6_1","SDK":"2.2.2-dev(38a443e)","Hardware":"ESP8266EX","CR":"338/699"}}
13:12:16 MQT: PintuGerbang/stat/STATUS3 = {"StatusLOG":{"SerialLog":2,"WebLog":2,"MqttLog":0,"SysLog":0,"LogHost":"domus1","LogPort":514,"SSId":["omahklodran_plus",""],"TelePeriod":10,"Resolution":"558180C0","SetOption":["54000009","2805C8000100060000005A00000000000000","00000000","00000000"]}}
13:12:16 MQT: PintuGerbang/stat/STATUS4 = {"StatusMEM":{"ProgramSize":569,"Free":432,"Heap":25,"ProgramFlashSize":1024,"FlashSize":1024,"FlashChipId":"14405E","FlashMode":3,"Features":["00000809","8FDAE397","043683A0","22B617CD","01001BC0","00007881","00000000"],"Drivers":"1,2,3,4,5,6,7,8,9,10,12,16,18,19,20,21,22,24,26,29","Sensors":"1,2,3,4,5,6,7,8,9,10,14,15,17,18,20,22,26,34"}}
13:12:16 MQT: PintuGerbang/stat/STATUS5 = {"StatusNET":{"Hostname":"PintuGerbang-2709","IPAddress":"192.168.1.9","Gateway":"192.168.1.1","Subnetmask":"255.255.255.0","DNSServer":"118.98.44.100","Mac":"5C:CF:7F:79:EA:95","Webserver":2,"WifiConfig":2,"WifiPower":0.0}}
13:12:16 MQT: PintuGerbang/stat/STATUS6 = {"StatusMQT":{"MqttHost":"192.168.1.5","MqttPort":1883,"MqttClientMask":"DVES_%06X","MqttClient":"DVES_79EA95","MqttUser":"aspi","MqttCount":1,"MAX_PACKET_SIZE":1000,"KEEPALIVE":30}}
13:12:16 MQT: PintuGerbang/stat/STATUS7 = {"StatusTIM":{"UTC":"Tue Feb 11 06:12:16 2020","Local":"Tue Feb 11 13:12:16 2020","StartDST":"Sun Jan 26 00:00:00 2020","EndDST":"Sun Jan 26 00:00:00 2020","Timezone":99,"Sunrise":"14:05","Sunset":"00:03"}}
13:12:16 MQT: PintuGerbang/stat/STATUS10 = {"StatusSNS":{"Time":"2020-02-11T13:12:16","DHT11":{"Temperature":null,"Humidity":null},"TempUnit":"C"}}
13:12:16 MQT: PintuGerbang/stat/STATUS11 = {"StatusSTS":{"Time":"2020-02-11T13:12:16","Uptime":"0T00:09:49","UptimeSec":589,"Heap":25,"SleepMode":"Dynamic","Sleep":50,"LoadAvg":19,"MqttCount":1,"POWER1":"OFF","POWER2":"OFF","POWER3":"OFF","POWER4":"OFF","Wifi":{"AP":1,"SSId":"omahklodran_plus","BSSId":"50:64:2B:27:A7:77","Channel":9,"RSSI":80,"Signal":-60,"LinkCount":1,"Downtime":"0T00:00:06"}}}
13:12:20 MQT: PintuGerbang/tele/STATE = {"Time":"2020-02-11T13:12:20","Uptime":"0T00:09:53","UptimeSec":593,"Heap":27,"SleepMode":"Dynamic","Sleep":50,"LoadAvg":19,"MqttCount":1,"POWER1":"OFF","POWER2":"OFF","POWER3":"OFF","POWER4":"OFF","Wifi":{"AP":1,"SSId":"omahklodran_plus","BSSId":"50:64:2B:27:A7:77","Channel":9,"RSSI":82,"Signal":-59,"LinkCount":1,"Downtime":"0T00:00:06"}}
13:12:20 MQT: PintuGerbang/tele/SENSOR = {"Time":"2020-02-11T13:12:20","DHT11":{"Temperature":null,"Humidity":null},"TempUnit":"C"}

• [ ] Provide the output of the Console log output when you experience your issue; if applicable:
  _(Please use_ weblog 4 _for more debug information)_

  Console output here:

TO REPRODUCE

_Steps to reproduce the behavior:_

EXPECTED BEHAVIOUR

_A clear and concise description of what you expected to happen._

SCREENSHOTS

_If applicable, add screenshots to help explain your problem._

ADDITIONAL CONTEXT

_Add any other context about the problem here._

(Please, remember to close the issue when the problem has been addressed)

[Jason2866]

You can flash a firmware with the needed driver via OTA. Easiest ist to go back to the version before.
The main reason for jump to 8.1.0.7 was the optimized DHT drivers.
Just OTA this file: http://thehackbox.org/tasmota/archive/20200210-180027-7d0577e-tasmota.bin

[adharyanto]

Hallo,

Thanks for the info…

I tried to update again via OTA Url = http://thehackbox.org/tasmota/archive/20200210-180027-7d0577e-tasmota.bin

But after restarting, it keeps on version 8.1.0.7, (not reverted back to 8.1.0.6) ….. and the DHT11 Temp & Humid still = NULL

Regards,

Antonius

From: Jason2866 [mailto:[email protected]]
Sent: Tuesday, 11 February, 2020 04:39 PM
To: arendst/Tasmota
Cc: adharyanto; Author
Subject: Re: [arendst/Tasmota] Tasmota 8.1.0.7: DHT11 Temp =NULL & Humid = NULL (#7717)

You can flash a firmware with the needed driver via OTA. Easiest ist to go back to the version before.
The main reason for jump to 8.1.0.7 was the optimized DHT drivers.
Just OTA this file: http://thehackbox.org/tasmota/archive/20200210-180027-7d0577e-tasmota.bin

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub https://github.com/arendst/Tasmota/issues/7717?email_source=notifications&email_token=ALLUYK7RSWTML5QYUTICYFTRCJW2HA5CNFSM4KS263T2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOELLX6JI#issuecomment-584548133 , or unsubscribe https://github.com/notifications/unsubscribe-auth/ALLUYK4OCURJMHAKJTL7RBDRCJW2HANCNFSM4KS263TQ .

[schrej-zz]

Hi,
I have an error, that might be related to this.
I also flashed 8.1.0.7.
My DHT22 sent Temp and Humidity for about 12h. Afterwards the return value of both was empty.
(Not NULL, as seen before with older versions).
Additionally, as a difference to former versions, this can be solved by restarting the device.
In older versions, I had to cut power off from DHT.

[ascillato2]

@adharyanto @schrej-zz

Going back to 8.1.0.6 solves your issue?

[adharyanto]

In order to flash back to 8.1.0.6, I have to dismantle the device, open the compartment, and flash manually the esp8266, which is a bit complicated, and I try to avoid this.

I need to do this OTA, but the link given by Jason2866 (http://thehackbox.org/tasmota/archive/20200210-180027-7d0577e-tasmota.bin) did not work, it keeps on version 8.1.0.7 after restarting, and the issue is still there…

If you have some other ways to flash back to 8.1.0.6, (= via OTA =), please inform me….and I will try again…

[schrej-zz]

Just OTA with a tasmota-minimal.bin and then try the bins in http://thehackbox.org/tasmota/archive/ from most recent to older until the issue vanishes.

[adharyanto]

First I tried to update:

• http://thehackbox.org/tasmota/tasmota-minimal.bin

then I choose one of the archive (20200207):

• http://thehackbox.org/tasmota/archive/20200207-140026-1a074da-tasmota.bin

It works, and it switches back to 8.1.0.6, and the Temperature & Humidity are back to normal value, (not NULL).

Fyi; I tried also version 8.1.0.8, the result is the same as 8.1.0.7, Temp & Humid = NULL, so I will have to use the 8.1.0.6.

Thanks.

[ascillato2]

@adharyanto @schrej-zz

Going back to 8.1.0.6 have solved your issue? We need more information so as to properly address this issue.

So far, all my DHTs works very reliable no matter if I use the new or the old driver. I have one of those outside at direct sunlight with a small roof for rain protection with half meter wires and connected to a nodemcu and this one with a harsh environment have never failed in 2 years. With the new driver it still works fine without hunging. So, are you sure that your DHT has enough power and proper wiring?

[ascillato2]

It works, and it switches back to 8.1.0.6, and the Temperature & Humidity are back to normal value

Ok. Thanks for testing :+1:

[ascillato2]

@KrzysztofPrzygoda

What do you think? What can be the issue with the new driver?
So far we have some DHT that needs the old driver, some others that needs the new driver and some others that works with any driver.

[adharyanto]

Further testing on the archives:

http://thehackbox.org/tasmota/archive/20200210-190030-7339b56-tasmota.bin === (null value = v8.1.0.7)

http://thehackbox.org/tasmota/archive/20200210-180027-7d0577e-tasmota.bin === (null value = v8.1.0.7)

http://thehackbox.org/tasmota/archive/20200210-170025-edadaa2-tasmota.bin === (normal value = v8.1.0.7)

http://thehackbox.org/tasmota/archive/20200207-140026-1a074da-tasmota.bin === (normal value = v8.1.0.6)

So, in my case I can use v8.1.0.6 (any version) OR v8.1.0.7 with specific this version = (20200210-170025-edadaa2) but not the newer…

From: Adrian Scillato [mailto:[email protected]]
Sent: Thursday, 13 February, 2020 06:39 AM
To: arendst/Tasmota
Cc: adharyanto; Mention
Subject: Re: [arendst/Tasmota] Tasmota 8.1.0.7: DHT11 Temp =NULL & Humid = NULL (#7717)

@KrzysztofPrzygoda https://github.com/KrzysztofPrzygoda

What do you think? What can be the issue with the new driver?
So far we have some DHT that needs the old driver, some others that needs the new driver and some others that works with any driver.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub https://github.com/arendst/Tasmota/issues/7717?email_source=notifications&email_token=ALLUYK47A5U4DIE67UNZWOTRCSCB3A5CNFSM4KS263T2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOELSZ5FA#issuecomment-585473684 , or unsubscribe https://github.com/notifications/unsubscribe-auth/ALLUYK4X5OACACN22UQ3HODRCSCB3ANCNFSM4KS263TQ .

[PabloVogel]

Sorry for introducing this subject again, but i would like to propose eliminating the high digital writes from the driver. As I explained a high is sustained by the pull up resistor, so the sensor and the esp only asserts low.

The change is very simple the pin is always in input_pull and when a low is required you do pinmode digital write and pinmode again. The dhtprep method is empty because the pin is allways in input pullup.

But I don't know what will happen with other setups. So I think this is a good opportunity to implement this in the new driver.

I've modified the 8.1.0 with those changes and so far so good. What worked before work now and what not still don't

BTW this change is important because it prevents a potentially dangerous situation when the esp output high and dht causing overcurrent. With the the new implementation this is harmless. Both ESPeasy and adafruit don't asserts highs.

[ascillato]

@PabloVogel If you have implemented that change, please do a PR for review.

[arendst]

Pls try lates dev where the DHT driver has been replaced by the ESPEasy version.

Great fun!!!

[ascillato]

So far, this fourth version of the DHT driver also works fine in my devices.

We need the confirmation from the people that have issues with these devices:

@PabloVogel
@adharyanto
@KrzysztofPrzygoda
@schrej-zz
@klaus-pittisch
@kiwichrish
@Magnus-rosenborg
@dcbo
@Dreamoffice
@DasUrmel
@DarthKegRaider
@retroip
@johination

that this new driver in latest Tasmota (http://thehackbox.org/tasmota/) is working fine for them, in order to deprecate older drivers.

[klaus-pittisch]

testing ..... 10x Am2301 with 8.1.0.8

[PabloVogel]

no issues with new driver

[adharyanto]

V8.1.0.8 works fine on my DHT11 device, no issues…

Thank you…

[klaus-pittisch]

11 hours, 10 sensors, no issues

Thank you

[OptimusGREEN]

8.1.0.8 still says null for a dht11 that I have

[arendst]

@OptimusGREEN did it ever work?

Check your hardware connections and verify if it's a DHT11 after all.

[PabloVogel]

Wich is the candidate for the release? V4 or V3?. I find V3 much more clearer.

[arendst]

V4 is a lot smaller while providing the same functionality. So V4 it is.

[OptimusGREEN]

@OptimusGREEN did it ever work?

Check your hardware connections and verify if it's a DHT11 after all.

Hi, yes it was working last night on whatever previous version I had. When I woke up this morning it said null and that's when I came across this issue so figured I'd update to the mentioned version in hope that it would fix the problem.

[ascillato]

When I woke up this morning it said null and that's when I came across this issue so figured I'd update...

@OptimusGREEN So, your DHT11 was not working before the update right?

[OptimusGREEN]

@OptimusGREEN So, your DHT11 was not working before the update right?

That's right. It was working then it wasn't so I updated.

[ascillato]

So, may be is not the new driver but a problem in your DHT11. Have you recheched wirings and power supply?

[OptimusGREEN]

not, yet as im out but the wiring hasnt been touched since it was working. I'll get a look once I'm home thanks.

[PabloVogel]

I would like to propose a little tidy up for the v4. As you want to condense the ESPeasy code in one function the problem is breaking out two levels of _for_ loops for which C lacks the appropriates control statements. As K&R said

Nevertheless, there are a few situations where gotos may find a place. The most common is to abandon processing in some deeply nested structure, such as breaking out of two or more loops at once. The break statement cannot be used directly since it only exits from the innermost loop.

```
noInterrupts();
if (!DhtExpectPulse(sensor, LOW) ||
!DhtExpectPulse(sensor, HIGH) ||
!DhtExpectPulse(sensor, LOW)) {
goto DHT_READ_ERROR;
}

for (uint32_t i = 0; i < 5; i++) {
int data=0;
for (uint32_t j = 0; j < 8; j++) {
if (!DhtExpectPulse(sensor, HIGH)) goto DHT_READ_ERROR;
delayMicroseconds(35); // Was 30
if (digitalRead(Dht[sensor].pin)) {
data |= (1 << (7 - j));
}
if (!DhtExpectPulse(sensor, LOW)) goto DHT_READ_ERROR;
}
dht_data[i] = data;
}
interrupts();

checksum = (dht_data[0] + dht_data[1] + dht_data[2] + dht_data[3]) & 0xFF;
if (dht_data[4] != checksum) {
char hex_char[15];
AddLog_P2(LOG_LEVEL_DEBUG, PSTR(D_LOG_DHT D_CHECKSUM_FAILURE " %s =? %02X"),
ToHex_P(dht_data, 5, hex_char, sizeof(hex_char), ' '), checksum);
return false;
}

return true;

DHT_READ_ERROR:
interrupts();
return false;
}
```

The AddLog_P2(LOG_LEVEL_DEBUG, PSTR(D_LOG_DHT D_TIMEOUT_WAITING_FOR " %s " D_PULSE), level ? D_START_SIGNAL_HIGH : D_START_SIGNAL_LOW); is mvoed inside DhtExpectPulse

[arendst]

Thx for your opinion but:

• The current double break works as expected.
• I hate gotos
• Doing the AddLog within DhtExpectPulse extends the time interrupts are disabled. AddLog could take quite a long time if all debug options are enabled.

So again, I think it stays this way.

[PabloVogel]

I respect your preferences but the DhtExpectPulse would not extend the time because addlog is inside an if statement and is only executed on the event of timeout.

    if (micros() > timeout) {
       AddLog_P2(LOG_LEVEL_DEBUG, PSTR(D_LOG_DHT D_TIMEOUT_WAITING_FOR " %s " D_PULSE), level ? D_START_SIGNAL_HIGH : D_START_SIGNAL_LOW);
       return false;
    }

That allows the change form

 level = 0;
 if (!DhtExpectPulse(sensor, level)) { break; }  // Expect LOW

to

 if (!DhtExpectPulse(sensor, LOW)) { break; }  

May I propose another version with breaks and no goto?

[arendst]

Make my day.

[PabloVogel]

It really is the same but as I did promise, here it is.

  bool error=false;
  noInterrupts();
  if (!DhtExpectPulse(sensor, LOW) &&
      !DhtExpectPulse(sensor, HIGH) &&
      !DhtExpectPulse(sensor, LOW)) {

    int data=0;
    for (uint32_t i = 0; i < 5; i++) {
      for (uint32_t j = 0; j < 8; j++) {
        if (!DhtExpectPulse(sensor, HIGH)) {
          error=true;
          break;
        }
        delayMicroseconds(35);                          // Was 30
        if (digitalRead(Dht[sensor].pin)) {
          data |= (1 << (7 - j));
        }
        if (!DhtExpectPulse(sensor, LOW)) {
          error=true;
          break;
        }
      }
      if (error) break;
      dht_data[i] = data;
    }
  }
  interrupts();

  if (error)
    return false;

It compiles but it's not tested as it doesn't really changes anything.

[klaus-pittisch]

2 of 10 DHT22 report NULL after 1 day
:(
shit

[sentiment-bot[bot]]

Please be sure to review the code of conduct and be respectful of other users.
Keep in mind, this repository uses the Contributor Covenant.

[klaus-pittisch]

[mike2nl]

Another thing which came up while i tested now the v4 dht driver.
I have a lot of DHT11 and 22 sensors because some older projects which are no longer used, but testing the whole thing was to now the things in the new driver.

What came is with older or hard used sensors (outside use) the the values can get higher then 100% rel. humidity. I had 2 sensors from 15 (yes 15) which gave me 104 and 106. I see we have the check for:
if ((NAN == Dht[sensor].h)

But not for the overshot. Checked some libraries for the DHT sensors and found that some make use of that check. Tested them with an wemos d1 mini and yes the mas values showed was 100. But that is not really a good way. Better would be another type of value. The NAN doesn't show the overshot. What could be done for Tasmota to check this and show it on the web ui, or in jason to message the user that the sensor must be refreshed or use a new one.

Refresh a sensor is not that complicated but with tha costs for that type of sensor we don't need to do it. More for the BME280 and BME680. Working on a document which describe's it.

[arendst]

For those getting NULL reports pls use the latest commit and enable more logging with option 3 and monitor DHT messages like:

12:51:29 DHT: Timeout waiting for start signal low pulse
12:51:29 DHT: Timeout waiting for start signal high pulse
12:51:29 DHT: Invalid NAN reading
12:51:29 DHT: Checksum failure 01 41 41 D7 DF =? 5A

[OptimusGREEN]

ok so my issue turned out to be the fact i was using gpio2 i think. I've switched to gpio3 and all is good.

[schrej-zz]

First feedback:
Config: AM2301on GPIO3
Got regular "Timeout waiting for start signal high pulse"
After end of serial logging, I got
"Timeout waiting for start signal low pulse"
once.
None of these messages afterwards up to now.

[kiwichrish]

Put this on four test setups, 24hr run time and fine with AM2302's on:

• ESP-01 on GPIO2
• Wemosd1 GPIO2 and GPIO14

With Aosong branded AM2302 survives multiple restarts (timer relay on reset, resetting it every 15 mins for the last day on both the EPS-01 and WemosD1).

Issue with Asair branded AM2302 is still there, but that's nothing to do with Tasmota / firmware it's the ESP POST serial output crashing the sensor. Per some other comments, don't use GPIO0/2 if you want these sensors 100% reliable.

DHT11 on ESP01/GPIO2 fine for a day as well.

[PabloVogel]

The biggest change in the new driver was the remotion of all digitalWrite(Dht[i].pin, HIGH); statements. Here is a thread on the topic https://forum.arduino.cc/index.php?topic=377413.0.

The data line is half duplex so collisions may occur and output mismatch between MCU and sensor not only can hang the device but also may destroy it or burn a gpio,

The protocol is really simple. The resistor pull-up maintains 3.3 V on the data line, indicating idle status. When the ESP wants a reading it output a single 0V pulse and waits , then the DHT acknowledges (another single low pulse) and report the data.

[PabloVogel]

Sorry to bother again, but after removing the sensor from a sonoff I found the device is still reporting the last value instead of nan, but the logs show that the read fails. Im using 8.1.0.8

18:18:32 DHT: Timeout waiting for start signal low pulse

It seems that the early exit in V5 prevents the code from updating the values

  interrupts();
  if (error) { return false; }

checking V4 the code that updates the readings was in DhtReadTempHum which was merged in DhtRead.

So V4 is safe.

[kiwichrish]

Just noticed there's multiple versions talked about.. My testing was 8.1.0.8, using dht_4 complied using the arduino IDE, really should get with the cool kids and use platformio, but too many projects in the arduino IDE I'm working on. :-)

[PabloVogel]

After revisiting V5 I found that the "==" operator cannot be used against NAN, the correct way to do that is by using the insnan() function. I think the section can be eliminated altogether.
If the section is not removed DHTSTRUCT.lastresult must be initalized. The original driver did that.

If you eliminate the max retry counter section the and initalize at the beginning Dht[sensor].t= NAN;Dht[sensor].h= NAN you can keep the code as is.

When a timeout occurs, if another log line is added then the timeout message is lost (PrepLog_P2 ). For example if there is a timeout then isnan is always true so I eliminated that log line (not very good)

Here is what I have and it's working. It preserves the max retries logic
I connected the power of a DHT22 to a Gpio configured as relay. So I can turn the sensor on and off remotely

Sorry I don't have a forked repo yet, this code goes after interrupts()

  float temperature = NAN;
  float humidity = NAN;
  if (!error) {
    uint8_t checksum = (dht_data[0] + dht_data[1] + dht_data[2] + dht_data[3]) & 0xFF;
    if (dht_data[4] == checksum) {
      switch (Dht[sensor].type) {
        case GPIO_DHT11:
          humidity = dht_data[0];
          temperature = dht_data[2] + ((float)dht_data[3] * 0.1f);  // Issue #3164
          break;
        case GPIO_DHT22:
        case GPIO_SI7021:
          humidity = ((dht_data[0] << 8) | dht_data[1]) * 0.1;
          temperature = (((dht_data[2] & 0x7F) << 8 ) | dht_data[3]) * 0.1;
          if (dht_data[2] & 0x80) {
            temperature *= -1;
          }
          break;
      }
    }
    else { //Checksum error
      char hex_char[15];
      AddLog_P2(LOG_LEVEL_DEBUG, PSTR(D_LOG_DHT D_CHECKSUM_FAILURE " %s =? %02X"),
        ToHex_P(dht_data, 5, hex_char, sizeof(hex_char), ' '), checksum);
    }
  } //error

  if (isnan(humidity)) { //Both t and h are numbers or not
    Dht[sensor].lastresult++;
    if (Dht[sensor].lastresult > DHT_MAX_RETRY) {  // Reset after 8 misses
      Dht[sensor].t = NAN;
      Dht[sensor].h = NAN;
    }
    return false;
  }

  if (humidity > 100) { humidity = 100.0; }
  if (humidity < 0) { humidity = 0.1; }
  Dht[sensor].h = ConvertHumidity(humidity);
  Dht[sensor].t = ConvertTemp(temperature);
  Dht[sensor].lastresult = 0;

  return true;
}

[arendst]

Thx. I also found out the lastresult code was failing.

As most of the time I did it my way in the latest commit ;-)

[PabloVogel]

After analyze the code I noticed that when you go input immediately after the low pulse you don't need that tricky delay(50) that has been subject to so much tweaking.

The original version used a digitalWrite(pin,HIGH) so you weren't able to detect the start of the ACK, thus forced to a blind delay

But now you can use an active expectPulse to wait the ACK to begin.

You do

 pinMode(Dht[sensor].pin, INPUT_PULLUP);
  if (!ExpectPulse(Dht[sensor].pin, HIGH)) { //Waiting for ACK
    AddLog_P(LOG_LEVEL_DEBUG, PSTR(D_LOG_DHT "Timeout waiting for DHT ACK"));
    return false;
  }

Instead of

 pinMode(Dht[sensor].pin, INPUT_PULLUP);
  switch (Dht[sensor].type) {
    case GPIO_DHT11:                                    // DHT11
    case GPIO_DHT22:                                    // DHT21, DHT22, AM2301, AM2302, AM2321
      delayMicroseconds(50);
      break;
    case GPIO_SI7021:                                   // iTead SI7021
      delayMicroseconds(20);                            // See: https://github.com/letscontrolit/ESPEasy/issues/1798
      break;
  }

And I also believe by that very reason the adafruit code from the old driver is better than the ESPeasy because it doesn't contain fixed waits.

  for (uint32_t i = 0; i < 80; i += 2) {
    cycles[i]   = ExpectPulse(Dht[sensor].pin, LOW);
    cycles[i+1] = ExpectPulse(Dht[sensor].pin, HIGH);
  }

I'm testing this new implementation and so far no errors.

So the protocol looks like that (with better logging) and only one hard wait (Necesary as is an output)

 if (digitalRead(Dht[sensor].pin) != IDLE) {
    AddLog_P(LOG_LEVEL_DEBUG, PSTR(D_LOG_DHT "Data line BUSY skipping read"));
    return false;
  }

  //One big fat pulse to request for data
  pinMode(Dht[sensor].pin, OUTPUT);
  digitalWrite(Dht[sensor].pin, LOW);
  delay(20);
  pinMode(Dht[sensor].pin, INPUT_PULLUP);

  //Perhaps a little delay here? A pair of microsec.

  if (!ExpectPulse(Dht[sensor].pin, HIGH)) { //Waiting for ACK
    AddLog_P(LOG_LEVEL_DEBUG, PSTR(D_LOG_DHT "Timeout waiting for DHT ACK"));
    return false;
  }

  if (!ExpectPulse(Dht[sensor].pin, LOW)) { //In the ACK
    AddLog_P(LOG_LEVEL_DEBUG, PSTR(D_LOG_DHT "DHT ACK too long"));
    return false;
  }

  if (!ExpectPulse(Dht[sensor].pin, HIGH)) { //Waiting for response
    AddLog_P(LOG_LEVEL_DEBUG, PSTR(D_LOG_DHT "Timeout waiting for Data transmission"));
    return false;
  }

  noInterrupts();
  for (uint32_t i = 0; i < 80; i += 2) {
    cycles[i]   = ExpectPulse(Dht[sensor].pin, LOW);
    cycles[i+1] = ExpectPulse(Dht[sensor].pin, HIGH);
  }
  interrupts();

As you know the request signal is theoretically not time dependent as the specs say "at least", meaning you ring the doorbell for long enough.

Interrupts are disabled very late, but it hasn't failed (yet) in my setup.

The logging is more useful because if you only get "Timeout waiting for DHT ACK" you know the sensor is hung.

You may have noticed that expectPulse don't return timeout, that is because I think it has two failure case.

• When the signal is not at the expected level at the start, your are either too late or too early. In this case count will be 0.

• Of course the timeout,

So I settle for 0 for error for both cases

int32_t ExpectPulse(uint8_t pin, bool level)
{
  uint32_t count = 0;
  for (uint32_t count=0; count < dht_max_cycles; count++) {
    if (digitalRead(pin) != level) {
      return count; //If count ==  0 then pulse is missing
    }
  }
  return 0; // Timeout
}

[EvilForge]

FYI - been lurking watching this thread and others regarding DHT sensors. Up to v8.1.0.2 I was having NULL after several hours on a self-compiled (arduino IDE) wemos D1 mini with the newer small blue sensor. One was in a greenhouse, the other the attic. Its winter so temps are cool (28 to 75F) here. Humidity ranges from 20-100%. I have tried pull-up resistors on one device with no improvement. The greenhouse is sensor only (analog light, DHT), and the Attic is a DHT and analog voltage sense for a doorbell circuit. Neither control a switch/relay.

For 2 days fw8.1.0.8 is still returning data with no issues. Hassio history graphs show no data dropouts at night when I'd miss seeing it.

I do have another outside sensor (same design, my DIY esp8266 wemos mini with a DHT sensor) as the two misbehaving, that has never failed. All sensors were from the same pack, but the esp's are varied sources (Banggood, Amazon, Ebay).

Anyhow, thanks again to all for helping resolve this. If you need any other data, I can try to get it for you, or even flash backwards if it will help put this one to rest. I have enjoyed Tasmota a lot, and I don't mind giving back some data. :)

[PabloVogel]

For what is worth, I was incorrect about the request timing, it is important and very unreliable. I found that DHT22 can start acknowledging before the pulse ends. So after input_pullup the line may never go HIGH.
I still strongly recommend replacing the fixed delay with a wait busy loop.

Also, May I recommend a refactor?

If you break inside a for loop, even at the end, the condition will be true on exit; so you can retest it to determine how it ended:

for(init;cond;expr) {
   if (something) break;
}
if (cond) return false; //break executed

Also instead of a double for, you can use integer division and module

    for (i = 0; i < 5; i++) {
      for (j = 0; j < 8; j++) {

Can be written as

    for (k = 0; k < 40; k++) {
      i=k/8. //Integer division
      j=i%8

So

  bool error = false;
  noInterrupts();
  if (DhtWaitState(sensor, 0) && DhtWaitState(sensor, 1) && DhtWaitState(sensor, 0)) {
    for (uint32_t i = 0; i < 5; i++) {
      int data = 0;
      for (uint32_t j = 0; j < 8; j++) {
        if (!DhtWaitState(sensor, 1)) {
          error = true;
          break;
        }
        delayMicroseconds(35);                          // Was 30
        if (digitalRead(Dht[sensor].pin)) {
          data |= (1 << (7 - j));
        }
        if (!DhtWaitState(sensor, 0)) {
          error = true;
          break;
        }
      }
      if (error) { break; }
      dht_data[i] = data;
    }
  } else {
    error = true;
  }
  interrupts();
  if (error) { return false; }

Can be expressed like this

  uint32_t i=0;  
  noInterrupts();
  if (DhtWaitState(sensor, 0) && DhtWaitState(sensor, 1) && DhtWaitState(sensor, 0)) {
    for (i = 0; i < 40; i++) {
        if (!DhtWaitState(sensor, 1)) {
          break;
        }
        delayMicroseconds(35);                          // Was 30
        if (digitalRead(Dht[sensor].pin)) {
          dht_data[i/8] |= (1 << (7 - i%8));
        }
        if (!DhtWaitState(sensor, 0)) {
          break;
        }
    }
  interrupts();
  if (i<40) { return false; }

No double break :)

[ascillato2]

Closing this issue as it has been solved.

Thanks everyone for helping and testing :+1:

---

Support Information (Guide)

See Wiki for more information.
See FAQ for common questions/answers and links if none of your question is in the list.
See Chat for more user experience.
See Community for forum.
See Code of Conduct

[GiorgioRoma]

Sorry, i used firmware tasmota 8.2.0.3 and the issue is present

The problem occurs approximately every 24 hours:

[adharyanto]

Hallo,

I am using 8.2.0.3 as well, but using DHT11 module and it is ok, (not SI7021 module).

Just the humidity value is somewhat too high in my opinion, (always above 90%)…. but this has happened for quite some time already…

Some time ago was much lower, I do not know what the cause of this… but I neglect it for the meantime…

And btw, I am using Node-RED to control my system, and I use the Tasmota Console content information to process on the Node-RED, like this example below:

• {"Time":"2020-04-18T19:56:14","ANALOG":{"A0":17},"DHT11":{"Temperature":30.0,"Humidity":92.0,"DewPoint":28.6},"TempUnit":"C"}

Whenever there is Tasmota update, my Node-RED dashboard, especially this Temp & Humid sometimes becomes broken, the reason because the format of Console content has changed, for example; before there was no “DewPoint” but on the updated version there is. Since I am using a certain way inside my Node-RED (my own algorithm) to extract the temp & humid values from this Console report, if the Console report format has changed, this causing my Node-RED dashboard broken. So, I always need to modify my Node-RED to suit the new Console format.

This is my Tasmota with DHT11 sensor:

This is my Node-RED dashboard, (simplified with Temp Chart only):

--
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus

[GiorgioRoma]

for completeness of information, I am using the dht22 sensor, exactly this:

[Jason2866]

@GiorgioRoma Have you installed the 4k7 Ohm resistor? The resistor is NOT on the PCB.

[GiorgioRoma]

really no, I knew he already had resistor.
Sure I have to put it on?

[schrej-zz]

I don't know, if we will ever find the myth behind these sensors.
There are so much different versions on the market.
I have a pure DHT 22 without any resistor running perfectly for weeks, and another one on a small red board with resistor, that only runs with GPIO parasite power, but stops working after about a day when connected to VCC.

Joerg

[weekendjoy]

All 8.2 firmware has this issue. I tried all 8.2
8.1 is fine

[GiorgioRoma]

The situation is strange. I'm running several tests. I am testing a sonoff basic rf, with the DHT22 temperature sensor, starts to provide null values ​​after less than 24 hours (Tasmota firm 8.2.0.3).

I am also testing a sonoff mini, always with the same type of DHT22 sensor and for 4 days reporting valid values. The difference between the two sonoff (as well as the model) is that on the sonoff mini (the one that works correctly) I have not enabled anything (mqtt, emulation, setOption19). Now also on this sonoff I have enabled these features, to check if it continues to work

I'll update you in the next few days

[adharyanto]

Hi, I am using Tasmota v8.2.0.4, DHT11 Sensor, it is fine…

--
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus

[eku]

@arendst I use DHT22 from the same batch with Ethersex and with Tasmota (8.2.0). Only with Tasmota the sensors drop at least once in 24 hours. Restarting Tasmota does not fix the problem. A power cycle is required.

[kaciker]

Hi, I have an ESP01 connected to DTHT11 with last Tasmota v8.3.1.2 and after 24h is turning null all values. I moved the DHT11 to a sonoff basic and after to a sonoff POW, and with same tasmota version alwais after 24h +- the null arrives. Only a power cycle make returns the values. Waiting for solutions, is possible to have a full reset by console ? I tried with commands "restart 1", and does not work. With this and nodered I could program a reset when the problem comes. THanks

[arendst]

Continuing on your request you've already find out that a power cycle solves yor issue. This cannot be programmed. The issue is your DHT11 which needs a power cycle, not Tasmota.

[Gunthervc]

Same problem here with sonoff & DHT11. after 12hours null :(
Have to power cycle

[Dyrke]

Sorry to tell you arendst, but I have the same problem. When I run the physical same DHT11 on a Olimex DEV board, there is absolutly no problem, it can run for weeks, with the same version tasmota, right now it is 8.3.1, but when I run it on an sonoff basic it stops after about 12 hours. Again it is the same DHT11. So it is not the DHT11 but I think it has something to do with the power supply in the Sonoff basic. I tried decoupling the power supply with a 47 uf 16 volt capacitor, right on the sensor board, and after that it ran for almost 36 hours with no problem. So to me it looks like some spikes/dropouts in the power supply.

[ascillato]

A sonoff basic can not power anything but itself. It was not designed to power a sensor. If you want to use a sonoff basic with a sensor, you must add an extra power supply for your sensor.

[Dyrke]

@ascillato
An DHT11 has these data
Conditions Minimum Typical Maximum
Power Supply DC 3V 5V 5.5V
Current SupplyMeasuring 0.5mA 2.5mA

So that isn't thrue as the ams1117 is capable of delevering 800 mA.

[adharyanto]

Hi,

Just for your information; I am using Sonoff Basic, Tasmota 8.3.1.2 (855e054-tasmota), configured as Generic Module, and I modified = I add 3 more relays (total 4 relays), also add DHT11.

Take/tap the 5V/3.3V power from Sonoff Basic power supply itself, so far working fine…

The additional 3 relays, sometimes on/sometimes off, when the relay is on it will draw some current…

Attached the snapshot…..

--
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus

[adharyanto]

[Gunthervc]

Hi, Just for your information; I am using Sonoff Basic, Tasmota 8.3.1.2 (855e054-tasmota), configured as Generic Module, and I modified = I add 3 more relays (total 4 relays), also add DHT11. Take/tap the 5V/3.3V power from Sonoff Basic power supply itself, so far working fine… The additional 3 relays, sometimes on/sometimes off, when the relay is on it will draw some current… Attached the snapshot…..
…
-- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus

Awsome!
Connected the DHT11 to 5v inside the Sonoff basic and keeps running now :)
Thanks alot

[kaciker]

My solution was soround the problem... In the two cases that I have the problem one with a sonoff POW and second with a ESP01. In both I instaled a relay 5v feding the DTH11 and using a gpio free, and with a rule in node-red when the "null" arive I send the order to swich off during 5s the realy.. finally each 12-20h the swich make a reset... is not clean but works...

[EvilForge]

I saw the various DHT sensors I have inside and outside eventually start to fail (I use WemosD1Mini for my sensors, not a sonoff), even with different wiring methods, pull-ups, different pins, different models (DHT12 and DHT22 and DHT11) and different firmware. Different power sources too!

It seemed simpler to me to just use a Bosch BME 280 sensor vs trying to power cycle. I also gained pressure and dewpoint values (with later Tasmota FW versions), to go along with Temp and Humidity, and the price for the sensor was cheaper than a relay/custom power cycle solution. It was also simpler to retrofit.

I haven't tested the BME sensors for more than 3 weeks, but I have seen no glitches since then, and I like the additional data. If you want the additional data, be certain you get a true BME, not a BMP. BMP wont have pressure, although a BMP should be a cheaper sensor if you dont want pressure. Most ebay sellers dont know the difference, apparently.

This is the best link for making sure you got the right one:
https://goughlui.com/2018/08/05/note-bosch-sensortec-bmp280-vs-bme280-sensor-confusion/

We had to have stable mains power for a long time to see all of the sensors fail.. unfortunately being rural, we lost power often, and of course that resets everything. But eventually, all of my DHT based sensors have started showing NULLs. :(

[ascillato]

@Dyrke

Please, search in old issues. That mod to a sonoff basic is outside the original design and also there are some batches of sonoff basics with very poor power supply. We made the version called TASMOTA-LITE.bin just because of these sonoffs basics!!! A full version of Tasmota uses more energy than can be provided by the power regulator of those devices. (most of those issues are grouped with a label "sonoff basic R2" so you can check them easily ) I'm just sharing with you the experience from older issues, not a random fact. It might work for your case and your actual device, but generally the case is that don't work reliable, so we don't recommend that.
Also, the 5V rail of a sonoff is noisy (please, check it with an oscilloscope) and not recommended for a sensor that needs a stable power source. The ams1117 can not deliver instantaneously all the power for the TX spikes of the ESP8266 and also power extra sensors and relays. A sonoff basic don't have the extra capacitors for that, because is a BASIC and cheap device.

@kaciker

_Please, DO NOT CONNECT SENSORS to a POW. It is very dangerous!!!!_ Your GND and 5v / 3.3v rail is directly connected to mains. If you or any member of your family touch that sensor, they can suffer an electroshock!!! There are BIG warnings in the TASMOTA DOCUMENTATION about that danger!!!!
Also, please, measure with a DMM and you will see and please, check old issues. Several users have suffer electroshocks because of that and also have devices that went on fire.
If you want a reliable temperature measurement, use a NodeMCU and a standard 5V power source.

[Dyrke]

@ascillato Found the problem.
I just got a new shipment of sensors, to another project, and tried them out. Love and behold everything worked perfect, on the old one. Been running now for almost 2 weeks without any problem. Apparently I got a sensible bunch in the last project. :-(

[dionrowney]

Did anyone solve this issue of the DHT11s reporting back null?

This seems to still be happening in v8.4.1.

I have a ASAIR NADHT11 and all I get is null. I heard going back to the older firmware was a solution but I cannot locate old bin files in back as far as indicate in the archives. Is there another source? Am I doing something else wrong? Why was this ticket closed?

Have 2 sensors of same type and both report same null value

[ascillato]

Did anyone solve this issue of the DHT11s reporting back null? Have 2 sensors of same type and both report same null value

Please, do a full search in issues and you will find that this was extrensely worked. Several timings for these sensors were tested among a lot of users and there is a batch of DHT11 that don't work. Please, buy another sensor or change your sensor for DHT22 or any other newer one.

Why was this ticket closed?

Because (as explained in the PRs) several tests were done and new drivers were tested, so the best that works in most brands of these sensors is now part of Tasmota.

I heard going back to the older firmware was a solution but I cannot locate old bin files in back as far as indicate in the archives.

A solution would be a better sensor, but if you want to try an older version of Tasmota just look in the releases (https://github.com/arendst/Tasmota/releases)

Am I doing something else wrong?

If you want you can also ask for support in the Tasmota Support Chat at Discord