Node-RED ile MQTT olayını API kaydına çevirmek

Bir tezgâh çalıştığını MQTT üzerinden bildiriyor. Üretim uygulaması ise belirli alanları olan bir HTTP isteği bekliyor. İki taraf da veriyi iletebiliyor ama aynı dili konuşmuyor. Node-RED’in burada işe yarayan özelliği, mesajı bir uçtan alıp diğer uca gönderirken biçimini ve anlamını açıkça dönüştürebilmesi. Konu, bir akışı görsel olarak çizmenin kendisinden çok, iki sistem arasındaki sözleşmeyi kurmak.

Önceki yazı Node-RED’in görsel akış yaklaşımını ele alıyordu. Bu kez tek bir köprüye bakalım: MQTT ile gelen tezgâh durumunu, üretim uygulamasının HTTP API’sine aktarırken hangi kararlar gerekir? Böyle bir akış hazırlanabilir; fakat üretime alınması, mesajın doğru yorumlandığı ve hata halinde ne olacağı kanıtlanmadan güvenli değildir.

Aynı olay, iki ayrı veri biçimi

Varsayımsal bir atölyede kesim tezgâhı atolye/kesim/tezgah3/durum konusuna RUN veya STOP değerini yayınlasın. Üretim uygulamasının API’si ise makine kimliği, olay türü, olay zamanı ve kaynak alanları bulunan bir JSON nesnesi beklesin. MQTT konusu makinenin nerede olduğunu söylüyor; mesaj içeriği ise yalnızca durum değerini taşıyor. Köprünün görevi bu iki parçayı birleştirmek.

İlk adım, makine kimliğini konudan çıkarırken beklenen konu biçimini denetlemektir. atolye/kesim/tezgah3/durum anlaşılabilir ama atolye/kesim/bilinmeyen/durum uygulamada kayıt açmak için yeterli olmayabilir. Kimlik eşlemesi açık olmalı; örneğin konu içindeki tezgah3, uygulamanın tanıdığı makine kaydıyla eşleştirilir. Bilinmeyen konuları sessizce varsayılan makineye yazmak, veri kaybından bile zor fark edilen bir hata yaratır: yanlış makinenin geçmişi kirlenir.

İkinci adım durum sözlüğüdür. RUN, uygulamada “üretim yapıyor” anlamına mı gelir, yoksa makine yalnızca enerjili mi? STOP planlı duruşu, arızayı ve iş beklemeyi ayırmaz. Akışta yalnızca bildiğimiz dönüşümü yapabiliriz. Kaynak mesajı bu ayrımları içermiyorsa API’ye uydurma arıza nedeni göndermemeliyiz. İhtiyaç duyulan ayrıntı ayrı bir sensörden veya operatör girişinden gelecekse, bunu veri sözleşmesinin eksikliği olarak kaydetmek gerekir.

Akışın sınırları

Node-RED’de MQTT giriş düğümü bir broker’dan konuya abone olur. Gelen mesajda msg.topic çoğunlukla abone olunan somut konuyu, msg.payload ise iletilen değeri taşır. Ardından bir doğrulama adımı konu ve yükün beklenen biçimde olup olmadığını denetler. Change düğümü basit alan eşlemelerini yapabilir; daha karmaşık kurallar için Function düğümünde kod yazılabilir. Son aşamada HTTP Request düğümü API’ye isteği gönderir ve yanıt ayrı bir hata denetimi adımına gider.

Bu sıralama yalnızca düğüm seçimi değildir. Köprünün giriş ve çıkış sözleşmesini görünür kılar. Girişte geçerli konu ve izin verilen durum değerleri, çıkışta JSON alanları ve API’nin kabul ettiği yanıtlar yazılı olmalı. Her mesajın API’ye gitmesi doğru değildir. Örneğin boş yük, tanınmayan makine veya beklenmeyen bir durum değeri için ayrı bir hata yolu kurulmalı. Hata yolunda orijinal mesajın ilgili bölümleri ve hata nedeni tutulabilir; parolalar veya erişim anahtarları kayda geçirilmemeli.

