Olay Tabanlı IoT Bildirim Omurgası: Webhook'tan SMS'e

Bir IoT projesinde mühendislik enerjisinin neredeyse tamamı iki uca gider: sahadaki cihaz (sensör, modem, gateway) ve verinin toplandığı platform (bulut, zaman serisi veritabanı, gösterge panosu). Aradaki bağlantıyı da operatör ya da uydu sağlar. Bu üç katman olgunlaştığında elinizde güzel bir gerçek zamanlı veri akışı olur.

Ama şu soru çoğu zaman cevapsız kalır: Kritik bir olay olduğunda bunu bir insan ne zaman öğrenecek?

Bir soğuk hava deposunun sıcaklığı eşiği aştığında, panoda kırmızı bir grafik belirir. Sorun şu ki o panoya gece 03:14'te kimse bakmıyor. Veri akıyor, dashboard çalışıyor, "her şey yolunda" görünüyor, ama olay bir eyleme dönüşemiyor. IoT mimarilerindeki en sessiz boşluk budur: olayı insana taşıyan bildirim katmanı.

Bu yazıda, bu katmanı SMS üzerine kurmanın somut bir mimarisini, üretim ortamında gerçekten işe yarayan desenleriyle birlikte ele alıyoruz.

Neden SMS? Push ve e-posta nerede tıkanıyor

IoT bildirimi denince akla ilk gelen push notification ya da e-posta olur. İkisinin de yeri var, ama kritik alarmlarda zayıf kaldıkları üç nokta var:

Kapsama. IoT'nin en değerli senaryoları tam da karasal ağın zayıf olduğu yerlerde yaşanır: tarlada sulama sensörü, kırsaldaki su deposu, OSB dışındaki bir saha. Buralarda akıllı telefon ve veri bağlantısı garanti değildir, ama GSM sinyali ve SMS çoğu zaman vardır. SMS, IP bağlantısı gerektirmeyen en yaygın "son adım" kanalıdır.

Dikkat ve teslim. Push bildirimleri sessize alınır, kapatılır, uygulama silinince kaybolur. E-posta gecikir, spam'e düşer, klasörde birikir. SMS ise açılma oranı en yüksek kanaldır ve cihazda ayrı bir uygulama kurulu olmasını gerektirmez. Vardiya amirinin telefonuna düşen bir SMS, panodaki kırmızı kutudan çok daha hızlı eyleme dönüşür.

Bağımsızlık. Bildirim kanalınız, izlediğiniz sistemle aynı altyapıya bağlıysa, o altyapı çöktüğünde uyarıyı da alamazsınız. SMS, izlenen sistemden bağımsız bir kanal olarak "out-of-band" bir güvence sağlar.

Doğru kurgu SMS'i tek kanal yapmak değil, kritik olaylarda garantili kanal olarak konumlamaktır. Bilgi amaçlı olaylar e-posta/push ile gider; eyleme zorlayan olaylar SMS ile.

Temel mimari: dört adım

Olay tabanlı bildirim omurgası özünde basittir:

[Cihaz / IoT Platformu]
        │  (olay: eşik aşımı, arıza, offline)
        ▼
[Webhook alıcısı / kural motoru]   ← eşik, dedup, sessiz saat, eskalasyon
        │
        ▼
[iletiMerkezi SMS API]
        │
        ▼
