ESP32 ile Sensör Verisini HTTP Üzerinden REST API’ye Gönderme

ESP32 HTTP veri gönderme süreci; sensörden ölçüm alma, bu ölçümü doğrulama, Wi-Fi ağına bağlanma, JSON gövdeli bir HTTP POST isteği oluşturma ve sunucu yanıtını kontrol etme adımlarından oluşur. ESP32’nin Wi-Fi ağına bağlanması tek başına verinin API’ye ulaştığını göstermez; DNS, ağ yönlendirmesi, port, sunucu ve kimlik doğrulama katmanları da ayrı ayrı çalışmalıdır.

Başlangıç seviyesinde doğru yaklaşım, akışı tek bir büyük işlem gibi görmek yerine ölçüm al → doğrula → bağlan → gönder → yanıtı kontrol et → logla şeklinde bölmektir. Böylece sensör, donanım, Wi-Fi veya REST API kaynaklı hatanın hangi aşamada oluştuğunu daha kolay anlarsınız.

ESP32’den REST Uç Noktasına Veri Akışı Nasıl Çalışır?

ESP32 ile bir REST API’ye sensör verisi göndermek, mikrodenetleyicinin ölçtüğü değeri ağ üzerinden başka bir yazılımın anlayacağı biçimde iletmesi anlamına gelir. ESP32 burada yalnızca sensörü okuyan bir kart değildir; aynı zamanda Wi-Fi istemcisi olarak çalışır, HTTP isteği oluşturur ve sunucunun döndürdüğü yanıtı değerlendirir.

Veri akışının temel diyagramı

Bir IoT başlangıç projesindeki temel iletişim zinciri şu şekilde düşünülebilir:

Sensör → ESP32 → Wi-Fi erişim noktası → Yerel ağ veya internet → HTTP sunucusu / REST API

Bu zincirde her bileşenin farklı bir görevi vardır:

• Sensör: Sıcaklık, nem, ışık, basınç, hareket veya başka bir fiziksel büyüklüğü elektriksel bir sinyale dönüştürür.
• ESP32: Sensör sinyalini okur, anlamlı bir değere dönüştürür ve gönderilecek JSON verisini hazırlar.
• Wi-Fi erişim noktası: ESP32’nin kablosuz ağa katılmasını sağlar. Ev yönlendiricisi veya telefon erişim noktası bu görevi üstlenebilir.
• Yerel ağ veya internet: İsteğin ESP32’den sunucunun bulunduğu adrese taşınmasını sağlar.
• HTTP sunucusu: Gelen isteği alır, doğrular, işler ve bir HTTP durum kodu ile yanıt gövdesi döndürür.
• Seri port: ESP32’nin bağlantı durumunu, gönderilen veriyi ve sunucu yanıtını geliştiriciye gösterir.

Örneğin ESP32, bir sıcaklık sensöründen 24,6 °C ölçtüğünde bu değer önce yazılım içinde sayısal bir değişkene aktarılır. Ardından ölçümün geçerli olup olmadığı kontrol edilir. Sensör okumayı başaramadıysa veya anlamsız bir değer döndürdüyse bu veri doğrudan sunucuya gönderilmemelidir.

Ölçüm al, doğrula ve veriyi anlamlı hâle getir

Ham sensör çıktısı her zaman doğrudan kullanılabilir değildir. Analog bir sensör ham ADC değeri döndürebilir; bu değer örneğin 0 ile belirli bir sayısal sınır arasında olabilir. Uygulamanızın ihtiyacı ise çoğu zaman voltaj, sıcaklık veya yüzde gibi anlamlı bir fiziksel birimdir.

Bu nedenle ESP32 tarafındaki ilk yazılım adımı şu sorulara cevap vermelidir:

• Okuma işlemi başarıyla tamamlandı mı?
• Ölçüm değeri sensörün beklenen aralığında mı?
• Değer birim dönüşümünden geçirildi mi?
• Ondalık basamak sayısı gereksiz bellek kullanımına yol açıyor mu?
• Ölçüm geçersizse istek gönderilmeden önce hata loglandı mı?

Dijital sıcaklık ve nem sensörlerinde kütüphane çoğu dönüşümü sizin için yapabilir; ancak bu, dönen değerin her zaman doğru olduğu anlamına gelmez. Sensör bağlantısı hatalıysa, besleme kararsızsa veya okuma zamanlaması uygun değilse kütüphane geçersiz bir sonuç bildirebilir. Geçersiz değerleri JSON içine yazmak yerine ölçümü durdurup seri portta açık bir hata mesajı göstermek daha güvenlidir.

REST uç noktası nedir?

REST uç noktası, bir istemcinin belirli bir URL üzerinden veri gönderdiği veya aldığı sunucu adresidir. ESP32 açısından bu adres, verinin teslim edileceği hedef noktadır. Örnek olarak şu URL’yi ele alalım:

http://example.local/api/readings

Bu örnekte:

• http:// iletişim protokolünü belirtir.
• example.local sunucunun alan adını veya ağ üzerindeki adını belirtir.
• /api/readings sunucu içindeki belirli REST kaynağını gösterir.

Gerçek projede URL, yerel ağdaki bir cihazı veya internette çalışan bir sunucuyu gösterebilir. Başlangıç aşamasında yerel ağdaki bir sunucuya gönderim yapmak, DNS ve internet yönlendirmesi gibi değişkenleri azaltabilir. Ancak farklı ağlardan erişim, güvenlik duvarı ve port yönlendirme gibi ek konular ortaya çıkar.

HTTP metodu, başlıklar ve JSON gövdesi

Bir HTTP isteği yalnızca URL’den oluşmaz. Sunucuya ne yapmak istediğinizi HTTP metodu, gönderdiğiniz verinin biçimini ise başlıklar ve istek gövdesi anlatır.

Ölçüm göndermek için sık kullanılan yapı şu şekildedir:

• Metot: POST
• URL: Veriyi kabul eden REST uç noktası
• Content-Type: application/json
• Gövde: Sensör verisini taşıyan JSON nesnesi

Örnek JSON gövdesi:

{
  "device_id": "esp32-01",
  "temperature": 24.6,
  "humidity": 48.2
}

Bu nesnedeki JSON alanları uygulamanın sözleşmesine göre belirlenir:

• device_id, verinin hangi cihazdan geldiğini ayırt etmeye yarar.
• temperature, sıcaklık ölçümünü taşır.
• humidity, nem ölçümünü taşır.

Burada alan adlarının doğru yazılması önemlidir. Sunucu temp alanını beklerken ESP32 temperature gönderirse istek teknik olarak sunucuya ulaşabilir, ancak uygulama veriyi beklenen alanda bulamayabilir. Bu yüzden REST API’nin beklediği JSON şeması önceden bilinmeli ve ESP32 kodu bu sözleşmeye göre hazırlanmalıdır.

Arduino-ESP32 ortamında kullanılan HTTPClient sınıfı; URL başlatma, başlık ekleme, POST isteği gönderme, zaman aşımı ayarlama ve yanıt gövdesini okuma gibi işlemler için API sunar. Güncel sınıf davranışında POST, metin gövdesiyle çağrılabilir; setTimeout ise TCP iletişiminde bekleme süresini yapılandırmak için kullanılır. Kullanılan kart paketinin sürümüyle API davranışı arasında fark olabileceğinden, uygulama öncesinde Arduino-ESP32 HTTPClient API tanımı kontrol edilmelidir.

Wi-Fi bağlantısı neden yeterli değildir?

ESP32’nin seri portta “Wi-Fi bağlandı” mesajı vermesi yalnızca kablosuz erişim noktasına katıldığını gösterir. Bu aşamadan sonra REST sunucusuna ulaşmak için başka kontroller de gerekir.

