50 Days, 50 IoT Projects with MicroPython – Seeking Feedback & Ideas

[kritishmohapatra]

Hi MicroPython community 👋

I’m working on a personal learning challenge:
100 days, 100 IoT projects using MicroPython.

I just completed Day 50, building projects with ESP32, ESP8266, and RP2040 (Pico).
Focus areas include:

Sensor interfacing and data logging

Local web dashboards in MicroPython

Cloud integrations (ThingSpeak / Flask APIs)

Basic anomaly detection pipelines

Open-source MicroPython libraries and tooling

Repository:
👉 https://github.com/kritishmohapatra/100_Days_100_IoT_Projects

The goal is to help beginners learn embedded systems with real examples and simulations.

I’d really appreciate:

Project ideas for intermediate/advanced level

Best practices for structuring embedded project documentation

Feedback on how to make the repo more useful for learners

If you find it useful, please consider starring the repo ⭐
Thanks for the amazing MicroPython ecosystem!

[Josverl]

Some suggestions from myself & Co

I suggest you try similar brainstorming with copilot or similar to help generate new ideas

1) Async Edge Scheduler + Offline-First Telemetry Buffer

• Rationale: Many IoT demos assume always-on Wi‑Fi; real devices need resilience (drops, reboots, outages).
• Core idea: Use uasyncio tasks + a flash-backed queue/ring-buffer to store sensor samples/events and “replay upload” when connectivity returns (HTTP/MQTT), with backoff and deduplication.

2) PID Temperature Controller (Reflow/Hotplate/Incubator Profile)

• Rationale: PID control is a practical “real engineering” topic and a big step up from threshold control.
• Core idea: Read temperature (DS18B20/NTC/MAX6675) at a fixed interval, run a PID loop (anti-windup + safety cutoffs), drive a heater via MOSFET/SSR, and optionally follow a time/temperature profile.

3) Closed-Loop PID Fan Controller with Tach Feedback (RPM Regulation)

• Rationale: Many projects do open-loop PWM; closed-loop RPM control is more robust and teaches feedback systems.
• Core idea: Use tach pulses to measure RPM, run PID to maintain target RPM (or a curve vs temperature), add stall detection, soft-start, and fault states.

4) ESP‑NOW Sensor Mesh + Coordinator + Time Sync

• Rationale: Wi‑Fi infrastructure isn’t always available; ESP‑NOW can build fast local networks.
• Core idea: Multiple nodes broadcast readings; a coordinator time-syncs nodes, acks/deduplicates packets, aggregates data, and bridges to MQTT/HTTP when available.

5) Reactive Power/Current Monitor + Load Shedding Policy Controller

• Rationale: Energy monitoring is useful and introduces signal processing + control policies.
• Core idea: Sample a CT clamp/ADC front-end, estimate current/apparent power, detect overload conditions, and control relays by priority (load shedding), with async sampling + decision tasks.

6) Smart Irrigation with Soil Model + PID Moisture Control

• Rationale: “Water when dry” is noisy and inefficient; plants/soil behave like a slow dynamic system.
• Core idea: Filter soil moisture readings, learn drying rate, run PI/PID to maintain a moisture setpoint, log watering events, and adapt thresholds over time.

7) Vibration Condition Monitor + Anomaly Detection (Edge Analytics)

• Rationale: Adds “edge intelligence” without requiring heavy ML; great for predictive maintenance demos.
• Core idea: Sample accelerometer data, compute features (RMS/peak/band energy), learn a baseline, trigger alerts + event logs when features drift beyond thresholds.
  Could even use machine learning using emlearn

8) Local-Only Web UI Appliance with PyScript Frontend

• Rationale: A modern UI without building a heavy backend; browser runs Python, device stays small.
• Core idea: MicroPython serves /api/* JSON endpoints + a static page; the page uses PyScript to fetch data, render charts, edit config, and provide a device “console”.

Perhaps best in multiple steps or projects
A) build pyscript webapp/ also on mobile
B) create/adapt backend
C) control direct or indirect MQTT/ database
D) reporting visualisation

9) On-Device Rule Engine / Scene Controller (“Tiny Node‑RED”)

• Rationale: Makes devices configurable without reflashing code; reusable across many projects.
• Core idea: Store rules (JSON/DSL) like “if X for Y seconds then action Z”, implement hysteresis/debounce, schedule timers with uasyncio, and expose a config API/UI.

10) Closed-Loop Servo/DC Motor Positioning with External Feedback

• Rationale: Standard servo control is open-loop; external feedback enables precision and teaches real motion control.
• Core idea: Use an encoder/potentiometer as feedback, run PID position control, include calibration and limit handling, and expose commands over UART/WebSocket/HTTP.

---

11) RP2040 (RP2) PIO Signal Generator + Logic Pattern Player

• Rationale: PIO is a signature RP2040 feature; great for deterministic timing and “hardware-like” behavior.
• Core idea: Use PIO to output precise waveforms/patterns (clock bursts, custom protocols, LED timings), provide a Python API to load sequences, and optionally add a tiny display UI.

12) RP2040 (RP2) PIO Soft-Peripheral Pack (UART/SPI/I2C via PIO)

• Rationale: Demonstrates how PIO can offload timing-critical I/O and extends available peripherals.
• Core idea: Implement (at least) a PIO UART TX/RX (or SPI), track framing/error counts, benchmark against hardware peripherals, and build a “bus exerciser” tool.

13) framebuf Mini GUI Toolkit + Demo Apps (Menus/Widgets/Graphs)

• Rationale: Reusable display/UI code is more valuable than one-off animations.
• Core idea: Build a small framebuf widget layer (labels, progress bars, sparklines, menus) with partial redraw (“dirty rectangles”), input handling (buttons/encoder), and demo apps.

14) Ultra-Low-Power Deep Sleep Sensor Node (Wake Reason + Burst Upload)

• Rationale: Battery-powered IoT is often about power strategy more than sensors.
• Core idea: Sleep most of the time, wake by timer/pin, sample quickly, burst upload (or queue if offline), persist counters/state, then deep sleep again with robust wake-reason handling.

15) Deep Sleep Door/Window Event Sensor (Debounced Wake + Event Queue)

• Rationale: Door sensors are common, but reliability details (bounce, missed events, offline queue) make it interesting.
• Core idea: Use reed/hall sensor for wake, debounce in software, record open/close events with timestamps, queue events offline, and sync later (MQTT/HTTP).

[kritishmohapatra]

Thank you so much sir for these detailed and high-quality suggestions 🙌
This is exactly the kind of real-world engineering guidance I was hoping to get from the community.

I really like the ideas around offline-first telemetry buffering, PID control systems, ESP-NOW mesh networking, vibration condition monitoring, and the tiny rule engine concept. These topics move far beyond basic demos and into production-grade IoT design, which is my long-term goal.

I plan to implement several of these ideas as part of my “100 Days, 100 IoT Projects” series and document the architecture, design decisions, and limitations so other students can learn from them too.

The RP2040 PIO projects and low-power deep sleep node ideas are especially interesting—I haven’t explored them deeply yet, but this gives me a great roadmap for advanced embedded systems learning.

If you have any recommended references, papers, or open-source projects for these topics, I’d love to study them.

Thanks again for taking the time to share such valuable insights—this is incredibly helpful!

[kritishmohapatra]

If this project helps anyone, consider starring or sponsoring to support open-source learning.

Thanks 🙌