ESP32-Based Autonomous Environmental Control System for Rain and Proximity-Driven Actuation in Residential Applications

In recent years, residential home automation has grown substantially, driven by advances in Internet of Things (IoT) technology and increasing demand for intelligent living environments. Particularly for seniors and people with disabilities, living autonomously by having their environment automatically respond to different stimuli can provide a greater level of safety, comfort, and independence during daily activity [1, 2]. For instance, applications that protect clothes from rain at outdoor laundries or control door access based on the proximity of the user without requiring continuous human involvement both represent practical ways to implement automation in residential locations and therefore realize significant social returns.

Though there are commercial products that offer the types of functionalities outlined above, most of them are independent systems, making their implementation prohibitively expensive due to high development costs and limiting their use in areas with developing economies [2]. Therefore, there is an increased interest in developing low-cost, embedded platforms that can integrate multiple types of sensing and actuation into a single architecture.

This document outlines the ESP32 as a potential microcontroller for real-time control applications, due largely to its dual-core processor (240 MHz). The ESP32 also integrates 2.4 GHz Wi-Fi and supports multiple hardware pulse-width modulation (PWM) channels. Therefore, many researchers and engineers use the ESP32 in their real-time monitoring systems because previous studies have shown excellent performance when using the ESP32 with Message Queuing Telemetry Transport (MQTT) protocols [3, 4]. In addition, the reduction in latency and improvement in system responsiveness for time-critical applications from performing local processing at the ESP32 device level can be particularly advantageous when developing automated solutions that require minimal dependency on cloud services [5].

The use of resistive rain-detection sensors is well-documented in the literature related to residential and agricultural IoT applications [6]. However, with few exceptions, most reported implementations are focused on acquiring environmental data rather than performing mechanical actuation. Very few examples exist where integrating local rain-monitoring sensor data with automated mechanical response systems (e.g., servo-driven protection systems) has been examined for residential applications. Similarly, many proximity-sensing solutions (active and passive) based on ultrasonic sensors such as the HC-SR04 have been reported in robotics and automation [7-9]. Most of these systems were implemented independently as stand-alone modules and/or have been built using centralized processing architectures, thereby limiting their scalability and responsiveness.

Smart homes today are widely using cloud based architecture to create communication delays which creates issues surrounding complexity and reliability when networks are experiencing low signal strength [10]. The use of a method called edge-based enables real-time action, less latency, and more reliable sensors/services helping provide an environment that supports distributed computing [11-13]. As outlined above, there is a clear need for a unified, low-cost solution to control environmental aspects that combines sensing modality data with reliable actuation.

As a solution to this identified gap, we have created and implemented a dual-subsystem automation framework which consists of rain detection for laundry protection along with proximity sensors for door opening/closing within a singular ESP32-based architecture.

Dual uses of debounce-enabled resistive sensing for precipitation detection and deferred actuation logic for safety based on proximity allow for reliable operation of the system via control of the SG90 servos using PWM signaling. This work utilizes independent subsystems that have been validated through both simulation and physical testing in Wokwi, demonstrating the feasibility of low-cost embedded solutions for the purpose of real-time automation in a home environment with high accuracy and very low latency.

The remaining sections of this document provide detail about the hardware architecture and methodology (in Section Two), present experimental results and discuss the results (in Section Three), and conclude with a summary of this work and suggestions for further research directions (in Section Four).

This section describes the hardware architecture and the operational principles for sensing, control, and validation of the proposed system. The design follows a modular structure to facilitate reproducibility, clarity, and scalability of the embedded IoT implementation. Each subsystem comprises a sensing device (i.e., sensor), an actuator (i.e., motor or light), and a computing device (i.e., microcontroller) for performing autonomous operations in a real-time environment.

3.1 Hardware components

The hardware elements of this project consist of the rain sensor FC-37 (Figure 1) and ultrasonic sensor HC-SR04 (Figure 2). The backbone of the architecture is the dual-core ESP32 DevKit V1 microcontroller, which has built-in Wi-Fi, multiple PWM channels, and is ideally suited for real-time control applications. The actuation of the sensors will be accomplished by two servo motors SG90, each supporting its own subsystem.

Figure 1. FC-37 resistive rain sensor module

Figure 2. HC-SR04 ultrasonic distance sensor module

Table 1. Specifications of the hardware components used in the system

Note: GPIO: General-Purpose Input/Output; ADC: Analog-to-Digital Converter; PWM: Pulse-Width Modulation

