search

arendst / Tasmota

Alternative firmware for ESP8266 and ESP32 based devices with easy configuration using webUI, OTA updates, automation using timers or rules, expandability and entirely local control over MQTT, HTTP, Serial or KNX. Full documentation at
https://tasmota.github.io/docs
GNU General Public License v3.0
21.96k stars 4.77k forks source link

DHT22 report null after a while #5619

Closed Magnus-rosenborg closed 5 years ago

Magnus-rosenborg commented 5 years ago
### BUG DESCRIPTION Get null for both humidity and temperature on AM2302, DS18B20 works fine. Running on Wemos D1 R2, Tasmota 6.5.0(sensors) ### REQUESTED INFORMATION _Make sure these boxes are checked before submitting your issue. Thank you_ **FAILURE TO COMPLETE THE REQUESTED INFORMATION WILL RESULT IN YOUR ISSUE BEING CLOSED** - [X] Read the [Contributing Guide and Policy](https://github.com/arendst/Sonoff-Tasmota/blob/development/CONTRIBUTING.md) and [the Code of Conduct](https://github.com/arendst/Sonoff-Tasmota/blob/development/CODE_OF_CONDUCT.md) - [X] Searched the problem in issues (https://github.com/arendst/Sonoff-Tasmota/issues) - [X] Searched the problem in the wiki (https://github.com/arendst/Sonoff-Tasmota/wiki/Troubleshooting) - [X] Searched the problem in the forum (https://groups.google.com/d/forum/sonoffusers) - [X] Searched the problem in the chat (https://discord.gg/Ks2Kzd4) - [X] Device used (i.e. Sonoff Basic) : _Sensor works on sonoff Basic but not on Wemos ____ - [X] Tasmota binary firmware version number used : 6.5.0, self compiled____ / (pre-compiled or self-compiled ?) - [X] Development IDE - Compiler / Upload tools used :platformio ____ / http____ - [X] Provide the output of command ``status 0`` : ``` STATUS 0 OUTPUT HERE: 00:53:59 MQT: stat/80/STATUS = {"Status":{"Module":18,"FriendlyName":["Wemos","Wemos2","Wemos3","Wemos4"],"Topic":"80","ButtonTopic":"KNAPP80","Power":0,"PowerOnState":3,"LedState":1,"SaveData":1,"SaveState":1,"SwitchTopic":"SWITCH80","SwitchMode":[2,0,0,0,0,0,0,0],"ButtonRetain":1,"SwitchRetain":1,"SensorRetain":0,"PowerRetain":1}} 00:53:59 MQT: stat/80/STATUS1 = {"StatusPRM":{"Baudrate":115200,"GroupTopic":"sonoffs","OtaUrl":"http://insidan.us.to/sonoff/firmware80.bin","RestartReason":"Software/System restart","Uptime":"0T00:09:47","StartupUTC":"2019-04-10T22:44:12","Sleep":50,"CfgHolder":4617,"BootCount":64,"SaveCount":296,"SaveAddress":"F9000"}} 00:53:59 MQT: stat/80/STATUS2 = {"StatusFWR":{"Version":"6.5.0(sensors)","BuildDateTime":"2019-04-11T00:17:47","Boot":31,"Core":"2_3_0","SDK":"1.5.3(aec24ac9)"}} 00:53:59 MQT: stat/80/STATUS3 = {"StatusLOG":{"SerialLog":0,"WebLog":2,"SysLog":0,"LogHost":"","LogPort":514,"SSId":["lj3m",""],"TelePeriod":60,"Resolution":"558180C0","SetOption":["000080E9","280500000100000000000000000000000000","00000000"]}} 00:53:59 MQT: stat/80/STATUS4 = {"StatusMEM":{"ProgramSize":547,"Free":456,"Heap":15,"ProgramFlashSize":1024,"FlashSize":4096,"FlashChipId":"164020","FlashMode":3,"Features":["0000041D","0FDEE3B4","0001A004","B7FFBFCC","005ABBC0"]}} 00:53:59 MQT: stat/80/STATUS5 = {"StatusNET":{"Hostname":"80-5893","IPAddress":"192.168.200.220","Gateway":"192.168.200.254","Subnetmask":"255.255.255.0","DNSServer":"192.168.200.1","Mac":"60:01:94:56:D7:05","Webserver":2,"WifiConfig":4}} 00:53:59 MQT: stat/80/STATUS6 = {"StatusMQT":{"MqttHost":"192.168.200.1","MqttPort":1883,"MqttClientMask":"DVES_%06X","MqttClient":"DVES_56D705","MqttUser":"scriptuser","MqttCount":1,"MAX_PACKET_SIZE":1000,"KEEPALIVE":15}} 00:53:59 MQT: stat/80/STATUS7 = {"StatusTIM":{"UTC":"Wed Apr 10 22:53:59 2019","Local":"Thu Apr 11 00:53:59 2019","StartDST":"Sun Mar 31 02:00:00 2019","EndDST":"Sun Oct 27 03:00:00 2019","Timezone":"+02:00","Sunrise":"07:07","Sunset":"20:35"}} 00:53:59 MQT: stat/80/STATUS10 = {"StatusSNS":{"Time":"2019-04-11T00:53:59","ANALOG":{"A0":8},"DS18B20":{"Temperature":1.0},"AM2301":{**"Temperature":null,"Humidity":null},"TempUnit":"C"}}** 00:53:59 MQT: stat/80/STATUS11 = {"StatusSTS":{"Time":"2019-04-11T00:53:59","Uptime":"0T00:09:47","SleepMode":"Dynamic","Sleep":50,"LoadAvg":48,"POWER1":"0","POWER2":"0","POWER3":"0","POWER4":"0","Wifi":{"AP":1,"SSId":"lj3m","BSSId":"E4:F0:42:E6:0A:85","Channel":6,"RSSI":100,"LinkCount":1,"Downtime":"0T00:00:06"}}} ``` - [x] Provide the output of console when you experience your issue if apply : _(Please use_ ``weblog 4`` _for more debug information)_ ``` CONSOLE OUTPUT HERE: under väntan startsignal hög puls = means timeout during wait for start signal high puls 00:57:24 DHT: Timeout under väntan startsignal hög puls 00:57:26 DHT: Timeout under väntan startsignal hög puls 00:57:28 DHT: Timeout under väntan startsignal hög puls 00:57:30 MQT: tele/80/STATE = {"Time":"2019-04-11T00:57:30","Uptime":"0T00:13:18","SleepMode":"Dynamic","Sleep":50,"LoadAvg":30,"POWER1":"0","POWER2":"0","POWER3":"0","POWER4":"0","Wifi":{"AP":1,"SSId":"lj3m","BSSId":"E4:F0:42:E6:0A:85","Channel":6,"RSSI":100,"LinkCount":1,"Downtime":"0T00:00:06"}} (bevarad) 00:57:30 MQT: tele/80/SENSOR = {"Time":"2019-04-11T00:57:30","ANALOG":{"A0":8},"DS18B20":{"Temperature":1.0},"AM2301":{"Temperature":null,"Humidity":null},"TempUnit":"C"} 00:57:30 DHT: Timeout under väntan startsignal hög puls 00:57:32 DHT: Timeout under väntan startsignal hög puls 00:57:35 DHT: Timeout under väntan startsignal hög puls 00:57:36 DHT: Timeout under väntan startsignal hög puls 00:57:38 DHT: Timeout under väntan startsignal hög puls 00:57:40 DHT: Timeout under väntan startsignal hög puls 00:57:41 WIF: Kontrollerar anslutning... 00:57:41 WIF: Ansluten 00:57:42 DHT: Timeout under väntan startsignal hög puls ``` ### TO REPRODUCE Nothing it happens all time, works after reboot for a minute then it starts to get null more and more null. After som hour or so only null values. ### EXPECTED BEHAVIOR Get both values. ### SCREENSHOTS _If applicable, add screenshots to help explain your problem._ ![thumb_IMG_4104_1024](https://user-images.githubusercontent.com/49500329/55919280-95367500-5bf5-11e9-9940-01cb69f03bff.jpg) ### ADDITIONAL CONTEXT Not sure if needed but AM2302 is connected to GPIO14 and my DS18B20 is connected to GPIO2. **(Please, remember to close the issue when the problem has been addressed)**
bananajoe86 commented 2 years ago

