ESP32 Projelerinde MQTT mi HTTP mi? Nasıl Karar Verilir?

ESP32 MQTT HTTP karşılaştırması yaparken tek bir “doğru” protokol aramak yerine veri akışının nasıl çalışacağını düşünmelisiniz. ESP32 yalnızca belirli aralıklarla tek bir API uç noktasına ölçüm gönderecekse HTTP POST daha anlaşılır bir başlangıç olabilir; cihazın broker’a bağlı kalması, bir mesajın birden fazla alıcıya ulaşması veya publish/subscribe modelinin kullanılması gerekiyorsa MQTT daha doğal bir seçeneğe dönüşebilir.

Kararı; sürekli bağlantı ihtiyacı, tek hedef ya da çoklu alıcı, bağlantı kesildiğinde verinin nasıl ele alınacağı, enerji sınırı ve sistemi işletme kolaylığı belirler. Enerji tüketimi, gecikme ve performans açısından peşinen üstünlük ilan etmek doğru değildir; sonuç donanıma, Wi-Fi kalitesine, mesaj sıklığına, bağlantı yönetimine ve sunucu yapılandırmasına göre değişir. MQTT, broker üzerinden publish/subscribe mimarisiyle çalışırken HTTP’de ESP32 bir sunucuya istek gönderir ve yanıt alır. ([mqtt.org](https://mqtt.org/?utm_source=openai))

Kısa cevap: ESP32 projeniz için MQTT mi HTTP mi?

İlk ESP32 projenizde hedefiniz sıcaklık gibi bir değeri belirli aralıklarla web sunucusuna kaydetmekse HTTP POST ile başlamak genellikle daha kolay anlaşılır. Buna karşılık sensör verisini aynı anda bir kontrol paneline, kayıt servisine ve alarm mekanizmasına ulaştırmak; cihazların broker üzerinden mesajlaşmasını sağlamak veya cihazdan cihaza iletişim kurmak istiyorsanız MQTT’nin publish/subscribe modeli daha uygun bir zihinsel model sunar.

• HTTP’yi değerlendirin: Tek bir URL’ye veri gönderiyor, mevcut bir REST API ile bütünleşiyor ve her isteğin sonucunu durum koduyla görmek istiyorsanız.
• MQTT’yi değerlendirin: Birden fazla alıcının aynı veriyi dinlemesi, cihazların belirli konulara mesaj yayınlaması veya bağlantının sürekli açık tutulduğu bir akışın yönetilmesi gerekiyorsa.
• Bağlantı kesintisini baştan tasarlayın: Ölçüm kaybolabilir mi, daha sonra tekrar gönderilmeli mi, yoksa yalnızca son değer mi önemli? Bu cevap protokol seçiminden daha belirleyici olabilir.
• Enerji sınırını test ederek karar verin: ESP32’nin uyanma, Wi-Fi’ye bağlanma, veri gönderme ve tekrar uykuya geçme davranışı; mesaj aralığı ve ağ koşullarıyla birlikte ölçülmelidir.

Basit bir kural kullanabilirsiniz: “Bir ölçüm, bir sunucu, bir yanıt” akışında HTTP; “Bir yayın, bir broker, birden fazla dinleyici” akışında MQTT ile düşünmeye başlayın. Bu yalnızca ilk karar çerçevesidir. Gerçek seçim, yeniden bağlanma davranışı, veri kaybı toleransı ve sunucu tarafında hangi altyapının zaten bulunduğu incelenerek netleştirilmelidir.

ESP32’den sensör verisi gönderme akışı nasıl düşünülmeli?

ESP32’den sensör verisi gönderme işini yalnızca “sensörü oku ve internete yolla” şeklinde ele almak yerine, küçük bir veri hattı olarak tasarlayın. Örneğin sıcaklık sensöründen periyodik olarak ölçüm alınır, ölçüm uygulamanın anlayacağı alanlarla bir yük hâline getirilir ve HTTP ya da MQTT üzerinden gönderilir.

1. Ölçüm aralığını belirleyin: Sıcaklık yavaş değişen bir değer olduğundan her döngüde gönderim yapmak yerine uygulamanın ihtiyacına uygun bir periyot seçilebilir. Hızlı değişen bir değerle ortam sıcaklığı aynı sıklıkta izlenmek zorunda değildir.
2. Veri yükünü anlamlandırın: Yalnızca 24.6 göndermek yerine cihazın hangi ölçümü yolladığını belirten alanlar eklemek ileride hata ayıklamayı kolaylaştırır.
3. Cihaz kimliğini düşünün: Tek bir ESP32 ile çalışırken gereksiz görünen cihaz kimliği, birden fazla cihaz devreye girdiğinde verilerin karışmasını önler.
4. Zaman bilgisini değerlendirin: Sunucu ölçümün alındığı zamanı güvenilir biçimde ekleyebiliyorsa cihazdan zaman damgası göndermek şart olmayabilir. Ağ gecikmesi, çevrimdışı saklama veya sonradan gönderim varsa zaman bilgisi daha önemli hâle gelir.
5. Başarısız gönderimi tanımlayın: Cihaz başarısız isteği hemen mi tekrar deneyecek, ölçümü bellekte mi tutacak, yoksa bir sonraki ölçümde eski veriyi yok sayacak? Bu davranış protokol seçiminden önce yazılı hâle getirilmelidir.

Örnek bir veri yükü şu şekilde olabilir:

{"device":"esp32-01","temperature":24.6}

Bu ifade iki alan içeren gerçek bir JSON nesnesidir: device cihazı, temperature ise ölçüm değerini temsil eder. Alan adları uygulamaya göre değişebilir; örneğin ölçüm birimi için unit, ölçüm zamanı için timestamp veya sensör türü için sensor eklenebilir. Ancak gereksiz alanlarla mesajı büyütmek yerine, alıcı sistemin gerçekten ihtiyaç duyduğu bilgileri göndermek daha sağlıklıdır.

HTTP POST ne zaman daha anlaşılır bir seçimdir?

HTTP POST, ESP32’nin belirli bir URL’ye istek gönderdiği, sunucunun bu isteği işlediği ve sonucu bir HTTP durum koduyla bildirdiği request-response akışıdır. Bu yapı, özellikle tek bir API uç noktasına periyodik ölçüm gönderen projelerde anlaşılması kolay bir başlangıç sağlar. Örneğin ESP32, sıcaklık değerini /api/temperature adresine JSON olarak gönderir; sunucu da isteği kabul ettiğini, reddettiğini veya işleyemediğini yanıtıyla bildirir.

HTTP; mevcut bir web sunucusuyla, REST API ile veya sunucu tarafında hazırlanmış bir kayıt endpoint’iyle bütünleşmeniz gerektiğinde değerlendirilebilir. Her gönderimin sonucunu aynı işlem içinde kontrol etmek de hata ayıklamayı kolaylaştırır. Bununla birlikte HTTP’nin her istekte nasıl bağlantı kurduğu; bağlantının kapatılması, yeniden kullanılması veya keep-alive gibi ayarlar kütüphane ve sunucu yapılandırmasına bağlıdır. Bu nedenle “HTTP her zaman daha az enerji tüketir” ya da “MQTT her zaman daha hızlıdır” gibi genellemeler yerine, kendi donanımınız ve ağınız üzerinde test yapmalısınız. Espressif’in HTTP istemci dokümantasyonu; POST verisi, istek başlıkları, yanıt durum kodu ve bağlantı kapatma gibi işlemleri ayrı API adımları olarak tanımlar. ([docs.espressif.com](https://docs.espressif.com/projects/esp-idf/en/stable/esp32/api-reference/protocols/esp_http_client.html?utm_source=openai))

Aşağıdaki örnekte Wi-Fi bağlantısının daha önce kurulduğu varsayılmıştır. URL’yi kendi sunucunuzun gerçek endpoint’iyle değiştirmeli ve sunucunun beklediği JSON sözleşmesine uygun alanlar kullanmalısınız.

#include <WiFi.h>
#include <HTTPClient.h>

void sendTemperature(float temperature) {
  if (WiFi.status() != WL_CONNECTED) return;

  HTTPClient http;
  http.begin("http://192.168.1.50:8000/api/temperature");
  http.addHeader("Content-Type", "application/json");

  String body = "{"device":"esp32-01","temperature":";
  body += String(temperature, 1) + "}";

  int code = http.POST(body);

  if (code > 0) {
    Serial.printf("HTTP durum kodu: %d ", code);
    Serial.println(http.getString());
  } else {
    Serial.printf("İstek hatası: %s ",
                  http.errorToString(code).c_str());
  }

  http.end();
}

Akışın özeti şöyledir: Wi-Fi bağlantısı kontrol edilir, HTTP istemcisi URL ile başlatılır, JSON içerik türü başlıkla belirtilir, gövde POST edilir ve sonuç incelenir. Pozitif bir HTTP kodu sunucudan bir yanıt alındığını gösterir; bu, uygulamanızın isteği mutlaka başarıyla kaydettiği anlamına gelmeyebilir. Başarı ve hata aralıklarını sunucunuzun API sözleşmesine göre ele almalısınız. Negatif bir sonuç ise bağlantı kurulamadığı veya istemci tarafında bir hata oluştuğu gibi durumları gösterebilir.

Başlangıç aşamasında kimlik bilgilerini kod içinde düz metin olarak bırakmaktan kaçının. HTTP kullanırken TLS/SSL, sunucu sertifikasının doğrulanması ve kimlik doğrulama başlıklarının nasıl yapılandırıldığı ayrıca incelenmelidir; şifreli bağlantı kullanmak tek başına bütün güvenlik risklerini ortadan kaldırmaz. http.end() çağrısı da isteğin sonunda istemci kaynaklarını ve bağlantı yaşam döngüsünü düzgün biçimde sonlandırmak için kodda açıkça yer almalıdır.

MQTT hangi projelerde daha doğal bir modele dönüşür?

MQTT, ESP32’nin veriyi doğrudan belirli bir alıcıya göndermesi yerine bir broker üzerinden mesajlaşmasını sağlar. ESP32 bir topic’e mesaj publish eder; veriyi kullanmak isteyen ekran, başka bir cihaz, sunucu veya uygulama aynı topic’i subscribe ederek mesajı alır. Böylece sensörün, veriyi tüketen sistemleri tek tek bilmesine gerek kalmaz.

Bu model özellikle aynı verinin birden fazla alıcıya ulaştırılması gerektiğinde doğal bir seçimdir. Örneğin ESP32 sıcaklık bilgisini ev/salon/sicaklik topic’ine gönderirken aynı mesajı bir mobil panel, otomasyon servisi ve başka bir ESP32 dinleyebilir. Cihazdan cihaza komutlarda da benzer yapı kullanılır: kontrol paneli ev/salon/role topic’ine ON mesajı gönderir, röleye bağlı ESP32 ise bu topic’i subscribe eder.

MQTT’nin öne çıktığı senaryolar genellikle şunlardır:

• Düzenli sıcaklık, nem, ışık veya enerji telemetrisi gönderen cihazlar
• Aynı sensör verisini birden fazla uygulamanın veya cihazın dinlemesi
• ESP32’den başka bir cihaza aç/kapat, mod değiştir veya ayar komutu gönderilmesi
• Mesajların küçük, anlamlı ve olay odaklı olması
• Gönderici ile alıcının birbirinden bağımsız geliştirilebilmesi

Bu mimaride broker, sistemde ayrıca işletilen bir bileşendir. HTTP tarafındaki API sunucusu istekleri karşılayıp yanıt döndürürken MQTT broker istemcilerin bağlantılarını, topic aboneliklerini ve mesaj dağıtımını yönetir. Bu nedenle “HTTP API sunucusu zaten var, broker’a gerek yok” veya “broker API sunucusunun aynısıdır” şeklinde düşünmek doğru değildir. Aynı makinede çalışabilirler ancak sorumlulukları farklıdır.

ESP32 ile topic’e sıcaklık verisi publish etmek

Aşağıdaki örnek, Arduino ortamında PubSubClient benzeri bir MQTT istemci API’siyle ESP32’nin sıcaklık değerini topic’e göndermesini gösterir. setServer(), connect(), connected() ve publish() fonksiyonları kütüphanenin API’sinde yer alır; publish() sonucunun kontrol edilmesi, mesajın istemci tarafından kabul edilip edilmediğini uygulama seviyesinde görmeyi sağlar. Broker adresi, kullanıcı adı ve parola örnek yer tutucudur; gerçek değerleri güvenli yapılandırma yöntemiyle sağlamalısınız. API ayrıntıları için PubSubClient API tanımı incelenmelidir.

#include <WiFi.h>
#include <PubSubClient.h>

WiFiClient net;
PubSubClient mqtt(net);

const char* broker = "BROKER_ADRESI";
const char* user = "MQTT_KULLANICI";
const char* pass = "MQTT_PAROLA";

bool reconnectMQTT() {
  if (mqtt.connected()) return true;
  if (!mqtt.connect("esp32-sicaklik-01", user, pass)) return false;
  return true;
}

void publishTemperature(float value) {
  if (!reconnectMQTT()) return;
  char payload[16];
  snprintf(payload, sizeof(payload), "%.2f", value);
  bool sent = mqtt.publish("ev/salon/sicaklik", payload);
  Serial.println(sent ? "MQTT publish başarılı" : "MQTT publish başarısız");
}

Gerçek uygulamada bağlantı kurulamadığında yeniden bağlanma fonksiyonu çağrılmalı, ancak bu işlem ana döngüyü uzun süre bloke etmemelidir. Wi-Fi bağlantısının durumu ile MQTT broker bağlantısının durumunu ayrı ayrı izlemek de hata ayıklamayı kolaylaştırır.

QoS, retained message, Last Will ve session davranışları yalnızca kodda bir seçenek yazmaktan ibaret değildir; broker’ın ve MQTT istemcisinin ilgili yapılandırmayı desteklemesi gerekir. Örneğin retained mesaj, yeni abone olan istemciye topic’in son durumunu iletmek için kullanılabilir; Last Will ise beklenmeyen bağlantı kopmalarında durum mesajı yayınlamak üzere tasarlanabilir. Bu özelliklerin davranışı için OASIS MQTT 3.1.1 standardı ile hedef broker ve istemci belgeleri birlikte kontrol edilmelidir.

MQTT ve HTTP arasında karar vermek için karşılaştırma çerçevesi

Kararı yalnızca “hangisi daha hızlı?” sorusuna indirgemek yerine veri akışının kimin tarafından başlatıldığına, kaç alıcının bulunduğuna ve bağlantı kesildiğinde ne yapılacağına bakın. Sayısal performans sonucu elde etmek için aynı ESP32, aynı Wi-Fi koşulları, aynı gönderim aralığı ve aynı payload ile ayrıca ölçüm yapmak gerekir.

Karar ağacı: Kendi ESP32 projenize uygulayın

1. Tek bir API’ye istek mi gönderiyorsunuz? Sensör verisi belirli bir backend endpoint’ine kaydedilecekse HTTP ile başlamak genellikle daha anlaşılırdır.
2. Birden fazla cihaz veya servis aynı veriyi dinleyecek mi? Evet yanıtında publish/subscribe modeli daha doğal hale gelir ve MQTT yönünde ilerlenebilir.
3. Sürekli bağlantı ve broker işletme ihtiyacı kabul edilebilir mi? Broker işletmek istemiyorsanız veya proje yalnızca basit bir API çağrısından oluşuyorsa HTTP’nin operasyonel yükü daha düşük olabilir.
4. Ağ kesintisinde veri kaybı nasıl ele alınacak? Başarısız HTTP isteği için yeniden deneme ve yerel kuyruk tasarlayın. MQTT’de ise istemci bağlantısı, QoS ve session ayarlarını hedef broker’ın davranışıyla birlikte değerlendirin.
5. Enerji bütçesi ve uyanık kalma süresi ne kadar önemli? Uyku-uyanma döngüsüyle çalışan bir cihazda bağlantıyı ne zaman kurup kapatacağınızı ölçerek karar verin; protokollerden birinin her koşulda daha az enerji harcadığını varsaymayın.
6. Hata ayıklama yaklaşımınız hangisine daha uygun? HTTP yanıt kodlarını ve endpoint kayıtlarını rahat izliyorsanız HTTP; topic akışını, abonelikleri ve broker olaylarını izleyebiliyorsanız MQTT daha uygun olabilir.

Ağ kesintisi, yeniden bağlanma ve hata ayıklama nasıl test edilir?

HTTP’de ağ koparsa istek başarısız olabilir; uygulama yeni istekte yeniden deneme yapıp yapmayacağına karar vermelidir. MQTT’de bağlantı koparsa istemci broker’a yeniden bağlanmayı deneyebilir, ancak bağlantı kurulmadan yapılan publish işlemi başarısız olabilir. Her iki yaklaşımda da sınırsız ve kontrolsüz yeniden deneme cihazı meşgul edebilir, logları doldurabilir veya aynı verinin birden fazla işlenmesine yol açabilir.

Bağlantı kesintisi test kontrol listesi

• Wi-Fi erişimini geçici olarak kapatın veya ESP32’nin erişim noktasından uzaklaşmasını sağlayın.
• HTTP istemcisinin veya MQTT istemcisinin bağlantı durumunu seri port loguna yazdırın.
• Bağlantıyı geri getirin ve cihazın normal akışa hangi sırayla döndüğünü gözlemleyin.
• İlk aşamada yalnızca davranış sırasını inceleyin; belirli bir yeniden deneme süresini varsaymayın.
• Kesinti sırasında oluşan veri kaybını, gecikmeli gönderimi ve yinelenen mesaj ihtimalini kontrol edin.
• HTTP API logları ile MQTT broker loglarını karşılaştırarak isteğin veya publish işleminin hangi aşamada kaldığını bulun.
• Başarısız denemelerin kaç kez yapılacağını, bekleme yaklaşımını ve cihazın hangi durumda yeniden başlatılacağını açıkça tanımlayın.

Kimlik bilgileri ve TLS konusunda temel uyarılar

Kullanıcı adı ve parolayı kaynak kod deposuna açık biçimde bırakmayın. Düz metin iletişim, hassas veriler için uygun olmayabilir; TLS/SSL kullanımı, sunucu sertifikasının doğrulanması ve gerekiyorsa istemci sertifikaları hedef sunucu ile ESP32 ağ kütüphanesinin yapılandırmasına göre değerlendirilmelidir. ESP32 tarafında güvenli istemci bağlantıları ve sertifika doğrulama seçenekleri için Espressif NetworkClientSecure belgeleri incelenebilir. Hiçbir protokolün tek başına güvenlik garantisi vermediğini; yetkilendirme, sertifika yönetimi, topic veya endpoint izinleri ve log politikalarının birlikte ele alınması gerektiğini unutmayın.

Proje başlamadan önce son seçim ve uygulama kontrol listesi

Son kararı yalnızca “MQTT mi, HTTP mi?” sorusuna göre vermek yerine, verinin nereye gittiğini, nasıl işlendiğini ve bağlantı koptuğunda ne olacağını yazarak verin. Tek bir API’ye düzenli ölçüm gönderen basit projelerde HTTP daha doğrudan ilerleyebilir. Birden fazla cihazın veri yayınladığı, farklı bileşenlerin aynı veriyi dinlediği projelerde ise MQTT’nin publish/subscribe modeli daha doğal olabilir.

HTTP seçtiyseniz kontrol listeniz

• ESP32’nin veri göndereceği tek API uç noktasını, HTTP metodu ve veri formatıyla birlikte netleştirin.
• Sunucunun döndürdüğü yanıt kodlarını işleyin. Başarılı, geçici hata ve kalıcı hata durumlarını aynı kabul etmeyin.
• Wi-Fi veya sunucu bağlantısı kesildiğinde kaç kez ve hangi aralıklarla tekrar deneme yapılacağını belirleyin.
• Aynı ölçümün tekrar gönderilmesi ihtimaline karşı sunucu tarafında zaman damgası, cihaz kimliği veya ölçüm kimliği kullanmayı değerlendirin.
• İstek gövdesinde gönderilen verinin eksik, hatalı ya da beklenmeyen biçimde olması durumunu test edin.
• Sunucu loglarında cihazın isteğinin ulaşıp ulaşmadığını, hangi yanıtın döndüğünü ve hatanın hangi aşamada oluştuğunu izleyin.

MQTT seçtiyseniz kontrol listeniz

• Broker adresini, portunu ve ESP32’nin bu adrese erişebildiğini proje başlamadan doğrulayın.
• Topic adlandırmasını hiyerarşik ve tutarlı tasarlayın. Örneğin cihaz, ortam ve veri türünü ayıran bir yapı ileride takibi kolaylaştırır.
• Hangi bileşenin publish, hangisinin subscribe rolünde olduğunu açıkça yazın.
• Bağlantı koptuğunda yeniden bağlanma denemelerinin ne zaman başlayacağını ve cihazın normal akışa nasıl döneceğini belirleyin.
• Mesaj kaybolursa sistemin bunu tolere edip edemeyeceğini kararlaştırın. Aynı mesaj birden fazla kez işlenirse sonuç bozulacak mı, kontrol edin.
• Ölçümlere cihaz kimliği, zaman bilgisi veya sıra numarası ekleyerek tekrar eden mesajları ayırt etmeyi değerlendirin.

Bu karar sürecinde temel programlama ve algoritmik düşünme becerilerinizi gözden geçirmek isterseniz, algoritma bilgisi ölçme testi üzerinden kısa bir öz değerlendirme yapabilirsiniz. Ancak test sonucu, protokol seçiminin yerine geçmez; asıl belirleyici proje veri akışı ve hata senaryolarıdır.

Uygulamaya geçmeden önce ortak son kontrol

1. Ölçümün hangi aralıklarla gönderileceğini belirleyin.
2. Bağlantı yokken verinin yok sayılacağına, geçici bellekte tutulacağına veya daha sonra tekrar gönderileceğine karar verin.
3. Kimlik bilgilerini düz metin olarak kod içine gömmeyin; TLS/SSL ve uygun kimlik doğrulama yapılandırmasını kullanın.
4. Gerçek sensör yerine önce sabit ve bilinen değerlerle uçtan uca test yapın.
5. Bağlantıyı bilerek kesip yeniden bağlanma, tekrar gönderim ve log davranışını gözlemleyin.

Sık Sorulan Sorular

ESP32 ile yalnızca tek bir sunucuya sensör verisi göndereceksem HTTP mi MQTT mi kullanmalıyım?

Tek bir API’ye belirli aralıklarla veri gönderiyor ve sunucudan karmaşık bir dağıtım beklemiyorsanız HTTP genellikle daha anlaşılır bir başlangıç modelidir. Ancak bağlantı kesintileri, cihaz sayısı ve gerçek zamanlı mesaj dağıtımı arttıkça MQTT de değerlendirilebilir.

MQTT kullanmak için neden broker gerekir?

Broker, publish eden cihaz ile mesajı dinleyen istemciler arasındaki merkezi aracıdır. ESP32 doğrudan her alıcıyla ayrı ayrı konuşmak yerine mesajı broker’a gönderir; ilgili topic’e abone olan istemciler mesajı buradan alır.

Wi-Fi bağlantısı kesildiğinde HTTP ve MQTT verileri ne olur?

Bağlantı yokken yeni veri sunucuya veya broker’a ulaşmaz. Uygulama veriyi geçici bellekte tutacak mı, kaybı kabul edecek mi ve bağlantı geldiğinde tekrar gönderecek mi önceden belirlemelidir. Tekrar gönderim, aynı ölçümün iki kez işlenmesi riskini de beraberinde getirebilir.

ESP32 projesinde MQTT veya HTTP kullanırken kimlik bilgileri nasıl korunmalı?

Kullanıcı adı, parola ve erişim anahtarlarını herkese açık kod depolarına veya doğrudan paylaşılacak kaynak dosyalarına koymayın. TLS/SSL kullanımı, sunucu sertifikasının doğrulanması ve sınırlı yetkilere sahip kimlik bilgileri temel güvenlik adımlarıdır.

Protokol seçiminden sonra bağlantı kopma ve yeniden bağlanma davranışı nasıl test edilir?

Çalışan bağlantıyı kesip cihazın hata kaydını, yeniden deneme aralığını, veri kaybını ve bağlantı geri geldiğinde oluşan mesaj sayısını kontrol edin. Testi hem kısa süreli kesintide hem de cihazın uzun süre çevrimdışı kaldığı senaryoda tekrarlayın.

İyi bir ESP32 projesinde doğru protokol, yalnızca ilk veriyi gönderen değil; hata, tekrar deneme ve bağlantı geri dönüşü sırasında da öngörülebilir davranan protokoldür.