MQTT Protokolü Rehberi: IoT Cihazları Nasıl Haberleşir?

"Sensör veriyi nereye gönderecek, panel bu veriyi nereden okuyacak?" IoT projelerinde ilk sorulan teknik soru genellikle budur. Kısa cevap: Çoğu projede cihazlar ile yazılım arasındaki konuşmayı MQTT taşır. MQTT, cihazların birbirini tanımadan, ortadaki bir sunucu (broker) üzerinden "konu" adı verilen kanallara mesaj yayımladığı ve bu kanallara abone olduğu hafif bir mesajlaşma protokolüdür. Zayıf bağlantılarda, düşük işlem gücüne sahip mikrodenetleyicilerde ve binlerce cihazın aynı anda bağlı olduğu sistemlerde rahat çalışır. Bu rehberde bir MQTT altyapısını sıfırdan kurarken izlediğimiz adımları; broker seçimi, topic tasarımı, QoS ve retain ayarları, güvenlik ve test sırasıyla anlatıyoruz.

MQTT nasıl çalışır? Yayımla-abone ol modeli

Klasik bir web API'sinde istemci sunucuya "bana şu veriyi ver" diye sorar ve cevap bekler. MQTT'de ise mantık farklıdır: Bir sıcaklık sensörü ölçümünü fabrika/hat1/kompresor/sicaklik konusuna yayımlar (publish). Bu konuya abone olan (subscribe) her istemci; panel, veritabanı yazıcısı, alarm servisi, mesajı broker aracılığıyla anında alır. Yayımlayan, kimin dinlediğini bilmez; dinleyen de mesajın hangi cihazdan geldiğini ancak konudan ve içerikten anlar.

Bu gevşek bağlılığın pratik faydaları vardır:

• Yeni bir tüketici eklemek için cihazlara dokunmanız gerekmez. Bir raporlama servisi eklemek, yalnızca yeni bir aboneliktir.
• Cihaz tek bir bağlantı açar ve onu açık tutar; her ölçümde yeniden bağlantı kurmanın maliyetini ödemez.
• Başlık (header) yükü çok küçüktür; bu yüzden hücresel veya kırsal bağlantılarda veri tasarrufu sağlar.

MQTT'nin güncel ana sürümü OASIS tarafından standartlaştırılan MQTT 5.0'dır. Sahada hâlâ çok sayıda 3.1.1 istemci bulunur ve broker'ların çoğu ikisini birlikte destekler.

Adım adım MQTT altyapısı kurmak

Aşağıdaki sıra, küçük bir pilottan yüzlerce cihazlı bir sisteme kadar uyguladığımız iş akışıdır. Her adımda hem ne yapılacağını hem de neden önemli olduğunu belirttik.

