Skip to content

Latest commit

 

History

History
292 lines (216 loc) · 16.7 KB

File metadata and controls

292 lines (216 loc) · 16.7 KB

Automatické kontroly

Přehled toho, co jednotlivé moduly dělají a kdy. Všechny hodnoty pocházejí z výchozí konfigurace v src/main/resources/application.yml — pokud jste ji změnili, platí vaše hodnoty, ne ty zde.

Každý modul lze vypnout jeho enabled přepínačem, nebo dočasně z nástěnky.


Hlídač nabití baterie — automation.battery

Běží každou hodinu v :05 a jedná jen v nastavených kontrolních bodech.

Pozadu za plánemself-use-thresholds, jedná jen v režimu FEED_IN_PRIORITY:

Čas Požadované nabití O víkendu
13:05 50 % 60 %
14:05 70 % 80 %
15:05 90 % 100 %

POKUD je baterie pod cílem a střídač je v režimu FEED_IN_PRIORITY PROVEĎ: přepni na SELF_USE, aby zbytek výroby šel do baterie.

Napřed před plánemfeed-in-thresholds, jedná jen v režimu SELF_USE:

Čas Nabití pro přepnutí
09:05 50 %
10:05 70 %

POKUD je baterie na cíli nebo nad ním a střídač je v režimu SELF_USE a předpověď na další 3 hodiny má kvalitu ≤ 2,2 PROVEĎ: přepni na FEED_IN_PRIORITY, aby se přebytek prodal místo aby propadl.

JINAK POKUD je baterie na cíli, ale obloha je zatažená PROVEĎ: nech SELF_USE — za slabého slunce výroba sotva pokryje dům a to málo, co by odešlo do sítě, se stejně večer nakupuje zpět.

Obě kontroly vychází ze skutečně naměřeného nabití, ne z předpovědi — zachytí i slunečnější dopoledne, než čekala předpověďová kontrola modulu počasí. Předpověď rozhoduje jen o tom, jestli se přebytek vůbec vyplatí posílat do sítě (viz níže). Každý kontrolní bod jedná jen ve "svém" režimu; ostatní režimy (např. BACKUP) nechává být.

Tolerancetolerance, výchozí 2 %. Kontrolní bod je očekávání, ne smlouva: baterie na 79 % proti cíli 80 % je prakticky vzato podle plánu a přepínat střídač kvůli takovému rozdílu jen způsobí, že režim kolem kontrolní hodiny poskakuje. Cíl proto platí za splněný, jakmile je nabití v rámci tolerance pod ním — v obou směrech, tedy i pro přepnutí do FEED_IN_PRIORITY. Víkendový příplatek se připočte k cíli první, tolerance se měří až proti výslednému číslu.

Kontrola slunečnafeed-in-weather, platí jen pro přepnutí do FEED_IN_PRIORITY. Nabitá baterie je jen půl důvodu dodávat do sítě; ta druhá půlka je, že ještě něco přijde. Kontrolní bod proto přepne, jen když průměrná kvalita předpovědi na dalších look-ahead-hours (3 h) je na max-quality (2,2) nebo pod ní — stejná hranice jako automation.weather.cloudy-threshold, aby se oba moduly na tom, co je „slunečno“, shodly. Když předpověď není dostupná, kontrola se přeskočí a režim zůstane beze změny. Bez API klíče na počasí nastavte enabled: false — modul se pak jako dřív rozhoduje jen podle nabití. Kontroly self-use-thresholds počasí neřeší vůbec: přestat dodávat je vždy bezpečné.


Limit dodávky — automation.export

Běží každou čtvrthodinu v :00, :15, :30 a :45 mezi 4:00 a 20:59, a navíc při každé změně přepínače připojení. Přesně na čtvrthodinu proto, že přesně tehdy se mění i cena — a je známá dlouho dopředu, takže není na co čekat. Hodinová kontrola by nechala střídač dodávat do záporné ceny až tři čtvrtě hodiny.

POKUD je spotová cena ≥ 0,5 CZK/kWh PROVEĎ: otevři dodávku na 3 950 W.

JINAK POKUD je přepínač v poloze HIGH (připojeno na měřenou síť) PROVEĎ: uzavři dodávku na 20 W — prodej by se nevyplatil, při záporné ceně by dokonce stál peníze.

JINAK (přepínač LOW, dodávka se k měřené přípojce nedostane) PROVEĎ: otevři dodávku na 3 950 W.

