Flexibilita spotřeby a Proteus

[Daniel]

Zdravím vespolek,
mám dotaz k Flexibilitě v Proteu. Používám chvíli, tak se v tom chci zorientovat. Vezmu příklad z dneška. Prosím o potvrzení bodů dole.

Ráno prodával do sítě. Nejdražší hodina je v 17h a tak k ceně po 9h přidal Flexibilitu, tak aby vykompenzoval případnou spotřebu v 17h za tu nejvyšší cenu.

1. Jestli tomu dobře rozumím, tak právě při spotřebě stejného objemu el. ze sítě v těch 17h jako jsem poslal předtím do sítě já vlastně žádnou odměnu za Flexibilitu negeneruji.
2. Generuji odměnu, pouze pokud spotřebuji energii jakoukoliv levnější hodinu ze sítě než 17.hod.
3. Amortizace baterky se nereflektuje, protože bych ji tak jako tak z baterky dostal na vlastní spotřebu (při vypnuté Flexibilitě)
4. Ztráty AC DC se nereflektují, protože bych tak jako tak z baterky konvertoval do AC při vlastní spotřebě a při odběru ze sítě konverze AC DC neprobíhá.

Díky za potvrzení.
Dan

[David]

Je to přesně tak jak píšete.

Každopádně akorát děláme poslední kontroly a dneska s půlnocí (pokud se něco nerozbije ) to změníme a bude tam “ještě něco navíc” tzn. nebude tam kompenzace jen oproti nejdražší hodině ale bude to oproti nejdražší hodině + delta - aktuálně dáváme deltu na 2Kč.

Současně změníme výpočet pro DOWN aktivaci - cílem je vám častěji posílat levnější elektřinu do baterie pro použití v dražší hodiny - bude se tam měnit výpočet že to nebude oproti nejnižší prodejní ceně, ale oproti nejnižší nákupní ceně - delta = reálně to znamená, že kompenzace bude o trošku nižší pro DOWN než je teď, ale reálně to snížení ceny způsobí, že bude více příležitostí pro aktivaci (oproti ceně odchylky) a tím více DOWN aktivací, které jsou stále zajímavé, jinými slovy, o trošku menší odměna, ale větší množství vs větší odměna ale menší množství (aktuální stav).

Půjde k tomu oficiální komunikace a aktualizace informací na webu + i techničtější vysvětlení pro ty které to zajímá

[David]

už ale teď víme, že hned bude následovat další změna, která bude více reálně reflektovat amortizaci - na to ale ještě nemáme hotovo všechny věci okolo, o co konkrétně jde:

amortizace se děje na základě vaší energetické bilance - pokud vaše FVE vyrobí za den více energie než spotřebujete, tak DOWN aktivace nedělá žádnou amortizaci (baterka by se nabila tak nebo tak) ale UP jí způsobuje (ubijeme a ono se to hned nabije z FVE, což by se normálně nestalo). To samé přesně obráceně pokud výroba z FVE je menší než spotřeba.

Současně chceme začít počítat vaší konkrétní zadanou amortizaci do toho výpočtu, to ale znamená, že aktivační ceny začnou být unikátní pro každého zákazníka (teď tomu tak není, všichni mají stejnou - jen tam trošku průměrujeme rozdíl mezi distribučními sazbami VT/NT, resp. ten rozdíl reálně kompenzujeme ze svého, bylo to aktuálně nejrychlejší řešení jak se dostat k něčemu, co můžeme spustit).

Jakmile bude mít každý zákazník unikátní cenu, musíme ale předělat celý systém aktivace, který aktuálně umí pracovat jen s jednou cenou (vyplatí se pustit nebo nevyplatí oproti predikci ceny odchylky?) a začne aktivovat jen část zákazníků podle jejich unikátní ceny - tzn. na základě predikce ceny odchylky pustí všechny zákazníky, kteří mají cenu nižší než predikce. Toto je ale složitější zásah do infrastruktury, která celou aktivaci ovládá.

Jakmile uděláme změny, aby toto bylo možné, vše popsané výše je ta “end game” toho jak má algoritmus fungovat (plus ještě přibude to, že budeme zpětně dávat bonus navíc, pokud se nakonec potvrdí cena odchylky opravdu vysoko - tedy profit share z extrémně úspěšné aktivace - potvrzené ceny odchylky se dozvídáme až s denním zpožděním).