1. Broker'ı seçin. Kendi sunucunuzda çalıştıracaksanız Eclipse Mosquitto küçük ve orta projeler için hafif, kararlı bir seçenektir. Kümelenme, yüksek bağlantı sayısı veya yerleşik kural motoru gerekiyorsa EMQX ya da HiveMQ gibi daha kapsamlı broker'lara bakılabilir. Bulut sağlayıcıların yönetilen IoT servisleri de MQTT konuşur; bakım yükü azalır ama sağlayıcıya özgü kurallara bağlanırsınız. Karar sorusu şudur: Broker'ın çökmesi üretimi durduruyor mu? Durduruyorsa yedeklilik ve izleme planı en baştan seçimin parçası olmalıdır.
2. Topic hiyerarşisini kâğıt üzerinde tasarlayın. Topic'ler eğik çizgiyle ayrılmış seviyelerden oluşur ve sonradan değiştirmek zahmetlidir; çünkü cihaz yazılımına, panel sorgularına ve yetki kurallarına gömülür. İyi bir şema, genelden özele gider: firma/tesis/alan/cihaz-kimligi/olcum. Örnek: nexova/izmir-depo/soguk-oda-2/th-014/sicaklik.
3. Mesaj türlerine göre QoS seviyesini belirleyin. Her mesaj aynı önemde değildir. Hangi verinin kaybolabileceğine, hangisinin mutlaka ulaşması gerektiğine baştan karar verin (ayrıntısı aşağıdaki bölümde).
4. Durum bilgisi için retain ve Last Will kullanın. Cihazın çevrim içi olup olmadığını panelde güvenilir biçimde göstermek, bu iki özelliğin doğru kurulmasına bağlıdır.
5. Güvenliği ilk günden açın. TLS, kullanıcı adı/parola veya istemci sertifikası ve topic bazlı yetkilendirme (ACL) "sonra ekleriz" denecek şeyler değildir. Sahaya çıkmış yüzlerce cihazın ayarını sonradan değiştirmek, baştan doğru yapmaktan çok daha pahalıdır.
6. Cihaz tarafı istemciyi sağlam yazın. Yeniden bağlanma, keep alive süresi, çevrim dışıyken veriyi biriktirme ve saat senkronizasyonu cihaz yazılımında ele alınmalıdır.
7. Komut satırından test edin. Panel yazılmadan önce mesaj akışını terminalden doğrulamak, hatanın cihazda mı broker'da mı olduğunu hızla ayırır.
8. Veriyi kalıcı depolamaya ve panele bağlayın. Broker bir veritabanı değildir; geçmiş veri için ayrı bir abone servis zaman serisi veritabanına yazmalıdır.

Topic tasarımı: İyi ve kötü örnekler

Topic tasarımı, MQTT projelerinde en çok hafife alınan konudur. Birkaç ay sonra "sadece İzmir deposundaki tüm sıcaklıkları göster" dediğinizde şemanızın bunu tek bir abonelikle verebilmesi gerekir.

Joker karakterler bu noktada devreye girer. + tek bir seviyenin yerine geçer, # ise kalan tüm seviyeleri kapsar ve yalnızca en sonda kullanılabilir. Örneğin nexova/izmir-depo/+/+/sicaklik aboneliği depodaki tüm alanlardaki tüm cihazların sıcaklık verisini getirir. nexova/izmir-depo/# ise o tesise ait her şeyi.

Uyguladığımız kurallar:

• Başa eğik çizgi koymayın. /fabrika/hat1 ile fabrika/hat1 farklı topic'lerdir ve baştaki boş seviye karışıklık yaratır.
• Küçük harf, Türkçe karakter ve boşluk kullanmayın. soguk-oda yazın, Soğuk Oda değil. Farklı istemci kütüphanelerinde kodlama sorunu yaşamamak için ASCII ile sınırlı kalmak en güvenlisidir.
• Cihaz kimliğini topic'e koyun, mesaj içine gömmeyin. Yetkilendirme kuralları topic üzerinden yazılır; cihazın yalnızca kendi kanalına yazabilmesi ancak böyle mümkündür.
• Telemetri ve komutu ayırın. Örneğin cihaz .../th-014/telemetri konusuna yazar, .../th-014/komut konusunu dinler. Aynı kanalı iki yönde kullanmak döngülere ve karışık yetkilere yol açar.
• Kişisel veya gizli bilgiyi topic adına yazmayın. Topic adları loglara, izleme araçlarına ve hata mesajlarına düşer.
• Üretim istemcilerinde # aboneliğinden kaçının. Tüm trafiği tek istemciye akıtmak hem performans hem güvenlik sorunudur.

Mesaj içeriği (payload) için de bir sözleşme yazın. JSON okunabilir ve hata ayıklaması kolaydır; bant genişliği kısıtlıysa ikili formatlar tercih edilebilir. Her durumda ölçüm birimini, zaman damgasını ve bir şema sürüm alanını eklemek, ileride formatı değiştirdiğinizde eski cihazlarla uyumu korur. Endüstriyel tarafta bu sözleşmeyi standartlaştırmak isteyenler için Eclipse Sparkplug spesifikasyonu da bir seçenektir.

QoS seviyeleri: Hangi mesaj için hangisi?