V grafu spotové ceny jsou intervaly pod 0,5 CZK/kWh uvnitř aktivních hodin přeškrtnuté šrafou a jejich sloupce ustoupí do pozadí — tam se dodávka do měřené sítě nevyplatí a modul limit uzavře. Mimo aktivní hodiny se limitem nehýbe, takže se ani nešrafuje.

Polední přiškrcení, jen při přepínači LOW:

POKUD je 12:00–14:59 a průměrná kvalita předpovědi je ≤ 3,0 PROVEĎ: nastav dodávku na power.reduced.

Ve výchozím nastavení je power.reduced rovna power.maximum (3 950 W), takže přiškrcení nic nemění. Snižte ji, pokud chcete v zatažené poledne nechat víc výroby v baterii.


Režim podle počasí — automation.weather

Běží každou hodinu v :02. V nastavených kontrolních bodech řeší slunečno/zataženo, ve všech ostatních hodinách kontroluje bouřku.

Kvalita předpovědi = úroveň typu počasí + oblačnost / 100. Nižší je slunečnější: 0 je jasno, 3–5 zataženo nebo déšť, 10 a výš bouřka.

Kontroly výhledu výroby

Čas Sledované okno Nabití potřebné pro FEED_IN_PRIORITY
07:02 09:00–12:59 10 %
09:02 10:00–14:59 20 %
11:02 12:00–16:59 40 %

POKUD je kvalita ≤ 2,2 (slunečno) a baterie má dost PROVEĎ: nastav FEED_IN_PRIORITY — přebytek se vyplatí dodávat.

JINAK POKUD je kvalita > 2,2 (zataženo) PROVEĎ: nastav SELF_USE — výroba patří do baterie.

Pozdější kontroly chtějí plnější baterii, protože zbývá méně dne na nápravu špatného odhadu.

Kontrola bouřky

Každou ostatní hodinu, výhled na následující 2 h.

POKUD je kvalita > 10,0 PROVEĎ: nastav BACKUP a drž baterii jako zálohu pro výpadek.

JINAK POKUD je střídač v BACKUP a příští hodina klesla pod 8,5 PROVEĎ: vrať SELF_USE.

Hystereze 1,5 brání překlápění režimu, když nad domem přechází fronta. Režim BACKUP nastavený ručně modul nikdy nesahá — opustí ho jen tehdy, když ho sám zapnul.


Prodej do sítě — automation.discharge

Plánuje se jednou denně v 15:00, tedy až po zveřejnění denního trhu.

Trh se vypořádává po 15 minutách, den má tedy 96 cen. Plánovač postupuje ve třech krocích:

  1. Špička — nejdražší interval mezi 15:00 a 23:45.
  2. Plató — od špičky se rozšiřuje na obě strany, dokud sousední intervaly zůstávají do 1 CZK/kWh pod ní. To je ta část večera, do které se opravdu vyplatí prodávat.
  3. Umístění — baterie zřídka pokryje celé plató, takže se okno dlouhé přesně na to, co baterie utáhne, posouvá po platu a vybere se umístění s nejvyšším výnosem. Při shodě vyhrává pozdější umístění, aby vybíjení skončilo na konci platu, a ne aby došlo ještě před špičkou.

POKUD je špička < 8 CZK/kWh PROVEĎ: neplánuj nic a napiš do logu proč.

Plánovač se na baterii nedívá. Běží v 15:00, tedy hodiny před večerní špičkou a ještě za slunce — nabití změřené v tu chvíli neříká nic o nabití v 19:00. Okno se proto plánuje jen podle ceny a délku určuje (min-battery − 40 % rezerva) × 11,6 kWh × 0,92 ÷ 4 600 W (vybíjecí výkon), nejvýše 4 hodiny. min-battery je 50 % — nabití, které prodej stejně vyžaduje; když už je baterie výš, počítá se to skutečné. Nadhodnotit se nedá, protože stejná hodnota je i práh pro zahájení; podhodnotit ne, okno by bylo příliš krátké na využití špičky.

Jestli se prodej vůbec vyplatí zahájit, se rozhoduje znovu při otevření okna, proti té samé hodnotě:

POKUD je při startu baterie < 50 % (min-battery) PROVEĎ: okno zahoď a napiš do logu proč.

Okno naplánované ručně z nástěnky tuhle hranici ignoruje — je to rozhodnutí člověka —, rezervu ale nikdy.

Vybíjecí výkon discharge-power je výkon baterie, ne výkon do sítě. Dálkové řízení řídí baterii a dům se z ní krmí dřív, než cokoli dorazí k elektroměru — při nastavení přesně na automation.export.power.maximum (3 950 W) tedy do sítě odejde limit mínus aktuální spotřeba domu a zbytek se „prodá“ do vlastní rychlovarné konvice, a to zrovna v nejdražší hodinu dne.

