Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Tasmota 8.1.0.7: DHT11 Temp =NULL & Humid = NULL #7717

Closed
15 tasks
adharyanto opened this issue Feb 11, 2020 · 75 comments
Closed
15 tasks

Tasmota 8.1.0.7: DHT11 Temp =NULL & Humid = NULL #7717

adharyanto opened this issue Feb 11, 2020 · 75 comments
Labels
bug Type - Confirmated Bug fixed Result - The work on the issue has ended

Comments

@adharyanto
Copy link

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
Copy link
Collaborator

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
Copy link
Author

adharyanto commented Feb 11, 2020 via email

@schrej-zz
Copy link

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 ascillato2 added awaiting feedback Action - Waiting for response or more information troubleshooting Type - Troubleshooting labels Feb 11, 2020
@ascillato2
Copy link
Collaborator

@adharyanto @schrej-zz

Going back to 8.1.0.6 solves your issue?

@adharyanto
Copy link
Author

adharyanto commented Feb 12, 2020 via email

@schrej-zz
Copy link

schrej-zz commented Feb 12, 2020 •
edited
Loading

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
Copy link
Author

adharyanto commented Feb 12, 2020 via email

@ascillato2
Copy link
Collaborator

@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
Copy link
Collaborator

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

Ok. Thanks for testing 👍

@ascillato2
Copy link
Collaborator

@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
Copy link
Author

adharyanto commented Feb 12, 2020 via email

@PabloVogel
Copy link

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
Copy link
Contributor

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

@ascillato ascillato mentioned this issue Feb 13, 2020
Closed
6 tasks
arendst added a commit that referenced this issue Feb 13, 2020
@arendst
Add another new DHT driver based on ESPEasy
7cc783a 
Add another new DHT driver based on ESPEasy. The old driver can still be used using define USE_DHT_OLD. The previous new driver can be used with define USE_DHT_V2 (#7717)
@arendst
Copy link
Owner

arendst commented Feb 13, 2020

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

Great fun!!!

arendst added a commit that referenced this issue Feb 13, 2020
@arendst
Add a stripped down Add a stripped DHT driver based on ESPEasy (#7717)
e9f0c5b 
Add a stripped DHT driver based on ESPEasy (#7717)
@ascillato
Copy link
Contributor

ascillato commented Feb 13, 2020 •
edited
Loading

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
Copy link

testing ..... 10x Am2301 with 8.1.0.8

@PabloVogel
Copy link

no issues with new driver

@adharyanto
Copy link
Author

adharyanto commented Feb 14, 2020 via email

@klaus-pittisch
Copy link

11 hours, 10 sensors, no issues

Thank you

@OptimusGREEN
Copy link

OptimusGREEN commented Feb 14, 2020 •
edited
Loading

8.1.0.8 still says null for a dht11 that I have
image
image

@arendst
Copy link
Owner

arendst commented Feb 14, 2020

@OptimusGREEN did it ever work?

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

@PabloVogel
Copy link

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

@arendst
Copy link
Owner

arendst commented Feb 14, 2020

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

@OptimusGREEN
Copy link

OptimusGREEN commented Feb 14, 2020 •
edited
Loading

@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
Copy link
Contributor

ascillato commented Feb 14, 2020 •
edited
Loading

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?

@ascillato2 ascillato2 added bug Type - Confirmated Bug fixed Result - The work on the issue has ended and removed awaiting feedback Action - Waiting for response or more information troubleshooting Type - Troubleshooting labels Feb 23, 2020
@GiorgioRoma
Copy link

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

bugDHT22

The problem occurs approximately every 24 hours:

andamentoDHT22

@adharyanto
Copy link
Author

adharyanto commented Apr 18, 2020 via email •
edited
Loading

@GiorgioRoma
Copy link

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

DHT22

@Jason2866
Copy link
Collaborator

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

@GiorgioRoma
Copy link

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

@schrej-zz
Copy link

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
Copy link

weekendjoy commented Apr 24, 2020 •
edited
Loading

null

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

@GiorgioRoma
Copy link

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
Copy link
Author

adharyanto commented Apr 24, 2020 via email

@eku
Copy link
Contributor

eku commented May 3, 2020

@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
Copy link

kaciker commented May 26, 2020

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
Copy link
Owner

arendst commented May 26, 2020

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
Copy link

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

@Dyrke
Copy link

Dyrke commented May 29, 2020 •
edited
Loading

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
Copy link
Contributor

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
Copy link

Dyrke commented May 29, 2020

@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
Copy link
Author

adharyanto commented May 29, 2020 via email

@adharyanto
Copy link
Author

aaa

@Gunthervc
Copy link

Gunthervc commented May 29, 2020 •
edited
Loading

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
Copy link

kaciker commented May 29, 2020

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...
image

@EvilForge
Copy link

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
Copy link
Contributor

ascillato commented May 29, 2020 •
edited
Loading

@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.

@ascillato2 ascillato2 mentioned this issue Jun 17, 2020
Closed
15 tasks
@Dyrke
Copy link

Dyrke commented Jun 24, 2020 •
edited
Loading

@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
Copy link

dionrowney commented Aug 18, 2020 •
edited
Loading

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
Copy link
Contributor

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
bug Type - Confirmated Bug fixed Result - The work on the issue has ended
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests