Overview
Personal hobby projects built between 2018-2022, before formal software engineering training. These self-taught embedded systems experiments evolved into a fully automated smart home - demonstrating the curiosity and persistence that later led to a professional software engineering career.
Flagship Project: MEBO Autonomous Robot
Complex robot requiring real-time motor control AND web connectivity. ESP32 alone lacked sufficient GPIO for all sensors, so I designed a dual-processor architecture with a custom UART protocol built from scratch.
Core 0"] MOTOR_CTRL["Motor Control
Core 1"] AUTONOMY["Autonomous
Decision Engine"] end subgraph ATMEGA["ATmega2560 - Sensors & GPIO"] ULTRASONIC["Ultrasonic Array
Obstacle Detection"] CONTACT["Contact Sensors
Collision"] DOCK["Docking Station
Detection"] end subgraph PROTOCOL["Custom UART Protocol"] UART["String-Based Serial
Built from Scratch"] end subgraph ACTUATORS["Actuators"] MOTORS["DC Motors
with Encoders"] SERVOS["Servos
Arm/Camera"] end end ESP32 --- UART UART --- ATMEGA AUTONOMY --> MOTOR_CTRL MOTOR_CTRL --> MOTORS MOTOR_CTRL --> SERVOS ULTRASONIC --> AUTONOMY CONTACT --> AUTONOMY DOCK --> AUTONOMY
Key Achievements
Custom UART Protocol
String-based serial communication built from scratch for fast, reliable inter-processor coordination between ESP32 and ATmega2560.
Encoder Navigation
Motor encoders enable precise navigation - robot maintains true heading without drift using real-time correction algorithms.
Dual-Core ESP32
Web server on Core 0, real-time motor control on Core 1. Ensures responsive UI while maintaining precise motor timing.
Fully Autonomous
Obstacle avoidance, docking station detection, and room navigation with no remote control needed. Built entirely solo - hardware, wiring, firmware, and protocol.
Technologies
Flagship Project: Automated Cat Feeder
ESP32-based system that loads, opens, and serves canned cat food with sensor feedback and multi-hub failover for reliability.
ADC"] FILL["Fill Level
Detection"] LIMIT["Limit Switches"] end subgraph NETWORK["Network"] WIFI["WiFi Manager
Dual SSID Failover"] HTTP["HTTP Server
REST API"] CALLBACK["Hub Callbacks
3-Hub Redundancy"] end end subgraph SMARTHOME["Smart Home Integration"] HUB1["Hubitat Hub 1"] HUB2["Hubitat Hub 2"] HUB3["Hubitat Hub 3"] end ESP32 --> LOADER ESP32 --> OPENER ESP32 --> SERVO ESP32 --> WEIGHT ESP32 --> FILL ESP32 --> LIMIT ESP32 --> WIFI WIFI --> HTTP HTTP --> CALLBACK CALLBACK --> HUB1 CALLBACK --> HUB2 CALLBACK --> HUB3
Key Features
Mechanical Automation
Can loading and opening mechanism with motor feedback. Weight and fill level monitoring for jam detection.
3-Hub Failover
If primary Hubitat hub fails, device automatically reports to backup hubs. Never miss a feeding due to network issues.
Watchdog Timer
4-hour auto-reset for stability. Web UI for manual override and diagnostics.
Sensor Integration
ADC-based weight sensing, limit switches for position detection, and fill level monitoring.
Technologies
Flagship Project: Adaptive Window Controller
Self-learning motor controller that adapts speed profiles based on observed performance and persists learned values across power cycles.
Command"] --> STATE["State Machine"] STATE --> PWM["PWM Controller
10-bit Resolution"] PWM --> MOTOR["DC Motor
H-Bridge"] MOTOR --> ENCODER["Position
Feedback"] ENCODER --> LEARN["Speed Learning
Algorithm"] LEARN --> RTC["RTC Memory
Persists Across Resets"] RTC --> PWM end subgraph SAFETY["Safety Features"] BOOT["Boot Counter"] --> FAILSAFE["Fail-Safe Mode
After 3 Rapid Reboots"] NTP["NTP Time Sync"] --> SCHED["Scheduled
Operations"] end
Key Features
Adaptive Speed Learning
Adjusts motor timing based on observed performance. Initial calibration measures time to fully open/close, then runtime adaptation handles stalls or overshoots.
RTC Memory Persistence
Learned speeds survive soft resets (ESP.restart()). Falls back to defaults if RTC data is corrupted.
Boot Loop Prevention
After 3 rapid reboots within 60 seconds, enters fail-safe mode to prevent infinite boot loops. Clears counter after 60 seconds of stable operation.
Multiple Motor Variants
Stepper, PWM with H-bridge, and linear actuator versions across bedroom, office, and living room windows.
Technologies
Flagship Project: Remote PC Power Control
Hardware-level PC control accessible via SSL VPN. When software remote access fails because the OS is frozen, this provides the ultimate fallback.
Power Controller"] WEBUI["Built-in Web UI"] RELAY["Relay
Power Button"] RESET["Reset Line
Hard Reboot"] end subgraph L2["Layer 2 - Z-Wave"] ZWAVE["Z-Wave Switch
Power Monitoring"] OUTLET["Smart Outlet
Last Resort Kill"] end end subgraph ACCESS["Access Methods"] VPN["SSL VPN
Remote Access"] HUB["Hubitat Hub"] TILES["Custom Tiles
Dashboard"] end VPN --> ESP VPN --> HUB HUB --> ESP TILES --> HUB ESP --> WEBUI ESP --> RELAY ESP --> RESET RELAY --> PC["Office PC"] RESET --> PC ZWAVE --> OUTLET OUTLET --> PC HUB --> ZWAVE
Key Features
Sleep/Wake Control
Put PC to sleep or wake via Hubitat, just like controlling a light switch.
Hard Reboot Capability
Simulate power button hold or reset line trigger when OS is completely frozen.
Layered Failover
ESP8266 for normal control, Z-Wave smart outlet as ultimate kill switch. Power monitoring confirms actual state.
Never Lost Access
Years of operation without ever being locked out of remote PC - demonstrates thinking beyond the happy path.
Technologies
Technical Challenges Solved
IR Protocol Memory Management
Samsung AC IR codes are 199 bytes each. With 20+ temperature/mode combinations, SRAM quickly exhausts on ESP8266 (80KB total). Solution: Store IR codes in PROGMEM (flash), load single code to SRAM buffer only when transmitting.
Multi-Hub Failover
Smart home hubs occasionally go offline. Solution: Dual SSID support with 3-hub callback system. Device attempts callback to each hub in sequence until successful.
Boot Loop Prevention
Configuration errors can cause infinite reboot loops. Solution: Boot counter in RTC memory - if counter > 3 within 60 seconds, enter fail-safe mode with web UI for diagnostics.
WiFi Stack Starvation
ESP8266 WiFi stack needs regular servicing. Blocking delay() calls cause connection drops. Solution: Custom wait() function that services HTTP handlers and ArduinoOTA during delays.
Architecture Patterns
Common design patterns applied across all projects:
Dual SSID"] HTTP["HTTP Server
REST Endpoints"] OTA["OTA Updates
ArduinoOTA"] NTP["NTP Client
Time Sync"] end subgraph APP["Application Layer"] STATE["State Machine
Device Logic"] PERSIST["RTC Memory
State Persistence"] WATCHDOG["Watchdog
Auto-Recovery"] end subgraph HARDWARE["Hardware Layer"] GPIO["GPIO Control
Relays/Motors"] ADC["ADC Reading
Sensors"] PWM["PWM Output
Motor Speed"] end subgraph INTEGRATION["Integration"] CALLBACK["Hub Callbacks
SmartThings/Hubitat"] WEBUI["Web UI
PROGMEM HTML"] end end WIFI --> HTTP HTTP --> STATE STATE --> GPIO STATE --> ADC STATE --> PWM STATE --> PERSIST HTTP --> CALLBACK HTTP --> WEBUI OTA --> WIFI NTP --> STATE WATCHDOG --> STATE
File Structure Convention
Projects use multi-file .ino structure with alphabetical prefixes for compilation order: