Loading
Category:
IoT Projects
Date:
February 2026

Industrial IoT Gateway

Kategori: IoT & Embedded Systems

Tags: Python · Flask · SQLite · MQTT · Industry Project · Reliability


Masalah: Koneksi Internet di Industri Tidak Bisa Dipercaya

Di lingkungan industri — pabrik, gedung, fasilitas produksi — ada satu kenyataan yang sering diabaikan: koneksi internet tidak pernah benar-benar stabil. Router bisa restart, ISP bisa down, kabel bisa terputus oleh aktivitas di lapangan.

Tapi data dari sensor tidak boleh hilang. Satu data pembacaan daya listrik yang hilang bisa berarti anomali konsumsi energi yang tidak terdeteksi. Satu data suhu yang tidak tercatat bisa berarti kegagalan cooling system yang luput dari pantauan.

Ketika saya bergabung di PT. Javadwipa Duta Mandiri sebagai IoT Developer, inilah tantangan utama yang harus saya selesaikan: bagaimana membangun sistem gateway yang tetap bisa mengumpulkan, menyimpan, dan meneruskan data sensor — bahkan saat koneksi ke cloud terputus?

Constraint utama: Gateway harus berjalan di edge device dengan resource terbatas, mendukung berbagai jenis sensor tanpa konfigurasi manual yang rumit, dan data tidak boleh hilang dalam kondisi apapun.


Pendekatan: Modular, Resilient, Plug & Play

Saya memulai dengan satu prinsip desain: “Data harus aman dulu, baru dikirim.” Artinya, gateway ini harus memprioritaskan penyimpanan lokal sebelum memikirkan konektivitas cloud.

Dual-Protocol Data Ingestion

Di lapangan, tidak semua perangkat IoT menggunakan protokol yang sama. Beberapa sensor mengirim data via HTTP POST (lebih sederhana), sementara perangkat lain menggunakan MQTT (lebih efisien untuk real-time). Gateway ini harus bisa menerima keduanya secara bersamaan.

Saya merancang sistem ingestion yang menerima data dari kedua protokol, lalu menormalisasi formatnya ke dalam satu skema unified sebelum disimpan ke database lokal.

Panduan integrasi bawaan yang memudahkan koneksi perangkat via HTTP atau MQTT

Auto-Discovery: Plug & Play untuk IoT

Masalah umum di implementasi IoT industri: setiap kali ada sensor baru, engineer harus masuk ke konfigurasi, mendaftarkan device ID, tipe sensor, dan parameter-parameternya. Proses ini memakan waktu dan rawan human error.

Solusi saya: auto-discovery engine. Ketika sebuah sensor baru mengirim data pertamanya ke gateway — baik via HTTP atau MQTT — sistem secara otomatis mendeteksi device ID dan tipe sensor, lalu mendaftarkannya ke database. Tidak perlu konfigurasi manual. Plug, send data, done.

15+ perangkat terdeteksi otomatis — dari sensor daya, suhu, air, hingga switch — tanpa konfigurasi manual

Offline Buffering: Data Tidak Boleh Hilang

Ini adalah inti dari sistem. Ketika koneksi ke cloud terputus, data tidak hilang — melainkan di-buffer ke database lokal SQLite. Sistem menjalankan background scheduler yang secara periodik mengecek konektivitas. Begitu koneksi pulih, data yang ter-buffer langsung di-sync ke cloud secara otomatis.

Saya mengimplementasikan dua mode backup yang bisa dikonfigurasi:

  • By Time Interval — sync setiap N detik (cocok untuk monitoring yang butuh near-realtime)
  • By Count Threshold — sync setelah N record terkumpul (cocok untuk menghemat bandwidth)

Data logs dengan filtering berdasarkan tipe sensor — setiap record tersimpan aman di lokal sebelum di-sync ke cloud


🔧 Tech Decision Log: Mengapa Flask & SQLite?

Mengapa Flask, bukan Express.js atau FastAPI?

Tiga alasan utama:

  1. Blueprint architecture — Flask Blueprints memungkinkan saya memecah aplikasi menjadi modul independen (ingestion, API, auth, backup). Setiap modul bisa dikembangkan dan di-test secara terpisah. Dalam konteks IoT gateway yang harus extendable, ini krusial.
  2. Ekosistem Python untuk IoT — banyak library sensor, MQTT client (paho-mqtt), dan tools data processing yang mature di Python. Menggunakan Flask berarti saya bisa memanfaatkan ekosistem ini tanpa bridge antar bahasa.
  3. Ringan & predictable — dibandingkan Django yang terlalu besar untuk gateway, dan FastAPI yang async-first (overkill untuk gateway sederhana), Flask memberikan balance yang tepat antara fleksibilitas dan kesederhanaan.

Mengapa SQLite, bukan PostgreSQL atau file JSON?

