Kamera Analitik Olaylarını Başka Sistemlere Bağlama: HTTP Bildirim (Webhook), MQTT ve Röle ile Işık, Siren, Kapı ve POS Kaydı Tetikleme

Analitik olayı başka sistemi hangi yollarla tetikler?

Bir kamera ya da NVR analitik olay ürettiğinde bunu dışarıya beş ana yolla iletebilir. Hangi yolun seçileceği, karşıdaki sistemin ne kadar bilgiye ihtiyaç duyduğuna bağlıdır: ışık yakmak için tek bir kontak yeterken, POS fişi eşleştirmek için olayın zamanı, türü ve kanalı gibi veriler gerekir.

• Alarm çıkışı / röle: Kamera veya NVR üzerindeki kuru kontak, bağlı cihazı doğrudan açar ya da kapatır. Ağ gerektirmez.
• HTTP/HTTPS bildirim (webhook): Olay olunca cihaz, tanımlı bir adrese istek gönderir; alıcı yazılım bunu işler.
• MQTT: Cihaz olayı bir aracıya (broker) yayımlar; abone olan sistemler mesajı anında alır.
• E-posta veya FTP ile resim: Olay anının görüntüsü gönderilir; insanın okuması için uygundur, otomasyon için zayıf bir yoldur.
• SDK / API: Yazılım, cihaza bağlanıp olay akışını kendisi dinler; en esnek ama en çok geliştirme gerektiren yoldur.

Kamera alarm çıkışı ve röle: ışık, siren ve kapı için en sade yol

Röle çıkışı, analitik olayı fiziksel bir eyleme çeviren en sade ve en bağımsız yöntemdir. Kamera ya da NVR alarm çıkışı genellikle düşük akımlı kuru kontaktır; ışık, siren, kapı kilidi veya alarm paneli girişi gibi yükler doğrudan bağlanmaz, araya yardımcı röle ya da kontaktör konur. Kontağın taşıyabileceği akım ve gerilim üretici belgesinde yazar; bu değer aşılırsa çıkış zarar görür.

Çıkışın kamerada mı NVR'de mi alınacağı bir tasarım kararıdır. Kamera çıkışı, kayıt cihazı kapalı ya da ağ kopuk olsa bile çalışır ve gecikmesi düşüktür; ancak her kameraya ayrı kablo ve ayrı yardımcı güç gerekebilir. NVR çıkışı merkezi toplanır, ama çıkış sayısı sınırlıdır ve olayın NVR'ye ulaşması gerekir. Analitiğin kamerada mı NVR'de mi çalıştığı da bu kararı etkiler; konu yapay zekâlı kamerada edge mi sunucu mu rehberinde anlatılıyor.

Röle ayarında iki parametre sık atlanır: çıkışın ne kadar süre açık kalacağı ve kontağın normalde açık (NO) mı normalde kapalı (NC) mı çalışacağı.

Webhook, MQTT, e-posta/FTP ve SDK: hangisi ne zaman seçilir?

Webhook, olay gerçekleştiğinde cihazın önceden tanımlı bir web adresine otomatik istek göndermesidir; alıcı sistem bu isteği alınca kendi işini yapar. Kameranın HTTP bildirim ayarında genellikle hedef adres, yöntem (çoğunlukla POST), kimlik bilgisi ve gönderilecek içerik (olay türü, kanal, zaman damgası, bazen resim) tanımlanır.

Webhook basit gibi görünse de alıcı tarafın hazırlanması gerekir. Alıcı bir otomasyon yazılımı, küçük bir sunucu betiği ya da POS yazılımının sağladığı bir uç nokta olabilir. HTTP'nin tanımında POST yöntemi tekrar edildiğinde aynı sonucu garanti etmez (RFC 9110, idempotent yöntemler bölümü); yani aynı olay iki kez gelirse alıcı çift işlem yapabilir. Alıcıda olay numarası veya zaman damgasına bakarak tekrarı ayıklamak bu yüzden önemlidir.

MQTT, çok sayıda cihaz ve yazılımın aynı olayı eş zamanlı dinlemesi gerektiğinde webhook'tan daha uygundur. Cihaz mesajı bir konuya (topic) yayımlar; ışık kontrolcüsü, panel ve kayıt yazılımı aynı konuya abone olur. OASIS MQTT belirtimi üç hizmet kalitesi tanımlar: QoS 0 en fazla bir kez teslim (mesaj kaybolabilir), QoS 1 en az bir kez teslim (tekrar gelebilir), QoS 2 tam bir kez teslim.

