Node-RED MQTT Bağlanmıyor: Sorun Giderme Rehberi

Node-RED MQTT bağlanmıyor sorunuyla uğraşıyorsanız node genellikle sarı bir "connecting" halkasında bekler veya connected ile disconnected arasında gidip gelir ve flow'unuzun geri kalanı sessizleşir. Bu rehber nedeni bulmanız için hızlı ve sıralı bir yol sunuyor: doğru log'ları okuyun, broker'a Node-RED dışından erişilebildiğini kanıtlayın, ardından durum yeşile dönene kadar port, TLS, hostname, client ID, kimlik bilgileri ve container ağı konularını sırayla ele alın.

Belirtileri Tanıyın

Bir mqtt in veya mqtt out node'unun altındaki durum ilk ipucunuzdur:

Son ikisine dikkat edin. Yeşil durum bağlantının çalıştığı anlamına gelir; bu yüzden doğrudan topic'lere geçin. "Bağlanmıyor" bildirimlerinin çoğu aslında abonelik sorunlarıdır.

Adım 1: Node-RED Log'unu Okuyun

Editör yalnızca kısa bir durum gösterir. Gerçek hata Node-RED log'undadır. Nerede bulacağınız Node-RED'i nasıl çalıştırdığınıza bağlıdır:

# Terminalden başlatıldıysa: log o terminaldedir

# systemd servisi olarak kurulduysa (örn. Raspberry Pi betiği)
journalctl -u nodered -f

# Docker
docker logs -f nodered

MQTT broker node'undan gelen Connection failed to broker: ... gibi satırları arayın. İki noktadan sonraki metin, örneğin Connection refused: Not authorized, getaddrinfo ENOTFOUND, ECONNREFUSED veya bir sertifika hatası, doğrudan aşağıdaki bölümlerden birine işaret eder.

Adım 2: Node-RED Dışında Test Edin

Node-RED'de herhangi bir şeyi değiştirmeden önce makinenin broker'a erişebildiğini kanıtlayın. Mosquitto istemcileri en hızlı yoldur. Kimlik bilgisi gerektirmediği için önce herkese açık MQTT test broker'ını deneyin:

mosquitto_sub -h broker.connectmq.com -p 1883 -i nr-test-6b0e \
  -t "connectmq/demo/6b0e/#" -v

İkinci bir terminalde:

mosquitto_pub -h broker.connectmq.com -p 1883 -i nr-test-pub-6b0e \
  -t "connectmq/demo/6b0e/ping" -m "hello"

hello görünürse bu makineden giden MQTT çalışıyor demektir. Şimdi özel broker'ınızı tam olarak Node-RED'in bağlanacağı şekilde, TLS ve kimlik bilgileriyle test edin:

mosquitto_sub -h YOUR_BROKER_HOST -p 8883 \
  --capath /etc/ssl/certs \
  -u YOUR_USERNAME -P YOUR_PASSWORD -i YOUR_CLIENT_ID \
  -t "test/#" -v -d

-d bayrağı CONNECT ve CONNACK paketlerini yazdırır. Bu komut başarısız olursa sorun Node-RED değil; ağ, sertifika veya kimlik bilgileridir. Başarılı olur ve Node-RED yine başarısız olursa Node-RED ayarlarını bu komutla alan alan karşılaştırın. Aynı client ID'yi kullandığı için Node-RED'i başlatmadan önce test istemcisini durdurun.

Adım 3: Sunucu, Port ve TLS'yi Birlikte Kontrol Edin

Bağlantı döngülerinin çoğu port ile TLS ayarları arasındaki bir uyuşmazlıktan kaynaklanır. Çoğu broker şu standart portları kullanır:

Yaygın hatalar:

1. TLS olmadan 8883 portu. Node-RED bir TLS portuna düz MQTT gönderir; broker bir TLS handshake'i bekler ve node sürekli yeniden bağlanmaya çalışır.
2. TLS işaretliyken 1883 portu. Node-RED düz bir porta karşı TLS handshake'i başlatır ve başarısız olur.
3. Server alanında şema. TCP ve TLS için yalnızca broker.connectmq.com gibi hostname'i girin. ws:// veya wss:// URL'sini yalnızca WebSocket üzerinden bağlanmak istediğinizde kullanın.
4. Yazım hataları ve boşluklar. Hostname'in sonundaki bir boşluk, fark edilmesi zor DNS hatalarına yol açar.

