Deep Sleep (Feature Request)

Feel free to trim the title for a proper tag. Not sure how you personally label these kinds of things 😃

One of the reasons I adore epaper displays is because how low power they are! (I own several e-ink ereaders. Maybe hoard is a better word)

And that was the basis of the project that you commented on that summoned the scourge that is me upon your codebase got me interested in revamping my project with this, to make a nicer looking, easier to edit version.

However, it runs on a battery. And batteries are small and don’t last that long! But, epaper doesn’t need power to keep the previous data for a very long time.

Luckily, the basic implementation seems quite easy. (Just 2 functions! esp_sleep_enable_timer_wakeup(microseconds_to_sleep) and esp_deep_sleep_start())

Source

But there’s a slight issue when it comes to the Web GUI. Which is keeping it online so a user can get to the UI. I see a few ways of solving this, but it’s ultimately up to you.

1. Don’t care about the user unless they connect
   • Start a timer on program start (say, 10-30s) and see if a user connects via HTTP. If they do, suspend the timer until board reset/button on dashboard similar to “Reboot”
2. Only start sleeping when told to or when previous reset was caused by deep sleep timer
   • Via button on dashboard similar to “Reboot”
   • But how do you tell it to stop?
3. Always sleep unless GPIO0 is held after boot
   • This is one I’m leaning towards, as it’s resilient against sudden power loss, and is easy enough for most to understand. Only issue is timing when to hold the button, as on Reset, it will go into download mode, and too late it will go to sleep. Maybe having this configurable like the DC/RST/BUSY pins would be best.

Another thing that would be nice, is an MQTT Birth message. Otherwise, it would have to rely on either:

1. Broker-Retained messages

2. Last value heard by the ESP

# 1 Isn’t that bad, but I prefer any persistent data to be kept in a proper database, and MQTT db files don’t seem mission critical to me. # 2 Is a bad idea all around, as it’s more likely than not for the ESP to miss the publisher’s message when it wakes.

Having it wake up, send a message saying “I’m alive!” and listening for 5-10 seconds before going back to sleep sounds ideal to me.

(Heck, even having the birth message in general could have positive side effects outside of deep sleep. Such as knowing for sure the ESP is connected to MQTT, making sure it has proper data very soon after start up, etc)

A pre-deep sleep message could be nice as well. Could be used simply for testing/logging, but I’m sure someone has a use for it.

[nullstalgia]

Extra brownie points if the pin state check is configurable to a HIGH or LOW! 🍪

Maybe an extra checkbox to set the pin to an INPUT_PULLUP/PULLDOWN to save the user a resistor? Or maybe it should be default depending on the setting…

And no problem! I’m just glad you’re not annoyed by the flood of issues and pulls.

[nullstalgia]

Added and current implementation is satisfactory.