ESP-01 - sleep configuration not working

[parabacus]

Hello!

I have problems with sleep configuration - in my case on a ESP-01 device flashed with ESP_Easy_mega-20200410_normal_ESP8266_1M.bin.

I have connected GPIO 16 to RST to get sleep functionality and I am sure that the device itselfe is working correct because I tested it with a dooropener application wich I use since about 2 years. This application was written an flashed with arduino.

Now I want to use the ESP-01 with ESPeasy connected with a temperature sensor DHT11 for monitoring my greenhouse. For this I use the DHT11 shield
The ESP device is connected with my FHEM instance on a RasPi and this is working fine - means that I get the values for temperature and humidity.
Now I want to set sleep state - for example 20 sec active time and 5 min sleeptime because I want to drive the ESP with battery. For this I confugured Sleep awake time to 20 and Sleep time to 300.
I expected that the device will sleep for the configured time, gets active for 20 sec for sending some samples (e.g. every 5 sec) and falls in sleep mode again.

Now the problem description:
After power up the ESP sends its samples to FHEM, where I can see the expeced samples every 5 sec. At FHEM the Sleep info shows me the 20 sec and the sleepState shows awaked for 20s (-1s) which changes to sleep awaited in 1s and then to sleeping. So far so good - but it won't wake up after the configured time! The web interface of the ESP is not reachable because it is really sleeping.
Only the manual reset will start the ESP device new but in some (alomst all!) cases only when hitting the reset button twice.

A test with a second ESP-01 with the same image and exactly the same configuration sends its samples continuously! This ESP shield is an oder one - maaby it is broken.
Here I can see also the state changes of the sleepState ( awaked for 20s (-1s) -> sleep awaited in 1s -> sleeping) but right after this it starts the next sequence without sleeping and the web IF will be reachable all time.

The next test with a third ESP-01 - now with a older version of ESPeasy (mega-20181125) and exacltly the same configuration shows the first behaviour.

Because I used sleep mode with a Wemos D1 before I tested this configuration on such a device! This works perfecly from the start!!

Now I am completley confused...!

[TD-er]

Is it possible one of the pins that should be in a specific state at boot are not in that state?
See: https://espeasy.readthedocs.io/en/lates ... on-esp8266

As you can see, GPIO 0, 2 and 15 need to be in a specific state at boot.
Waking up from deep sleep is a special kind of boot.

[parabacus]

I tried this by connecting a 10kOhm resistor on both Pins GPIO 0 an 2 - the only available I/O-Pins of the ESP-01, but the behaviour is the same like before.
I think an external pull up is not really needed and some informations due to GPIO16 is documented in the link you have posted.

GPIO-16 is a special pin. The RTC will send a short (low) pulse when the sleep timer does send a wake-up signal.
In order to wake from deep sleep, GPIO-16 has to be connected to the RST pin. If connected, this pin should not be used as GPIO pin, or else the module will reboot.
Other limitations are:
. GPIO16 has a built-in pull-down resistor (all others have built-in pull-up)
. To enable the pull-down resistor for GPIO16, you have to use INPUT_PULLDOWN_16

My interpretation: All needed pins have an internal pull-up resistor.

I searched a lot today and I have seen that many problems occured by using deep sleep with a ESP-01, but all was solved with arduino-sketches - nothing found with ESPeasy.


My latest test was removing the task for the DHT11 and without the DHT11 shield to eleminate any influece of this. To see, if somthing is sent to FHEM I configured the "Generic System Info" RSSI to be transfered.

With this test I observed some interesting behaviour:
- After power up the RSSI was transfered cyclic for the configuerd "Sleep awake time".
- Then the ESP falls into sleep mode.
- If the time "Sleep time" was expired the blue LED flashes shortly. Then only one cklick on the reset button starts the transmission new.
- If the time "Sleep time" was not expired, two cklicks on the reset button are needed!

If the resistors on GPIO 0 and 2 are connected or not doesn't matter.

