Mengaktifkan Status entity.person di Home Assistant

Sudah lama entity person orang-orang yang ada di rumah tampilkan dalam home automation saya. Ya iseng aja, biar tampilan dashboard terlihat cantik.

Yang membuat tidak cantik adalah statusnya yang unknown. Akhirnya saya iseng cari tahu bagaimana cara mengaktifkannya.  Dengan cara ini kamu akan tahu dimana anggota keluarga berada, dan termasuk tapi kemana aja 🙂

Caranya adalah:

  1. Install Home Assistant Companion di handphone kita
  2. Hubungkan dengan Home Assistant kita (kebetulan yang punya saya bisa diakses publik melalui cloudflare tunnel)
  3. Kemudian masuk ke Setting >> Companion App >> Manage Sensor
  4. Banyak sekali sensor yang ada disitu. Cari Location Sensor >> Location Zone Enable.

Agar tidak boros bateray ada Sensor update frequency ambil yang normal aja yaitu update setiap 15 menit.

Ok, Happy home assistant ….

TLDRAW Whiteboard, Apa Bedanya dengan Excalidraw?

Saat pertama kali membuka tldraw, rasanya hampir otomatis kita berkata dalam hati: “Ini mirip Excalidraw.”

Dan memang tidak keliru. Cara menggunakannya pun nyaris sama. Kita bisa langsung menggambar kotak, panah, menulis teks, dan mencoret-coret ide di kanvas yang luas. Untuk kebutuhan menuangkan pikiran secara visual, tldraw bekerja sebagaimana Excalidraw bekerja. Tidak perlu penyesuaian yang aneh-aneh. Duduk, buka, gambar.

Namun, semakin lama digunakan, perbedaan keduanya mulai terasa. Bukan perbedaan yang mencolok di permukaan, tetapi perbedaan niat di balik pembuatannya.

Excalidraw terasa seperti papan tulis digital yang sengaja dibuat “tidak terlalu rapi”. Garis-garisnya sedikit goyah, font-nya menyerupai tulisan tangan, dan keseluruhan tampilannya memberi kesan bahwa ini adalah ruang berpikir, bukan ruang pamer hasil akhir. Ada rasa manusia di sana. Diagram yang dibuat terasa seperti catatan di buku, bukan desain presentasi. Dan justru karena itulah Excalidraw terasa nyaman dipakai untuk berpikir.

Font di Excalidraw, meskipun sederhana, terasa lebih hangat dan enak dipandang saat digunakan untuk diskusi atau menjelaskan sesuatu ke orang lain. Ditambah lagi, Excalidraw sudah menyediakan library elemen. Ini hal kecil, tapi sangat membantu. Kita bisa menggunakan kembali simbol-simbol yang sama tanpa harus menggambar ulang. Alur berpikir tidak terputus hanya karena urusan teknis.

Di sisi lain, tldraw terasa lebih bersih dan lebih modern. Font-nya rapi, tampilannya netral, dan kesannya lebih “produk digital”. Bukan berarti dingin, tapi jelas berbeda rasa. Saat ini, tldraw juga belum memiliki konsep library seperti Excalidraw. Menggambar di tldraw lebih bebas, tetapi juga lebih mentah. Kita benar-benar mulai dari kanvas kosong, tanpa banyak elemen siap pakai.

Perbedaan ini menjadi semakin jelas ketika kita melihat tujuan jangka panjangnya. Excalidraw terasa dibuat terutama untuk manusia yang sedang berpikir. Ia menemani proses, bukan mengejar hasil akhir. Ia tidak memaksa rapi, karena ide memang sering kali belum rapi.

Sementara tldraw terasa dirancang sebagai fondasi teknologi. Ia bukan sekadar alat gambar, melainkan mesin kanvas. Sesuatu yang bisa ditanam ke dalam aplikasi lain, dikembangkan lewat kode, dan dijadikan bagian dari sistem yang lebih besar. Di sini, tldraw tidak berusaha meniru papan tulis manusia, tetapi membangun infrastruktur visual yang stabil dan fleksibel.

Karena itu, pertanyaan “mana yang lebih baik” sebenarnya kurang tepat. Yang lebih tepat adalah: kita sedang ingin melakukan apa.

Jika tujuannya adalah berpikir, berdiskusi, menjelaskan ide, atau memetakan konsep dengan cepat dan manusiawi, Excalidraw terasa lebih pas. Ia tidak mengintimidasi, tidak terlalu formal, dan memberi ruang bagi ide untuk tumbuh apa adanya.

Namun jika tujuannya adalah membangun produk, sistem, atau aplikasi yang membutuhkan kanvas interaktif sebagai fitur, tldraw menjadi pilihan yang lebih masuk akal. Ia bukan hanya alat yang dipakai, tetapi fondasi yang bisa dikembangkan.

