A Robot Found a Sensor It Had Never Seen. Mine Ignored One for Two Years.

A robotics lab at UT Austin published something this week with a title I have not been able to put down: Deployment Is Not Destiny.

The setup is a robot going into a place nobody can fully plan for — in their case, an operational nuclear reactor. Partway through the job, somebody hands the robot a sensor it has never encountered. A module on a rail mount, plugged in over USB. No firmware update. No engineer with a laptop. No trip back to the shop.

The robot finds it, works out what it can now do that it could not do a minute ago, and rewrites its own task plan around it. Their number for how long that takes is minutes. Their claim, in their words, is that the robot requires no prior knowledge of the payload at all.

I read that on a Monday morning and then went and looked at my own system, which has been running in a basement for two years, and found something that has been sitting in plain sight the entire time.

My System Has a Discovery Layer. It Can Find Exactly One Thing.

I was actually a little proud of this part. My sump pump monitor does not have its sensor's address hardcoded, because home networks reassign addresses and I got tired of the thing breaking every time the router rebooted. So it has a discovery routine, and every piece of the system uses it — the monitor, the guardian process, the daily status report.

Here is what it does, in the order it does it:

1. explicit candidate IPs from caller / environment
2. cached last-known address
3. sweep the whole 192.168.68.0/24 by expected MAC

That third line is a threaded scan across two hundred fifty-four addresses. And sitting right underneath it, in the source file, are two constants: the subnet, and a twelve-character hardware ID of the one device it is looking for.

So: my system sweeps an entire network. It touches every device on it. And it is looking for a single machine whose identity is compiled into the program. Anything else it encounters — and it encounters everything — gets read, checked against that ID, and thrown away.

And that reframes something I wrote about last week, which was slightly embarrassing on its own and is worse in this light.

The Camera That Has Been Sitting There the Whole Time

There is a camera in my basement. It works. I wrote three hundred and thirty-six lines of code to talk to it. It has credentials, it is on the account, it can pull a snapshot on demand.

My monitoring system has never once used it. Not a single call, in two years.

When I wrote about that, I framed it as a lucky accident of sensor choice — the camera watches water, the smart plug watches the motor, and the motor is where the failure actually lives. I still think that is right, and I would make the same choice again.

But that explanation was incomplete, and today I know why. It is not only that I chose not to use the camera. It is that there is no path in this system by which a capability I did not design in could ever get used. The discovery scan walks past that camera's address every time it runs. Reads it. Checks the ID. Discards it. Every recovery, for two years.

Adding it is not a setting. It is me, opening a Python file, writing code, and redeploying. UT Austin's number for the same operation is minutes, in the field, by someone who is not the person who built it.

The Part Where I Argue Against Myself

Now, the honest correction, because there is a version of this post that is much more dramatic than the truth supports.

My pump has been the same pump in the same pit for two years. It is not going into a reactor. Nobody is going to hand it a thermal camera mid-mission. Runtime recomposition, for one sump pump, is wildly over-engineered, and if I built it this week I would be building a research demo instead of a business.

Here is why I am writing about it anyway.

I am not selling one sump pump. The other system I run covers forty devices in a building, and the pitch I make to a building owner is explicitly incremental: start with the pump you already worry about, add the boiler next quarter, add the rooftop unit after that. That is an honest pitch. It is how a small building can actually afford this.

And every single one of those "adds" is currently me, editing code, on my laptop.

That is completely fine at one customer. At ten customers it is not a workflow, it is the business, and it is a business that does not scale past however many afternoons I have. The thing that university lab built is not an academic curiosity to me. It is a picture of the wall standing between me and a second customer.

One Rule I Am Keeping, and Why

There is a real conflict here with something I have argued before, and I want to resolve it rather than quietly hope nobody notices.

I have written that a building monitor should never close the control loop — watch the asset, raise a hand, and let the equipment's existing controls do the controlling. The moment your software drives the machine, you own the machine.

The UT Austin framework composes actuators as well as sensors. A robot that discovers a new arm and immediately starts planning with it is the precise thing I said not to build.

Both of those can be true, and the rule that comes out of it is short enough to remember:

Compose sensors. Never compose actuators.

A newly discovered read-only sensor can only make the system better informed. The worst case is a measurement nobody uses. A newly discovered actuator changes what the software can do to a building it does not understand yet. In a nuclear emergency, that risk is obviously worth taking. In a church basement with a twenty-year-old boiler and no redundancy, it is not, and it is not going to become worth taking later.

This is also a different problem from one I have written about before, and the distinction matters. I have made the case that the hard part of physical AI is pushing software updates out to machines in the field — that is the vendor's delivery problem. This is the inverse: the machine's problem of absorbing hardware that shows up next to it. A flawless update pipeline still does not let a monitor notice a sensor a facilities tech plugged in this morning.

The Question to Ask Your Monitoring Vendor

Here is the practical version, and it costs you nothing to ask.

Whoever is selling you building monitoring will show you a dashboard. It will look good, because dashboards are the part everyone polishes. What you want to know is not on it:

Then listen for which of three answers you get:

• "It's a setting." Best case, and rare. Ask them to show you, live, on the actual product.
• "We'd send someone out." Fine and honest — now ask what it costs and how far out they book. This is the answer most of the industry gives, and it is where your budget quietly goes.
• "We'd add support for that." This means a code change, and it means your expansion is scheduled against somebody's engineering backlog, not against your building's needs.

None of those three is disqualifying. The point is that a monitoring system is not a thing you buy once. It is a thing you extend for as long as you own the building, and the cost of the second sensor tells you far more about the vendor than the price of the first one does.

For what it is worth, my honest answer to my own question today is the third one. That is why I am writing it down.

What I Am Actually Doing About It This Week

Not building a component manager. I want to be specific about that, because the failure mode here is obvious — read an inspiring paper, spend three weeks building a framework nobody asked for, ship nothing a customer can see.

The scoped version is one hour of work. My monitor already reads several of its settings from the environment rather than from source — the power threshold that decides whether the pump is running, the polling intervals. The discovery layer does not. So: move those two constants into the same pattern, add a second device, and answer one question.

Can I point my system at a second sensor without editing a Python file?

If yes, I have earned the first honest sentence I can say to a second customer about extensibility. If it takes longer than an hour, I stop and write down why it took longer — because that answer is worth as much as the change would have been. That is the whole scope.

And it still sits behind a customer-facing report feature I promised in public three days ago and have not shipped. If there is one free afternoon this week, it does not go to this.

Deployment is not destiny. But right now, in my basement, it mostly is — and the useful thing about reading a paper like that is not the framework. It is finding out that the constraint you had stopped noticing was a choice somebody else already refused to accept.