My first idea was - is it possible, that the configuration of INPUT_PULLDOWN_16 doesn't work and therefore the wake mechanism will not be triggered? But why does ist work with external reset button?
Or is the register value (RTC?) for the delay (sleep awaited in 1s) not written correctly and therefore the reset will not occure? Because the LED flashes after expiration of "Sleep time" this also improbably.

My reasonable suspicion ist that the wifi module isn't activated correctly after expiration of "Sleep time"!

Because no external influence is given now I think this is a bug in the ESP-01 or in ESPEasy. - ...or the bug in ESP-01 has no workaround in ESPEasy till yet.

I think for the ESP-01 a other or a second command is needed to wake up the device AND wifi module - or when sleep is initiated is has to be configured that for the next wake up the wifi module hast to be started too.
With the WEMOS D1 it works fine the whole day.

[TD-er]

Well to address all points you made (not saying those are the solution, but to help you understand how things work)

GPIO-0 and -2 have to be pulled up at boot.
So if you have some sensor connected to them, then this sensor may pull them down at boot time.
That's why I mentioned them.

Waking up from deep sleep is the same as a reboot.
Only difference is that we write in some special memory (that will keep its data as long as the unit is powered) our intention of shutting down + we set a timer to wake up.
GPIO-16 does send a pulse to the reset pin, the same as when you reset the unit yourself.

If you set the INPUT_PULLDOWN_16 state, or have some sensor connected to GPIO-16, then this may have an effect on the reset functionality.
GPIO-16 is not wired the same as the other pins.
The only thing GPIO-16 can do, is pull the pin down using its internal pull-down resistor. (other pins have an internal pull-up resistor)
The reset pin is wired using a pull-up resistor.
So when you press the reset button, you will pull that pin low.

For the ESP01, you need to solder a wire to a very hard to reach place on the ESP8266 chip.
See: https://randomnerdtutorials.com/esp8266 ... duino-ide/

Right next to this GPIO-16 pin, there is the CHIP_EN pin.
The chip_en pin has to be pulled up, or else the ESP will not boot at all.
So if you touch both pins (GPIO-16 and the CHIP_EN), you will get strange results when trying to reset/reboot the node.

[parabacus]

Thank you for your detaild answer!

But I think I have done it all well.

GPIO 0 an 2 are pulled up to VCC with 10kOhm resistor.
GPIO-16 is solderd to ESP-01-Pin RST and here a push button is conneced to ground to perform the manual reset.
CH_EN is pulled up to VCC directly on the ESP-01 shield.
At the moment no sensor or something is connected. The ESP-01 ist working stand alone - see atteched picture.
No additional code in the rules. The INPUT_PULLDOWN_16 state is not set by me.
https://www.letscontrolit.com/forum/dow ... ew&id=4831

I have tried it with four different ESP-01 modules and all devices will show identical behavior!

Now I'm at the end of my investigation. No idea...!?!
Do you need screenshots from ESPEasy config pages?

[TD-er]

Do you have a detailed picture of how you soldered the wire from GPIO-16 to the RST pin?

[parabacus]

it was not quite easy..

https://www.letscontrolit.com/forum/dow ... ew&id=4832

[ThomasB]

Plugging the ESP-01 header into a typical breadboard, as shown in the photo, will bridge (short) adjacent header pins together. This could cause some signal conflicts because the breadboard has continuity across each row of pin holes. In other words, GPIO-1 would bridge to GND, EN would bridge to GPIO-2, RST would bridge to GPIO0, and 3.3V would bridge to GPIO-3.

If your breadboard is wired this way then the board might not boot during the wake-up event. That's because GPIO-0 would be tied to RST which is driven low at wakeup by GPIO-16. This would cause boot failure because GPIO-0 needs to be high to enable the reboot.

But if you've cut some header pins off to avoid this situation then you should be good to go. But as a sanity check, get out the ohmmeter and reconfirm all header pins are isolated from each other.

