IoT Sayaç Verisi ve MQTT ile Enerji Yük Tahmini

Enerji yük tahmini, bir binanın, tesisin veya sahanın önümüzdeki saatlerde ya da günlerde ne kadar elektrik çekeceğini öngörür. Okumalarını MQTT üzerinden aktaran IoT sayaçlarıyla, aylık faturalara güvenmek yerine kendi verinizden bir tahmin oluşturabilirsiniz. Bu kullanım senaryosu; sayaçtan modele uzanan veri yolunu, talep için önemli olan özellikleri, çalışan bir gün öncesi tahmin betiğini ve sonucun pik tıraşlama ile planlama kararlarını yönlendirebilmesi için nasıl yayınlanacağını adım adım ele alıyor.

Enerji Yükü Neden Tahmin Edilmeli

Bir yük tahmini, tesis ve üretim yöneticilerinin her gün karşılaştığı pratik sorulara yanıt verir:

• Pik talep yönetimi. Pek çok tarife, ayın en yüksek ölçüm aralığına dayanan talep (güç) bedelleri içerir. Yarın öğleden sonra sınıra yaklaşılacağını önceden bilmek, esnek yükleri kaydırmanıza olanak tanır.
• Esnek yüklerin planlanması. Kesikli (batch) prosesler, elektrikli araç şarjı, ön soğutma ve su ısıtma, talebin ya da fiyatların daha düşük olduğu saatlere taşınabilir.
• Enerji alımı ve öz tüketim. Güneş enerjisi, batarya veya zaman dilimli tarife sözleşmesi olan sahaların ne zaman şarj edeceğine, deşarj edeceğine ya da alım yapacağına karar vermek için talep tahminine ihtiyacı vardır.
• Anormallik tespiti. Tahmin ile gerçekleşen yük arasında büyük ve kalıcı bir fark, çoğu zaman açık unutulmuş bir ekipmana, arızalanmakta olan bir kompresöre veya bir ölçüm hatasına işaret eder.

Tahmin ufku karara bağlıdır: gün içi tahminler (önümüzdeki birkaç saat) gerçek zamanlı kontrolü, gün öncesi tahminler planlama ve satın almayı, daha uzun ufuklar ise bütçelemeyi destekler.

Veri Yolu: Sayaçtan Modele

Tipik bir kurulumda elektrik sayaçları veya alt sayaçlar, onları Modbus, M-Bus ya da üretici API'si üzerinden okuyan bir gateway'e bağlıdır ve bu gateway okumaları bir MQTT broker'a yayınlar. Hava durumu verileri ile üretim ya da doluluk takvimleri de bunların yanında yayınlanır veya saklanır.

Meters (Modbus RTU/TCP) -> gateway -> MQTT broker -> historian subscriber -> forecasting service
                                           ^                                         |
                       weather / schedule publisher                 forecast topic <-+

Net bir topic düzeni, modeli sayaç üreticilerinden bağımsız tutar:

connectmq/site1/main/meter1/energy       {"ts":..., "kwh_total": 183422.6}
connectmq/site1/main/meter1/power        {"ts":..., "kw": 142.8}
connectmq/site1/weather/outdoor          {"ts":..., "temp_c": 27.4}
connectmq/site1/main/meter1/forecast     {"generated":..., "points":[...]}

Mümkün olduğunda enerjiyi aralık başına değerler yerine kümülatif bir sayaç olarak yayınlayın. Bir mesaj kaybolsa bile bir sonraki sayaç değeri tüketimi içerir ve aralık talebi fark alınarak birebir yeniden oluşturulabilir. Anlık güç canlı dashboard'lar için faydalıdır ancak tahmin için gürültülüdür. Sayaçlarınız Modbus cihazlarıysa, gateway tarafını Modbus TCP'den MQTT'ye rehberi gösteriyor.

Enerji Yük Tahminini Belirleyen Özellikler

Gün öncesi tahminlerde her özelliğin tahmin yapılmadan önce mevcut olması gerekir. Bu, gelecek saatler için ölçülen sıcaklığı değil hava durumu tahminini kullanmak ve en az 24 saatlik gecikmeler kullanmak anlamına gelir. Eğitimde ölçülen ve tahmin edilen hava durumunu karıştırmak, testte mükemmel görünüp operasyonda hayal kırıklığı yaratan modellerin yaygın bir nedenidir.

Python ile Gün Öncesi Tahmin

Aşağıdaki betik, ticari bir binanın sayaç değerini ve dış ortam sıcaklığını dört hafta boyunca simüle eder, bunları ücretsiz genel MQTT broker'a yayınlar, geri toplar, sayacı 15 dakikalık talebe dönüştürür, bir gradient boosting modeli eğitir ve 24 saatlik bir tahmin yayınlar. Gerçek bir kurulumda toplama adımı simülatör yerine historian'ınızdan okuma yapar.

import json
import math
import random
import time
import uuid

import numpy as np
import pandas as pd
import paho.mqtt.client as mqtt
from sklearn.ensemble import HistGradientBoostingRegressor