1. DNS çözümleme: URL’de alan adı kullanılıyorsa ESP32 bu alan adını bir IP adresine çevirebilmelidir.
2. Ağ yönlendirmesi: ESP32’nin bulunduğu ağ, hedef sunucunun bulunduğu yerel ağa veya internete rota sağlayabilmelidir.
3. Port erişimi: Sunucunun dinlediği port erişilebilir olmalıdır. Varsayılan HTTP ve HTTPS portları her ağda açık olmak zorunda değildir.
4. Sunucu durumu: API uygulaması çalışıyor, ilgili rota tanımlı ve istekleri kabul ediyor olmalıdır.
5. Kimlik doğrulama: API anahtarı, Bearer token veya başka bir doğrulama mekanizması gerekiyorsa istek uygun başlıklarla hazırlanmalıdır.
6. İstek biçimi: HTTP metodu, JSON alanları, veri türleri ve Content-Type sunucunun beklentileriyle eşleşmelidir.

Örneğin ESP32 Wi-Fi’ye bağlanmış olabilir; fakat DNS sunucusuna erişemediği için alan adını çözemeyebilir. Alternatif olarak URL çözümlense bile sunucunun portu güvenlik duvarı tarafından engellenebilir. Bu iki durumda da sorun sensörde veya JSON oluşturma kodunda olmayabilir.

Sunucu yanıtı nasıl takip edilir?

POST isteği gönderildikten sonra ESP32’nin yalnızca “istek gönderildi” mesajı yazması yeterli değildir. Uygulama, dönen HTTP durum kodunu ve mümkünse yanıt gövdesini seri porttan göstermelidir.

Başlangıç seviyesinde log akışı şu bilgileri içerebilir:

• Ölçüm değeri ve ölçümün geçerli olup olmadığı
• Wi-Fi bağlantı durumu
• İsteğin gönderileceği URL’nin kısa gösterimi
• HTTP durum kodu
• Sunucu yanıtının ilk bölümü
• Bağlantı veya zaman aşımı hatasının kodu

Örnek bir seri port akışı şöyle görünebilir:

Ölçüm: 24.60 °C
Wi-Fi bağlantısı hazır
JSON gönderiliyor
HTTP durum kodu: 201
Sunucu yanıtı: {"saved":true}

Bu çıktıda 201 görülmesi, sunucunun isteği alıp yeni bir kayıt oluşturduğunu gösterebilir. Ancak hangi kodun başarı kabul edileceği API tasarımına bağlıdır. İstemci yazılımı yalnızca tek bir kodu beklemek yerine sunucunun sözleşmesine göre başarılı yanıt aralığını ve hata durumlarını ele almalıdır.

Sensör ve ESP32 Bağlantısında Pin, Voltaj ve ADC Ayrıntıları

ESP32 ile sensör bağlantısında en sık yapılan hata, herhangi bir GPIO pininin her görev için uygun olduğunu varsaymaktır. Oysa pinin giriş veya çıkış niteliği, analog ya da dijital işlevi, açılış sırasında taşıdığı özel görev ve Wi-Fi ile birlikte çalışma durumu karta ve ESP32 çip ailesine göre değişebilir.

Bu bölümde örnek olarak klasik ESP32 tabanlı bir ESP32-DevKitC V4 ve dijital sıcaklık-nem sensörü olarak DHT22/AM2302 ele alınmaktadır. Bu örnek, bütün ESP32 kartlarının veya bütün DHT22 modüllerinin aynı elektriksel özelliklere sahip olduğu anlamına gelmez. Kullandığınız kartın pinout çizimini ve sensörünüzün teknik dokümanını uygulama öncesinde mutlaka karşılaştırın.

Analog ve dijital sensör arasındaki fark

Analog sensör, ölçüm sonucunu sürekli değişen bir gerilim veya akım seviyesi olarak üretir. ESP32 bu sinyali ADC, yani analog-dijital dönüştürücü üzerinden sayısal bir değere çevirir. Örneğin ışık şiddeti arttıkça sensör çıkışı yükseliyor olabilir; fakat bu ham gerilimin doğrudan “lüks” veya “sıcaklık” olarak yorumlanabilmesi için sensörün veri sayfasındaki dönüşüm ilişkisinin bilinmesi gerekir.

Dijital sensör ise ölçümü kendi içinde işleyip ESP32’ye dijital iletişim protokolüyle aktarır. DHT22 gibi sensörlerde ESP32, veri hattındaki zamanlamaya uygun biçimde bitleri okur. Bu yöntemde ADC kullanılmaz; fakat sensörün desteklediği protokol, okuma aralığı, başlatma yöntemi ve kütüphane kullanımı önem kazanır.

Arduino ortamında DHT22 için yaygın kullanılan kütüphane DHT.h arayüzünü sağlar. Bu kütüphane DHT serisi sensörler için hazırlanmıştır ve bazı kullanım biçimlerinde Adafruit Unified Sensor kütüphanesine de ihtiyaç duyabilir. Kütüphane kurulumundan sonra sensör tipi ile veri pininin kodda doğru tanımlanması gerekir. Sensör modeliniz DHT22 değilse, aynı kütüphaneyi varsayarak ilerlemeyin.

Bağlantıda temel elektriksel kurallar

Bir sensörü ESP32’ye bağlamadan önce şu dört noktayı kontrol edin:

• Veri pini: Sensörün çıkış hattı, ESP32’de uygun bir GPIO girişine bağlanmalıdır.
• Ortak toprak: Sensörün GND pini ile ESP32’nin GND pini ortak olmalıdır. Ortak toprak yoksa sinyal seviyesi doğru yorumlanmayabilir.
• Besleme gerilimi: Sensörün desteklediği besleme aralığı ile ESP32 kartının sunduğu gerilim karşılaştırılmalıdır.
• Sinyal gerilimi: Sensörün veri veya analog çıkışı, ESP32 GPIO ya da ADC girişinin izin verdiği sınırlar içinde kalmalıdır.

Özellikle bir sensör modülünün 5 V ile beslenebilmesi, veri çıkışının da ESP32 için güvenli biçimde 5 V olduğu anlamına gelmez. Bazı modüllerde çıkış hattı besleme gerilimine yakın seviyeye çıkabilir. Bu nedenle 5 V seviyesindeki bir çıkış doğrudan ESP32 girişine uygulanmamalıdır; kartın ve sensörün belgeleri kontrol edilmeli, gerekiyorsa uygun seviye dönüştürme veya gerilim bölücü kullanılmalıdır.

ESP32 pin numaraları neden genellenmemeli?

“ESP32’de şu pin her zaman analog girişidir” gibi bir cümle güvenli değildir. ESP32-DevKitC V4, ESP32-WROOM modülü taşıyan başka bir geliştirme kartı, ESP32-S2, ESP32-S3 veya ESP32-C3 tabanlı kart aynı pin isimlerini ve ADC düzenini kullanmayabilir.

Klasik ESP32 ailesinde ADC1 ve ADC2 kanalları farklı GPIO gruplarına bağlıdır. Espressif dokümantasyonu, klasik ESP32’de ADC2’nin Wi-Fi sürücüsüyle paylaşılabildiğini ve Wi-Fi başladıktan sonra ADC2 kullanımında kısıt bulunduğunu belirtir. Bu nedenle Wi-Fi üzerinden veri gönderen analog sensör projesinde ADC pini seçerken kart pinout’u ve ilgili çip dokümanı birlikte kontrol edilmelidir. ESP32-DevKitC V4 üzerindeki pin işlevlerini görmek için Espressif ESP32-DevKitC V4 kullanıcı kılavuzu incelenebilir.

