The maintainer replied — and corrected me, rightly

In part one I misjudged a project. In part two I found and reported two blocking faults.

In this part the maintainer replies — and takes one of my measurements apart. Rightly so.

The credit line came unprompted

The pleasant part first. Overnight a new pre-release appeared along with a long reply to my two reports. In it, unasked:

“the [0.3.0] credit line — that is yours, and it should have been there when it shipped.”

Without anybody having to ask. The small irritation about my contribution not appearing in the release notes had resolved itself before it was ever voiced.

That is a form of collaboration rarely described because it is unspectacular: somebody notices by themselves that an attribution is missing and fixes it.

And then the sentence that landed

My report contained a table. In it, one row as a control — a camera model correctly refused a particular function, set against another that was wrongly allowed it.

The reply:

“that row measured our config, not the camera”

That is right. The error code in my row was real. The word “correctly” was not.

The function works on that model. It was simply on a blocklist in the project’s shipped configuration. So my measurement measured that this list takes effect — not that the camera cannot do it.

Why I did not notice

This is the genuinely instructive part. A confirmed counter-measurement had been sitting for weeks in the very directory I had checked out and searched.

I did not look, because the blocklist looked like a deliberate setting — and what looks deliberate does not get questioned.

A shipped default looks like knowledge. It is only somebody else’s assumption, at the time they wrote it.

Both blocklists now ship empty, and the comment there now says what belongs in them: a device family that technically cannot do it — a property of the transport rather than of the model.

And a limit of the method I should have stated

My test was a handshake against an interface: does it open or does it refuse?

That shows whether the gate opens. It can never show whether the camera behind it is capable, because in that test nothing reaches the camera at all.

For my actual finding it was exactly the right tool. For the row beside it, the wrong one — and I gave both the same weight.

Third error of the same kind in one day

The uncomfortable part is not the single mistake but the pattern. On the same day two others of the same sort had happened to me:

• a number confused with another because both looked plausible
• measured too soon after a restart and taken the result for the normal state
• and now: a default taken for a measurement

The pattern is always the same: see a number, invent the interpretation, and fail to ask the obvious control question.

The control question would have been different each time, but there would always have been one. For the blocklist: is there a measurement anywhere showing the opposite? It was two directories away.

And my second suspicion was disproved too

I had reported that a particular camera family had become worse in a newer version — a regression, then.

The counter-check from there was better than mine:

• The file in question is byte-identical across five versions. Not a single commit touched it.
• The fields I found suspicious are not read by the program at all. It takes exactly one value and opens the stream with it.

So my “regression” was none. I had seen two things side by side — a new version and worse behaviour — and turned that into a cause.

The same pattern as with the cameras themselves, where I put forward seven explanations and all seven fell. And the same as with the network measurements, where the attribution hung on a two-hour time zone offset.

What I took away

1. Distinguish what your tool can measure from what you want to know. A handshake tests a gate, not a camera. That holds for every indirect test.
2. A default is not a measurement. It is somebody’s assumption, at a time you do not know.
3. Actively look for the counter-measurement before you report. Mine was in the same directory. A grep would have done it.
4. Weight your findings differently. I wrote up one well-evidenced finding and a weakly evidenced side note with the same confidence. That makes the good finding attackable.
5. Accept corrections publicly. Anybody who reports a fault has to be able to take having one reported back — otherwise both stop.

So what?

Three parts about a project I took for half dead. At the end there is: an MIT licence, a login that works, a live view in my dashboard, and a project that now sits in the default catalogue of Home Assistant extensions.

My share in that was small and consisted almost entirely of describing precisely. No feature, no architecture — two bug reports with a log excerpt and a source location.

What I learned was more about me than about cameras: I like inferring a state from a snapshot. With the project assessment, with the blocklist, with the supposed regression — three times the same.

That it was caught every time was not down to me. It was down to somebody else looking.