I haven't considered a suitable solution for handling fast transitions, such as opening and then quickly closing the door within a second. Precisely, we need to maintain the case where the switch is open for some time even if it is just closed immediately.

Latest configuration. This will hold power for appx 5 seconds even if the door is closed immediately.

 

From what I have been reading about the ESP8266 the current drain is:
The ESP8266 power consumption is between 15µA and 400mA depending on different use cases.
In idle state with powered WiFi the NodeMCU V2 has a current consumption around 70mA. With an operating voltage of 3.3V
With that being the situation the best approach is to to put the unit in the deep sleep mode as previously suggested. The circuit in post #81 is load sensitive because of the requirements placed on the design and cannot deliver more then about 8 ma effectively.
Replacing Q2 with a CPC1002 should solve the load problem if pursuing this complete shut down option.
External wake up circuit.

 

From what I have been reading about the ESP8266 the current drain is:
The ESP8266 power consumption is between 15µA and 400mA depending on different use cases.
In idle state with powered WiFi the NodeMCU V2 has a current consumption around 70mA. With an operating voltage of 3.3V
With that being the situation the best approach is to to put the unit in the sleep mode as previously suggested. The circuit in post #81 is load sensitive because of the requirements placed on the design and cannot deliver more then about 8 ma effectively.
Replacing Q2 with a CPC1002 should solve the load problem.

The maximum collector current of 2N3906 (Q2) is 200 mA. What prevents it from delivering more than 8 mA to address the issue?


To address this limitation, I think we can consider replacing the PNP transistor with a P-MOSFET, as P-MOSFETs are capable of draining more current.

In the simulation of the normally closed switch, the 2N3906 appears to be drawing tens of mA. However, when a P-MOSFET is simulated in the same circuit, it shows that it can handle up to 400 mA. It's important to note that the 400 mA scenario represents an extreme case, likely when using all GPIOs and WiFi simultaneously, and operating the ESP at the highest clock speed. In most practical cases, the current requirement will not exceed 200 mA, and on average, 100 mA will be sufficient.

 

This is the simulation of the normally open switch (when it is not affected by any external magnet). The same P-MOSFET can handle 400 mA.




There is only one issue with this design related to C11. Let's consider this scenario:

• Initially, the door is closed, so the switch S20 is closed, and everything is off.
• Someone opens the door and enters, and the door remains open for 3-5 seconds, which is sufficient for the ESP to wake up.
• The ESP wakes up and pulls the KEEP_ALIVE signal high, and starts executing its code.
• It takes a considerable amount of time when executing the code (e.g., 1 minute, assuming it lost connection to the Wi-Fi and then reconnects).
• Finally, it finishes the code and pulls down the KEEP_ALIVE signal to shut down.

At this point, a strange undesired behavior occurs. Instead of being powered off, the system either stays powered on or wakes up again. This is due to the capacitor C11 introducing some delay to both the switch S20 and the KEEP_ALIVE signal. We want this behavior to only affect the switch S20. While it works well when you open and close the switch rapidly, the scenario mentioned above is very common, and we expect it to happen repeatedly.

 

What prevents it from delivering more than 8 mA to address the issue?

The amount of current it can deliver is dependent on the bias current through the base junction of the transistor. Yes it can handle up to 200ma but only if fully biased. Your design constraint of using the reed switch with essentially zero current draw is the problem as far as using a 2N3906.
I think the simulation is flawed. The output on Q27 shows 417mv at PR84 but also shows 3.29V at PR86. They are the same connection so how can that be?
It's also showing only 338mv at PR83 which in no way can turn ON Q29 and activate Q27.

 

At this point, a strange undesired behavior occurs.

I don't see that on my breadboard setup.

 

The amount of current it can deliver is dependent on the bias current through the base junction of the transistor. Yes it can handle up to 200ma but only if fully biased. Your design constraint of using the reed switch with essentially zero current draw is the problem as far as using a 2N3906.
I think the simulation is flawed. The output on Q27 shows 417mv at PR84 but also shows 3.29V at PR86. They are the same connection so how can that be?
It's also showing only 338mv at PR83 which in no way can turn ON Q29 and activate Q27.

PR83 and PR84 are utilized to measure the voltage specifically across capacitors C10 and C11. In addition, I have added PR91 and PR90, which serve as absolute voltage probes, similar to PR81.

 

I don't see that on my breadboard setup.

If that's the case, it could potentially be a software glitch. To ensure that C11 is not causing a delay in powering off the ESP, we need to thoroughly investigate its behavior.
I have replaced C11 with a 100mF capacitor to enhance the detection of any potential delay. However, even after more than 100 seconds, the output is still showing a voltage of 3.29V.

 

PR83 and PR84 are utilized to measure the voltage specifically across capacitors C10 and C11. In addition, I have added PR91 and PR90, which serve as absolute voltage probes, similar to PR81.

OK I see that now.

If that's the case, it could potentially be a software glitch.

