There is a camera in my basement. It works. I wrote three hundred and thirty-six lines of code to talk to it — find it on the account, pull its status, download a snapshot, request a video stream. It has an API key and a secret and a region setting. I built the whole thing and it works fine.
This week I went looking for every place my monitoring system actually uses it.
There are none. Not one. In two years of watching a sump pump around the clock, sending alerts at three in the morning, escalating through three tiers of severity and occasionally saving me from a flooded basement, the camera has never made a single decision.
I did not do that on purpose. I am only now able to explain why it was right.
What My System Actually Looks At
Every decision the monitor makes comes from four numbers, read off a smart plug between the pump and the wall:
| What it reads | What that physically is |
|---|---|
| Active power | watts the motor is pulling right now |
| Current | amps |
| Voltage | volts at the outlet |
| Plug temperature | how hot the plug itself is running |
That is the entire sensory world of the thing. Four numbers off an outlet. Every tier escalation, every dry-run detection, every stuck-float recovery attempt, every alert email — all of it comes out of watching electricity move through a motor.
The camera, meanwhile, would have shown me water.
Here is the distinction I could not have articulated a year ago: the water is the consequence. The motor is the cause.
A pump drawing four hundred watts is working. A pump drawing forty watts is spinning against nothing — it has lost prime, or the impeller is gone, or the float is stuck open. That failure is happening right now, and the pit will look completely, reassuringly normal for hours afterward. Water accumulates slowly. By the time a camera has something worth photographing, the interesting part happened a long time ago and the only remaining question is how bad it is going to get.
NASA Has the Same Problem, Four Hundred Million Times Larger
This week I read about a NASA machine learning model called COFFIES that predicts sunspots up to twelve hours before they become visible.
You cannot see inside the sun. The magnetic churn that produces a sunspot happens well below the surface, where no instrument will ever get a look at it. So the model does not try. It reads two things at and above the surface — the magnetic field, and the acoustic waves — and infers the condition underneath from how those waves come through.
The write-up put it in a way I have not been able to stop thinking about: the model hears sunspots forming.
A sunspot, when it finally appears, is the last event in a long causal chain. Everything upstream of it is already encoded in the sound. Waiting for the visible spot means waiting for the outcome. Reading the acoustic field means catching the cause.
My pump is not the sun. But it is the same shape of problem at a scale that fits in a basement, and I got to the same answer by accident, because a smart plug cost less than a camera and I did not think about it very hard at the time.
The Same Week, at the Opposite Extreme
Two other things landed in the same few days, and together they made the pattern hard to ignore.
A developer released an open-source project that detects human beings through walls using nothing but ordinary WiFi. An ESP32 board and a Raspberry Pi, sampling the radio channel a hundred times a second, reading presence out of the way a body disturbs the signal. Not motion — presence. It can detect someone standing perfectly still, by their breathing. The write-up's summary of its one real limitation is the best line I read all week: you can hide from it for as long as you can hold your breath.
Think about what that means next to a conventional motion sensor. A person sitting still in a room is invisible to a motion detector and fully legible to a radio field passing through the same room. Same person, same room, same instant. One sensor has them and the other does not, and it has nothing to do with sensor quality. It is about which physical quantity each one is coupled to.
The other item was an argument from an acoustics company that the simulators robots are trained in are, in their words, essentially silent. Enormous effort has gone into photorealistic virtual worlds; almost none into how those worlds sound. Their explanation for the gap is the part that stuck with me. Sound is governed by wave physics, so it is exquisitely sensitive to the geometry and materials of a specific room. Which means you cannot scrape acoustic data at scale the way you scrape images. A photo of a room stays a photo of that room when you copy it into a dataset. A recording made in a room is a measurement of that room, and it does not transfer anywhere.
That is normally framed as a problem. For a small operator it is the best news in the story, and I will come back to it.
What to Ask a Monitoring Vendor
Here is the practical version, for anyone being sold equipment monitoring for a building.
The demo will be visual, because visual demos are the ones that look impressive in a conference room. Somebody will show you a dashboard with a camera feed and a box drawn around a piece of machinery. It will be genuinely cool. The question it will not answer is the only one that matters:
What physical quantity does this sensor measure, and is the failure I am afraid of upstream or downstream of it?
Work through it for your actual equipment:
- A bearing starting to go shows up in vibration and in motor current draw. It shows up on camera when the machine is already shaking hard enough to see, which is months later and considerably more expensive.
- A pump losing prime shows up in power draw within seconds. It shows up in the pit as slowly rising water, hours later.
- A motor winding degrading shows up in current and in heat. It never shows up visually until there is smoke.
- A flooded floor, a propped-open door, a truck in the wrong bay — these are genuinely visual. A camera is the correct instrument. I am not anti-camera; I am against using one to answer a question its physics cannot reach.
Most of what actually breaks in a small commercial building breaks inside a housing, and announces itself first in electricity, vibration, or heat. Those are the modalities that get there early. A camera is an excellent instrument for confirming a flood that has already happened.
Where This Leaves Me, Honestly
I would rather not end on a victory lap, because I do not think I have earned one. Two things are true at the same time here.
The first is that I picked the right modality, mostly by accident, and I now understand why it was right. That reframes what I have been calling this system. I have been saying "pump monitor" for two years. It is more accurate to call it a motor condition monitor that happens to be attached to a pump, and that matters to a building owner with four pieces of rotating equipment and exactly one sump.
The second thing is less flattering. That WiFi project samples its signal a hundred times a second. My monitor polls every thirty seconds when things are quiet, and every five when something is happening.
Against my idle rate, that is a factor of three thousand. And the difference is not a matter of degree. At a hundred samples a second you can filter down to the frequency band of a human breath and pull a breathing rate out of a radio wave. At one sample every thirty seconds you can tell whether a motor is on or off, and essentially nothing about the shape of the run.
My pump does not need a hundred hertz. The events I care about last a minute or two. But I have been describing what I do as condition monitoring, and condition monitoring at one sample per thirty seconds is state logging wearing a better jacket. The motor's start-up transient — the part of the waveform that genuinely tells you about a stiffening impeller or a bearing on its way out — happens entirely in the gap between two of my samples. In two years I have never once seen it. I have been reading the summary of a signal and calling it the signal.
That is the next thing I build, and I am writing it here so it is on the record.
The Part That Should Encourage You
Back to the acoustics argument: the reason wave-based data cannot be scraped at scale is that it is welded to the geometry and materials of one specific place.
Every large company in this industry is trying to solve monitoring with a model trained on somebody else's buildings. For the modalities that actually catch failures early — the electrical, the vibrational, the acoustic — that data does not travel well, because the measurement is partly a measurement of the building. The sixty-year-old pump in my basement, on my circuit, in my concrete pit, produces a signature that no amount of training on new commercial HVAC will reproduce.
Two years of recordings from one pump in one basement is a small dataset by any standard. It is also the only dataset in the world that describes that pump. Nobody can buy their way to it. They would have to go stand in the basement for two years.
That is the whole business, if I am honest. Not a better model. A longer record of your specific machine, taken with an instrument whose physics actually reaches the thing that breaks.
Monitoring that measures the cause, not the aftermath
Electrical signature monitoring on your rotating equipment, running locally, with ninety days of documented baseline from your own machinery. No cameras pointed at anything, and the baseline is yours to keep whether or not you stay.
See how it works