-
Notifications
You must be signed in to change notification settings - Fork 4.8k
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.
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
DHT22 not working when Restart/Reset on GPIO2... OK at power up #3522
Comments
Hi, The behaviour you are experimenting is related to the esp8266. Gpio2 is used at boot time for the hardware. There is nothing Tasmota can do about that. You should use another gpio. For more information, see the wiki at https://github.com/arendst/Sonoff-Tasmota/wiki/Expanding-Sonoffs |
The generic pin model allows the selection of devices on GPIO2. If the boot mode pins were the issue it shouldn't boot correctly? It's only web initiated restart that fails. The GPIO0 and GPIO2 are pulled high and the AM2302 only drives the line after a > 1ms low from GPIO2 which only happens after the reset complete and GPIO pin configured from input to output. My board currently uses GPIO, 0,4,5,12,13,14 with one more needed GPIO2 which almost works. Any more info about the structure of a web initiated restart? Cheers |
https://tttapa.github.io/ESP8266/Chap04%20-%20Microcontroller.html You can't use GPIO15 or 16 with a pull-up, but they can be used for some things that don't need a pull-up, like an output. |
Hi, Have you managed to solve your issue? |
I can't see how this makes a difference, in the ESP8266 Technical reference guide, GPIO2 is used as the SDA signal in the I2C implementation which is a bi-directional I/O the same behaviour a One-Wire device requires. The restart works on one of my sensor nodes running 6.0.0a so either it's a subtle timing issue with this batch of sensors or a diff between 6.1.1c and 6.0.0a. |
Since you are experiencing the issue, you are the best person to do more detective work to uncover the true issue. You are correct that other people have used GPIO2 for DHT22 devices. So, you either have a different batch of DHT22s or perhaps it really is something different in the code. It might also only occur when all the other stuff you have is attached. The DHT22 protocol is very sensitive and hard to implement. The sensors are also not that good, which is probably the reason that many people choose not to use them. They are cheaper which is always nice, but not generally worth it if you have to spend hours trying to troubleshoot issues with them. |
I will investigate further, I have 10 x AM2302 from two different suppliers, I will try them with 6.1.1c on Wemos D1 mini, Sonoff Basic and ESP-01 modules. The accuracy is a little inconsistent between devices but ok for the purposes i need. I can't reason why the hard reset works and the soft doesn't. I was hoping that someone could assist me in where I put an initialisation delay in the DHT22 routine or a trigger for the GPIO change to see if it was timing related. The trigger pulse to the AM2302 is 15ms every 2.2s in both cases with the successful case showing data transmission for 4.5ms. Just wondering about the timing of the point GPIO2 changes from an O/P to and I/P. |
Hi, Have you managed to solve your issue? |
@JollyJames When using Wemos D1 mini please note the LED on the board, it is connected to GPIO2 too. |
I've notice the LED is connected. Installed PlatformIO with VS Code and compiled for Wemos D1 mini and ESP-01 with only GPIO0 and GPIO2 being used and restart still show nan for temp and humidity and correct values for power on reset. Rolled back to 5.10.0h and same performance. Trying to insert scope marker on GPIO4 when GPIO2 is made and input get compile errors atm. Also trying understand why error message is sent, 'Timeout waiting for start signal high pulse'. I'll give it the weekend and if no progress I'll have to re wire all the sensor boards with new GPIO config. |
Yep, try to troubleshooting if you have free time and let us know what you’re found. |
The LED flashes when the DHT22 routine programs the GPIO2 as an O/P and sends it low for the 20ms that the AM2302 needs to trigger it to drive the one-wire with the temp and Humidity data. After 20ms the DHT22 routine should switch the OP to an I/P and read the data sequence. The GPIO as an I/P will be not provide enough drain current to turn the LED on so the whole LED + 10K pull up on my board will allow the AM2302 to drive the signal. This scope traces a datasheet perfect after a hard reset, after a soft reset the AM2302 doesn't respond to the 20ms initiation pulse. I was looking for some help to work out where in the DHT22 routine the GPIO is turned from O/P to I/P my theory is that its late or missed somehow after a soft reset. Does anyone know how software reset is implemented and how the ESP8266 behaves? is it a jump to reset vector? |
You probably aren't going to find anyone here with that knowledge. You might at the esp8266 Arduino project, but you will probably have to ask at the espressif site. So, are you saying you captured oscilloscope traces of line in both the case where it works and also where it doesn't? Looking at the schematic for the esp-12, there is that led that is going to require current as soon as something tries to bring the line low. You also have the 10K pull-up. It is, of course, going to depend on the actual parts, but it is possible that the ground doesn't go low enough to be registered. If you are looking for the DHT code, it is here The function DhtRead() does the transition. |
Hi, Have you managed to solve your issue? |
Hi, Closing issue as there is no feedback. Please, ask to reopen if needed. Thanks |
I have the same problem. My DHT22/AM2302 is connected to GPIO1 (I don't have other GPIOs to work with). It works fine when I power up the device, but any reboot will kill the DHT22 readings and I get this log message:
Disconnecting an reconnecting the power supply brings the sensor back - every single time. |
The answer to your issue is: don't do that. GPIO1 is the TX line. It will always output something when the esp8266 starts. There is nothing you can do to prevent that. Since the DHT22 gets confused when it sees the signal from the boot messages, your choice is simple, find another pin to use. |
There is a reason there is a list of pins to avoid. They each have complications that make them unsuitable for general purpose use. If what you are attaching can still work with the constraints, it is fine to use them. If not, avoid using the pin or swap the function with something that doesn't conflict. |
Why does it work the first time it boots up? Seriallog is set to 0. |
Also, according to this document, the only restriction for GPIO1 is that it cannot be used during serial communication, of which there is none. I had the same problem with a Sonoff SC where I replaced the DHT11 with a DHT22 - would never work after a reboot, only after power cycle. |
The esp8266 bootloader, of which no one has control, ALWAYS outputs stuff when it starts. This happens before any application code runs, which can then decide to output more debug information or not. The point is that as a user of any part you need to understand the constraints. Many people use the DHT series of parts. At one time they were the only cheap humidity sensors. Even then they were not very good, but they were inexpensive. Today, they are still inexpensive and still as good as they ever were. But, now there are other far better choices available many for not a lot more money. But, it is your money and time so buy what you like. There is likely no one here who can help you make it work. The DHT series is tempermental and obviously the serial output from the boot loader sends it out to lunch. If you must use the DHT22, don't put it on any of the pins listed as ones to avoid. |
Well, in any case I still cannot find the mentioned "list of pins to avoid", at least not one where GPIO1 is mentioned. |
https://github.com/arendst/Sonoff-Tasmota/wiki/Expanding-Sonoffs |
Hi, I may have found a solution to reset the dht22 using an 2N3905 transistor with a 470k resistor with GPIO0. Sending low on GPIO0 will shutdown the dht22 and a high will power it up and the firmware download mode will not be triggered when esp8622 is rested. :) So far it works perfectly ! Yann, |
Hi guys, I'm having issues with a wemos D1 mini after upgrading to v6.3 |
can you explain me how you connected the transistor? |
Hi, how do you send the highs/lows? In the Tasmota console? Thank you! |
I have moved the DHT22 from GPIO2 to GPIO3(RxD) and since then no more problems. |
I had the same problem, the solution was to change the power from 3.3 to 5v, |
i'm interested in more details if possible |
Don't know if this goes here but... I was using a DHT22 shield for a Wemos D1 mini (for tasmota/home assistant). The pinout for the shield uses D4 and that didn't work (null), so I rerouted it to D3. Previously, I would have to remove power, then reconnect, to get anything from D4. I just used a little extra solder and broke a pin. Adds a little character. haha. Hope this helps someone. |
i tested a 2n2222 transistor on ground and GPIO1 as base. |
Hi, can you add a connection diagram? |
You absolutely need a resistor on the base, ie between GPIO 1 and the base of the transistor. I would use something between 1K and 10K ohm. |
relevant information, I had 2 power cuts since and each time the sonoff went into 'flashing mode'. |
I had the issue after soft Reboot. I connect now the DTH22 to the GPIO3 (Rx) Pin. The ESP is an ESP-01. So far the my problem with the DTH22 is solved for me. I'll hope it ist stable now. |
Please tell us if it's stable now |
I get the issue again on GPIO3 too. Look like that this is independent from GPIO Pin. A soft Reboot does't fix this issue, just an Power off helps to bring back the DHT22 in service again. |
None of the GPIO 0,1,2,3 is really safe to use with the DHT22. GPIO3 is just the least worrysome of them. And as others have said: the DHT is somewhat "temperamental". |
Try setting the pin bootmode (GPIO boot states) to Output low. For me it worked with ans ESP easy ;) |
When using WemosD1 & DHT22 You should avoid GPIO0, GPIO2 and GPIO15 for their special boot properties Using D7/GPIO13 as a communication port worked for me. And remember - you also need to "short" RST and D0 pins to make deep_speer work. I've connected DHT22 to 5V pin additionally - and it work like a charm :) |
Following on from..
#2988
Please read closed bug, #2988
I am also finding that GPIO2 in 6.1.1c shows the same behaviour, power on = working, restart = nan for both temp and humidity. Using identical AM2302 on GPIO2 and GPIO4 configuring with AM2301 and SI7021 shows the same behaviour.. removing the sensor and then adding it whilst powered also prompts correct operation. Web restart always fails GPIO2 connected sensor. This should work, feels like timing issue or lock-up with sensor from restart... 100% repeatable.
log file shows
03:00:44 DHT: Timeout waiting for start signal high pulse
03:00:46 DHT: Timeout waiting for start signal high pulse
Using Arduino IDE with esp8266 Community V2.4.2 Board Lib
Tools: Wemos D1 R2 & mini, 4m (1M SPIFFS), Disable, None, v1.4 Highter Bandwidth, Flash, 80Mhz, 11500, All Flash Contents, COM5.
Update OTA works well.
Also, make sure these boxes are checked [x] before submitting your issue - Thank you!
status 0
:The text was updated successfully, but these errors were encountered: