Files
ems/docs/04-modules/consumption.md
Dusan Vojacek 343f2f9847
Some checks failed
CI and deploy / migration-check (push) Failing after 10s
CI and deploy / deploy (push) Has been skipped
rebuild consumpton baselaline
2026-05-02 13:56:35 +02:00

8.1 KiB
Raw Blame History

Modul: Consumption (Spotřeba)

Členění spotřeby

Systém rozlišuje dva typy spotřeby:

1. Bazální (neflexibilní) spotřeba

  • Spotřeba kterou nelze odložit ani řídit
  • Příklady: osvětlení, elektronika, vaření, cirkulační čerpadla
  • Zdroj: měřená telemetrie ze střídače (load_power_w - suma flexibilní spotřeby)
  • Použití v plánování: jako pevný vstup (musí být pokryta)

2. Flexibilní spotřeba

  • Spotřeba kterou lze časově přesunout nebo regulovat
  • Příklady: nabíjení EV, ohřev TUV, tepelné čerpadlo (při přetopení zásobníku)
  • Zdroj: telemetrie z konkrétních zařízení (EV nabíječky, stavové vstupy Loxone)
  • Použití v plánování: jako optimalizovatelná proměnná

Jak se měří celková spotřeba

Střídač Deye poskytuje přes Modbus registr load_power_w = celková okamžitá spotřeba objektu (vše za hlavním jističem na AC straně střídače).

load_power_w (Deye) = bazální_spotřeba + EV_nabíjení + TUV + ostatní flexibilní

Výpočet bazální spotřeby

Bazální výkon je to, co zůstane po odečtení řízených zátěží od celkové spotřeby ze střídače:

bazální_w = load_power_w - ev_power_w - heat_pump_power_w
  • load_power_w telemetrie střídače (telemetry_inverter), 1min.
  • ev_power_w v agregaci statistik se bere průměr výkonu ze všech nabíječek site v časovém okně ±30 s kolem měření střídače (telemetry_ev_charger).
  • heat_pump_power_w stejně z telemetry_heat_pump (TČ včetně kompresoru; slouží jako proxy za měřitelný příkon TČ).

Ukládání profilu: tabulka consumption_baseline_stats (unikátní (site_id, day_of_week, hour_of_day)). Plní ji ems.fn_update_baseline_stats(site_id, lookback_days) z minutové telemetrie za posledních N dní; agregace po DOW a hodině (Europe/Prague). Do řádku se zapisuje jen bucket s alespoň 4 vzorky (minuty). EMA 70/30 při ON CONFLICT: nový batch má váhu 30 %, existující průměr 70 % (postupné zpřesňování). Denní job v backendu: 00:30 (fn_update_baseline_stats(..., 30)).

Predikce do horizontu: ems.fn_get_baseline_forecast(site_id, from, to) generuje 15min sloty (generate_series), pro každý slot najde řádek podle DOW+hodiny v Praze. forecast_w = uložený průměr; confidence_w = konzervativní odhad avg + 0.5 * COALESCE(stddev, 100). Pokud pro slot neexistuje statistika, fallback forecast_w = 500 W (málo nebo žádná historie; prakticky odpovídá situaci před ~4 týdny kvalitních dat v jednotlivých hodinách). Směrodatná odchylka je v DB k dispozici pro budoucí použití v solveru (fáze 2).

Solver (planning_engine._load_slots): pro každý 15min interval efektivní ceny bere avg_power_w z consumption_baseline_stats podle DOW+hodiny slotu, jinak 500 W nečte consumption_baseline_interval. Stejná hodnota se ukládá do planning_interval.load_baseline_w při každém běhu plánovače (přehled v UI / PostgREST). Odchylka vs. skutečnost: tabulka baseline_load_forecast_accuracy, plněno po auditu.

Operace: přepočet bez EMA „ocasu“: denní job volá fn_update_baseline_stats, které při updatu bucketu míchá 70 % starý + 30 % nový průměr. Je-li profil zaseklý, smaž statistiky a znovu načti z telemetrie — kanonické API je ems.fn_rebuild_consumption_baseline_stats(p_site_id, p_lookback_days) v db/routines/R__085_fn_rebuild_consumption_baseline_stats.sql: při p_site_id IS NULL maže celou consumption_baseline_stats a přepíná všechny řádky z ems.site; při konkrétním site_id jen řádky dané lokality. Příklad (psql / MCP): select * from ems.fn_rebuild_consumption_baseline_stats(2, 30); jedna lokality; select * from ems.fn_rebuild_consumption_baseline_stats(null::int, 30); všechny lokality (první argument je site_id — ne zaměnit s počtem dnů). Tenký wrapper: scripts/rebuild_consumption_baseline_stats.sh. Špatná měření (EV/TČ) funkce sama neopraví.