BROKER = "broker.connectmq.com"
BASE = f"connectmq/demo/{uuid.uuid4().hex[:8]}/site1"
START = 1767225600  # 2026-01-01 00:00 UTC
STEPS = 28 * 96     # 15 dakikalık aralıklarla 4 hafta
rows = []


def on_message(client, userdata, msg):
    p = json.loads(msg.payload)
    p["kind"] = msg.topic.rsplit("/", 1)[1]
    rows.append(p)


client = mqtt.Client(mqtt.CallbackAPIVersion.VERSION2, client_id="elf-" + uuid.uuid4().hex[:8])
client.on_message = on_message
client.connect(BROKER, 1883, keepalive=60)
client.subscribe([(f"{BASE}/meter1/energy", 1), (f"{BASE}/weather/temp", 1)])
client.loop_start()
time.sleep(1)

counter = 100000.0
for i in range(STEPS):
    t = START + i * 900
    hour = (t % 86400) / 3600
    workday = time.gmtime(t).tm_wday < 5
    temp = 24 + 7 * math.sin((hour - 9) / 24 * 2 * math.pi) + random.gauss(0, 1)
    occupied = workday and 7 <= hour < 19
    kw = 40 + (90 if occupied else 0) + 6 * max(temp - 22, 0) + random.gauss(0, 5)
    counter += kw * 0.25
    client.publish(f"{BASE}/meter1/energy", json.dumps({"ts": t * 1000, "kwh_total": round(counter, 2)}))
    client.publish(f"{BASE}/weather/temp", json.dumps({"ts": t * 1000, "temp_c": round(temp, 2)}))
    time.sleep(0.21)  # adım başına iki mesaj, saniyede 10 mesajın altında kal

time.sleep(3)

df = pd.DataFrame(rows)
df["ts"] = pd.to_datetime(df["ts"], unit="ms", utc=True)
energy = df[df.kind == "energy"].set_index("ts")["kwh_total"].sort_index().resample("15min").last()
temp = df[df.kind == "temp"].set_index("ts")["temp_c"].sort_index().resample("15min").mean()

data = pd.DataFrame({"kw": energy.interpolate().diff() * 4, "temp": temp.interpolate()})
data["hour"] = data.index.hour + data.index.minute / 60
data["dow"] = data.index.dayofweek
data["lag_1d"] = data["kw"].shift(96)
data["lag_7d"] = data["kw"].shift(7 * 96)
data["cdh"] = (data["temp"] - 22).clip(lower=0)
FEATS = ["hour", "dow", "lag_1d", "lag_7d", "temp", "cdh"]
data = data.dropna()

train, test = data.iloc[:-96], data.iloc[-96:]
model = HistGradientBoostingRegressor(max_iter=300, learning_rate=0.05).fit(train[FEATS], train["kw"])
pred = model.predict(test[FEATS])
mae = np.mean(np.abs(pred - test["kw"]))
print(f"Day-ahead MAE: {mae:.1f} kW, peak forecast {pred.max():.0f} kW, actual peak {test['kw'].max():.0f} kW")

forecast = {
    "generated": int(time.time() * 1000),
    "model": "gbr-load-v1",
    "unit": "kW",
    "points": [{"ts": int(ts.timestamp() * 1000), "kw": round(float(v), 1)} for ts, v in zip(test.index, pred)],
}
client.publish(f"{BASE}/meter1/forecast", json.dumps(forecast), qos=1, retain=True).wait_for_publish()
client.loop_stop()
client.disconnect()

Kurulum için pip install paho-mqtt pandas numpy scikit-learn komutunu çalıştırın. Simülatör genel broker'ın hız sınırına uyduğu için çalıştırma yaklaşık on dakika sürer. Buradaki test gününde, hava durumu tahmininin yerine simüle edilmiş ölçülen sıcaklık kullanılıyor; üretimde modele gelecek saatler için tahmini sıcaklığı verin. Birden fazla tahmin başlangıç noktasıyla geriye dönük test (backtesting) ve basit (naive) bir referans modelle karşılaştırma hakkında arka plan bilgisi için IoT zaman serisi tahmini yazısına bakın.

Tahmini Aksiyona Dönüştürmek

Bir tahmin ancak kararları değiştirdiğinde karşılığını verir. Yaygın kalıplar:

1. Pik uyarıları. Tahmin edilen piki talep sınırınızla karşılaştırın ve tesis ekibini bir önceki akşamdan bilgilendirin.
2. Yük kaydırma. Bir planlama betiği tahmin topic'ine abone olur ve elektrikli araç şarjı veya kesikli ısıtma gibi esnek yükleri düşük talepli aralıklara taşır.
3. Ön soğutma ve ön ısıtma. HVAC, ucuz veya düşük talepli saatleri kullanarak bina kütlesinde ısıl enerji depolayabilir; bu kalıp yapay zeka ile HVAC optimizasyonu yazısında ele alınıyor.
4. Tahmin ile gerçekleşen değerin izlenmesi. Canlı sapmayı ayrı bir topic olarak yayınlayın ve kalıcı farklarda uyarı verin.