Untuk offline buffering di edge device, pilihannya terbatas:

  • File JSON/CSV — terlalu fragile. Saat proses write terganggu (e.g. power loss), file bisa corrupt. Tidak ada mekanisme transaction.
  • PostgreSQL/MySQL — overkill. Butuh instalasi server database terpisah, konsumsi resource tinggi, dan maintenance tambahan di edge device.
  • SQLite ✅ — serverless, single-file database, mendukung transaction ACID, dan bisa menangani concurrent reads tanpa masalah. Perfect untuk skenario buffering di mana data harus aman bahkan saat power tiba-tiba mati.

Dengan SQLAlchemy ORM di atas SQLite, saya mendapatkan keuntungan tambahan: jika suatu saat perlu migrasi ke PostgreSQL (misalnya untuk deployment yang lebih besar), cukup ganti connection string — tanpa ubah satu baris kode query pun.


Arsitektur Sistem

Berikut adalah arsitektur end-to-end dari IoT Gateway V4:

Arsitektur IoT Gateway: sensor di lapangan → ingestion via HTTP/MQTT → SQLite buffer → auto-sync ke cloud → monitoring lokal & remote

Modul-Modul Utama

ModulFungsiTeknologi
Data IngestionMenerima data dari sensor via HTTP POST & MQTT subscribeFlask Routes, paho-mqtt
Auto-DiscoveryDeteksi & registrasi perangkat baru secara otomatisCustom middleware
Local StorageBuffering data lokal dengan transaction safetySQLite + SQLAlchemy ORM
Cloud SyncSinkronisasi data ke server cloud saat onlinerequests, APScheduler
Payload MappingKonfigurasi format JSON output per endpoint cloudDynamic JSON builder
Auth & SecurityAutentikasi API & dashboardJWT (Flask-JWT-Extended)
DashboardMonitoring lokal real-timeJinja2 + vanilla JS + WebSocket

Fitur Endpoint Configuration yang Fleksibel

Salah satu fitur yang paling saya banggakan: konfigurasi endpoint cloud yang sepenuhnya dinamis. Setiap cloud server memiliki format JSON yang berbeda. Alih-alih hardcode mapping di kode, saya membangun UI konfigurasi yang memungkinkan operator memetakan field internal gateway ke format JSON apapun yang dibutuhkan server tujuan.

Konfigurasi endpoint dengan JSON payload mapping dan live output preview — operator bisa menyesuaikan format tanpa coding

Panduan Mapping & Filter

Panduan mapping dengan filter target device dan source value options

Backup Strategy yang Configurable

Backup strategy bisa dikonfigurasi per kebutuhan: trigger by time interval atau by data count threshold


Hasil & Dampak

Dashboard utama menampilkan system health, connected devices, dan live data stream dari 15+ sensor

Yang Tercapai:

  • ✅ Zero data loss — tidak ada data sensor yang hilang, bahkan saat koneksi terputus selama berjam-jam.
  • ✅ 15+ tipe sensor terhubung secara plug & play — water, fire, weather, power, smoke, gas, lux, switch, hum & temp.
  • ✅ Dual-protocol support — HTTP dan MQTT berjalan bersamaan tanpa konflik.
  • ✅ Auto-discovery menghilangkan kebutuhan konfigurasi manual perangkat baru.
  • ✅ Modular codebase — penambahan fitur baru tidak mengganggu modul yang sudah berjalan.
  • ✅ Configurable backup — operator bisa menyesuaikan strategi sync tanpa menyentuh kode.
  • ✅ Deployable di edge device — Gateway berjalan efisien dengan konsumsi resource rendah (CPU < 10%, Storage < 5%).

Key Learning

1. “Design for Offline First, Online Second”

Dalam sistem IoT industri, koneksi internet adalah luxury, bukan guarantee. Merancang sistem dengan asumsi bahwa koneksi akan selalu ada adalah kesalahan fatal. Sebaliknya, merancang untuk offline-first membuat sistem jauh lebih robust — dan ketika koneksi tersedia, itu hanya bonus.

2. Auto-Discovery Mengubah Pengalaman Deployment

Fitur sederhana seperti auto-discovery ternyata memiliki dampak besar pada deployment experience. Waktu setup perangkat baru berkurang drastis — dari yang sebelumnya harus konfigurasi manual per sensor, menjadi cukup colok dan kirim data.

3. SQLite Lebih Powerful dari yang Orang Kira

Banyak developer meremehkan SQLite sebagai “database mainan”. Kenyataannya, untuk use case buffering dan local storage di edge device, SQLite adalah pilihan yang sangat tepat — ringan, reliable, support ACID transaction, dan zero-maintenance.


Tech Stack

LayerTechnology
Backend FrameworkPython Flask (Blueprints + Application Factory)
ORMSQLAlchemy
DatabaseSQLite (local buffer) + Cloud DB (remote)
IoT ProtocolsMQTT (paho-mqtt), HTTP REST
AuthenticationJWT (Flask-JWT-Extended)
Task SchedulerAPScheduler (background sync)
Frontend DashboardJinja2 + Vanilla JS + DataTables
DeploymentLinux (edge device / VPS)