POKUD má do sítě odcházet celý limit PROVEĎ: nastav discharge-power nad limit — rozdíl pokryje spotřebu domu a limit dodávky ve střídači drží elektroměr na 3 950 W. Výchozí 4 600 W je 3 950 W + 650 W rezervy na spotřebu.

Platí dva stropy: co baterie a střídač zvládnou dodat (o víc se dá požádat, ale nevznikne to) a limit dodávky, který je po dobu prodeje jediné, co drží přebytek mimo elektroměr — rezervu proto nastavujte podle skutečné spotřeby domu, ne podle štítkového výkonu střídače. Hodnota 0 znamená „řiď se limitem dodávky“, tedy chování před zavedením tohoto nastavení.

Obě čísla se používají jinde a log je uvádí obě: délka okna se počítá z vybíjecího výkonu, protože tou rychlostí se baterie doopravdy vyprazdňuje, kdežto očekávaný výnos jen z té části, která projde elektroměrem — co sní dům, nikdo nekoupí.

Prodej se provádí dálkovým řízením, ne změnou režimu střídače: relace má vlastní dobu trvání a střídač se po ní sám vrátí do svého režimu — i kdyby tahle aplikace mezitím spadla. Hlídač kontroluje baterii každé 2 minuty a ukončí relaci dřív, jakmile se dosáhne rezervy 40 %.

V grafu spotové ceny je ta část dne, do které se smí prodávat — uvnitř prohledávaných hodin (15:00–23:45) a na minimální ceně (8 CZK/kWh) nebo nad ní — podbarvená barvou prodeje a minimální cena je vedená čárkovaně napříč grafem. Je to místo, kde okno může vzniknout, ne kde vznikne: jestli v něm nakonec vznikne, rozhoduje až plánovač podle špičky, plató a nabití baterie.

Okno lze z nástěnky zrušit (Zrušit plán), nahradit jiným (Přeplánovat) nebo naplánovat ručně (Naplánovat okno). Ruční okno jde zadat dvěma způsoby: mezi časy, nebo začít hned na zvolenou dobu. Varianta „začít hned“ se řídí hodinami aplikace, ne prohlížeče.


Rychlé akce z nástěnky

Vedle karty prodeje sedí Rychlé akce — ruční zásahy pro to, o čem automatika vědět nemůže. Nic se neplánuje ani nepamatuje:

  • Režim střídače (Vlastní spotřeba, Priorita dodávky, Záloha) — trvalý. Přežije restart a modul jej může při dalším běhu opět změnit. Aktuální režim je na tlačítkách zvýrazněný a přepne se hned po přijetí příkazu, ne až s dalším čtením střídače; změna si navíc zapíše i režim, ze kterého se přepínalo, takže pruh Režim střídače dnes má čím obarvit úsek před ní.
  • Dálkové řízení (Nabít ze sítě, Prodat do sítě, Ukončit dálkové řízení) — střídač se sám vrátí do svého režimu, i kdyby tahle aplikace spadla. Vyžaduje připojení k SolaX Cloud. Ukončit dálkové řízení je aktivní jen tehdy, když nějaká relace opravdu běží; řádek pod kartou napíše, proč je případně vypnuté.

Nabíjet lze dvěma způsoby: na dobu, nebo do nabití. Vyplňte Do nabití a relace poběží, dokud baterie nedosáhne zadané hodnoty, ať to trvá jakkoli dlouho — konec určí sám střídač, tenhle režim (soc_target_control_mode) žádný časovač nemá. Pole s dobou se přitom ztlumí a řádek pod poli předem napíše, která z obou variant se odešle.

Ukončení dálkového řízení během běžícího prodeje projde modulem prodeje, ne za jeho zády, takže naplánované okno i historie zůstanou v souladu se střídačem.

Opuštění dálkového řízení se posílá dvěma příkazy, ne jedním. Cloud hlásí exit_vpp_mode jako úspěšné, jakmile ho zařadí do fronty, a některé střídače relaci sice ukončí, ale zůstanou ve svém stavu dálkového řízení — v aplikaci SolaX Normal Mode(R-n) —, dokud opravdu neproběhne dokumentovaný přechod exit remote control. Nejdřív se proto pošle jednosekundová relace s nulovým výkonem a nextMotion = 160, která tenhle přechod provede, a přímé ukončení jde až na ni. Jedna sekunda při 0 W s baterií neudělá nic. Pokud váš střídač odchází i po samotném exit_vpp_mode, nastavte solax.cloud.exit-with-push-power: false.