According to current research references [20, 21], the performance of IoT platforms based on ESP32 cores is very efficient when operated in real-time; they offer low power (consumption) combined with low latency. Both FC-37 and HC-SR04 sensors perform reliably and are commonly used in low-cost automation systems due to their user-friendly design, ease of integration to the system, and compatibility with embedded platforms [22]. Main characteristics of the hardware used in this research are summarized in Table 1.

3.2 FC-37 rain detection subsystem

The resistive nature of the FC-37 rain sensor, where water droplets present on the sensor decrease the electrical resistance between its conductive traces, allows for an associated change in the sensor's voltage output to be detected by the ESP32 via the analog-to-digital converter (ADC). The sensor is then conditioned to provide a 3.3 V input to be compatible with the ESP32.

The block diagram of the rain detection system is shown in Figure 3; the sensing, processing, and actuation subsystems are all integrated into the rain detection system.

Figure 3. Block diagram of the FC-37 rain-detection and SG90 laundry-retraction subsystem

A debounce time of 5 seconds will reduce false activations of the sensor due to temporary moisture or changes in humidity by enabling the sensor to detect and measure moisture for a period of time. A similar use of filtering and debounce techniques has been demonstrated to improve measurement stability in ultrasonic and resistive sensing systems under variable environmental conditions [7]. The SG90 servo motor, selected for its 50 Hz PWM compatibility and compact form factor [23], is activated only when a valid rain condition persists beyond the debounce window.

In addition, when a valid rain condition is confirmed, the ESP32 generates a 50 Hz PWM pulse on GPIO 14 to rotate the SG90 servo motor from 0° to 90°, allowing the laundry collection mechanism to retract. Once the rain condition clears, the servo returns to its original position.

An illustration of the results from Wokwi's simulation of this experiment is shown below in Figure 4. The diagram clearly demonstrates that the transition from dry to wet and vice versa occurs correctly before any physical implementation occurs.

Figure 4. Wokwi simulation of the FC-37 subsystem: Dry state (servo at 0°) and wet state (servo at 90°)

The operational sequence illustrated in Figure 5 describes the debounce filtering process and the corresponding actuation cycle, ensuring stable system behavior during intermittent precipitation.

Figure 5. Flow diagram of the FC-37 rain-protection subsystem showing initialization, debounce logic, and servo actuation cycle

3.3 HC-SR04 proximity detection subsystem

The HC-SR04 ultrasonic distance sensor works by sending out a 40 kHz sound wave and receiving the signal back so that we can calculate how far away an object is from the sensor using time-of-flight principles shown in Eq. (1).

$Distance (\mathrm{cm})=\frac{(\text { Echo time }(\mu \mathrm{s})) *(0.034)}{2}$        (1)

The speed of sound in air at room temperature is 0.034 cm/µs. Thus, the formulation of time-of-flight accounts for the distance traveled twice (i.e., to get from the transmitter to the object and back) by using 0.034 cm/µs as the average speed of sound in the environment to obtain a distance estimate that is generally accurate in short-range applications where the wall reflections are not changing significantly after repeated measurement cycles [24].

The block diagram of the proximity-detecting subsystem is shown in Figure 6 and provides insight into how the various components of the subsystem (i.e., sensors, processors, actuators) interact within the system.

Figure 6. Block diagram of the HC-SR04 proximity-detection and SG90 door-control subsystem

In this application, a distance threshold of 7 cm is defined for when to activate the door. When an object is detected to be within this distance, the ESP32 will send a signal to activate a SG90 servo motor (connected to GPIO 13) using a 50 Hz PWM signal for the servo motor to rotate between 0°-90° (to open the door - see section 3.2 for more details). When the door is opened, it will remain open for a maximum of 3 seconds while the user is present. This prevents the door from closing too quickly on the user, thus increasing their safety.

Ultrasonic sensing technologies have proven to be accurate when the ultrasonic sensor is aligned perpendicular to the detected surface; however, performance will vary depending on the surface orientation and other external variables (interference) that could affect the detected distance between the object and the door [25]. Figure 7 shows the Wokwi simulation output for both detection states — no-presence (door closed) and presence (door open, LED on) — confirming correct control logic prior to physical prototype testing.

Figure 7. Wokwi simulation of the HC-SR04 subsystem: No-presence state (door closed) and presence state (door open, LED on)

In addition, the operational method is explained in Figure 8 by integrating the distance detection process, threshold evaluation, and controlled actuation into a cyclic monitoring loop. The systematic nature of this organization allows for stable operation and avoids the undesirable oscillation that can occur when an object gets close to the detection boundary.

