MQTT-SN Nedir? Sensör Ağları için MQTT Açıklamalı

MQTT-SN, TCP'nin fazla ağır olduğu ya da hiç bulunmadığı sensör ağları için tasarlanmış bir MQTT varyantıdır. Bu yazıda MQTT-SN'in normal MQTT'den nasıl ayrıldığını, topic ID'lerin, gateway'lerin ve uyuyan client'ların ne olduğunu ve MQTT-SN cihazlarını standart bir broker'a nasıl aktaracağınızı öğreneceksiniz; böylece yığınınızın geri kalanının bu cihazların varlığından haberdar olmasına bile gerek kalmaz.

MQTT-SN Nedir?

MQTT-SN, MQTT for Sensor Networks (Sensör Ağları için MQTT) anlamına gelir. İlk olarak 2000'lerin sonunda IBM araştırmacıları tarafından (önce MQTT-S adıyla) yayımlandı; amaç, düğümlerinin küçük radyoları, küçük pilleri olan ve TCP/IP yığını bulunmayan Zigbee gibi kablosuz sensör ağlarına yayınla/abone ol modelini getirmekti. Yaygın olarak uygulanan sürüm MQTT-SN 1.2'dir; OASIS o zamandan beri standartlaştırılmış bir ardıl üzerinde çalışmaktadır.