Analog ölçüm yapılırken çözünürlük de doğru yorumlanmalıdır. ADC’nin 12 bit olarak yapılandırılması, teorik olarak ham değerin 4096 ayrı seviyeden biriyle ifade edilebilmesi demektir. Ancak bu, her kartta ölçümün ideal ve tamamen doğrusal olduğu anlamına gelmez. Referans gerilimi, ADC attenuation ayarı, çipler arasındaki üretim farklılıkları, besleme gürültüsü ve sensör çıkışının kararlılığı gerçek sonucu etkileyebilir.

Bu sebeple analog sensör verisini JSON’a yazmadan önce şu ayrım yapılmalıdır:

• Ham ADC değeri mi gönderilecek?
• Kalibre edilmiş voltaj mı gönderilecek?
• Voltajdan türetilen fiziksel değer mi gönderilecek?
• Sunucu ham veriyi mi, dönüştürülmüş veriyi mi bekliyor?

Dijital DHT22 örneğinde ise ADC çözünürlüğü doğrudan kullanılmaz. Bunun yerine veri pininin doğru GPIO’ya bağlanması, sensörün uygun beslenmesi ve kütüphanenin doğru sensör tipiyle başlatılması önemlidir. Bir sensörün dijital olması da her GPIO’nun otomatik olarak uygun olduğu anlamına gelmez; açılışta özel görev yapan, yalnızca giriş destekleyen veya kart üzerinde başka devrelerle paylaşılan pinler olabilir.

Bağlantı öncesi kısa elektriksel güvenlik kontrol listesi

1. Kullandığınız ESP32 kartının tam modelini belirleyin.
2. Kartın pinout çiziminde seçtiğiniz pinin giriş, dijital veya ADC işlevini kontrol edin.
3. Wi-Fi ile birlikte ADC kullanacaksanız ADC1/ADC2 kısıtlarını kart ve çip belgelerinden doğrulayın.
4. Sensörün besleme gerilimini ve çıkış seviyesini teknik dokümandan kontrol edin.
5. ESP32 ile sensör arasında ortak GND bağlantısı kurun.
6. 5 V seviyesindeki sinyali ESP32 girişine doğrudan uygulamayın.
7. Analog sensör kullanıyorsanız çıkış geriliminin seçilen ADC giriş aralığına uygun olduğundan emin olun.
8. Enerji vermeden önce VCC, GND ve veri kablolarının yönünü tekrar kontrol edin.

JSON POST İsteğiyle İlk ESP32 IoT Projesini Kurma

ESP32 ile bir sensör verisini REST API’ye göndermenin temel akışı şöyledir: ölçüm al, veriyi doğrula, Wi-Fi ağına bağlan, JSON gövdesi oluştur, HTTP POST isteği gönder, yanıt kodunu kontrol et ve sonucu logla. Bu sırayı takip etmek, sorunun sensörde mi, kablosuz ağda mı, HTTP isteğinde mi yoksa sunucu tarafında mı olduğunu ayırmayı kolaylaştırır.

