"Automatic Light Sleep" or "Timed / Forced Light Sleep"

[Regolsis]

Hi,

before I have found this cool ESPeasy stuff I tried to program the ESP8266 by myself. I used the following doc for setting the device into different light sleep modes without having to use the deep sleep mode and its disadvantages:
https://github.com/esp8266/Arduino/tree ... wPowerDemo

But it seems to me that with ESPeasy it is impossible to use these important sleep modes:
- Automatic Light Sleep
- Timed / Forced Light Sleep

screenshot-github.com-2022.10.08-13_17_42.png (83.39 KiB) Viewed 7380 times

Does anyone know how to use them with ESPeasy?

Why are these modes important for me: I want to make window-sensors, which should wake up when opening or closing the window. So the reed-contacts can switch from on to off (window open) or from off to on (window closed). With interrupts and these light sleep modes it would work, but not with deep sleep.

So it would be really great to be able to use ESPeasy and get my project done this way. Any hints for me? Thank you!

[TD-er]

I will for sure look into these suggested modes.
However there is for sure a difference between chip revisions, which behave different on some energy mode changes.

[Regolsis]

So there is no possibility to set the device to sleep except for deep sleep at the moment?

In CPU Eco Mode it consumes at least 20mA, which is way too high for a battery device. I tried to disable wifi (WifiDisconnect), but this also does not work. Is there any chance to shut down wifi manually and reactivate it by command? I would like to only enable it every some hours. This would be the same like "Forced Light Sleep" I think.

[TD-er]

Right now ESPEasy will retry to reconnect as soon as you disconnect.
But I am working on the WiFi part right now, and I will look into this for sure to make sure "WiFi off" is also a proper network medium to have active.

Also looking into the hints given here: https://www.instructables.com/ESP8266-Pro-Tips/

[chromo23]

@Regolsis there is an option i just made up where you can use the deep sleep mode (which might be the best option in terms of powersaving)

you use two reed switches next to each other and a magnet.....
the reed switch close to the window is always either open or closed. This one is connected to any input of the esp for determining the window state.
As you open the window it passes by the the second reed switch and gives the necessary pulse for waking up. As it wakes up it reads the gpio which is connected to the first reed switch...

Here a quick drawing of what i mean:

Bildschirmfoto 2022-10-08 um 19.40.00.png (25.33 KiB) Viewed 7358 times

[Regolsis]

Right now ESPEasy will retry to reconnect as soon as you disconnect.
But I am working on the WiFi part right now, and I will look into this for sure to make sure "WiFi off" is also a proper network medium to have active.

Sounds great. Perhaps you could also have a look into my link above at the same time, because these sleep modes are all also dependent on wifi mode and state. You only need some few commands:
- WiFi.forceSleepBegin()
- gpio_pin_wakeup_enable()
- wifi_fpm_set_wakeup_cb(wakeupCallback);
- wifi_fpm_open()
- wifi_fpm_do_sleep(time)
- delay(time+1) //delay needs to be 1 mS longer than sleep or it only goes into Modem Sleep
- WiFi.forceSleepWake()

With this set the ESP only consumes around 0,7mA in sleep mode, I did the measurement (ESP8266-12F, not D1 mini). The ESP can be awaken at any time either by end of the set sleep "time" or before by any set GPIO-interrupt. in wakeupCallback() you can check which one woke the ESP up (time or interrupt) by GPIO_REG_READ(GPIO_STATUS_ADDRESS). It is not that complicated and the ESP gets way more powerful with this functionality.

[Regolsis]

@Regolsis there is an option i just made up where you can use the deep sleep mode (which might be the best option in terms of powersaving)

Thank you! This is a good idea, but with that I can't use the automatic wake up to send alive state or battery state. This window sensor also gets temperature and humidity within the same ESP. Today I use this in an ATiny, but I want to exchange this old device by an ESP8266.

As it is only a SW-issue, see my comment above, it should better be solved by programming.

[TD-er]

Right now ESPEasy will retry to reconnect as soon as you disconnect.
But I am working on the WiFi part right now, and I will look into this for sure to make sure "WiFi off" is also a proper network medium to have active.

Sounds great. Perhaps you could also have a look into my link above at the same time, because these sleep modes are all also dependent on wifi mode and state. You only need some few commands:
- WiFi.forceSleepBegin()
- gpio_pin_wakeup_enable()
- wifi_fpm_set_wakeup_cb(wakeupCallback);
- wifi_fpm_open()
- wifi_fpm_do_sleep(time)
- delay(time+1) //delay needs to be 1 mS longer than sleep or it only goes into Modem Sleep
- WiFi.forceSleepWake()

