I'm working on a "door sensor" project, using an ESP8266 Huzzah breakout. Here's the gist of the setup function:
BASIC SETUP/CHECKS (on every boot):
* set up serial
* read RTC state (5 variables)
* if no state found, try reading config from a JSON "file" (using the old? FS.h)
* if still no state, start a web portal (using WiFiManager) to get the values + wifi credentials. This will cause a reboot
* check if a "sensor" is connected (by checking if GPIO2 is high). If it is low, start web portal ("please connect a sensor"). This will cause a reboot
* if "sensor type" is missing (from state/config), try to detect it by "timing" the RC circuit comprised of C2 and R8 (millis to charge C2 until GPIO2 reads as HIGH)
SENSOR CHECK
* read battery level (ADC, analogRead)
* increase boot counter, and save RTC state
* read "sensor" inputs (i.e. GPIO4 and GPIO5)
* if values (HIGH/LOW) are the same as previous values (from state found above) then DEEP SLEEP 1 second: reboot
REPORT (one/both values different)
* connect to wifi (WiFiManager)
* create one or two POST requests for the changed value(s) and send to API
* save RTC state (new "previous" values)
* DEEP SLEEP 1 second
Deep sleep is used to save battery, as the idea is to try to run this circuit on 3 AA batteries (standard alkaline, household batteries) in series. These should give something within the range of 3 - 4.5V, and the minimum required voltage for the ESP8266 Huzzah seems to be 3.3V. Otherwise, the setup is configured such as to avoid having to connect to WiFi until something actually needs reporting (logging to API) -- again, to save battery, as the ESP draws more current when WiFi is on. In my use case, an "event" (i.e. door opening or closing) might only happen once a day, so not connecting to WiFi saves both time and power.
However, is my design for this circuit good enough? I'm not happy with the battery life of this setup; even with the above mentioned measures (deep sleep, and holding back on the wifi) the VARTA batteries only lasted a couple of weeks. The voltage has now dropped below 3.3V, at which point the Huzzah fails to boot. I've verified that the Huzzah by itself -- taken out of my circuit -- does indeed fail to boot at 3.19V, so this does not appear to be caused by something other than low power.
Please have a look at my schematic, and let me know if something is odd, bad, or just wrong.
Need some help on running ESP8266 Huzzah on 3 AA batteries (schematic advice?)
-
- Posts: 9757
- Joined: Thu Nov 26, 2015 4:08 am
Re: Need some help on running ESP8266 Huzzah on 3 AA batteries (schematic advice?)
Your issue is that a deep sleep of one second is next to useless: the amount of current required to start up, get a DHCP lease again etc probably negates the power saved by deep sleep entirely.
I'd do one of two things:
- Connect the door sensor to the reset pin of the ESP8266 somehow, so you can sleep for a longer time for the other sensors but will wake up immediately when the door opens
- Use a different ESP chip. If you use e.g. the ESP32-C6, with a WiFi-6 access point and light sleep, your power usage even when on and connected will be dramatically lower than with the ESP8266. Note you may want to see if your chosen SDK (Arduino?) already supports this chip. If not, even picking an ESP32-C3 or so will save you a fair bit of power as it has better light sleep modes.
I'd do one of two things:
- Connect the door sensor to the reset pin of the ESP8266 somehow, so you can sleep for a longer time for the other sensors but will wake up immediately when the door opens
- Use a different ESP chip. If you use e.g. the ESP32-C6, with a WiFi-6 access point and light sleep, your power usage even when on and connected will be dramatically lower than with the ESP8266. Note you may want to see if your chosen SDK (Arduino?) already supports this chip. If not, even picking an ESP32-C3 or so will save you a fair bit of power as it has better light sleep modes.
Re: Need some help on running ESP8266 Huzzah on 3 AA batteries (schematic advice?)
Hi, and thanks for responding!
About deep sleep: As outlined in the description of the setup method, I avoid connecting to wifi unless/until some input actually changes. So I won't be getting a DHCP lease etc on every boot, don't you agree? Still, it does have to start up every time (the "basic setup" part) which maybe, in itself, is a high drain.
I have looked into waking the ESP8266 on "external interrupts", but it doesn't seem to support this. In order to wake the chip using the reset pin, a pulse (high-low-high) has to be created on the RST pin, which requires quite a bit of circuitry to create.
As this is a learning project, I find these types of limitations are interesting challenges and learning opportunities. I know the ESP32 is more powerful, and easier to work with, but I hope to get as much out of this setup (using the 8266) as possible For instance, if I were to switch/upgrade to ESP32, would there still be issues with the circuit that draw unnecessary amounts of current while the chip is sleeping?
I'm very interested in getting some comments on the circuit, but I'm starting to think this might just be that the project has reached the limit of what's feasible with this chip... Maybe I should just upgrade to the 32. I have learned a lot by experimenting with the 8266 though -- stuff I otherwise wouldn't have had to think about if I had simply started with the 32.
About deep sleep: As outlined in the description of the setup method, I avoid connecting to wifi unless/until some input actually changes. So I won't be getting a DHCP lease etc on every boot, don't you agree? Still, it does have to start up every time (the "basic setup" part) which maybe, in itself, is a high drain.
I have looked into waking the ESP8266 on "external interrupts", but it doesn't seem to support this. In order to wake the chip using the reset pin, a pulse (high-low-high) has to be created on the RST pin, which requires quite a bit of circuitry to create.
As this is a learning project, I find these types of limitations are interesting challenges and learning opportunities. I know the ESP32 is more powerful, and easier to work with, but I hope to get as much out of this setup (using the 8266) as possible For instance, if I were to switch/upgrade to ESP32, would there still be issues with the circuit that draw unnecessary amounts of current while the chip is sleeping?
I'm very interested in getting some comments on the circuit, but I'm starting to think this might just be that the project has reached the limit of what's feasible with this chip... Maybe I should just upgrade to the 32. I have learned a lot by experimenting with the 8266 though -- stuff I otherwise wouldn't have had to think about if I had simply started with the 32.
Who is online
Users browsing this forum: No registered users and 37 guests