Přepínač přípojky

Stav GPIO vstupu (BCM 17) je vidět v dlaždicích na přehledu: Měřená síť při HIGH, Druhá přípojka při LOW. Mimo Raspberry Pi, nebo s raspberry.enabled: false, se čte záskok hlásící trvale HIGH — dlaždice to napíše, aby se náhražka nepletla s měřením.

Každé přehození přepínače se navíc zapisuje do historie, takže průběh dne se kreslí jako tenký pruh pod pruhem režimu střídače (graf Režim střídače dnes) — obojí na jedné časové ose, protože co dělal limit dodávky odpoledne dává smysl až vedle toho, do které přípojky se v tu chvíli dodávalo. Se záskokem místo skutečného GPIO se pruh nekreslí vůbec: celý den „měřené sítě“, který nikdo nezměřil, by byl výmysl.


Změny režimu mimo aplikaci — solax.control.work-mode-watch

Střídač nepřepíná jen tato aplikace: režim jde změnit z aplikace SolaX, přímo na displeji střídače i plánem uloženým v něm — a nic z toho se sem neohlásí. Pracovní režim se proto jednou za minutu (interval) čte zpátky a změna, kterou aplikace neudělala, se zapíše do historie jako každá jiná.

POKUD střídač hlásí jiný režim, než jaký měl při minulém čtení, a není to režim, který aplikace sama krátce předtím zapsala PROVEĎ: zapiš změnu do historie pod zdroj Střídač — objeví se v Poslední aktivitě i v pruhu Režim střídače dnes.

Nic navíc se kvůli tomu nečte: kontrola se dívá na tentýž uložený snímek, který stejně obsluhuje nástěnku i moduly.

Vlastní zápisy se nezapisují dvakrát. Každé úspěšné nastavení režimu se hlídači ohlásí a režim, který odpovídá zápisu mladšímu než attribution-window (5 min, aby přežil i frontu příkazu přes cloud), se bere jako vlastní — zaznamenal ho už ten, kdo ho nastavil.

Co hlídač nevidí: změnu provedenou, když aplikace neběžela nebo byl střídač nedostupný — pod grafem se pak jen napíše, že se aktuální režim neshoduje s poslední zaznamenanou změnou — a cokoli během dálkového řízení, které střídač řídí bez sáhnutí na trvalý režim.

Nic se podle toho neděje. Jde o záznam, ne o zásah: ručně nastavený režim vydrží, dokud nepřijde další kontrolní bod modulu počasí nebo baterie a nerozhodne jinak.


Historie akcí

Zaznamenané akce se drží 48 hodin (timeline.retention) a ukládají se do data/timeline.json, takže po restartu nástěnka nezačíná prázdná a grafy nemají díry, které už nic nedoplní. Strop timeline.persisted-events je jen pojistka, aby zacyklený modul soubor nenafoukl. Záznamy starší než okno se při čtení souboru zahodí — aplikace vypnutá týden se nesmí vrátit s týden starou „poslední aktivitou“. Je to pořád jen pohodlí pro zobrazení — trvalým záznamem zůstávají rotující logy v logs/.

Každý řádek má nadpis a vysvětlení: co modul rozhodl a proč. Kolik řádků je vidět, se přepíná přímo v hlavičce karty Poslední aktivita (5 až 100) a volba se pamatuje v prohlížeči.

V hlavičce jsou i dva filtry, obojí zapamatované v prohlížeči: Dnes / Včera / Vše vybírá den (historie sahá dva dny zpět) a Jen změny schová kontroly, které nic neudělaly — limit dodávky se přepočítává každou čtvrthodinu a skoro vždy vyjde „není co dělat“, což je 68 řádků denně, pod kterými se ztratí těch pár, které něco říkají. Neúspěšná kontrola zůstane vidět vždycky.

Tytéž záznamy kreslí i graf Plánovaných akcí, když se přepne na Celý den: hodiny před aktuálním časem se doplní tím, co doopravdy proběhlo, na řádku svého modulu a potlačeně, aby plán zůstal to první, co je vidět. Neúspěšný běh je červený. Graf Kvality počasí se přepíná stejně; hodiny, které už proběhly, se ukládají průběžně do data/weather-history.json, protože předpověď sama dozadu nevidí. Restart je tedy nesmaže, ale co aplikace nikdy neviděla (třeba ráno před prvním spuštěním), v grafu chybí — osa i tak zůstane celý den a pod grafem se napíše, odkdy jsou hodiny zaznamenané.