Save power by (reliably) switching the ESP WiFi on and off

-Update Oct 2017-  Doug Elliot very kindly submitted a comment (see below) to let me know that the redoubtable Erik Bakke has done a much better job at both troubleshooting and writing up this issue in a series of articles on his blog.  Rather than wasting your time with my half-hearted fumbling around, I’ll point you directly to the first article in Erik’s series.  Stay with it and read the whole bunch right through to the end; he keeps on coming up with new tweaks as he goes along.  There are a couple of extra articles (one on eliminating network scan at start-up and another on solar power for the ESP8266) which are part of the series, so don’t miss them, either.


I have an ongoing project to add an ESP8266 to a solar trickle charger for a lead-acid battery.  Really, the only set-in-concrete requirement is that the controller must switch off the feed from the solar panel before the battery voltage gets to dangerous (“gassing”) levels, but it would be nice to have remote data logging of voltages (battery and solar) and temperature, as well as some control over the load (a small impeller pump in an external sump well, used for orchard irrigation during the summer and autumn).

Because the target battery is a standard (wet plate) car battery, I have quite a bit of capacity to play with, but even so, my back-of-the-envelope calculations show that the ESP8266 is quite capable of completely discharging the battery in under a week (assuming no sunshine and an ESP8266 module with WiFi enabled and transmitting on a more or less continuous basis), so I’d been looking for a reliable way to save power, but still have the ESP8266 do real time monitoring of the battery and solar voltages and interrupt the charge process when the battery was already fully charged (I should probably note that we get a lot of sunshine here during the summer and autumn months and our usage of the pump is only very intermittent, so despite having a mere 300mA output from the solar panel, it is possible to overcharge the battery over time).

I didn’t want to use deep-sleep mode (although it’s the least power hungry), because I want the ESP to be the actual charge controller and it can’t do that if it’s off in la-la land for the best part of its day.  I still want to use the WiFi capability (otherwise there’d be little point in using the ESP over a PIC), but I don’t need to have 24/7 connectivity.  Turning the WiFi on and off has always been a bit of a hit and miss business for me, though (and with quite a few other people too, judging by the number of hits a web search on the subject generates).  So I was pleasantly surprised to find some answers in a GitHub “issue” raised against the ESP8266/Arduino project.  The thread contained some excellent answers and testing experiences from some of the well known members of the ESP8266 community (thanks guys!), so I felt fairly sure I was onto a winner, but there were one or two twists along the way.  So here is a brief rundown on how I’m doing it with those kinks ironed out and here is a program which will demonstrate the practicality and reliability of using the “Issue 644” method.

First, let me assure the nervous reader that, despite what follows, we are not putting the ESP to sleep at all, we do not need to use an interrupt or a reset to restart the WiFi and we also do not need to make any hardware changes to the ESP module for this method to work.

The crux of this method is to use WiFi.forceSleepBegin() to put the ESP into “modem sleep” mode.  It’s important to realize that this does not put the core into any form of sleep; it simply turns the modem (radio) off.  There are some other incantations in there to ensure that WiFi is shut down in  an orderly fashion:-


