Hackaday ran a column this week with a title I've effectively been selling for two years: Add Sensors To Everything! The argument is that measurement isn't only for control. It's for finding out what your system is actually doing, which is usually not what you assumed.
The example is small and perfect. Put a strain gauge in a 3D printer's hot end — Prusa does this — and you can finally measure the pressure of molten plastic instead of guessing at it. Unmelted filament behaves like a springy piston, so pressure lags the commands, and for years people calibrated that lag by trial and error. A sensor removes the guessing.
But here's the part worth stealing. That gauge went in to solve calibration. Once it was there, it turned out to also detect when the nozzle touched the bed, which handles leveling. And it turned out to detect clogs, because a clog shows up as over-pressure before it shows up as a ruined print. Nobody installed that sensor to catch clogs. It caught clogs anyway.
The more you can measure, the more you can discover about the way your system is running.
That's the whole idea, and I believe it. I also think it's about half of a true statement, and the missing half is the entire reason my customers pay me a monthly fee.
What a pump told me that I never asked it
There's a sump pump in a basement in Watertown that I've had instrumented for over a year. One off-the-shelf sensor watching vibration and current, feeding a small model on a small local box in the building. I put it there to answer one question: is this pump running when it should be?
That question got answered in the first week. Everything useful I've learned since was something I didn't ask.
I learned what that pump's cycle rhythm looks like in a dry stretch versus after three days of rain, and how many hours of warning a change in rhythm gives you before there's water on the floor. I learned that the current it draws on startup drifts with something other than load. I learned what the vibration signature does in the weeks before a float switch starts getting unreliable, which is a thing you can see if something is watching and a thing you cannot possibly see if it isn't. None of that was in the spec. It was in the data, waiting for someone to be looking.
Multiply that by the forty-odd devices in the Northampton building and you get the real product: not a failure alert, but a description of how a building actually behaves, written by the building.
Then read the comment section
Hackaday's readers are engineers, and they immediately supplied the counterargument. Sensors everywhere is how you get a car that throws four warning lights for one loose connector. It's how you get a CAN bus that fails in ways that are harder to diagnose than the failures it was added to prevent. More measurement is not automatically more insight. Frequently it's more noise, arriving faster, at a person who has stopped reading it.
They're right, and I've written about this exact failure before. The most common thing I find in a small commercial building isn't an absence of data. It's a system generating alerts that everyone learned to ignore in the first month, because the alerts fire on fixed thresholds that have nothing to do with how that particular machine behaves.
So both things are true at once. Measure more than you plan to act on, because you cannot discover a pattern you never recorded. And accept that the raw stream is worth roughly nothing until something has learned what normal looks like on that specific machine.
The sensor costs $40. The normal takes two weeks.
This is the part people get backwards when they price a monitoring project. They shop sensors. Sensors are the cheapest thing in the system and getting cheaper — a vibration monitoring point that ran about $600 in 2019 is under $50 today, and basic IoT sensor units are under a dollar. Hardware is not the constraint and hasn't been for years.
What takes time is the two weeks of watching after installation, while a model on the local box learns that this pump starts like this, settles like this, draws this much on a 90-degree day and that much in February. After that, the system isn't comparing your machine to a manual. It's comparing your machine to itself, last month. Drift from a machine's own history is a signal. Drift from a factory threshold is a coin flip.
| Sensor with a threshold | Sensor with a learned baseline | |
|---|---|---|
| What it knows | A number from a manual | How this machine actually behaves |
| False alarms | Constant, then ignored | Rare enough to stay credible |
| Catches slow drift | No — only the final threshold breach | Yes — that's the whole point |
| Finds things you weren't looking for | No | Routinely |
| Where the cost is | Hardware | The two weeks of learning |
Why the frontier keeps agreeing with this
Two things happened in robotics this week that rhyme with the same lesson.
The largest check in physical AI this month — $1.7 billion, led by a16z — went to Atoms, a company whose stated thesis is that purpose-built machines beat general-purpose ones in real industrial environments. Not a humanoid that can do anything. A specific machine for a specific job. And when AMD launched its new robotics compute platform to take on NVIDIA, the headline claim wasn't more raw intelligence. It was 3.4x better real-time reliability — a promise that the boring layer won't miss its deadline.
Billions of dollars of frontier robotics money, and the arguments winning are be specific and be reliable. That is a very expensive way of arriving at what the guy with one sensor on a sump pump already knew.
Where to actually start
If you run a building or a shop and this resonates, don't start with an audit of everything. Start with the one machine whose failure would ruin your week — the pump, the compressor, the walk-in, the air handler over the expensive room. One sensor on that. Two weeks of learning. Then judge whether what it tells you was worth knowing.
My experience is that it tells you two categories of thing. The one you paid for, which is a warning before an expensive failure. And the one you didn't, which is a description of how that machine has been living all along. Customers stay subscribed in month nine — the month when nothing breaks — because of the second category.
One machine. One sensor. Two weeks to learn its normal.
Each critical asset gets one off-the-shelf sensor and a small model on a local box in your building. It learns how that specific machine behaves, then watches for the drift that shows up before a failure and puts it in front of a person who knows the equipment. Read-only, never on your control network, nothing leaves the building. $99 to $199 per month against a $125 to $208 market rate, hardware under $3,000, installed this week. Start with the one machine that scares you most.
See how it worksSources: Hackaday, Elliot Williams, “Add Sensors To Everything!” (July 25, 2026), for the measurement-as-discovery framing, the Prusa hot-end strain-gauge example (pressure calibration, bed-level detection, and clog detection via over-pressure), and the comment-thread counterargument on sensor sprawl and warning fatigue. Atoms’ $1.7 billion round led by Andreessen Horowitz, with Ben Horowitz joining the board, and its purpose-built-over-humanoid rationale via TechCrunch, SiliconANGLE, and PYMNTS (July 22–23, 2026). AMD Kria AI robotics platform and Ryzen AI Embedded X100 claims, including 3.4x real-time reliability versus NVIDIA Jetson T5000, via the AMD Newsroom Advancing AI 2026 announcement and The Robot Report (July 23, 2026). Vibration monitoring point cost decline ($600 in 2019 to under $50 in 2026), sub-$1 IoT sensor units, and small commercial HVAC predictive-maintenance pricing of $125 to $208 per month via Oxmaint 2026 benchmarks and prior briefs. Field deployments at The Intersecto Watertown sump-pump site and Northampton 40-device building. Companion brief: /Users/tdeshane/lobster/research/physical-ai-brief-2026-07-26.md.