[Alıcı]  +  [Teslim raporu webhook'u]

Buradaki kritik bileşen ortadaki kural motorudur. Cihazdan gelen ham olayı doğrudan SMS'e çevirmek bir hafta sonra sizi alarm yorgunluğuna (alert fatigue) boğar. Aradaki katman, "hangi olay, kime, ne zaman, kaç kez" sorularını yönetir.

Adım 1: Olayı yakala (webhook)

Çoğu IoT platformu (ThingsBoard, AWS IoT, Azure IoT Hub, ya da kendi backend'iniz) bir kural tetiklendiğinde HTTP webhook gönderebilir. Tipik bir payload şöyle görünür:

{
  "deviceId": "depo-3-sensor-01",
  "metric": "temperature",
  "value": 9.4,
  "threshold": 8.0,
  "severity": "critical",
  "site": "İstanbul Depo 3",
  "timestamp": "2026-06-29T03:14:22Z"
}

Bu payload'ı alan küçük bir servis kurmanız yeterli. Aşağıda Node.js (Express) ile minimal bir örnek var; mantık her dilde aynıdır.

import express from "express";
const app = express();
app.use(express.json());

app.post("/iot-webhook", async (req, res) => {
  const event = req.body;

  // 1) Geçersiz / önemsiz olayları erken ele
  if (event.severity !== "critical") return res.sendStatus(204);

  // 2) Kural motoruna devret (dedup, eskalasyon, sessiz saat)
  await handleEvent(event);

  // 3) Platforma hızlı 200 dön, SMS gönderimini bekletme
  res.sendStatus(200);
});

app.listen(3000);

Önemli bir detay: webhook'a hızlı yanıt verin, SMS gönderimini senkron beklemeyin. Platform genelde birkaç saniyede yanıt alamazsa olayı tekrar gönderir; bu da çift bildirime yol açar. Olayı bir kuyruğa (queue) atıp 200 dönmek en sağlıklı yaklaşımdır.

Adım 2: SMS'i gönder (iletiMerkezi SMS API)

Kural motoru "bu olay bildirilmeli" dediğinde iletiMerkezi SMS API'sine tek bir POST isteği atılır. Gerçek endpoint ve gövde şu şekildedir:

async function sendSms(numbers, text) {
  const res = await fetch("https://api.iletimerkezi.com/v1/send-sms/json", {
    method: "POST",
    headers: { "Content-Type": "application/json" },
    body: JSON.stringify({
      request: {
        authentication: {
          key: process.env.IM_API_KEY,
          hash: process.env.IM_API_HASH
        },
        order: {
          sender: "FIRMA",       // onaylı gönderici başlığınız
          iys: "0",               // bilgilendirme iletisi (aşağıda açıklıyoruz)
          message: {
            text: text,
            receipents: { number: numbers }
          }
        }
      }
    })
  });

  const data = await res.json();
  if (Number(data.response.status.code) !== 200) {
    throw new Error("SMS hatası: " + data.response.status.message);
  }
  return data.response.order.id; // sipariş id'si, teslim takibi için saklayın
}

Mesaj metnini kısa, eyleme dönük ve veriden arındırılmış tutun:

[KRITIK] İstanbul Depo 3 sıcaklık 9.4°C (limit 8°C).
03:14. Kontrol gerekli. Detay: panel.firma.com/d/depo-3

iys parametresine dikkat: bu olay bir alarm/bilgilendirme iletisi olduğu için "0" gönderilir. Eğer gönderdiğiniz içerik ticari nitelik taşıyorsa (kampanya, tanıtım) bu değer yasal olarak "1" olmalı ve İYS sorgusu yapılmalıdır. Bu ayrımın detayını IoT/M2M bildirimlerinde mevzuat yazımızda ele alıyoruz. IoT alarmlarının çoğu onay gerektirmeyen bilgilendirme kategorisine girer ve bu büyük bir operasyonel avantajdır.

Adım 3: Kural motorunun üç olmazsa olmazı

Mimarinin değerini bu katman belirler. En az şu üçü olmadan üretime çıkmayın:

Tekrar bastırma (deduplication / debounce)

Bir sensör eşiğin etrafında salınırsa (8.0 / 8.1 / 7.9 / 8.2 ...) dakikada onlarca olay üretebilir. Her birini SMS'e çevirmek hem maliyeti patlatır hem de alıcıyı bildirimlere karşı duyarsızlaştırır. Çözüm: aynı cihaz + metrik için bir soğuma penceresi (örn. 30 dk) koyun. iletiMerkezi API'si zaten aynı gönderici, alıcı ve mesaj metni kombinasyonunu kısa süre içinde tekrar göndermeyi 451 Tekrar eden sipariş hatasıyla engeller; ama asıl filtrelemeyi siz kendi tarafınızda yapmalısınız.

const lastSent = new Map(); // key: deviceId+metric -> timestamp
const COOLDOWN_MS = 30 * 60 * 1000;

function shouldNotify(event) {
  const key = `${event.deviceId}:${event.metric}`;
  const now = Date.now();
  if (lastSent.has(key) && now - lastSent.get(key) < COOLDOWN_MS) {
    return false; // soğuma penceresi içinde, bastır
  }
  lastSent.set(key, now);
  return true;
}

Üretimde bu durumu bellekte değil Redis gibi paylaşımlı bir yerde tutun; yoksa birden çok sunucu instance'ı ayrı ayrı bildirim gönderir.

Sessiz saat ve önem derecesi

Her olay gece 03:00'te birini uyandırmayı hak etmez. Önem derecesine göre kanal ve zaman ayrıştırın: critical her zaman anında SMS; warning mesai saatinde SMS, dışında sadece e-posta; info yalnızca panoda. Bu basit matris alarm yorgunluğunu büyük ölçüde çözer.

Kademeli eskalasyon

Kritik bir alarmda ilk kişi yanıt vermezse olay kaybolmamalı. Basit bir eskalasyon zinciri: SMS'i ilk sorumluya gönder; X dakika içinde onay (örn. bir linke tıklama ya da panelde "alındı" işareti) gelmezse bir üst kişiye, sonra yöneticiye ilet.

const chain = ["+90505...", "+90532...", "+90555..."]; // sorumlu -> amir -> yönetici

async function escalate(event, level = 0) {
  if (level >= chain.length) return;
  await sendSms([chain[level]], formatMessage(event, level));
  // 10 dk içinde onaylanmazsa bir üst seviyeye geç
  scheduleCheck(event.id, level, 10 * 60 * 1000, async () => {
    if (!isAcknowledged(event.id)) await escalate(event, level + 1);
  });
}

Bu desen IIoT (kestirimci bakım) ve sağlık senaryolarında kritiktir; tek bir kişinin telefonu sessizdeyse tüm zincir tıkanmaz.

Adım 4: Teslimi doğrula

Bir bildirim sistemi "gönderdim" demekle bitmez; "ulaştı mı?" sorusunu da cevaplamalı. iletiMerkezi'nde her gönderim bir sipariş id'si döndürür (order.id). Bu id ile SMS Rapor endpoint'inden teslim durumunu sorgulayabilirsiniz. Kritik alarmlarda akış şöyle olmalı: gönder, sipariş id'sini sakla, kısa süre sonra teslim durumunu kontrol et, "iletilemedi" ise alternatif kanala (arama, ikinci numara) düş.

Bu geri besleme döngüsü olmadan, sessizce iletilememiş bir alarm sizi "her şey yolunda" yanılgısında bırakır; bu da hiç bildirim göndermemekten daha tehlikelidir.

Hacim ve maliyet: baştan doğru kurun

IoT bildirimleri tipik olarak çok sayıda, küçük, çoğu önemsiz olaydan oluşur. Eğer her ham olayı SMS'e çevirirseniz hem bütçe hem de kullanıcı dikkati erir. Doğru tasarımın özü, SMS'e ulaşmadan önce olayların büyük kısmını elemektir:

Eşik + histerezis ile gürültüyü kaynağında kes (8°C'de değil, 8°C'yi 5 dk sürekli aşınca tetikle).
Soğuma penceresiyle tekrarları bastır.
Önem derecesiyle kanalları ayır; SMS'i yalnızca eyleme zorlayan olaylara ayır.
Toplulaştır: 10 sensör aynı anda offline olduysa 10 SMS değil, "İstanbul Depo 3'te 10 cihaz offline" tek SMS'i gönder.

Bu dört filtre, tipik bir kurulumda SMS hacmini ham olay sayısının yüzde birine indirir. Sonuç: hem ölçeklenebilir hem de okunan bir bildirim sistemi.

Özet

IoT mimarinizdeki en değerli iyileştirme bazen yeni bir sensör ya da daha iyi bir pano değil, olayı insana güvenilir biçimde ulaştıran ince bir katmandır. Bu katman dört parçadan oluşur: olayı yakala (webhook), gürültüyü ele (kural motoru), garantili kanaldan ilet (SMS API), teslimi doğrula (rapor).

iletiMerkezi SMS API'si tam olarak bu omurganın "son adım" parçası için tasarlanmıştır; dokümantasyonda alarm ve bilgilendirme sistemleri açıkça örnek kullanım olarak geçer. Ücretsiz hesapla 100 SMS kredisi tanımlanır; webhook'unuzu bağlayıp ilk alarmınızı dakikalar içinde test edebilirsiniz.

Sırada: bu bildirimlerin hangisinin yasal onay gerektirdiği, hangisinin gerektirmediği. Devamı IoT ve M2M Bildirimlerinde Mevzuat yazısında.

Kaynaklar: iletiMerkezi SMS API Dokümantasyonu, SMS Rapor API