Last month, my sump pump's float switch got stuck. The pump was drawing 500 watts continuously, the motor temperature was climbing toward 40C, and water was rising in the pit. I was asleep.
The AI I built caught it. It detected the abnormal power draw pattern, identified it as a stuck float, and began an automated recovery protocol. By the time I woke up, the system had run 97 recovery cycles, keeping the basement dry while preventing the motor from burning out. No flood. No dead pump. No $10,000 remediation bill.
Here's how I built it with a $25 smart plug, a local LLM running on my Mac, and three USGS stream gauges.
The Problem
Sump pumps fail in exactly two ways, both catastrophic:
- The pump dies and water rises until it floods your basement
- The float switch sticks, the pump runs continuously until the motor overheats and dies, then water rises until it floods your basement
Both failures happen silently. You find out when you step in water. By then, you're looking at $5,000-$15,000 in water damage, mold remediation, and a new pump.
I wanted something that would catch both failure modes before they became emergencies. Not a $300 "smart" water sensor that sends a push notification after the water is already on the floor. Something that understands what the pump is doing and why.
The Architecture
Three components, each doing one thing well:
1. The Sensor: Shelly Plug US Gen4
A $25 smart plug with built-in power monitoring. It reports watts, voltage, current, and internal temperature over HTTP. No cloud subscription. No app required. Just a REST API on your local network.
The key insight: you don't need a water sensor to detect a pump problem. A sump pump draws 0 watts when idle and ~500 watts when running. If it's been drawing 500 watts continuously for 3 minutes, the float is stuck. If it's drawing 0 watts during a rainstorm when the stream gauges are rising, the pump may have failed. Power monitoring tells you everything.
2. The State Machine: pump_state.py
A 7-state machine that manages the pump through failure scenarios without human intervention:
NORMAL -> stuck 3 min -> POWER_CYCLE
POWER_CYCLE -> success -> NORMAL
POWER_CYCLE -> fail -> TIER_1 (60s ON / 15 min OFF)
TIER_1 -> 3 cycles still stuck -> TIER_2 (90s ON / 10 min OFF)
TIER_2 -> 6 cycles still stuck -> TIER_3 (120s ON / 10 min OFF)
Any tier -> pump stops naturally -> COOLDOWN
COOLDOWN -> stable idle 90s -> NORMAL
Any state -> motor overtemp -> LOCKOUT (manual only)
The tiered escalation is the critical design. When the float sticks, you can't just leave the pump running (motor death) or turn it off (flood). You need a duty cycle that keeps the water manageable while giving the motor time to cool. Each tier increases the ON duration and decreases the OFF duration as the situation escalates.
3. The Brain: ai_analyzer.py + Ollama
A Flask server running on my Mac M3 Max that fuses three data streams:
- Pump telemetry: Power draw, temperature, cycle frequency from the Shelly plug (every 10 seconds)
- Weather data: Temperature, precipitation, soil moisture, snow depth from Open-Meteo (hourly)
- Stream gauges: Water levels from 3 USGS stations on the Mohawk River and Schoharie Creek (every 30 minutes)
Every 5 minutes, it sends the fused context to a Qwen 32B model running locally via Ollama. The model analyzes the current situation and produces:
- A weather risk score (0-100) based on precipitation, soil saturation, and snowmelt
- Stream trend analysis (rising/falling/stable for each gauge)
- Correlation hypotheses ("pump activity increasing as Mohawk rises at Fonda, likely regional water table effect")
- Recommended actions ("monitor closely, stream levels elevated but below flood stage")
What It Caught
On April 11, 2026, the system detected a stuck float at approximately 3am. Power draw was 493-506W continuously. The state machine began recovery:
- Power cycle attempt: failed (float still stuck)
- Escalated to TIER 1: 60s ON / 15 min OFF duty cycle
- After 3 cycles, escalated to TIER 2: 90s ON / 10 min OFF
- After 6 more cycles, escalated to TIER 3: 120s ON / 10 min OFF (maximum duty)
- Ran 97 cycles at TIER 3, maintaining water level while keeping motor temperature at 38.4C (safe)
Meanwhile, the AI analyzer correlated this with rising stream levels on the Mohawk and noted elevated soil moisture from recent rain. It correctly assessed this as a high-risk period where the pump was doing real work (not just a sensor glitch).
I got the alert email and text. The basement was dry. The motor was intact. The system was doing exactly what it was designed to do.
The Bigger Picture: Physical AI for Everyone
This isn't a toy project. It's a proof of concept for a much larger idea: edge AI that understands physical systems.
The same architecture works for:
- HVAC monitoring: Power draw anomalies predict compressor failure days before it happens
- Building management: 40 sensors across a building, one local AI correlating them all
- Fleet maintenance: Sensor data from specialty vehicles predicting when a lift or HVAC unit needs service
- Water infrastructure: Municipal pump stations, well houses, stormwater systems
The pattern is always the same: cheap sensors + edge inference + domain knowledge = predictive intelligence that prevents expensive failures.
I'm building these systems for small businesses that can't afford Siemens or Honeywell but still need their buildings to work. A church. A 3-location HVAC company. A bus parts distributor. The $1M-$5M businesses that the enterprise players ignore.
Need monitoring for your building or equipment?
I build custom AI monitoring systems using off-the-shelf sensors and local inference. No cloud subscriptions. No vendor lock-in.
Let's TalkTechnical Details
The full system is approximately 2,000 lines of Python across three files:
pump.py- CLI for manual pump control and monitoringpump_state.py- 7-state machine with tiered escalationai_analyzer.py- Flask server, SQLite telemetry store, Ollama integration, weather/stream APIs
Hardware cost: $25 (Shelly Plug). Software cost: $0 (all open source). Compute: runs on any Mac, Linux box, or Raspberry Pi with enough RAM for the LLM.
The state machine persists to /var/tmp/ so it survives reboots. The SQLite database retains 30 days of readings. Weather data is cached to avoid hammering free APIs.
If you want to build something similar, the core insight is: start with the sensor data you already have. A smart plug gives you power monitoring. A smart thermostat gives you temperature. A water meter gives you flow. Feed it to a local LLM with domain context and let it find the patterns.
The robots are coming. But before they arrive, there's a massive opportunity in making the buildings and equipment we already have smarter with the AI tools we already have.