Výchozí stav domu, dat a klimatických automatizací

Co bylo předmětem analýzy

V domě už existovaly dvě funkční, ale z velké části oddělené soustavy. Home Assistant řešil letní ochranu proti přehřívání, rolety, přirozené větrání a vazbu na klimatizaci. Vytápění řídily samostatné časové plány v aplikaci Tado. Oba systémy pracovaly se stejnými místnostmi a teplotami, neměly však společnou autoritu, která by rozhodovala o sezóně, požadovaném komfortu a vhodném zdroji.

Analýza proto nezačala návrhem nových automatizací. Nejprve jsme zjišťovali, která teplota je v každé zóně skutečně směrodatná, které zařízení umí vyžádat plynový kotel, které entity pouze měří, jaké bezpečnostní vazby už existují a kde by se dva nezávislé plánovače mohly začít přetahovat.

Fyzické rozdělení domu

Ground Floor: jedna topná zóna přes několik místností

Kuchyně, obývací pokoj, ložnice a koupelna jsou tepelně propojené a v Tado tvoří jednu fyzickou zónu. Kotel řídí nástěnný termostat climate.tado_thermostat_main_living; radiátorové hlavice v ložnici, obýváku, kuchyni a koupelně pracují jako součást stejného celku. Pro rozhodování o topení proto není správné jednoduše průměrovat teploty u všech radiátorů. Autoritativní hodnotou je teplota nástěnného termostatu, protože právě podle ní Tado zónu reguluje.

Přízemí je prakticky stále obývané. Neřeší se zde tedy běžná detekce „obsazeno / prázdno“, ale přechod mezi denním komfortem a nočním útlumem. Z analýzy vyplynulo, že hlavním signálem musí zůstat čas. Zhasnutí všech hlavních světel v kuchyni, obývacím pokoji a ložnici může noční režim pouze uspíšit. Krátké rozsvícení na WC nebo v koupelně naopak nesmí v noci obnovit denní komfort.

Guest Big a Guest Small: nepravidelně využívané pokoje

Oba pokoje mají vlastní Tado zónu a mohou samostatně vyžádat spuštění kotle. Guest Big používá tři radiátorové hlavice a samostatný nástěnný termostat; Guest Small má radiátorovou hlavici a nástěnný termostat. V obou případech je pro prostorovou teplotu vhodnější nástěnný termostat než údaj z hlavice zahřívané radiátorem.

Tyto zóny jsou většinu času prázdné, a proto pro ně nedává smysl každodenní komfortní rozvrh. Výchozí stav má být VACANT s nižší udržovací teplotou. Při příjezdu se ručně nebo později automaticky přepnou do COMFORT. Krátkodobé zvýšení teploty patří do samostatného režimu BOOST s časem vypršení.

Attic: jedna místnost, dva zdroje tepla a několik konfliktů

Podkroví je nejsložitější zóna. Obsahuje radiátor s hlavicí climate.tado_radiator_attic, který využívá plynový kotel, a klimatizaci climate.attic_toshiba_ac, která umí chladit i topit. Dále jsou zde dvě venkovní rolety Velux, elektricky ovládané střešní okno a senzor Velux/Netatmo měřící teplotu, vlhkost a CO₂.

Teplota z Velux senzoru byla vyhodnocena jako primární prostorová teplota. Údaj z Tado hlavice je pouze fallback, protože hlavice může být lokálně ohřátá radiátorem. Budoucí řízení musí zároveň zajistit, aby klimatizace netopila proti radiátoru, aby neběžela s otevřeným oknem a aby se rolety nepohybovaly do nebezpečné polohy při otevřeném Veluxu.

Pasivní části

Spodní WC má Tado hlavici, ale samo neiniciuje spuštění kotle. Využívá pouze dobu, kdy kotel běží kvůli některé hlavní zóně, a v návrhu proto zůstává pasivním následovníkem. Chodba nemá aktivní regulaci; její teplota se skládá z dostupných čidel ve třech Hue senzorech. Tyto části poskytují kontext, ale nesmějí být zaměněny za samostatné řídicí zóny.

Inventura devíti YAML packages

Balíčky nebyly špatným základem. Naopak už obsahovaly řadu užitečných senzorů, bezpečnostních podmínek a dlouhodobou historii. Cílem analýzy bylo určit jejich odpovědnost a zabránit tomu, aby stejný stav počítalo více souborů různým způsobem.

Problém 1: Solcast nepopisuje skutečné oslunění oken

Pro stínění se používaly entity sensor.solcast_pv_forecast_power_now a sensor.solcast_pv_forecast_peak_forecast_today. Z jejich poměru vznikal senzor „intenzity“ v procentech. Název mohl působit jako aktuální měření, ve skutečnosti však obě vstupní hodnoty pocházejí z modelové prognózy fotovoltaické výroby.

