I Handed My Plants Over to an AI Agent: A Practical Guide to Automated Watering from Sensors to Pump

The most frustrating part of keeping plants alive often isn't the watering itself—it's that you have no idea whether they actually need water right now. Wilting leaves could mean underwatering, or they could mean root rot from overwatering. Judging by eye alone has a high failure rate. Most automatic plant waterers on the market are just timed switches—hardly "smart." A creator on Bilibili decided to build it themselves: using an ESP32-S3, multiple sensors, a camera, and a large-model Agent, they assembled a plant AI Agent that can sense, reason, and actually water the plants. The real highlight of this process isn't the pump at the end—it's how an ordinary person leveraged AI to gradually close the loop of "observe—judge—act—observe again."

Run the Minimal Loop First, Then Touch Real Hardware

When facing a project spanning hardware, embedded systems, web development, and AI reasoning, wiring everything together from the start is disastrous—when something breaks, you have no idea which layer failed. The creator's approach was restrained: first have Doubao Work build a minimal version where "even the sensor data is fake," validating just one thing—whether the AI can read plant status, make a judgment, and store the result back.

This approach is worth borrowing for anyone building Agent projects. Getting the minimal loop working means the skeleton of data flow and decision logic is sound. Every subsequent real hardware integration is just swapping in a known input source, rather than debugging in the dark.

Once the skeleton worked, it was time for the real thing. The core board is an ESP32-S3, responsible for reading sensors and transmitting data over WiFi to an application on the computer. Again, the creator didn't try to do everything at once—first having the Agent help connect the board to WiFi and upload a fixed set of data, confirming the data actually reaches the application. In this step, Doubao Work directly inspected the computer environment, automatically installed Arduino CLI, compiled the firmware, and flashed it. The embedded terminal window in the reply could be clicked to test immediately, saving the hassle of switching back and forth between terminals.

ESP32-S3 is a 32-bit SoC from Espressif integrating Wi-Fi and Bluetooth 5 (LE). It uses a dual-core Xtensa LX7 architecture with a maximum clock of 240 MHz, 512 KB of on-chip SRAM, and support for external PSRAM/Flash. Compared to the classic ESP32, the S3 adds AI instruction extensions, USB OTG, and richer peripheral interfaces—making it suitable for IoT projects requiring cameras, audio, or more complex local computation. This article uses it as the core board precisely for its Wi-Fi connectivity, enough GPIO pins to attach multiple I²C sensors, and its ability to drive image modules like the ESP32-CAM; Arduino CLI support for the S3 is also mature, making it easy for the Agent to compile and flash automatically.

Giving the Agent Skin and Eyes

With the data channel in place, the next step was replacing fake data layer by layer. Temperature and air humidity use the SHT40 module, and the Agent specifically labeled the wire colors during connection—beginner-friendly. After wiring, the creator wasn't satisfied and cross-checked against the air conditioner's displayed temperature. The results matched—this kind of caution about "not blindly trusting AI" is exactly the habit hardware projects demand.

Light sensing uses the VAMO7700 module, which exposed a problem AI can't solve for you: following the suggested wiring blocks the breadboard holes in the same row. This kind of physical spatial constraint is easy for AI to get wrong without seeing the actual hardware. The creator had the Agent re-plan the wiring; while an experienced eye could still spot minor flaws, it at least demonstrated that hardware information must be fed back to the AI by a human. The soil sensor was simply tested with a cup of water, and since it hadn't been formally calibrated, the creator specifically had the Agent add a "not yet usable for judgment" status flag, preventing the AI from treating uncalibrated readings as real decision inputs.

Numbers alone aren't enough—drooping, curling, or yellowing leaves are invisible to sensors. So an ESP32-CAM was added as eyes. The creator didn't pursue real-time video, instead uploading clear photos at intervals—plant changes are slow, so a single high-resolution image is better suited for AI to compare before and after.

I²C (Inter-Integrated Circuit) is a two-wire synchronous serial bus that uses only SCL (clock) and SDA (data) signal lines to connect multiple slave devices, each with a unique address. The SHT40 temperature/humidity module and VAMO7700 light module typically use I²C, so they can share the same set of pins in parallel on the bus—which is also why breadboard wiring tends to "conflict": the same row of holes must accommodate multiple jumper wires and module pins simultaneously. Understanding I²C's addressing mechanism helps diagnose whether "can't read data" is a wiring issue, address conflict, or missing pull-up resistors. For beginners, confirming the bus can scan the device address before discussing reading calibration is the more reliable debugging order.