Güvenlik olaylarında genellikle en az QoS 1 tercih edilir; böylece kayıp önlenir, tekrar ise alıcıda ayıklanır. MQTT'nin son istek (Last Will) özelliği, cihazın bağlantısı beklenmedik biçimde koptuğunda aracının önceden tanımlı bir mesajı yayımlamasını sağlar; bu, kamera ya da bağlantı arızasını fark etmek için kullanışlıdır. ONVIF Profile M, analitik olayların meta veri akışı, ONVIF olay servisi veya MQTT ile iletilebileceğini tanımlar; ayrıntısı ONVIF Profile M rehberinde yer alır.

E-posta ve FTP ile resim gönderme, olayı bir insana göstermek için yeterlidir ama otomasyon için gecikmeli ve ayrıştırması zordur. SDK/API ise üretici belgesine göre cihaza bağlanıp olay akışını okur; kendi yazılımını geliştiren entegratörler için uygundur, lisans ve sürüm uyumu ayrıca denetlenmelidir.

Örnek akışlar: gece ışık ve anons, aydınlatma, POS eşleştirme, alarm paneli

Aşağıdaki dört akış, aynı mantığın farklı eylemlerle uygulanmış halidir: olay, tetikleyici, eylem ve kayıt. Her akışta olay kaydı tutulması, sonradan neyin neden çalıştığını açıklamak için gereklidir.

• Gece bölge ihlalinde sarı ışık ve hoparlör anonsu: Mesai dışı zaman şablonunda, çevre bölgesinde insan algılanınca kamera alarm çıkışı yardımcı röle üzerinden sarı ışığı yakar ve aynı olay hoparlörde kayıtlı anonsu çalıştırır. Anons ayarları için kamera hoparlörüne özel uyarı anonsu rehberine bakılabilir.
• Kapı yakınında insan algılanınca aydınlatma açma: Kapı önüne çizilen bölgede insan algılanınca röle ışığı belli süre açar. Işık sensörü ya da gün saati koşuluyla birleştirilirse gündüz gereksiz tetikleme önlenir.
• Kasa işleminde kamera olay damgası ile POS fişini eşleştirme: POS yazılımı her fiş için işlem numarası ve saat bilgisini bir uç noktaya ya da kamera yazılımına gönderir; kamera da olay metnini (örneğin fiş numarası) görüntü üzerine yazar. Eşleşmenin güvenilir olması için kamera, NVR ve POS saatleri aynı zaman kaynağına (NTP) bağlanmalıdır. Çalışan izlemesi içeren her kullanımda KVKK aydınlatma yükümlülüğü ayrıca değerlendirilir.
• Alarm panelinin bölgesini tetikleme: Kamera çıkışı panelin bir bölge girişine bağlanır; böylece analitik olay, panelin kendi gecikme, devreye alma durumu ve izleme merkezine iletim mantığına girer. Bu bağlantıda kamera analitiği panelin tek tetikleyicisi olmamalı, doğrulama için ikinci bir dedektör ya da görüntü doğrulaması düşünülmelidir. Akıllı ev tarafındaki senaryolar için akıllı ev senaryoları ve otomasyon kuralları rehberi, kamera olaylarını açık kaynak yazılımla birleştirmek için Home Assistant ve Frigate rehberi bakılabilir.

Tetikleyici güvenilirliği ve tekrar tetikleme bekleme süresi

Otomasyonun doğruluğu, onu tetikleyen analitiğin doğruluğunu aşamaz. Yanlış pozitif oranı yüksek bir bölge ihlali kuralı, her yanlış alarmda siren çaldırır, ışık yakar ya da gereksiz bildirim gönderir; kaçırılan bir olayda ise hiçbir eylem gerçekleşmez. Bu nedenle eylem ne kadar etkiliyse (siren, kilit, panel alarmı) tetikleyici o kadar sıkı doğrulanmalıdır.

Etki seviyesine göre kademeli bir yapı kurmak makuldür: düşük etkili eylemleri (kayıt işareti, bildirim) tek analitik olayına bağlamak, yüksek etkili eylemleri ise iki koşula ya da insan onayına bağlamak. Sahada kabul testi ve yanlış/kaçırılan alarm sayımı için video analitik doğruluğu nasıl test edilir rehberindeki yöntem uygulanabilir.

