Having an ESP32 control a reed switch with wifi and deep sleep on LIPO battery

[StealthRT]

I’m looking to create a project for my home. I am wanting to place window and door sensors (reed switch) and hook it up to my ESP32 wroom-32 (wemos) microprocessor. The version I have has the JST connector to hook up a LIPO battery to. I have 20 of these to use with a reed switch and a custom 3D printed enclose for it.

I found the website that allows me to input the specs of my esp32 and see how long the battery would last depending on the size of the battery. For my math I came up with the following:

Capacity rating of battery = 1700mAh
Current consumption of device during sleep = 0.02 mA
Current consumption of device during wake = 5 mA
Number of wakeups per hour = 120 (every 2 minutes)
Duration of wake time = 1000 ms

This puts it just shy of 1 year (323.7 days) on the LIPO only.

I plan on utilizing the deep sleep function that the esp32 has. I’ve seen that its around 150 µA (0.15 mA) and replacing that value with the one provided above (0.02 mA) with the calculator gives me an even lower amount of days. So, I will only wake it up using the external source which would be the reed switch (ext0/vp) and use the Timer function to send and receive data every 2 minutes and then go back to sleep for another 2 minutes

The big question I have though is this – How much does waking every 2 minutes, turning on the Wi-Fi and RX/TX a json string take in mA? Each time I am wanting it to send via WIFI a json string to my home server API to let update my dashboard so it knows that esp32 status (open or closed window/door) and battery level (10-100%).

Now the even bigger question is – how would I be able to send a command to the esp32 to let it know if it needs to alarm when it detects the reed switch connection or if I simply want to open the window to get some fresh air without it tripping the alarm? That can be done with every 2 minutes it wakes and send data – I could just send json string back letting it know to not worry if the reed switch is tripped or not. But again, I do not know how much current all that would take to achieve all this?

So, to summarize:
- I want to place the esp32 into deep sleep every 2-5 minutes.
- I want to send a json string every 2 minutes to my API.
- I want to send back a json string for “disable” to not care about the reed switch status or “Enable” which would mean to care about the reed switch status.
- I want to turn on the Wi-Fi just enough to be able to send and receive json data.

I’m sure there’s somebody out there that has done this type of setup or close to it that can lend some helpful advice.

 

[Frankchie]

I would try and let the reed switch control power to the ESP32. The ESP32 can then keep the power on by controlling external circuitry, like a simple transistor switch. If necessary, when the ESP is done transmitting it can then kill it's own power via that same mechanism. If the signal from the reed switch is too short to allow the ESP32 to fully boot up and activate the latch via software, there's ways to overcome that (e.g., ESP32 3.3v power out pin, and other ways).

 

[Frankchie]

Oops. I just realized that the ESP32 itself does not have a 3.3v power out pin to control the transistor switch that I mentioned above, that's a feature of the typical ESP32 development board. If you are using a raw ESP32 without a development board you will have to find a pin that quickly outputs voltage upon power up of the ESP32. I think GPIO0 may be such a pin as it seems to have a hard 10k pullup internally.

 

[Harald Kapp]

Have a look at this circuit.
The only catch is that the trigger from the reed switch needs to be active long enough for the µC to activate the output pin to H level.
Placing a capacitor from the gate of the MOSFET to GND may help to mitigate issues if the startup of the µC takes too long.

 

[Frankchie]

Have a look at this circuit.
The only catch is that the trigger from the reed switch needs to be active long enough for the µC to activate the output pin to H level.
Placing a capacitor from the gate of the MOSFET to GND may help to mitigate issues if the startup of the µC takes too long.

Building on your capacitor suggestion, I would think that cap might also eliminate the need for the BJT transistor and related circuitry. The uC could simply GND the mosfet gate maybe through a series resistor. Although it may not be that simple if the powered-off uC pin has some continuity to gnd.

 

[Harald Kapp]

The uC could simply GND the MOSFET gate maybe through a series resistor.

Yes it could. But: the problem with this idea is: when power to the µC is turned off, the output voltage of the GPIO pin will drop which in turn would turn-on the P-MOSFET, thus powering the µC again. A vicious cycle.
This is prevented by the bipolar transistor which requires an active high signal from the GPIO pin.

 

[Frankchie]

Yes it could. But: the problem with this idea is: when power to the µC is turned off, the output voltage of the GPIO pin will drop which in turn would turn-on the P-MOSFET, thus powering the µC again. A vicious cycle.
This is prevented by the bipolar transistor which requires an active high signal from the GPIO pin.

Ah yes, the ole vicious cycle problem I know it well. Although it may not apply in this case.

That's because when powered off the GPIO voltage will indeed disappear, but I don't think the uC GPIO pin would necessarily sink current. So the mosfet should turn off because its gate voltage stays high via the 100k pullup resistor.

I haven't done much work with the ESP32, but I have worked with the ESP8266, a close cousin. Some quick ohmmeter and diode FW voltage checks on that unpowered uC show no continuity to ground on several of its GPIO pins. Although some GPIO pins had about 13k ohms to gnd, perhaps explained because some of its GPIO pins have documented internal hard pullup or pulldown resistors.

Of course the transition period could be problematic, but hopefully your cap and the GPIO series resistor I mentioned would solve that issue.

 

[Harald Kapp]

but I don't think the uC GPIO pin would necessarily sink current.

But it will.
Typically I/O pins of an IC are protected by diodes like so. When the positive supply (V_DD) falls towards 0 V, any input voltage higher than V_DD+0.6 V (1 diode pass voltage) will make the input diode leading to V_DD become forward biased (conducting). This diode will then pull the input towards GND.

 

[Frankchie]

But it will.
Typically I/O pins of an IC are protected by diodes like so. When the positive supply (V_DD) falls towards 0 V, any input voltage higher than V_DD+0.6 V (1 diode pass voltage) will make the input diode leading to V_DD become forward biased (conducting). This diode will then pull the input towards GND.

Yes that is a problem. Although strangely, depending on the specific GPIO pin, I see varying Diode FW drop to the unpowered ESP8266 VDD pin from 1.8v to 2.8v to nothing (open) depending on the specific pin. When powered I see similar results. So I suppose that there may be a combination of a specific GPIO pin with an extra diode or two and judicious resistor values that may be workable.

However giving this more thought, perhaps also problematic is the GPIO state during the transition period as the uC powers up/down from a gradually rising/falling supply VDD (due to the capacitor). I don't think that the GPIO output can be predicted during that transition period and it's not good practice to design around anything that is unpredictable. So unless someone has a better idea, I think it's best to stick to the original 2-transistor latching circuit.

Thanks, Harald, for your help.