A do tohoto všeho ještě přijde technická flexibilita - tedy ta přímo pro ČEPS, kde je placeno i za pohotovost oproti jen aktivaci a tím se ty platby ještě zvednou - máme toho v pipelině opravdu hodně a proto tolika změn - ze kterých je mnoho jen “dočasných” abychom to k vám dostali co nejrychleji než přijde to lepší řešení, které ale ještě zabere nějaký čas

[Daniel]

Díky Davide, ta komplexita je velká. Držím palce. Taky jsem si říkal, že by bylo lepší častěji nabíjet než vybíjet. Dneska už jsem skoro plaite a ceka me ta 17. hodina A zajímalo mě jestli aktivujete jednotlivce. Díky za zajímavé info a výhled. Ta pohotovost pro Ceps bude extra sluzba mimo Flexibilitu nebo bude navázána na vyšší odměnu za Flexibilitu?

[David]

budeme to mít pod “jednou flexibilitou” a budeme za vás rozhodovat, co je pro vás lepší dle aktuálních tržních podmínek - zda obchodní flexibilita oproti odchylce nebo technická pro ČEPS (reálně je to jedna a ta samá, jen “z opačných břehů odchylky :)” ) - obchodní jde dělat s jakýmkoliv výkonem ale je potřeba predikovat cenu odchylky a trefovat se, jinak je to ztrátová záležitost. Technická pro ČEPS je potřeba splnit certifikace a mít konkrétní výkony které musí striktně následovat řízení od ČEPSu, ale zase máte jistotu ceny aktivace (oproti nejistotě v podobě odhadu ceny odchylky) + odměnu i za rezervaci.

Obojí to pak uvidíte jako odměnu v rámci flexibility, tak jak ji máme teď.

[Hugo]

Dostal jsem nabídku na flexibilitu,ale nevím jestli je už vhodný čas na přepnutí.Proteus používám již přes půl roku a jsem s tím spokojený.V létě bez toho nejde fungovat.Díky za odpověď ohledně to přepnutí
Hugo

[David]

není to vylučující se - naopak je ideální mít zapnuté automatické řízení a k tomu flexiblitu. Pak je z toho největší zisk.

Jde mít samozřejmě kombinaci - automatické řízení vypnutí a flexibilitu zapnutou například, ale naše doporučení je mít zapnuté obojí

[MikeTe]

Zdravím, dneska, možná po avizovaných změnách ve výpočtech, se mi po 13h nějak chybně zobrazil výpočet ceny spotřeby, kde je chybně uvedeno za distribuci 0 a NT. Přitom já žádný NT pro odběrné místo nemám. Před 12h jsem přitom koukal, že na tu 13h byla cena spočítána dobře.

[tomasd]

Dobrý den,
rád bych se připomenul o přístupové údaje k API o které jsem žádal v soukromé zprávě. Nějak se asi ztratila.

Díky,
Tomáš

[radoslavius]

Me by zajimalo jak to je, jestli vlastne vubec nejake pouzitelne API je. Podle me existuje jen nejaka rozpracovana dokumentace, ke ktere jsem dostal odkaz. Pokud se pletu a neco je, tak bych mel rad taky pristup. Na dnesnim webinari bylo receno, ze nejake API bude mozna v 1. kvartalu roku 2025. Diky Radek

[David]

Je tam chyba, pracujeme na opravě, výpočet protea funguje správně ale máme chybně zobrazení NT/VT cen

[David]

Aktuálně existuje MQTT API ale s téměř nulovou dokumentaci a určené hlavně pro integrátory dalších zařízení.

Vydáme jiné co bude mít primárně signály pro flexibilitu ale i signály řízení Protea, chci ho mit co nejdříve abychom vám umožnili připojit vše možné i nemožné, ale nesmím s tim prý předbíhat tsk to čeká další v řadě

[PetrH]

Zdravím a měl bych dotaz, nebo námět. Teď se po 2 dny stalo, že přišel požadavek na dodávku do sítě, ale baterie byla vybitá. Těchto pár dní nebyly rozdíly na spotu v průběhu dne takové, že by se vyplatilo nabíjet a vybíjet baterii, tak třeba dnes byla celý den na minimu SOC. Napadá mě, že pro takovéto případy by se měla udržovat baterie na cca 50%, protože bych měl rezervu pro výpadek gridu, měl bych kapacitu pro poskytování flexibility a pro baterii je to dlouhodobě lepší. Neřešil jsem to hlouběji, jen se mi to zdá pocitově lepší…

