Menjembatani Modbus RTU ke MQTT berarti mengambil nilai register yang dipaparkan sebuah perangkat lapangan serial melalui bus RS-485 dan mempublikasikannya, sebagai pesan terstruktur, ke broker MQTT yang dilanggani oleh SCADA, platform cloud, atau stack analitik Anda. Gateway menjalankan dua tugas sekaligus: ia bertindak sebagai master Modbus yang melakukan polling slave pada jadwal tetap, dan ia bertindak sebagai klien MQTT yang mengubah setiap hasil polling menjadi payload pada sebuah topik. Panduan ini menelusuri setiap keputusan konfigurasi, dari parameter jalur serial hingga TLS, menggunakan gateway SRT-MGATE-1210 dari SURIOTA sebagai contoh nyata.
Mengapa Jembatan Protokol Sama Sekali Diperlukan
Modbus RTU adalah protokol request-response pada bus serial bersama. Sebuah master harus secara eksplisit melakukan polling setiap slave, satu transaksi pada satu waktu, dan tidak ada konsep perangkat mendorong data atas inisiatifnya sendiri maupun topologi publish-subscribe. MQTT adalah kebalikannya: protokol publish-subscribe ringan yang dirancang untuk distribusi event many-to-many melalui TCP/IP (biasanya port 1883 tanpa enkripsi, atau 8883 dengan TLS). Untuk dasar-dasar broker, desain topik, dan tingkat QoS, lihat panduan pendamping kami tentang MQTT untuk IoT industri; di sini kami berfokus pada konfigurasi gateway yang menghasilkan pesan-pesan tersebut. Gateway merekonsiliasi kedua dunia ini. Ia mempertahankan loop polling deterministik di sisi serial dan menerjemahkan nilai yang ditangkap menjadi publish asinkron di sisi jaringan. Jika Anda masih memutuskan antara Modbus serial dan Ethernet di sisi lapangan, penjelasan kami tentang Modbus RTU vs Modbus TCP membahas trade-off-nya secara rinci.
Langkah 1: Atur Parameter Jalur Serial
Setiap slave pada satu segmen RS-485 harus menggunakan parameter serial yang identik atau bus tidak akan berkomunikasi. Konfigurasikan port serial gateway agar sama persis dengan perangkat lapangan:
- Baud rate: salah satu dari nilai standar (9600, 19200, 38400, 57600, 115200). 9600 dan 19200 adalah default yang paling umum untuk meter dan sensor.
- Data bit, paritas, stop bit: framing Modbus RTU yang umum adalah 8 data bit dengan paritas genap dan 1 stop bit (8E1). Ketika paritas tidak digunakan, spesifikasi mensyaratkan 2 stop bit (8N2) untuk mempertahankan frame karakter 11-bit.
- Alamat slave: 1 hingga 247 adalah unit ID yang valid; 0 adalah alamat broadcast dan tidak pernah di-polling untuk meminta respons.
Hormati pula batas fisik standar EIA/TIA-485-A: satu segmen mendukung hingga 32 unit load dan kabel sepanjang kira-kira 1200 m pada baud rate yang lebih rendah, dengan satu resistor terminasi (biasanya 120 ohm) di tiap ujung jauh trunk. Pengkabelan yang buruk adalah penyebab tunggal paling umum dari timeout yang intermiten, jadi jika Anda melihat error CRC tinjau panduan kami tentang pengkabelan dan kegagalan terminasi RS-485.
Langkah 2: Definisikan Peta Register dan Polling
Selanjutnya, beri tahu gateway apa yang harus dibaca. Setiap entri polling menentukan alamat slave, function code Modbus, register awal, jumlah, dan cara mendekode raw word 16-bit menjadi nilai teknik. Empat data model standar dipetakan ke function code sebagai berikut: Read Coils (01), Read Discrete Inputs (02), Read Holding Registers (03), dan Read Input Registers (04). Holding register (function 03) membawa sebagian besar pengukuran analog. Jika tata letak register perangkat Anda kurang jelas, artikel pendamping tentang pemetaan register Modbus menjelaskan offset pengalamatan dan tipe data.
Perhatikan dengan cermat lebar data dan urutan word. Sebuah float 32-bit atau akumulator kWh menempati dua register 16-bit berurutan, dan vendor berbeda-beda apakah word tinggi yang lebih dulu (big-endian) atau word rendah yang lebih dulu (little-endian atau word-swapped). Mengatur urutan word yang salah menghasilkan nilai yang tampak masuk akal tetapi skalanya kacau, jadi selalu validasi terhadap layar perangkat saat commissioning.
Langkah 3: Rancang Struktur Topik MQTT
Sebuah topik adalah string UTF-8 hierarkis dengan level yang dipisahkan garis miring. Hierarki yang disiplin dan deskriptif-diri membuat langganan dan kontrol akses jauh lebih mudah di kemudian hari. Pola yang praktis adalah site/area/device/measurement, misalnya plant1/utility/meter01/voltage. Hindari garis miring di awal dan hindari karakter wildcard + dan # di dalam topik yang dipublikasikan (keduanya dicadangkan untuk subscriber). Tabel di bawah menunjukkan bagaimana sekumpulan kecil register dari power meter PM1611-WD SURIOTA akan dipetakan ke bus dan ke MQTT.
| Slave | Function | Register | Tipe | Pengukuran | Topik MQTT |
|---|---|---|---|---|---|
| 1 | 04 (Input) | 0x0000 | uint16, /10 | Tegangan L-N (V) | plant1/utility/meter01/voltage |
| 1 | 04 (Input) | 0x0006 | uint16, /100 | Arus (A) | plant1/utility/meter01/current |
| 1 | 04 (Input) | 0x000C | int16, /1000 | Faktor Daya | plant1/utility/meter01/pf |
| 1 | 03 (Holding) | 0x0100 | uint32, /1 | Energi Aktif (kWh) | plant1/utility/meter01/energy |
| 2 | 04 (Input) | 0x0001 | int16, /10 | Suhu (degC) | plant1/utility/thm01/temperature |
| 2 | 04 (Input) | 0x0002 | uint16, /10 | Kelembapan (%RH) | plant1/utility/thm01/humidity |
Baris suhu dan kelembapan di sini berasal dari sensor Modbus THM-30MD SURIOTA yang berbagi bus yang sama, yang persis merupakan jenis segmen perangkat campuran yang memang dirancang untuk ditangani oleh sebuah gateway.
Langkah 4: Rancang Payload JSON
Anda dapat mempublikasikan satu nilai per topik sebagai angka telanjang, tetapi satu objek JSON per perangkat biasanya lebih mudah dikonsumsi karena ia menggabungkan timestamp, flag kualitas, dan semua pengukuran dalam satu pesan atomik. Jaga agar key tetap pendek dan stabil, dan sertakan timestamp UTC agar sistem hilir tidak terpaksa mempercayai jam mereka sendiri. Payload per perangkat yang umum terlihat seperti ini:
{
"ts": "2026-06-09T08:30:00Z",
"device": "meter01",
"status": "ok",
"data": {
"voltage": 229.8,
"current": 12.34,
"pf": 0.97,
"energy_kwh": 184523
}
}
Field status itu penting. Ketika sebuah slave tidak menjawab atau mengembalikan exception Modbus, jangan diam-diam membuang pembacaan tersebut. Publikasikan payload dengan "status": "timeout" atau error eksplisit sehingga konsumen dapat membedakan nilai usang dari nilai nol. Memetakan exception secara bersih adalah separuh dari integrasi yang tangguh, dan tabel di bawah mencantumkan kode standar yang mungkin diterima gateway dalam frame respons.
| Kode | Nama | Penyebab Umum |
|---|---|---|
| 01 | Illegal Function | Slave tidak mendukung function code yang diminta |
| 02 | Illegal Data Address | Alamat register di luar jangkauan untuk perangkat tersebut |
| 03 | Illegal Data Value | Jumlah atau nilai di luar batas yang diizinkan |
| 04 | Slave Device Failure | Error yang tidak dapat dipulihkan di dalam slave |
| 05 | Acknowledge | Request diterima, pemrosesan panjang sedang berlangsung |
| 06 | Slave Device Busy | Slave sedang sibuk dengan perintah panjang, coba lagi nanti |
| 0B | Gateway Target Failed to Respond | Tidak ada balasan dari perangkat yang dialamatkan di balik sebuah gateway |
Langkah 5: Pilih QoS dan Interval Publish
MQTT menawarkan tiga tingkat quality of service. QoS 0 (at most once) bersifat fire-and-forget tanpa acknowledgement, QoS 1 (at least once) menjamin pengiriman tetapi dapat menduplikasi, dan QoS 2 (exactly once) menjamin pengiriman tunggal melalui handshake empat langkah. Untuk telemetri periodik yang dipublikasikan ulang setiap beberapa detik, QoS 1 biasanya merupakan titik ideal: Anda menoleransi duplikat sesekali tetapi tidak pernah kehilangan pembacaan. Cadangkan QoS 2 untuk event yang tidak boleh terduplikasi, seperti acknowledgement perintah. Tulisan kami yang lebih mendalam tentang desain topik dan QoS MQTT membahas lebih jauh retained message, Last Will and Testament, dan perilaku clean session.
Atur interval publish agar sesuai dengan fisika dari apa yang Anda ukur, bukan dengan kemampuan maksimum yang dapat ditanggung bus. Energy meter berubah lambat, jadi interval 5 hingga 30 detik sudah lebih dari cukup; tren getaran atau tekanan mungkin memerlukan 1 detik. Ingat bahwa bus serial adalah bottleneck-nya: pada 9600 baud setiap transaksi memakan puluhan milidetik, jadi melakukan polling 30 register pada 10 slave setiap detik itu realistis, tetapi melakukan polling ratusan pada laju sub-detik tidak. Periode loop polling gateway harus selalu lebih panjang dari jumlah seluruh waktu transaksi ditambah jeda antarframe.
Langkah 6: Amankan Koneksi
Jangan pernah mengirim koneksi broker plaintext ke produksi. Konfigurasikan gateway sebagai berikut:
- TLS: sambungkan pada port 8883 dengan sertifikat CA agar klien memverifikasi broker. Gunakan mutual TLS (sertifikat klien) jika broker mendukungnya.
- Autentikasi: username dan password unik per gateway, jangan pernah kredensial bersama, sehingga perangkat yang disusupi dapat dicabut tanpa mengganggu seluruh fleet.
- Otorisasi: batasi ACL broker tiap gateway hanya pada prefix topik yang dimilikinya, misalnya
plant1/utility/#untuk publish dan tidak ada apa pun untuk subscribe kecuali jika ia menerima perintah.
Di sisi serial, lindungi jalur RS-485 itu sendiri. Rute luar ruangan yang panjang terpapar surge dan perbedaan potensial tanah, dan di situlah surge protector RS-485 inline serta isolasi yang tepat membuktikan kegunaannya. Disiplin pengkabelan ini adalah bagian dari setiap proyek integrasi sistem dan IoT industri yang dikelola dengan baik, di mana gateway hanyalah satu mata rantai dalam rantai yang lebih panjang dari sensor ke dashboard.
Daftar Periksa Commissioning
- Pastikan parameter serial sama dengan setiap slave dan bahwa terminasi serta biasing sudah benar.
- Lakukan polling satu register secara manual dan bandingkan dengan layar perangkat untuk memverifikasi penskalaan dan urutan word.
- Berlangganan pohon topik gateway dengan klien uji dan konfirmasi bentuk payload serta timestamp.
- Paksa terjadinya timeout (cabut salah satu slave) dan konfirmasi field status melaporkannya alih-alih mempublikasikan data usang.
- Aktifkan TLS dan autentikasi, lalu verifikasi ulang seluruh jalur dari ujung ke ujung.
Pertanyaan yang Sering Diajukan
Sebaiknya saya mempublikasikan satu topik per nilai atau satu objek JSON per perangkat?
Satu objek JSON per perangkat umumnya lebih disukai karena mengelompokkan pengukuran terkait dengan timestamp dan flag kualitas bersama ke dalam satu pesan atomik, yang menyederhanakan penyelarasan waktu di hilir. Gunakan topik per nilai hanya ketika konsumen berlangganan pengukuran individual secara independen atau ketika ukuran payload harus seminimal mungkin.
Tingkat QoS mana yang terbaik untuk telemetri Modbus melalui MQTT?
QoS 1 adalah default praktis untuk telemetri periodik. Ia menjamin broker menerima setiap pembacaan setidaknya sekali sambil menjaga overhead tetap rendah. QoS 2 menambahkan handshake empat arah yang lebih lambat dan hanya layak digunakan untuk pesan yang tidak boleh terduplikasi, seperti acknowledgement kontrol.
Seberapa cepat gateway dapat melakukan polling Modbus RTU dan publish?
Bus serial menentukan batas atasnya. Pada 9600 baud satu transaksi memakan puluhan milidetik, sehingga total waktu loop adalah jumlah seluruh transaksi ditambah jeda antarframe. Atur interval publish lebih panjang dari loop tersebut dan sesuaikan dengan seberapa cepat besaran yang diukur benar-benar berubah, bukan dengan maksimum bus.
Bisakah satu gateway menangani tipe perangkat berbeda pada bus yang sama?
Bisa. Selama semua perangkat berbagi parameter serial yang sama dan memiliki alamat unik (1 hingga 247), gateway melakukan polling kumpulan campuran meter dan sensor serta memetakan setiap blok register ke topik dan payload-nya sendiri, persis seperti yang ditunjukkan pada tabel pemetaan di atas.