The Sensor In the Water Is the One That Failed

On Friday, two executives from a tactile sensing company published an argument I have been accidentally testing in my basement since February.

The company is UltraSense Systems, and the piece ran in The Robot Report under the names of their CEO and CTO. Their claim is that if you want a robot hand to feel things, you should not put the sensor on the part that touches. You should put it underneath, and infer the contact.

They do it with ultrasound. Acoustic waves travel through the material stack and bounce off internal boundaries. When something presses on the outside, the geometry changes, and so do the echo timing and the reflection amplitude. From that you can work backward to force, location, shear, slip, even what material is pressing. They quote 500 micrometers of spatial resolution through elastomer and force precision around 1.25 millinewtons, and they note that more than four million units of this have already shipped in cars.

The interesting part is not the ultrasound. It is their reason for going to all that trouble. Surface-mounted sensing skin, they write, has to survive "repeated compression, abrasion, contamination, humidity, temperature variation, cleaning exposure, and material aging." Over millions of contact cycles you get wear, hysteresis, creep, delamination, baseline drift, and a recalibration problem that never ends.

Which is to say: the sensor lives inside the environment it is reporting on, and that environment is hostile, and it is hostile in exactly the way the sensor was installed to detect.

I have a sump pump monitor that has been logging continuously since February 23rd. It has four sensing channels. When I sat down to check UltraSense's argument against my own data, I noticed something I had never noticed in six months of staring at this thing: those four channels happen to be perfectly ordered by how close they sit to the water.

And they are also perfectly ordered by how badly they have performed.

Four Channels, Ranked by Proximity

Here is the whole system, from wettest to driest. Every figure is from sump_pump_monitor.log on the host that writes it, covering 2026-02-23 through this morning — 203 calendar days, 177 of which appear in the log, 153,428 lines.

Read the first row and the last row against each other. The sensor that is physically immersed in the thing it measures has a success rate under one percent. The sensor that has never been within four feet of the water has been unable to make a call twice in six months.

The Float: 868 Attempts, 6 Wins

The float switch is the mechanical part that is supposed to sense the water level and turn the pump on. Mine sticks. That is not news here — it is the reason software has been running this pump for months. What I had never counted is how hard the software has been trying to fix it.

The monitor has an unstick routine: rapidly cycle the plug on and off to jostle the float free, then hold the pump on for a while and see whether the power draw drops to zero. If it drops, the float cleared. If the pump is still pulling watts, it did not.

The log reconciles cleanly, which is rare enough that I want to show the arithmetic:

868  UNSTICK ATTEMPT     sequences started
-149 aborted             plug too hot to continue
 719  verification runs   "holding ON to check if float cleared..."
-713 UNSTICK FAILED      pump still running
   6  UNSTICK SUCCESS

Six. Here they are, all of them, in six months:

2026-03-22 15:50:56
2026-04-30 00:58:30
2026-04-30 04:48:42
2026-04-30 14:04:10
2026-09-02 10:55:49
2026-09-09 18:51:32

Three of the six are on the same day in April. A 0.8% success rate, and half the successes are one afternoon.

I want to be careful about what this does and does not prove. The unstick routine failing does not mean the float is broken every time — it means the pump was still drawing current at the end of the sequence, which can also happen because the water genuinely has not gone down yet. But the direction is not in doubt. A mechanical contact sensor sitting in a pit of water, silt and whatever else ends up down there has degraded to the point where 4,761 rapid power cycles have produced six confirmed recoveries.

The Channel That Has Never Said Anything

The smart plug has an ambient light sensor. I wired an alert to it, on the theory that if the basement went from dark to not-dark, either someone was down there or water was reflecting light back at the plug.

In six months it has produced 690 readings. They are all either dark or unknown. There have been exactly zero transitions between states, which means the alert path in sump_pump_monitor.py has never executed. Not once. It has been sitting on a production monitor for six months as code that has never run.

That is its own small lesson, and it is not really about proximity. Untested code on a live system is worse than no code, because you are carrying the risk without getting the signal. If a channel has produced no information in six months, you either give it a real job or you delete it. I am going to delete it.

The Apparatus Measuring Itself

The third row is the one I find most uncomfortable, because it is the layer everybody forgets to count.

The smart plug reports its own internal temperature and its own WiFi signal. Both of these are sensors measuring the measuring device. And the measuring device is, by a wide margin, the least reliable component in the system:

• 230 spontaneous reboots in 203 days. That is one roughly every 21 hours. 201 of them were CPU panics, 14 were interrupt watchdog resets, 4 were watchdog timeouts.
• 4,884 failed RPC calls to the plug, of which 4,614 were connection failures and 219 were authentication failures.
• 4,684 cycles that logged "Could not reach Shelly, retrying next cycle."