Bezplatnou verzi Solcast chceme zachovat. Pro tento projekt je dostatečná jako informace o očekávaném slunečním potenciálu, nikoliv jako náhrada fyzického čidla osvitu. Ani sun.sun problém neřeší: poskytuje polohu Slunce a umožní určit, zda může svítit na konkrétní okno, ale neříká, zda je mezi Sluncem a domem souvislá oblačnost.

To vysvětlovalo situace, kdy geometrie oken i Solcast vyžadovaly stínění, přestože byl den dlouhodobě zatažený a reálné riziko přehřátí bylo malé. Konzervativní fallback při nedostupnosti Solcastu navíc raději předpokládal významné slunce, což je bezpečné proti přehřátí, ale může vytvářet zbytečné pohyby rolet.

Navržené doplnění o počasí

Do rozhodnutí proto vstupují dva nezávislé zdroje předpovědi: Met.no jako weather.forecast_domov a Open-Meteo jako weather.povrly. Jejich úkolem není reagovat na každý krátký mrak, ale posoudit oblačnost v několika následujících hodinách. Pokud Solcast očekává silné slunce, zatímco předpovědi ukazují delší výrazné zatažení, preventivní stínění se potlačí.

Význam jednotlivých vstupů je tedy odlišný:

• sun.sun určuje den, azimut a možnost dopadu Slunce na konkrétní fasádu;
• Solcast v bezplatné verzi popisuje očekávaný solární potenciál;
• Met.no a Open-Meteo poskytují nezávislý kontext oblačnosti a očekávaného vývoje;
• vnitřní a venkovní teploty určují, zda je solární zisk problém, nebo naopak užitečné bezplatné teplo.

Blitzortung má jinou roli. Není vstupem pro odhad jasu, ale bezpečnostní podmínkou pro okna. Aktivní bouřkové riziko musí mít vyšší prioritu než požadavek na větrání a Velux zavřít nebo zabránit jeho otevření.

Problém 2: Velux rozhodoval správně, ale mohl být nestabilní

Původní logika už obsahovala důležité podmínky: minimální venkovní teplotu, rozdíl vnitřní a venkovní teploty, požadavek podle CO₂ a vlhkosti, blokaci při aktivní klimatizaci a uzavření při rizikovém počasí. Otevření bylo zpožděné a zavření mělo delší čekací dobu. Přesto se při hodnotách těsně kolem hranice mohl samotný požadavek opakovaně měnit.

Samotné zpoždění triggeru není plnohodnotná hystereze. Potřebujeme oddělit:

• raw požadavek — co vychází z teploty, CO₂ a vlhkosti právě teď;
• stabilní požadavek — stav potvrzený po definovanou dobu;
• cílovou polohu — zavřeno, mikroventilace nebo plné větrání;
• skutečnou polohu — potvrzení, že okno povel opravdu provedlo.

Otevírací a zavírací hranice nemají být stejné. Vedle teplotní hystereze je potřeba minimální doba setrvání ve stavu a jasné pořadí priorit: bouřka nebo aktivní AC → zavřít; ruční override → nezasahovat; větrání → nejprve ověřit bezpečnou polohu rolet; teprve potom měnit polohu okna.

Problém 3: topná sezóna nebyla totéž co celoroční klimatický režim

heating_season.yaml už měl rozumnou ochranu proti přepínání po jediném dni. Pokud některá Tado zóna požadovala teplo tři dny po sobě, zapnul topnou sezónu; po pěti dnech bez požadavku ji ukončil. Požadavek se správně odvozoval ze zón, nikoliv jen z chodu hořáku, protože Immergas může běžet také kvůli ohřevu teplé vody.

Problémem byl dvoustavový výsledek. Na jaře a na podzim může teplota ráno krátce klesnout pod komfort, ale slunce a vyšší denní maximum deficit bez topení dorovnají. Binární stav léto / topení také neuměl vyjádřit, že se už nemá agresivně bránit solárním ziskům, ale ještě není důvod spouštět pravidelné vytápění.

Návrh proto počítá se stavy summer, transition a heating. Doporučení má vycházet z předpovědi na přibližně 48 hodin, očekávaných minim a denních maxim z obou meteorologických služeb, z několika po sobě jdoucích kandidátních dnů a z největšího deficitu právě komfortní zóny. Nejdřív se má několik dní pouze doporučovat změna; automatické přepnutí produkční sezóny je až pozdější krok.

Problém 4: požadavek Tado, běh kotle a příčina startu nejsou stejná data

Hořák je detekován nepřímo podle příkonu zásuvky Shelly, v původním balíčku hranicí nad 80 W. Z toho lze spolehlivě odvodit start, stop, denní dobu běhu a průměrnou délku cyklu. Nelze z toho však přímo poznat, zda kotel topí do radiátorů, nebo připravuje TUV.

