deepsleep : adding command to select wake up pins on ESP 32

[ouinouin]

Hi, actually the deepsleep on esp 32 is time based but can also support wake up pins.
apparently esphome already implements the wake up pins.
i was thinking first the functionality to be impelemented as a component, but while the system is up, the gpio can have a different role so might be a command would be a better choice.

as having very few capacities in C, is this addition doable easily ? what do you think about this idea , this could help to tasmotize some (few for the moment i admit) battery powered devices, or other interresting devices like the M5stack range of products.

I m trying to get this working in order to make work the AbuttonV3a from april brother, wich is to my knowledge the only button available with the case AND having schematics. LED on the button is actually working.

[barbudor]

Hi
The problem is not just adding pins to wake-up the ESP32.
The DeepSleep process in Tasmota has been designed with only 1 goal in mind : periodic wake-up to read sensors, publish the result and get back to sleep.
When Tasmota wakes up, it get the time from NTP as usual, compute the time for the next wake-up and after the telemetry message, it will go again to sleep. If Tasmota found out that he woke up at at time different than the expected time, it will go straight to sleep before the telemetry message.

So it's more than just adding wake-up GPIOs, it's about supporting new use-case that needs to be precisely described before starting to code.

So tell me more about your use case.
What is this device ? As you said there are schematic, please share them.
What would be the use case ? What Tasmota would do when woken-up ?

[sfromis]

Hypothetically, one plausible use case could be for some sort of alarm, to report when a switch input has tripped, ideally able to report which pin was triggered, even if the signal is no longer present when Tasmota has booted. One example could be at a front door, with inputs for door open/close, lock/unlock change, doorbell pushed, letter slot opened/closed, PIR inside/outside triggered, and maybe also a window beside the door. Wired power may be inconvenient there....

[barbudor]

As Tasmota is mostly event-driven, how would you like to be made aware after boot of the wake-up reason ?
An automatically generated MQTT/JSON such as { "WakeupReason": { "gpio": 23, ....} } that could be parsed by a rule, Berry or Scripting ?
Should this be a sent as early in the boot process only to the rule engine even if no MQTT connection is active ? or wait for the MQTT connection ?
And how do we go back to sleep ? A new DeepSleepNow command that do not program a wake-up time ?

Let's define what we want to do with it and how
Coding is just the last easy step

[sfromis]

One way of passing data could be as a RestartReason. This is now included in the JSON payloads published to MQTT, but also available to rules without MQTT having connected, and available via Status commands, the latter being convenient for Berry, especially if available early at autoexec or even preinit time. Going to sleep could indeed be a new command, or maybe something like DeepSleepTime -1.

Of course, things also depends on what's practically feasible, like if it is possible to record activity on more than one wakeup pin, after the first has initiated the wakeup. The value of having multiple wakeup pins does suffer if only the first can be reliably recorded.

Maybe a "full" solution would entail support for the ULP coprocessor of ESP32.....

[Jason2866]

ULP is NOT available on all ESP32 MCUs. Imho to special for a general solution

[ouinouin]

Hi,
the first step would be to be able to wake the esp32, then there is effectively the problem to gather if possible the data : from where was i woken up.
the target is :
https://wiki.aprbrother.com/en/AButton_V3.html#about-the-project
schematics
source code

it is basically a fairly simple button, but believe me, the battery powered buttons (that are not oddious diy devices) are really something missing in the esp8266 / esp32, i think the april brother project is a simple one and easy to step in to start with this subject.
ecosystem i already gave a try with a swiss esp8266 button (mystrom) but couldnt get all the secrets out of it. I can remember by checking the swiss button source code avail on github that they were not even doing a deepsleep on their esp8266.

the esphome support the deepsleep with wake up pin option from esp32 , maybe there is some inspiration to be found in their code ?
https://esphome.io/components/deep_sleep.html#deep-sleep-prevent-action

a problem i could see is to lock deepsleep timer with a command that doesnt write anything to flash , since when you write deepsleep 0 in a rule or something, i suppose its writing to flash so if you want to stop the deepsleeep timer, you ll wear the flash rapidly.

