Der Betreuer hat geantwortet — und mich zu Recht berichtigt

In Teil 1 habe ich ein Projekt falsch eingeschätzt. In Teil 2 habe ich zwei blockierende Fehler gefunden und gemeldet.

In diesem Teil antwortet der Betreuer — und nimmt eine meiner Messungen auseinander. Zu Recht.

Die Kreditzeile kam von selbst

Zuerst das Angenehme. Über Nacht kam eine neue Vorabversion und eine lange Antwort auf meine zwei Berichte. Darin, ungefragt:

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

Ohne dass jemand darum bitten musste. Die kleine Verstimmung darüber, dass mein Beitrag in der Versionsnotiz nicht auftauchte, hatte sich damit erledigt, bevor sie je ausgesprochen wurde.

Das ist eine Form von Zusammenarbeit, die man selten beschreibt, weil sie unspektakulär ist: Jemand bemerkt von selbst, dass eine Zuschreibung fehlt, und korrigiert sie.

Und dann der Satz, der saß

In meinem Bericht stand eine Tabelle. Darin eine Zeile als Gegenprobe — ein Kameramodell, das eine bestimmte Funktion korrekt abgewiesen bekommt, gestellt gegen ein anderes, das sie fälschlich erlaubt bekommt.

Die Antwort:

„that row measured our config, not the camera“

Das stimmt. Der Fehlercode in meiner Zeile war echt. Das Wort „korrekt“ war es nicht.

Die Funktion funktioniert auf diesem Modell. Nur hatte die mitgelieferte Konfiguration des Projekts es auf einer Sperrliste. Meine Messung hat also gemessen, dass diese Liste wirkt — nicht, dass die Kamera es nicht kann.

Warum ich das nicht gemerkt habe

Das ist der eigentlich lehrreiche Teil. Eine bestätigte Gegenmessung lag seit Wochen im selben Verzeichnis, das ich ausgecheckt und durchsucht hatte.

Ich habe nicht nachgesehen, weil die Sperrliste wie eine absichtliche Vorgabe aussah — und was absichtlich aussieht, hinterfragt man nicht.

Eine mitgelieferte Voreinstellung sieht aus wie Wissen. Sie ist aber nur die Annahme von jemand anderem, zu dem Zeitpunkt, als sie geschrieben wurde.

Beide Sperrlisten liefern inzwischen leer aus, und der Kommentar an der Stelle sagt jetzt, was dort hineingehört: eine Gerätefamilie, die es technisch nicht kann — eine Eigenschaft der Übertragung, nicht des Modells.

Und eine Grenze der Methode, die ich hätte nennen müssen

Mein Prüfverfahren war ein Handschlag gegen eine Schnittstelle: Geht sie auf oder weist sie ab?

Das zeigt, ob die Weiche aufgeht. Es kann nie zeigen, ob die Kamera dahinter etwas kann, weil bei dieser Prüfung gar nichts bei der Kamera ankommt.

Für meinen eigentlichen Fund war das genau das richtige Werkzeug. Für die Zeile daneben war es das falsche — und ich habe beide gleich gewichtet.

Dritter Fehler derselben Art an einem Tag

Das Unangenehme daran ist nicht der einzelne Fehler, sondern das Muster. An demselben Tag waren mir zwei weitere derselben Sorte unterlaufen:

• eine Zahl mit einer anderen verwechselt, weil beide plausibel aussahen
• zu früh nach einem Neustart gemessen und das Ergebnis für den Normalzustand gehalten
• und jetzt: eine Voreinstellung für eine Messung gehalten

Das Muster ist immer dasselbe: eine Zahl gesehen, die Deutung dazuerfunden, und die naheliegende Gegenfrage nicht gestellt.

Die Gegenfrage wäre jedes Mal eine andere gewesen, aber es hätte immer eine gegeben. Bei der Sperrliste: Steht irgendwo eine Messung, die das Gegenteil zeigt? Sie lag zwei Verzeichnisse weiter.

Und auch mein zweiter Verdacht wurde widerlegt

Ich hatte gemeldet, eine bestimmte Kamerabaureihe sei in einer neueren Fassung schlechter geworden — ein Rückschritt also.

Die Gegenprobe von dort war besser als meine:

• Die betreffende Datei ist über fünf Versionen hinweg byteweise identisch. Kein einziger Commit hat sie angefasst.
• Die Felder, die ich auffällig fand, liest das Programm überhaupt nicht. Es nimmt genau einen Wert und öffnet damit den Strom.

Mein „Rückschritt“ war also keiner. Ich hatte zwei Dinge nebeneinander gesehen — eine neue Version und ein schlechteres Verhalten — und daraus eine Ursache gemacht.

Dasselbe Muster wie bei den Kameras selbst, wo ich sieben Erklärungen aufgestellt habe und alle sieben gefallen sind. Und dasselbe wie bei der Netzmessung, wo die Zuordnung an zwei Stunden Zeitzone hing.

Was ich daraus mitgenommen habe

1. Unterscheide, was dein Werkzeug messen kann, von dem, was du wissen willst. Ein Handschlag prüft eine Weiche, keine Kamera. Das gilt für jeden indirekten Test.
2. Eine Voreinstellung ist keine Messung. Sie ist die Annahme von jemandem, zu einem Zeitpunkt, den du nicht kennst.
3. Such aktiv nach der Gegenmessung, bevor du berichtest. Meine lag im selben Verzeichnis. Ein grep hätte gereicht.
4. Gewichte deine Befunde unterschiedlich. Ich habe einen gut belegten Fund und eine schwach belegte Nebenzeile mit derselben Sicherheit aufgeschrieben. Das macht den guten Fund angreifbar.
5. Nimm Berichtigungen öffentlich an. Wer einen Fehler meldet, muss aushalten, selbst einen gemeldet zu bekommen — sonst hört beides auf.

Und was heißt das?

Drei Teile über ein Projekt, das ich für halb tot gehalten habe. Am Ende stehen: eine MIT-Lizenz, eine Anmeldung, die funktioniert, ein Livebild in meinem Dashboard, und ein Projekt, das inzwischen im Standardverzeichnis der Home-Assistant-Erweiterungen steht.

Mein Anteil daran war klein und bestand fast ausschließlich aus genauem Beschreiben. Kein Feature, keine Architektur — zwei Fehlerberichte mit Protokollauszug und Quelltextstelle.

Was ich dabei gelernt habe, war mehr über mich als über Kameras: Ich schließe gern aus einer Momentaufnahme auf einen Zustand. Bei der Projektbewertung, bei der Sperrliste, beim vermeintlichen Rückschritt — dreimal dasselbe.

Dass das jedes Mal aufgefallen ist, lag nicht an mir. Es lag daran, dass jemand anderes hingesehen hat.