Pada akhirnya, Excalidraw dan tldraw tidak sedang berlomba. Mereka berjalan di jalur yang berbeda. Excalidraw mendekat ke cara manusia berpikir, sementara tldraw mendekat ke cara sistem bekerja. Dan kita, sebagai manusia yang sering berada di antara dua dunia itu, tinggal memilih sesuai kebutuhan hari ini.

Renungan Seorang Developer Tua :)

Ada satu fase yang hampir pasti dialami developer yang usianya sudah melewati 40 tahun atau bahkan sudah 50 tahun. Fase ketika kita mulai sadar bahwa masalah utama kita bukan lagi kurang belajar, tapi terlalu banyak belajar tanpa arah.

Di usia ini, teknologi tidak melambat. Justru sebaliknya. Ia makin bising.

JavaScript terus melahirkan framework baru. Frontend sekarang seperti laboratorium eksperimen tanpa jam istirahat. Ada Next.js, Remix, SvelteKit, Astro, Hono, Bun, Deno, edge runtime, server action, island architecture. Semua terlihat canggih. Semua terlihat menjanjikan. Dan jujur saja, semuanya terasa melelahkan.

Di backend, kita melihat pemandangan serupa.

PHP masih di sana. Masih dipakai. Masih menghasilkan uang. Tapi Laravel makin hari makin kompleks. Indah, rapi, penuh keajaiban—dan penuh jebakan bagi yang tidak benar-benar paham. Di saat yang sama, Go dan Rust naik daun. Go terlihat sederhana dan cepat. Rust terlihat serius dan aman. Banyak developer 40+ yang diam-diam bertanya: “Apa saya harus pindah?”

Pertanyaan itu wajar.

Tapi di usia ini, mungkin pertanyaan yang lebih jujur adalah: “Untuk apa?”

Karena di titik ini, kita sudah tidak lagi belajar demi rasa penasaran semata. Kita belajar sambil membawa beban: tanggung jawab keluarga, proyek yang harus selesai, sistem yang harus stabil, dan energi yang tidak lagi tak terbatas.

Masalahnya, banyak dari kita masih bersikap seperti developer usia 20-an. Mengejar semua tren. Takut ketinggalan. Takut dianggap usang. Padahal realitasnya berbeda.

Di usia 40+, kedalaman jauh lebih berharga daripada kecepatan.

Kita tidak butuh sepuluh framework di kepala. Kita butuh satu atau dua yang benar-benar kita pahami sampai ke akar. Bukan sekadar bisa pakai, tapi tahu risikonya. Tahu batasnya. Tahu kapan harus berkata: “Ini cukup.”

Frontend modern, misalnya. Kita tidak harus menguasai semuanya. Tapi kita perlu memahami problem intinya: state, async, rendering, performance, dan maintainability. Framework boleh berganti, tapi masalah dasarnya itu-itu saja.

Backend pun sama.

Laravel, Go, Rust—semuanya alat. Yang menentukan kualitas sistem bukan bahasanya, tapi keputusan teknis di baliknya. Salah desain tetap salah, walau ditulis dengan bahasa yang sedang naik daun.

Maka, bagaimana seharusnya bersikap sebagai developer 40+?

Pertama, berdamai dengan kenyataan bahwa kita tidak perlu tahu semuanya.

Ini bukan menyerah. Ini memilih. Kita memilih fokus. Kita memilih energi kita dipakai untuk hal yang berdampak nyata.

Kedua, jadikan teknologi baru sebagai cermin, bukan tujuan.

Belajar Go untuk memahami kesederhanaan concurrency. Belajar Rust untuk memahami pentingnya safety. Belajar framework frontend baru untuk melihat pendekatan berbeda. Tapi tidak harus pindah stack setiap kali ada yang viral.

Ketiga, ukur keberhasilan dari keberlanjutan, bukan kekinian.

Sistem yang bisa dirawat lima tahun ke depan lebih berharga daripada sistem yang terlihat futuristik hari ini tapi menyiksa besok.

Keempat, manfaatkan satu keunggulan yang tidak dimiliki developer muda: pengalaman.

Kita pernah melihat teknologi datang dan pergi. Kita tahu bahwa hype selalu berulang dengan nama baru. Pengalaman ini bukan beban—ini kompas.

Dan terakhir, izinkan diri kita untuk berkata jujur:

“Saya tidak ingin menjadi developer yang tahu semuanya. Saya ingin menjadi developer yang bisa diandalkan.”

Di usia 40+, mungkin tujuan kita bukan lagi menjadi yang paling update, tapi yang paling stabil.

Dan justru di situlah nilai kita sebenarnya.

Menjalankan Program PHP Tua