- Thomas

[parabacus]

Hello Thomas,

the ESP-Shield is not pluged directly into the breadboard. It ist not the first one I use this.
The behaviour is also shown if the ESP-shield is working only stand alone - without any breadboard, sensor shield pluged - only the ESP with the required wireing of VCC, GND, CH_EN pulled up, GPIO-16 brideged to RST!

[TD-er]

[offtopic]
I keep seeing a squirrel in that "2" on the label
[/offtopic]

I'm a bit out of ideas here to what it could be.

Just for test, can you test a really old build (e.g. something end of 2018) to check the wiring is at least OK?
It could be something core related.
For the 1M builds we use a different board definition compared to the 4M builds.

[parabacus]

I have done this before - see infos in my first post:

The next test with a third ESP-01 - now with a older version of ESPeasy (mega-20181125) and exacltly the same configuration shows the first behaviour.

To be sure haven't made a mistake I tried it once again. First I flashed the blank image to delete all former informations/configurations because I determined that not all will be erased by flashing another image. Then I flashed ESP-mega-20181125_normal_ESP8266_1024.bin. Now no sensor shield was connected. Only the transmisson of generic system info RSSI is configured.

...and all behavior is the same - power up => transmisson of RSSI for "awake time" => sleep => no wakeup after configured "sleep time" (only short flush of the blue LED) => one hit of reset button initiates wakeup.
If I hit the reset button right after entering sleep mode, a second button hit is needed.

I'm sure that I dont make any mistakes - there is any bug...

Is it possible for anyone to try it on a real ESP-01 shield for verification?

[TD-er]

Not ruling out the option that there might be a SW bug.
But if it is also not working as it should on an old build, then I think something hardware related is more plausible.
Otherwise we would have had lots of reports from other users.

There might still be a short somewhere in the GPIO-pin to some other pin (the EN pin is the most likely given your description of the symptoms)
It can also be a short below the ESP, where you don't see it.

[parabacus]

I don't maintain that it is a SW bug - more I think it is a abnormality of the impemented core in the ESP-01.

In the meantime I have used six different ESP-01 shields and all devices show the identical behaviour!
A short between pins doesn't exist - not on six differnt devieces and with the same effect.

Because the WEMOS D1 works perfectly with the identical configuration I am rather sure that it is a HW related bug in the ESP-01. But I am also sure that this coud be fixed per SW.

I will check all ESP-01 shields...

[parabacus]

I have checked all my ESP-01 shields with Ohmmeter - no short between adjoining pins and no short between every pins - all values are in a high mega-ohm-value, except between VCC and RST - here I can see about 12kOhm, but all shields (also unused new one) showing this.

No HW related problem with my composition!
Please trust me - I am 49 years, trained radio & TV technician with 7 years practice and a electronic engineer with a diploma. Since over 20 years I am working in the automotive industry and the first 10 years as a embedded SW engineer.

[Micha_he]

Maybe try a external pullup-resistor like 100k from GPIO16 to Vcc. ESPEasy implemantation of the internal pullup/pulldown on GPIO16 is somewhat unclear

I mean this thread: https://www.letscontrolit.com/forum/vie ... 004#p26004

[parabacus]

no success...

@Micha_he: Have you solved your Problem?

[ThomasB]

I searched github and found other reports of this issue. A couple good reads:
https://github.com/esp8266/Arduino/issues/6007
https://github.com/esp8266/Arduino/issues/5892

TL;DR: Wakeup from sleep does not work on some ESP8266 modules. Some speculate it is due to the board layout of some clone modules (insufficient trace width on supply rails). Some suspect the reset filter circuity. However, one fellow solved the wakeup issue by slightly increasing the 3.3V supply. Another guy fixed it by changing the flash memory chip. A few solved it by using a different ESP8266 module.

- Thomas

[TD-er]

Hmm that sounds like the wake pulse may not be a very clean square wave pulse (and probably not long enough)

