> 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 Transport Telemetri Antrian Pesan (MQTT) telah digunakan selama bertahun-tahun, tetapi kini sangat relevan karena pertumbuhan IoT yang eksplosif: baik perangkat konsumen maupun perangkat industri menerapkan jaringan terdistribusi dan komputasi tepi, dan perangkat dengan transmisi data yang konstan menjadi bagian dari kehidupan sehari-hari. Pertumbuhan yang sangat intensif ini 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 jaringan pipa minyak dalam kerangka kerja SCADA. Tujuannya adalah memiliki protokol yang hemat bandwidth, ringan, dan menggunakan sedikit daya baterai, karena perangkat terhubung melalui tautan satelit yang pada saat itu sangat mahal. Saat ini, sebagian besar perangkat menggunakan versi 5.0. Transport Telemetri Antrian Pesan (MQTT) adalah protokol jaringan ringan dengan model penerbitan-berlangganan yang mengangkut pesan antardevais. Protokol ini biasanya berjalan di atas TCP/IP; namun, setiap protokol jaringan yang menyediakan koneksi dua arah yang berurutan, tanpa kehilangan, dapat mendukung MQTT. Protokol ini dirancang untuk koneksi ke lokasi jarak jauh ketika diperlukan “jejak kode kecil” 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 telepon pintar, serta jumlah sensor dan Perangkat terhubung yang terus bertambah. Dengan demikian, MQTT telah menjadi protokol untuk aliran data antardevais dengan daya CPU dan/atau masa pakai baterai terbatas, serta untuk jaringan dengan biaya tinggi atau bandwidth 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 varian MQTT-SN untuk bekerja melalui Bluetooth, UDP, ZigBee, dan dalam jaringan IoT lain selain TCP/IP. ## Cara kerjanya ### Model penerbitan dan berlangganan Ada 2 definisi utama dalam MQTT: broker MQTT dan klien MQTT. Broker MQTT adalah server yang menerima semua pesan dari klien lalu mengarahkan pesan ke klien tujuan yang sesuai. Sederhananya, broker bertindak seperti kantor pos, MQTT tidak menggunakan alamat penerima yang dituju, tetapi menggunakan baris subjek yang disebut “Topik”, dan siapa pun yang ingin mendapatkan salinan pesan itu akan berlangganan ke topik tersebut. Banyak klien dapat menerima pesan dari satu broker (kemampuan satu-ke-banyak). Demikian pula, banyak penerbit dapat memublikasikan topik ke satu pelanggan (banyak-ke-satu). Klien MQTT adalah perangkat apa pun (dari mikrokontroler hingga server lengkap) yang menjalankan pustaka MQTT dan terhubung ke broker MQTT melalui jaringan. * Klien terhubung ke broker. Klien dapat berlangganan 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 tersebut ke semua klien yang berlangganan topik tersebut. Karena Pesan MQTT diatur 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 topik “config\_change”. Aplikasi pemrosesan data yang menyimpan data sensor ke dalam basis data backend akan berlangganan topik “sensor\_data”. Aplikasi konsol admin dapat menerima perintah admin sistem untuk menyesuaikan konfigurasi sensor, seperti sensitivitas dan frekuensi sampel, serta 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 khusus yang ditentukan oleh operator broker. Saat membuat koneksi, penting untuk memahami bahwa server mungkin melanjutkan sesi lama jika diberikan identitas klien yang digunakan kembali. Port standar adalah 1883 untuk komunikasi tanpa enkripsi dan 8883 untuk komunikasi terenkripsi -- menggunakan Secure Sockets Layer (SSL)/Keamanan Lapisan Transportasi (TLS). Selama handshake SSL/TLS, klien memvalidasi sertifikat server dan mengautentikasi server. Klien juga dapat memberikan sertifikat klien kepada broker selama handshake. Broker dapat menggunakan sertifikat ini untuk mengautentikasi klien. Meskipun tidak secara khusus menjadi bagian dari spesifikasi MQTT, sudah menjadi kebiasaan bagi broker untuk mendukung autentikasi klien dengan sertifikat SSL/TLS sisi klien. Karena protokol MQTT ditujukan untuk menjadi protokol bagi perangkat dengan sumber daya terbatas dan perangkat IoT, SSL/TLS mungkin tidak selalu menjadi pilihan dan, dalam beberapa kasus, mungkin tidak diinginkan. Dalam 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 tersebut, nama pengguna dan kata sandi cukup dibiarkan kosong. ### Format Pesan MQTT MQTT dianggap sebagai protokol ringan karena semua Pesan memiliki jejak kode yang kecil. Paket terdiri dari header tetap 2-byte + header variabel dan payload. Pada 2-byte pertama ini, header tetap akan selalu ada di semua paket, sedangkan dua lainnya, header variabel dan payload, tidak selalu ada. ![Format Pesan MQTT](/files/97eb0020cfd5cc25e2302e3c18738765a9b8ebbb) Dari header tetap dua-byte, byte pertama adalah bidang kontrol. Bidang kontrol 8-bit ini dibagi menjadi dua bidang 4 bit. Empat bit MSB pertama adalah bidang jenis perintah. Jenis ini menentukan tindakan yang akan dilakukan: klien ingin berlangganan ke topik, Pesan baru diterbitkan untuk pelanggan, dan lainnya. Empat bit berikutnya adalah bit flag kontrol dan digunakan oleh perintah publish; untuk sisa perintah, bit-bit ini dicadangkan dan nilainya akan 0. Byte kedua dari header tetap berisi sisa panjang, yaitu panjang header variabel + panjang payload. Header variabel tidak ada di semua paket MQTT. Beberapa perintah atau Pesan MQTT menggunakan bidang ini untuk memberikan informasi tambahan atau flag, dan nilainya bervariasi tergantung pada jenis paket. Pengidentifikasi paket umum pada sebagian besar jenis paket. Pada akhirnya, paket dapat berisi payload. Payload juga bersifat opsional dan bervariasi menurut jenis paket. Bidang ini biasanya berisi data yang sedang dikirim. Misalnya, untuk paket CONNECT, payload-nya adalah ID klien dan “username dan password” jika ada. Dan untuk paket PUBLISH, isinya adalah Pesan yang akan diterbitkan. ### Kualitas layanan QoS mengacu pada kesepakatan antara pengirim Pesan dan penerima Pesan tersebut. Ini bertindak sebagai fitur kunci dalam MQTT, memberi 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 latensi dan kebutuhan bandwidth yang lebih besar, sehingga klien yang berlangganan dapat menentukan tingkat QoS tertinggi yang ingin mereka terima. * Tingkat QoS paling sederhana adalah layanan tanpa konfirmasi. Tingkat QoS ini menggunakan rangkaian paket PUBLISH; penerbit mengirim Pesan ke broker satu kali, dan broker meneruskan Pesan ke pelanggan satu kali. Tidak ada mekanisme untuk memastikan Pesan telah diterima dengan benar, dan broker tidak menyimpan Pesan. Tingkat QoS ini juga dapat disebut sebagai paling banyak satu kali, QoS0, atau tembak dan lupakan. * Tingkat QoS kedua adalah layanan terkonfirmasi. Tingkat QoS ini menggunakan urutan paket PUBLISH/PUBACK antara penerbit dan brokernya, serta antara broker dan pelanggan. Paket konfirmasi memverifikasi bahwa konten telah diterima, dan mekanisme percobaan ulang akan mengirimkan konten asli lagi jika konfirmasi tidak diterima tepat waktu. Hal ini dapat mengakibatkan pelanggan menerima beberapa salinan dari pesan yang sama. Tingkat QoS ini juga dapat disebut sebagai setidaknya sekali 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 tepat satu kali atau QoS2. ![QoS MQTT](/files/45820e6b3cd25da9c510134f81bcc663806d7683) ## Kelebihan dan kekurangan ### Keunggulan: * MQTT bersifat agnostik terhadap paket. Muatan protokol MQTT dapat membawa berbagai jenis data seperti biner, teks ASCII, dan sebagainya. Penerima perlu menafsirkan dan mendekode sesuai dengan format yang digunakan oleh pengirim. * Ini menggunakan paket berukuran kecil dan dapat digunakan untuk aplikasi dengan bandwidth rendah. * Ini menawarkan konsumsi daya baterai yang lebih rendah. * Ini adalah protokol yang andal karena menggunakan opsi QoS untuk menyediakan pengiriman yang terjamin. * Karena model publish/subscribe-nya, protokol ini skalabel. * Ini menawarkan rancangan yang terpisah karena perangkat dan server mudah dipisahkan. Ideal untuk komunikasi terdistribusi satu ke banyak dan aplikasi yang terpisah. * Perangkat pengirim data dapat mengirim data ke server kapan saja terlepas dari statusnya. * Dilengkapi dengan fungsi LWT (Last Will and Testament) untuk memberi tahu pihak-pihak terkait tentang pemutusan koneksi klien yang tidak normal. * Bergantung pada TCP/IP untuk tugas komunikasi dasar. * Dirancang untuk mengirimkan pesan sesuai dengan templat "maksimum satu kali", "minimum satu kali", dan "tepat satu kali". ### Kekurangan: * MQTT tidak dapat mendukung streaming video. * Masalah dengan latensi. * Keamanan tidak disertakan. MQTT tidak terenkripsi. Sebagai gantinya, ia 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. * 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. * Armada. Organisasi menggunakan MQTT untuk membangun sistem manajemen Armada yang lebih cerdas yang meningkatkan optimalisasi Armada, Keselamatan Supir, dan menurunkan biaya Bahan bakar. Moda transportasi baru yang 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 back-end memberikan visibilitas yang diperlukan untuk meningkatkan operasi Armada secara keseluruhan. * Data sensor lingkungan. MQTT mendukung model pengiriman Pesan “tidak lebih dari sekali”. Dalam jaringan dengan cakupan wilayah yang parsial atau latensi tinggi, ini berarti bahwa informasi dapat hilang atau diduplikasi. Di area tempat sensor jarak jauh merekam dan mengirimkan data pada interval yang ditentukan, hal ini bukan masalah, karena pembacaan baru diterima secara berkala. Sensor di lingkungan terpencil 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 masalah yang muncul dengan cepat dan mencegah waktu henti. Misalnya, untuk pembangkit listrik tenaga angin, Anda memerlukan pengiriman terjamin dari indikator kinerja terkini kepada tim lokal bahkan sebelum informasi ini sampai ke pusat pemrosesan data. Dalam situasi seperti itu, pengiriman Pesan “setidaknya sekali” menjamin bahwa flag yang sesuai akan diperhatikan oleh spesialis yang diperlukan tepat waktu, meskipun tiba sebagai duplikat. Ini penting untuk komunikasi mesin-ke-mesin dengan prioritas lebih tinggi. * Sistem penagihan: Ada Pesan yang memiliki prioritas dan akurasi lebih tinggi yang perlu ditangani dengan benar. Dalam situasi bisnis di mana duplikasi catatan tidak dapat diterima, termasuk dalam sistem penagihan, flag QoS transmisi “tepat satu kali” 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 waktu nyata 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 selama perpesanan dari ponsel ke ponsel, tetapi juga karena protokol ini memungkinkan Pesan dikirim secara efisien dalam 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 MQTT Xirgo & BCE Untuk mengonfigurasi perangkat Xirgo & BCE agar bekerja dengan MQTT: * Di dalam FMSET: Pilih **Konektivitas** → **Server telemetri** → **Pengaturan alamat broker MQTT** dan tentukan host: [mqtt.eu.navixy.com](http://mqtt.eu.navixy.com/) untuk server EU dan [mqtt.us.navixy.com](http://mqtt.us.navixy.com/) untuk server US, port 1883. * Dan tambahkan pengguna bawaan di **Keamanan MQTT** -> **Otorisasi**\ ![MQTT device configuration](/files/5fc7e3a879dd0f1bb0610716cb80d8e8f9b2b872) ### Konfigurasi perangkat MQTT Globalmatix Untuk mengonfigurasi perangkat Globalmatix agar bekerja dengan MQTT: * Tentukan server port 1883 untuk EU dan port 1883 untuk US * **Pengguna/kata sandi**: globalmatix/secretword * **Topik**: globalmatix/in Untuk mengonfigurasi perangkat Globalmatix agar bekerja dengan MQTTS: * Tentukan **server** port 8883 untuk EU dan port 8883 untuk US * **Pengguna/kata sandi**: globalmatix/secretword * **Topik**: 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, and the optional `goal` query parameter: ``` GET https://navixy.com/docs/expert-center/id/vehicle-telematics-technology/connectivity/mqtt-fundamentals.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. 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.