TLS için ayrıca Verify server certificate seçeneğinin etkin olduğunu ve sunucu adının sertifikayla eşleştiğini kontrol edin. ConnectMQ, Node.js'in varsayılan olarak güvendiği bir Let's Encrypt sertifikası kullanır; bu yüzden bir CA dosyası yüklemenize gerek yoktur. Eski bir CA dosyasıyla özel bir TLS yapılandırması eklediyseniz onu kaldırın. Eksiksiz kurulum Node-RED MQTT TLS yazısındadır.

Adım 4: Yinelenen Client ID'leri Eleyin

MQTT broker'ları client ID başına yalnızca bir bağlantıya izin verir. İkinci bir istemci aynı ID ile bağlandığında broker ilkinin bağlantısını keser. Her iki istemci de otomatik olarak yeniden bağlanıyorsa birbirlerini sonsuza kadar düşürürler; bu da connected ile disconnected arasında gidip gelen bir durum olarak görünür.

Yinelenmelerin tipik kaynakları:

• Aynı flow ile deploy edilmiş, dizüstü bilgisayar ve Raspberry Pi gibi iki Node-RED örneği.
• Node-RED'in client ID'siyle çalışır bırakılmış bir test mosquitto_sub'ı.
• Eskisi hâlâ çalışırken yeniden oluşturulan bir Docker container'ı.
• Tek bir Node-RED içinde aynı ID'ye sahip iki broker config node'u.

Her örneğe benzersiz bir ID verin. Herkese açık broker'da boş olmayan herhangi bir benzersiz dize çalışır. ConnectMQ özel broker'larında client ID'ler verilen kimlik bilgilerine bağlıdır; bu yüzden portalda gösterilen client ID'yi kullanın ve o kimlik bilgisi setini ikinci bir örnekte yeniden kullanmayın; bunun yerine onun için başka bir kimlik bilgisi oluşturun.

Adım 5: Kimlik Bilgilerini ve Hesap Sınırlarını Kontrol Edin

Bağlandıktan hemen sonra reddedilen bir bağlantı genellikle kimlik doğrulama anlamına gelir. MQTT 3.1.1 ile 4 veya 5 dönüş kodlarını (hatalı kullanıcı adı veya parola, yetkisiz) görürsünüz; MQTT 5 ile 0x86 veya 0x87 gibi reason code'lar görürsünüz. Broker node'unun Security sekmesinde kullanıcı adını ve parolayı yeniden girin, ardından deploy edin. Kimlik bilgileri flow'lardan ayrı saklanır; bu yüzden bir flow'u yeni bir makineye içe aktarmak broker ayarlarını getirir ama parolayı getirmez.

Daha az belirgin iki neden:

• Tekrarlanan başarısız girişler. ConnectMQ, tekrarlanan başarısız giriş denemelerinden sonra bir IP adresini engeller. Yanlış bir parola deploy ettiyseniz ve Node-RED birçok kez yeniden denediyse, yeni parolanın da yanlış olduğu sonucuna varmadan önce kimlik bilgilerini düzeltin ve engelin kalkmasını bekleyin.
• Bağlantı kotaları. Her planın bir bağlantı sınırı vardır; ücretsiz Serverless plan 25 bağlantıya kadar izin verir. Sınırın üzerinde bir MQTT 5 broker'ı 0x97 (quota exceeded) reason code'u ile reddedebilir. Tüm cihazlarınızı, panolarınızı ve Node-RED örneklerinizi sayın.

Adım 6: Ağ, DNS ve Container Sorunlarını Düzeltin

Log'da ENOTFOUND, ETIMEDOUT veya ECONNREFUSED görünüyorsa:

• Güvenlik duvarları. Kurumsal ve bazı misafir ağları giden 1883 ve 8883 trafiğini engeller. Ham MQTT'nin geçemediği yerlerden çoğu zaman geçebilen 8084 portundaki güvenli WebSocket'i deneyin.
• Docker'da localhost. Container içinde localhost container'ın kendisidir. Broker'ın hostname'ini, bir Compose servis adını veya host.docker.internal kullanın; bkz. Node-RED Docker.
• DNS. Node-RED sunucusunda nslookup YOUR_BROKER_HOST çalıştırın. DNS'i hatalı yapılandırılmış gateway'ler ilk olarak burada başarısız olur.
• Proxy'ler. Node-RED'in MQTT istemcisi ham TCP için bir HTTP proxy üzerinden yönlendirme yapmaz; WebSocket bağlantıları proxy'lerle daha uyumlu olabilir.

