I Got the Safety-Critical Part Right by Accident

Hackaday published a list this weekend of seven sensors and breakout boards to keep out of anything you intend to ship. Nobody funded it, nobody acquired anybody. It was still the most useful thing I read all week, and one item on it sent me to check my own basement.

Here's the shape of the list. The DHT11 and DHT22 temperature-humidity sensors, on a proprietary one-wire protocol with accuracy nobody will vouch for. The HC-SR04 ultrasonic rangefinder, with no temperature compensation, so it drifts anywhere that isn't a climate-controlled room. The HC-SR501 motion module, too inconsistent and too power-hungry for production. MQ-series gas sensors, which need calibration against a reference gas you don't have. The MPU-6050 IMU, which is in half the tutorials on the internet and is not actively manufactured. Cadmium sulfide photoresistors, which perform poorly and are a RoHS problem in Europe.

Six reliability problems. Every one is a part I have used or seriously considered, because they're the parts the tutorials use, and the tutorials are how you build the first version fast.

Then there's number seven, and number seven is not like the others.

The One That Isn't About Accuracy

Number seven is the ACS712 current sensor breakout board. The objection is not that it reads current badly. The objection is that mains-rated breakout modules routinely ignore creepage distance.

Creepage is the physical spacing on a circuit board between the high-voltage side and the low-voltage side. Not the air gap — the distance a fault would have to travel across the surface of the board. It's a boring number in a standards document, and it's what stands between a mains fault and everything downstream: the microcontroller, the network it's on, and the person holding it.

That one stopped me, because my sump pump monitor is current sensing on a mains circuit. That's the entire mechanism. The pump draws about 500 watts when it runs, and watching how much it pulls and how long it pulls it is how the system knows the float switch is stuck — which is the failure I built the thing to catch. A float that jams in the up position means the motor runs continuously, overheats, and dies, and then the basement floods.

So: cheap mains current sensing, in a basement. The basement is the wettest room in the building. It's the only room with a floor drain, which is not a coincidence, and the only reason there's a pump down there is that water gets in.

I went and checked what's actually in that path.

I Passed. I Did Not Pass on Purpose.

There is no ACS712 in my system. The current sensing is done by a Shelly Plug US Gen4 — a sealed, listed consumer appliance that sits between the wall outlet and the pump and does the metering internally. My software never touches mains. It polls the plug over HTTP every thirty seconds and reads a number.

Item seven does not apply to me. Good.

Except I want to be honest about how that happened, because it wasn't judgment.

I did not choose that plug after reasoning about creepage distance. I had never thought about creepage distance in my life until Sunday. I chose it because I wanted the system to be able to power-cycle the pump. A stuck float switch will sometimes free itself if the pump stops and restarts, and I wanted the monitor to try that automatically at 3 AM instead of waking me up. That requires a relay on the mains side. The part that gives you a relay on the mains side, in a listed enclosure, for thirty dollars, also happens to give you power metering.

I got the safety-critical decision right as a free side effect of a convenience requirement.

That's the actual lesson, and it's less flattering than "I chose well." A decision that would have been invisible to me either way went the right direction because of something unrelated. Which means it could just as easily have gone the other way, and I would have had no mechanism for noticing.

The Parts Where Nothing Forced My Hand

So the real question isn't the mains path. It's: where in my systems did no convenience requirement accidentally save me?

The environmental sensing, mostly. Nothing about temperature and humidity monitoring forces you toward a good part. There's no relay you also need, no enclosure requirement, no listing to satisfy. You need a number, the DHT22 gives you a number for two dollars, and the tutorial is right there. That's exactly the profile of a decision that gets made in ten seconds and lives for five years.

And here's why that matters more than it sounds. The failure mode of a drifting temperature sensor is not an alarm. It's a slow corruption of the baseline you built on top of it. If the sensor starts reading three degrees high over the course of a year, it looks like the building changed. You spend a month adjusting thresholds against a sensor that's quietly lying, and you don't catch it until you happen to put a second sensor next to it.

I know that pattern because I've lived a version of it, and I blamed my own code for three weeks.

That's the trap with prototype-grade parts, and it's why the list is worth taking seriously even though six of the seven items are "merely" reliability. They don't fail loudly. They fail as a slow rot in the thing you built on top of them, in a building you're not standing in, on a timeline long enough that you've forgotten what you installed.

This Is Not a Beginner Problem

The easy read on that Hackaday list is that it's for hobbyists graduating to real work. It isn't. The same gap showed up twice more this week with much better-funded people on the other side of it.

