A Service Running Does Not Mean Working

A lot of hardware projects eventually become a pile of services. Camera stream service. Serial bridge service. IMU bridge service. Maybe a web UI. Maybe a logging daemon. When something breaks, the first instinct is to check whether the service is active.

That check matters, but it is not the same as knowing whether the physical system is still behaving like the version that worked. A camera service can be active while frame rate drops. An IMU bridge can be active while the sensor reports no usable motion samples. A serial service can be alive while the device behind it changed ports.

The first Oplut camera test was small. Not just because of my circumstances as a broke student, but to narrow down the data. I tested this by capturing a baseline while the camera stream was running. I stopped the camera service. Ran the check again. Oplut reported a degraded state and wrote evidence saying the camera was running at baseline, but the functioning had degraded. Then I restarted the camera stream, and the check returned to ok.

That is not the whole product. It is the first sanity check. If Oplut cannot catch the obvious physical surface changing, it has no right to claim anything deeper. The useful path is to build up from boring truths until the tool can explain non-obvious drift too.

The goal is not a prettier status page. The goal is physical data visibility that can say: this is the thing that changed, here is the baseline, here is the current state, and here is what you should inspect next.