QoS (Quality of Service), mesajın teslim garantisini belirler. Seviye arttıkça güvenilirlik artar, ama trafik ve gecikme de artar.

Pratikte en sık kullandığımız seviye QoS 1'dir; alıcı tarafta mesaja benzersiz bir kimlik veya zaman damgası ekleyip kopyaları ayıklamak, QoS 2'nin ek yükünü taşımaktan genellikle daha verimlidir. Bir ayrıntıya dikkat: QoS, yayımlayan ile broker arasında ve broker ile abone arasında ayrı ayrı uygulanır. Cihaz QoS 1 ile yayımlasa bile abone QoS 0 ile abone olduysa ikinci aşamada garanti düşer.

Retain, Last Will ve oturum ayarları

Retain (saklı mesaj): Retain bayrağıyla yayımlanan mesajı broker o topic için saklar ve sonradan abone olan her istemciye hemen gönderir. Panel açıldığında "son bilinen değer" için birkaç dakika beklemek yerine anında veri görürsünüz. Her telemetri mesajını retain yapmak gerekmez; cihaz durumu, son ayar ve yapılandırma bilgisi için idealdir. Saklı mesajı silmek için aynı topic'e boş içerikli ve retain bayraklı bir mesaj yayımlamak yeterlidir.

Last Will and Testament (LWT): İstemci bağlanırken broker'a bir "vasiyet" mesajı bırakır. Bağlantı düzgün kapanmadan koparsa (elektrik kesildi, modem çöktü) broker bu mesajı yayımlar. Tavsiye ettiğimiz kalıp şudur: Cihaz bağlanır bağlanmaz .../th-014/durum konusuna retain bayraklı online yayımlar; LWT olarak aynı konuya retain bayraklı offline bırakır. Böylece panel her an doğru durumu gösterir.

Keep alive: İstemci belirlenen süre içinde hiç mesaj göndermezse küçük bir ping atar. Broker, keep alive süresinin bir buçuk katı boyunca istemciden haber alamazsa bağlantıyı ölü sayar ve LWT'yi tetikler. Hücresel bağlantılarda bu süreyi çok kısa tutmak veri tüketimini artırır, çok uzun tutmak ise kopmaların geç fark edilmesine yol açar.

Kalıcı oturum: MQTT 5'te oturum süresi (session expiry) ayarı ile istemci bağlantısı koptuğunda broker'ın abonelikleri ve kaçırılan QoS 1/2 mesajlarını ne kadar süre tutacağı belirlenir. Komut alan cihazlar için kalıcı oturum, kısa kesintilerde komutların kaybolmamasını sağlar. MQTT 5 ayrıca mesaj ömrü, hata nedeni kodları ve paylaşımlı abonelik ($share/grup/topic) gibi özellikler getirir; paylaşımlı abonelik, yükü birden fazla işleyici servis arasında dağıtmak için kullanışlıdır.

MQTT güvenliği: TLS, kimlik doğrulama ve yetkilendirme

İnternete açık, parolasız bir broker, saldırganlar için hem veri hem de cihazlarınıza komut gönderme fırsatıdır. Güvenliği üç katmanda kurgulayın:

1. Şifreli bağlantı (TLS): Standart MQTT portu 1883 şifresizdir; TLS üzerinden MQTT için 8883 kullanılır. Üretimde 1883'ü dış dünyaya kapatın. Cihazların sunucu sertifikasını doğrulaması gerekir; doğrulamayı kapatan "hızlı çözümler" TLS'yi anlamsız kılar. Mikrodenetleyicide kök sertifikayı ve sertifika yenileme planını unutmayın.
2. Kimlik doğrulama: Her cihaza ayrı kullanıcı adı ve güçlü parola ya da daha iyisi ayrı istemci sertifikası verin. Tüm cihazlarda aynı parolayı kullanmak, tek bir cihazın sökülüp incelenmesiyle bütün filonun açığa çıkması demektir.
3. Yetkilendirme (ACL): Her istemcinin hangi topic'e yazıp hangisini okuyabileceğini sınırlayın. Sensör yalnızca kendi telemetri konusuna yazmalı, yalnızca kendi komut konusunu okumalıdır.

