IoT Sensörleri ve MQTT Uyarılarıyla HVAC İzleme

IoT sensörleriyle HVAC izleme, klima santrallerinin, fan coil'lerin ve çatı tipi ünitelerin yalnızca açık olup olmadığını değil, gerçekte nasıl davrandığını sürekli olarak görmenizi sağlar. Bu kullanım senaryosu, en yaygın arızaları hangi ölçümlerin yakaladığını, bunları MQTT üzerinden nasıl yayınlayacağınızı ve bir bulut broker ile uyarılara ve çalışma süresi raporlarına nasıl dönüştüreceğinizi gösteriyor.

HVAC Ekipmanında Neler Ters Gider

HVAC sorunlarının çoğu kendini bir alarmla belli etmez. Yavaş kaymalar olarak ortaya çıkarlar: bir filtre dolar ve hava debisi düşer, bir vana takılır ve serpantin performansı azalır, kötü bir termostat konumu yüzünden bir kompresör kısa döngü yapar ya da bir zaman programı geçersiz kılınıp hiç sıfırlanmadığı için bir ünite bütün hafta sonu çalışır. Kullanıcılar bunu ancak konfor bozulduğunda fark eder; o zamana kadar da haftalarca enerji boşa harcanmış olur.

Bir bina yönetim sistemi bunların bir kısmını algılayabilir, ancak birçok sahada hiç BMS yoktur ya da yalnızca bir yüklenicinin erişebildiği bir BMS vardır. Birkaç IoT sensörünü sonradan eklemek ve MQTT'ye yayınlamak bu boşluğu hızla doldurur ve ünite ister bir mağazadaki çatı tipi paket ünite ister bir ofis kulesindeki klima santrali olsun, tüm portföyde aynı şekilde çalışır.

Önemli Sinyaller

Ünite başına onlarca noktaya ihtiyacınız yok. Aşağıdaki ölçümler pratik arıza tespitinin büyük kısmını karşılar:

En faydalı türetilmiş değer, dönüş ve besleme havası arasındaki fark olan delta-T'dir. Bir soğutma ünitesi çok küçük bir delta-T ile çalışıyorsa, ya serpantine soğutulmuş su veya soğutucu akışkan gelmiyordur, ya hava debisi çok yüksektir ya da bir sensör yanlış yerdedir. Haftalar içinde istikrarlı biçimde yükselen bir filtre basıncı normaldir; aniden sıfıra doğru düşen bir basınç ise filtrenin çöktüğü veya eksik olduğu anlamına gelir.

Mimari

Bu sinyalleri MQTT'ye taşımanın iki yaygın yolu vardır:

1. Mevcut kontrolörler. Ünitelerde zaten BACnet kontrolörleri varsa, BACnet'ten MQTT'ye eğitimimizde gösterildiği gibi bir gateway noktaları okur ve yayınlar.
2. Sonradan eklenen sensör düğümleri. Ünite başına bir ESP32 veya küçük bir endüstriyel IoT modülü probları doğrudan okur ve Wi-Fi ya da Ethernet üzerinden yayınlar. ESP32 MQTT eğitimi bağlantı temellerini ele alıyor.

Her iki durumda da düğüm bir broker'a giden yönde yayın yapar ve her tüketici abone olur: devreye alma için portaldaki topic gezgini, türetilmiş değerler için bir analitik betiği ve tesis personeli için bir panel. Topic yapısı bina hiyerarşisini izler:

acme/ist01/tower-a/roof/ahu-2/telemetry
acme/ist01/tower-a/roof/ahu-2/derived
acme/ist01/tower-a/roof/ahu-2/status

Her aralıkta tek bir telemetri mesajı trafiği küçük tutar ve zaman hizalamasını kolaylaştırır:

{
  "ts": "2026-10-16T10:30:00Z",
  "supply_c": 13.6,
  "return_c": 23.1,
  "outdoor_c": 27.4,
  "filter_dp_pa": 182,
  "fan_a": 6.8,
  "comp_a": 14.2,
  "mode": "cooling"
}

MQTT'den Delta-T ve Çalışma Süresi Hesaplamak

Türetilmiş değerleri her sensör düğümünde değil, tek bir yerde hesaplamak en iyisidir. Aşağıdaki betik her ünitenin telemetrisine abone olur, delta-T'yi hesaplar, fan ve kompresör çalışma süresini biriktirir, kısa döngüyü tespit etmek için saat başına kompresör kalkışlarını sayar ve sonuçları yeniden MQTT'ye yayınlar. Demo önekiyle ücretsiz herkese açık MQTT broker'ında deneyin, ardından özel kimlik bilgilerine geçin.