Aşağıdaki örnek, Arduino uyumlu ESP32 geliştirme ortamında kullanılmak üzere hazırlanmıştır. Örnek, klasik ESP32 tabanlı bir kartta ADC1 grubunda yer alan GPIO34 pinini varsayar. Ancak ESP32 ailesindeki kartların ADC pinleri, pin yetenekleri ve ölçüm aralıkları aynı değildir. Bu nedenle kendi kartınızın pin tablosunu ve kullandığınız sensörün veri sayfasını kontrol etmeden bağlantıyı birebir kopyalamayın. Espressif’in Arduino-ESP32 belgelerinde de ADC pinlerinin çipe göre değişebildiği, `analogRead()` sonucunun kalibre edilmemiş ham ADC değeri döndürdüğü belirtilir. ([docs.espressif.com](https://docs.espressif.com/projects/arduino-esp32/en/latest/api/adc.html?highlight=ADC&utm_source=openai))

Ölçüm al–doğrula–bağlan–gönder–yanıtı kontrol et–logla akışı

Bu örnekte sensörün analog çıkışından alınan ham değer `sensorRaw` değişkeninde tutulur. Değerin fiziksel birimi sıcaklık, ışık şiddeti, nem veya basınç olarak otomatik biçimde belirlenmez. Örneğin analog bir sıcaklık sensöründe ham ADC değeri gerçek sıcaklığa dönüştürülmek isteniyorsa sensörün veri sayfasındaki dönüşüm formülü, referans gerilimi, ADC davranışı ve çoğu durumda kalibrasyon sonucu dikkate alınmalıdır.

Kod içindeki SSID, parola ve API adresi özellikle yer tutucu olarak bırakılmıştır. Gerçek Wi-Fi bilgilerinizi, erişim token’ınızı veya API anahtarınızı kaynak koduna yazmayın. Aşağıdaki örnekte kimlik doğrulama başlığı kullanılmadığı için yalnızca gövde formatını ve temel POST akışını göstermek amaçlanır.

#include <WiFi.h>
#include <HTTPClient.h>
const char* ssid = "YOUR_WIFI_SSID";
const char* password = "YOUR_WIFI_PASSWORD";
const char* endpoint = "http://your-api.example/v1/measurements";
const int SENSOR_PIN = 34; // Klasik ESP32 örneği; kartınıza göre değiştirin

void setup() {
  Serial.begin(115200);
  int sensorRaw = analogRead(SENSOR_PIN);
  Serial.printf("ADC raw: %d ", sensorRaw);
  if (sensorRaw < 0 || sensorRaw > 4095) { Serial.println("Ölçüm geçersiz"); return; }
  WiFi.begin(ssid, password);
  unsigned long start = millis();
  while (WiFi.status() != WL_CONNECTED && millis() - start < 15000) delay(250);
  if (WiFi.status() != WL_CONNECTED) { Serial.println("Wi-Fi bağlantısı başarısız"); return; }
  HTTPClient http;
  http.setConnectTimeout(5000); http.setTimeout(5000);
  http.begin(endpoint); http.addHeader("Content-Type", "application/json");
  String json = "{"device":"esp32-demo","sensor_raw":" + String(sensorRaw) + "}";
  int code = http.POST(json);
  Serial.printf("HTTP code: %d ", code);
  if (code > 0) Serial.println(http.getString());
  else Serial.println(http.errorToString(code));
  http.end();
}
void loop() { delay(10000); }

Bu kodda `WiFi.h` kablosuz ağ bağlantısını, `HTTPClient.h` ise HTTP istemci işlemlerini sağlar. Kullanılan `setConnectTimeout()`, `setTimeout()`, `POST(String)`, `getString()` ve `errorToString()` metotları Arduino-ESP32 HTTPClient API’sinde yer alan işlevlerdir. HTTPClient kaynak kodunda bağlantı zaman aşımı ile TCP yanıt zaman aşımının ayrı ayarlanabildiği, `POST()` metodunun HTTP durum kodunu veya negatif hata kodunu döndürdüğü görülür. ([github.com](https://github.com/espressif/arduino-esp32/blob/master/libraries/HTTPClient/src/HTTPClient.cpp?utm_source=openai))

Kodun önemli bölümleri ne yapıyor?

• ADC okuma: `analogRead(SENSOR_PIN)` sensör pinindeki analog sinyali ham sayısal değere çevirir. Bu değer tek başına fiziksel ölçü birimi değildir.
• Basit geçerlilik kontrolü: Kod, klasik ESP32 için kullanılan 12 bitlik varsayılan ham aralığa göre temel bir sınır kontrolü yapar. Farklı çiplerde çözünürlük veya ADC davranışı değişebileceği için bu kontrol kartınıza göre yeniden değerlendirilmelidir.
• Wi-Fi bağlantısı: `WiFi.begin()` bağlantı sürecini başlatır. Döngü, bağlantı kurulana kadar sonsuza dek beklemek yerine 15 saniyelik bir üst sınır kullanır.
• JSON gövdesi: `device` alanı cihazı, `sensor_raw` alanı ise ham ADC değerini temsil eder. Gerçek bir API’nin beklediği alan adları farklı olabilir.
• Content-Type: `application/json` başlığı, sunucuya istek gövdesinin JSON biçiminde olduğunu bildirir.
• POST çağrısı: `http.POST(json)` JSON metnini belirtilen uç noktaya gönderir ve sunucudan dönen HTTP kodunu alır.
• Yanıt gövdesi: Pozitif bir HTTP kodu alındığında `getString()` ile sunucunun metin yanıtı okunur.
• Kaynak temizliği: `http.end()` bağlantı ve istemci kaynaklarının serbest bırakılması için çağrılır.

Örneği kendi projenizde sürekli ölçüm gönderecek şekilde genişletirken `setup()` içinde tek seferlik gönderim yapmak yerine ölçüm alma ve gönderme işlemlerini kontrollü bir `loop()` akışına taşıyabilirsiniz. Fakat her döngüde yeni istek göndermek yerine ölçüm aralığı belirlemek, bağlantı kopmalarını ele almak ve aynı verinin tekrar tekrar kaydedilmesini önlemek gerekir.

REST API’nin beklediği JSON şeması da önceden netleştirilmelidir. Sunucu örneğin aşağıdaki alanları bekliyor olabilir:

• `device_id`: Cihazın benzersiz kimliği
• `sensor_type`: Sensör türü
• `value`: Kalibre edilmiş fiziksel değer
• `unit`: Ölçü birimi
• `measured_at`: Ölçüm zamanı

Bu alanlardan yalnızca bildiğiniz ve doğru ürettiğiniz bilgileri gönderin. Ham ADC değerini sıcaklık gibi sunmak, API’ye teknik olarak geçerli görünen ancak anlamsal olarak yanlış bir veri göndermenize neden olabilir. Özellikle veri tabanında veya kontrol panelinde kullanılacak ölçümlerde kalibrasyon adımını ayrı bir işlem olarak tasarlamak daha güvenlidir.

Arduino, ESP32 veya JSON mantığını ekrandan kendi hızınızda pekiştirmek isterseniz asenkron video yazılım eğitimleri içinde temel programlama, değişkenler, koşullar ve hata ayıklama konularını tekrar edebilirsiniz. Eğitmenimiz Berk Keskin’in yaklaşımında amaç yalnızca kodu çalıştırmak değil, kodun hangi varsayımlara dayandığını ve hata verdiğinde nasıl inceleneceğini anlamaktır.

Beklenen seri port çıktısı nasıl okunur?

Seri port hızını 115200 baud olarak ayarladıktan sonra başarılı bir akışta benzer bir çıktı görebilirsiniz:

ADC raw: 1876
HTTP code: 201
{"status":"accepted","id":"demo-42"}

Buradaki `201`, sunucunun isteği alıp yeni bir kaynak veya kayıt oluşturduğunu ifade edebilir. API’niz aynı işlem için `200` veya başka bir 2xx kodu döndürebilir. Önemli nokta, isteğin ağ üzerinden ulaşmasının yanında sunucunun gövdeyi beklediği biçimde kabul edip etmediğini de yanıt kodu ve yanıt gövdesi üzerinden kontrol etmektir.

Wi-Fi bilgileri doğru değilse veya erişim noktası ulaşılamıyorsa örnek şu biçimde sonlanabilir:

ADC raw: 1876
Wi-Fi bağlantısı başarısız

Bu durumda HTTP isteği henüz gönderilmemiştir. Öncelikle SSID, parola, ağ kapsama alanı ve kartın doğru güç aldığı kontrol edilmelidir. Wi-Fi bağlantısı kurulmuş ancak uç nokta adresine erişilemiyorsa negatif bir istemci hata kodu görülebilir:

ADC raw: 1876
HTTP code: -1
connection refused

Negatif kodlar HTTP sunucusunun gönderdiği 4xx veya 5xx yanıtları değildir. Bunlar genellikle bağlantı kurulamadığını, istemcinin yanıt alamadığını veya isteğin oluşturulması sırasında bir ağ hatası oluştuğunu gösteren istemci tarafı hata sonuçlarıdır. Bu ayrımı yapmak, sunucu yanıtı ile ağ bağlantısı problemini birbirine karıştırmamanızı sağlar. ([github.com](https://github.com/espressif/arduino-esp32/blob/master/libraries/HTTPClient/src/HTTPClient.cpp?utm_source=openai))

HTTP Durum Kodları, Zaman Aşımı ve Temel Güvenlik Riskleri

ESP32’nin HTTP POST isteğini göndermiş olması, verinin uygulama tarafından kesin olarak kabul edildiği anlamına gelmez. Süreci üç ayrı aşamada düşünmek gerekir: cihazın ağa bağlanması, HTTP sunucusuna ulaşması ve API’nin gönderilen JSON’u işleyip kabul etmesi. Bu aşamalardan biri başarısız olduğunda ekrandaki belirti diğerlerinden farklı olur.

2xx, 4xx ve 5xx kodlarını başlangıç seviyesinde yorumlama

Başarılı kabul edilen kodun yalnızca `200` olduğunu varsaymak doğru değildir. Bazı API’ler yeni kayıt oluşturulduğunda `201`, gövde döndürmeden işlemi tamamladığında `204` kullanabilir. Bu yüzden cihaz kodunda yalnızca tek bir kodu başarı saymak yerine API sözleşmesinde belirtilen yanıtları açıkça tanımlayın.

Benzer şekilde `400` ile `401` aynı sorunu anlatmaz. `400` çoğunlukla JSON veya parametre biçiminin sunucunun beklentisine uymadığını düşündürürken, `401` kimlik doğrulama katmanına işaret eder. `404` ise doğru sunucuya ulaşılmış olsa bile istenen yolun yanlış yazılmış olabileceğini gösterir. Bu nedenle bir hata gördüğünüzde önce “sunucuya ulaşabildim mi?”, sonra “sunucu isteği anladı mı?” ve son olarak “işlemi yapmaya yetkim var mı?” sorularını sorun.

Zaman aşımı neden oluşur?

Zaman aşımı, ESP32’nin belirlenen süre içinde beklediği ağ veya HTTP yanıtını alamaması durumudur. Nedeni yalnızca internet bağlantısının yavaş olması değildir. Aşağıdaki durumların her biri zaman aşımına yol açabilir:

• ESP32’nin erişim noktasına bağlanamaması
• DNS çözümlemesinin başarısız olması veya uzun sürmesi
• Uç nokta adresinin yanlış yazılması
• Sunucunun kapalı, meşgul veya erişilemez olması
• Sunucunun isteği alıp yanıt üretmesinin beklenenden uzun sürmesi
• Güvenlik duvarı, ağ politikası veya yönlendirici kısıtlaması
• Sunucunun yanıt gövdesini bağlantıyı kapatmadan eksik bırakması

Arduino-ESP32 HTTPClient içinde `setConnectTimeout()` sunucuya bağlantı kurma aşamasındaki süreyi, `setTimeout()` ise TCP bağlantısı üzerinden beklenen veri için kullanılan zaman aşımını ayarlamak üzere kullanılır. HTTPClient ayrıca yanıt gövdesini `getString()` ile okuyabilir ve bağlantı kurulamadığında veya okuma zaman aşımı oluştuğunda negatif hata kodları döndürebilir. ([github.com](https://github.com/espressif/arduino-esp32/blob/master/libraries/HTTPClient/src/HTTPClient.cpp?utm_source=openai))

Sonsuz bekleme, cihazın ana döngüsünü kilitleyebilir. Böyle bir durumda ESP32 yeni ölçüm alamaz, LED veya ekran gibi diğer görevleri güncelleyemez ve bazı projelerde watchdog sıfırlamasına kadar ilerleyebilir. Bu nedenle her ağ işlemi için makul bir zaman sınırı, hata logu ve kontrollü tekrar deneme planı bulunmalıdır.

Tekrar deneme eklerken de dikkatli olun. Cihaz, sunucu isteği işlediği hâlde yanıtı alamamış olabilir. Bu durumda ESP32 aynı POST isteğini yeniden gönderirse veri iki kez kaydedilebilir. Özellikle ödeme, sayaç, stok, alarm veya komut işlemlerinde tekrar gönderimleri ayırt etmek için sunucu tarafında benzersiz olay kimliği, cihaz kimliği ve zaman damgası gibi alanlar kullanılabilir.

HTTP ve HTTPS arasındaki temel güvenlik farkı

http:// ile gönderilen veriler şifrelenmeden taşınabilir. Aynı ağdaki kötü niyetli bir gözlemci, ağ trafiğini inceleyebiliyorsa JSON gövdesini, cihaz kimliğini veya gönderilen kimlik bilgilerini görebilir. Bu nedenle gerçek cihaz projelerinde HTTPS kullanımı değerlendirilmelidir.

HTTPS yalnızca veriyi şifrelemekten ibaret değildir. ESP32’nin karşı sunucunun gerçekten beklenen sunucu olduğunu doğrulaması gerekir. Arduino-ESP32’nin güvenli istemci altyapısında kök CA sertifikası `setCACert()` ile tanımlanabilir; bu sertifika, sunucu sertifikasının doğrulanmasında kullanılır. Sertifika doğrulamasını devre dışı bırakan `setInsecure()` seçeneği test amacıyla bulunabilse de üretim ortamında sahte sunucuya bağlanma riskini artırır. ([github.com](https://github.com/espressif/arduino-esp32/blob/master/libraries/NetworkClientSecure/README.md?utm_source=openai))

HTTPS/TLS kullanımı mikrodenetleyici tarafında ayrıca tasarım gerektirir. Sertifika zincirinin firmware içinde tutulması flash alanı tüketebilir; TLS el sıkışması ve şifreleme işlemleri RAM, işlem süresi ve doğru sistem zamanı gibi ek gereksinimler doğurabilir. Bu, HTTPS’nin kullanılmaması gerektiği anlamına gelmez. Aksine, güvenli bağlantı kurulacaksa sertifika yönetimi, bellek kullanımı, saat senkronizasyonu ve hata durumları baştan planlanmalıdır.

Temel güvenlik önlemleri

• Kimlik bilgilerini koda gömmeyin: Gerçek SSID, parola, token ve API anahtarlarını herkese açık depolara veya ekran görüntülerine koymayın.
• Logları temiz tutun: HTTP başlıklarını, `Authorization` değerlerini veya gizli anahtarları seri porta yazdırmayın.
• Sunucuda kimlik doğrulama uygulayın: API’nin yalnızca URL’yi bilen herkes tarafından kullanılmasına izin vermeyin.
• HTTPS sertifikasını doğrulayın: Test kolaylığı için sertifika kontrolünü kapatmak, üretim güvenliği için uygun bir çözüm değildir.
• JSON doğrulaması yapın: Sunucu, beklenmeyen alanları, hatalı veri türlerini ve fiziksel olarak anlamsız değerleri reddedebilmelidir.
• Tekrar gönderimi düşünün: Zaman aşımından sonra aynı ölçümün ikinci kez kaydedilmesini önlemek için olay kimliği veya idempotency yaklaşımı kullanın.
• En az yetki ilkesini uygulayın: Bir cihazın yalnızca ihtiyaç duyduğu uç noktaya ve işleme erişebilmesi daha güvenlidir.
• Hata mesajlarını sınırlayın: Sunucunun ayrıntılı iç hata bilgisini doğrudan cihaza döndürmesi, sistem yapısı hakkında gereksiz bilgi sızdırabilir.

Başlangıç projesinde önce yerel ve hassas olmayan bir test verisiyle HTTP akışını doğrulamak, ardından HTTPS, kimlik doğrulama ve tekrar gönderim kontrolünü eklemek öğretici olabilir. Ancak HTTP’yi üretim güvenliği varmış gibi değerlendirmemek gerekir. Test ortamı ile gerçek kullanıcı veya cihaz verisi taşıyan ortamın güvenlik gereksinimleri birbirinden ayrılmalıdır.

ESP32 Sensör ve HTTP Hatalarını Adım Adım Teşhis Etme

ESP32 ile sensör verisi gönderirken hata ayıklamaya doğrudan HTTP isteğinden başlamak çoğu zaman yanlış noktaya odaklanmanıza neden olur. Daha güvenilir yöntem, sorunu ölçüm al–doğrula–bağlan–gönder–yanıtı kontrol et–logla sırasıyla daraltmaktır. Böylece sensör bağlantısı, Wi-Fi, ağ erişimi, REST uç noktası ve sunucu davranışı birbirine karıştırılmaz.

Arduino-ESP32 ortamında Wi-Fi istemci, yani STA modu, ESP32’nin bir erişim noktasına bağlanarak ağa çıkmasını sağlar. Bağlantıdan sonra alınan IP adresini seri porta yazdırmak, cihazın yalnızca ağa bağlanıp bağlanmadığını değil, yerel ağda gerçekten adres alıp almadığını da görmenize yardımcı olur. ([docs.espressif.com](https://docs.espressif.com/projects/arduino-esp32/en/latest/api/wifi.html?utm_source=openai))

1. Ölçüm al: Önce sensör kablosunu ve ham değeri kontrol edin

HTTP isteği başarısız görünse bile sorun sensörde olabilir. Sensör yanlış pine bağlandıysa, besleme gerilimi uygun değilse veya ESP32 ile sensörün GND hattı ortak değilse kod doğru çalışıyor gibi görünse de elde edilen veri geçersiz olabilir.

İlk kontrolde aşağıdaki sırayı izleyin:

1. ESP32 kartınızın ve sensörünüzün pinout şemasını kontrol edin.
2. VCC, GND ve veri hattının doğru bağlandığından emin olun.
3. ESP32 ile sensör arasında ortak GND bulunduğunu doğrulayın.
4. Analog sensörde analog okuma, dijital sensörde dijital okuma kullanıldığını kontrol edin.
5. Ham sensör değerini HTTP göndermeden önce seri porta yazdırın.
6. Elinizi sensöre yaklaştırmak, ışığı değiştirmek veya fiziksel koşulu değiştirmek gibi güvenli bir test yapın.

Bir sensörün ham değerinin hangi aralıkta olması gerektiği kart ve sensör modeline göre değişebilir. Bu nedenle yalnızca “bu pin her ESP32 kartında aynıdır” veya “ADC her kartta aynı çözünürlükte çalışır” gibi genellemeler yapmayın. Önce kullandığınız kartın pinout belgesini ve sensörün teknik dokümanını esas alın.

Karar noktası: Ham değer fiziksel değişime tepki veriyor mu?

• Evet: Sensör okuma aşaması büyük ölçüde çalışıyor; bir sonraki adım Wi-Fi bağlantısını kontrol etmektir.
• Hayır: HTTP kodunu değiştirmeden önce kablo, GND, besleme, okuma türü, pin seçimi ve sensörün başlatma koduna dönün.
• Değer anlamsız veya taşmış görünüyorsa: Yanlış pin, yanlış veri tipi, yanlış sensör kütüphanesi kullanımı veya sensörün beklediği başlatma adımının eksik olması ihtimallerini inceleyin.

2. Doğrula: Ölçüm geçersiz mi, yoksa sabit mi?

“Sensör sürekli aynı değeri gösteriyor” şikâyeti iki farklı duruma işaret edebilir. Birinci durumda sensör gerçekten değişmeyen bir ortamı ölçüyordur. İkinci durumda ise veri hattı, okuma fonksiyonu veya yazılım akışı hatalıdır.

Değerin sabit kalması durumunda şu kısa kontrol sırasını uygulayın:

1. Ham değeri HTTP gövdesinden bağımsız olarak yazdırın.
2. Fiziksel koşulu kontrollü biçimde değiştirin.
3. Değişim yoksa veri kablosunu ve GND bağlantısını yeniden kontrol edin.
4. Analog giriş kullanıyorsanız seçilen pinin kart modelinizde gerçekten uygun olup olmadığını doğrulayın.
5. Dijital sensör kullanıyorsanız başlatma fonksiyonunun ve sensör adresinin doğru olduğunu kontrol edin.
6. Değer değişiyor fakat JSON içindeki alan sabit kalıyorsa, JSON oluşturma kodunu inceleyin.

Örneğin seri portta ham değer değişirken gönderilen JSON her defasında aynı sayıyı içeriyorsa sorun sensör bağlantısında değil, ölçüm değerinin yanlış değişkene aktarılmasında veya JSON’un yalnızca bir kez oluşturulmasında olabilir. Tersine, JSON değişiyor fakat sunucudaki kayıt sabitse bu kez REST sunucusunun veri doğrulama, önbellekleme veya kayıt mantığı incelenmelidir.

3. Bağlan: Wi-Fi durumunu ve alınan IP adresini loglayın

Sensör ölçümü doğru olduktan sonra ESP32’nin ağa bağlanıp bağlanmadığını kontrol edin. Sadece “Wi-Fi bağlandı” mesajı yeterli değildir; bağlantı durumunu ve alınan IP adresini de yazdırın.

Serial.print("Wi-Fi durumu: ");
Serial.println(WiFi.status());

if (WiFi.status() == WL_CONNECTED) {
  Serial.print("Alinan IP: ");
  Serial.println(WiFi.localIP());
} else {
  Serial.println("Wi-Fi baglantisi yok");
}

Wi-Fi bağlantısı kopuyorsa önce SSID ve parolanın doğru sağlandığını, erişim noktasının kapsama alanını ve kartın gerçekten beklenen ağa bağlanıp bağlanmadığını kontrol edin. Daha sonra bağlantı kopmasının yalnızca başlangıçta mı, yoksa belirli bir süre sonra mı oluştuğunu gözlemleyin.

Bağlantı sırasında şu ayrımı yapın:

• Hiç IP alınmıyorsa: Kimlik bilgileri, erişim noktası, güvenlik ayarı veya sinyal koşulları incelenmelidir.
• IP alınıyor fakat istek gitmiyorsa: DNS, port, URL, yerel ağ erişimi veya sunucu dinleme ayarı kontrol edilmelidir.
• İlk istek gidiyor, sonraki istekler gitmiyorsa: Yeniden bağlanma akışı, bağlantının kapatılması, zamanlama ve sunucunun bağlantıyı nasıl sonlandırdığı incelenmelidir.

Gerçek Wi-Fi bilgilerini kaynak koduna açık biçimde yazmak yerine, proje sırasında güvenli bir yapılandırma yöntemi kullanın. Seri port loglarında SSID parolasını veya API anahtarını kesinlikle yazdırmayın.

4. DNS ve yerel ağ erişimini ayırın

Wi-Fi’ye bağlanmak, REST sunucusuna ulaşılabildiği anlamına gelmez. ESP32 IP adresi almış olabilir; ancak alan adı çözümlenemiyor, sunucu farklı bir ağda bulunuyor, port kapalı veya yönlendirici cihazlar arası iletişime izin vermiyor olabilir.

Teşhisi şu sorularla daraltın:

1. REST URL’sindeki alan adı veya IP adresi doğru mu?
2. URL’de yazan port, sunucunun gerçekten dinlediği port mu?
3. Uç nokta aynı yerel ağda mı, yoksa internet üzerinden mi erişilecek?
4. Yerel ağdaki başka bir cihazdan aynı URL’ye erişilebiliyor mu?
5. Sunucu logunda ESP32’den gelen bir bağlantı veya istek görünüyor mu?
6. Alan adı kullanılıyorsa DNS çözümlemesi gerçekleşiyor mu?

Yerel ağdaki bir sunucuya bağlanıyorsanız, bilgisayarın tarayıcıdan açabildiği bir adresin ESP32 tarafından da aynı şekilde erişilebilir olduğunu varsaymayın. Bilgisayar kablolu ağda, ESP32 kablosuz ağda olabilir; misafir ağı istemciler arası iletişimi engelliyor olabilir veya sunucu yalnızca localhost üzerinde dinliyor olabilir.

5. Gönder: HTTP isteğinin gerçekten oluşturulduğunu doğrulayın

Wi-Fi ve ağ erişimi doğrulandıktan sonra HTTP katmanına geçin. İsteğin başarısız olması, sunucunun isteği reddettiği anlamına gelmeyebilir. ESP32 sunucuya hiç ulaşamamış da olabilir.

İstek öncesinde hassas bilgileri yazdırmadan şu bilgileri loglayabilirsiniz:

• İsteğin başlayacağı zamanı veya sıra numarasını,
• URL’nin alan adı ve yol kısmını,
• HTTP metodunu, örneğin POST,
• Gönderilecek JSON alan adlarını,
• Ölçümün güvenli biçimde yuvarlanmış veya sınırlanmış değerini,
• İsteğin tamamlanıp tamamlanmadığını.

REST sunucusunun beklediği HTTP metodu, JSON şeması, kimlik doğrulama yöntemi ve hata yanıtı biçimi mutlaka o sunucunun kendi dokümantasyonundan doğrulanmalıdır. Örneğin sunucu POST yerine PUT bekliyor olabilir; temperature alanı yerine value istiyor olabilir veya kimlik doğrulamasını başlıkta değil farklı bir mekanizma ile yapıyor olabilir. Bu ayrıntılar tüm REST sunucuları için ortak değildir.

6. Yanıtı kontrol et: Negatif hata kodu ile HTTP durum kodunu karıştırmayın

Arduino-ESP32 HTTPClient akışında pozitif bir değer, sunucudan HTTP yanıtı alındığını gösterir; negatif değer ise bağlantı, gönderim veya okuma gibi istemci tarafı bir hataya işaret edebilir. Bu nedenle yalnızca “kod negatif” demek yerine hata metnini ve hangi aşamada oluştuğunu loglayın. HTTPClient kaynak kodunda bağlantı reddedilmesi ve okuma zaman aşımı gibi istemci hataları ayrı hata durumları olarak ele alınır. ([github.com](https://github.com/espressif/arduino-esp32/blob/master/libraries/HTTPClient/src/HTTPClient.cpp?utm_source=openai))

Pozitif HTTP kodu aldıktan sonra yanıt gövdesini de okuyun. Sunucu 400 döndürdüğünde nedenini JSON gövdesinde belirtebilir; boş gövde de döndürebilir. Yanıt gövdesi incelenmeden yalnızca durum koduna bakmak, hatanın JSON alan adından mı, yetkilendirmeden mi veya sunucu içindeki işlemden mi kaynaklandığını anlamayı zorlaştırır.

[SENSOR] raw=684
[WIFI] status=connected
[WIFI] ip=192.168.1.42
[HTTP] POST basladi
[HTTP] code=201
[HTTP] response={"accepted":true}
[LOG] gonderim tamamlandi

Bu akışta her aşama ayrı loglandığı için sorunun nerede oluştuğu hızlıca anlaşılır. Örneğin [SENSOR] satırı var, fakat [WIFI] satırı yoksa sorun HTTP’den önce başlamıştır. [HTTP] POST basladi görülüyor ancak [HTTP] code satırı gelmiyorsa bağlantı kurulması veya yanıtın okunması beklenirken zaman aşımı yaşanıyor olabilir.

Hata senaryoları ve ilk müdahale tablosu

Wi-Fi kopması nasıl teşhis edilir?

ESP32 bağlantısı belirli aralıklarla kopuyorsa her ölçümden önce yalnızca bir kez bağlantı kontrolü yapmak yeterli olmayabilir. Döngü içinde Wi-Fi durumunu gözlemleyin ve kopma anını kaydedin.

• Kopma her zaman aynı sürede oluyorsa zamanlama, güç beslemesi veya erişim noktası davranışını inceleyin.
• Kopma yalnızca HTTP isteğinden sonra oluyorsa bağlantının kapatılması, sunucu yanıtı veya yeniden bağlanma kodunu kontrol edin.
• Kopma sensör okuması sırasında oluyorsa güç kararlılığı ve kablo bağlantılarını gözden geçirin.
• Kopmadan sonra cihaz tekrar bağlanıyorsa, veri gönderme işlemini bağlantı kurulmadan başlatmayın.
• Tekrar bağlanma döngüsünde uzun süre bloklanan kod varsa, ölçüm zamanlamasının bu durumdan nasıl etkileneceğini belirleyin.

Programlama temellerini güçlendirmek isteyen bir maker için bu tür teşhis akışları, yalnızca kütüphane komutlarını ezberlemekten daha değerlidir. Değişkenler, koşullar, fonksiyonlar ve hata durumları üzerine çalışmak isteyenler ücretsiz kodlama bilgi testi ile mevcut seviyelerini ölçebilir.

4xx ve 5xx yanıtlarını nasıl ayırabilirsiniz?

HTTP durum kodlarının ilk rakamı, yanıt sınıfını gösterir. 4xx aralığı istemcinin gönderdiği istekle ilgili bir problem olduğunu; 5xx aralığı ise sunucunun isteği işlerken sorun yaşadığını ifade eder. Ancak bu ayrım, istemcinin hiç sunucuya ulaşamadığı negatif HTTPClient hata kodlarıyla aynı şey değildir. HTTP durum kodları 400–499 ve 500–599 aralıklarında sınıflandırılır. ([developer.mozilla.org](https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Status?utm_source=openai))

• 400: JSON biçimi, zorunlu alan veya istek yapısı hatalı olabilir.
• 401: Kimlik doğrulama bilgisi eksik veya geçersiz olabilir.
• 403: Kimlik bilinse bile erişim yetkisi bulunmayabilir.
• 404: URL yolu veya kaynak yanlış olabilir.
• 405: Uç nokta kullanılan HTTP metodunu desteklemiyor olabilir.
• 415: Gönderilen içerik türü, örneğin application/json, beklenen formatla uyuşmuyor olabilir.
• 429: Çok kısa aralıklarla fazla istek gönderiliyor olabilir.
• 500: Sunucu içinde beklenmeyen bir hata oluşmuş olabilir.
• 502 veya 504: Ağ geçidi ya da arka uç sunucu yanıtı ile ilgili sorun yaşanıyor olabilir.

4xx yanıtında aynı isteği hiçbir değişiklik yapmadan tekrar tekrar göndermek genellikle sorunu çözmez. Önce URL, metod, başlıklar, JSON alanları ve kimlik doğrulama bilgileri incelenmelidir. 5xx yanıtında ise sunucu logu ve isteğin sunucuya hangi içerikle ulaştığı kontrol edilmelidir.

Uygulama Öncesi Kontrol Listesi ve Projeyi Genişletme

ESP32 kodunu yüklemeden ve gerçek bir sunucuya veri göndermeden önce aşağıdaki kontrol listesini tamamlayın. Bu liste, donanım kaynaklı hatalarla HTTP kaynaklı hataları daha en başta ayırmayı amaçlar.

Kod yüklemeden önce kontrol listesi

• Kullandığınız ESP32 kart modelinin pinout belgesi doğrulandı mı?
• Sensörün VCC ve GND bağlantıları kartın ve sensörün gereksinimleriyle uyumlu mu?
• ESP32 ile sensör arasında ortak GND var mı?
• Sensör analog mu, dijital mi? Kodda doğru okuma yöntemi kullanılıyor mu?
• Seçilen pin, kullandığınız kart modelinde gerçekten uygun mu?
• Ham sensör ölçümü HTTP isteği olmadan seri portta makul ve değişken görünüyor mu?
• Wi-Fi bilgileri gerçek parola yerine güvenli bir yapılandırma yöntemiyle sağlanıyor mu?
• REST URL’si, portu ve uç nokta yolu sunucunun dokümanıyla eşleşiyor mu?
• JSON alan adları, veri tipleri ve zorunlu alanlar sunucunun beklediği şemayla uyumlu mu?
• Content-Type: application/json başlığı gerektiği şekilde ekleniyor mu?
• HTTP yanıt kodu ve yanıt gövdesi seri porta loglanıyor mu?
• Zaman aşımı süresi ve Wi-Fi yeniden bağlanma davranışı tanımlı mı?
• API anahtarı, parola veya sertifika gibi hassas bilgiler seri porta yazdırılmıyor mu?
• İstek başarısız olduğunda cihazın sonsuz ve kontrolsüz bir tekrar döngüsüne girmesi engelleniyor mu?

Kullanılacak Arduino geliştirme ortamı, ESP32 kart desteği, sensör kütüphanesi, REST sunucusu ve ağ bileşenlerinin kurulum adımları proje tarihinde kullanılan sürümlere göre ayrıca doğrulanmalıdır. Özellikle kart seçimi, seri port, kütüphane bağımlılıkları ve sunucunun yerel ağdan erişilebilir olması aynı projede birlikte kontrol edilmelidir. Arduino-ESP32 belgelerinde Wi-Fi olayları, bağlantı durumu ve istasyon modu için kullanılan API’ler güncel kurulumla birlikte takip edilmelidir. ([docs.espressif.com](https://docs.espressif.com/projects/arduino-esp32/en/latest/api/wifi.html?utm_source=openai))

İlk çalışan sürümde hangi davranışlar yeterlidir?

Başlangıç seviyesinde hedef, aynı anda çok sayıda özelliği eklemek değil, ölçümden sunucu yanıtına kadar izlenebilir bir akış oluşturmaktır. İlk sürümde şu davranışlar yeterli bir temel sağlar:

1. Belirli bir zaman aralığında sensörden ölçüm al.
2. Ham değerin geçerli olup olmadığını kontrol et.
3. Wi-Fi bağlantısını kontrol et.
4. Bağlantı yoksa yeniden bağlanmayı dene.
5. Geçerli ölçümü JSON gövdesine dönüştür.
6. HTTP POST isteğini gönder.
7. Durum kodunu ve yanıt gövdesini kaydet.
8. Başarısız isteği hemen sınırsız biçimde tekrarlama.

Bu akış çalıştıktan sonra projeyi kontrollü biçimde genişletebilirsiniz. Her yeni özellik, teşhisi zorlaştırmaması için ayrı bir adım olarak eklenmelidir.

Projeyi güvenli ve anlaşılır biçimde genişletme

Ölçüm zamanlaması: Her döngünün sonunda sabit bir gecikme kullanmak yerine ölçüm aralığını bilinçli olarak tanımlayın. Çok sık ölçüm almak gereksiz ağ trafiği ve sunucu yükü oluşturabilir; çok seyrek ölçüm almak ise değişimleri kaçırabilir.

Yeniden bağlanma: Wi-Fi koparsa önce mevcut durumu loglayın, ardından kontrollü bir yeniden bağlanma denemesi yapın. Yeniden bağlanma sırasında sensör okumalarının ve HTTP isteklerinin nasıl davranacağını belirleyin.

Tekrar gönderim: Ağ hatasında aynı veriyi yeniden göndermek bazı projelerde yararlı olabilir; ancak sunucu aynı ölçümü iki kez kaydedebilir. Bu nedenle ölçüme bir sıra numarası veya cihaz tarafı zaman bilgisi eklemek, tekrar gönderim kararını daha sonra kolaylaştırabilir.

Yerel önbellekleme: Bağlantı geçici olarak yoksa veriyi RAM’de sınırlı sayıda tutmak başlangıç için düşünülebilir. Daha uzun süreli saklama gerekiyorsa bellek kapasitesi, güç kesintisi ve veri kaybı ayrıca ele alınmalıdır. Önbellek sınırsız büyümemeli; dolduğunda hangi verinin silineceği önceden belirlenmelidir.

Kalibrasyon: Sensörün ham değerini doğrudan gerçek fiziksel birime çevirmek yerine, bilinen bir referansla karşılaştırma yapın. Kalibrasyon katsayılarını kodun içine dağınık biçimde yazmak yerine tek bir bölümde tutmak, daha sonra düzeltme yapmayı kolaylaştırır.

Sunucu tarafında doğrulama: ESP32’den gelen veriye tamamen güvenilmemelidir. Sunucu; beklenen alanların bulunup bulunmadığını, veri tiplerini, kabul edilebilir aralıkları, cihaz kimliğini ve istek sıklığını kontrol etmelidir. İstemci tarafındaki doğrulama kullanıcı deneyimini iyileştirir; sunucu tarafındaki doğrulama ise sistemin güvenilirliğini korur.

HTTPS ve TLS için başlangıç düzeyinde sınırlar

HTTPS kullanmak, HTTP isteğinin TLS ile şifreli bir taşıma katmanı üzerinden yapılmasını sağlar; fakat yalnızca URL’nin başına https:// yazmak güvenli bir sistem kurmak için yeterli değildir. Sunucu sertifikasının doğrulanması, kök sertifikanın cihaza sağlanması, alan adı eşleşmesi, sertifika süresi ve cihazın doğru zamana sahip olması gibi konular ayrıca değerlendirilmelidir.

Espressif belgeleri, sunucu doğrulaması gerektiğinde uygun kök sertifikanın istemci yapılandırmasına verilmesi gerektiğini belirtir. Sertifika doğrulamasını tamamen devre dışı bırakmak bağlantıyı test etmeyi kolaylaştırabilir; ancak aradaki kötü niyetli bir aracının sunucu gibi davranması riskini artırır. Bu nedenle doğrulamayı kapatmak, gerçek kullanıcı verileri veya hassas kimlik bilgileri gönderen kalıcı projeler için varsayılan çözüm olarak görülmemelidir. ([docs.espressif.com](https://docs.espressif.com/projects/esp-idf/en/v5.3-rc1/esp32/esp-idf-en-v5.3-rc1-esp32.pdf?utm_source=openai))

Başlangıç projesinde önce yerel ve kontrollü bir HTTP akışıyla ölçüm–yanıt döngüsünü doğrulamak, ardından HTTPS sertifika doğrulamasını ayrı bir aşama olarak eklemek daha anlaşılır olabilir. Ancak gerçek sisteme geçerken kimlik doğrulama, sertifika yönetimi ve hassas bilgilerin saklanması yeniden gözden geçirilmelidir.

Programlama temellerini pekiştirmek isteyen okuyucular, genel video yazılım eğitimleri ile değişkenler, koşullar, fonksiyonlar ve hata ayıklama konularını çalışabilir. Bu yönlendirme bir donanım veya IoT eğitimi iddiası değildir; amaç ESP32 projesinde kullanılan temel programlama becerilerini güçlendirmektir.

Sık Sorulan Sorular

ESP32 sensör verisini HTTP ile göndermek için internete bağlı olması şart mı?

Hayır. ESP32 ile REST sunucusu aynı yerel ağda bulunuyorsa internet bağlantısı olmadan da HTTP üzerinden veri gönderilebilir. İnternet, sunucunun farklı bir ağda veya uzakta bulunması durumunda gerekir. Her iki durumda da ESP32’nin hedef IP adresine veya alan adına ve ilgili porta erişebilmesi gerekir.

ESP32’den gelen HTTP isteğinde 4xx ve 5xx durum kodları nasıl ayırt edilir?

HTTP durum kodunun ilk rakamına bakılır. 400–499 aralığı istemci isteğiyle, 500–599 aralığı ise sunucunun isteği işlerken yaşadığı sorunlarla ilişkilidir. Örneğin 400 hatalı istek biçimini, 401 kimlik doğrulama gereksinimini, 404 yanlış yolu, 500 ise sunucu tarafındaki beklenmeyen hatayı gösterebilir. HTTPClient’ın negatif hata kodları ise sunucudan 4xx veya 5xx yanıtı alınmadan önce oluşan bağlantı ya da okuma sorunlarını ifade edebilir.

Sensör ölçümü sürekli aynı değeri gösteriyorsa hangi bağlantılar ve ayarlar kontrol edilmelidir?

Önce sensörün VCC, GND ve veri hattı kontrol edilmelidir. Ardından ESP32 ile sensörün ortak GND kullandığı, doğru pinin seçildiği, analog veya dijital okuma yönteminin sensörle uyumlu olduğu ve ham değerin fiziksel değişime tepki verip vermediği incelenmelidir. Ham değer değişiyor fakat JSON sabit kalıyorsa değişken aktarımı ve JSON oluşturma kodu kontrol edilmelidir.

ESP32 ile HTTPS kullanırken TLS ve sertifika doğrulaması neden ayrıca ele alınmalıdır?

HTTPS, veriyi şifreli taşımaya yardımcı olur; ancak istemcinin gerçekten doğru sunucuya bağlandığını doğrulamak için sertifika ve alan adı kontrolleri gerekir. Kök sertifikanın sağlanmaması veya sertifika doğrulamasının devre dışı bırakılması, bağlantının şifreli görünmesine rağmen sahte bir sunucuya bağlanma riskini artırabilir. Bu nedenle TLS ayarları, sertifika yönetimi ve cihaz saatinin güvenilirliği gerçek projeye geçmeden önce test edilmelidir.

ESP32 sensör projesinde güvenilir sonuç, tek bir HTTP komutundan değil; ölçümü doğrulayan, bağlantıyı izleyen, yanıtı kontrol eden ve her adımı anlaşılır biçimde loglayan düzenli bir akıştan oluşur.