Balíček proto při startu porovnává aktuální a cílové teploty čtyř zón a ukládá pravděpodobného iniciátora. Je to užitečná diagnostika, nikoliv nezpochybnitelný důkaz. Pokud žádná zóna nevypadá jako žádající, výsledek je „pravděpodobně ohřev TUV“. Nová architektura musí tento rozdíl zachovat a nesmí používat samotný stav hořáku jako jediný podklad pro sezónu nebo obsazenost.

Problém 5: cílová teplota potřebovala jasného vlastníka

Dokud cíle mění časový plán Tado, není bezpečné, aby je současně pravidelně přepisoval Home Assistant. Jinak vzniknou dvě autority a ruční změna uživatele může být při nejbližším přepočtu bez vysvětlení vrácena. Pro každou zónu proto musí být odděleny tři hodnoty:

• automatický cíl podle sezóny, času a stavu zóny;
• dočasný override s jednoznačným časem vypršení;
• efektivní cíl, který by se později skutečně zapsal do Tado nebo AC.

Ground Floor zůstává výchozně komfortní a přepíná hlavně mezi dnem a nocí. Guest Big, Guest Small a Attic jsou výchozně úsporné a na dashboardu potřebují jednoduché volby Eco, Komfort a dočasný Boost. Přítomnostní senzory lze doplnit později, ale nemají být podmínkou funkčního základního systému.

Problém 6: volba zdroje tepla v Attic

Budoucí source manager podkroví musí nejprve zjistit efektivní cílovou teplotu a skutečný deficit. Až potom může volit mezi AC, GAS a vyčkáním. Pevná jediná teplotní hranice by vedla k přepínání zdrojů při každém kolísání venkovní teploty, proto návrh počítá s hysterezí, minimální dobou provozu a možností ručně zdroj vynutit.

Do automatické volby patří venkovní teplota, povolení AC heat, dostupnost zařízení a informace, zda už jiná zóna stejně potřebuje plyn. Později lze přidat i ekonomiku podle ceny elektřiny, plynu a přibližného COP klimatizace. Základní bezpečnostní pravidlo je ale neměnné:

• při topení klimatizací musí Tado v Attic dostat útlumový cíl, aby kvůli stejné místnosti nespustilo kotel;
• při topení plynem se klimatizace vypne a komfortní cíl dostane Tado;
• přechod musí zkontrolovat skutečný stav obou zařízení a nesmí proběhnout při neznámých vstupních datech;
• aktivní klimatizace vždy blokuje otevření Veluxu.

Datová kvalita a zachování historie

Analýza ukázala potřebu jednotných „autoritativních“ teplot. Ground Floor používá nástěnný termostat, Guest pokoje vlastní prostorové termostaty, Attic Velux/Netatmo s fallbackem na Tado a chodba průměr dostupných Hue senzorů. Každý odvozený senzor má uvádět zdroj a při výpadku raději přejít do unavailable než tiše nahradit teplotu nulou.

Samostatným technickým požadavkem bylo zachovat stávající entity_id, unique_id a historii. Už se objevil problém s duplicitním venkovním teplotním senzorem a také příliš složitá varianta venkovního průměru, která způsobila nedostupnost celého template bloku. Proto jsme se rozhodli provádět změny po malých částech, nepřesouvat současně logiku i identitu entit a každý mezikrok ověřit po restartu Home Assistantu.

Co se má zachovat a co změnit

Zachovat

• Tado jako výkonnou vrstvu pro ventily a vyžádání plynového kotle;
• zónové rozdělení a kvalitnější prostorová čidla místo teplot u zahřátých hlavic;
• stávající letní funkce, ruční blokace, movie režimy a bezpečnostní reakce na AC a bouřku;
• diagnostiku Immergas, počty startů, dobu běhu a historii existujících entit;
• možnost člověka kdykoliv automatiku dočasně přepsat.

Změnit nebo doplnit

• oddělit datovou, rozhodovací a výkonnou vrstvu;
• nahradit pouhé léto / topení třemi sezónními stavy a stabilním doporučením;
• doplnit Solcast o konsenzus oblačnosti z Met.no a Open-Meteo;
• oddělit raw a stabilní požadavek Veluxu a přidat skutečnou hysterezi;
• zavést explicitní stav využití zóny a časově omezený override;
• vytvořit samostatný source manager pro podkroví a vyloučit souběh AC s plynem;
• před aktivním řízením zobrazit všechna rozhodnutí, jejich důvody a rozdíl proti produkci.

Výsledek první fáze

Výsledkem analýzy nebyl nový plánovač ani přímé ovládání zařízení. Vznikl návrh vrstev: normalizovaná data → stav domu a zón → doporučený cíl → stabilizace rozhodnutí → teprve později konkrétní akce. Současné produkční automatizace měly zůstat beze změny, dokud nebude možné nový výpočet několik dní porovnávat s realitou.

Tím byla definována druhá fáze projektu: shadow implementace. Ta už obsahuje nový kód a dashboard, ale nemá oprávnění měnit Tado, klimatizaci, rolety, Velux ani produkční přepínač sezóny.