[Prokop]

Dobrý den,

bohužel u flexibility dopředu nevíme kdy nastane a jakým směrem, její potřeba je vyhodnocována pouze v reálném čase. Jakákoliv predikce je silně nespolehlivá.

Zatím k optimalizaci přistupujeme tak, že se snažíme nabíjení/vybíjení baterie řídit v prvním kroku proti spotu, tak jak je dle predikcí pro vás nejvýhodnější. A v případě aktivace flexibility poskytujeme takovou kompenzaci, která je pro vás vždy výhodná. Tj. flexibilita funguje jako další hodnota nad spotovou optimalizaci (a vždy skutečně přinese hodnotu navíc).

Máte pravdu, že může být výhodné v baterii držet více/méně elektřiny (pro potřeby flexibility) než automatické řízení naplánuje. Optimalizace je pak ale výrazně komplikovanější. Automatické řízení by pak muselo “přednabitou energii” držet v baterii po relativně dlouhou dobu, pro aktivace, které nemusí přijít. A často by tak docházelo k situaci, kdy celá operace nebyla optimální (flexibilita často není aktivovaná několik dnů po sobě). Například včera/dnes jsou ceny elektřiny v rozmezí cca 2-3,5. Kč/kWh. Na Nový rok, 1.1. v noci budou ale ceny velmi pravděpodobně výrazně nižší. Pokud bychom tak baterii nabili dopředu, bude se často stávat, že ji nenabijeme v nejvýhodnější hodinu. Tento problém tak platí stejně i pro automatické řízení. Ve dnech kdy FVE svítí, je pak jakákoliv rezerva ještě problematičtější.

Aby systém fungoval správně, museli bychom brát v potaz výhled cen elektřiny a predikci výroby fve/spotřeby domácnosti na delší časový úsek dopředu (než současných 48 hodin). Tak abychom například nedrželi nabitou baterii do slunečných dnů, kdy byste pak přebytky elektřiny musel dodávat do sítě. Kvalita predikcí se ale s delším časovým oknem výrazně snižuje. Testujeme možnosti jak algoritmus z tohoto hlediska vylepšit, ale je to netriviální problém, a nějaký čas nám určitě zabere než otestujeme řešení, které bude fungovat univerzálně (pro všechny roční období, pro všechny naše zákazníky a bude správně reagovat na dynamický vývoj cen na energetických trzích).

Ale v principu máte pravdu, prostor pro zlepšení tu rozhodně je :).

[PetrH]

Dobrý den,
děkuji za obšírné vysvětlení, ale musím svoje myšlenky ještě upřesnit. Je mi jasné, že flexibilitu nepředpovíte, ale můžete být na ni připraveni a mít něco v zásobě. Třeba tento konkrétní případ, teď bylo více dnů, kdy se nevyplatilo z důvodu spotu nabíjet baterii do plna, takže baterie se pohybovala ve spodní polovině kapacity. Kdyby se kapacita pohybovala v horní polovině, tak je k dispozici rezerva. Jakoby mít kromě volitelné tvrdé hodnoty min SOC ještě další “virtuální” hranici SOC, kterou by Proteus udržoval v takovýchto obdobích nízké volatility spotu a pracoval s ní jenom v těch současných 48hodinách. Jde mi hlavně o rezervu pro výpadky napájení, rezerva pro flexibilitu je na druhém místě. Jsou lokality, kde jsou výpadky častější a tam by se to hodilo.
Do budoucna bych měl námět, že by Proteus mohl využívat varování před extrémním počasím a dopředu nabít baterii na plno a nečerpat z ní. Kupříkladu když budou hlásit na noc vichřici nebo mrznoucí déšť, tak je předpoklad výpadku napájení a dá se na to připravit. Podobně to dělá v USA Tesla Powerwall…
Další věc je predikce výroby FVE, u mě vlivem profilu terénu a stromů je predikce v zimě hodně optimistická, až o 100% a pak vychází automatizace méně efektivně. Bylo by fajn možnost uživatelsky nastavit “lokální koeficient produkce FVE”, a pak by si to mohli sami uživatelé zohlednit a zpřesnit odhad.
Berte to jako náměty na vylepšení, ale vy to vidíte v širších souvislostech a něco vám smysl dá, něco ne

