All Posts

  • Published on
    HTL-07 mendefinisikan arsitektur keamanan HortiLink per-site dengan pendekatan layered security yang mencakup physical protection, network isolation, device authentication, authorization berbasis role, serta integritas firmware dan command. Model identitas bersifat per-site dengan device_id unik untuk Node dan Gateway, serta user identity berbasis RBAC pada Server. MQTT dilindungi dengan ACL dan autentikasi, ESP-NOW menggunakan enkripsi dan replay protection, dan OTA wajib diverifikasi melalui hash dan signature. Keamanan dirancang untuk lingkungan LAN semi-trusted tanpa ketergantungan internet, dengan mekanisme key provisioning, revocation, audit trail, dan proteksi terhadap rogue device serta firmware tampering.
  • Published on
    HTL-08 mendefinisikan seluruh skenario kegagalan dalam sistem HortiLink serta mekanisme deteksi, dampak, containment, dan recovery-nya. Dokumen ini mencakup kegagalan pada layer Node, relay chain, Gateway, Server (Raspberry Pi), jaringan LAN, elektrikal, software, data, dan keamanan. Setiap failure diklasifikasikan dan dipetakan dalam matriks terstruktur untuk memastikan sistem mampu beroperasi dalam mode degradasi aman (safe degradation) tanpa menghentikan kontrol lokal. HTL-08 menjadi referensi utama untuk QA validation, risk assessment, dan troubleshooting lapangan dengan pendekatan containment per-domain dan recovery bertahap otomatis maupun manual.
  • Published on
    HTL-09 mendefinisikan rencana pengujian komprehensif untuk sistem HortiLink per-site sebelum dinyatakan Production Ready. Dokumen ini mencakup unit test (Node, Gateway, Server), integration test end-to-end, electrical validation, failure injection, stress test, soak test, OTA validation, security validation, serta commissioning checklist. Setiap kategori pengujian memiliki kriteria lulus/gagal yang terukur. HTL-09 menjadi acceptance gate formal untuk memastikan seluruh desain HTL-00 hingga HTL-08 tervalidasi secara teknis, operasional, dan keselamatan sebelum deployment produksi.
  • Published on
    Banyak engineer menggunakan ESP32 dengan Arduino core seolah-olah sistem berjalan secara single-thread melalui `setup()` dan `loop()`. Kenyataannya, ESP32 berjalan di atas FreeRTOS dengan beberapa task internal seperti WiFi, TCP/IP stack, dan idle task. Tanpa memahami execution model ini, firmware mudah menjadi blocking, race-prone, dan tidak deterministik. Artikel ini membongkar bagaimana `loop()` sebenarnya adalah task FreeRTOS, bagaimana ISR mem-preempt eksekusi, dan bagaimana aktivitas jaringan memengaruhi kontrol hardware. Tujuannya membentuk mental model eksekusi sistem sebelum masuk ke disiplin arsitektur produksi.
  • Published on
    Concurrency pada ESP32 bukan fitur tambahan, tetapi kondisi default karena Arduino core berjalan di atas FreeRTOS. Banyak engineer memahami task dan interrupt secara terpisah, namun belum memiliki mental model utuh tentang scheduler, preemption, race condition, dan shared state. Artikel ini membangun pemahaman dari dasar - apa itu task, bagaimana scheduler bekerja, bagaimana ISR memengaruhi task aktif, serta bagaimana queue dan mutex berperan dalam menjaga integritas data. Fokusnya bukan pada API detail, tetapi pada model eksekusi yang memengaruhi desain firmware sensor–relay yang deterministik dan stabil.