Prompts for Arduino, ESP32, and Raspberry Pi: Build a Smart Home, Auto-Watering System, and Robot Without an Engineering Degree

Prompts for Arduino, ESP32, and Raspberry Pi: Build a Smart Home, Auto-Watering System, and Robot Without an Engineering Degree

You don't need a degree in electronics to build a working IoT device in 2026. What you actually need is a clear problem, a board, and the ability to describe what you want to an AI assistant precisely enough that it produces compilable code. The bottleneck for most beginners isn't soldering — it's the blank page: how do I structure a sketch, which library do I include, why does my MQTT client keep disconnecting at 3 a.m.

This collection is built around that bottleneck. Each prompt below is a copy-paste-ready request you can drop into an AI agent, with a note on which task it fits, a realistic usage example, and the kind of output you should expect. The examples reference real, documented APIs: Arduino's setup()/loop() structure, ESP32's ESP-IDF and Arduino core, Raspberry Pi's RPi.GPIO and gpiozero, MicroPython, MQTT 3.1.1 (OASIS standard), and Home Assistant's MQTT Discovery. Nothing here is invented hardware or a made-up protocol.

One caveat before you start: always verify generated pin numbers against your board's pinout. An AI can write a correct analogRead() call and still point it at a pin that doesn't exist on your specific ESP32 variant. Treat every prompt as a strong first draft, not gospel.

1. The "Explain My Board First" Prompt

Task: Onboarding yourself to unfamiliar hardware before writing a single line.

Prompt:

I have an ESP32-WROOM-32 dev board. List: (1) which GPIO pins are safe for digital input/output, (2) which support ADC2 and why ADC2 conflicts with Wi-Fi, (3) which are input-only, (4) which are strapping pins. Cite the Espressif ESP32 datasheet section names. Output as a Markdown table.

Why it works: Most beginner failures are pin-related, not code-related. This forces the model to surface constraints like "GPIO 34–39 are input-only" that you'd otherwise learn the hard way.

Example output snippet:

2. Sketch Generator with Explicit Library Versions

Task: Generate a complete Arduino sketch that actually compiles.

Prompt:

Write an Arduino sketch for an ESP32 that reads a DHT22 on GPIO 4 and publishes temperature and humidity to an MQTT broker every 30 seconds. Use PubSubClient and DHTesp libraries. Include Wi-Fi reconnect logic in loop(). Target Arduino core 2.0.x. Add comments explaining each block.

Why it works: Naming the libraries and core version prevents the model from hallucinating a dht.read() signature that doesn't match. Specify versions whenever possible.

Reality check: PubSubClient's default buffer is 256 bytes. If your JSON payload grows, you'll silently drop messages — ask the AI to call setBufferSize() explicitly.

3. Auto-Watering System: State Machine, Not delay()

Task: Build a plant watering controller that doesn't block.

Prompt:

Design a non-blocking auto-watering system for ESP32. Read a capacitive soil moisture sensor on ADC1_CH0 every 10 minutes. If moisture < threshold, run a relay pump for 5 seconds, then wait 1 hour before the next check. Use millis()-based timing, no delay(). Output a state machine diagram in text and the full sketch.

Why it works: delay() is the single most common beginner bug — it freezes Wi-Fi and MQTT. Forcing a state machine keeps the device responsive.

Calibration tip: Capacitive sensors read ~2600–3200 in dry air and ~1200–1500 in water (varies by model). Ask the AI to generate a calibration routine that prints raw values over serial so you can set your own threshold.

4. MicroPython Firmware for Raspberry Pi Pico W

Task: Move from C++ to Python for faster iteration.

Prompt:

Write MicroPython code for a Raspberry Pi Pico W that connects to Wi-Fi, reads an onboard temperature via ADC(4), and serves a JSON endpoint at /status using the socket module. Include a simple HTTP response with proper headers. Explain the conversion formula for the Pico's internal temperature sensor.

Why it works: The Pico W's internal temp sensor formula (27 - (voltage - 0.706) / 0.001721) is a real, documented quirk. Asking for the explanation makes the AI commit to the actual constant instead of guessing.

5. MQTT Topic Design and Discovery

Task: Structure your topics so Home Assistant finds devices automatically.

Prompt:

Design an MQTT topic hierarchy for a home with 3 rooms, each with temperature, humidity, and a light. Then write the Home Assistant MQTT Discovery config payloads so the devices appear automatically. Use the homeassistant/<component>/<node_id>/<object_id>/config format. Show one full retained JSON payload.

Why it works: MQTT Discovery is documented behavior, not magic. Once the AI produces the correct config topic structure, your entities appear without YAML editing.

Example config topic: homeassistant/sensor/livingroom_temp/config

6. Home Assistant Automation from Natural Language

Task: Turn "dim the lights when the movie starts" into working YAML.

Prompt:

Write a Home Assistant automation in YAML: when my media_player enters state 'playing' after 8 PM, dim living room lights to 15% over 3 seconds and close the blinds. Use the current automation syntax with trigger, condition, and action blocks.

Why it works: HA's YAML schema changes between versions. Asking for "current syntax" nudges the model toward trigger/condition/action rather than the deprecated platform-only style.

7. The "Why Is My Device Rebooting?" Debugger

Task: Diagnose crashes from serial logs.

Prompt:

My ESP32 reboots every ~40 seconds. Here is the serial output: [paste]. Identify the likely cause (brownout, watchdog, exception), explain what each line means, and suggest 3 fixes ranked by likelihood.

