Yellow doorbell/dash project

In the previous post, I outlined how the “Yellow Development Board” from AI-Thinker had become my new, go-to ESP8266 board for projects, partly because the headers make it easy for interconnects and partly because it’s got lots of LEDs already on board.  Not to mention that it’s reasonably priced and comes equipped with a battery box and a low quiescent current voltage regulator (important when you’re running from batteries).

Even more recently, I wanted to experiment with a doorbell-cum-dash style button, based on one of the dollar-store LED push-button lights which seem to be available everywhere nowadays. The idea is that pushing the button will initiate a connection to the MQTT server Three-LED lightfrom the ESP8266 embedded inside the button and then, based upon which ESP just called, the MQTT server will initiate a process. That process could be anything from ordering another bottle of Rivella from Amazon, to switching on the stair lights, or announcing that there’s someone at the back door (or just about anything else you can think of where a momentary push button is used). The dollar-store light, as it comes, incorporates three, white LEDs and a latching switch, with a battery box for three, AA batteries built into the bottom. The construction of these lights is extremely flimsy (I just cracked the battery cover on the one pictured above while positioning it for the photo), but they are still amazing value for what they are. Taking the thing apart reveals that the LED “reflector” is nothing more than a flimsy sheet of white card, but that doesn’t matter, as we won’t be using it anyway. In fact, we can remove the LED PCB completely and just hold onto the white LEDs for some other project (our Yellow board already has more than enough LEDs) just keeping the base for our project. The original switch is a latching type, which isn’t what we want, either. On Prototype internalsthe first LED light that I bought, I tried to dismantle the original switch, with the idea that I’d convert it into a momentary type by throwing away the latching mechanism. However, the mechanism is so tiny that my motor skills weren’t up to the job (and that tiny little spring will no doubt be found by the vacuum cleaner, eventually). In the end, I simply removed the plunger from the original switch and glued a momentary “tact” switch on top of it (which put the new switch at exactly the right height to work with the push mechanism). The Yellow board (this time minus its own battery box) fitted perfectly on top of the built-in battery box (with that bit of flimsy white card insulating it from the exposed battery connectors), while some extra circuity fitted on a strip of prototyping board at the end of the battery box opposite to the switch. Despite the sticky-tape and hot glue, this prototype worked very well.

The circuitry on the prototyping board deserves a quick explanation here. The whole purpose of this project was to have an ESP8266 which would sit doing nothing at all for very long periods. Basically, that’s something that the ESP isn’t very good at. Even if it’s sitting there in deep sleep, it can still deplete three AA batteries in about three months, which is not very useful for a doorbell/dash type application, so the intention here was to have the ESP turned off completely, until it needed to wake up. The button implies physical interaction, so we know we can get the unit to switch on for the length of time that the button is held closed, at least. For a doorbell type application, that’s likely to be some significant part of a second, at a minimum, but still probably not long enough for the ESP to go from a cold start, through negotiating a connection with an access point to sending an MQTT message.  What  we needed was a method for the ESP to ensure, once it had been initially powered, that it could latch the power on until its work was complete and then (importantly) turn it back off again.

The answer is provided by the circuit below.  The ESP will start up very quickly indeed, especially if you don’t muck about trying to initialize serial ports, or wireless, or sending debug messages.  So what we do in our application is, as the very first thing, use the pinMode() command to initialize a designated pin as an output (which we’ll call “POWER_SW”, for power-switch) and then call digitalWrite() to set POWER_SW to “HIGH”, then we go back to our normal setup() routines.  This happens in a few milliseconds and we use the output of the GPIO pin designated as “POWER_SW” to drive the PWR_LATCH input signal of our latch circuitry, below.†

MOSFET power-latch schematic

