İyi bir Mosquitto bridge yapılandırması, Raspberry Pi üzerindeki yerel bir broker'ın LAN'daki cihazlara hizmet vermeye devam ederken yalnızca seçtiğiniz topic'leri bir bulut broker'a aktarmasını sağlar. Bu eğitimde ConnectMQ'ya portal kimlik bilgileriyle TLS üzerinden bağlanan, her tesisin kendi ad alanına sahip olması için topic'leri yeniden eşleyen, komutları aşağı geri gönderen, internet kesintileri boyunca mesajları kuyruğa alan ve klasik mesaj döngüsünden kaçınan bir bridge kuracaksınız. Her seçenek açıklanıyor; böylece dosyayı körü körüne kopyalamak yerine ihtiyacınıza göre uyarlayabilirsiniz.
Mosquitto Bridge Nasıl Çalışır?
Bridge özel bir protokol değildir. Yerel Mosquitto broker uzak broker'a giden bir bağlantı açar ve sıradan bir MQTT istemcisi gibi davranır: yapılandırmasındaki topic satırlarına göre bir tarafta abone olur, diğer tarafta yeniden yayınlar. Bunun üç faydalı sonucu vardır:
- Gelen port gerekmez. Pi, bir tarayıcının bir web sitesine bağlanması gibi 8883 portu üzerinden dışarı bağlanır. Router'ınız kapalı kalır.
- Uzak broker'ın özel bir şeye ihtiyacı yoktur. Standartlara uyan her broker bir bridge'i kabul eder, çünkü yalnızca bir kullanıcı adı, parola ve client ID ile oturum açan bir istemci görür.
- Sınırı neyin geçeceğine siz karar verirsiniz. Tesisten yalnızca bir
topicsatırıyla eşleşen topic'ler çıkar ya da girer.
Bu kurulumda uzak taraf, yönetilen bir MQTT broker olan ConnectMQ'dur. Bridge, diğer her cihaz gibi portalda üretilen kimlik bilgileriyle kimlik doğrular. Yerel broker'ı henüz kurmadıysanız önce Raspberry Pi'ye Mosquitto kurulumu yazısını izleyin.
Sensors / PLC gateway / Node-RED (LAN)
| mqtt://pi:1883 (local users)
v
+---------------------------+
| Mosquitto on Raspberry Pi |
| bridge "connectmq" |
+---------------------------+
| mqtts://broker.connectmq.com:8883
| remote_username / remote_password / remote_clientid
v
+---------------------------+
| ConnectMQ cloud broker | dashboards, phones, other sites
+---------------------------+
Başlamadan Önce
- Mosquitto 2.0 çalıştıran ve en az bir kimlik doğrulamalı yerel dinleyicisi (listener) olan bir Raspberry Pi.
- Kimlik bilgilerine sahip bir bulut broker. Portalda kaydolun, bir plan seçin, bir broker oluşturun ve üretilen kullanıcı adını, parolayı ve client ID'yi kopyalayın. Client ID bu kimlik bilgilerine bağlıdır, bu yüzden bridge onu birebir kullanmalıdır.
- Topic adları için bir plan. Yerel topic'lerin bulutta nasıl görüneceğine karar verin.
site1/gibi bir tesis ön eki, birden fazla Pi'nin çakışmasını önler.
Hesap açmadan hızlı bir deneme için, kimlik bilgisi olmadan ve benzersiz herhangi bir client ID ile 1883 portu üzerinden herkese açık MQTT test broker'ına connectmq/demo/3c7d52/ gibi rastgele bir ön ek kullanarak bridge kurabilirsiniz. Oradaki her şey herkes tarafından okunabilir, bu yüzden yalnızca sahte veri kullanın.
Eksiksiz Mosquitto Bridge Yapılandırması
/etc/mosquitto/conf.d/bridge-connectmq.conf dosyasını oluşturun:
# ---- Bağlantı ----
connection connectmq
address broker.connectmq.com:8883
bridge_protocol_version mqttv311
try_private false
start_type automatic
restart_timeout 5 60
keepalive_interval 60
# ---- TLS ----
bridge_capath /etc/ssl/certs
bridge_insecure false
# ---- ConnectMQ portalından kimlik bilgileri ----
remote_clientid YOUR_CLIENT_ID
remote_username YOUR_USERNAME
remote_password YOUR_PASSWORD
# ---- Oturum ve kuyruk ----
cleansession false
local_clientid bridge-connectmq-local
# ---- Durum topic'i (uzak tarafta yayınlanır) ----
notifications true
notifications_local_only false
notification_topic site1/bridge/state
# ---- Topic eşleme ----
# Telemetri yukarı: yerel "sensors/#" -> uzak "site1/sensors/#"
topic sensors/# out 1 "" site1/
# Makine durumları yukarı, retained değerler korunur
topic machines/+/state out 1 "" site1/
# Komutlar aşağı: uzak "site1/cmd/#" -> yerel "cmd/#"
topic cmd/# in 1 "" site1/
Yeniden başlatın ve günlüğü izleyin:
sudo chmod 0640 /etc/mosquitto/conf.d/bridge-connectmq.conf
sudo chown root:mosquitto /etc/mosquitto/conf.d/bridge-connectmq.conf
sudo systemctl restart mosquitto
sudo journalctl -u mosquitto -f
Connecting bridge connectmq (broker.connectmq.com:8883) satırını ve ardından hiçbir hata görmemelisiniz. Dosya uzak parolayı içerdiği için izin değişikliği önemlidir.
Seçenek Seçenek
| Seçenek | Buradaki değer | Neden |
|---|---|---|
address |
broker.connectmq.com:8883 |
Bulut broker'ın TLS portu |
bridge_protocol_version |
mqttv311 |
Geniş destek; güncel Mosquitto sürümlerinde MQTT 5 bridge da mümkündür |
try_private |
false |
Mosquitto dışındaki broker'ların reddedebileceği, yalnızca Mosquitto'ya özgü bir bridge bayrağından kaçınır |
restart_timeout |
5 60 |
Yeniden bağlanma denemeleri arasında 5 sn'den 60 sn'ye kadar geri çekilir |
bridge_capath |
/etc/ssl/certs |
Sistem CA deposu broker'ın Let's Encrypt sertifikasını doğrular |
bridge_insecure |
false |
Ana bilgisayar adı doğrulamasını her zaman açık tutun |
remote_clientid |
Portal client ID'si | Verilen kimlik bilgileriyle eşleşmelidir |
cleansession |
false |
QoS 1 mesajlarının kesintilerde kuyruğa alınması için oturumları korur |
notifications |
true |
Bridge bağlandığında 1, koptuğunda (last will olarak) 0 yayınlar |
notification_topic |
site1/bridge/state |
Durumu kendi ad alanınızın içinde tutar |
topic Satırını Anlamak
Sözdizimi topic <pattern> <direction> <qos> <local-prefix> <remote-prefix> şeklindedir. Mosquitto dışarı aktarırken yerel bir topic'ten yerel ön eki kaldırır ve uzak ön eki ekler; in için tersini yapar. Boş bir yerel ön ek ("" olarak yazılır) ve site1/ uzak ön ekiyle:
- Yerel
sensors/boiler/temp, uzaktasite1/sensors/boiler/tempolur. - Uzak
site1/cmd/pump1/set, yereldecmd/pump1/setolur.
Uzak ön ekin eğik çizgiyle bittiğine dikkat edin. O olmadan site1sensors/... elde edersiniz; yapması kolay, fark etmesi zor bir hatadır.
Bridge Üzerinde QoS
Bir topic satırındaki QoS, bridge boyunca kullanılan en yüksek seviyedir. Pratik seçim QoS 1'dir: onaylarla teslimatı garanti eder ve QoS'u 1 ile sınırlayan ücretsiz Serverless planı dahil her planda desteklenir. QoS 2'yi yalnızca onu destekleyen bir plandaysanız ve veri yinelemelere gerçekten tahammül edemiyorsa kullanın. MQTT QoS seviyeleri makalesi bu ödünleşimleri ele alıyor.
İnternet Kesintileri Sırasında Kuyruk
cleansession false ile yerel broker, bağlantı koptuğunda bridge'in oturumunu korur ve QoS 1 mesajlarını onun için kuyruğa alır. Bağlantı geri geldiğinde birikmiş mesajlar buluta boşaltılır. Kuyruk, ana yapılandırmanızdaki max_queued_messages (ve isteğe bağlı olarak max_queued_bytes) ile sınırlanır. Onu kapsamak istediğiniz en uzun kesintiye göre boyutlandırın; SD kartlı bir Pi'de ölçülü tutun, çünkü kalıcı kuyruklar her otomatik kayıtta diske yazılır. QoS 0 mesajları kuyruğa alınmaz; bu da telemetriyi QoS 1 ile aktarmak için bir başka nedendir.
Bulut tarafının da kendi sınırlarını uyguladığını unutmayın. Uzun bir birikim tek seferde gelirse, plan bazlı kotaları ve flood koruması olan bir broker onu kısıtlayabilir; bu yüzden çok uzun kesintiler, çevrimdışı mesaj tamponlama rehberindeki gibi uygulama düzeyinde bir tamponla daha iyi yönetilir.
Bridge'i Uçtan Uca Test Etmek
Bulut tarafında abone olun. Herkese açık broker ile doğrudan mosquitto_sub kullanabilirsiniz; özel bir broker ile ikinci bir kimlik bilgisi seti ya da portalın tarayıcı içi MQTT istemcisini kullanın:
mosquitto_sub -h broker.connectmq.com -p 8883 --capath /etc/ssl/certs \
-u YOUR_USERNAME_2 -P YOUR_PASSWORD_2 -i YOUR_CLIENT_ID_2 \
-t 'site1/#' -v
Pi üzerinde yerel olarak yayınlayın:
mosquitto_pub -h localhost -u sensors -P 'sensors-password' -i t1 -q 1 \
-t sensors/boiler/temp -m 64.2
Bulut abonesi site1/sensors/boiler/temp 64.2 ve site1/bridge/state 1 yazdırır. Şimdi aşağı yönlü bağlantıyı test edin. Yerelde cmd/# topic'ine abone olun, ardından bulut tarafından site1/cmd/pump1/set topic'ine yayın yapın. Mesaj yerelde cmd/pump1/set olarak gelir.
Son olarak bir kesintiyi test edin: Pi'deki ağı durdurun (sudo nmcli networking off), yerelde birkaç QoS 1 mesajı yayınlayın, ağı yeniden etkinleştirin ve mesajların buluta ulaşmasını izleyin. Bağlantı koptuğu sürece bridge durum topic'i, broker tarafından bridge'in last will mesajı olarak teslim edilen 0 değerine geçer.
Mosquitto Bridge Yapılandırmanızda Döngülerden Kaçınmak
Döngü, dışarı aktarılan bir mesajın geri gelip yeniden dışarı aktarılmasıyla oluşur. En yaygın neden, aynı topic'ler üzerinde bir both kuralı ya da örtüşen in ve out desenleridir:
# Tehlikeli: site1/ altındaki her şey ileri geri seker
topic # both 1 "" site1/
Yönleri ayrı alt ağaçlarda tutun: telemetri ve durumlar out ile çıkar, komutlar farklı bir dal (cmd/) altında in ile girer. Gerçekten both gerekiyorsa, Mosquitto sürümünüz destekliyorsa no-local aboneliklerle MQTT 5 bridge'i tercih edin ve dikkatle test edin. # topic'ini hiçbir yönde ön eksiz olarak asla aktarmayın.
Birden Fazla Tesis, Tek Bulut Broker
Her Pi kendi kimlik bilgilerini ve kendi ön ekini (site1/, site2/, ...) alır. Panolar tüm tesisleri görmek için +/sensors/# topic'ine ya da tek bir tesis için tek bir ön eke abone olur. Her bridge'in kimlik bilgilerine bağlı benzersiz bir client ID'si olduğundan, bir tesisin erişimini iptal etmek diğerlerini asla etkilemez. Ücretli Serverless planları paylaşımlı abonelikler (shared subscriptions) ekler; bu, birden fazla bulut tüketicisinin birleşik akışı bölüşmesi gerektiğinde işe yarar. Endüstriyel tesisler daha da ileri gidip portalın algılayıp cihaz görünümünde gösterdiği enterprise/site/area/line/cell gibi ISA-95 tarzı bir hiyerarşi benimseyebilir.
Sorun Giderme
| Günlük mesajı veya belirti | Neden | Çözüm |
|---|---|---|
Connection Refused: not authorised |
Yanlış kimlik bilgileri veya client ID | Üçünü de portaldan yeniden kopyalayın |
certificate verify failed |
Eksik CA deposu veya yanlış saat | ca-certificates paketini kurun, NTP'yi timedatectl ile kontrol edin |
| Bridge bağlanıyor, hiçbir şey gelmiyor | Topic deseni veya ön ek uyuşmazlığı | Ön eklerdeki sondaki eğik çizgiyi unutmayın |
| Bağlantı birkaç saniyede bir kopuyor | Aynı client ID'yi kullanan başka bir istemci | Her bağlantı için bir client ID |
| Kesintilerde mesajlar kayboluyor | QoS 0 veya cleansession true |
QoS 1 ve cleansession false kullanın |
| Bridge'i etkinleştirince mesaj fırtınası | Örtüşen in/out kurallarından kaynaklanan döngü | Her yön için ayrı alt ağaçlar |
Pi'nizi ConnectMQ'ya Bağlayın
app.connectmq.com adresinde kredi kartı gerektirmeden ücretsiz bir Serverless broker oluşturun, üretilen kullanıcı adını, parolayı ve client ID'yi bridge dosyanıza yapıştırın ve tesisinizin topic'lerinin portalın canlı topic gezgininde belirmesini izleyin. Bu bridge'in etrafındaki daha geniş ağ geçidi tasarımı için IoT ağ geçidi olarak Raspberry Pi yazısını, Pi serisinin tamamı için ise Raspberry Pi MQTT eğitimini okuyun.
Sık Sorulan Sorular
ConnectMQ'nun Mosquitto için özel bir bridge özelliğine ihtiyacı var mı?
Hayır. Mosquitto bridge, portaldaki kullanıcı adı, parola ve client ID ile sıradan bir MQTT istemcisi olarak bağlanır; bu yüzden her plan çalışır.
Bridge'i MQTT 3.1.1 ile mi yoksa MQTT 5 ile mi kurmalıyım?
MQTT 3.1.1, bridge'ler için en basit ve en yaygın test edilmiş seçimdir. Bridge bağlantısında MQTT 5 özelliklerine ihtiyacınız varsa güncel Mosquitto sürümleri mqttv50 bridge'i destekler.
try_private neden false yapılmalı?
Etkinleştirildiğinde Mosquitto, Mosquitto'dan Mosquitto'ya bağlantılar için tasarlanmış standart dışı bir protokol bayrağıyla bir bridge olduğunu bildirir. Bunu kapatmak, bağlantıyı diğer broker'lar için tamamen standart tutar.
Bridge bir kesinti sırasında kaç mesajı kuyruğa alır?
cleansession false ile QoS 1 ve 2 mesajları için max_queued_messages ve max_queued_bytes ne kadarına izin veriyorsa o kadar. QoS 0 mesajları bağlantı koptuğu sürece atılır.
