> 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 publish/subscribe yang mendukung komunikasi perangkat IoT ringan. Mencakup pengaturan broker MQTT, format pesan, tingkat QoS, dan kasus penggunaan telematika. Protokol Message Queuing Telemetry Transport (MQTT) telah digunakan selama bertahun-tahun, tetapi kini menjadi sangat relevan karena pertumbuhan IoT yang eksplosif: perangkat konsumen dan industri sama-sama menerapkan jaringan terdistribusi dan komputasi tepi, dan perangkat dengan transmisi data yang terus-menerus menjadi bagian dari kehidupan sehari-hari. Pertumbuhan yang intensif ini mendorong orang untuk mencari cara 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 1999. Protokol ini digunakan untuk memantau pipa minyak dalam kerangka kerja SCADA. Tujuannya adalah memiliki protokol yang hemat bandwidth, ringan, dan menggunakan daya baterai yang sedikit, karena perangkat 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 ringan publikasi-berlangganan yang 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 data dapat mendukung MQTT. Protokol ini dirancang untuk koneksi ke lokasi terpencil yang memerlukan “jejak kode kecil” atau ketika 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, hal ini mencakup ponsel pintar, serta jumlah sensor dan perangkat terhubung yang terus bertambah. Dengan demikian, MQTT telah menjadi protokol untuk mengalirkan data antara perangkat dengan daya pemrosesan CPU terbatas 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 varian MQTT-SN untuk bekerja melalui Bluetooth, UDP, ZigBee, dan pada jaringan IoT lain selain TCP/IP. ## Cara kerjanya ### Model publikasi-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 tersebut ke klien tujuan yang sesuai. Sederhananya, broker bertindak sebagai kantor pos: MQTT tidak menggunakan alamat penerima yang dituju, melainkan menggunakan baris subjek yang disebut “topik”, dan siapa pun yang menginginkan salinan pesan itu akan berlangganan topik tersebut. Beberapa klien dapat menerima pesan dari satu broker (kemampuan satu ke banyak). Demikian pula, beberapa penerbit dapat memublikasikan topik ke satu pelanggan (banyak ke satu). Klien MQTT adalah perangkat apa pun (mulai 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 dalam suatu topik dengan mengirimkan Pesan dan topik tersebut ke broker. * Broker kemudian meneruskan Pesan 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 dalam 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 penghentian. 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 menyadari 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 Keamanan (TLS). Selama handshake SSL/TLS, klien memvalidasi sertifikat server dan mengautentikasi server. Klien juga dapat memberikan sertifikat klien kepada 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 dirancang untuk perangkat dengan sumber daya terbatas dan perangkat IoT, SSL/TLS mungkin tidak selalu menjadi pilihan dan, dalam beberapa kasus, mungkin tidak diinginkan. Dalam situasi tersebut, autentikasi disajikan sebagai nama pengguna dan kata sandi teks biasa, yang dikirim oleh klien ke server - 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 dikosongkan. ### Format Pesan MQTT MQTT dianggap protokol ringan karena semua Pesan-nya 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](https://3546701789-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FIgDb43gtyXcm1Av4h1np%2Fuploads%2Fgit-blob-6ea9b1f21c9f81792c5f2c59d36794c86f4881ab%2Fimagen-20231019-231143.png?alt=media) Dari header tetap dua byte, byte pertama adalah bidang kontrol. Bidang kontrol 8-bit ini dibagi menjadi dua bidang 4 bit. 4 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. 4 bit berikutnya adalah bit bendera kontrol dan digunakan oleh perintah publish; untuk perintah lainnya bit ini dicadangkan dan nilainya akan 0. Byte kedua dari header tetap berisi sisa panjang, yaitu panjang header variabel + panjang payload. Header variabel tidak terdapat di semua paket MQTT. Beberapa perintah atau pesan MQTT menggunakan bidang ini untuk memberikan informasi tambahan atau bendera, dan nilainya bervariasi tergantung pada jenis paket. Pengidentifikasi paket umum pada sebagian besar jenis paket. Pada akhirnya, paket dapat berisi payload. Bahkan payload bersifat opsional dan bervariasi menurut jenis paket. Bidang ini biasanya berisi data yang dikirim. Misalnya, untuk paket CONNECT, payload adalah ID klien serta nama pengguna dan kata sandi jika ada. Dan untuk paket PUBLISH, payload adalah pesan yang akan diterbitkan. ### Kualitas layanan QoS mengacu pada kesepakatan antara pengirim sebuah pesan dan penerima pesan tersebut. Ini bertindak sebagai fitur kunci dalam MQTT, memberi klien kemampuan untuk memilih di antara tiga tingkat layanan. Tiga level QoS yang berbeda menentukan bagaimana konten dikelola oleh protokol MQTT. Meskipun level QoS yang lebih tinggi lebih andal, level tersebut memiliki latensi dan persyaratan bandwidth yang lebih besar, sehingga klien yang berlangganan dapat menentukan level QoS tertinggi yang ingin mereka terima. * Level QoS paling sederhana adalah layanan tanpa pengakuan. Level QoS ini menggunakan urutan paket PUBLISH; penerbit mengirim pesan ke broker satu kali, dan broker meneruskan pesan ke pelanggan satu kali. Tidak ada mekanisme yang memastikan bahwa pesan telah diterima dengan benar, dan broker tidak menyimpan pesan tersebut. Level QoS ini juga dapat disebut sebagai paling banyak sekali, QoS0, atau kirim 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 kembali konten asli jika konfirmasi tidak diterima tepat waktu. Hal ini dapat menyebabkan 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 sekali atau QoS2. ![QoS MQTT](https://3546701789-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FIgDb43gtyXcm1Av4h1np%2Fuploads%2Fgit-blob-9ab221645f4cb2fd3ec068c2cbd9aa27a4196e83%2Fchrome_q1ak4noiok-600x466.png?alt=media) ## Keuntungan dan kerugian ### Keuntungan: * 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 berbandwidth 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 dapat diskalakan. * Ini menawarkan desain yang terpisah karena perangkat dan server mudah dipisahkan. Ideal untuk komunikasi satu-ke-banyak yang terdistribusi dan aplikasi yang terpisah. * Sebuah perangkat penerbit dapat mengirim data ke server kapan saja, apa pun statusnya. * Dilengkapi dengan fungsi LWT (wasiat terakhir) untuk memberi tahu para pihak tentang terputusnya koneksi klien secara abnormal. * Mengandalkan TCP/IP untuk Tugas komunikasi dasar. * Dirancang untuk mengirimkan Pesan sesuai dengan templat “maksimum sekali”, “minimum sekali”, dan “tepat sekali”. ### Kekurangan: * MQTT tidak dapat mendukung streaming video. * Masalah dengan latensi. * Keamanan tidak terintegrasi bawaan. MQTT tidak terenkripsi. Sebagai gantinya, MQTT menggunakan TLS/SSL (Keamanan Lapisan Transportasi/Keamanan Lapisan Soket Aman) untuk enkripsi terkait Keamanan. * Broker terpusat dapat menjadi titik kegagalan karena koneksi klien dengan broker selalu terbuka. * 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 Armada yang lebih cerdas yang meningkatkan optimalisasi Armada, keselamatan Supir, dan menurunkan biaya Bahan bakar. Mode transportasi baru yang menggunakan drone juga mengubah cara kita mengangkut barang. Konektivitas antara perangkat seluler yang digunakan oleh operator, informasi telemetri langsung dari kendaraan, dan integrasi ke dalam sistem Penjadwalan dan perutean sisi belakang memberikan visibilitas yang diperlukan untuk meningkatkan operasi Armada secara keseluruhan. * Data sensor lingkungan. MQTT mendukung model pengiriman Pesan “tidak lebih dari satu kali”. Dalam jaringan dengan cakupan wilayah yang sebagian atau latensi tinggi, ini berarti bahwa informasi dapat hilang atau terduplikasi. 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 merupakan 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 indikator kinerja saat ini yang terjamin ke tim lokal bahkan sebelum informasi ini sampai ke pusat pemrosesan data. Dalam situasi seperti itu, pengiriman Pesan “setidaknya sekali” menjamin bahwa penanda yang sesuai akan diperhatikan oleh spesialis yang diperlukan secara tepat waktu, bahkan jika pesan itu datang sebagai duplikat. Ini penting untuk komunikasi mesin-ke-mesin dengan prioritas yang lebih tinggi. * Sistem penagihan: Ada Pesan yang bahkan lebih diprioritaskan dan akurat yang perlu ditangani dengan benar. Dalam situasi bisnis ketika duplikasi catatan tidak dapat diterima, termasuk dalam sistem penagihan, bendera 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 antar ponsel, tetapi juga karena protokol ini memungkinkan Pesan dikirim secara efisien dalam milidetik, meskipun koneksi internet tidak konsisten di seluruh dunia. ## 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 berfungsi dengan Navixy ### Konfigurasi perangkat MQTT Xirgo & BCE Untuk mengonfigurasi perangkat Xirgo & BCE agar bekerja dengan MQTT: * Di 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 AS, port 1883. * Dan tambahkan pengguna bawaan di **Keamanan MQTT** -> **Otorisasi**\ ![MQTT device configuration](https://3546701789-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FIgDb43gtyXcm1Av4h1np%2Fuploads%2Fgit-blob-197f3834a584ce60ef3ef825d645d2e490e2b1b7%2Fimagen-20231019-231034.png?alt=media) ### Konfigurasi perangkat MQTT Globalmatix Untuk mengonfigurasi perangkat Globalmatix agar bekerja dengan MQTT: * Tentukan server port 1883 untuk EU dan port 1883 untuk AS * **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 AS * **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 by asking a question. Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters: ``` 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 what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case. 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.