🏠 Prožívání · Energie a spotřeba

Energie kterou vidíš, ne hádáš

Runtime-based kWh estimate kotle, plug devices s power metering, rolling daily a yearly tracking. Žádný hi-end energy meter zatím, ale 95 % přesnost ze čtení stavu zařízení a počítání času. Plánovaný Shelly 3EM doplní finální 5 % až bude rozpočet a čas.

9 kWPříkon kotle
11Plug devices
~95 %Přesnost odhadu
2 minSample interval

Co to dělá

Měření tam, kde to jde, odhad kde to nejde

Hlavní spotřebič je elektrický kotel 9 kW Protherm RAY. Reálný měřák zatím není — místo toho se počítá runtime: každé 2 minuty demand cron inkrementuje counter, když je kotel zapnutý. Na konci dne se spočítá kwh = (runtime_today_s / 3600) × kotel_kw. Přesnost asi 95 %, protože kotel interně moduluje 3 / 6 / 9 kW podle teploty vody.

Plug devices (zásuvky se Z-wave power metering) měří přímo — kromě on/off mají capability measure_power v wattech. Aktuální spotřeba se vzorkuje do EventLog a denní integrace dá kWh. Některé zásuvky mají i meter_power (kumulativní counter, zpřesňuje měření přes restarty).

Cíl není absolutní přesnost faktura-grade — cíl je vědět, který spotřebič žere kolik a kdy. Z toho jde odvodit, že kotel ročně sebere ~3 500 kWh, ledničce stačí ~250, počítač v idle ~80, ostatní zanedbatelně. Pro reálné fakturační měření je v plánu Shelly 3EM (CT clamp na 3 fáze v rozvaděči).

Denní provoz

Jak se měří přes den