[Jason2866]

Still the first step is missing. Defining ALL wanted use cases. Design a concept for all. Start coding with the most wanted feature.
Projects which do just wake up and do a fixed defined action are very different from Tasmota and
the way how it is done is probably not a possible way to implement in Tasmota.
Tasmota is way more complex.

[ouinouin]

for me we dont need as a first step to use the ULP, i ve looked for some example, it seems complicated as involves directly assembly code , and the use cases are maybe far from diyers reality.

for me the good use cases are :
a button /whatever inpu triggering the boot of the system (unfortunately it seems impossible to then get wich gpio was activated).
with this use case you can cover diy PIR sensors or any other sensor with thresholds integrated for example where the motion sensor pulls a pin high or low.

we know that there will be strong limitations to try to implement every use cases for low power but using gpios as wakeup pins can lead to interresting "semi-lowpower" systems

• the user press the button.
• esp 32 boots and gives reason of boot (gpio or RTC basically)
• execution of any rule ON rtcwakeup do.... ON gpiowakeup do...
• esp32 goes to deepsleep after a timer or after triggering the deepsleep by another rule or by the deepsleep timer

[barbudor]

I will start thinking about this

@sfromis The RestartReason is in INFO3 but all 3 INFO messages are skipped on DeepSleep wake-up, probably to reduce time and avoid recurrent unnecesarry boot info
But in that case, may be INFO3 could be kept...

[pearson]

Has there been any progress on this?

I've run into a simple use case where wakeup on GPIO would be very useful: a battery operated ESP32 connected to a reed switch. When the reed switch is triggered, I want the ESP32 to wake up and send a message. This would be useful for many tasks, such as monitoring whether a door is closed or not.

In point form, the use case is:

• wake up on GPIO to send a message that the GPIO changed, such as a door monitoring reed switch
• wake up on timer for routine check-ins with the server

[ouinouin]

hi, i m still interrested by this subject, i ve seen the ULP berry stuff and will try to get some results from this, but so far its a lot of job just to say : i want to wake with GPIO4. I hope the guy who develpopped th ulp extension with berry will cross this post and help us to achieve the GPIO wake functionality.
@barbudor the really nice application i can see for that is : to be able to make usable wifi buttons and wifi motion sensors , this would really be a great addition to the ecosystem.
i m actually pimping anx outdoor battery solar powered light as you can buy on amazon. getting a gpio wakeup woul give access to put some tasmota on those kid of devices easily :-)

[Staars]

I will try to create an example for your use case. The ULP should be able to do this.

[Staars]

Just for completeness, here is an adapted example from the ESP-IDF for the ESP32 (FSM type ULP). The resulting code snippet could serve as a base for an individual solution. You can paste this to the Berry console.

import ULP
ULP.wake_period(0,20000)
var c = bytes().fromb64("dWxwAAwAzAAAABgAgwOAcg8AANA8AIBwEAAJggkBuC4wAMBwKAAAgAkB+C8PASByMADAcBAAQHIzA4ByDwAA0DMAAHAfAEByVABAgFMDgHJCA4ByDwAA0AsAAGgAAACwQwOAcg4AANAKAABycABAgBoAIHIOAABoAAAAsFMDgHJCA4ByDwAA0AsAAGgzA4ByDgAA0BoAAHIaAEByDgAAaGMDgHIOAADQGgAAcg4AAGhzA4ByDwAA0C8AIHC4AECAAAAAsDAAzCkQAEByuABAgAEAAJAAAACw")
ULP.load(c)
c = nil
var gpio = 0 # change me
var rtc_io_num = ULP.gpio_init(gpio,0) # GPIO to input 
ULP.set_mem(55,3) #edge_count_to_wake_up, debouncing does not seem to be perfect
ULP.set_mem(56,rtc_io_num) #rtc_gpio_number
ULP.run()

Then ULP.sleep() will start deep sleep forever or ULP.sleep(30) for 30 seconds, if not waken up by something.

[smhc]