Okay, so how does all of this work?  Well first of all, power is coming in from the battery box on the L/H side of the diagram on the pads marked as BAT+ and BAT-.  Our Yellow board is supplied from the R/H side pads, marked PWR_OUT and GND.  In between, right at the top, there are two more pads marked as SW_BATT and SW_VREG.  These are the two wires to our actual momentary contact “tact” switch, which we just pressed (a few milliseconds ago) to provide the initial power connection between the battery box and the ESP.  What we have now is a situation where the switch has been released, the battery is disconnected from the ESP8266 again and the charge on the smoothing capacitor next to the voltage regulator on the Yellow board is rapidly starting to deplete.

The ESP though, has already started up from cold, initialized the POWER_SW GPIO and set it to high.  As we noted, that GPIO is actually driving the PWR_LATCH line (bottom, R/H side of the diagram above).  This is connected to the gate of Q2, an N-channel MOSFET and will turn that device on, pulling the voltage at the junction of R1 and R3 low in turn.  This turns Q1 (a P-channel MOSFET) on, providing an alternative path for the battery power to reach the ESP8266.  As long as the “POWER_SW” signal remains high, the power will remain connected to the ESP8266.

As you’ve probably already guessed, once the ESP has finished running its designated tasks, it simply flips the POWER_SW signal from HIGH to LOW and, before the ESP8266 has time to print out “Goodbye cruel world!” to the console, the power is gone.

Why don’t we just invert the logic and have the ESP8266 drive Q1 directly, instead of adding the extra components around Q2?  Well the main reason is that the battery pack on the LED light has three 1.5 volt batteries in it.  When they’re brand new, the total voltage across all three cells can measure as high as 4.8 volts.  The ESP, as we all know (despite rumours to the contrary) is a 3v3 device and the voltage at the end of the resistor chain of R1 and R3 would float up to full battery voltage when the ESP was switched off and not pulling that line low, so Q2 is mainly there to protect the ESP from the full battery voltage (the N-channel used for Q2 needs to be chosen to withstand full battery voltage with some additional headroom, which isn’t asking much of a stand-alone MOSFET).  The chain of R1 and R3 is also there to protect the gate of Q1, the p-channel device, from being driven beyond its gate/source voltage limit (which is unlikely in this particular circuit, anyway).

Finally, the question is, which GPIO should we use as the POWER_SW drive?  Well, GPIO-0, GPIO-2 and GPIO-15 are bad choices, because they are all read at power-up time to determine which mode the ESP will boot into.  GPIO-16 is a good candidate though, as we definitely will not be connecting it to the reset pin for deep-sleep wake-up in this project.  If you want to change this on your particular board, feel free.  Just change the definition in the user_config.h file (and ensure that your chosen GPIO is not used for any of the other functions).

Update – The prototype auto-latching switch board worked very well, so I’ve knocked together a PCB using mostly through-hole components (that’s what I have in my parts drawers and besides, my hands are too shaky for SMD stuff nowadays …I can just about manage the AO3415, but only because I can’t find it in TO-92).  If anyone wants to roll their own, the board files (Eagle format) are available on GitHub.  My next version will probably provide an alternative SMD footprint for the 2N7000 (using the AO3414, which is what I had originally planned), but feel free to go 100% SMD if you prefer.

Okay, that’s our hardware.  The software is coming along next in two or three separate pieces.

† – It’s worth noting that if the GPIO on the ESP8266 isn’t initialized to “digital” mode, the MOSFET switch will be held “on” and you’ll be unable to switch it off (which is somewhat counter intuitive).


3 thoughts on “Yellow doorbell/dash project

  1. […] As promised in the previous post, we’re going to explore a simple application for the Yellow Development Board this time round.  The one thing that this board has plenty of is LEDs.  There are half-a-dozen red LEDs and one blue across the bottom of the board, as well as a 5mm RGB LED.  So, not surprisingly, we’re going for the “Blinkenlights” option as the first demo.  You won’t need an MQTT server or even a working access-point to have this demo work, but the display does get a bit boring quite quickly. […]


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s