Reject if-else: Teach the AI to Say "Uncertain"

The real watershed is the judgment logic. If it were just "open the pump when soil moisture drops below X," a simple program would suffice—no AI needed. The creator's rule for the Agent: it must simultaneously consider photos, temperature, air humidity, light, and reliable soil data—and when information is insufficient, directly say "uncertain."

On the first comprehensive judgment, because the soil data wasn't calibrated, the Agent didn't force a conclusion—it output "uncertain." This is exactly the desired effect—the AI must not force an answer just to respond. This design is often overlooked in Agent deployment: a clearly defined capability boundary is more valuable than forced output.

But repeating the rules every time was tedious. The creator solidified this process into a skill called "Plant Health Check," after which a single sentence or click could execute the fixed workflow. He also deliberately turned off the device for testing; when the Agent discovered it was receiving stale data, it didn't proceed with old data but directly reported that the information had expired—the Agent was developing the self-awareness of "knowing when it can't judge."

Agent Skill can be understood as a packaged, reusable set of prompts plus tool-call workflows: it codifies "which sensors to read, in what order to check them, and what conditions must be met before concluding" into a capability unit that the Agent can invoke. Compared to repeating rules in every conversation, skills offer stable workflows, can be triggered by scheduled tasks or other Agents, and are easier to version-manage. This article turning inspection logic into the "Plant Health Check" skill and delegating code review to a "Full-Site Code Quality Inspector" is essentially upgrading the Agent from "one-off Q&A" to "orchestratable capability modules"—which is also the mainstream approach in current Agent engineering.

Let the AI Self-Audit, Schedule Inspections, and Monitor Remotely

Rather than checking the page design item by item himself, the creator had Doubao Work open the plant console in a browser and view the page from a user's perspective. The Agent found issues like device online status not being intuitive and simulated versus real data being easily confused. He then brought in HTML and data visualization skills to build out sensor cards, device status, AI judgments, photos, historical curves, and mobile support.

As the codebase grew, the creator worried that having one Agent write everything from start to finish would propagate earlier errors. Instead of spinning up multiple Agents, he invoked a "Full-Site Code Quality Inspector" work partner to specifically hunt for problems. The inspector identified 24 issues in one pass; severe issues were fixed first, preventing failures during long-term operation.

Skills require manual triggering, so scheduled tasks were set up to invoke the inspection skill at fixed times for unattended operation. How does one know from outside that the system is still working? Through remote control: logging into the same account on phone and computer, selecting the home computer and corresponding project on the phone, and asking a question to see the status—tasks sync across both ends.

The Pump Comes Last—and It Must Have a Safety Lock

Before truly taking over watering, the creator first dealt with the messy wiring—physical information that must be confirmed by a human. The Agent's redesigned wiring was much cleaner. When connecting the pump, he didn't let the AI start it immediately upon detecting a water shortage; instead, he added a safety restriction: the pump is only allowed to operate when the judgment result clearly indicates watering is needed AND current conditions satisfy execution requirements.

The most interesting part of this project is no longer "whether the AI can water." Opening a pump when soil is dry—a simple program can do that. What's truly valuable is the entire process: from breaking down the project, reading real sensors, and making comprehensive judgments from photos, to solidifying workflows into skills, having the Agent self-audit pages, using work partners for quality inspection, scheduled inspections, remote phone monitoring, and only then cautiously controlling the pump. This is a complete "observe—judge—act—observe again" loop, and a sample of an ordinary person using AI to bring an idea to life.

Actuator safety interlock is a common design in automation control: an action is permitted only when multiple conditions are simultaneously satisfied; if any condition fails, it stays off. In the watering scenario, "AI judges watering is needed" is only one necessary condition—it must be combined with soil data being calibrated, the device being online with fresh data, and the pump not being in a fault or manually disabled state before powering on. When driving a pump via relay or MOSFET, one should also consider fail-safe default-off on power loss, per-watering volume limits, and maximum runtime caps—preventing continuous spraying due to sensor misreads or network glitches. Such hard constraints cannot be left to the large model's discretion; they must be enforced at the code level.