Mosquitto'da bu yapının temel ayarları kabaca şöyle görünür (yollar örnektir):

listener 8883
cafile /etc/mosquitto/certs/ca.crt
certfile /etc/mosquitto/certs/server.crt
keyfile /etc/mosquitto/certs/server.key
allow_anonymous false
password_file /etc/mosquitto/passwd
acl_file /etc/mosquitto/acl

Parola dosyası mosquitto_passwd aracıyla oluşturulur. ACL dosyasında pattern write nexova/+/+/%c/telemetri gibi bir kural, her istemcinin yalnızca kendi istemci kimliğiyle eşleşen topic'e yazmasına izin verir. Broker'ın çalıştığı sunucunun kendisi de korunmalıdır; işletmenin genel güvenlik tabanı için KOBİ siber güvenlik kontrol listemizi de gözden geçirebilirsiniz.

Cihaz tarafında sağlam istemci yazmak

Broker ne kadar iyi kurulursa kurulsun, sahadaki sorunların çoğu cihaz yazılımından çıkar. Gömülü istemcide şu davranışları mutlaka test edin:

• Kademeli yeniden bağlanma: Bağlantı koptuğunda her saniye tekrar denemek yerine bekleme süresini artırarak deneyin ve rastgele küçük bir gecikme ekleyin. Elektrik kesintisi sonrası yüzlerce cihazın aynı anda broker'a yüklenmesini böyle önlersiniz.
• Benzersiz client ID: Aynı client ID ile ikinci bir istemci bağlanırsa broker ilkini düşürür. Kopyalanmış yazılımla sahaya çıkan iki cihazın birbirini sürekli atması, sık gördüğümüz ve teşhisi zor bir arızadır.
• Çevrim dışı tampon: Bağlantı yokken ölçümleri belleğe veya flash'a yazın, bağlantı gelince zaman damgalarıyla gönderin. Flash yıpranmasını da hesaba katın.
• Saat senkronizasyonu: Zaman damgası koyacaksanız cihaz saatinin NTP veya başka bir kaynakla doğrulanması gerekir; aksi hâlde grafikleriniz yanlış zamanda veri gösterir.
• Bellek ve TLS yükü: TLS el sıkışması küçük mikrodenetleyicilerde ciddi RAM ister. Kart seçimini buna göre yapın; prototip aşamasındaki tercihler için ESP32 ile IoT prototipi yazımızda pratik notlar var.

LoRaWAN gibi doğrudan MQTT konuşmayan ağlarda da MQTT çoğu zaman devrededir: Ağ sunucusu, cihazlardan gelen veriyi MQTT ile dışarı verir. Bu yapının nasıl işlediğini LoRaWAN rehberimizde anlattık.

Test ve hata ayıklama

Paneli yazmadan önce akışı komut satırında doğrulayın. Mosquitto ile gelen istemci araçları bunun için yeterlidir:

mosquitto_sub -h broker.ornek.com -p 8883 --cafile ca.crt -u test-istemci -P 'parola' -t 'nexova/izmir-depo/#' -v

Bu komut tesisteki tüm mesajları topic adlarıyla birlikte ekrana basar. Ayrı bir terminalden mosquitto_pub ile komut konusuna mesaj gönderip cihazın tepkisini izleyebilirsiniz. Sorun ayırmada sık kullandığımız kontroller:

• Mesaj hiç gelmiyorsa: Cihaz gerçekten bağlı mı, broker logunda yetki reddi var mı, topic adında yazım farkı (büyük/küçük harf, fazladan eğik çizgi) var mı?
• Mesajlar kesik kesik geliyorsa: Client ID çakışması ve keep alive ayarı kontrol edilmeli.
• Panel eski değer gösteriyorsa: Retain'li eski bir mesaj kalmış olabilir.
• Broker yavaşlıyorsa: Mosquitto'nun $SYS konularındaki istatistikler bağlantı ve mesaj sayılarını gösterir.

