When I started building an IoT smart parking system on an ESP32, I expected the hardest part to be the software — MQTT messaging, the real-time dashboard, the sensor logic. I did not expect my biggest engineering problem to be electricity itself . The Symptom My setup had a 7-sensor infrared array feeding into the ESP32, which controlled multiple servo motors to open and close parking gates. The moment I wired the servos directly to the same power rail as the ESP32, things got weird: The display would randomly turn off The servos themselves wouldn't move reliably Programming the open/close angle logic became a nightmare — behavior that should have been simple felt inconsistent and unpredictable At first, I assumed it was a code problem. It wasn't. Isolating the Problem Instead of guessing, I disconnected the servo motors from the circuit first — and the ESP32 and display immediately behaved normally again. That confirmed the servos were the source of the issue, not my code. I brought the problem to a teammate and did some research to understand the why , not just patch the symptom. The Actual Cause: Inrush Current Servo motors, especially under load, draw a large spike of current the moment they activate — far more than their steady-state operating current. This is called inrush current . When multiple servos pulled that current spike from the same power rail as the ESP32, it caused a voltage drop (brownout) on the line. The ESP32 is sensitive to voltage stability — even a brief dip is enough to reset it or disrupt connected peripherals like the display. That's exactly why the screen kept turning off: it wasn't a display bug, it was a power problem wearing a display bug's disguise. The Fix: Power Domain Separation The fix wasn't a smarter piece of code — it was an isolated servo shield to physically separate the servo power domain from the ESP32's logic power domain. The servos now draw their current spikes from their own supply, instead of dragging down the rail the ESP32 depends on. Once that separation was in place: The brownout resets disappeared completely The display stopped randomly turning off The servo angle control — which had felt buggy and inconsistent before — suddenly worked exactly as programmed, because the logic was never actually broken. It was just running on unstable power. The Lesson The most valuable part of this bug wasn't the fix itself — it was realizing the bug wasn't in my code at all. When symptoms show up in seemingly unrelated places (a display glitching, motor logic acting "buggy"), it's worth stepping back and asking whether the real problem is one layer lower than where the symptoms appear. In embedded systems, software and hardware failures can look identical from the outside. Isolating variables — literally disconnecting components one at a time — is still the fastest way to tell them apart.