Aynı nesne bölgede kaldıkça kural defalarca tetiklenebilir; bunu sınırlayan ayar bekleme süresidir (cooldown). Bekleme süresi dolmadan gelen yeni olaylar yok sayılır ya da aynı olay grubuna eklenir. Süre çok kısa tutulursa webhook alıcısı ve sirenler sürekli çalışır; çok uzun tutulursa gerçek ikinci olay kaçabilir.

Ağ güvenliği: HTTPS, yetki ve açık port

Bu liste, bir analitik olay entegrasyonunu teslim etmeden önce gözden geçirmek içindir; her madde yukarıda anlatılan bir riskin karşılığıdır.

Olay kaybı durumunda yedek ve test akışı

Ağ, aracı veya alıcı yazılım kesildiğinde olay kaybolabileceği için kritik akışlarda ikinci bir yol bulunmalıdır. Güvenlik açısından önemli eylemlerde röle çıkışı ağdan bağımsız çalıştığı için yedek olarak kullanılır; ağ üzerinden giden webhook ya da MQTT mesajı ise yalnızca ek bilgi taşıyan ikinci kanal olur. Her durumda olayın NVR'de kayıt işareti olarak da saklanması, sonradan ne olduğunu göstermeye yarar.

Alıcı tarafta kuyruklama ve hata kaydı tutmak, kayıp mesajın fark edilmesini sağlar. MQTT'de QoS 1 ile Last Will mesajı bağlantı kopmasını bildirir; webhook alıcısında ise belirli bir süre olay gelmemesi alarm üreten bir sağlık denetimi kurulabilir. Güç kesintisi ihtimali olan tesislerde röle yükünün (siren, ışık) ve ağ cihazlarının kesintisiz güç kaynağına bağlanması da yedek planın parçasıdır.

• Teslimattan önce her akış için bir test senaryosu yazılır: tetikleyici, beklenen eylem ve beklenen süre.
• Gerçek insan veya araç hareketiyle test yapılır; yalnızca arayüzdeki test düğmesi ağ yolunu ve analitiği sınamaz.
• Ağ kablosu çekilerek ve alıcı kapatılarak olay kaybı davranışı denenir.
• Aynı olay üst üste üretilerek bekleme süresinin çalıştığı görülür.
• Test sonuçları tarih ve kabul imzasıyla müşteriye yazılı bırakılır.

Kurulumcu için yapılandırma kontrol listesi

Aşağıdaki liste, bir analitik olay entegrasyonunu teslim etmeden önce gözden geçirmek için kullanılabilir. Her madde, yukarıdaki bölümlerde anlatılan bir riskin karşılığıdır.

• Tetikleyici analitik sahada test edildi; yanlış ve kaçırılan alarm sayıları not edildi.
• Eylemin etkisine göre tek koşul, çift koşul ya da insan onayı seçildi.
• Röle kontak değeri ve yük uyumu üretici belgesinden kontrol edildi, yardımcı röle kullanıldı.
• NO/NC mantığı ve çıkış süresi ayarlandı.
• Bekleme süresi her eylem için ayrı belirlendi.
• Webhook için HTTPS, MQTT için TLS ve ayrı kısıtlı yetkili kullanıcı kullanıldı.
• Varsayılan parolalar değiştirildi; cihazlar ayrı ağda, gereksiz portlar kapalı.
• Kamera, NVR ve POS saatleri aynı NTP kaynağına bağlandı.
• Alıcıda tekrar eden olay ayıklaması ve hata kaydı var.
• Ağ kesilince çalışan yedek yol (röle ya da NVR kaydı) tanımlı.
• Çalışan veya müşteri görüntüsü işleyen akışlarda KVKK aydınlatması yapıldı.
• Test raporu ve ayar dökümü müşteriye teslim edildi.

Bayifi bu konuda nerede devreye girer?

Bu tür entegrasyonlar genellikle kamera, NVR, röle modülü ve ağ ekipmanının birlikte planlanmasını gerektirir. Bayifi'de bölgenizdeki kurulumcuları bayiler sayfasından il il inceleyebilir, projedeki ürünlerin toptancılarda anlık stok durumunu pazar bölümünden görebilirsiniz. Kurulumcu veya toptancıysanız firmanızı /kaydol sayfasından kaydedebilirsiniz.