import json
import time
import uuid
from collections import defaultdict, deque

import paho.mqtt.client as mqtt

BROKER, PORT = "broker.connectmq.com", 1883
PREFIX = "connectmq/demo/hvac-q81z"
FAN_ON_A = 1.0          # bunun üzerindeki akım fanın çalıştığı anlamına gelir
COMP_ON_A = 3.0         # bunun üzerindeki akım kompresörün çalıştığı anlamına gelir
MAX_STARTS_PER_HOUR = 6

state = defaultdict(lambda: {"last_ts": None, "fan_s": 0.0, "comp_s": 0.0,
                             "comp_on": False, "starts": deque()})


def on_connect(client, userdata, flags, reason_code, properties):
    print("connected:", reason_code)
    client.subscribe(f"{PREFIX}/+/telemetry", qos=0)


def on_message(client, userdata, msg):
    unit = msg.topic.split("/")[-2]
    try:
        t = json.loads(msg.payload)
    except json.JSONDecodeError:
        return
    s = state[unit]
    now = time.time()

    if s["last_ts"] is not None:
        dt = min(now - s["last_ts"], 120)      # kesintiler çalışma süresini şişirmesin diye boşlukları sınırla
        if t.get("fan_a", 0) > FAN_ON_A:
            s["fan_s"] += dt
        if s["comp_on"]:
            s["comp_s"] += dt
    s["last_ts"] = now

    comp_on = t.get("comp_a", 0) > COMP_ON_A
    if comp_on and not s["comp_on"]:
        s["starts"].append(now)
    s["comp_on"] = comp_on
    while s["starts"] and now - s["starts"][0] > 3600:
        s["starts"].popleft()

    delta_t = None
    if "return_c" in t and "supply_c" in t:
        delta_t = round(t["return_c"] - t["supply_c"], 2)

    derived = {
        "ts": t.get("ts"),
        "delta_t_c": delta_t,
        "fan_runtime_h": round(s["fan_s"] / 3600, 2),
        "comp_runtime_h": round(s["comp_s"] / 3600, 2),
        "comp_starts_last_hour": len(s["starts"]),
        "short_cycling": len(s["starts"]) > MAX_STARTS_PER_HOUR,
    }
    client.publish(f"{PREFIX}/{unit}/derived", json.dumps(derived), qos=1, retain=True)


client = mqtt.Client(mqtt.CallbackAPIVersion.VERSION2, client_id=f"hvac-analytics-{uuid.uuid4().hex[:6]}")
client.on_connect = on_connect
client.on_message = on_message
client.connect(BROKER, PORT, keepalive=60)
client.loop_forever()

Çalıştığını görmek için komut satırından bir üniteyi simüle edin:

mosquitto_pub -h broker.connectmq.com -p 1883 -i hvac-sim-q81z \
  -t "connectmq/demo/hvac-q81z/ahu-2/telemetry" \
  -m '{"ts":"2026-10-16T10:30:00Z","supply_c":13.6,"return_c":23.1,"filter_dp_pa":182,"fan_a":6.8,"comp_a":14.2}'

Buradaki çalışma süresi sayaçları bellekte tutulur; bu yüzden betik yeniden başladığında sıfırlanırlar. Faturalandırma düzeyinde çalışma süresi için türetilmiş değerleri aynı aboneden bir zaman serisi veritabanına yazın ya da Telegraf gibi bir aracın topic'lere abone olup bunları saklamasına izin verin.

HVAC Arızaları için Eşik Uyarıları

ConnectMQ, portalda gelen değerler üzerinde eşik uyarı kuralları tanımlamanıza olanak tanır ve tetiklenen her uyarı uyarı günlüğünde tutulur. Soğutma yapan bir klima santrali için pratik başlangıç kuralları:

Eşikleri bir haftalık gözlemden sonra ünite bazında ayarlayın. Ekipman, iklim ve filtre sınıfı evrensel sayılar için fazla değişkendir; doğru filtre basınç sınırlarını üreticinin veri sayfası verir.

Geçmişi Saklamak ve Raporlamak