AMD announced the Ryzen AI Embedded X100 family and the Kria AI system-on-module, aimed squarely at robotics and edge AI. The hardware looks genuinely good: six SKUs, up to 50 TOPS of NPU, 55 watts, and up to 128 GB of memory unified across CPU, GPU, and NPU so perception and planning stop copying data back and forth. The Kria module closes a control loop in 1.5 microseconds and ships on an open COM-HPC form factor instead of something proprietary, with open-source baseboard schematics. After the edge compute pricing moves of the last few months, a credible second source is worth a lot to a small shop.

The headline claims are 3.4x better real-time performance than NVIDIA's Jetson Thor T5000, plus 1.6x spare compute and 2.3x more agentic capacity.

Those benchmarks were run by AMD's partners. And the AMD side of the comparison wasn't a Kria board. It was a GMKtec mini PC running a Ryzen AI Max+ 395 desktop chip.

A mini PC stood in for the robotics module, in a robotics benchmark, against a competitor's shipping robotics module. Nobody hid it — it's disclosed if you read down far enough. But it's the same species of gap as the DHT22 on the bench. The number is real under the conditions it was measured in, and those conditions are not the conditions of a deployment. A desktop chip in a mini PC has a fan, an enclosure with room in it, and no real-time hypervisor eating cycles underneath. A 55-watt module bolted into a mechanical room has none of that.

Every edge deployment I've done came in under the spec sheet. Not once was that a vendor lying. It's that a spec sheet describes a bench, and I don't work on a bench.

The Most Honest Product of the Week Priced the Gap In

The third one is my favorite, because somebody actually admitted it.

Weave Robotics is taking orders on Isaac 1, a home robot that folds laundry, makes beds, and puts things away. It rolls on wheels rather than legs, rises to five foot nine when there's work to do, and has two-finger grippers. Seven thousand nine hundred ninety-nine dollars outright, or four hundred forty-nine a month. Two hundred fifty to reserve one, California deliveries this fall.

Near the bottom of every writeup is the sentence that makes the product make sense: the autonomy is partial, and it's backed by teleoperation. When Isaac hits something it can't handle, a remote human takes over and finishes the job.

That's the most credible thing about it. Weave built a robot with a human backstop and then priced the human in. Four hundred forty-nine a month is what a physical AI product costs when you're honest about how many minutes of human it still needs, amortized across a fleet.

Everyone else selling autonomy is in one of two positions. They have a backstop and don't mention it, or they don't have one and will find out what that costs during their first bad winter.

What I'm Actually Doing About It

Three things, cheap enough that there's no excuse for not having done them already.

1. Write down every part number in both deployments

A single file per site: part, what it measures, is it on the list, what the replacement costs. I already know what the mains path holds, because I just looked. I do not know, off the top of my head, what's doing environmental sensing on every node in the 40-device building, and that's the honest answer to the question this list asked me.

Rough guess on the total cost to move everything to production-grade parts: under two hundred dollars. That's the actual point. This is a cheap problem right up until it's an expensive one, and there's no middle.

2. Stop relying on lucky adjacency for anything that faults

The mains path came out fine because a convenience requirement dragged it there. That's not a process, it's a coincidence, and coincidences don't repeat across installs. The rule going forward is simpler than any judgment call: nothing I build touches mains directly. If a circuit needs measuring, it gets measured by a listed appliance with the isolation already inside it, and my code reads a number over the network. That's not the cheapest way. It's the way that doesn't depend on me having thought about creepage distance at the right moment.

3. Publish the bill of materials to the customer

This is the one that changes the business rather than the hardware.

Nobody hiring a monitoring service asks what current sensor is in the box. They can't — it's not reasonable to expect a building owner to know. Which means the bill of materials is a place where cutting corners is completely invisible at the moment of sale and completely visible three years later, to somebody else, possibly to an insurance adjuster.

So make it visible on purpose. Every install gets a published parts list with real part numbers and a written statement that nothing in the mains path is a hobby breakout. The customer's own electrician can check it in five minutes. It costs me one file per building.

I don't expect anyone at my price point to match it, and not because they couldn't write the file. Because a fair number of them are running the parts on that list, and they'd have to change their hardware before they could make the claim.

The Cheap Half and the Careful Half

Sensors keep getting cheaper. Unit costs are under a dollar for a lot of what I use, and open firmware like Thingino will turn a ten-dollar IP camera into a real monitoring node with on-device motion detection and no cloud account attached. That's genuinely good and I use all of it.

But cheap parts are exactly what makes a list like Hackaday's urgent instead of pedantic. When the wrong part and the right part were forty dollars apart, choosing carefully was a budget decision, and you made it consciously. Now they're two dollars apart, so nothing forces you to think about it at all. The decision doesn't feel like a decision. It just happens, in ten seconds, and then it runs for five years in someone's basement.

I got mine right without thinking. That's the part that bothers me, and it's why I'm writing the file.