[prehor]

Dvojí SOC pro flexibilitu by mohl fungovat podobně jako Backup mód pro Solax - při požadavku na dodávku v rámci flexibility baterii vybít až o 5% pod min. SOC (nebo volitelnou hodnotu) a jakmile důvod na dodávku pomine ji zase dobít na min. SOC. Tím se dá pro flexibilitu využít rezerva v baterii, kterou držím pro případ výpadku sítě.

Myšlenka nabití baterie na 100% před nahlášeným extrémním počasím přímo v Proteovi se mi líbí. Zatím to řeším tak, že Protea na tu dobu manuálně vypnu.

[Daniel]

Dneska se jela flexibilita tedy hodně. Škoda, že špatným směrem a baterie byla rychle prázdná. Asi se hodně prepocitali dnes

[Prokop]

Ano máte pravdu že z hlediska rezervy pro případ výpadku by rezerva pomohla. Máme na to i úkol, včetně predikce rizikových faktorů extrémního počasí. Jen na to bohužel ještě nebyl čas :). Ale jak jsem psal, s rezervou je problém, kdy ji nabít a jak dlouho ji udržovat. Protože typicky přes zimu jsou delší období, kdy je cena vysoká (pak se vyplatí baterii vybít a rezervu neschovávat) a nabít když je cena elektřiny nejnižší. Tak jak tomu bylo např. 1.1… A rovněž baterie nesmí držet rezervu do slunečních dnů, aby byla kapacita volná pro nabíjení ze samovýroby. K tomu aby to fungovalo správně musíme zohlednit delší časové okno než na které nyní Proteus kouká. Přípravě na flexibilitu, která by sebou nesla náklad na straně uživatele, se zatím cíleně vyhýbáme (ale pokud to bude pro uživatele výhodné, určitě se do budoucna pokusíme s něčím přijít).

Predikce FVE upravujeme, zkoušíme jiné poskytovatele meteorologických dat i zohledňování lokálních specifik, a výhledově je snad mírně zlepšíme. Nicméně, tady vždy bude velká část, která zůstane nepredikovatelná. Proto naše automatické řízení funguje ve scénářích a vybírá takový model řízení, který statisticky bude fungovat nejlépe i s ohledem na chyby v predikcích.

Ale každopádně moc děkuji za podněty. Je vždy dobré slyšet zpětnou vazbu a to kde systém nefunguje tak jak by měl.

[PetrH]

Nevím, jestli se Proteus učí u každého klienta zpřesňovat predikci výroby ze skutečnosti, jestli když u mne předpovídá 2x více výroby, tak se naučí, že já prostě tolik nevyrobím
Pokud ne, tak by se možnost uživatelské korekce odhadu výroby hodila. Protože to má dopad i na to, že u mne není potřeba nechávat na slunečné dny (prosinec, leden) rezervu v baterii, protože nevyrobím tolik, abych ji významně dobil. V mém konkrétním případě nebude žádný model dostatečně přesný, žádný nezohlední stromy, na které kůrovec zapomněl

[khostri]

S tím dvojím SOC se to už několikrát probíralo. Samozřejmě by to bylo zajímavé, jen bylo vysvětleno že jsou s tím určité komplikace. Otázkou je, jestli by to v podstatě nevyřešil nějaký skokový model ala Victroj BatteryLife. Tím myslím princip, ne konkrétně toto.
Tzn například mít hard spodní hranici SOC v Proteovi v nastavení. Ale v rámci dne by se hodnota SOC zvyšovala, a nebo snižovala horní hranice 100% u zákazníků se zepnutou flexibilitou. Pokud by počet minut v rámci dne, kdy byla baterka na nejnižším SOC přesáhla určitou hodnotu (kterou by si mohl uživatel korigovat - taková jakoby flexibilita), tak by se min SOC zvýšilo třeba o 5% případně max nabití snížilo o 5 %. Toto by se nedělo trvale ale do určité horní hranice
Takže v běžných dnech by se v zásadě nic nedělo, ve slunečných dnech by držel na horním konci rezervu pro flexibilitu a stejně tak a dolním konci by při delším špatném konci zvětšoval rezervu.