Poznámka: TUV jako samostatný odečet zůstává otevřený bod, pokud není měřen zvlášť; aktuálně je TČ zahrnut v heat_pump_power_w.


Ukládání spotřeby

Real-time telemetrie

Celková spotřeba je součástí telemetry_inverter.load_power_w (1min záznamy).

EV nabíječky mají vlastní tabulku telemetry_ev_charger s přesným výkonem.

Agregovaná spotřeba pro plánování

  • consumption_baseline_stats primární vstup solveru: hodinový profil (DOW + hodina) z telemetrie, EMA, viz výše.
  • consumption_baseline_interval volitelné 15min řady (actual / forecast) pro jiné účely; solver z ní bazál nečte.

Predikce bazální spotřeby

Metoda: DOW + hodina + EMA

Operativní predikce je v fn_get_baseline_forecast a v přímém dotazu v _load_slots na consumption_baseline_stats. Doplňkově lze z historie stavět 15min profily v consumption_baseline_interval, pokud je k tomu samostatný job není nutné pro běh LP.


Flexibilní zařízení detailní popis

EV nabíječky (Teltonika TeltoCharge 22kW)

Komunikace: Teltonika poskytuje REST API a/nebo OCPP protokol.

Parametr Hodnota
Max výkon 22 000 W (třífázové)
Min výkon (1 fáze) 1 380 W
Počet na home-01 2
Protokol OCPP 1.6 nebo Teltonika REST API

Co systém řídí:

  • Povolení/zakázání nabíjení (smart charging on/off)
  • Omezení výkonu (charge current limit v Amperech)
  • Časový plán nabíjení (nastavit okno kdy smí nabíjet)

Telemetrie (stahuje se každou minutu):

  • stav konektoru (available / charging / faulted)
  • aktuální výkon [W]
  • kumulativní energie [kWh]
  • proud [A], napětí [V]
  • session ID

Plánování:

  • EV se nabíjí v době levné energie nebo přebytku FVE
  • Respektuje požadavek uživatele: "nabitý na X % do Y hodin"
  • Pokud není požadavek nastaven → nabíjí při přebytku nebo nejlevnějším spotu

Otevřený bod: Teltonika API vs OCPP rozhodnout při první integraci. Doporučujeme OCPP pro standardizaci.


TUV / Tepelné čerpadlo

Komunikace: přes Loxone (HTTP Virtual Input zapnout/vypnout)

Co systém řídí:

  • Povolení ohřevu (Loxone přepne výstupní relé)
  • Systém pošle setpoint do Loxone, Loxone provede

Telemetrie:

  • Stav ON/OFF (čteme z Loxone HTTP výstupu nebo Virtual Output stavu)
  • Teplota zásobníku (pokud je čidlo v Loxone doporučeno)
  • Aktuální výkon: není přímo měřen, používáme max_power_w z asset_flexible_device

Plánování:

  • TUV se ohřívá v době přebytku FVE nebo levného spotu
  • Minimální a maximální teplota zásobníku je respektována (pokud máme čidlo)
  • Nouzová priorita: pokud teplota pod minimum → ohřát bez ohledu na cenu

Výpočet bazální spotřeby v auditu

-- Agregovaná skutečná bazální spotřeba za 15min interval
CREATE VIEW consumption_vw_actual_baseline AS
SELECT
    t.site_id,
    time_bucket('15 minutes', t.measured_at) AS interval_start,
    AVG(
        t.load_power_w
        - COALESCE(ev1.power_w, 0)
        - COALESCE(ev2.power_w, 0)
        -- TUV: odečíst max_power pokud byl v daném intervalu aktivní
    ) AS baseline_power_w
FROM telemetry_inverter t
-- JOIN na EV telemetrii
GROUP BY t.site_id, time_bucket('15 minutes', t.measured_at);

Konfigurace (env proměnné)

CONSUMPTION_FORECAST_LOOKBACK_WEEKS=4
TELTONIKA_API_URL_1=http://192.168.x.x/api    # charger 1
TELTONIKA_API_URL_2=http://192.168.x.x/api    # charger 2
TELTONIKA_POLL_INTERVAL_SEC=60
TUV_DEFAULT_POWER_W=2000                       # fallback pokud není měřeno

Otevřené body

  • Teltonika: OCPP vs REST API rozhodnout před implementací
  • TUV teplota zásobníku: přidat čidlo do Loxone pro přesnější řízení
  • Bazální spotřeba: zpřesnit odečítání TUV výkonu (ON/OFF × čas vs pevný výkon)
  • Sezónní korekce predikce spotřeby (léto vs zima) fáze 2