Bir şarj cihazı uzun süre şarj yapmasa bile çevrimiçi olduğunu yönetim yazılımına bildirmelidir. Bu bildirim için kullanılan OCPP mesajının adı Heartbeat'tir (kalp atışı). Mesajın kendisi çok basittir, ancak hangi aralıkla gönderildiği hem arıza tespitini hem de mobil veri maliyetini etkiler.
Heartbeat ne işe yarar?
Heartbeat'in üç temel görevi vardır:
- Canlılık bildirimi: CSMS, cihazın bağlı ve çalışır olduğunu bilir.
- Saat senkronizasyonu: Heartbeat'in cevabında güncel zaman (
currentTime) bulunur; cihaz saatini bununla düzeltebilir. - Bağlantıyı canlı tutma: Bazı mobil operatörler ve ağ cihazları uzun süre sessiz kalan bağlantıları kapatır; düzenli trafik bunu önler.
İstek ve cevap şöyle görünür:
[2, "2001", "Heartbeat", {}] [3, "2001", {"currentTime": "2026-10-02T10:15:00Z"}]
HeartbeatInterval nereden gelir?
Aralık, BootNotification cevabındaki interval alanıyla cihaza bildirilir. OCPP 1.6J'de cihaz yapılandırmasındaki HeartbeatInterval anahtarı ile de değiştirilebilir (ChangeConfiguration). OCPP 2.0.1 ve 2.1'de aynı ayar cihaz modelinde OCPPCommCtrlr.HeartbeatInterval değişkeni olarak bulunur ve SetVariables ile değiştirilir.
Önemli bir ayrıntı: OCPP 1.6J'de cihaz, son Heartbeat'ten sonra başka bir mesaj gönderdiyse Heartbeat'i atlayabilir; çünkü her mesaj zaten cihazın canlı olduğunu gösterir. Bu yüzden şarj sırasında Heartbeat seyrekleşebilir.
Kaç saniye olmalı?
Tek doğru değer yoktur; ihtiyaç ve bağlantı türüne göre değişir. Pratik aralıklar:
- 60–300 saniye: Kamuya açık, durumu yakından izlenmesi gereken cihazlar için yaygın tercih. Bağlantı kopmaları birkaç dakika içinde fark edilir.
- 300–900 saniye: Özel otoparklar, siteler ve iş yerleri için yeterlidir.
- 900 saniyenin üstü: Veri tüketimini en aza indirmek gerektiğinde, ancak arıza tespiti gecikir.
Unutmayın ki Heartbeat dışındaki mesajlar (durum değişikliği, ölçüm değerleri) da trafik üretir. Heartbeat'i aşırı sıklaştırmak çoğu zaman gereksiz veri tüketir; aşırı seyreltmek ise kopuk bir cihazı saatlerce fark etmemenize neden olabilir.
WebSocket ping ile farkı
OCPP-J'de WebSocket protokolünün kendi ping/pong mekanizması da vardır. OCPP 1.6J'de bunun aralığı WebSocketPingInterval anahtarıyla ayarlanır. Ping/pong, bağlantının ağ seviyesinde açık kalmasını sağlar; Heartbeat ise uygulama seviyesinde "cihaz çalışıyor" bilgisini verir. İkisi birbirinin yerine geçmez. İyi bir kurulumda WebSocket ping daha sık (örneğin 30–60 saniye), Heartbeat daha seyrek tutulabilir.
Heartbeat gelmiyorsa ne yapmalı?
CSMS, beklenen sürenin birkaç katı boyunca hiçbir mesaj almazsa cihazı çevrimdışı kabul etmelidir. Nedenler genellikle şunlardır:
- İnternet bağlantısı veya SIM kart sorunu,
- Cihazın elektriğinin kesilmesi,
- Firmware'in donması,
- Sunucu tarafında bağlantının kapatılması.
Ayrıntılı bir kontrol listesi için OCPP bağlantısı neden kopar yazımıza bakabilirsiniz.
Panelde izleme
Heartbeat'i tek başına izlemek yerine "son mesaj zamanı"nı izlemek daha doğrudur. Üreticy'nin OCPP yazılımı, her cihazın son iletişim zamanını gösterir ve bağlantı koptuğunda panelde uyarı üretir. Bu uyarıların hangi süreden sonra tetikleneceği, Heartbeat aralığınızla uyumlu olmalıdır.
Mobil hatlarda veri hesabı
Heartbeat mesajı ve cevabı birlikte, WebSocket ve TLS ek yükleriyle beraber kabaca birkaç yüz bayt tutar. 60 saniyelik aralıkla bir cihaz günde 1.440 Heartbeat gönderir; bu ayda birkaç megabayta karşılık gelir. Tek başına küçük görünse de yüzlerce cihazlık bir ağda ve dar kotalı M2M hatlarında fark yaratır. 300 saniyeye çıkmak bu tüketimi beşte birine indirir. Asıl veri tüketimi çoğu zaman MeterValues örnekleme aralığından gelir; bu yüzden iki ayarı birlikte değerlendirmek gerekir. Ayrıntılar için MeterValueSampleInterval yazımıza bakabilirsiniz.
Önerilen başlangıç noktası şudur: kamuya açık cihazlarda Heartbeat 300 saniye, WebSocket ping 60 saniye ve çevrimdışı uyarısı 15 dakika. Ağınızın davranışını birkaç hafta izledikten sonra bu değerleri ihtiyacınıza göre ayarlayabilirsiniz.
Sonuç
Heartbeat basit ama kritik bir mesajdır: cihazın yaşadığını gösterir, saati düzeltir ve bağlantıyı canlı tutar. Kamuya açık cihazlarda birkaç dakikalık, özel kullanımlarda daha uzun aralıklar uygundur. Aralığı belirlerken veri maliyeti ile arıza tespit hızı arasındaki dengeyi gözetin.