And then the temperature channel, which deserves its own paragraph. It has fired 6,074 warnings in six months. The warning line is 50.0 °C. The actual action threshold, where the monitor cuts the pump for cooling, is 60.0 °C. The hard electronics limit is 70.0.

The hottest reading in the entire log is 59.4 °C.

So this channel has never reached its action threshold, and has generated six thousand warnings about approaching it. Six thousand messages, zero decisions. That is a warning line placed where the data happens to live rather than where the decision is, and the result is that I have spent six months training myself to ignore the one thermal signal the system has. It is also the channel that aborted 149 of those 868 unstick attempts — the plug got warm enough, by its own overly cautious standard, to cancel 17% of the repairs it was trying to make.

The Channel That Has Been Wrong Twice

And then there is the wattage. The furthest thing from the water. It does not know the pump exists. It knows that a certain amount of electrical power is crossing a plane in the wall.

The monitor's entire decision rule is one line: is the draw above 100 watts.

Across 22,660 heartbeat readings spanning six months, here is how many landed anywhere in the gray zone between 20 W and 400 W:

2026-03-13 07:30:29   TIER_3    394.8 W
2026-03-17 03:53:43   NORMAL     38.4 W

Two. Everything else was either essentially zero or north of 400 watts. The distribution is not just bimodal, it is almost a step function with nothing in the middle.

It gets better. Of the 15,238 log lines where the monitor recorded a confirmed pump run with a parsable wattage, the minimum was 444.8 W and the maximum was 705.7 W. The threshold is 100. The closest call in six months of continuous operation cleared the decision boundary by a factor of 4.4.

Why the Far Sensor Wins

The pattern is the same one UltraSense is selling against robot skin, and I think it generalizes past both of us.

Current, voltage, vibration, acoustic energy and heat all leave a machine whether you are touching it or not. They are conserved quantities that propagate outward. You can stand well back, in a clean dry place, and read them.

A contact sensor does not get that option. It has to be in the pit, in the flow, on the surface, inside the thing. And here is the trap: the reason you put a sensor somewhere is that the conditions there matter, which is precisely why the conditions there will eventually eat your sensor. The float sits in water because water is what matters. Water, silt and six months are also what kills floats. Robot skin sits at the contact point because contact is what matters. Contact is also abrasion, compression and contamination.

So the design rule I am taking out of this week is: prefer the channel that is furthest from the process and closest to a conserved physical quantity. When you have a choice between measuring the thing directly and inferring it from an energy flow that escapes the thing, the inference usually ages better. Not because it is more accurate on day one — on day one the float is more accurate, it is literally reading the water — but because on day four hundred it is still reading the same way it did on day one.

The Part UltraSense Leaves Out

I would not want anyone to take this too far, including me, so here is the honest limit.

My wattage channel is sharp, durable and nearly never ambiguous. It is also blind. It tells me the motor is energized. It does not tell me water is leaving the pit. A pump can draw a beautiful, unambiguous, 490-watt signature while moving nothing at all, and the power channel will report that as a healthy run every single time.

That is not hypothetical. It is the failure mode I wrote up a couple of weeks ago, when the assessor spent 22 days locked into a HIGH_INFLOW classification that nothing in the system could contradict, because nothing in the system can see water. The float, for all its faults, was the only component that ever actually touched the physical quantity I care about. I replaced it with a proxy, and the proxy is far more reliable at measuring what it measures, and what it measures is not quite the thing.

UltraSense's piece does not say this, and I think it should. Sub-surface sensing buys you durability. It does not buy you omniscience. The honest version of the rule is:

Three Questions For Your Own System

If you run any kind of condition monitoring, this is a twenty-minute audit and I would recommend it:

1. List your channels and sort them by physical distance from the process. Then pull the failure counts for each. If the ordering matches mine, you now know which channel is going to need replacing and roughly when.
2. Count how many sensors are measuring your monitoring hardware rather than your equipment. In my system that is two of four, and they account for 230 reboots and nearly five thousand failed calls. That layer is real, it fails constantly, and almost nobody budgets for it.
3. For every warning threshold, ask what you did the last time it fired. If the answer is "nothing, 6,074 times," the threshold is in the wrong place. Move it to where you would actually behave differently, or remove it.

As I write this the pump is in TIER_3, the plug is at 44.6 °C, the service has been up 1,307 hours without a restart, and the last cycle ran at 496.9 watts — a number I trust completely, about a question I am no longer sure I am asking correctly.

The basement is dry. It has been dry the whole time. The float, meanwhile, is still down there, still stuck, still being jostled 4,761 times by a piece of software that has managed to free it six times and has never once given up.