Dnes (21.10.) mě v datech v Proteovi zarazilo, když Proteus mezi 13:00-13:30 spustil 2x na cca 5 min. maximální dodávku do sítě (cca 6-7 kW). V detailech operací flexibility se pak ale objevily pouze velmi malé objemy, které mi ale nesedí s daty z VRM a HA. Proteus nasčítal za tu půlhodinu dodávku pouze v objemu 0,29 kWh, zatímco VRM mi tvrdí cca 1 kWh, což mi i při jednoduchém výpočtu na kalkulačce sedí víc. Přitom FVE v tu hodinu běžela normálně v módu nabíjení baterie z panelů (normální provoz). Kde dělám ve výpočtu chybu, že mi to nesedí?
takto to vidím u nás
Ta první aktivace otočila nabíjení baterky na vybíjení, tzn dodaný výkon je z +4kW na -4kW tzn 8kW krát čas (cca 5 minut) tzn. objem by měl být cca 0,67 kWh za tu aktivaci 13:10 až 13:15 - což u vás v Proteovi vidím, že nemáte.
Nechám prověřit, vím, že těch problémů se špatným objemem bylo teď více, kvůli úpravě logiky, jak se to počítá - samozřejmě to všem opravíme zpětně pokud je tam reálně problém
3 Likes
Ok, díky za prověření. Zarazilo mě právě ten malý objem, protože jsem přitom viděl, jak tu dodávku do sítě pouštěl Proteus na plný výkon.
1 Like
jojo, takhle v rychlosti si myslím, že to nemáme správně 
Takže díky moc za report!
Mně se dnes stalo, že flexibilita přišla reálně v 10:22 a taky během několika sekund se rozběhly měniče. Ale ve statistice se objevila flexibilita 10:19-10:29. Skončení proběhlo pár sekund po 10:30, což je standard.
Přijde mi, jestli nemůže být cinklý ten čas startu flexibility o 3 min dřív než je reálný čas, nebo jestli se požadavek ze serveru reálně zpozdil?
Problém 1
Koukal jsem na to vyhodnocení. U prvního příkazu byl problém, že my koukáme na hodnotu před aktivací, v ten konkrétní časový bod ale přišly nepřesná data. Celé vyhodnocení tak pak bylo proti špatnému referenčnímu bodu. Pracujeme na tom abychom výpočet změnili, aby nezapočítal hodnoty, které chvilkově ustřelí (bohužel se to čas od času děje). Objem vám přepočítáme.
Problém 2
Druhá aktivace je problematičtější. Výpočet objemu flexibility probíhá tak, že vezmeme hodnotu na gridu ze střídače (patě domu) a odčítáme od ní spotřebu (v každém časovém okamžiku) od toho odečítáme hodnotu na gridu poníženou o hodnotu spotřeby z momentu před aktivací. T.j. v podstatě koukáme na změnu na patě domu očištěnou o naměřenou spotřebu.
Odečítání spotřeby, vychází z toho, že chceme započítávat pouze zařízení, které jsme schopni řídit. Jakmile budeme rozšiřovat sadu zařízení co řídíme (například EV), tak se zbytková hodnota bude snižovat. Celý výpočet předpokládá, že spotřeba je absolutně nezávislá na aktivaci flexibility ale rovněž předpokládá že změna spotřeby by se bez aktivace projevila na hodnotě gridu.
To k čemu došlo je, že se v časovém okně flexibility výrazně snížila spotřeba. Výpočet tak předpokládá, že bez aktivace flexibility by to vedlo k výrazně vyšším přetokům (protože nepracuje s tím, že by se bývala začala nabíjet baterie). To jestli je náš výpočet správný tak závisí na stavu baterie v daný moment a plánu řízení.
Pokud dojde v rámci aktivace ke změně spotřeby bude se lišit i výpočet dodané energie v rámci flexibility. Tohle je vědomá nepřesnost kterou ve výpočtu máme. Způsobuje ale symetrickou chybu, t.j. jednou objem zvýší, a podruhé sníží a přes více aktivací by pro vás měla být neutrální.
Jak bychom to měli dělat
Nejlepší způsob jak objem spočítat je modelovat přesné hodnoty na zařízeních, které řídíme (nyní pouze baterie a FVE) v případě že by k aktivaci nedošlo, t.j. baseline bez flexibility, a dopočítávat hodnotu na patě domu. Pak jednoduše porovnat naměřenou realitu a modelový výpočet a rozdíl brát jako aktivovaný objem. Do výpočtu by vstupoval plán řízení, limity výkonů na baterií, limity jističů na domu atp. A tady je kámen úrazu.
Ačkoliv je teoretický výpočet nejlepší, přináší řadu problémů. Předpokládá, že jsme schopni správně modelovat chování systému “bez zásahu”. To se ale ukazuje jako relativně problematické, například:
- Baterie jsou nezřídka rozbalancované a u MSoC nám tak často zmizí značná část energie (tohle je často nesymetrická chyba, buď tam je a nebo není).
- Baterie často nedosahují výkonů, které jsou nominálně uvedené. Pokud předpokládáme, že baterie zvládne 6kW výkonu, ale v realitě jsou to 4, tak do výpočtu baseline musí vstoupit 4, protože více spotřeby za například náhle zapnuté nabíjení elektromobilu nepokryje.
- Výkony nejsou plošně odlišné, závisí především na aktuálním nabití baterie a teplotě, tento koeficient tak musíme dynamicky přepočítávat. Znovu se typicky nejedná o symetrickou chybu.
- Museli bychom modelovat ztráty systému.
Jsem přesvědčen o tom, že dlouhodobě, budeme právě tento způsob používat, ale předtím musíme všechny data vyčistit a být si jisti že nedochází k systematickým chybám. Ačkoliv současný přístup přináší chyby neměl by být zatížen systematickou chybou. Bez přesných limitů baterie, chování systému a zbývající energie, baseline spočítat nelze.
@premyslav
Ano, bohužel se nám několikrát stalo, že příkaz do střídače přišel s velkým zpožděním. Chybu jsme opravili a nyní by vše už mělo fungovat lépe.
1 Like
já sem musím zmínit, že se omlouvám datovému týmu pod vedením @Prokop, že jsem zmínil konkrétně toto:
Nechám prověřit, vím, že těch problémů se špatným objemem bylo teď více, kvůli úpravě logiky, jak se to počítá
Byl jsem upozorněn, že změna kódu, co to počítá, proběhla naposledy více jak rok zpět
Ten problém není v samotném výpočtu, ale v tom, že se bere jako baseline specifický bod před aktivací, viz co píše Prokop a u vás se to zrovna “hezky” potkalo s tím, že Victron API prostě sem tam vrací nesmysly (děje se to prakticky pořád, u někoho častěji, u někoho méně častěji) a u vás se to zrovna potkalo, vypadá to konkrétně takto:
Když si sečteme energie do systému a ze systému, tak to nesedí - tzn. vzniká tam elektřina “z ničeho” a nebo se naopak ztrácí “nikam”. U vás je to ještě relativně malá výchylka, u některých zákazníků to API vrací klidně výkony najednou v MW na pár vteřin a pak se to vrátí zpět do “reality kilowatt”.
Každopádně u vás použijeme jiný bod pro baseline a přepočteme a obecně tu baseline nebudeme nejspíše dělat dle jednoho bodu, ale spíše průměru nějakého časového intervalu jako například 15s (proč to píšu nejistě je proto, že u vás by to pomohlo, ale u zákazníků, kde zrovna přijde chyba v řádu MW, ten průměr 15s nic neřeší, pořád to bude nesmysl - takže je potřeba to ještě více projít a promyslet jak přesně to řešit)
David: Co použít mediánovou hodnotu z 5 hodnot těsně před aktivací?
Byla by použita prostřední hodnota z těch 5 a “smazaly” by se extrémy.
dává smysl, máme na to meeting v pátek myslím, tak to tam přednesu