Bir makinenin çalışıp çalışmadığını, bir deponun sıcaklığını veya bir çevrimin kaç saniye sürdüğünü bilmek için her zaman büyük bir otomasyon yatırımı gerekmez. ESP32 tabanlı bir veri toplama birimi, doğru sınırlar içinde tasarlandığında küçük bir izleme projesini ekonomik hale getirebilir. Asıl mühendislik sorusu kartın internete bağlanması değil; ölçümün güvenilirliği, bağlantı kesildiğinde davranış ve üretim sisteminden nasıl ayrıldığıdır.
01Önce izleme ile kontrolü ayırın
İzleme sistemi mevcut durumu kaydeder; kontrol sistemi ise makinenin hareketini ve prosesini yönetir. Bir sıcaklık ölçümünün birkaç saniye gecikmesi raporu etkileyebilir. Buna karşılık bir eksenin durdurulmasının gecikmesi fiziksel tehlike oluşturabilir. Bu nedenle aynı donanım maliyetine bakılarak iki görev birbirinin yerine konamaz.
ESP32, çevresel ölçüm, enerji analizöründen veri okuma, bağımsız parça sayımı ve bakım amacıyla durum kaydı gibi işlerde değerlendirilebilir. Güvenlik fonksiyonları, deterministik hareket kontrolü ve prosesin güvenli sınırlarını koruyan işlevler uygun endüstriyel kontrol mimarisinde kalmalıdır. Standart bir PLC de tek başına güvenlik PLC'si değildir; güvenlik görevi ayrıca tasarlanır.
02Saha sinyalini GPIO'ya doğrudan bağlamayın
Bir geliştirme kartının girişleri, endüstriyel bir giriş modülüyle aynı elektriksel dayanıklılığa sahip değildir. Makineden gelen 24 V durum sinyali için uygun seviye uyarlaması, giriş koruması ve gerekiyorsa galvanik izolasyon gerekir. Analog ölçümde yalnızca ADC çözünürlüğüne bakmak yetmez: referans kararlılığı, sensör doğruluğu, kablo etkisi ve kalibrasyon da toplam hatayı belirler.
4–20 mA veya 0–10 V sinyal alınacaksa uygun bir analog ön uç seçilir. Kablo uzunluğu, ortak-mod gerilimi ve cihazların toprak ilişkisi değerlendirilir. Hazır endüstriyel sensörün RS-485 çıkışını okumak, hassas bir analog ölçüm devresini sıfırdan kurmaktan daha yönetilebilir olabilir. Seçim, ölçülecek büyüklüğe ve bakım ekibinin yetkinliğine göre yapılmalıdır.
03Veri sözleşmesi: sayı tek başına yeterli değildir
Her kayıt için cihaz kimliği, ölçüm zamanı, mühendislik birimi ve veri kalitesi tutulmalıdır. “Sıcaklık 28,4” mesajı, ölçümün beş dakika önce alındığı bilinmiyorsa yanıltıcıdır. Sensör kopması, zaman bilgisinin güvenilmez olması ve ölçüm aralığı dışı değer, ayrı kalite durumlarıyla işaretlenebilir.
{
"device": "izleme-01",
"sequence": 1842,
"temperature_c": 28.4,
"quality": "good",
"timestamp": "2026-10-27T09:30:00Z"
}
Bu şema açıklama amaçlıdır. Gerçek projede zaman kaynağı, yeniden başlama sonrası sıra numarası davranışı ve eksik verinin nasıl gösterileceği birlikte tanımlanır. Sunucunun mesajı aldığı saat ile sensörün ölçüm saati aynı kabul edilmemelidir.
04Bağlantı kesintisini normal bir durum olarak tasarlayın
Wi-Fi bağlantısı kalabalık kanallar, metal pano, anten yerleşimi veya erişim noktası değişimi nedeniyle kesilebilir. Yazılımın sonsuza kadar bağlantı beklemesi, ölçüm görevini de durdurmamalıdır. Ölçüm ve haberleşme işleri ayrılmalı; yeniden bağlanma denemeleri kontrollü aralıklarla yapılmalıdır.
MQTT kullanmak tek başına veri kaybını çözmez. QoS seçimi, istemcinin kalıcı oturumu, sunucu davranışı ve cihazdaki tampon birlikte ele alınır. Tekrar gelen mesajlar için cihaz kimliği ve sıra numarasıyla ayıklama yapılabilir. Her örneği flash belleğe yazmak yerine yazma ömrünü dikkate alan tamponlama ve toplu kayıt stratejisi seçilir.
05Bir pilot uygulamayı nasıl boyutlandırırız?
Örnek olarak beş soğuk depodan dakikada bir sıcaklık kaydı aldığımızı varsayalım. Günde 5 × 1.440 = 7.200 kayıt oluşur. Kayıt başına 100 baytlık ham veri varsayımı yaklaşık 720 kB/gün eder; protokol, indeks ve veritabanı ek yükleri buna dahil değildir. Bu hesap, “çok az veri” düşüncesini somut bir depolama ve kesinti bütçesine dönüştürür.
| Karar | Pilot uygulamada sorulacak soru |
|---|---|
| Örnekleme | Prosesin değişim hızı için bir dakika yeterli mi? |
| Kesinti toleransı | Ağ yokken kaç saatlik kayıt korunmalı? |
| Zaman | Enerji kesilince ölçüm saati nasıl doğrulanacak? |
| Alarm | Eski veri ile gerçek sıcaklık alarmı ayrılıyor mu? |
| Bakım | Kart ve sensör değişiminde kimlik nasıl taşınacak? |
06Kabul testinde yalnızca normal çalışmayı denemeyin
Sensör bağlantısını kesmek, erişim noktasını kapatmak, sunucuyu erişilemez yapmak ve beslemeyi kontrollü biçimde kesip geri vermek test senaryolarının parçasıdır. Cihazın geri döndüğünde yanlış sayaç üretmediği, tamponu doğru sırayla boşalttığı ve eski veriyi yeniymiş gibi göstermediği kontrol edilir.
Besleme ve anten yerleşimi için kullanılan ESP32 varyantının üretici tasarım kılavuzu izlenmelidir. Endüstriyel kutu, bağlantı elemanları ve ortam koşulları geliştirme kartından ayrı değerlendirilir. Sonuçta başarılı pilot, yalnızca bir grafiğin görünmesi değil; aynı ölçümün bakım yapılabilir ve hatası anlaşılabilir biçimde tekrar elde edilmesidir.
07Örnek doğrulama senaryosu
Pilot kabulünde bir saatlik ağ kesintisi senaryosu tanımlandığını varsayalım. Cihaz kesinti boyunca ölçmeye devam etmeli, yeniden bağlanınca kayıtları özgün ölçüm zamanlarıyla göndermeli ve aynı kaydı iki kez toplam sonuca katmamalıdır. Ardından enerji kesintisi denenerek tamponun hangi bölümünün kalıcı olduğu doğrulanır. Son raporda kayıp kayıt sayısı, toparlanma süresi ve saat sapması ayrı yazılır. Bir grafiğin kesintisiz çizilmesi tek başına yeterli kanıt değildir; sunucu interpolasyonu veri kaybını gizleyebilir.
Teknik kaynaklar ve ileri okuma
Ürün ve sürüm özelindeki değerler için ilgili üreticinin güncel dokümanı esas alınmalıdır. Yukarıdaki hesaplar ve senaryolar açıklama amaçlı mühendislik örnekleridir.