Figure 8. Flow diagram of the HC-SR04 proximity subsystem: Distance measurement, threshold comparison, and deferred door-close logic

3.4 SG90 servo motor control via pulse-width modulation

Each of the two subsystems utilizes an SG90 servo motor, which is controlled via PWM signals produced by the LED Controller (LEDC) peripheral on the ESP32 microcontroller. The servo motor operates at a fixed frequency of 50 Hz, and the angular position of the shaft is determined by varying the pulse duration sent to it. A duration of about 1 ms will correspond to 0 degrees of rotation, whereas a duration of about 2 ms will correspond to 180 degrees of rotation. This allows for very precise position control of the servo motor when operating in that range.

In this proposed design, only partial rotation (0-90 degrees) will be required to produce the required mechanical actions. Because of the use of hardware-based PWM generation, there is a high level of accuracy associated with timing control, as well as less load on the processor compared to a software-based approach. Several studies have demonstrated that using dedicated PWM peripherals can significantly enhance the stability of actuation in embedded control systems [21, 26].

3.5 Printed circuit board design and system integration

To increase the robustness of the system and make experimentation reproducible, each of the two subsystems was created on a dedicated printed circuit board (PCB) designed using KiCad. Each PCB was designed with proper signal routing, power distribution, and decoupling capacitors to reduce electrical noise and ensure consistent operation. All PCBs were designed with industry-standard connectors for the sensors, actuators, and power supply; all PCBs also included a unified Universal Asynchronous Receiver-Transmitter (UART) interface for programming the firmware. The schematic diagrams for the FC-37 and HC-SR04 subsystems can be seen in Figures 9(a) and (b).

(a)

(b)

Figure 9. (a) Schematic of the FC-37 subsystem (KiCad), (b) Schematic of the HC-SR04 subsystem (KiCad)

Figures 10(a) and (b) show the corresponding PCB layouts for each subsystem, where the placement of components, routing topology, and electrical connections within each subsystem can be observed. The PCB layouts were designed so that there would be short signal paths between the ESP32, sensors, and actuators, which reduced propagation delay and lowered the effects of electromagnetic interference (EMI) on the devices that are being used to communicate with the ESP32 [27]. Special attention was given to how power was distributed and how the grounds were connected so that both analog sensors and PWM actuators operated consistently under real-time conditions. Power rail stability was measured at the ESP32 VCC pin during peak PWM actuation: supply voltage remained at 3.28 V ± 0.03 V, with no transient dips below 3.2 V. The FC-37 analog output exhibited a peak-to-peak noise of 18 mV under static dry conditions, which is below the ADC resolution threshold (26 mV for 12-bit at 3.3 V). PWM signal integrity was verified using an oscilloscope: the 50 Hz control pulse showed less than 1.2 µs of jitter across 500 consecutive cycles, confirming that hardware-based LED Controller (LEDC) peripheral generation achieves the timing stability required for precise servo control.

(a)

(b)

Figure 10. (a) PCB layout of the FC-37 subsystem, (b) PCB layout of the HC-SR04 subsystem

3.6 Validation protocol

Validation of the system was performed in two stages: the first focused on verifying that the system worked properly by conducting simulations on Wokwi; this would allow for the verification of control logic, sensor interactions and actuator responses to be verified through simulations. It has been shown that validation through simulation can reduce implementation problems in the creation of embedded systems and speed up complete development cycles [28]. For the second stage, a physical prototype of the system was created by constructing a scaled 3D model of a house out of polylactic acid (PLA). Rain was simulated by spraying mist on the FC-37 prototype sensor; object measurements were taken for proximity tests at distances from 1.0 cm up to 7.5 cm. To complement the controlled tests, two real-world test scenarios were also conducted. In Scenario A, the FC-37 subsystem was deployed on a residential balcony during a natural rainfall event (ambient temperature 18 ℃, relative humidity 87%), with the servo mechanism connected to a lightweight fabric curtain rail. In Scenario B, the HC-SR04 subsystem was mounted at a standard residential door frame (height 2.1 m) and tested with five different users approaching at natural walking speeds and at angles up to 20° from perpendicular. These field trials confirmed the system’s operational viability outside the laboratory.

The performance of the system was measured using three metrics; the accuracy of all actuators, the time it took to complete an actuation cycle (from the time of sensor threshold detection to complete servo actuation), and the reliability of the system. Before all tests, an environmental baseline was established to ensure replicability and to provide a standard for wireless communication.