bool WiFi_Off() {
WiFi.disconnect();
WiFi.mode(WIFI_OFF);
WiFi.forceSleepBegin();

One of the issues at this point though, is that the WiFi can take a finite, but variable time to shut down after the final forceSleepBegin() call, so at this point I’ve just added a timeout loop, checking the status of the connection until it goes down (returning without an error) or times out (returning with an error):-


while ((WiFi.status() == WL_CONNECTED)
&& (conn_tries++ < WIFI_RETRIES)) {
delay(100);
#ifdef DEBUG
Serial.print(".");
#endif
}
if (WiFi.status() != WL_CONNECTED)
return (true);
else
return (false);

The default timeout of 3 seconds is more than enough for the WiFi_Off() function.

The WiFi_On() function is pretty much a reversal of the “off” code:-


bool WiFi_On() {
conn_tries = 0;

WiFi.forceSleepWake();
WiFi.mode(WIFI_STA);
wifi_station_connect();
WiFi.begin(STA_SSID, STA_PASS, WIFI_CHANNEL, NULL);

while ((WiFi.status() != WL_CONNECTED)
&& (conn_tries++ < WIFI_RETRIES)) {
delay(100);
#ifdef DEBUG
Serial.print(“.”);
#endif
}
if (WiFi.status() == WL_CONNECTED)
return (true);
else
return (false);
}

The call to “wifi_station_connect()” seems to be the equivalent of a sacrificial chicken for most people, though. Without it, the restart of the WiFi doesn’t always work; with it, everything is hunky-dory (whatever that means).

Unfortunately, actually getting the call to wifi_station_connect() to compile turned out to be a bit problematic for me (from within the PlatformIO build environment). Just where the heck is it? Well, some searching found a define for it in the user_interface.h file in Espressif’s SDK. Adding a simple:-

#include "user_interface.h"

…in the header of my ESP_Power_Save.ino file got me past the initial “not found” messages, but then, at the last stage, the linker failed with “undefined reference” errors. Grrrr! The magic sauce for that though, is simply to let the C++ compiler know that it’s looking for a plain C function (buried deep in the nether regions of the Espressif SDK, in this case) by modifying that include to be:-

extern "C" {
#include "user_interface.h"
}

Finally, it compiled …and worked, too.

Before you flash ESP_Power_Save.ino to your ESP8266, you’ll need to configure the IP addresses, access-point SSID and password in the user_config.h file.

After flashing, connect to the ESP8266 console as normal and you’ll find yourself in a mini test environment where you can use a few simple, single character commands:-

  • “w” — to toggle the state of the WiFi between on and off.
  • “s” — to display the current state of the WiFi connection.
  • “c” — to display a simple count on the console, just to prove that the ESP core is still operational.

I’d recommend opening a second window and using it to ping the ESP’s IP address, to verify whether it is up or not as you toggle the WiFi.

Finally, a word of caution …If you try to connect to a non-existent access-point, or one which is out of range, or you use an incorrect password, then the WiFi will not turn off. That seems pretty counter-intuitive to me and I haven’t yet worked out why it happens. At any rate, it’s obviously worth doing some testing (I use a hand-held ESP8266 rig running on three AA batteries) to make sure that you have connectivity before deploying this power-save code to your remote units.


Update — The latest version of the code now includes a cut-down version of the “FSWebServer” example (from the ESP8266WebServer library) which will server up a 750kB JPEG file from SPIFFS on the ESP.  It takes a non-trivial amount of time for the little ESP to retrieve such a substantial file from SPIFFS, chunk it up and push it out across the network, which hopefully will give you adequate time to measure the current consumption of your module while busy transmitting, for comparison with when the WiFi is toggled to the “off” state.


Update #2 –  Real world testing has brought some interesting “features” to light.  Most problematical is that the WiFi doesn’t seem to always switch off completely, which is peculiar.

First, you need to know that the ESP8266 returns its current status when interrogated with the WiFi.printDiag() request.  When running normally, the results look something like this:-


Mode: STA
PHY mode: N
Channel: 11
AP id: 0
Status: 5
Auto connect: 1
SSID (9): Mainwaring
Passphrase (10): D0ntPan1c!
BSSID set: 0

The two most important indicators are the Mode and Status lines (although the SSID and Passphrase entries will also change when the WiFi is disabled).

The current draw on  my test module is generally in the area of 75ma when WiFi is enabled, with very brief peaks when actually transmitting (so brief that they’re impossible to measure with an ordinary digital multimeter).  That value drops off to 20ma when the WiFi is disabled and at the same time, WiFi.printDiag() changes to show “Mode: NULL” and “Status: 255” (and the module stops servicing web requests or even  a simple “ping”).

Frequently, toggling the WiFi (with the “w” command) will give the same result in terms of connectivity (ie:- the unit stops responding to web requests or pings) and the result of a WiFi.printDiag() is still “Mode: NULL” and “Status: 255”, but the current draw remains in the 75ma region.  I suspected that the auto-connect or auto-reconnect settings may have been responsible, but after further testing that doesn’t seem to be the case.

So, after using the word “reliably” in the title of this post (which, admittedly, referred specifically to being able to turn WiFi back on after a modem sleep), I now find that the current reduction isn’t reliable at all.  Does anyone have any ideas?

Advertisements

Killer (ESP8266) Apps for the Weekend

Sometimes, while browsing GitHub for ESP8266-related projects, I come across a user’s page which just happens to “push all the right (ESP8266) buttons” for me.  One which I came across recently was from martin-ger and he has several projects which tickle my fancy.

Those three should keep you amused over the weekend and give you a sample of what Martin is capable of.  Definitely a page worth bookmarking!

 

 

Nice little TFT screen adapter board

Johan Kanflo has an interesting site which is definitely worth browsing.  One of his ESP8266 projects which caught my eye was the “Commadorable-64”.  Although the Commodore 64 isn’t a shared experience, using a tiny TFT display connected to an ESP is.  Johan has put together a neat little carrier board for the ESP8266 which solders directly onto the pins of the TFT display board.  Instant wireless display!

Johan’s project actually covers more than just one model of display, with the ESP Johan Kanflo's TFT Adapter Boardcarrier board being available for the 2.2, 2.4 and 2.8 inch TFTs (the larger models have connections for touch control, too);  follow the links on Johan’s project page to reach the DirtyPCBs pages for the one which interests you.

Johan has a Github repository with the code for this project (and many more) available for download.

0.96″ OLED with an SPI interface

There’s a metric ton of those tiny, cheap, 0.96″ displays for sale out there, but one of the drawbacks is that you’re never quite sure which of the interface type you’ll be getting (the photos displayed by the vendors rarely match to the shipped product and the descriptions almost never do).  I ended up with an SPI version on my bench the other week, when what I was really after was the good old I2C version.  Oh well, how hard can this be, anyway?

Well, when you look at the back of the display there are some silk-screened instructions for what combination of resistors are used for which interface, but I have to admit that the idea of moving SMD devices of that size around without losing one on the floor, or pulling off a trace, didn’t seem too attractive to me.  An internet search found a StackExchange thread dealing with the subject and, although the procedure described didn’t look too intimidating after all, it also yielded important clues to the connections needed to have the module just work in its intended mode of SPI.  I was using a Node-MCU module, so I had pins to spare for the extra three wires, so it wasn’t really much extra effort to slap the whole lot onto a breadboard and mess around to try and get it working. OLED breadboarded with NODE_MCU I was also using Squix’s “PlaneSpotter” package as the software to test it with, as Squix’s excellent implementation of the SSD1306 driver library is claimed to be interface agnostic and should work with the SPI as well as the I2C interface (all of his current examples use the I2C interface).

The one thing that did confuse me to begin with were which of the SPI pins to connect on the ESP side; specifically the “DI” and “DO” pins from the display.  It’s SPI, so those should be the MOSI and MISO lines, right?  Err ..no!  With the help of the above mentioned StackExchange thread, I eventually cottoned-on to the fact that the display doesn’t use DO as MISO at all, it uses it as the SPI clock line, so ignore that wonderfully helpful labelling on the display connector.

The next step was working out which pins were which on the Node-MCU.  This is the first time I’ve used one of these beasties and I didn’t find its pin labelling particularly helpful, either (on the other hand, it is undeniably a nice packaging of the ESP module and USB interface components).  Eventually I got it all worked out, loaded up “PlaneSpotter” and had Tokyo to Seoul traffic showing up first try (all due to Squix’s neat programming and packaging).

Well that was the test part and now that I’ve verified that the display works, I need to move on to implementing my own, more modest project.  Before I leave you though, I’d just like to make a note of the hardware connections and minor software changes which were needed, as they might be of help to someone else.

First, here are the connections for both Node-MCU and normal ESP8266 GPIO pins for the display:-

Display NodeMCU ESP8266
CS D8 GPIO15
DC D4 GPIO2
RES D0 GPIO16
DI D7 GPIO13
DO(CLK) D5 GPIO14

 

…and here are the changes to the main.cpp file of the PlaneSpotter code.  As you can see, we just comment-out the I2C defines and add our own pin definitions below (note that the SPI pins, DI, DO and SCL, are hard-coded into the ESP8266 library and can’t be changed):-


// Display Settings
//const int I2C_DISPLAY_ADDRESS = 0x3c;
//const int SDA_PIN = D2;
//const int SDC_PIN = D3;


// 4-pin SPI Version.
const int RES = D0; // GPIO16. \
const int DC = D4; // GPIO2. - Normal ESP pin numbering.
const int CS = D8; // GPIO15. /

Next we just comment-out the init call for the I2C version and add in the call to the SPI one:-


// Initialize the oled display for address 0x3c
// sda-pin=14 and sdc-pin=12
//SSD1306Wire display(I2C_DISPLAY_ADDRESS, SDA_PIN, SDC_PIN);
//SH1106Wire display(I2C_DISPLAY_ADDRESS, SDA_PIN, SDC_PIN);
SSD1306Spi display(RES, DC, CS);
OLEDDisplayUi ui(&display);

For all of the other required local settings for this app, please refer to Squix’s notes.

 

A wee bit late for Xmas, but…

Here’s a very seasonal item, courtesy of Hackaday  …Sean Hodgins’ ESP8266-enabled Xmas ornaments.  They’re worth checking out for the really neat, multi-coloured PCBs (although I’d probably decide to do without the piezo speaker if I were to build any).

Sean Hodgins' Xmas Ornaments

No word yet on where Sean sourced the PCBs, or on what the battery life is like (even with deepSleep(), not long, I’d guess).

Sean’s GitHub repository has all of the code, if you fancy knocking a couple of these together on Xmas morning.

Weekend Reads [7th May 2016]

As a little bit of a break from the ongoing TASMOTA series, here are a few links for some light, ESP-related, weekend reading.

Finally, here’s one just to amuse you.  It’s not an ESP8266 project, but a project along the same lines of the ESP relay switching boards which have generated so much discussion in the forums recently (about the relative safety of their designs).  This one popped up in the Editor’s Choice newsletter from Instructables (and obviously, when it comes to basic electronics,  the Instructables editor is as clueless as the original submitter).

What I’d like to know though, is how the submitter actually did what he did?  Take a look at the “$1 AUTOMATIC WATER LEVEL CONTROLLER” project and see how many mistakes you can spot (you’ll need to  scroll well down in the comments to see an image of the bottom of the board).  I’ll give you a clue for the first one …I’m colour-blind, but not that colour-blind!  At any rate, please feel free to ignore the author’s advice that this is a working design for an AC pump.

Have a good one!