There have been similar reports with the ESP12S modules (some of them), where there was an extra capacitor over GPIO-16, which would cause a very slow rise of the pulse and thus a pulse that was too short. See: https://www.esp8266.com/viewtopic.php?f=6&t=17975
Not sure how the mentioned "450 Ohm resistor" can fix this, or how it should be placed. (maybe instead of a direct wire between RST and GPIO-16 ?)


Maybe you can put a scope on the signal to see if this may be the problem here?

[ThomasB]

Hmm that sounds like the wake pulse may not be a very clean square wave pulse (and probably not long enough)

That was what others had speculated. But if you read those two links very carefully, it does not appear it is the main culprit. Especially since a small minority of the affected boards also exhibited manual reset issues (two pushes required).

If I had to tackle fixing this issue I would first suspect the power rail. For example, insufficient Vcc-Ground trace widths and/or decoupling caps inside the wifi module. Both the 8266 and the memory chip seem to be critical about the voltage quality; And there's a current spike at reset that I suspect could invite problems on a poorly designed module.

- Thomas

[parabacus]

Okay.. - I am not crazy... or incompetent!
This sounds like a bigger problem over some model and hard to find.

Because I have no scope at the moment (not at home) it makes little sense for me to test some of the suggested problem solving.
At meantime I used different power supply but in all cases I hat the same behaviour.
Tomorrow I will test the resistor between GPIO16 an RST - that's an easy test.

[TD-er]

If it is indeed related to power lines, then maybe also place a capacitor as close as possible to the ESP module.
For example 100 nF as close as possible and something around 22 uF (used on most NodeMCU/Wemos boards) also close to the power pins.
To overcome the power surge during RF-calibration you may also want to add something like 180 - 330 uF.

[Micha_he]

@parabacus: Yes, I've solved the problem on my battery-powered window-contact with a 1,2MOhm (high value to reduce standby current) resistor.
But my probem was not exactly the same as yours. My ESP-01 didn't go into deepsleep-mode safely, when powered >3V. But the reset in my circuit is via a external contact.

When I found some time, I'll do a test with my ESP-01 and a wire/resistor from RST to GPIO16 and report it here...

[parabacus]

I have the sense of security that the behavior is different and depnends on the manufacturer of the devices. As I read somtimes the ESP will not go to sleep (like your problem), doesen't wake up from sleep mode or sometimes it would boot again right after entering sleep mode (I have also such a device too). Firstly I need a scope to do detaild investigations but becaus of corona I am in home office since about 12 weeks and now I am holidays at home.
Because I identified this problem only by playing with the ESPs it has no urgency for me at the moment.

[parabacus]

One little finding today...

I have flashed my dooropener sketch to the "buggy" ESP device. This depends on a sleeping ESP-01 which will woke up per hard reset (RTS to ground) and sending a sepcial command to my FHEM instance.
Here I can also observe that two hits of the reset button are needed. But the installed dooropener only need one push everytime!

I have looked to the two dooropener push buttons which I have installed in our house. In both a ESP with a lable "AI-Cloud inside" are installed.

So I looked to the diffences:

A) Flash device:
On the ESP-01 devices that I have many different flash typs are installed.
It could be that the flash in case of the "AI-Cloud" performe the startup in the right way (P25Q80H) and in the other versions, it will not work correct (25Q80cSIG, FT25H08).

B) Clock generation:
In the "AI Cloud" a differnet looking (bigger) clock generator is installed.

[TD-er]

If you suspect flash chips, you can also have a look at the sysinfo page.
There's the flash type and vendor mentioned.

[Micha_he]

I've checked the 'ESP_Easy_mega-20200410_normal_ESP8266_1M.bin" with my (modified with 680k between Vcc and GPIO16) ESP-01.
Same settings and the ESP-01 goes safe in deepsleep for 300s, wake up, send 4 sets of generic-sysinfo-data to my MQTT and goes in deepsleep again.

The problem doesn't seem from ESPEasy.