With this set the ESP only consumes around 0,7mA in sleep mode, I did the measurement (ESP8266-12F, not D1 mini). The ESP can be awaken at any time either by end of the set sleep "time" or before by any set GPOI-interrupt. in wakeupCallback() you can check which one woke the ESP up (time or interrupt) by GPIO_REG_READ(GPIO_STATUS_ADDRESS). It is not that complicated and the ESP gets way more powerful with this functionality.

When is "gpio_pin_wakeup_enable()" introduced?
I was sure only the ESP32 could be woken up by a GPIO pin...

[chromo23]

@Regolsis there is an option i just made up where you can use the deep sleep mode (which might be the best option in terms of powersaving)

Thank you! This is a good idea, but with that I can't use the automatic wake up to send alive state or battery state.

actually you can..... just wake the esp periodically for transmitting your sensor and battery values and by using the reset it wakes up manually and sends your window state along with the sensorvalues.

Edit: it´s just a matter of writing the right rule for it

[Regolsis]

When is "gpio_pin_wakeup_enable()" introduced?
I was sure only the ESP32 could be woken up by a GPIO pin...

No, ESP8266 works fine with that (I tested ESP8266-07 and ESP8266-12F). I did implement this with success, but as I mentioned I want to use ESPeasy instead of building all functionality by self programming.

[Regolsis]

actually you can..... just wake the esp periodically for transmitting your sensor and battery values and by using the reset it wakes up manually and sends your window state along with the sensorvalues.

Edit: it´s just a matter of writing the right rule for it

I want to get the window open state right at the moment when it changes, so this would not work. With ESPeasy (as I understood) I can only use either time based deep sleep or wake up by manual reset, not both. Or does it work both at the same time?

[chromo23]

Or does it work both at the same time?

Yes..you can use rules for all of that...
I can send you a demo code if you are interested.

[Regolsis]

Yes..you can use rules for all of that...
I can send you a demo code if you are interested.

Yes, would be nice, thank you.

I read this post and TD-er replied, that it is not possible:
viewtopic.php?t=9249#p59790

[chromo23]

I read this post and TD-er replied, that it is not possible:

And he is right, thats why i suggested you two reed switches... one for the window state and one for waking up..

Here the code:

Code: Select all

On System#Wake Do
  LoopTimerSet_ms,1,100,50
  GPIO,12,1				//Turn on the sensor
  TaskEnable,1 	// Update first sensor
Endon

On WiFi#Connected Do
  Let,1,1
Endon

On sensor_extern#All Do
  Let,2,1
Endon 