Why it works: ESP32 backtraces include Guru Meditation Error, rst:0x..., and a decoded exception. Feeding the raw log beats describing the symptom — the model reads the actual reset reason.

Common culprit: A brownout detector was triggered message almost always means your USB port can't supply enough current when Wi-Fi transmits. A powered hub or a proper 5V supply fixes it.

8. Robot Motor Control with PWM

Task: Drive a two-wheeled robot without burning out the motors.

Prompt:

Write Arduino code to control two DC motors via an L298N driver on an ESP32. Implement forward, backward, turn left, turn right, and stop functions. Use `ledcSetup` and `ledcWrite` for PWM (the ESP32 Arduino core 2.x API). Explain the difference between `analogWrite` and `ledcWrite` on ESP32.

Why it works: On ESP32, analogWrite is not the classic AVR implementation — the LEDC peripheral is. Asking for the distinction prevents copy-pasting AVR tutorials that don't work.

9. Sensor Fusion: Combining Two Readings

Task: Smooth noisy sensor data before acting on it.

Prompt:

I have a noisy ultrasonic distance sensor (HC-SR04) on an ESP32. Write code that takes 5 readings, discards outliers using median filtering, then applies an exponential moving average with alpha=0.2. Explain why median-first then EMA reduces false triggers.

Why it works: This is real signal processing, not hand-waving. Median removes spikes (a hand waving past the sensor); EMA smooths the remaining jitter. Both are standard techniques.

10. Power Optimization for Battery Projects

Task: Make a sensor node last months, not days.

Prompt:

My ESP32 sensor node runs on 18650 batteries and dies in 2 days. Rewrite the firmware to use deep sleep between readings, wake every 10 minutes, and disconnect Wi-Fi immediately after publishing. Calculate expected battery life given a 2000 mAh cell and a 20 mA average active current for 3 seconds per wake.

Why it works: Deep sleep is the single biggest lever for battery IoT. The math is simple enough that the AI can show its work, and you can sanity-check it.

Rough estimate: 3s active at ~120 mA peak + 597s sleeping at ~10 µA ≈ average of ~0.6 mA → roughly 130+ days on 2000 mAh. Real numbers vary with regulator efficiency.

11. OTA Updates So You Stop Unplugging Cables

Task: Push firmware wirelessly.

Prompt:

Add ArduinoOTA to my ESP32 sketch so I can upload new firmware over Wi-Fi from the Arduino IDE. Include the hostname setup, the `ArduinoOTA.handle()` call in loop(), and a note on what to do if the device doesn't appear in the Ports menu.

Why it works: OTA is built into the ESP32 Arduino core — no extra hardware. The troubleshooting note matters because mDNS (which OTA relies on for discovery) is blocked on many routers.

12. Raspberry Pi as a Local MQTT + Home Assistant Hub

Task: Replace cloud dependency with a local server.

Prompt:

Give me the Docker Compose file to run Mosquitto MQTT broker and Home Assistant on a Raspberry Pi 4 with 4GB RAM. Include volume mounts for persistence, a mosquitto.conf with `allow_anonymous false` and a password file, and the port mappings. Explain how to generate the password file with mosquitto_passwd.

Why it works: This is a well-documented Docker setup. mosquitto_passwd -c /path/passwd user is the real command. Running locally means your automations survive an internet outage.

13. Cross-Board Porting Assistant

Task: Move a project from Arduino Uno to ESP32 without rewriting from scratch.

Prompt:

I have this Arduino Uno sketch: [paste]. Port it to ESP32. List every change needed: pin remapping, 3.3V logic concerns, analogRead resolution differences (10-bit vs 12-bit), and any library incompatibilities. Output a diff-style summary.

Why it works: The 10-bit vs 12-bit ADC difference alone breaks threshold logic silently. A structured diff makes the migration auditable.

14. Safety and Compliance Prompt

Task: Don't burn your house down with a mains-powered relay.

Prompt:

I'm switching a 220V AC load with a relay controlled by an ESP32. List the safety requirements: isolation between low and high voltage, creepage distance, fuse placement, and why you should never power the relay coil from the ESP32's 3.3V pin. Reference general electrical safety principles.

Why it works: This is the prompt most beginners skip. The answer isn't a substitute for a licensed electrician, but it flags the real hazards — mains voltage, coil current, and back-EMF from inductive loads.

15. The "Teach Me the Concept" Prompt

Task: Fill the knowledge gap behind the code.

Prompt:

Explain I2C vs SPI vs UART as if I'm building my first multi-sensor project. Cover: number of wires, max devices, typical speed, and one concrete example of when each is the right choice. Use a table, then one paragraph on how to pick.

Why it works: You'll hit this decision within your first week. Understanding the tradeoffs means you stop guessing which sensor to buy.

Putting It Together

The pattern across all fifteen prompts is the same: name your board, name your libraries, name your constraints, and ask for the reasoning. That's what separates a prompt that produces compilable code from one that produces plausible-looking garbage. Start with prompt #1 to learn your hardware, use #2 and #3 to get something blinking and watering, then layer in MQTT (#5), Home Assistant (#6), and OTA (#11) as your project grows.

The real skill isn't memorizing syntax — it's learning to describe a system precisely. Every time you write a prompt, you're forced to clarify what you actually want the device to do. That clarity is the engineering skill, and it's fully learnable without a degree.

If you want to go deeper into structured, self-paced learning on embedded systems and IoT, asibiont.com covers the fundamentals with AI-guided practice. Bring a board, bring a problem, and start with prompt #1.