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.

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

Closed
JollyJames opened this issue Aug 19, 2018 · 42 comments
Closed

DHT22 not working when Restart/Reset on GPIO2... OK at power up #3522

JollyJames opened this issue Aug 19, 2018 · 42 comments
Labels
awaiting feedback Action - Waiting for response or more information troubleshooting Type - Troubleshooting

Comments

@JollyJames
Copy link

JollyJames commented Aug 19, 2018

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!

  • [x ] Searched the problem in issues and in the wiki
  • [x ] Hardware used : wemos D1 mini
  • [x ] Provide the output of command status 0 :
STATUS 0 OUTPUT HERE
11:06:49 MQT: stat/sensor-c/STATUS = {"Status":{"Module":19,"FriendlyName":["Sensor C","Sensor C2"],"Topic":"sensor-c","ButtonTopic":"0","Power":0,"PowerOnState":0,"LedState":1,"SaveData":1,"SaveState":1,"ButtonRetain":0,"PowerRetain":0}}

**To Reproduce**
as above

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

**Screenshots**
![untitled](https://user-images.githubusercontent.com/24388131/44307909-e82b9580-a3a2-11e8-8ed6-bb04cb3dce2f.png)

**Additional context**
11:06:49 MQT: stat/sensor-c/STATUS2 = {"StatusFWR":{"Version":"6.1.1c","BuildDateTime":"2018-08-10T01:57:45","Boot":31,"Core":"2_4_2","SDK":"2.2.1(cfd48f3)"}}

11:06:49 MQT: stat/sensor-c/STATUS10 = {"StatusSNS":{"Time":"2018-08-19T11:06:49","Switch1":"ON","Switch2":"ON","SI7021-02":{"Temperature":nan,"Humidity":nan},"SI7021-04":{"Temperature":24.0,"Humidity":57.4},"TempUnit":"C"}}

**(Please, remember to close the issue when the problem has been addressed)**
@ascillato
Copy link
Contributor

ascillato commented Aug 19, 2018

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

@JollyJames
Copy link
Author

JollyJames commented Aug 20, 2018

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?
Even the wiki uses GPIO2, https://github.com/arendst/Sonoff-Tasmota/wiki/Wemos-D1-Mini-and-DHT22-(DHT21,-AM2301,-AM2302,-AM2321)-Shield-Humidity-&-Temperature

Cheers

@Frogmore42
Copy link
Contributor

https://tttapa.github.io/ESP8266/Chap04%20-%20Microcontroller.html
Says that GPIO2 gets debug output on boot. That is likely the cause of the issue you are seeing.

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.

@ascillato
Copy link
Contributor

Hi,

Have you managed to solve your issue?

@JollyJames
Copy link
Author

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.

@Frogmore42
Copy link
Contributor

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.

@ascillato2 ascillato2 added the awaiting feedback Action - Waiting for response or more information label Aug 24, 2018
@JollyJames
Copy link
Author

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.

@ascillato
Copy link
Contributor

Hi,

Have you managed to solve your issue?

@ascillato2 ascillato2 added the troubleshooting Type - Troubleshooting label Aug 29, 2018
@wongnam
Copy link

wongnam commented Aug 29, 2018

@JollyJames When using Wemos D1 mini please note the LED on the board, it is connected to GPIO2 too.
if you connect a DHT22 to them they will be connected in parallel. For better performance you should choose a different GPIO for DHT22 input.

@JollyJames
Copy link
Author

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.

@wongnam
Copy link

wongnam commented Aug 30, 2018

Yep, try to troubleshooting if you have free time and let us know what you’re found.
In my experience, I don’t use GPIO 2 for input due to the LED is physical soldered onboard as an output, an indicator function.

@JollyJames
Copy link
Author

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?

@Frogmore42
Copy link
Contributor

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
https://github.com/arendst/Sonoff-Tasmota/blob/development/sonoff/xsns_06_dht.ino

The function DhtRead() does the transition.

@ascillato2
Copy link
Collaborator

Hi,

Have you managed to solve your issue?

@ascillato2
Copy link
Collaborator

Hi,

Closing issue as there is no feedback. Please, ask to reopen if needed. Thanks

@seidler2547
Copy link

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:

DHT: Timeout waiting for start signal high pulse

Disconnecting an reconnecting the power supply brings the sensor back - every single time.

@Frogmore42
Copy link
Contributor

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.

@Frogmore42
Copy link
Contributor

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.

@seidler2547
Copy link

Why does it work the first time it boots up? Seriallog is set to 0.

@seidler2547
Copy link

seidler2547 commented Oct 9, 2018

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.

@Frogmore42
Copy link
Contributor

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.

@seidler2547
Copy link

seidler2547 commented Oct 10, 2018

Well, in any case I still cannot find the mentioned "list of pins to avoid", at least not one where GPIO1 is mentioned.

@Frogmore42
Copy link
Contributor

https://github.com/arendst/Sonoff-Tasmota/wiki/Expanding-Sonoffs
A little ways down on the page.

@salaun29
Copy link

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,

@demian85
Copy link

demian85 commented Dec 1, 2018

Hi guys, I'm having issues with a wemos D1 mini after upgrading to v6.3
Basically, what does this mean? Timeout waiting for start signal high pulse?
I have a AM2302 sensor connected to D1, an IR receiver to D6 and a motion sensor to D5, none of them seem to work after the upgrade and all I see in the web admin is null values for the sensor :/
Sensor has a 4.7k pull up resistor.

@grgmll
Copy link

grgmll commented Apr 11, 2019

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,

can you explain me how you connected the transistor?

@Erdloch
Copy link

Erdloch commented Apr 26, 2019

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,

how do you send the highs/lows? In the Tasmota console?
Can you tell me the commands?

Thank you!

@stacklover
Copy link
Contributor

I have moved the DHT22 from GPIO2 to GPIO3(RxD) and since then no more problems.
Once you have configured a correct WLAN access, you don't need RxD anymore.

@mindvisionro
Copy link

I had the same problem, the solution was to change the power from 3.3 to 5v,
Power voltage shoud be between 3.3V and 6V DC. When power is supplied to sensor don't send any instruction to it withing one second to pass unstable status.

@matrottier
Copy link

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,

i'm interested in more details if possible

@dbummy
Copy link

dbummy commented Jul 24, 2019

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.

2019-07-24 10_44_54-Photos

@matrottier
Copy link

matrottier commented Jul 25, 2019

i tested a 2n2222 transistor on ground and GPIO1 as base.
seems to work after restart, temperature and humidity are working.
i'm using this dht22

@grgmll
Copy link

grgmll commented Jul 25, 2019

Hi, can you add a connection diagram?
Thank you

@matrottier
Copy link

sonoff_basic_2n2222_dht22
with a sonoff basic r2 and a transistor 2n2222
i have very limited knowledge in eletronic so excuse me, so i can be wrong.

@Frogmore42
Copy link
Contributor

You absolutely need a resistor on the base, ie between GPIO 1 and the base of the transistor.
https://learn.sparkfun.com/tutorials/transistors/all

I would use something between 1K and 10K ohm.

@matrottier
Copy link

relevant information, I had 2 power cuts since and each time the sonoff went into 'flashing mode'.
I guess because he was not responding anymore.
I unplugged it after unplugging the ground.

@SchefferKD
Copy link

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.

@adisah13
Copy link

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

@SchefferKD
Copy link

SchefferKD commented Apr 28, 2020

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.

@stacklover
Copy link
Contributor

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

@smalla
Copy link

smalla commented Jun 8, 2020

Try setting the pin bootmode (GPIO boot states) to Output low. For me it worked with ans ESP easy ;)

@kokein
Copy link

kokein commented Nov 8, 2020

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 :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
awaiting feedback Action - Waiting for response or more information troubleshooting Type - Troubleshooting
Projects
None yet
Development

No branches or pull requests