Canlı değerler arızaları yakalar; geçmiş ise tasarrufu kanıtlar ve bakıma yön verir. Her tüketici yalnızca başka bir MQTT istemcisi olduğu için depolama eklemek sensör düğümlerine dokunmayı gerektirmez. Yaygın seçenekler; MQTT consumer girdisiyle InfluxDB'ye yazan bir Telegraf örneği, PostgreSQL'e kayıt ekleyen bir Node-RED akışı veya kurumunuzun zaten kullandığı veritabanına yazan küçük bir Python abonesidir. Ham telemetriyi doğal aralığında birkaç ay saklayın, saatlik toplamları ise yıllarca tutun.

Tesis ekipleri için faydalı aylık raporlar arasında ünite başına çalışma saatlerinin programlanmış saatlerle karşılaştırması, her ünitenin düşük delta-T ile geçirdiği saat sayısı, her filtrenin değişim basıncını aştığı tarih ve kompresör kalkışlarına göre sıralanmış üniteler bulunur. Bu sayılar "üçüncü kat hep sıcak" gibi belirsiz şikâyetleri somut iş emirlerine dönüştürür.

Devreye Alma Kontrol Listesi

1. Tüm portföyü değil, üç ila beş temsili ünite seçin.
2. Besleme problarını karışık hava için serpantinin yeterince aşağısına, dönüş problarını ise karışım kutusundan önceye monte edin.
3. Akım trafolarını kablonun tamamına değil, tek bir iletkene takın.
4. Ünite döngü yaparken topic gezgininde canlı değerleri izleyerek her sensörü devreye alın.
5. Analitik abonesini çalıştırın ve uyarıları etkinleştirmeden önce bir hafta gözlemleyin.
6. Teknisyenlerin neyi kontrol edeceğini bilmesi için her uyarı için kısa bir çalışma talimatı yazın.
7. Yanlış alarmlar kontrol altına alındığında ünitelerin geri kalanına genişletin.

Ölçeklemek

Ünite başına tek bir sonradan eklenen düğüm ve bir analitik servisi, bir pilot için ücretsiz Serverless plana kolayca sığar. Bina ekledikçe bağlantı sayısı ünitelerle doğrusal olarak artar; ücretli Serverless katmanı paylaşımlı aboneliklerle 1.000 bağlantıya kadar destekler, böylece yükü bölen birkaç analitik işçisi çalıştırabilirsiniz. Broker bir bulut MQTT broker olduğu için her binaya sensör düğümleri dışında hiçbir şey kurmazsınız.

Hava kalitesi ve doluluk, HVAC verisine değerli bir bağlam katar: iç ortam hava kalitesi izleme ve ofis doluluk sensörleri yazılarına bakın. Daha geniş resim bina otomasyon sistemi MQTT yazısında ve IoT otomasyon rehberinde ele alınıyor.

HVAC'nizi ConnectMQ ile İzlemeye Başlayın

app.connectmq.com adresinde kredi kartı gerekmeden ücretsiz bir Serverless broker oluşturun. Bir sensör düğümü bağlayın, değerleri canlı topic gezgininde izleyin, ardından delta-T ve filtre basıncı için eşik uyarı kuralları ekleyin. ConnectMQ broker'ı çalıştırır; böylece ekibiniz ekipmana odaklanabilir.

Sık Sorulan Sorular

En faydalı tek HVAC ölçümü hangisidir?

Besleme ve dönüş havası sıcaklığı birlikte; çünkü delta-T ünitenin gerçekten ısı transfer edip etmediğini gösterir. Ardından filtre fark basıncını ekleyin.

IoT sensörleriyle HVAC izleme için bir BMS'e ihtiyacım var mı?

Hayır. Sonradan eklenen sensör düğümleri doğrudan MQTT'ye yayın yapabilir. Bir BMS varsa, bir gateway yeni sensörler kurmak yerine onun noktalarını yeniden kullanabilir.

HVAC telemetrisi ne sıklıkla gönderilmeli?

Sıcaklıklar ve basınçlar için 30 ila 60 saniyede bir yeterlidir. Çalışma süresi ve kısa döngü için akım ölçümleri 10 ila 15 saniyelik aralıklardan fayda görür.

Uyarılar broker'ın kendisinden gönderilebilir mi?

ConnectMQ eşik uyarı kurallarını değerlendirir ve bunları uyarı günlüğüne kaydeder. SMS, e-posta veya kayıt açma için ilgili topic'lere tepki veren Node-RED gibi bir abone çalıştırın.