> 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 Transport Telemetri Antrian Pesan (MQTT) telah digunakan selama bertahun-tahun, tetapi sekarang sangat relevan karena pertumbuhan eksplosif IoT: baik perangkat konsumen maupun industri menerapkan jaringan terdistribusi dan komputasi tepi, dan perangkat dengan transmisi data terus-menerus menjadi bagian dari kehidupan sehari-hari. Pertumbuhan intensif semacam 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 pipa minyak dalam kerangka 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 berjenis terbit dan berlangganan yang mengangkut Pesan antarperangkat. Protokol ini biasanya berjalan di atas TCP/IP; namun, protokol jaringan apa pun yang menyediakan koneksi dua arah yang terurut dan tanpa kehilangan dapat mendukung MQTT. Protokol ini dirancang untuk koneksi dengan lokasi jauh yang memerlukan "jejak kode kecil" atau memiliki bandwidth jaringan terbatas. Protokol ini adalah standar terbuka OASIS dan rekomendasi ISO (ISO/IEC 20922). Mengingat kondisi operasional, protokol ini dibuat kecil dan ringan. Ini ideal untuk perangkat dengan konsumsi daya rendah dan masa pakai baterai terbatas. Kini, ini mencakup ponsel cerdas, serta jumlah sensor dan Perangkat terhubung yang terus bertambah. Dengan demikian, MQTT telah menjadi protokol untuk mengalirkan data antara perangkat dengan daya CPU terbatas dan/atau masa pakai baterai terbatas, serta untuk jaringan dengan biaya mahal atau bandwidth rendah, stabilitas yang tidak dapat diprediksi, atau latensi tinggi. Itulah sebabnya MQTT dikenal sebagai protokol ideal untuk IoT. MQTT dibangun di atas protokol TCP/IP, tetapi ada cabang MQTT-SN untuk berjalan di atas Bluetooth, UDP, ZigBee, dan jaringan IoT lain selain TCP/IP. ## Cara kerjanya ### Model terbit dan berlangganan Ada 2 definisi utama dalam MQTT: broker MQTT dan klien MQTT. Broker MQTT adalah server yang menerima semua Pesan dari klien lalu meneruskan Pesan ke klien tujuan yang sesuai. Secara sederhana, broker berperan seperti kantor pos, MQTT tidak menggunakan alamat penerima yang dituju melainkan menggunakan baris subjek yang disebut “Topik”, dan siapa pun yang ingin salinan pesan itu akan berlangganan ke topik tersebut. 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). 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 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 pada satu topik dengan mengirimkan pesan dan topik ke broker. * Broker kemudian meneruskan pesan ke semua klien yang berlangganan ke topik itu. Karena Pesan MQTT diorganisasi 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, lalu 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 Protokol Kontrol Transmisi/Protokol Internet (TCP/IP) ke broker dengan menggunakan port standar atau port khusus yang ditentukan oleh operator broker. Saat membuat koneksi, penting untuk menyadari bahwa server mungkin melanjutkan sesi lama jika diberi identitas klien yang digunakan ulang. Port standar adalah 1883 untuk komunikasi tidak terenkripsi dan 8883 untuk komunikasi terenkripsi -- menggunakan Lapisan Soket Aman (SSL)/Keamanan Lapisan Transport (TLS). Selama negosiasi SSL/TLS, klien memvalidasi sertifikat server dan mengautentikasi server. Klien juga dapat memberikan sertifikat klien kepada broker selama negosiasi. Broker dapat menggunakan ini untuk mengautentikasi klien. Meskipun tidak secara khusus menjadi bagian dari spesifikasi MQTT, kini sudah lazim bagi broker untuk mendukung autentikasi klien dengan sertifikat sisi klien SSL/TLS. Karena protokol MQTT bertujuan menjadi protokol untuk perangkat IoT dengan sumber daya terbatas, SSL/TLS mungkin tidak selalu menjadi pilihan dan, dalam beberapa kasus, mungkin tidak diinginkan. Dalam situasi seperti itu, 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 seperti itu, nama pengguna dan kata sandi cukup dibiarkan kosong. ### Format pesan MQTT MQTT dianggap protokol ringan karena semua Pesan yang dimilikinya memiliki jejak kode kecil. Paket terdiri atas header tetap 2 byte + header variabel dan payload. Dalam 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 0. Byte kedua dari header tetap berisi panjang tersisa, yaitu panjang header variabel + panjang payload. Header variabel tidak ada pada 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 terdapat pada sebagian besar jenis paket. Pada akhirnya, paket dapat berisi payload. Payload juga bersifat opsional dan bervariasi sesuai jenis paket. Bidang ini biasanya berisi data yang sedang dikirim. Misalnya, untuk paket CONNECT, payload adalah ID klien dan 'nama pengguna dan kata sandi' jika tersedia. Dan untuk paket PUBLISH, payload adalah pesan yang akan diterbitkan. ### Kualitas layanan QoS merujuk pada kesepakatan antara pengirim pesan dan penerima pesan tersebut. Ini berfungsi sebagai fitur utama dalam MQTT, memberi klien kemampuan untuk memilih di antara tiga tingkat layanan. Ketiga tingkat QoS yang berbeda menentukan bagaimana konten dikelola oleh protokol MQTT. Meskipun tingkat QoS yang lebih tinggi lebih andal, tingkat tersebut memiliki persyaratan 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 konfirmasi. 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 pesan telah diterima dengan benar, dan broker tidak menyimpan pesan. Tingkat QoS ini juga dapat disebut sebagai paling banyak sekali, QoS0, atau kirim lalu lupakan. * Tingkat QoS kedua adalah layanan dengan konfirmasi. 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 mengirim konten asli lagi jika konfirmasi tidak diterima tepat waktu. Hal ini dapat menyebabkan pelanggan menerima beberapa salinan 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 percobaan ulang, pesan hanya akan dikirim 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) ## Keunggulan dan kekurangan ### Keunggulan: * MQTT tidak bergantung pada jenis paket. Payload protokol MQTT dapat membawa jenis data apa pun seperti biner, teks ASCII, dll. Penerima perlu menafsirkan dan mendekode sesuai format yang digunakan oleh pemancar. * MQTT menggunakan paket berukuran kecil dan dapat digunakan untuk aplikasi bandwidth rendah. * MQTT menawarkan konsumsi daya baterai yang lebih rendah. * MQTT adalah protokol yang andal karena menggunakan opsi QoS untuk menyediakan pengiriman terjamin. * Karena model terbit dan berlangganannya, MQTT bersifat skalabel. * MQTT menawarkan desain terpisah karena perangkat dan server mudah dipisahkan. Ideal untuk komunikasi terdistribusi satu-ke-banyak dan aplikasi terpisah. * Perangkat penerbit dapat mengirim data ke server kapan saja tanpa memandang statusnya. * Dilengkapi dengan fungsi LWT (wasiat terakhir) untuk memberi tahu pihak-pihak terkait tentang pemutusan koneksi klien yang tidak normal. * Bergantung pada TCP/IP untuk tugas komunikasi dasar. * Dirancang untuk mengirim Pesan sesuai dengan templat "paling banyak sekali", "paling sedikit sekali", dan "tepat sekali". ### Kekurangan: * MQTT tidak dapat mendukung streaming video. * Masalah latensi. * Keamanan tidak tersedia secara bawaan. MQTT tidak terenkripsi. Sebaliknya, MQTT menggunakan TLS/SSL (Keamanan Lapisan Transport/Lapisan Soket Aman) untuk enkripsi. * Broker terpusat dapat menjadi titik kegagalan karena koneksi klien dengan broker selalu terbuka. * MQTT tidak mendukung fitur lanjutan seperti kontrol aliran. ## Di mana MQTT dapat digunakan Karena aplikasi IoT kini diterapkan dalam skala besar, MQTT menjadi sorotan sebagai cara terbuka, sederhana, dan skalabel untuk menerapkan komputasi terdistribusi dan fungsionalitas IoT ke 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 optimasi Armada, Keselamatan Supir, dan menurunkan biaya Bahan bakar. Mode 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 backend menyediakan 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 parsial atau latensi tinggi, ini berarti bahwa informasi dapat hilang atau terduplikasi. Di area tempat sensor jarak jauh merekam dan mengirim data pada interval yang ditentukan, hal ini tidak menjadi masalah, karena pembacaan baru diterima secara teratur. Sensor di lingkungan terpencil biasanya merupakan perangkat berdaya rendah, yang menjadikan MQTT solusi ideal bagi sensor IoT dengan prioritas transfer data yang relatif rendah. * Data kesehatan mesin: untuk merespons masalah yang muncul dengan cepat dan mencegah waktu henti. Misalnya, pada pembangkit listrik tenaga angin, Anda memerlukan pengiriman terjamin indikator kinerja saat ini kepada 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 tepat waktu, meskipun pesan tersebut tiba sebagai duplikat. Ini penting untuk komunikasi mesin-ke-mesin dengan prioritas lebih tinggi. * Sistem penagihan: Ada Pesan yang bahkan lebih penting dan akurat yang perlu ditangani dengan benar. Dalam situasi bisnis ketika duplikasi catatan tidak dapat diterima, termasuk dalam sistem penagihan, bendera QoS transmisi "tepat sekali" berguna. Hal ini menghilangkan duplikasi atau kehilangan paket dalam 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 selama pengiriman pesan antarponsel, tetapi juga karena protokol ini memungkinkan pengiriman Pesan secara efisien dalam hitungan milidetik, meskipun koneksi internet tidak konsisten di seluruh dunia. ## Perangkat MQTT yang didukung 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 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](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 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.