Endüstriyel IoT

MQTT QoS, Retain ve Last Will: Endüstriyel Uygulamalarda Doğru Kullanım

QoS seviyeleri, saklı (retained) mesajlar ve Last Will, MQTT’yi endüstride güvenilir kılan üç mekanizmadır. Hangisini ne zaman, hangi tuzaklarla kullanmalısınız?

3 dakika okuma ASP Dijital

Bu yazıda
  1. QoS: teslimat garantisi
  2. Retain: son bilinen değer
  3. Last Will: kopmayı bildirme
  4. Oturum ve süre yönetimi
  5. MQTT 5.0 ile gelenler
  6. Sparkplug ile ilişkisi
  7. Kontrol listesi

MQTT hafif bir protokoldür, ancak üretim ortamında “mesaj gitti mi?”, “yeni bağlanan abone güncel değeri nasıl öğrenir?” ve “bir cihaz koptuğunda bunu kim fark eder?” sorularının cevabı üç mekanizmada yatar: QoS, retain ve Last Will.

QoS: teslimat garantisi

QoSGarantiMaliyetTipik kullanım
0En fazla bir kez (gönder ve unut)En düşükSık güncellenen telemetri; bir örneğin kaybı önemsiz
1En az bir kez (tekrar olabilir)OrtaÖnemli olaylar, alarmlar; alıcı tekrarları tolere edebilmeli
2Tam bir kezEn yüksek (4 adımlı el sıkışma)Tekrarın zararlı olduğu nadir komutlar

Pratik kural: telemetri için QoS 0, olay ve alarm için QoS 1 yeterlidir; QoS 2’nin ek yükü çoğu saha uygulamasında gerekçelendirilmesi zor bir lükstür. QoS 1’de aynı mesajın iki kez gelebileceğini unutmayın: alıcı tarafı idempotent tasarlayın (örneğin olay kimliği ile tekrarları eleyin).

Ayrıca QoS, yalnızca istemci ile aracı arasındaki her bir hop için geçerlidir; yayıncı QoS 1 ile gönderse bile abone QoS 0 ile abone olmuşsa aracıdan aboneye teslim QoS 0 olur.

Retain: son bilinen değer

Bir mesaj retain bayrağıyla yayımlanırsa aracı o topic için son mesajı saklar ve o topic’e yeni abone olan her istemciye hemen iletir. Böylece pano veya uygulama, bir sonraki değişikliği beklemeden güncel durumu görür.

  • Uygun: Yavaş değişen durum bilgisi (cihaz çevrimiçi/çevrimdışı, mod, konfigürasyon).
  • Uygunsuz: Olaylar ve komutlar. Saklanan bir “başlat” komutu, yeni bağlanan her istemciye tekrar iletilir.
  • Temizleme: Saklı mesajı kaldırmak için aynı topic’e boş yükle, retain bayrağı açık bir mesaj yayımlanır. Unutulan saklı mesajlar eski veriyi “canlı” gösterebilir.

Saklı değer bayat olabilir: yayıncı çoktan kopmuş olsa bile son değer görünmeye devam eder. Bu nedenle veriyle birlikte zaman damgası taşıyın ve durum bilgisini aşağıdaki Last Will ile birleştirin.

Last Will: kopmayı bildirme

İstemci bağlanırken aracıya bir “vasiyet” mesajı bırakır. İstemci beklenmedik biçimde koparsa (ağ kesintisi, güç kaybı, zaman aşımı) aracı bu mesajı yayımlar; istemci düzgün şekilde ayrılırsa (DISCONNECT) yayımlanmaz.

Klasik desen:

durum topic'i: acme/istanbul/paketleme/hat-3/gateway/durum
bağlanınca : "online"  (retain = true)
Last Will  : "offline" (retain = true)

Böylece abone olan her uygulama, gateway çevrimiçi mi değil mi, hemen ve güvenilir şekilde bilir. Aracının kopmayı fark etmesi keep alive süresine bağlıdır: değer çok uzun olursa kopma geç algılanır, çok kısa olursa zayıf ağlarda gereksiz kopmalar yaşanır.

Oturum ve süre yönetimi

  • Kalıcı oturum: İstemci kopsa bile abonelikler ve (QoS 1/2) bekleyen mesajlar aracıda tutulabilir; yeniden bağlanınca teslim edilir. Aracı belleğini sınırlamak için kuyruk ve süre limitleri tanımlayın.
  • İstemci kimliği: Her istemci için benzersiz ve kararlı bir kimlik kullanın; iki istemci aynı kimlikle bağlanırsa aracı eskisini koparır.

MQTT 5.0 ile gelenler

MQTT 5.0 bazı endüstriyel ihtiyaçlara doğrudan yanıt verir: neden kodlu yanıtlar, mesaj ve oturum süre sonu (expiry), kullanıcı özellikleri (user properties) ve paylaşımlı abonelikler (birden çok tüketici arasında yük dağıtımı). Kullandığınız aracı ve istemci kütüphanelerinin 5.0 desteğini ve davranış farklarını doğrulayın.

Sparkplug ile ilişkisi

Sparkplug B, bu mekanizmaları standartlaştırır: NDEATH mesajı bir düğümün MQTT Last Will’idir, “birth” mesajları bir düğümün tüm metriklerini bildirir ve ana uygulama durumu için saklı bir STATE mesajı kullanılır. Yani aynı fikirler, cihaz keşfi ve veri tazeliği için ortak bir sözleşmeye bağlanmıştır.

Kontrol listesi

  1. Telemetri → QoS 0; olay/alarm → QoS 1 (+ idempotent alıcı).
  2. Durum bilgisi → retain; olay ve komut → retain kapalı.
  3. Her gateway/uygulama için Last Will + “online” saklı durum mesajı.
  4. Veriyle birlikte zaman damgası ve kalite bilgisi.
  5. Eski/saklı topic’lerin temizlik prosedürü.
  6. Keep alive ve oturum süreleri sahadaki ağ koşullarına göre test edilmiş.

Bu kuralları bir Unified Namespace tasarımında topic yapısıyla birlikte düşünmek en iyi sonucu verir; yapıyı topic oluşturucu aracımızla deneyebilirsiniz.