On Rules#Timer=1 Do
  If [var#1]=1 and [var#2]=1	//when wifi is connected and there are values from the sensor send data
    //send your stuff... in this case to thingspeak
    SendToHTTP api.thingspeak.com,80,/update?api_key=XXXXXXXXXXXX&field8=[batterie#Analog]&field4=[sensor_extern#Humidity]&field7=[sensor_extern#Pressure]&field3=[sensor_extern#Temperature]&field5=[window#state]	 	
    TimerSet_ms,1,0
    TimerSet_ms,2,10 
    Let,1,0
    Let,2,0
  Elseif %eventvalue2%=50 //if nothing happend during 15sec of beeing on go back to sleep
    TimerSet_ms,2,10 
  Endif
Endon

On Rules#Timer=2 Do //after sending data either go to sleep or if powercycle wait 30sec
  If [boot#isboot]=1
    DeepSleep,1800 //comment this out to stop deepsleep
  Else
    TimerSet,2,30
    TaskValueSet,boot,1,1
  Endif
Endon

Code: Select all

[boot#isboot]

is a dummy device to determine whenever it was a powercycle (the value is lost in this case) or not

[Regolsis]

Code: Select all

[boot#isboot]

is a dummy device to determine whenever it was a powercycle (the value is lost in this case) or not

Thank you.
Ah, that's the trick to differentiate between manual reset and auto timer deep sleep? The value is kept on manual reset but not on auto wake up?

What do you mean with "powercycle"?

[chromo23]

right now it doesn’t determine between manual and auto wake up... why would you need it... every time all your data is send....
you could change the rules to determine a manual or auto wake... just look for a state change of the "window-switch". If it hasn’t changed it is a auto wake up.
powercycle means you disconnect and reconnect the esp from power and than have a 30sec window of accessing the webui. (the same behavior as if you would set the "sleep mode" in the config tab)

Edit: sorry but i am not very good in explaining and i also have someone sitting next to me who is waiting to start the movie

[TD-er]

Yes..you can use rules for all of that...
I can send you a demo code if you are interested.

Yes, would be nice, thank you.

I read this post and TD-er replied, that it is not possible:
viewtopic.php?t=9249#p59790

Well, what do I know...
I will for sure look into the option to wake by pin on ESP8266.
For ESP32 it is at least implemented to send an event with the pin state of some pins.
I know the ESP32 can be programmed to wake by a specific pin, or even some touch level. But that's not yet implemented.

[Regolsis]

right now it doesn’t determine between manual and auto wake up... why would you need it... every time all your data is send....
you could change the rules to determine a manual or auto wake... just look for a state change of the "window-switch". If it hasn’t changed it is a auto wake up.
powercycle means you disconnect and reconnect the esp from power and than have a 30sec window of accessing the webui. (the same behavior as if you would set the "sleep mode" in the config tab)

Edit: sorry but i am not very good in explaining and i also have someone sitting next to me who is waiting to start the movie

I don't understand

After deep sleep timeout System#Wake is called. But System#Boot is called on power off and on? In your rules there is only wake, so there is no difference between deep sleep timeout and manual reset? I thought manual reset is a reboot.

[Regolsis]

I will for sure look into the option to wake by pin on ESP8266.

Thank you, I am really looking forward to this.

For ESP32 it is at least implemented to send an event with the pin state of some pins.
I know the ESP32 can be programmed to wake by a specific pin, or even some touch level. But that's not yet implemented.

Are these events related to deep sleep? Because I think the light sleep modes are way more powerful and more easy to use in implementations, rules etc. Very strange that neither ESPeasy nor Tasmota nor ESPHome use these light sleep states as they would bring so much more possibilities in comparison to deep sleep, which is not a real sleep, but kind of reboot.

[TD-er]

[...]

Are these events related to deep sleep? Because I think the light sleep modes are way more powerful and more easy to use in implementations, rules etc. Very strange that neither ESPeasy nor Tasmota nor ESPHome use these light sleep states as they would bring so much more possibilities in comparison to deep sleep, which is not a real sleep, but kind of reboot.

They also bring a lot of head-ache for the devs as WiFi stability (from a programmer point of view) is an absolute nightmare on ESP8266/ESP32.
If you have a chip/board which behaves nicely, then it is really simple to operate WiFi.
However there are so many edge cases which are hardly documented and more often than not absolutely not documented at all

Doesn't mean I disagree with you about the extra potential. Quite the opposite!
I would love to have proper low-power applications.
But given the true nightmare nature of Espressif WiFi, I totally understand why "the others" don't have this implemented.

I will for sure look into it and hopefully this isn't another box Pandorra left out there.

[Regolsis]

However there are so many edge cases which are hardly documented and more often than not absolutely not documented at all

You are wrong: These "features" are not hardly documented, but they are nice easter eggs from our "Chinese fliends"

But given the true nightmare nature of Espressif WiFi, I totally understand why "the others" don't have this implemented.

I am not sure, but it seems not to be very well known (missing detailed documentation could be the cause). Even outside of these frameworks mostly deep sleep is the standard topic with ESP8266, there is not much about light sleep. Although these different sleep modes are very often used with Arduinos and ATinys. It is strange.

[TD-er]

Sure the features are known, but there are so many issues with the WiFi which may be not common knowledge.
Most users who program for the ESP8266 do so for very specific use cases and thus on a very limited set of hardware.
The firmware versions with a larger user base will find out very soon that lots of boards act different and WiFi is then one of the first things to fail or "act strange".

I know Theo (from Tasmota, he lives about 20km from me) and some of the other devs I also "speak" regularly through issues regarding ESP's. They all will agree that the WiFi code for ESPs is something they rather not dare to touch as it may stop working by simply looking at it.

[Regolsis]

They all will agree that the WiFi code for ESPs is something they rather not dare to touch as it may stop working by simply looking at it.

[chromo23]

After deep sleep timeout System#Wake is called. But System#Boot is called on power off and on? In your rules there is only wake, so there is no difference between deep sleep timeout and manual reset? I thought manual reset is a reboot.

My solution is for the esp8266 only (and under the condition that you understood my idea of two reed switches next to each other)

from https://randomnerdtutorials.com/esp8266 ... duino-ide/

After putting the ESP8266 in deep sleep mode, there are different ways to wake it up:

#1 timer wake up: the ESP8266 wakes itself up after a predefined period of time
#2 external wake up: the ESP8266 wakes up when you press the RST button (the ESP8266 restarts)

It doesn’t matter how you wake it up... what matters is, that it wakes up either way.
So your regular waking up to send sensor data you archive by connecting GPIO 16 to RST and then periodically pull RST low (archieved by the "DeepSleep" command )
And the window detection wake up you manage by manually pulling RST TO GROUND via thew reed switch.

My code is maybe also a bit confusing since i copied it from my weatherstation which is optimized to put the esp back to sleep as fast as possible...
But what is basically does ist, sending something after a wake and puts the device with "DeepSleep,1800" back to sleep if the "boot#isboot" vlaue is 1
This value doesn’t change during wakeups but gets lost (backt to zero) when you disconnect and reconnect the powersource. If this happens, the "DeepSleep,1800" command is issued after 30seconds.
So you have time to log in and change things (e.g. disable deepsleep by commenting it out)

Edit: I could also have used Sytem#Boot in my rules.. it doesn’t matter in this case. I thought system#wake is processed before system#boot. That’s why i choose it..

[Regolsis]

My code is maybe also a bit confusing since i copied it from my weatherstation which is optimized to put the esp back to sleep as fast as possible...
But what is basically does ist, sending something after a wake and puts the device with "DeepSleep,1800" back to sleep if the "boot#isboot" vlaue is 1
This value doesn’t change during wakeups but gets lost (backt to zero) when you disconnect and reconnect the powersource. If this happens, the "DeepSleep,1800" command is issued after 30seconds.
So you have time to log in and change things (e.g. disable deepsleep by commenting it out)

I understand: In normal function the sensor sends all 30min its data and goes back to sleep. But to update or access the device you disconnect and reconnect power, so after this reboot it stays some time awake to access the web interface.

OK, so there is no difference between manual reset (not power off/on) and timed wake up from deep sleep, in both situations System#Wake is called and you cannot find out how it has woken up.

With light sleep modes you can find out by GPIO_REG_READ(GPIO_STATUS_ADDRESS).

[chromo23]

I agree, that other sleepmodes are more powerful. But in a simple usecase like yours the deepsleep with the only downside of a second reed switch has in terms of powerconsuption (20uA compared to at least 400uA) a huge advantage when powered by a battery.

[chromo23]

you cannot find out how it has woken up.

In your case you can!
When the window-state has changed it was a manual (reed-switch) wake up and if not it was an automatic one...

[Regolsis]

you cannot find out how it has woken up.

In your case you can!
When the window-state has changed it was a manual (reed-switch) wake up and if not it was an automatic one...

As the dummy device keeps the last state, even during deep sleep, I could know this, yes, now I understand, what you mean.

But I have another use case with 2 different reeds with different functions (mail notification): After someone throws in a letter, I want to get notified by wifi and an LED blinks outside the box, until I open the front door of the mailbox. Also the mailbox should send me battery info every x hours. This would be really complicated with only deep sleep, also because sometimes the mailbox lid stays open or is closed very fast, so even with 2 doubled reeds this would not work fine. I installed the wires in the mailbox (runs with Arduino since several years now) and I don't want to make it all new.

[Regolsis]

When the window-state has changed it was a manual (reed-switch) wake up and if not it was an automatic one...

I found this project:
http://www.whatimade.today/esp-8266-mai ... and-blynk/



This circuit works with only one reed-contact. But it wakes the ESP up only in "one direction". Do you have an idea, how to change this to wake up the ESP in both "directions", on opening and closing the reed?

[TD-er]

Maybe use a coil instead of a reed contact?
This coil then could trigger a FET which can remain open by its own current.

[Regolsis]

Maybe use a coil instead of a reed contact?
This coil then could trigger a FET which can remain open by its own current.

A coil does not have an open or closed state. I must be able to read out the reed contact after wakeup.

[TD-er]

I know, but that's why I suggested to add a FET to it as a "sample and hold" kind of idea.
A simple FET and capacitor could do the trick.
Just make sure the capacitor can be discharged in due time and will not be charged by the GPIO while it is in sleep. Maybe add some diode with low leak current inbetween.

[chromo23]

This circuit works with only one reed-contact. But it wakes the ESP up only in "one direction". Do you have an idea, how to change this to wake up the ESP in both "directions", on opening and closing the reed?

One reed switch a bit further away from the magnet would do the trick...so it would pulse every time the magnet passes (just like in the window-open detection suggested by me)

Another thought for your mail setup would be to keep it as it is and just add an esp. The Arduino could then power on the esp with a transistor (fet) and maybe pass some infos via serial or gpios. the esp sends its data then over wifi and the arduino turns it off afterwards...

[Regolsis]

One reed switch a bit further away from the magnet would do the trick...so it would pulse every time the magnet passes (just like in the window-open detection suggested by me)

That's the problem: 2 reeds and 1 magnet and 1 reed has to be way away from the other. So this would result in a not nice installation. At the moment I use a small TicTac-box.

Another thought for your mail setup would be to keep it as it is and just add an esp. The Arduino could then power on the esp with a transistor (fet) and maybe pass some infos via serial or gpios. the esp sends its data then over wifi and the arduino turns it off afterwards...

Way too complicated. I really don't want to work with 2 complete different systems, I want to replace all the old stuff (7-8 years) with ESPs only.

[Regolsis]

I know, but that's why I suggested to add a FET to it as a "sample and hold" kind of idea.
A simple FET and capacitor could do the trick.
Just make sure the capacitor can be discharged in due time and will not be charged by the GPIO while it is in sleep. Maybe add some diode with low leak current inbetween.

If the ESP would light sleep, the solution would be so easy

I already was able to install the whole set to compile ESPeasy by my own, but I have no idea how and where to implement it. Seems not to be solved by a plugin, but I am not sure.

[chromo23]

That's the problem: 2 reeds and 1 magnet and 1 reed has to be way away from the other. So this would result in a not nice installation. At the moment I use a small TicTac-box.

No i meant only one reed-switch (as a replacement for your whole circuit). just for waking up in every direction. place your tic tac box a bit further away from the magnet.
I guess you will not get around a second switch for state detection. I doesn’t need to be a second reed-switch. You could also use a microswitch..

And by the way, two reed-switches would still fit perfectly in a tic tac box next to each other. they can be placed almost side by side for the 2-reed solution. (it depends then on the strength/ placement and direction of the magnet)

[chromo23]

If the ESP would light sleep, the solution would be so easy

But how do you deal with the massive increase in power consumption than (assuming your setup uses a battery only)

Edit: and let’s not forget.. it would only be easy if somebody is implementing it. this is work too. it is easier right now to buy and install a second switch than writing and testing code for it...

[Regolsis]

And by the way, two reed-switches would still fit perfectly in a tic tac box next to each other. they can be placed almost side by side for the 2-reed solution. (it depends then on the strength/ placement and direction of the magnet)

Could be, but it is too complicated to set this thing up on a window and keep it working. When handling with a window every day several times, there will be some efforts to adjust magnets and reeds every day.

[Regolsis]

But how do you deal with the massive increase in power consumption than (assuming your setup uses a battery only)

Edit: and let’s not forget.. it would only be easy if somebody is implementing it. this is work too. it is easier right now to buy and install a second switch than writing and testing code for it...

I have a small li-ion battery and a very small solar panel attached to the window, which works since 7-8 years now without fail. So this 0,5mA power does not really matter in light sleep.

[Regolsis]

In the meantime I found a solution using an XNOR-gate: Now the ESP wakes up on rising and on falling edge of the reed-contact. I don't know, why I have to use a transistor to lower down RST, because the XNOR-gate output pin seems not to be powerful enough to pull down the RST-pin.

Yesterday I build 3 of these sensors and they all work very well. In deep sleep they use about 50uA.

Schaltplan Fenstersensor.png (35.52 KiB) Viewed 6568 times

photo_2022-10-28_17-54-59.jpg (177.82 KiB) Viewed 6568 times

[TD-er]

Just curious how you're measuring 50 uA?
You can't measure it using a multimeter, because of the "burden voltage".
A multimeter needs a resistor in series with the load and measures the voltage over this resistor.
However for small current ranges, this resistor needs to be of quite large resistance and thus you cannot properly measure the load of an ESP as there will be quite a lot from the Vcc as voltage drop over this resistor.

[Regolsis]

I use a normal multimeter with mA and uA scale. Of course I am not sure if this is super correct, but I can see the tendency quite clear. So it doesn't matter if it is 30uA or 80uA, but it is really energy efficient, which the none decreasing voltage of my battery does also proof.

[TD-er]

OK, just keep in mind you probably have quite a large error in your measurement.
60 uA does seem quite plausible considering the Espressif datasheets, but that also means you have chosen excellent other components with really low quiescent current.
When using a multimeter, you can have a measurement error on really low currents with can be off by upto 2 orders of magnitude. (thus upto 100x) Thus rendering the low current range of a multimeter essentially useless. (in this range a factor of 10x as worst case error is more likely)
This makes it really hard to estimate battery life based on these measurements.

[Regolsis]

Yes, the XNOR does not use any measurable current and the voltage divider has high resistors. Also the HT7333 LDO uses very little current. I think the measurement is correct, because the battery shows nearly no drop over night with the ESP-sensors sending every 15mins in my test.