Satu Platform Smart Lock, Dua Jenis Bangunan yang Sangat Berbeda

Satu Platform Smart Lock, Dua Jenis Bangunan yang Sangat Berbeda

Kos dan hotel sama-sama ingin pintu yang terbuka untuk orang yang tepat, dan tertutup untuk yang lain. Selebihnya, kebutuhannya sangat berbeda.

Saya membangun satu platform akses yang melayani keduanya. Bagian menarik dari desainnya bukan di hardware lock. Justru di keputusan soal penempatan network dalam critical path — jalur yang kalau macet, seluruh proses buka pintu ikut macet — dan untuk bangunan mana keputusan itu layak biayanya.

Dua bangunan, dua batasan

Pemilik kos ingin sesuatu yang murah dipasang dan tidak perlu dirawat: tanpa kabel, tanpa perangkat tambahan per lantai, tanpa bergantung pada koneksi internet bangunan. Hotel ingin kebalikannya: hak akses yang update seketika saat booking berubah, visibilitas jarak jauh ke setiap pintu, dan sistem yang terhubung dengan cara kerja front desk yang sudah ada.

Melayani keduanya dengan satu arsitektur tetap berarti kos jadi kemahalan atau hotel jadi kurang terlayani. Jadi platform ini tidak punya satu arsitektur. Ia punya dua tier di atas satu core yang sama: integration API, mobile app, dan sisi admin, semuanya dipakai bersama oleh kedua tier. Koneksi fisik ke lock yang menentukan perilaku masing-masing tier.

Tier BLE-only: ponsel sebagai network

Untuk kos, lock berkomunikasi lewat Bluetooth murni. Tidak ada gateway, tidak ada hub, tidak ada bridge kabel. Ponsel manager adalah seluruh transport layer-nya — mirip kurir yang membawa kunci fisik dari pintu ke pintu, cuma kuncinya digital. Membuat PIN, mencabut kredensial, menarik log, semuanya terjadi dengan berdiri di depan pintu, aplikasi terbuka, dan membiarkan Bluetooth melakukan handshake langsung dengan lock.

Kedengarannya terbatas sampai Anda sadar apa yang didapat dari situ: lock tidak pernah butuh internet untuk membuat keputusan akses. Kredensial diverifikasi di dalam lock itu sendiri, jadi PIN penyewa tetap jalan saat WiFi mati, router restart, atau ada rentang waktu tanpa konektivitas ke bangunan sama sekali. Pintu memang tidak pernah bergantung pada konektivitas bangunan sejak awal. Backend hanya berperan untuk urusan administratif di sekitar akses, bukan akses itu sendiri: ia melacak siapa memegang kredensial apa, kapan harus kedaluwarsa, dan apa isi log terakhir saat ponsel sinkronisasi.

Trade-off-nya, pencabutan akses tidak instan. Kalau PIN harus hilang saat itu juga, seseorang harus mendatangi pintu secara fisik. Ponsel manager harus ada di sana untuk mendorong perubahan itu.

Bagi manager yang tinggal di lokasi dan mengecek pintu tiap hari, itu bukan keterbatasan nyata. Sama saja dengan perjalanan yang biasa ia lakukan membawa kunci fisik. Bagi pemilik yang mengelola beberapa properti dari jarak jauh, itu jadi celah nyata — sinyal bahwa tier BLE-only sudah tidak cukup.

Saya bahas lebih dalam soal kombinasi kredensial dan siklus hidup penyewa di akses pintu smart untuk kos.

Tier hotel: gateway berarti membeli sistem, bukan sekadar lock

Hotel memakai lock yang terhubung lewat gateway: bridge kecil, biasanya satu per lantai, yang membuat setiap lock bisa dijangkau tanpa ponsel harus berdiri di depan pintu. Kemampuan dihubungi kapan saja itulah yang mengubah lock dari perangkat berdiri sendiri menjadi bagian dari sebuah sistem. Backend tahu level baterai dan state lock secara real-time, dan bisa mendorong perubahan kredensial tanpa ada yang perlu berjalan menyusuri lorong.

Bagian yang benar-benar penting secara komersial bukan gateway-nya. Melainkan apa yang dimungkinkan oleh gateway: hak akses yang digerakkan oleh sistem manajemen hotel, bukan dikelola manual. Penetapan kamar saat check-in langsung memberi akses ke tamu, terikat dengan lama menginapnya. Checkout langsung mencabutnya saat itu juga — tanpa langkah terpisah yang harus diingat front desk, tanpa jeda waktu saat kredensial tamu yang sudah pergi masih aktif.

State housekeeping — bersih, kotor, sudah diperiksa, tidak bisa dipakai — tetap terlihat berdampingan dengan state lock. Kamar tidak ditandai siap dijual saat kondisi pintunya sendiri masih tidak konsisten.

Ini disiplin siklus hidup yang sama dengan yang saya tulis untuk status kamar hotel sebagai state machine. Akses, seperti housekeeping, adalah state yang harus dimodelkan secara eksplisit. Kalau tidak, ia berubah jadi checklist manual seseorang.

Tier mana yang dijual, dan kenapa memaksakan tier lain adalah kesalahan

Pertanyaan penentunya: siapa yang secara fisik ada di bangunan, dan seberapa cepat akses perlu berubah. Manager yang tinggal di lokasi dan bisa menjangkau pintu mana pun dalam beberapa menit tidak butuh gateway. Yang ia butuhkan cuma hardware murah dan aplikasi. Gateway di setiap lantai justru jadi biaya berulang untuk masalah yang tidak ia miliki.

Hotel sama sekali tidak bisa berjalan di tier BLE-only. Check-in dan checkout terjadi terus-menerus. Tamu berharap akses begitu kamar diserahkan, dan tidak ada manager yang bisa menyusuri lorong setiap kali booking berubah.

Gateway bukan upgrade untuk hotel. Itu syarat minimum agar siklus akses bisa mengikuti siklus booking sama sekali.

Menjual tier yang salah cepat kelihatan dampaknya. Kos dengan gateway membayar untuk kendali jarak jauh yang tidak pernah dipakai, karena managernya sudah ada di lokasi. Hotel tanpa gateway berarti seseorang di front desk membuat dan menghapus kredensial secara manual sepanjang hari — justru koordinasi manual yang seharusnya dihilangkan oleh sistem manajemen.

Intinya

Satu platform, dua tier, satu pertanyaan penentu: apakah bangunan itu punya orang di lokasi yang bisa menjangkau pintu mana pun dalam hitungan menit, atau apakah akses perlu berubah seketika saat booking berubah?

Kos menjawabnya dengan ponsel dan lock Bluetooth. Hotel menjawabnya dengan gateway yang terhubung ke siklus booking. Backend, integration API, dan mobile app tetap sama di baliknya. Yang berubah cuma tier koneksinya, dan apa yang ia hubungkan. Untuk arsitektur backend yang merangkai protokol seperti ini, lihat panduan lengkap backend IoT.