Tasarım hedefi basittir: MQTT programlama modelini (topic'ler, yayınlama, abone olma, QoS) korumak, ancak kısıtlı bir bağlantıda pahalı olan her şeyi çıkarmak. MQTT-SN bağlantı yönelimli bir taşıma gerektirmez. Ağ adreslenmiş datagram'ları teslim edebildiği sürece UDP üzerinde ve Zigbee veya BLE tabanlı mesh katmanları gibi IP dışı datagram ağları üzerinde çalışır.

Önemli sonuç şudur: Bir MQTT-SN client'ı normal bir MQTT broker ile doğrudan konuşamaz. Bir tarafta MQTT-SN, diğer tarafta TCP üzerinden MQTT konuşan bir gateway'e ihtiyaç duyar.

Bir Bakışta MQTT-SN ve MQTT

Topic ID'ler: Her Yayında Bayt Tasarrufu

factory/izmir/hall2/line4/temperature gibi bir topic, her PUBLISH paketinde düzinelerce bayta mal olur. Bütün bir çerçevenin yaklaşık yüz bayt taşıyabildiği bir bağlantıda bu kabul edilemez. MQTT-SN, dizeyi iki baytlık bir sayıyla değiştirir.

Bir ID elde etmenin üç yolu vardır:

1. Kayıtlı topic ID'ler. Client tam topic adıyla REGISTER gönderir; gateway bir ID içeren REGACK ile yanıt verir. Client ardından bu ID ile yayın yapar. Eşlemeler oturum süresince geçerlidir.
2. Önceden tanımlı topic ID'ler. Client ve gateway, ID'ler üzerinde yapılandırma yoluyla önceden anlaşır; böylece kayıt gerekmez. Sabit firmware için en verimli seçenek budur.
3. Kısa topic adları. t1 gibi tam olarak iki karakter; doğrudan ID alanında taşınır.

Bir client tam bir topic adıyla abone olduğunda gateway, eşleşen mesajları iletirken kullanacağı ID'yi döndürür. Joker karakterli abonelikler desteklenir, ancak gateway bu durumda her somut topic'i teslim etmeden önce client'a kaydetmek zorundadır; bu da gidiş-dönüşleri artırır.

Gateway'ler ve Forwarder'lar

Gateway, her MQTT-SN kurulumunun kalbidir. Spesifikasyon iki stil tanımlar:

• Şeffaf (transparent) gateway. Gateway her MQTT-SN client'ı için broker'a ayrı bir MQTT bağlantısı açar. Basittir ve client başına semantiğe sadıktır, ancak broker sensör sayınız kadar bağlantı görür.
• Toplayıcı (aggregating) gateway. Gateway broker'a tek bir MQTT bağlantısı tutar ve tüm sensör trafiğini bunun üzerinden çoğullar. Daha az broker bağlantısı, gateway'de daha fazla mantık.

Bir forwarder, MQTT-SN mesajlarını anlamadan sarıp client'lar ile bir gateway arasında aktaran daha da basit bir düğümdür; client'lar birkaç radyo atlaması uzakta olduğunda kullanışlıdır.

Gateway'ler kendilerini periyodik ADVERTISE mesajlarıyla duyurur. Bir tane duymamış bir client SEARCHGW yayını yapabilir; gateway'ler (veya bir gateway bilen diğer client'lar) GWINFO ile yanıt verir.

Uyuyan Client'lar

Pille çalışan sensörler ömürlerinin çoğunu radyo kapalı geçirir. MQTT-SN bunu açıkça modeller:

1. Client bir uyku süresiyle DISCONNECT gönderir ve uyku durumuna geçer.
2. Uyurken gateway ona gönderilen mesajları tamponlar.
3. Client uyanır, client ID'siyle PINGREQ gönderir, tamponlanmış mesajları alır ve tampon boşaldığında PINGRESP alır.
4. Tekrar uykuya döner.

Düz MQTT'de bunun bir karşılığı yoktur: TCP bağlantısını düşüren bir cihaz basitçe çevrimdışıdır ve yalnızca broker'daki kalıcı oturumlar onun için mesaj tutabilir.

QoS -1: Bağlantı Olmadan Yayınlama

MQTT-SN, bazen QoS -1 (sonraki taslaklarda QoS 3) olarak yazılan bir seviye ekler. Bir client, önceden tanımlı bir topic ID veya kısa ad kullanarak hiç bağlanmadan bilinen bir gateway adresine PUBLISH gönderebilir. Onay yoktur, oturum yoktur. Birkaç dakikada bir bir değer bağıran çok basit işaretçiler (beacon) için idealdir.

MQTT-SN'i Standart Bir MQTT Broker'a Aktarmak

Gateway MQTT-SN'i normal MQTT'ye dönüştürdüğü için bulut tarafı standartlara uygun herhangi bir broker olabilir. Yaygın bir açık kaynak seçenek, Linux üzerinde çalışan, UDP'de MQTT-SN dinleyen ve bir üst akış broker'ına bağlanan Eclipse Paho MQTT-SN Gateway'dir (paho.mqtt-sn.embedded-c projesinden).

Gateway'i ConnectMQ gibi bir yönetilen MQTT broker'a yönlendiren bir yapılandırma kabaca şöyle görünür. Anahtar adları gateway'in örnek gateway.conf dosyasından gelir; seçenekler sürümler arasında değiştiği için derlediğiniz sürümün README dosyasını kontrol edin.

# gateway.conf (Paho MQTT-SN Gateway, alıntı)
GatewayID=1
GatewayName=site1-mqttsn-gw
KeepAlive=60

# Üst akış MQTT broker (ConnectMQ, TLS)
BrokerName=broker.connectmq.com
BrokerPortNo=1883
BrokerSecurePortNo=8883
LoginID=YOUR_USERNAME
Password=YOUR_PASSWORD

# Tüm sensörler için tek bir TLS bağlantısı kullan
AggregatingGateway=YES
TransparentGateway=NO

# MQTT-SN tarafı: sensörler için UDP dinleyici
GatewayPortNo=10000
MulticastIP=225.1.1.1
MulticastPortNo=1883

Özellikle ConnectMQ'da dikkat edilmesi gereken iki şey:

• Client ID'ler kimlik bilgilerine bağlıdır. Her broker kimlik bilgisi seti kendi client ID'siyle gelir; bu yüzden sensör başına bir üst akış bağlantısı açan şeffaf bir gateway, sensör başına bir kimlik bilgisi setine ihtiyaç duyar. Tek bir üst akış kimliğine sahip toplayıcı bir gateway genellikle daha uygundur.
• Bağlantı kotaları. Ücretsiz Serverless planı 25'e, ücretli Serverless planı 1.000'e kadar bağlantıya izin verir. Toplama, büyük sensör alanlarında bile sizi bu sınırların rahatça içinde tutar.

Bulut tarafını doğrulayın

Gateway çalıştıktan sonra, sensör verilerinin sıradan MQTT olarak geldiğini görmek için bir dizüstü bilgisayardan abone olun. Bir kavram kanıtlama sırasında gateway'i bunun yerine genel MQTT test broker'ı'na yönlendirebilirsiniz (anonim, port 1883, benzersiz topic öneki):

mosquitto_sub -h broker.connectmq.com -p 1883 -i mqttsn-check-4d1e \
  -t "connectmq/demo/4d1e/#" -v

Üretim kimlik bilgileriyle -p 8883 --capath /etc/ssl/certs -u YOUR_USERNAME -P YOUR_PASSWORD ve portaldaki client ID'yi ekleyin. Aşağı akıştaki her şey (dashboard'lar, Node-RED akışları, historian'lar) veriyi, sensörler yerel olarak MQTT konuşuyormuş gibi tüketir.

MQTT-SN Ne Zaman Seçilmeli (ve Ne Zaman Seçilmemeli)

Karar vermeden önce bu kontrol listesini kullanın:

1. Cihazda TCP içeren bir IP yığını var mı? Cihazda TCP'li Wi-Fi veya hücresel bağlantı varsa TLS üzerinden düz MQTT daha basittir ve daha iyi desteklenir. ESP32 MQTT eğitimi bunun iyi bir örneğidir.
2. Radyo yalnızca datagram mı destekliyor? Zigbee, 6LoWPAN, ham LoRa tarzı bağlantılar veya özel sub-GHz radyolar MQTT-SN'in doğal alanıdır.
3. Pil ömrü en önemli kısıt mı? Gönderilen her baytın enerjiye mal olduğu durumlarda uyuyan client'lar ve topic ID'ler karşılığını verir.
4. Bir gateway çalıştırıp güvence altına alabilir misiniz? Gateway kritik bir bileşen haline gelir. İzleme, yeniden başlatma ve üst akış kimlik bilgilerini planlayın.
5. Güvenlik ne olacak? MQTT-SN'in yerleşik şifrelemesi yoktur. Sensör tarafında bağlantı katmanı güvenliğine veya DTLS'e, gateway-broker ayağında TLS'e güvenin.
6. Kütüphane erişilebilirliği. C ve gömülü platformlar için client kütüphaneleri mevcuttur, ancak ekosistem MQTT'ninkinden çok daha küçüktür.

Birçok proje için en iyisi hibrit bir yaklaşımdır: Kısıtlı düğümler yerel bir gateway ile MQTT-SN konuşur; gateway'in üst akış bağlantısı dahil geri kalan her şey standart MQTT konuşur. Temel protokolü hâlâ öğreniyorsanız MQTT eğitimi ve MQTT'nin TCP mi UDP mi kullandığı açıklamasıyla başlayın.

Yaygın MQTT-SN Tuzakları

• Topic ID kayması. Kayıtlı ID'ler oturuma özeldir. Bir gateway yeniden başlatıldıktan sonra client'lar yeniden kayıt olmalıdır, aksi halde yanlış topic'e yayın yaparlar. Önceden tanımlı ID'ler bundan kaçınır, ancak firmware ile gateway yapılandırması arasında senkronize tutulmalıdır.
• UDP paket kaybı. UDP üzerinden QoS 0 gerçekten veri kaybedebilir. Önemli olan her şey için QoS 1 kullanın ve yeniden deneme zamanlayıcılarını radyonuza göre boyutlandırın.
• Parçalanma. Payload'ları küçük tutun; MQTT-SN mesajlarının tek bir ağ çerçevesine sığması amaçlanır.
• Tek hata noktası olarak gateway. Gateway çökerse sensörler hiçbir şeyi tamponlamaz. Hızlı yeniden başlatma ve uyarı için tasarım yapın.

Sensör Ağınızı ConnectMQ'ya Taşıyın

Gateway sizin; broker'ın sizin olması gerekmiyor. ConnectMQ, MQTT-SN gateway'inize 8883 üzerinde bir TLS uç noktası, MQTT 3.1.1 ve 5.0 desteği ve verinin aktığını doğrulamak için canlı bir topic gezgini sunar. app.connectmq.com adresinde kredi kartı gerektirmeden ücretsiz bir Serverless broker oluşturun, oluşturulan kimlik bilgilerini gateway yapılandırmanıza kopyalayın ve sensörleriniz buluta çıksın.

Sık Sorulan Sorular

Bir MQTT-SN client'ı doğrudan bir MQTT broker'a bağlanabilir mi?

Standart bir broker'a bağlanamaz. MQTT-SN farklı bir paket formatı ve taşıma kullanır; bu yüzden bir gateway'in onu broker için TCP üzerinden MQTT'ye çevirmesi gerekir.

MQTT-SN QoS 2'yi destekler mi?

Evet. MQTT-SN 1.2, QoS 0, 1 ve 2'nin yanı sıra basit yayıncılar için bağlantısız QoS -1 modunu destekler.

MQTT-SN güvenli mi?

Protokolün kendisinde şifreleme yoktur. Sensörler ile gateway arasında bağlantı katmanı güvenliği veya DTLS, gateway ile broker arasında TLS kullanın.

MQTT-SN hangi portu kullanır?

Kayıtlı tek bir port yoktur; gateway yapılandırmasına bağlıdır. Birçok örnek 10000 gibi bir UDP portu kullanır ya da UDP üzerinden 1883'ü yeniden kullanır.