Same issue with a Wemo D1 and DHT11. Physical startup shows value for Temp/Humidity and Drewpoint. After 3 minutes all values become null.

rjcgit commented 2 years ago

My DHT22 AM2302 sensors using a ESP01 work when first configured, but most of the time when I issue an SetOption8 command to change to Fahrenheit they begin issuing Nulls. Strangely if I go into the Configure Template window and change the GPIO2 pin to AM2302 from User save and then go back and change from AM2302 to User they begin working for a short period of time then go back to issuing nulls. Not I have used 3 DHT22 sensor boards and 3 ESP01s and the problem always happens when I attempt to change to Fahrenheit. Even stranger when I use new boards they work at Celsius. But once this happens erasing and reprogramming with Tasmotizer they continue with the Null problem.

bespokecomp commented 1 year ago

Is this a hardware or a firmware issue?

(All details posted below for clarity)

Does anybody have any further information on this?

I'm getting random null readings for the sensor and it's the only thing stopping me from completing dehumidifier home automation project i've spent weeks on. The sensor just simply stops working when I need it to work constantly and consistently for my Node-Red and Mosquitto Broker, both installed on a raspberry pi, flow to work. I've tried changing between AM3201 and SI7021 in the Module parameters drop down menus and no difference. It will sometimes give successful readings for hours, and then just "null".
Powering off at the mains, discharging anything by pressing the sonoff button a couple of times, and powering back on again, refreshes and gives me temp and humidity again.

