Inggris
Tionghoa
Spanyol
Rusia
Portugis
Prancis
Jerman
Thailand
Vietnam
Arab
Italia
Turki
Polandia
Jepang
Kegagalan koneksi gateway MQTT harus diselidiki pada tahap pertama yang gagal: pencarian tujuan, koneksi jaringan, TLS jika diperlukan, penerimaan broker, atau izin pesan. Mengubah topik tidak memperbaiki kegagalan jabat tangan TLS. Simpan galat klien dan log broker terkait agar uji berikutnya menangani tahap yang benar.
Pastikan apa yang dijalankan gateway terpasang
Perangkat gateway METRAVON TG451 mencantumkan MQTT dalam fungsi perangkat lunaknya, tetapi mode firmware dan desain pesan platform yang diperlukan tetap harus dipastikan. Catat versi firmware, versi MQTT, transportasi, nama host broker, port layanan, dan identitas yang diberikan kepada instalasi ini.
Periksa spesifikasi layanan sebenarnya untuk TCP biasa, TLS, atau transportasi lain yang didukung. Jangan menyimpulkan port benar dari nilai bawaan yang diingat. Pastikan tujuan terkonfigurasi adalah titik akhir broker, bukan alamat konsol web atau rute penyeimbang beban untuk layanan berbeda.
Temukan kegagalan koneksi gateway MQTT pada log
| Hasil | Tahap terkait | Bukti berguna |
|---|---|---|
| Nama gagal | Pencarian tujuan belum menghasilkan alamat yang dapat digunakan. | Catat nama host, hasil resolver, dan jalur jaringan aktif tanpa mengubah kredensial. |
| Port gagal | Koneksi layanan yang diminta belum terbentuk. | Bandingkan upaya koneksi dengan catatan layanan penerima server dan firewall. |
| TLS gagal | Sesi aman belum terbentuk. | Simpan galat jabat tangan dan verifikasi waktu, nama host, serta materi sertifikat yang diperlukan. |
| Broker menolak | Server mengembalikan hasil koneksi MQTT. | Tafsirkan hasil berdasarkan versi protokol yang dinegosiasikan dan log broker. |
| Tanpa data berguna | Penerimaan koneksi belum menghasilkan keluaran aplikasi yang diharapkan. | Periksa izin topik, penanganan muatan, dan log catatan yang diterima platform. |
Perbaiki kepercayaan dan identitas tanpa melewatinya
Untuk TLS, pastikan jam gateway, validitas sertifikat, dan nama host. Otoritas sertifikat privat memerlukan konfigurasi kepercayaan yang sesuai. Jika TLS timbal balik diperlukan, pastikan sertifikat klien dan kunci privat cocok serta milik perangkat yang dimaksud.
Jangan mengunggah kunci privat ke tiket dukungan atau menonaktifkan verifikasi sertifikat agar galat menghilang. Minta rantai kepercayaan yang diharapkan dan setelan koneksi yang didukung dari pemilik layanan, lalu terapkan melalui proses konfigurasi yang diizinkan.
Identitas klien MQTT dan izin publikasi adalah persoalan terpisah. Broker dapat menerima koneksi sambil menolak operasi tidak berizin. Periksa topik tepat, huruf besar-kecil, dan kebijakan akun. Pada MQTT 3.1.1, ketika broker menerima koneksi baru menggunakan pengenal klien yang sudah terhubung, broker memutus klien yang ada. Dua gateway dengan pengenal itu dapat saling menggeser berulang saat menyambung kembali. Bandingkan pengenal klien dan waktu koneksi broker sebelum mengubah antena atau setelan pemeliharaan sesi.
Pisahkan publikasi berhasil dari pengukuran benar
Broker mengangkut muatan; broker tidak secara bawaan memvalidasi makna rekayasa nilai sensor. Bandingkan pesan tertangkap dengan skema yang disepakati dan bacaan sumber yang diperiksa. Verifikasi satuan, penskalaan, identitas sumber, dan waktu akuisisi sebelum mendiagnosis ketiadaan tren sebagai masalah konektivitas.
PUBACK QoS 1 memastikan penerima MQTT mengambil tanggung jawab atas pesan, bukan bahwa basis data akhir menyimpan pengukuran. QoS 1 dapat mengirim duplikat; QoS 2 mencegah pengiriman duplikat dalam pertukaran protokolnya, tetapi tidak menyertifikasi pemrosesan basis data di hilir. Periksa QoS yang didukung firmware terpasang serta layanan penerima, lalu tentukan cara aplikasi mengidentifikasi dan merekonsiliasi catatan berulang. Pesan yang dipertahankan bukan arsip deret waktu, dan adanya sesi bukan bukti semua pengukuran sebelumnya tetap tersedia.
Untuk sesi tidak stabil, bandingkan konfigurasi pemeliharaan sesi, gangguan jaringan, dan alasan penutupan sisi server. Tentukan perilaku percobaan ulang dan pemeliharaan sesi dari persyaratan layanan serta kondisi teramati. Siklus percobaan ulang agresif dapat menyembunyikan galat awal dan membebani tujuan.
Gunakan perbandingan klien terpisah hanya untuk menjawab pertanyaan tertentu
Klien uji yang disetujui pada jaringan sama dapat membantu membedakan keterjangkauan layanan dari masalah konfigurasi gateway. Berikan identitas terpisah dan topik uji yang diizinkan. Jangan menduplikasi identitas perangkat hidup atau menerbitkan nilai uji ke pengukuran produksi.
Catat titik akhir, transportasi, dan kelas kredensial yang diuji. Koneksi laptop berhasil melalui jaringan berbeda berguna sebagai bukti, tetapi tidak memverifikasi rute, jam, atau penyimpanan kepercayaan gateway.
Pertanyaan integrasi MQTT
T1. Haruskah topik diubah jika broker tidak pernah menerima sesi?
Selesaikan tahap koneksi yang gagal terlebih dahulu. Pemetaan topik telemetri normal relevan setelah penerimaan, meskipun fitur terkait koneksi dapat mempunyai persyaratan kebijakan sendiri. Gunakan hasil penolakan broker sebenarnya, bukan mengubah bidang yang tidak terkait.
T2. Apakah autentikasi berhasil membuktikan izin publikasi?
Tidak. Pastikan operasi yang diizinkan dan jalur topik akun yang tepat. Lalu periksa muatan yang diterima aplikasi hilir; izin transportasi dan validasi aplikasi berbeda.
T3. Apa yang harus disertakan dalam permintaan dukungan MQTT?
Kirim model dan firmware, versi protokol, transportasi, titik akhir, waktu galat, serta hasil klien/broker yang dibersihkan dari data sensitif. Sertakan contoh topik dan muatan dengan data sensitif disamarkan jika sesi bekerja tetapi data gagal. Jangan sertakan kata sandi, token, dan kunci privat.
Ringkasan
Diagnosis tahap koneksi yang gagal, lalu verifikasi izin pesan dan data rekayasa secara terpisah. Minta tinjauan konfigurasi MQTT METRAVON dengan galat tercatat dan spesifikasi layanan, bukan hanya tangkapan layar berstatus luring.