Adım 7: Keepalive ve Oturum Ayarlarını Kontrol Edin

Bağlantı aksi hâlde sağlıklı bir ağda her bir iki dakikada bir kopuyorsa keepalive'a bakın. 60 saniyelik bir değer çoğu bağlantıya uygundur. Çok uzun değerler, NAT router'larının boştaki bağlantıları sessizce düşürmesine izin verir. Ayrıca Clean session ayarlarının ve protokol sürümünün flow'unuzun beklentisiyle eşleştiğinden emin olun. 3.1.1'e ayarlanmış bir broker node'unda MQTT 5 özelliklerini karıştırmak bağlantıyı engellemez, ancak bağlandıktan sonraki tuhaf davranışları açıklayabilir.

Hızlı Sorun Giderme Kontrol Listesi

1. Flow deploy edildi mi ve MQTT node'u bir broker yapılandırmasına bağlı mı?
2. Node-RED log'u belirli bir hata gösteriyor mu?
3. mosquitto_sub aynı makineden aynı ayarlarla bağlanabiliyor mu?
4. Port ve TLS ayarları eşleşiyor mu (1883 düz, 8883 TLS)?
5. Server alanı yazım hatası içermeyen yalın bir hostname mi?
6. Client ID çalışan tüm istemciler arasında benzersiz mi?
7. Kullanıcı adı ve parola doğru mu ve IP'niz geçici olarak engellenmemiş mi?
8. Planınızın bağlantı sınırının altında mısınız?
9. DNS çözümleniyor mu ve port bu ağdan veya container'dan açık mı?

Durum yeşil ama mesajlar gelmiyorsa topic'leri ve wildcard'ları kontrol edin; çalıştığı bilinen bir flow için Node-RED MQTT eğitimine bakın. Resmi Node-RED MQTT node belgeleri de her broker ayarını açıklar.

Hata Ayıklaması Kolay Bir Broker Edinin

Broker tarafını görebildiğinizde sorun giderme daha hızlıdır. ConnectMQ; tarayıcı içi bir MQTT istemcisi ve canlı topic gezgini içeren bir portal sunan tam yönetilen bir MQTT hizmetidir; böylece Node-RED'in mesajlarının ulaşıp ulaşmadığını kontrol edebilirsiniz. Belirli bir istemcinin bağlı olup olmadığını izlemek için $SYS/broker/connection/{clientId}/state topic'ine de subscribe olabilirsiniz. app.connectmq.com adresinde kredi kartı gerektirmeden ücretsiz bir Serverless broker oluşturun ve tam host, port, kullanıcı adı, parola ve client ID değerlerini Node-RED'e kopyalayın. Arka plan bilgisi için bulut MQTT broker seçimi hakkındaki yazımızı okuyun.

Sık Sorulan Sorular

Node-RED MQTT node'um neden connecting durumunda takılı kalıyor?

Genellikle host veya port yanlıştır, TLS port ile eşleşmiyordur ya da bir güvenlik duvarı bağlantıyı engelliyordur. Tam hata için Node-RED log'unu kontrol edin ve aynı ayarları mosquitto_sub ile test edin.

Node-RED MQTT node'um neden sürekli bağlanıp kopuyor?

En yaygın neden yinelenen bir client ID'dir: aynı ID'ye sahip başka bir istemci oturumu sürekli devralır. Her Node-RED örneğine ve test aracına benzersiz bir client ID verin.

ConnectMQ'ya bağlanmak için bir CA sertifikası yüklemem gerekir mi?

Hayır. ConnectMQ, Node.js'in varsayılan olarak güvendiği bir Let's Encrypt sertifikası kullanır. Use TLS kutusunu işaretleyin, 8883 portunu kullanın ve sertifika doğrulamasını açık bırakın.

Node-RED kurumsal bir güvenlik duvarı arkasından MQTT'ye bağlanabilir mi?

1883 ve 8883 portları engelliyse, izin verilme olasılığı daha yüksek olan /mqtt yoluyla 8084 portunda güvenli WebSocket üzerinden MQTT'yi deneyin.