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ď.
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
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.
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
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ě
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ší…
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 :).
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
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.
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.
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
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.
