> For the complete documentation index, see [llms.txt](https://navixy.com/docs/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://navixy.com/docs/expert-center/id/vehicle-telematics-technology/connectivity/mqtt-fundamentals.md). # Dasar-dasar MQTT Protokol Message Queuing Telemetry Transport (MQTT) telah digunakan selama bertahun-tahun, tetapi kini menjadi sangat relevan karena pertumbuhan IoT yang eksplosif: baik perangkat konsumen maupun industri sedang menerapkan jaringan terdistribusi dan komputasi tepi, dan perangkat dengan transmisi data konstan menjadi bagian dari kehidupan sehari-hari. Pertumbuhan yang intensif semacam itu memaksa orang mencari cara untuk mentransfer data secara efisien. ## Apa itu MQTT Andy Stanford-Clark (IBM) dan Arlen Nipper (saat itu bekerja untuk Eurotech, Inc.) menulis versi pertama protokol ini pada tahun 1999. Protokol ini digunakan untuk memantau pipa minyak dalam kerangka SCADA. Tujuannya adalah memiliki protokol yang hemat bandwidth, ringan, dan menggunakan daya baterai yang kecil, karena perangkat-perangkat tersebut terhubung melalui tautan satelit yang pada saat itu sangat mahal. Saat ini, sebagian besar perangkat menggunakan versi 5.0. Message Queuing Telemetry Transport (MQTT) adalah protokol jaringan publish-subscribe yang ringan dan mengirimkan pesan antarperangkat. Protokol ini biasanya berjalan di atas TCP/IP; namun, protokol jaringan apa pun yang menyediakan koneksi dua arah yang berurutan dan tanpa kehilangan dapat mendukung MQTT. Protokol ini dirancang untuk koneksi dengan lokasi jarak jauh ketika diperlukan "small code footprint" atau bandwidth jaringan terbatas. Protokol ini merupakan standar terbuka OASIS dan rekomendasi ISO (ISO/IEC 20922). Mengingat kondisi operasionalnya, protokol ini dibuat kecil dan ringan. Protokol ini ideal untuk perangkat dengan konsumsi daya rendah dan masa pakai baterai terbatas. Kini, ini mencakup ponsel pintar, serta semakin banyak sensor dan perangkat terhubung. Dengan demikian, MQTT telah menjadi protokol untuk streaming data antarperangkat dengan daya CPU dan/atau masa pakai baterai terbatas, serta untuk jaringan dengan bandwidth mahal atau rendah, stabilitas yang tidak dapat diprediksi, atau latensi tinggi. Itulah sebabnya MQTT dikenal sebagai protokol ideal untuk IoT. Protokol ini dibangun di atas protokol TCP/IP, tetapi ada cabang MQTT-SN untuk bekerja melalui Bluetooth, UDP, ZigBee, dan jaringan IoT lain selain TCP/IP. ## Cara kerjanya ### Model publish dan subscribe Ada 2 definisi utama dalam MQTT: MQTT Broker dan MQTT client. MQTT broker adalah server yang menerima semua pesan dari klien lalu mengarahkan pesan tersebut ke klien tujuan yang sesuai. Sederhananya, broker bertindak sebagai kantor pos, MQTT tidak menggunakan alamat penerima yang dituju tetapi menggunakan baris subjek yang disebut “Topic”, dan siapa pun yang ingin mendapatkan salinan pesan tersebut akan berlangganan topik itu. Beberapa klien dapat menerima pesan dari satu broker (kemampuan satu ke banyak). Demikian pula, beberapa penerbit dapat menerbitkan topik ke satu pelanggan (banyak ke satu). MQTT client adalah perangkat apa pun (dari mikrokontroler hingga server penuh) yang menjalankan pustaka MQTT dan terhubung ke MQTT broker melalui jaringan. * Klien terhubung ke broker. Klien dapat berlangganan ke topik pesan apa pun di broker. Koneksi ini dapat berupa koneksi TCP/IP biasa atau koneksi TLS terenkripsi untuk pesan sensitif. * Klien menerbitkan pesan di bawah suatu topik dengan mengirimkan pesan dan topik tersebut ke broker. * Broker kemudian meneruskan pesan ke semua klien yang berlangganan topik tersebut. Karena pesan MQTT diorganisasikan berdasarkan topik, pengembang aplikasi memiliki fleksibilitas untuk menentukan bahwa klien tertentu hanya dapat berinteraksi dengan pesan tertentu. Misalnya, sensor akan menerbitkan pembacaannya di bawah topik “sensor\_data” dan berlangganan ke topik “config\_change”. Aplikasi pemrosesan data yang menyimpan data sensor ke basis data backend akan berlangganan ke topik “sensor\_data”. Aplikasi konsol admin dapat menerima perintah administrator sistem untuk menyesuaikan konfigurasi sensor, seperti sensitivitas dan frekuensi sampel, dan menerbitkan perubahan tersebut ke topik “config\_change”. ### Jenis pesan MQTT Sesi MQTT dibagi menjadi empat tahap: koneksi, autentikasi, komunikasi, dan terminasi. Klien memulai dengan membuat koneksi Transmission Control Protocol/Internet Protocol (TCP/IP) ke broker menggunakan port standar atau port kustom yang ditentukan oleh operator broker. Saat membuat koneksi, penting untuk mengenali bahwa server mungkin melanjutkan sesi lama jika diberikan identitas klien yang digunakan kembali. Port standar adalah 1883 untuk komunikasi tidak terenkripsi dan 8883 untuk komunikasi terenkripsi -- menggunakan Secure Sockets Layer (SSL)/Transport Layer Security (TLS). Selama handshake SSL/TLS, klien memvalidasi sertifikat server dan mengautentikasi server. Klien juga dapat memberikan sertifikat klien ke broker selama handshake. Broker dapat menggunakannya untuk mengautentikasi klien. Meskipun tidak secara khusus menjadi bagian dari spesifikasi MQTT, sudah menjadi kebiasaan bagi broker untuk mendukung autentikasi klien dengan sertifikat sisi klien SSL/TLS. Karena protokol MQTT bertujuan menjadi protokol untuk perangkat yang dibatasi sumber dayanya dan perangkat IoT, SSL/TLS mungkin tidak selalu menjadi pilihan dan, dalam beberapa kasus, mungkin tidak diinginkan. Pada keadaan seperti itu, autentikasi disajikan sebagai nama pengguna dan kata sandi teks biasa, yang dikirim oleh klien ke server - ini, sebagai bagian dari urutan paket CONNECT/CONNACK. Selain itu, beberapa broker, terutama broker terbuka yang dipublikasikan di internet, akan menerima klien anonim. Dalam kasus seperti itu, nama pengguna dan kata sandi cukup dibiarkan kosong. ### Format pesan MQTT MQTT dianggap sebagai protokol ringan karena semua pesannya memiliki small code footprint. Paket terdiri dari header tetap 2-byte + header variabel dan payload. Pada 2-byte pertama ini, header tetap akan selalu ada di semua paket dan dua lainnya, yaitu header variabel dan payload, tidak selalu ada. ![Format pesan MQTT](/files/0bced5eae4299f3a8625c727994eb7f263e6bc68) Dari header tetap dua byte, byte pertama adalah field kontrol. Field kontrol 8-bit ini dibagi menjadi dua field 4 bit. 4 bit MSB pertama adalah field jenis perintah. Jenis ini menentukan tindakan yang akan dilakukan: klien ingin berlangganan topik, pesan baru diterbitkan untuk pelanggan, dan lainnya. 4 bit berikutnya adalah bit flag kontrol dan digunakan oleh perintah publish; untuk perintah lainnya bit tersebut dicadangkan dan nilainya akan 0. Byte kedua dari header tetap berisi panjang tersisa, yaitu panjang header variabel + panjang payload. Header variabel tidak ada di semua paket MQTT. Beberapa perintah atau pesan MQTT menggunakan field ini untuk menyediakan informasi atau flag tambahan dan nilainya bervariasi tergantung pada jenis paket. Pengidentifikasi paket umum ada pada sebagian besar jenis paket. Pada akhirnya, paket dapat berisi payload. Bahkan payload bersifat opsional dan bervariasi sesuai jenis paket. Field ini biasanya berisi data yang sedang dikirim. Misalnya, untuk paket CONNECT, payload adalah client ID dan 'username and password' jika ada. Dan untuk paket PUBLISH, isinya adalah pesan yang akan diterbitkan. ### Quality of Service QoS mengacu pada perjanjian antara pengirim pesan dan penerima pesan. Ini bertindak sebagai fitur kunci dalam MQTT, memberikan klien kemampuan untuk memilih di antara tiga tingkat layanan. Tiga tingkat QoS yang berbeda menentukan bagaimana konten dikelola oleh protokol MQTT. Meskipun tingkat QoS yang lebih tinggi lebih andal, tingkat tersebut memiliki kebutuhan latensi dan bandwidth yang lebih tinggi, sehingga klien yang berlangganan dapat menentukan tingkat QoS tertinggi yang ingin mereka terima. * Tingkat QoS paling sederhana adalah layanan tanpa pengakuan. Tingkat QoS ini menggunakan urutan paket PUBLISH; penerbit mengirim pesan ke broker satu kali, dan broker meneruskan pesan ke pelanggan satu kali. Tidak ada mekanisme untuk memastikan bahwa pesan telah diterima dengan benar, dan broker tidak menyimpan pesan. Tingkat QoS ini juga dapat disebut sebagai at most once, QoS0, atau fire and forget. * Tingkat QoS kedua adalah layanan dengan pengakuan. Tingkat QoS ini menggunakan urutan paket PUBLISH/PUBACK antara penerbit dan brokernya, serta antara broker dan pelanggan. Paket pengakuan memverifikasi bahwa konten telah diterima, dan mekanisme coba ulang akan mengirimkan kembali konten asli jika pengakuan tidak diterima tepat waktu. Hal ini dapat menyebabkan pelanggan menerima beberapa salinan dari pesan yang sama. Tingkat QoS ini juga dapat disebut sebagai at least once atau QoS1. * Tingkat QoS ketiga adalah layanan terjamin. Tingkat QoS ini mengirimkan pesan dengan dua pasang paket. Pasangan pertama disebut PUBLISH/PUBREC, dan pasangan kedua disebut PUBREL/PUBCOMP. Kedua pasangan ini memastikan bahwa, berapa pun jumlah percobaannya, pesan hanya akan dikirimkan satu kali. Tingkat QoS ini juga dapat disebut sebagai exactly once atau QoS2. ![QoS MQTT](/files/c8d9adfcbb28b70706da5db2b8187a6cdf02c274) ## Kelebihan dan kekurangan ### Kelebihan: * MQTT bersifat packet agnostic. Payload protokol MQTT dapat membawa jenis data apa pun seperti biner, teks ASCII, dll. Penerima perlu menafsirkan dan mendekode sesuai format yang digunakan oleh pengirim. * Protokol ini menggunakan paket berukuran kecil dan dapat digunakan untuk aplikasi berbandwidth rendah. * Protokol ini menawarkan konsumsi daya baterai yang lebih rendah. * Protokol ini andal karena menggunakan opsi QoS untuk memberikan pengiriman yang terjamin. * Karena model publish/subscribe-nya, protokol ini skalabel. * Protokol ini menawarkan desain yang terpisah karena perangkat dan server mudah dipisahkan. Ideal untuk komunikasi terdistribusi satu ke banyak dan aplikasi yang terpisah. * Perangkat yang menerbitkan dapat mengirim data ke server kapan saja tanpa bergantung pada statusnya. * Dilengkapi dengan fungsi LWT (Last Will and Testament) untuk memberi tahu pihak-pihak terkait tentang pemutusan koneksi klien yang abnormal. * Bergantung pada TCP/IP untuk tugas komunikasi dasar. * Dirancang untuk mengirimkan pesan sesuai dengan templat "maximum once", "minimum once" dan "exactly once". ### Kekurangan: * MQTT tidak dapat mendukung streaming video. * Masalah dengan latensi. * Keamanan tidak bawaan. MQTT tidak terenkripsi. Sebagai gantinya, MQTT menggunakan TLS/SSL (Transport Layer Security/Secure Sockets Layer) untuk enkripsi keamanan. * Broker terpusat dapat menjadi titik kegagalan karena koneksi klien dengan broker selalu terbuka. * Protokol ini tidak mendukung fitur lanjutan seperti kontrol aliran. ## Di mana MQTT dapat digunakan Karena aplikasi IoT kini diterapkan dalam skala besar, MQTT telah menjadi sorotan sebagai cara yang terbuka, sederhana, dan skalabel untuk menerapkan komputasi terdistribusi dan fungsionalitas IoT kepada basis pengguna yang lebih luas — baik di pasar konsumen maupun industri. * Manajemen armada. Organisasi menggunakan MQTT untuk membangun sistem manajemen armada yang lebih cerdas, yang meningkatkan optimalisasi armada, keselamatan pengemudi, dan menurunkan biaya bahan bakar. Mode transportasi baru menggunakan drone juga mengubah cara kita memindahkan barang. Konektivitas antara perangkat seluler yang digunakan oleh operator, informasi telemetri langsung dari kendaraan, dan integrasi ke dalam sistem penjadwalan dan perutean backend menyediakan visibilitas yang diperlukan untuk meningkatkan operasi armada secara keseluruhan. * Data sensor lingkungan. MQTT mendukung model pengiriman pesan "no more than once". Dalam jaringan dengan cakupan wilayah yang sebagian atau latensi tinggi, ini berarti informasi dapat hilang atau digandakan. Di area tempat sensor jarak jauh merekam dan mengirim data pada interval yang ditentukan, hal ini bukan masalah, karena pembacaan baru diterima secara teratur. Sensor di lingkungan jarak jauh biasanya adalah perangkat berdaya rendah, yang menjadikan MQTT solusi ideal untuk sensor IoT dengan prioritas transfer data yang relatif rendah. * Data kesehatan mesin: untuk merespons dengan cepat masalah yang muncul dan mencegah waktu henti. Misalnya, untuk pembangkit listrik tenaga angin, Anda memerlukan pengiriman indikator kinerja terkini yang terjamin kepada tim lokal bahkan sebelum informasi ini sampai ke pusat pemrosesan data. Dalam situasi seperti itu, pengiriman pesan "at least once" menjamin bahwa penanda yang sesuai akan diperhatikan oleh spesialis yang diperlukan tepat waktu, meskipun pesan datang sebagai duplikat. Hal ini penting untuk komunikasi machine-to-machine dengan prioritas yang lebih tinggi. * Sistem penagihan: Ada pesan yang bahkan lebih prioritas dan akurat yang perlu ditangani dengan benar. Dalam situasi bisnis di mana duplikasi catatan tidak dapat diterima, termasuk dalam sistem penagihan, flag QoS transmisi "exactly once" sangat berguna. Ini menghilangkan duplikasi atau kehilangan paket dalam penagihan atau sistem penagihan, mengurangi jumlah anomali dan kontradiksi yang tidak perlu dalam perjanjian. * Aplikasi perpesanan berbasis teks untuk komunikasi real-time yang memanfaatkan penggunaan data dan energi MQTT yang rendah. Misalnya, Facebook menggunakan MQTT untuk aplikasi Messenger-nya, bukan hanya karena protokol ini menghemat daya baterai saat perpesanan ponsel ke ponsel, tetapi juga karena protokol ini memungkinkan pesan dikirim secara efisien dalam hitungan milidetik, meskipun koneksi internet di seluruh dunia tidak konsisten. ## Perangkat MQTT yang didukung oleh Navixy * Xirgo Global FMS500 Light MQTT (IOTM * Xirgo Global FMS500 Light+ MQTT (IOTM) * Xirgo Global FMS500 StCAN MQTT (IOTM) * BCE FMS500 Light MQTT (IOTM) * BCE FMS500 Light+ MQTT (IOTM) * BCE FMS500 StCAN MQTT (IOTM) * GlobalmatiX xTCU ## Cara mengonfigurasi perangkat MQTT agar bekerja dengan Navixy ### Konfigurasi perangkat Xirgo & BCE MQTT Untuk mengonfigurasi perangkat Xirgo & BCE agar bekerja dengan MQTT: * Di dalam FMSET: Pilih connectivity → Telemetry server → MQTT broker address settings) tentukan host: [mqtt.eu.navixy.com](http://mqtt.eu.navixy.com/) untuk server EU dan [mqtt.us.navixy.com](http://mqtt.eu.navixy.com/) untuk server US, port 1883. * Dan tambahkan pengguna default di MQTT Security -> Authorization\ ![MQTT device configuration](/files/5bbe66013bdccd4d8f0498b23bcdbd142b58a698) ### Konfigurasi perangkat Globalmatix MQTT Untuk mengonfigurasi perangkat Globalmatix agar bekerja dengan MQTT: * Tentukan server port 1883 untuk EU dan port 1883 untuk US * User/password - globalmatix/secretword * Topic globalmatix/in Untuk mengonfigurasi perangkat Globalmatix agar bekerja dengan MQTTS: * Tentukan server port 8883 untuk EU dan port 8883 untuk US * User/password - globalmatix/secretword * Topic globalmatix/in --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter: ``` GET https://navixy.com/docs/expert-center/id/vehicle-telematics-technology/connectivity/mqtt-fundamentals.md?ask= ``` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.