Saat bilgisi ayrıca karara bağlanmalı. Makine yalnızca durum değeri gönderiyorsa olayın makinede oluştuğu zamanı bilmiyoruz; köprü en fazla mesajın kendisine ulaştığı zamanı ekleyebilir. Bu ikisini aynı şeymiş gibi sunmak, ağ kesintisinden sonra gelen eski mesajları yanlış sıraya dizer. Kaynak zaman damgası varsa doğrulanıp korunmalı, yoksa API alanı “alınma zamanı” olarak açıkça adlandırılmalı. Sonradan hazırlanacak vardiya raporu bu ayrıma dayanır.

Bağlantı kopunca ne olur?

Entegrasyonun işlediği en kolay gün, hem broker’ın hem API’nin ayakta olduğu gündür. Zor soru API kısa süreliğine yanıt vermediğinde çıkar. HTTP isteğini bir kez göndermek ve başarısızlığı görmezden gelmek olay kaybettirebilir. Sınırsız tekrar denemek ise API toparlandığında aynı olayı defalarca yazdırabilir. Tekrar politikası, başarısız mesajın nerede tutulacağı ve operatörün bu durumu nasıl göreceği önceden belirlenmeli.

Bir olay kimliği varsa kaynak ve kimlik üzerinden tekrarları ayıklamak mümkündür. Yalnızca RUN yükü varsa, aynı değerin iki kez gelmesi iki farklı olay mı yoksa teslim tekrarı mı, köprü tek başına bilemez. MQTT teslim ayarlarının neyi garanti ettiği ve hedef API’nin idempotent kayıt desteği birlikte değerlendirilmelidir. Node-RED’de yapılacak bir akış, bu iki sistemin eksik bıraktığı kimliği sihirli biçimde üretemez.

Kalıcı kuyruk ve bağlantı kesintisinden sonra yeniden gönderme gerekiyorsa Node-RED akışının yanında uygun bir mesaj altyapısı ve açık saklama süresi gerekir. Bellekte bekletilen olayların yeniden başlatma sonrası korunacağını varsaymayın. Operasyonel karar basitçe yazılabilir: API erişilemezse hangi olaylar yeniden denenecek, ne kadar süre tutulacak, süre dolunca kim haberdar olacak? Bu sorulara cevap yoksa canlı ekran güzel görünse de geçmiş eksik kalabilir.

Küçük bir doğrulama planı

Denemeyi tek makine ve iki bilinen durumla başlatmak yeterli. Önce örnek MQTT mesajlarıyla geçerli konu, geçersiz konu ve bilinmeyen durum değerini ayrı ayrı gönderin. API’ye yalnızca geçerli mesajın ulaştığını, kayıttaki makine kimliğinin doğru olduğunu kontrol edin. Sonra API’yi erişilemez hale getiren kontrollü bir test yapın. Akış hatayı görünür kılıyor mu, mesajı yeniden gönderebiliyor mu, yeniden göndermede çift kayıt oluşuyor mu? Yanıtı tahmin etmek yerine hedef sistemin kayıtlarında kontrol edin.

Son test, makine yeniden bağlandığında gecikmiş bir mesaj göndermek olabilir. Kaynak ve alınma zamanları ayrı tutulmuşsa olayın nerede geciktiği görülebilir. Kaynak zamanı yoksa bu belirsizliği raporda saklamayın. Tek tezgâhta bu hataları yakalamak, bütün atölyenin konularını bir anda bağlayıp sonradan hangi kaydın nereden geldiğini araştırmaktan daha kolaydır.

Node-RED burada ERP’nin, MES’in veya makine kontrolünün yerini almaz. Sınırlı görevi, iki arayüzün farklı konuştuğu yerde veriyi denetlenebilir bir kuralla taşımaktır. Başarılı bir köprü, yalnızca bir ekranda yeşil ışık göstermekle değil; yanlış mesajı reddetmek, başarısız isteği görünür kılmak ve hedef sistemde doğru kaydı göstermekle ölçülür.

Kaynaklar: Luke van Enkhuizen’in açık kaynak üretim araçları derlemesi, Node-RED mesaj kavramları ve mesajlarla çalışma rehberi. Atölye senaryosu örnekleme amacıyla kurgulanmıştır.