Kontinuální vzorkování, denní agregace, rolling history.

  1. Continuous

    Sample every 2 min

    sh_heating_demand_v1 cron: pokud boiler_state='on', runtime_today_s += 120. Plug devices měří capability measure_power v real-time, vzorkují se passively.

  2. 00:00

    Daily reset

    Půlnoc → runtime_yesterday_s = runtime_today_s a runtime_today_s = 0. Yesterday hodnota slouží pro briefing („Včera kotel X min, asi Y kWh"). Reset_date track se zapisuje pro audit trail.

  3. Weekly

    Trend aggregation

    Týdenní průměr se počítá z 7 yesterday hodnot. Slouží pro detekci anomálií (kotel běžel 50 % déle než průměr → něco je špatně se zateplením? otevřená okna? bug v scheduler?).

  4. Yearly

    Cumulative total

    runtime_total_s nikdy se nereetuje — kumulativní counter pro celý život skriptu. Z toho lze odvodit life-cycle spotřebu kotle, predict kdy bude vyžadovat servis, atd.

Scény

Pět situací kde se měření hodí

Některé jsou dashboard-driven, jiné automatické alerty.

Dashboard tile

Heating page má kWh today + runtime today. Realtime hodnota čtená přímo z proměnných. Yesterday hodnota pro porovnání. Týdenní průměr jako sparkline.

Briefing zmínka

Když yesterday ≥ 0,5 kWh, briefing fáze 2 zmíní: „Včera kotel X min, asi Y kWh". Konkrétní data v ranní řeči, žádné odhady „možná hodně".

Anomaly alert

Brain Guardian: pokud runtime jednoho dne > 200 % týdenního průměru, alert do EventLog. Suggested checks: otevřená okna, scheduler bug, anti-cycling guard issue.

Plug power log

Každé 5 min se vzorkuje measure_power všech plug devices do EventLog. Z toho se konstruuje denní křivka — kdy se PC zapnul / vypnul, kdy se vařilo, kdy běžela pračka.

Yearly review

Cumulative total per device → roční přehled. Plán: GitHub Actions cron 1.1. vygeneruje yearly report .md do repa, automaticky pushne. Manuál pak ze srovnání s předchozími lety.

Hardware

Co reálně měří

Plug-level metering tam kde má smysl, runtime estimate kde není volba.

11× Plug devices

Z-wave / Wi-Fi · power + meter

Zásuvky s capability measure_power (real-time W) a meter_power (kumulativní kWh). Nasazené na: PC, lednička, monitor, audio system, charger, atd. Levný způsob jak měřit jeden spotřebič.

Fibaro FGS-214 (kotel)

Z-wave switch · runtime tracking

Hlavní switch pro kotel. Sám nemá power metering (jen on/off + status), proto runtime-based estimate. Při budoucím Shelly 3EM se runtime estimate kombinuje s real measurement pro cross-check.

4× Fibaro FGT-001 (TRV)

Termo hlavice · battery powered

Nemá power metering pro topný okruh — měří jen sebe (battery level). Užitečné jako sekundární data — když TRV ventil zavřený, ale kotel běží, něco je nezpojené. Tracking přes runtime + comparison.

FGS-223 (rezerva)

Double Switch 2 · power metering · unmapped

Z-wave switch s native power metering capability. Aktuálně nezapojený — kandidát pro oběhové čerpadlo topení (heating Fáze C+) nebo bojler. Až fyzická instalace, nový metric stream do energy tracking.

Shelly 3EM Plánováno

CT clamp · 3-phase · Wi-Fi · MQTT

Zlatý standard. Tři proudové cívky se navinou na 3 fáze v rozvaděči, měří real-time + kumulativní kWh per fáze. Doplní runtime estimate přesným měřením, plus dá granularitu „kuchyňská linka vs. lednička vs. PC pokoj".

Pro tech-savvy

Co se děje pod kapotou

Runtime tracking, plug sampling, HA Energy Dashboard plánovaný.

Runtime → kWh formula 
// In sh_heating_demand_v1 (cron 2 min)
if (boiler_state === 'on') {
  runtime_today_s += 120;  // = sample interval
}

// kWh estimate
kwh_today = (runtime_today_s / 3600) * kotel_kw;
// kotel_kw = 9 (configured per device)

Zdroj nepřesnosti:

  • Kotel moduluje 3 / 6 / 9 kW podle teploty vody — odhad používá max 9 kW
  • Sample interval 2 min — chyba ±60 s na on/off transition
  • Boiler_state zaznamenán až 1–2 s po fyzickém přechodu (Z-wave latence)

Net effect: estimate slightly nadhodnocuje (~95 %). Pro fakturaci málo, pro trend analýzu dost.

Plug power sampling

sh_plug_sampler_v1 cron 5 min iteruje 11 plug devices, čte measure_power capability a zapisuje do EventLog s timestamp. Z toho se konstruuje historie:

  • Real-time: aktuální W per plug
  • Daily integral: ∫(W) dt = denní kWh
  • Capability meter_power: kumulativní counter, zpřesňuje přes restarty

Devices které nemají measure_power (jen on/off) se ignorují — runtime tracking pro ně ne stojí za to.

HA Energy Dashboard (plánováno)

todo_homeassistant_rpi_integration.md — fáze 5 plánu. Home Assistant na RPi4 jako read-only observer pro 11 plug devices. Energy Dashboard dá per-device + total view.

Pipeline: Homey → MQTT → HA → Energy Dashboard. Integration přes HACS Homey add-on (pokud existuje), jinak custom MQTT bridge. User pending: Long-Lived Token + Terminal & SSH add-on.

Yearly aggregation (GitHub Actions cron)

Plán pro 1.1.: GitHub Actions cron stáhne EventLog yearly export, vypočte per-device kWh totals, vygeneruje reports/yearly_<rok>.md a auto-pushne do smart-home-website repa. Read-only output pro web (Phase D — case studies like „Year of heating").

Implementace nezávisí na Homey — GitHub Action stáhne EventLog z Google Sheets přes Apps Script API + zpracuje openpyxl / pandas + commit.

Anomaly detection (runtime > 200 % avg)

Brain Guardian invariant: pokud denní runtime > 200 % rolling 7-day average, alert. Možné příčiny:

  • Otevřené okno (heating ztráta) — door/window sensor by měl detekovat
  • Scheduler bug (target_temp zaseknutý nahoře)
  • Anti-cycling guard nefunguje (cooldown bug 25.4. resolved)
  • TRV ventil mechanicky zaseknutý (battery battery? nejde zavřít?)
  • Sezónní změna (extra studené týdny) — false positive

Alert je read-only flag, žádné auto-akce. User si musí ověřit a rozhodnout.

Související

Souvislosti v kontextu webu

Topení a klima

Hlavní spotřebič co měříme — runtime tracking, anti-cycling, schedule.

Infrastruktura

HA RPi4, GitHub Actions, MQTT bridge plánovaný pro Energy Dashboard.

AI Brain

Brain Guardian anomaly detection — runtime > 200 % avg invariant.

Hardware

FGS-223 rezerva, Shelly 3EM specs, plug devices detail.