Before I leave the house, I want to see an overview of all relevant home automation variables
- are all the windows and doors closed?
- are all the lights off?
- is my computer off?
- is the washer or dryer still running?
For this, I built a small, battery-powered display next to the front door. It has a Wifi connection to the home network, and pulls all relevant OpenHAB variables via its REST interface, every hour, and at the push of a button.
The display layout and set of OpenHAB variables are configurable via a JSON text embedded in the source code — in the future, this could also be read from flash file storage, or pulled from an external server.
Architecture
- an ESP8266 module with custom software
- a 2.9″ e-Ink display
- a pair of AA batteries, which should last for more than a year.
All code and schematics are available in my Github repository.
Build instructions
The hardware is very simple, see the schematic.
The software was developed using Platformio. Just download the repository contents into an empty folder, and open that folder as a Platformio project.
In folder src/, rename file myauth_sample.h to myauth.h and enter your Wifi SSID and password.
Selection and display position of openHAB variables is done via a large JSON text embedded in the source code. For a detailed description, see the README.md file in the repository.
Over-the-air update
The device supports OTA firmware updates, despite the fact that it is in deep sleep most of the time. How? When it wakes up, it checks an openHAB switch item named EnableOTA, and if that is ON, then the device does not go back to sleep, but waits for an OTA request. It also turns the openHAB item back to OFF.
Power saving considerations
First, we need to minimize deep sleep power consumption:
- a bare ESP-12F module is better than a Wemos D1 or NodeMCU development module — probably due to the voltage regulator and USB interfaces on those modules
- while the e-Ink display consumes virtually no power when displaying static content, the e-Ink module consumes ~250µA, probably due to level shifters. Solution: the e-Ink module must be powered off during sleep. It is powered from a GPIO line of the ESP8266
- even with the e-Ink display module powered off, there is still some currect due to pull-up resistors on the ESP8266 side, if GPIO0 and GPIO2 are connected directly to the display module. Solution: connect to display module via Schottky diodes.
- connect the processor directly to batteries without a voltage regulator, avoiding any quiescent current. A bare ESP-12F on bench power supply works down to 2.2V, fails at 2.0V, so should be ok with 2x AA batteries
Also, we need to minimize the duration of active Wifi during a wake period:
- try to reconnect to Wifi using previously established SSID, IP and channel number, which are cached in flash file system
- parsing the layout definition requires network access for REST requests to the OpenHAB server
- the parsed layout definition is cached in flash fiel system
- parsing the layout definition only occurs if it differs from the cached version ( as determined by comparing CRC checksums)
Depending on these design decisions, here is the power consumption we get for an ESP8266 with a 2.9″ e-Ink display, during deep sleep:
- with NodeMCU, USB powered: 360µA
- with bare ESP-12F, 3.3V powered: 250µA
- with bare ESP-12F, 3.3V powered, e-Ink power disconnected: 16µA
Power consumption and battery life
The following factors contribute to power consumption or battery drain, in decreasing order of importance:
- the self-discharge of the batteries, according to [1], about 80 µA or 1.92 mAh per day
- wake time with WiFi on, at 90 mA x ~2s per wakeup, or 1.2 mAh per day
- wake time with WiFi off, waiting for the display to refresh, at ~5mA x 18s per wakeup, or 0.6 mAh per day
- deep sleep, at ~20 µA or 0.48 mAh per day — if we were using a development module with 250 µA current consumption in deep sleep, this would rise to 6 mAh per day!
With the design decisions I made, the biggest part of power consumption is now the self-discharge of the batteries, which I can’t influence. Optimizing the power consumption during wake time was also relevant. Minimizing the deep sleep power consumption of the supposedly “low power” e-Ink display module was certainly worthwhile!
Conclusions and Lessons Learned
I have had this up and running for about half a year now, the battery voltage has dropped from 3.2V to 2.9V, with hourly screen refreshes, so I do expect it to last for a year or longer before I have to replace the batteries.
I found it somewhat difficult to use the sleep functions of the ESP8266 processor. When googling for this topic, I found various contradicting instructions. In the end, I managed to get the “deep sleep” function to work as desired, to put the processor in a minimum power consumption mode between screen refreshes. However, I never managed to get a sleep mode to work for the 15s that the display needs to complete its refresh. All I could do was turn off WiFi and then have the processor twiddle its thumbs until the display indicates it is done.