Son adım, veriyi kalıcı hâle getirmektir. Bir abone servis, mesajları zaman serisi veritabanına yazar; panel bu veritabanından okur. Veriyi başka iş sistemlerine taşımak için n8n gibi iş akışı araçları da MQTT tetikleyicileriyle çalışabilir. Fabrika ölçeğinde bu katmanların nasıl birleştiğini endüstriyel otomasyon rehberimizde anlattık.

Sık Sorulan Sorular

MQTT ile HTTP arasındaki temel fark nedir?

HTTP istek-cevap modeliyle çalışır ve her istekte görece büyük başlıklar taşır. MQTT ise sürekli açık bir bağlantı üzerinden küçük mesajlarla yayımla-abone ol modeli kullanır. Sık ve küçük veri gönderen, bağlantısı kararsız cihazlar için MQTT daha verimlidir; tek seferlik veri çekme veya dosya aktarımı için HTTP daha doğaldır.

Ücretsiz halka açık broker'ları kullanabilir miyim?

Test ve öğrenme için evet; gerçek proje için hayır. Halka açık test broker'larında kimlik doğrulama yoktur, herkes topic'lerinizi okuyabilir ve hizmet garantisi bulunmaz. Üretimde kendi broker'ınızı veya yönetilen bir servisi kullanın.

Bir broker kaç cihaz taşır?

Broker yazılımına, sunucu kaynaklarına, mesaj sıklığına, TLS kullanımına ve QoS seviyelerine bağlıdır. Küçük bir sunucudaki Mosquitto yüzlerce cihazlı tipik bir projeyi rahatlıkla taşır. Kesin kapasiteyi gerçekçi mesaj profiliyle yük testi yaparak belirlemek gerekir.

MQTT 3.1.1 mi kullanmalıyım, MQTT 5 mi?

Broker ve istemci kütüphaneniz destekliyorsa MQTT 5'i tercih edin; hata nedeni kodları, oturum ve mesaj süreleri, paylaşımlı abonelikler işletmeyi kolaylaştırır. Sahada değiştirilemeyecek eski cihazlarınız varsa broker iki sürümü birlikte destekleyebilir.

Broker çökerse veriler kaybolur mu?

Broker yeniden başlatıldığında kalıcılık ayarı açıksa retain'li mesajlar ve kalıcı oturumlar geri yüklenebilir. Ancak broker bir arşiv değildir. Cihaz tarafında tampon, sunucu tarafında izleme ve gerekiyorsa yedekli broker yapısı kurgulanmalıdır.

Cihazlara MQTT üzerinden yazılım güncellemesi gönderilebilir mi?

Güncelleme bildirimi ve sürüm bilgisi MQTT ile gönderilebilir. Ancak büyük dosyanın kendisini genellikle HTTPS üzerinden indirmek daha sağlıklıdır; MQTT bu durumda "yeni sürüm var, şu adresten indir" mesajını taşır.

Sonuç

MQTT'nin kendisi basittir; projeyi başarılı kılan, etrafındaki kararlardır: anlamlı bir topic şeması, mesaj türüne uygun QoS, retain ve LWT ile güvenilir durum takibi, ilk günden açık güvenlik ve sahada kopmalara dayanıklı cihaz yazılımı. Bu kararları baştan doğru almak, ileride yüzlerce cihazın yazılımını yeniden yazmaktan kurtarır. Nexova Studio olarak broker kurulumu, cihaz yazılımı, veri katmanı ve panel geliştirmeyi uçtan uca üstleniyoruz. Ayrıntılar için IoT çözümleri sayfamıza bakabilir, projenizi konuşmak için bize yazabilirsiniz.

Kaynaklar

• OASIS: MQTT Version 5.0 Standard
• Eclipse Mosquitto: Documentation
• HiveMQ: MQTT Essentials