Do you have the source code for those ULP bytes? I'd like to add wake up to a couple different pins, not just the one. I assume this code is using esp_sleep_enable_ulp_wakeup() with the ULP doing a wait/loop on the desired pin?

[smhc]

Thanks, but I believe I found your copy of the source: https://github.com/Staars/berry-examples/blob/main/ulp_examples/ulp_gpio_wake.py

[Staars]

Yes, I guess that this is the example.
I fear, that this particular code will not assemble with the latest versions of Micropython as there has been an API-change.
Personally I switched over to the other method of creating an ULP binary by creating an IDF-project.
Therefore a good starting is always one of the examples in ESP-IDF. But of course it is still assembly code and I would not call it freakin‘ easy.

If there is interest, I could probably add an example for this usecase in the „ULP-IDF-way“.

[smhc]

Ok thanks. Unless you need to do other processing in ULP I would imagine the hardware backed esp_sleep_enable_ext0_wakeup() and esp_sleep_enable_ext1_wakeup() functions would be far easier and consume much less power if all you need to do is wake on a pin. I am possibly going to use a vanilla IDF style project as I am concerned the boot and init etc times might be too long for a door sensor in Tasmota... am still experimenting.

That said - for any users of ULP I do think it would be useful to show how to actually get the binary data from code. Otherwise the feature is restricted to people that probably aren't even using Tasmota anyway.

[VoyteckPL]

Is it implemented?

[Jason2866]

Yes, just use the Berry code above.

[VoyteckPL]

Sorry I'm newbie 😆 how do I run this code on installed tasmota? Maybe I have to compile something?

[sfromis]

https://tasmota.github.io/docs/Berry/#ulp-module

[belveder79]

I can confirm that this works perfectly for my ESP32 flashed with a custom Tasmota 12.5 version and having

#define USE_BERRY_ULP

I use it for a Keybox defining a single edge and an opener switch from a standard cupboard (closed door=open switch=off, open door=closed switch=on), connecting GPIO 14 (defined as "NONE" on the tasmota template, which is important!) to GND pin.

Per default when the box is closed and the switch is open, GPIO14 will be high per default (gpio.digital_read(14) == 1), and if it is open and the switch is closed, it will be low (gpio.digital_read(14) == 0).

I have an autoexec.be file which starts a loop to check on the GPIO14. If it is high, it repeats checking with tasmota.timer. If it becomes low, the box has been closed and the script from @Staars is invoked (with an additional ULP.sleep() at the end to put the ESP32 back to deep sleep). Works perfect, thx!

[smhc]

I assume the "ULP solution" is basically some code that is running in ULP mode to wait on a pin change, and it enables esp_sleep_enable_ulp_wakeup() when sleeping. If so it's a shame Tasmota never implemented true deep sleep with esp_sleep_enable_ext0_wakeup() or esp_sleep_enable_ext1_wakeup():

It would allow more efficient sleep and could be easier to use than ULP. I would suspect "all" Tasmota would need to do is allow configuring certain pins as "WAKEUPx" (or NONE) pins and callback(s) to put the esp32 into ext0 or ext1 wakeup mode. Yes there are some design considerations around getting the "wake up reason", but this can be done later and at a much lower priority. The simple use case of waking up due to a pin change and taking an action on startup/boot would allow so many more applications, in particular battery operated contact sensors which is a pretty big gap in the ecosystem.

Even some berry callbacks that map to the various functions in https://docs.espressif.com/projects/esp-idf/en/v5.3.1/esp32/api-reference/system/sleep_modes.html would be adequate for 99% of use cases for battery operated sensors.

[barbudor]

From your description it looks easy to do
Will you provide a PR ?
Thanks

[smhc]

I may provide a PR which simply exposes those wakeup APIs and perhaps a sleep API (will need to check the existing DeepSleep command doesn't automatically enable RTC wakeup). I will do that in due time however, for the short term I am simply cut and pasting some raw C/C++ to do a MQTT publish on boot and handling the logic elsewhere on the network. I'm also using an esp2866 for something different and it won't have berry.

I hope it's just a few lines of code to expose those 2 or 3 APIs which will open up a lot of battery operated contact sensor device possibilities.