ConnectMQ ile tahmin ve ölçülen güç topic'lerini canlı topic gezgininde izleyebilir ve ölçülen talep için eşik tabanlı uyarı kuralları tanımlayabilirsiniz; böylece uyarı günlüğü sınırınızı aşan her aralığı kaydeder. Daha gelişmiş aksiyonlar, aynı broker'a abone olan Node-RED akışları veya Python servisleri gibi kendi client'larınızda çalışır.

Tahminleri Gün İçinde Güncellemek

Gün öncesi tahmin bir kez yapılır, ancak gün nadiren tam planlandığı gibi geçer. Plansız bir fazla mesai vardiyası veya öngörülenden daha sıcak bir öğleden sonra yükü kaydırır. Basit bir iyileştirme, tahmini en son ölçülen talebi ek girdi olarak kullanarak her saat yeniden çalıştırmak ve her yeni sürümü bir üretim zaman damgasıyla aynı retained topic'e yayınlamaktır. Tüketiciler her zaman en güncel görünümü görür; siz de her sürümü saklayarak gün içi güncellemelerin doğruluğu orijinal gün öncesi çalıştırmaya kıyasla ne kadar artırdığını ölçebilirsiniz.

Pratikte Karşılaşılan Tuzaklar

• Sayaç sıfırlanmaları ve taşmaları. Sayaçlar başa döner veya değiştirildikten sonra sıfırlanır; negatif farkları negatif talep olarak değil, sıfırlanma olarak ele alın.
• Saat dilimleri ve yaz saati uygulaması. Veriyi UTC olarak saklayın, takvim özelliklerini yerel saatte hesaplayın; aksi hâlde sabah 08:00'deki devreye alma yılda iki kez bir saat kayar.
• Tatiller ve duruşlar. Tatil işareti olmadan model, resmî tatilde normal bir hafta içi yükü tahmin eder.
• Değişen referans düzeyleri. Yeni ekipmanlar, iyileştirmeler veya değişen çalışma saatleri eski geçmişi yanıltıcı hâle getirir; güncel veriye daha fazla ağırlık verin ya da kayan bir pencere üzerinde yeniden eğitin.
• Ana sayaçla tutmayan alt sayaç toplamları. Ölçülmeyen yükler ve kayıplar vardır; alt sayaç tahminlerini toplamak yerine doğrudan ana sayacı tahmin edin ve alt sayaçları teşhis için kullanın.

Birden Fazla Sahaya Ölçeklemek

Tek bir bina bir betiktir; elli saha ise bir platformdur. Topic düzenini her sahada aynı tutun, wildcard'larla abone olan tek bir tahmin servisi çalıştırın ve sonuçları saha bazında saklayın. Yönetilen bir MQTT broker, mesajlaşma katmanını işletmenin operasyonel yükünü ortadan kaldırır; ConnectMQ ise sahaların izolasyon gerektirdiği durumlar için Dedicated kümeler ve BYOC kurulumları sunar. Modelleri bağlantılı cihazlarla birleştirme hakkında daha fazlası için yapay zeka ve IoT rehberine, enerji sistemlerine model tabanlı bir bakış için ise enerji için dijital ikizler yazısına göz atın.

ConnectMQ ile Başlayın

app.connectmq.com adresinde kredi kartı gerektirmeden ücretsiz bir Serverless broker oluşturun. Sayaç gateway'inizi ve tahmin servisinizi oluşturulan YOUR_USERNAME, YOUR_PASSWORD ve YOUR_CLIENT_ID bilgileriyle bağlayın ve enerji yük tahmini modelinizin ihtiyaç duyduğu geçmiş veriyi biriktirmeye başlayın. Saha ekledikçe topic'lerinizi değiştirmeden daha büyük bir bulut MQTT broker planına geçin.

Sık Sorulan Sorular

Enerji yük tahmini nedir?

Enerji yük tahmini, bir binanın, tesisin veya şebeke bölgesinin gelecekteki zaman aralıklarındaki elektrik talebini, genellikle geçmiş sayaç verileri, hava durumu ve takvim bilgilerinden yola çıkarak öngörür.

Enerji yükünü tahmin etmek için ne kadar veriye ihtiyacım var?

Düzenli bir çalışma takvimine sahip bir bina için birkaç haftalık 15 dakikalık veri, kullanılabilir bir gün öncesi tahmin üretebilir. Mevsimsel ısıtma ve soğutma kalıplarını ve tatilleri yakalamak için ise bir yıl veya daha fazla veri gerekir.

Sayaçlarımdan enerji mi yoksa güç mü yayınlamalıyım?

Tahmin ve faturalama doğruluğu için kümülatif enerji sayacını yayınlayın, çünkü kaybolan mesajlar tüketimin kaybolmasına yol açmaz. Canlı dashboard'lara ihtiyacınız varsa ek olarak anlık gücü de yayınlayın.

Yük tahmini için en iyi hangi model çalışır?

Takvim, gecikme ve hava durumu özellikleri üzerinde gradient boosting güçlü ve açıklanabilir bir varsayılan seçimdir. Bunu geçen haftanın aynı günü referans modeliyle karşılaştırın ve yalnızca başka bir model kayan bir geriye dönük testte daha iyi sonuç verirse geçiş yapın.