Kenapa halaman ini penting

Halaman ini menjelaskan bagaimana Modul Network masuk ke model eksekusi ZeroKernel yang lebih besar, masalah apa yang sebenarnya diselesaikan, dan trade-off apa yang benar-benar Anda bayar saat fitur ini dipakai di firmware produksi. Tujuannya bukan melihat Modul Network sebagai satu API terpisah, tetapi memahami posisinya di dalam bounded scheduling, disiplin queue, visibilitas fault, dan pemilihan profile.

Baca topik ini sebagai kontrak operasional. Mulai dari jalur paling kecil yang benar-benar jalan, pasang dulu di profile lean, lalu baru naik ke routing, diagnostics, atau state transport yang lebih kaya setelah Anda bisa membuktikan hasil timing-nya tetap layak dibanding tambahan flash dan RAM. Pola pikir ini yang menjaga ZeroKernel tetap berguna di board kecil dan tidak berubah jadi abstraksi yang gemuk.

Pola paling aman selalu sama: tentukan batas runtime-nya, jaga hot path tetap pendek, ukur efeknya dengan compare script, lalu baru naikkan kompleksitas. Contoh di bawah bukan pemanis; itu adalah pola minimum yang bisa Anda ambil ke firmware nyata saat Anda butuh integrasi yang rapi, bukan loop manual yang sulit dipertahankan.

Tiga pola yang langsung bisa dipakai

Loop maintenance WiFi

Pisahkan pace reconnect dari cadence sensor agar churn link tidak merusak hot path.

    ZeroWiFiMaintainer wifi;
wifi.setBackoff(250, 2000);
wifi.tick(linkIsUp, attemptReconnect);

HTTP queue step pump

Antrekan pekerjaan dulu, lalu kuras secara cooperative agar satu POST tidak mendominasi loop.

    ZeroHttpPump pump;
pump.enqueue(payload);
pump.tick(connectStep, writeStep, finishStep);

MQTT publish drain

Batasi publish per tick dan baca success rate bersama queue depth, bukan terpisah.

    ZeroMqttPump mqtt;
mqtt.enqueue(topicKey, value);
mqtt.tick(connectBroker, publishStep);

Apa yang perlu Anda cek saat memakainya

Validasi timing lebih dulu, baru bentuk API. API yang terlihat rapi bukan kemenangan kalau fast miss justru naik.
Pilih profile paling kecil yang masih cocok, lalu aktifkan modul opsional hanya saat payoff terukurnya benar-benar jelas.
Jaga callback dan langkah transport tetap bounded supaya watchdog, panic flow, dan batas queue tetap punya arti.

Kesalahan umum yang membuat hasil jadi menyesatkan

Jangan menyalin pola demo ke firmware produksi tanpa mengukurnya di board dan profile build yang benar-benar akan dipakai.
Jangan membaca angka sukses tanpa membaca queue depth, timing, dan label workload di sampingnya.
Jangan menyalakan diagnostics atau kompatibilitas berat di target lean hanya karena default-nya terasa nyaman.

Urutan kerja yang disarankan

Mulai dari jalur paling kecil yang valid

Boot runtime, daftar task minimum yang berguna, lalu buktikan baseline timing bersih sebelum menambah lapisan opsional.

Tambah satu lapisan, lalu ukur

Masukkan routing, diagnostics, atau transport satu lapisan demi satu agar biaya dan payoff-nya tetap jelas.

Publikasikan hanya hasil yang bisa diulang

Update docs, chart, atau klaim publik hanya setelah workload yang sama lolos jalur validasi yang sama lebih dari sekali.

Peta modul

Modul	Status	Peran
`ZeroTransportMetrics`	Cukup stabil di ESP32 / BETA di ESP8266	Mencatat attempt transport, queue depth, dan retry yang terlihat.
`ZeroHttpPump`	Cukup stabil di ESP32 / BETA di ESP8266	Menjalankan fase kirim HTTP secara cooperative, bukan satu langkah blocking besar.
`ZeroMqttPump`	Cukup stabil di ESP32 / BETA di ESP8266	Mengantre dan menguras publish work dengan bounded retry.
`ZeroWiFiMaintainer`	Cukup stabil di ESP32 / BETA di ESP8266	Mengatur pace reconnect dan menyiarkan link state dengan lebih bersih.

Cara mengadopsi

Buktikan dulu firmware stabil di core runtime tanpa modul.
Tambah modul yang benar-benar menyelesaikan bottleneck berikutnya, bukan semua sekaligus.
Jalankan compare script lagi dan lihat apakah biaya resource-nya memang dibayar hasil yang pantas.

Kematangan target saat ini

Saat ini layer transport sudah cukup kuat di ESP32 untuk dianggap layak dipakai secara nyata setelah divalidasi terhadap endpoint Anda sendiri. Di ESP8266, modul yang sama masih tetap BETA karena biaya timing live-nya belum cukup bersih di beberapa run berulang.

BETA di sini bukan berarti main-main. Artinya modul itu berguna, sudah dites, dan sudah diukur, tapi masih aktif dituning untuk board dan jalur transport yang belum sekonsisten ESP32.

FAQ modul network

Apakah semua project harus mengaktifkan semua modul network?

Tidak. Setiap modul memang sengaja dibuat opsional agar firmware hanya membayar perilaku transport yang memang dibutuhkan.

Kenapa success dan fail bisa naik bareng di demo synthetic?

Karena throughput naik dan workload synthetic memang menyuntikkan failure. Baca success bersama attempt dan rate.

Bagaimana cara paling aman memvalidasi halaman ini di board nyata?

Mulai dari profile paling lean yang masih relevan, jalankan compare script yang paling sempit untuk topik ini, lalu baru lanjut ke workload yang lebih berat. Jangan lompat langsung ke build penuh kalau timing dasarnya belum jelas.