Must be as even a 100mf cap should discharge in appx 100ms. I'll test that on my breadboard and get back to you, might missing something.

 

Must be as even a 100mf cap should discharge in appx 100ms. I'll test that on my breadboard and get back to you, might missing something.

Yes, please verify the simulation results. I have conducted multiple simulations with various capacitance values for C11 and different scenarios, and it seems that C11 behaves the same way regardless of whether the switch S20 opens or the KEEP_ALIVE signal is pulled down.

 

I find this thread really annoying. It is an exercise in adding unnecessary complexity to handle non-existent problems. Put the processor in deep sleep and wake it up when the door is opened. If the processor has internal weak pull-ups, like every micro I have used has, the switch is the only component needed. Extra hardware to do things trivially done in software is just plain silly.

 

I find this thread really annoying. It is an exercise in adding unnecessary complexity to handle non-existent problems. Put the processor in deep sleep and wake it up when the door is opened. If the processor has internal weak pull-ups, like every micro I have used has, the switch is the only component needed. Extra hardware to do things trivially done in software is just plain silly.

Yeah and I don't get it either. The ESP8266 for example has at least 3 sleep modes where current draw is negligible. In addition magnetic reed switches for open or closed door detection are very common including NO and NC contacts are common. Beats me?

Ron

 

I find this thread really annoying. It is an exercise in adding unnecessary complexity to handle non-existent problems. Put the processor in deep sleep and wake it up when the door is opened. If the processor has internal weak pull-ups, like every micro I have used has, the switch is the only component needed. Extra hardware to do things trivially done in software is just plain silly.

I understand that you find this thread frustrating, and I appreciate your perspective on simplifying the solution. Using deep sleep and internal weak pull-ups to handle the door opening is indeed a straightforward approach, and it can be effective for many applications. However, I am exploring different solutions to broaden my understanding and gain experience in working with various hardware components. While some might see it as unnecessary complexity, it provides a valuable learning opportunity for me. I'll consider your feedback and keep in mind the more straightforward software-based approach for future prototypes. Thank you for sharing your thoughts.

I completely understand your viewpoint. While the circuit may seem more complex compared to a software-based solution, exploring hardware-based approaches can offer unique insights and possibilities like extreme low power usage. It's important to remember that there is no one-size-fits-all solution, and different scenarios may require different approaches.

Even though this circuit may not suit everyone's needs, it can still be valuable to others who seek to understand and work with specific hardware components or explore alternative methods of achieving similar results. The diversity of solutions in the engineering and electronics field allows for creativity and innovation.

Ultimately, each prototype in home automation is an opportunity for gaining more practical experience and learning. While some may prefer software solutions, others, like myself, find value in understanding hardware implementations. It's about exploring various approaches and finding what best suits our specific requirements.

In the end, I believe that a wide range of solutions can coexist, and what might not be useful for one person could be a breakthrough for someone else. Different perspectives and ideas contribute to the advancement of technology and innovation in various fields.

 

Anyway, I will present the final circuit, after editing, with detailed simulations and explanations of its advantages over software-based solutions. I strongly believe that this approach will prove to be exceptionally beneficial for anyone who comes across this thread in the future. By exploring and showcasing the hardware implementation, we can highlight the unique benefits it offers, which may not be achievable through software alone.

 

Possibly the next time you could explain that your goal is to learn circuits rather than have many of our post go with no response and wonder exactly what your goal actually was.

Thank You
Ron

 

Hello Reloadron,

Thank you for your feedback; it is genuinely appreciated. I want to clarify that my main goal in this thread is to learn more about circuits and gain a deeper understanding of the design process. I apologize if my approach seemed unclear (while I indicated that I require a modification for the previous circuit in post #1), and I understand the concern about unanswered posts.
To address this, I will refrain from posting multiple times in the thread. Instead, I plan to compile all the final circuit details, guidance, and explanations in a single comprehensive post. My intention is to create a valuable resource for others who may come across this thread in the future, enabling them to learn from our discussions and experiences.
Over the past few days, I have conducted extensive simulations and thorough research in related topics. My aim is to achieve extreme power efficiency in the final circuit design. While the circuit itself may not be simple, its purpose is to perform a straightforward task efficiently by powering on an ESP using a variety of triggers.
I believe that even a seemingly simple circuit can have far-reaching applications, and I hope future readers find it beneficial in various scenarios. Encouraging such efficient and versatile designs can lead to valuable breakthroughs in the field of home automation.
Once again, I am grateful for your feedback, and I respect your viewpoint. Please understand that my primary objective is to learn and contribute to the knowledge base of others. Let's maintain a supportive and understanding environment for everyone involved in the discussion.
Thank you.

 

My aim is to achieve extreme power efficiency in the final circuit design.

Have you considered the expense of powering up a processor at each event vs the expense of waking it from sleep? I would not presume to know this without some research and probably experimentation.

The efficiency of any such system also depends on the frequency of the events and processing power required to handle them, and required response time. Which means there is no general method that will always be the most efficient.