Unit:

Sonoff Basic R2

PCB:

Sonoff RF R2 Power V1.3

Tasmota firmware:

12.2.0(tasmota)

Core/SDK Version

2_7_4_9/2.2.2-dev(38a443e)

Sensor

DHT22

Connections:

Sonoff PCB DHT22 4.7K Pull-up Resistor
GPIO5 (data) OUT *
5V (VCC) + *
GND -

Tasmota Configuration:

Here I created an empty generic(18) configuration file (right) and made the same connections that correlate to the standard onboard connections of the RELAY, BUTTON & LED for the Sonoff, that I first gleaned from in the Configure Template section in Tasmota (left), and selected AM3201 for GPIO5.

|TasTemplate|MyTasConfig|

llllllllqq commented 8 months ago

on esp32c3 (luatos cdc version, see https://cdn.openluat-luatcommunity.openluat.com/attachment/20220609213416069_CORE-ESP32-A12.pdf and https://wiki.luatos.com/_static/bom/esp32c3.html and https://wiki.luatos.com/chips/esp32c3/board.html#id3 ) with Program Version 13.3.0(tasmota32) Build Date & Time 2023-12-12T14:31:41 Core/SDK Version 2_0_14/4.4.6.231122 my dht22 still has this issue. it is on gpio5

pilaGit commented 6 months ago

I have the same problems with AM2302, connected directly (no resistors) to different devices. Working perfectly, then stops! Problem may appear once in few years, in few months or daily! Only hard power cycle or removing the AM2302 GND wire (other two do not solve the issue) and reconnecting it back fixes things! For 3 years!

Today, I have 100% positively proved, that in my case, problem is absolutely not the Tasmota! Problem is caused by electromagnetic interference (EMI/EMP) - not my field, these therms may not be perfectly correct! I am an expert programmer and mathematician. My own, extremely complex, SmartHome program runs several homes and I had to program around 30+ bugs in Tasmota! So I am not defending the Tasmota!

Note: I do not claim this is the only possible cause for this problem! But, if others would check if this may be the cause of their AM2302 problem, we would all prosper! Unfortunately, this needs bit of explaining to be accepted as proved. Please, bear with me! Not a simple problem to prove!

One of my homes is in colder continental EU N45 climate and needs humidifiers. In 2021 I bought two AM2302 to test if they can be used to run humidifiers. They worked perfectly for heating, and are useless for cooling. They were connected to D1 minis. One of them would occasionally blank out. It was temporary connected to D1 mini, using DuPont wires, and was next to humidifier, so I would dismiss occasional (once in weeks) problem and would just replug the GND. The second AM2302 was permanently connected to a D1 mini in another zone. That second AM2302 had the problem just once in 3+ years! Again, I dismissed it and reconnected its Gnd to its screw-in clamp.

This problematic one, connected with DuPont wires to D1 mini, would bug me from once in few days to once in few months. No rule. So, recently I decided to move it to Sonoff Dual R2 where it was supposed to be connected permanently. I soldered it! Man, was that a mistake! From occasionally, it would faint on a daily basis! So, I ordered third AM2302 and replaced the old one with the new one. It works! Until my shutters were closed yesterday at sunset! AM2302 fainted again! I reconnected the AM2302 GND, it works again. Until my shutters were raised this morning! I retested everything: 2 different AM2302, different GPIO0s, different Grounds, checked solder points, verified all connections are OK. This particular Sonoff Dual R2 is used to: lower and raise the shutters, it has one DS18B20 sensor with its own pull-up, has a Reed switch for open/close window and its LED is used for signalling. Everything else all homes works perfectly for 5 years! This zone alone has 15+ devices.

Sometimes AM2302 does not make a problem. When the shutters are fully lowered - it faints. On small shutter movements and after raising the shutters, problem often does not present itself! Problem may occur immediately or after a 1-2-3 minutes! AM2302 disappears. Power cycle or recouplling the AM2302 GND solves it always! Noting else helps.

So, today I left a new AM2302 attached to my 230V powered Sonoff and brought nearby an USB powered D1 mini and attached the old AM2302 to it. Here is my proof: I have witnessed on multiple occasions, that both AM2302s, connected to separate USB powered D1 mini and to the 230v Sonoff, would disappear at the same instant! Moving D1 mini around, its AM2302 would disappear less frequently, while the AM2302 connected to the Sonoff would drop dead during every cycle! At least once!

I ave proven and am absolutely certain that my shutter motors emit occasional EMI/EMP killing the AM2302s! In another home, similar shutters motor would disrupt TV picture for a 1-2 seconds! Friend said he has a Tuya gateway which, when plugged to its USB C cable, would disrupt TV picture for a moment! Problems occurs because motors are Inductive loads (having moving parts, as opposed to resistive loads: e.g. bulbs or heaters). I can not explain friend's Tuya gateway, except: they made it the cheapest possible way, usual Chinese quality.

Why this EMI/EMP problem occurred only once on my second AM2302 connected to D1 mini in large living zone, I have no clue. Btw, this living area D1 mini has 4 of the same shutter motors within 2-3 meters to the left and to the right of it! There are two Sonoffs with 4 relays and another one with 2 relays, all within half a meter from AM2302! Plus several other relays, not powering motors! Plus many other sensors and relays. Ah, just that particular D1 mini, additionally to the AM2302, has: 2 DS18B20 (using D1 internal pull-up resistor), BH1750 Illuminance sensor and its LED is used for signalling. I do think sometimes TV in that zone would flicker for a moment, but quite rarely. Mostly, all 4 shutter motors in that zone are run simultaneous! Every day, they run at least two times! In summer, 5 times. This AM2302 disappeared just once in 3+ years.

Now I need to find how to fix that problem. Two ferrites placed on the problematic AM2302 cable did not help. I will have to try placing them near the motor, but that is not my field of expertise. For now, I connected this Sonoff Dual, one whose motor is causing the problem, to a plug the SmartHome program controls. If the SmartHome notices AM2302 is unavailable, it cycles the power for Sonoff Dual R2 and its AM2302. But, that is not the solution! Guess what just happened, few minutes after the sunset? My SmartHome power cycled Sonoff and all is well again.

Anybody else willing to test it they have the same cause of this problem?

PabloVogel commented 6 months ago

Just connect the power pin of the DHT to a gpio and send a low pulse when the DHT hangs. No need to reboot the whole thing. Some DHT are total crap and other are rock solid (older ones). Motors generate lots of electrical noise (EMF) that can even hang the ESP's. As as the ESP has a watchdog it heals itself, but the crappy DHT seems to be too basic.

pilaGit commented 6 months ago

Logically, that would work. But...

You propose that we connect both data and 3v3 pins of AM2302 to data pins? Not 3v3 to 3v3? Or do you mean both together? Sort of, something like DS18B20 parasitic mode where I connect both GND and 3v3 leads to the ground?

My problem can not be solved by breaking data or 3v3 lines, only by breaking data or power cycle.

My AM2302s are 3+ years apart. I expect all are crap, more or less, but crap.

How would that work? I would have to define 2 GPIOs as having AM2302? And then, do what?

My aim was for others to check if this is the cause of their problem. Rebooting the Sonoff takes 4 seconds total, but I said that can not be the acceptable solution.

PabloVogel commented 6 months ago

No, connect the 3.3v to an unused gpio and configure it as a relay. So when it's on you are powering the DHT when it's off you are not. Now you can remote reboot the DHT switching momentarily off.

pilaGit commented 6 months ago

Well, I am embarrassed I did not think of that! Logically, this makes sense! I tried many variations, but not this one. It is late now for me to switch wires, I will try that tomorrow! AM2302 should work with current from a GPIO.

This sounds brilliant, strictly logically speaking. This really should work! In my particular situation, it will take some tinkering inside the Sonoff Dual to replace wires. Luckily, it has a free GPIO.

Still, I wanted to pint to a different cause of this problem, for the sake of other users. I have not seen anybody taking this route.

pilaGit commented 6 months ago

I just rewired a D1 mini with AM2302 as you suggest, and it works as expected. When the Relay is On, it works. I can kill it for a few seconds, AM2302 dies and then returns!

I will make a real test tomorrow. My concern is that I always had to break the GND, breaking Data or 2v2 never helped.

Regardless, this is a brilliant idea! I will report back tomorrow. But still, this is not a solution, but more elegant workaround than what I do now, by powering down the Sonoff.

Still, I like and appreciate brilliant ideas!

pilaGit commented 6 months ago

After a late supper, I went on to test a variant that I might need. Killing the Gnd line. I can not do it on a Sonoff, but it is simple on a D1 mini as its D8 has inbuilt pull-down.

Just connect Gnd from AM2302 to D1 mini's D8 GPIO15 instead to Gnd and define it as Relay_i. Kills Gnd line but takes quite long time.

pilaGit commented 6 months ago

Both of the above (GND or 3v3) resets AM2302 when connected alone to my D1 mini. But, for some reason, the AM2302 connected to my Sonoff Dual R2 resets only when its Gnd is cut.

We still need someone from this field to offer actual solution of the problem. Confirmation of others would also be nice. For now, we have usable workarounds.

pilaGit commented 6 months ago

Spec sheet says: One capacitor valued 100nF can be added between VDD and GND for wave filtering.

Is that related to problems we have and could that be a fix?

frollard commented 5 months ago

I'm experiencing similar but with multiple time of flight laser sensors sharing the I2C bus. VL53L0X has a configurable (volatile) i2c address, which is set up on boot via the inhibit lines to individually address each sensor and give a unique address. (I believe sensor 1 keeps the default address, and sensor 2++ get increments from there). From there on, if a sensor loses power, it loses config and starts colliding with the default address causing 1-2 nulls. I can't just power cycle the sensors as tasmo needs to run the startup script to re-address the volatile sensors. A soft reset of tasmota in this case DOES bring the sensors back to life by re-programming it. We may need to use both tricks - io pin to relay power cycle the sensors if they internally crash, then software reboot the esp to fix the config. In theory just the reboot should be needed. Startup: image After a while: image

(Aside: using the distance sensors to track the inventory count of a pop machine, because makerspace decentralized volunteers need access to the inventory...and our vending controller only announces digital transactions over the network, not coin transactions because reasons).

SuperMaximus1984 commented 4 months ago

Same here. Using Olimex ESP32-POE with multiple AM2302 sensors. What's peculiar is that sensors drop out to NULL in almost exact periods of time. Either at 20:41 in the evening or 5:32 in the morning. I register these dropouts in my Home Assistant. Definitely cannot be resistor or power issue. Can some timer be set in Tasmota drivers?