MQTT köprüleme (bridging), seçilen topic'lerdeki mesajların bir broker'dan diğerine otomatik olarak akması için iki broker'ı birbirine bağlar. Bu rehberin sonunda bir bridge'in ne zaman mantıklı olduğunu, topic yeniden eşleme ve döngü önlemenin nasıl çalıştığını anlayacak; yerel verileri bir bulut broker'a ileten çalışan bir Mosquitto bridge yapılandırmasına ve bir Node-RED alternatifine sahip olacaksınız.
MQTT Köprüleme Gerçekte Ne Yapar
Bridge özel bir protokol değildir. Bir broker (veya yardımcı bir program) başka bir broker'a sıradan bir MQTT client bağlantısı açar, bir tarafta abone olur ve diğer tarafta yeniden yayınlar. Uzak broker açısından bridge, kullanıcı adı, parolası ve client ID'si olan herhangi bir client'tır.
Bu ayrıntı, onu nasıl kuracağınız açısından önemlidir. ConnectMQ dahil birçok barındırılan broker kendisi dışa doğru bir bridge çalıştırmaz. Bunun yerine bridge'i uçta (edge) çalıştırırsınız: Tesisteki bir Mosquitto örneği veya bir gateway üzerindeki bir Node-RED akışı, bulut broker'a client olarak dışarıya doğru bağlanır. Tesisin yalnızca 8883 portunda giden erişime ihtiyaç duyması nedeniyle bu, güvenlik duvarı açısından da daha dostane yöndür.
Köprülemenin tipik nedenleri:
- Yerel özerklik. PLC adaptörleri, HMI'lar ve kontrolörler internet bağlantısı kopsa bile tesis ağındaki bir broker ile konuşmaya devam eder.
- Seçici dışa aktarım. Her ham sinyal değil, yalnızca toplanmış veya onaylanmış topic'ler tesisten çıkar.
- Daha az bulut bağlantısı. Yüzlerce yerel cihaz tek bir üst akış bağlantısını paylaşır; bu da sizi bağlantı kotalarının içinde tutar.
- İsim alanı eşleme.
line4/press/tempgibi yerel topic'ler,acme/izmir/line4/press/tempgibi küresel olarak benzersiz bulut topic'lerine dönüşür.
Köprüleme Topolojileri
| Topoloji | Açıklama | Uygun olduğu durum | Dikkat edilmesi gereken |
|---|---|---|---|
| Uçtan buluta (out) | Yerel broker seçilen topic'leri yukarı iter | Telemetri, dashboard'lar, historian'lar | Kesintiler sırasında tamponlama |
| Buluttan uca (in) | Bulut komutları tesise iner | Ayar noktaları, yapılandırma, OTA tetikleyicileri | Kimin komut verebileceğini yetkilendirmek |
| Çift yönlü | Ayrı topic ağaçlarında her iki yön | Tam uzaktan işletim | Mesaj döngüleri |
| Hub and spoke | Çok sayıda tesis tek bir merkezi broker'a köprülenir | Çok tesisli Unified Namespace | Tesisler arası topic çakışmaları |
Hub-and-spoke deseni birçok Unified Namespace ve Sparkplug B tasarımının omurgasıdır: Her tesis kendi yerel broker'ına sahiptir ve buluttaki kurumsal topic ağacına bir dal katkısında bulunur.
Seçenek 1: Bulut Broker'a Mosquitto Bridge
Eclipse Mosquitto'nun mosquitto.conf içinde yapılandırılan yerleşik bir bridge özelliği vardır. Aşağıdaki örnek, tesis cihazları için 1883 portunda yerel bir broker çalıştırır ve portalda oluşturulan kimlik bilgileriyle 8883 üzerinden TLS ile bir ConnectMQ broker'a köprüler.
# /etc/mosquitto/conf.d/bridge-connectmq.conf
# --- Tesis ağındaki cihazlar için yerel dinleyici ---
listener 1883
# Üretimde password_file ile sıkılaştırın
allow_anonymous true
# --- ConnectMQ'ya (bulut) bridge ---
connection connectmq-cloud
address broker.connectmq.com:8883
bridge_protocol_version mqttv311
bridge_capath /etc/ssl/certs
bridge_insecure false
remote_clientid YOUR_CLIENT_ID
remote_username YOUR_USERNAME
remote_password YOUR_PASSWORD
# QoS 1 mesajlarının kısa yeniden bağlanmalarda korunması için uzak oturumu tut
cleansession false
keepalive_interval 60
restart_timeout 5 60
# Uzak broker Mosquitto değil: özel bridge bayrağını kullanma
try_private false
notifications false
# Üst bağlantı koptuğunda yerel tamponlama
max_queued_messages 10000
# topic <pattern> <direction> <qos> <local-prefix> <remote-prefix>
# Yerel plant/line4/... -> bulut acme/izmir/line4/...
topic # out 1 plant/ acme/izmir/
# Bulut acme/izmir/cmd/... -> yerel cmd/...
topic # in 1 cmd/ acme/izmir/cmd/
Topic satırları şöyle çalışır: Mosquitto deseni (#) alır, yerel aboneliği oluşturmak için başına yerel öneki ekler (plant/#) ve iletirken yerel öneki uzak önekle değiştirir. plant/line4/press/temp üzerindeki yerel bir mesaj bulutta acme/izmir/line4/press/temp olarak görünür. in satırı komutlar için bunun tersini yapar.
Önemli ayarlarla ilgili notlar:
remote_clientid, kimlik bilgilerinizle birlikte verilen client ID olmalıdır. Broker client ID'leri kimlik bilgilerine bağlar; bu yüzden rastgele bir kimlik reddedilir.try_private false. Mosquitto'nun özel bridge bayrağı Mosquitto'dan Mosquitto'ya bir uzantıdır; diğer broker'lar bunu reddedebilir.notifications false. Aksi halde Mosquitto bridge durum mesajlarını$SYS/broker/connection/...topic'lerine yayınlar; Mosquitto olmayan bir uzak broker bunları kabul etmeyebilir.bridge_capath. Sistem CA deposunu gösterir. Broker, standart Linux dağıtımlarında bu depoda bulunan bir Let's Encrypt sertifikası sunar.max_queued_messages. Üst bağlantı koptuğunda yerel broker'ın kaç mesaj tamponlayacağını sınırlar. Bunu kesinti toleransınıza ve diskinize göre boyutlandırın.
Mosquitto'yu yeniden başlatın ve günlüğünde Connecting bridge connectmq-cloud ve ardından başarılı bir bağlantı olup olmadığını izleyin. Başarısız olursa CONNACK kodunu içeren günlük satırı sorunun kimlik bilgilerinden mi TLS'ten mi kaynaklandığını söyler.
Bridge'i uçtan uca test edin
# Dizüstü bilgisayarda: bulut tarafını izleyin
mosquitto_sub -h broker.connectmq.com -p 8883 --capath /etc/ssl/certs \
-u YOUR_USERNAME -P YOUR_PASSWORD -i YOUR_OTHER_CLIENT_ID \
-t "acme/izmir/#" -v
# Tesis ağında: yerel broker'a yayın yapın
mosquitto_pub -h 192.168.10.5 -p 1883 -i press-sim-01 \
-t "plant/line4/press/temp" -m "78.2" -q 1
Bulut abonesinde acme/izmir/line4/press/temp 78.2 görmelisiniz. Dizüstü bilgisayarın kendine ait bir kimlik bilgisi setine ihtiyaç duyduğunu unutmayın; iki bağlantı tek bir client ID'yi paylaşamaz. Kimlik bilgisi gerektirmeyen bir deneme için bridge'i 1883 portundaki genel MQTT test broker'ı'na yönlendirin, kullanıcı adı ve parola satırlarını kaldırın, benzersiz bir remote_clientid kullanın ve connectmq/demo/b7e2/ gibi bir uzak önek kullanın (genel veriler herkese görünür).
Seçenek 2: Bridge Olarak Node-RED
Tesiste zaten Node-RED çalışıyorsa ikinci bir broker sürecine hiç ihtiyacınız olmayabilir. İki MQTT config düğümü içeren bir akış bridge görevi görür ve size mesajları filtreleyebileceğiniz, yeniden adlandırabileceğiniz ve dönüştürebileceğiniz bir yer sağlar.
- Yerel broker için bir broker config'i (örneğin
192.168.10.5:1883) kullanan ve QoS 1 ileplant/#topic'ine abone olan birmqtt indüğümü ekleyin. - Topic'leri yeniden eşlemek ve dışa aktarmak istemediğiniz her şeyi atmak için bir
functiondüğümü ekleyin. - İkinci bir broker config'i kullanan bir
mqtt outdüğümü ekleyin: sunucubroker.connectmq.com, port 8883, "Use TLS" etkin, portaldaki kullanıcı adınız, parolanız ve client ID'nizle.
// Function düğümü: yerel topic'leri bulut isim alanına eşle
const LOCAL_PREFIX = "plant/";
const REMOTE_PREFIX = "acme/izmir/";
if (!msg.topic.startsWith(LOCAL_PREFIX)) {
return null; // beklenmeyen topic'leri yok say
}
// Örnek filtre: ham debug sinyallerini dışa aktarma
if (msg.topic.includes("/debug/")) {
return null;
}
msg.topic = REMOTE_PREFIX + msg.topic.slice(LOCAL_PREFIX.length);
msg.qos = 1;
return msg;
Aşağı inen komutlar için bir ayna yol ekleyin: Bulut config'inde acme/izmir/cmd/# topic'ine abone olan bir mqtt in, öneki cmd/ olarak yeniden yazan bir function düğümü ve yerel broker'a bir mqtt out. Node-RED MQTT eğitimi config düğümlerini ve TLS ayarlarını ayrıntılı olarak ele alır; resmi Node-RED belgeleri ise her MQTT düğümü seçeneğini listeler.
Ödünleşim şudur: Node-RED, bir broker'ın yapabildiği gibi diske tamponlama yapmaz. Üst bağlantı koptuğunda, kendi kuyruklamanızı eklemediğiniz sürece akıştan geçen mesajlar kaybolur. Store-and-forward gerektiğinde Mosquitto daha iyi seçimdir; mantık gerektiğinde ise Node-RED kazanır.
Mesaj Döngülerini Önlemek
Çift yönlü bridge'ler döngü oluşturabilir: Bir mesaj yukarı çıkar, aşağı yönlü kuralla eşleşir, geri gelir, tekrar yukarı çıkar. Sizi güvende tutan kurallar:
- Yukarıdaki gibi her yön için ayrık topic ağaçları kullanın (
plant/dışarı gider,cmd/içeri gelir). #topic'ini asla aynı öneklerle her iki yönde köprülemeyin.- MQTT 5 kurulumlarında No Local abonelik seçeneği bir client'ın kendi yayınlarını almasını engeller; bu, bridge aynı bağlantı üzerinde hem abone olup hem yayın yaptığında yardımcı olur.
- Üretim trafiğini etkinleştirmeden önce tek bir mesajla test edin ve her iki tarafı izleyin.
Sorun Giderme Kontrol Listesi
| Belirti | Olası neden | Çözüm |
|---|---|---|
| CONNACK not authorized | Yanlış kimlik bilgileri veya client ID | Üç değerin hepsini portaldan kopyalayın |
| Bağlanırken TLS hatası | CA deposu eksik veya yol yanlış | ca-certificates kurun, bridge_capath değerini kontrol edin |
| Bridge bağlanıp sonra kopuyor | Başka yerde kullanılan yinelenen client ID | Her client'a kendi kimlik bilgisi setini verin |
| Topic'ler öneksiz görünüyor | Topic satırı önekleri yer değiştirmiş | Sıra önce yerel önek, sonra uzak önektir |
| Kesintiden sonra veri boşlukları | Kuyruk çok küçük veya QoS 0 | QoS 1 kullanın ve max_queued_messages değerini artırın |
| Mesajlar sonsuz yankılanıyor | Çakışan in/out kuralları | Her yön için ayrı ağaçlar |
Bridge'leriniz için Bir Bulut Uç Noktası Seçmek
Bulut tarafı sıkıcı olmalıdır: her zaman açık, varsayılan olarak TLS'li ve tesis başına bir üst akış bağlantısının yanı sıra dashboard'larınızı ve servislerinizi kabul edebilen. Bir yönetilen MQTT broker yama ve sertifika işlerini ortadan kaldırır; bulut MQTT broker rehberi ise barındırma ödünleşimlerini adım adım anlatır. Bu yapı taşlarında yeniyseniz yeni başlayanlar için MQTT eğitimi ve yayınla/abone ol modeli bu yazıya iyi birer eşlikçidir.
Tesislerinizi ConnectMQ'ya Köprüleyin
app.connectmq.com adresinde kredi kartı gerektirmeden ücretsiz bir Serverless broker oluşturun, ardından oluşturulan kullanıcı adını, parolayı ve client ID'yi Mosquitto bridge'inize veya Node-RED config düğümünüze yapıştırın. ConnectMQ'nun canlı topic gezgini, köprülenen topic'lerin gelişini gerçek zamanlı gösterir; böylece daha fazla tesis bağlamadan önce eşlemeyi doğrulayabilirsiniz.
Sık Sorulan Sorular
ConnectMQ'nun yerleşik bir bridge'i var mı?
Hayır. Uçta, broker'a TLS üzerinden normal bir client olarak bağlanan Mosquitto, Node-RED veya başka bir MQTT client'ı çalıştırarak ona köprüleme yaparsınız.
User properties gibi MQTT 5 özelliklerini köprüleyebilir miyim?
MQTT 5 ile köprüleme yapmak için Mosquitto'da bridge_protocol_version mqttv50 ayarlayın. Her iki broker'ın da MQTT 5'i desteklediğini kontrol edin ve güvendiğiniz özelliklerin iletildiğini test edin.
Bir bridge kaç bağlantı kullanır?
Bir Mosquitto bridge, üzerinden kaç yerel cihaz yayın yaparsa yapsın uzak broker'a tek bir bağlantı kullanır. Bir Node-RED bridge ise broker config düğümü başına bir bağlantı kullanır.
İnternet bağlantısı koptuğunda verilere ne olur?
Bir Mosquitto bridge mesajları max_queued_messages sınırına kadar yerel olarak kuyruğa alır ve bağlantı geri geldiğinde iletir. Düz Node-RED akışları, siz eklemediğiniz sürece tamponlama yapmaz.