Saya mempunyai aplikasi tua. Menggunakan PHP versi 7.4 dan ini yg jadi masalah, setting sort_open_tag nya on. Untuk saat ini tidak ada yang lebih parah dari hal ini.

Akhirnya aplikasi saya jalankan menggunakan internal server di php. Tapi kata chatGPT hanya efektif untuk PHP 7.4 dan tidak unntuk PHP 8.X. Kebetulan lokasi php saya ada di /usr/bin/php7.4 ya. Silahkan sesuaikan untuk PHP kamu.

/usr/bin/php7.4 -d short_open_tag=On -S localhost:3000

Okey, semoga membantu 🙂

SQLite, WAL, dan Alasan Laravel Tidak Takut Menggunakannya

Ada masanya kita terlalu cepat memberi label. SQLite sering kebagian label yang kurang menyenangkan: database kecil, database lokal, database buat main-main. Bahkan kadang hanya dianggap pantas untuk testing, bukan untuk aplikasi sungguhan.

Padahal, kalau kita mau berhenti sejenak dan melihat lebih dalam, SQLite justru lahir dari kebutuhan yang sangat nyata: membuat sistem yang bekerja dengan tenang, stabil, dan tidak merepotkan.

SQLite tidak meminta banyak. Ia tidak butuh server. Tidak perlu user dan password. Tidak perlu service yang harus hidup sepanjang waktu. Ia cukup hadir sebagai satu file, dan langsung bekerja.

Bagi sebagian orang, kesederhanaan ini dianggap kelemahan. Bagi saya, justru di situlah kekuatannya.

Kita hidup di era di mana tidak semua aplikasi perlu berskala raksasa. Banyak sistem dibangun untuk sekolah, koperasi, lembaga, atau internal kantor. Sistem-sistem ini lebih membutuhkan ketenangan daripada kemewahan fitur.

SQLite hadir untuk dunia seperti itu.

Ia sudah lama menemani Android, browser, aplikasi desktop, bahkan sistem embedded. Bukan karena ia paling canggih, tapi karena ia paling bisa diandalkan untuk konteks yang tepat.

Masalah mulai muncul ketika SQLite dipaksa bekerja di luar habitatnya. Error yang paling sering disebut biasanya satu: “database is locked”. Di sinilah banyak orang berhenti dan menyimpulkan bahwa SQLite tidak layak dipakai.

Padahal, yang sering luput adalah kenyataan bahwa SQLite berkembang. Ia tidak diam di tempat. Salah satu fitur penting yang sering tidak disadari adalah WAL, atau Write-Ahead Logging.

Dengan WAL, cara kerja SQLite berubah cukup fundamental. Proses menulis data tidak lagi mengganggu proses membaca. Data baru dicatat terlebih dahulu, sementara pembaca tetap bisa bekerja dengan data yang ada.

Hasilnya terasa sederhana tapi dampaknya besar. Aplikasi menjadi lebih responsif. Error penguncian jauh berkurang. SQLite menjadi jauh lebih ramah untuk penggunaan multi-user ringan.

Di titik inilah SQLite sering kali dinilai ulang. Bukan lagi sebagai database kecil, tetapi sebagai database yang tahu batas dirinya.

Menariknya, pendekatan ini sejalan dengan filosofi Laravel.

Laravel tidak dibangun untuk membuat kita pusing sejak hari pertama. Ia ingin kita fokus pada aplikasi, bukan pada infrastruktur. Karena itu, SQLite sering muncul sebagai pilihan default, terutama di awal pengembangan dan pengujian.

Dengan SQLite, developer bisa langsung bekerja. Migrasi jalan. Testing berjalan. Tanpa perlu mengurusi server database yang belum tentu dibutuhkan sejak awal.

Ini bukan keputusan sembrono. Ini keputusan yang sadar konteks.

Laravel tahu bahwa sebagian besar aplikasi tidak langsung berhadapan dengan ribuan user. Banyak aplikasi lahir untuk menyelesaikan masalah yang spesifik dan terbatas. Di fase itu, kecepatan membangun jauh lebih penting daripada skala.

Ketika nanti aplikasi tumbuh, Laravel juga tidak mengikat kita. Migrasi ke MySQL atau PostgreSQL tetap terbuka. Tanpa harus menulis ulang segalanya.

SQLite dan Laravel sama-sama mengajarkan satu hal yang sering kita lupakan sebagai programmer: tidak semua masalah perlu solusi besar sejak awal.

Ada saatnya kita butuh sistem yang sederhana, tenang, dan bisa dipercaya. Sistem yang tidak banyak bicara, tapi bekerja.

Di konteks itulah SQLite menemukan tempatnya.

Bukan untuk semua kasus. Bukan untuk semua skala. Tapi untuk banyak kebutuhan nyata yang sering kita hadapi sehari-hari.

Dan mungkin, di sanalah letak kedewasaannya.