Všiml jsem si dnes (a vlastně možná u několikrát zpětně), že v případě záporných cen algoritmus se nikdy nesnaží nakupovat ze sítě do baterie. Nerozumím proč. Myslel jsem, že je to díky záporné ceně moc blízko nule atím pádem nevyjde celková cena včetně distribučních poplatků, ale zítra na Štědrý den v 16:00 bude cena -0.42. Což je docela dost. A systém celý den chce držet baterku na minimu. Tzn pojede ze sítě bez ohledu na cenu, spotřebu, cokoliv.
Podle mě je to špatně a mám cukání přepnout na DESS, abych se podíval na jeho plán. Protože tenhle zápor mi přijde docela zajímavý.
Je to záměr? Pokud ano, tak proč? A pokud ne, není to chyba například ignorací znaménka v rámci expression?
Nevyplatí se to kvůli amortizaci baterky - rozdíl mezi nejnižší a nejvyšší cenou ve dni musí být větší (po započtení distribuce a dph) než cena za amortizaci baterie - to se v žádném bodě neděje a proto je ekonomicky nejvýhodnější jen používat elektřinu ze sítě a baterii vůbec nepoužívat.
Ještě doplnim že zobrazená cena je bez našeho poplatku 0.35Kč/kWh - ten sám o sobě z toho udělá -0.07, distribuce to pak otočí kolem nuly do plusu a dph to ještě zvýší - rozdíl pak mezi touto cenou a nejvyšší cenou ve dni není vyšší než amortizace baterie (můžete si ji ale v nastavení změnit na co chcete, klidně na nulu).
Kdyby tedy WR nabijel, jen by prodražil cenu elektřiny o amortizaci a to by nakonec bylo dražší než ji používat přímo ze sítě s ohledem na dnešní ceny.
Až budou publikovány ceny na OTE pro 25.12. (Dnes kolem 13:00) a pokud tyto ceny budou výše, ještě může dojít ke změně plánu (ten se počítá každou hodinu) a baterie se nabije v těch 16:00 aby si tuto energii přenesl ba pondělní ráno, pokud tam budou ceny vyšší i po započtení amortizace.
Ok děkuji. Nějak mi nedošlo, že viditelné ceny jsou nákupní ceny spot, jelikož DESS uvádí už upravené.
Pak tomu rozumím. Mám tedy možná nějaký tip/tipy na možná vylepšení:
bylo by hezké kromě standardní spot ceny vidět ceny skutečnou nákupní včetně vašich poplatků a distribuce - dás se asi udělat vzorec ala DESS (kde jsem dle odhadu roční spotřeby a výroby rozpočítával měsíční ceny na kWh)
přišlo by mě zajímavé pracovat s korekcí predikce spotřeby/výroby. Podobný typ jsem psal i Dirkovi na DESS. Myslím to jako takovou cross-day dynamickou váhu nabíjení baterie. Podle mého v případě, že se dlouho drží baterie na minimu a současně se nepotkává predikce výroby/spotřeby s realitou, dle mého by se měla postupěm času zvyšovat výhodnot nabití baterie.
Reálně se zvyšuje šance, že cena z nízké hladiny se pohne výše, kdy bude baterie vybitá a dojde tak k vyšším nákladům. jelikož jsou ceny známy jen den dopředu, právě tato váha by se snažila tento stav kompenzovat - je asi jedno, jetli je implementace klasická či s dopomocí nějakého machine learningu.
Představa tedy je:
baterie na minimu, jede se ze sítě, jak jste psal díky amortizaci se baterie nenabíjí. Každou hodinu se ale o nějakou hodnotu sníží koeficient ceny amortizace baterie. V určitém bodě při stávajícíc hladině cen bude výhodnější začít nabíjet baterii. Pokud se cena zvýší, koeficient se pomalu vrací zpět na 1.
Samozřejmě jsou tam věci na odzkoušení - jaká je strmost křivky změn koeficientu, v případě začátku nabíjení baterie, co je pro danou hodinu cílové SOC, při jaké diferenci predikce/reálné situace, zda jako parametr používat i aktuální SOC atd. Ale jde mi o myšlenku.
Ano, v určitých momentech vlastně je absolutní aktuální cena nabíjení baterie vyšší než nákup ze sítě, která ale bude s velkou pravděpodobností kompenzována při nejbližším pohybu ceny vzhůru
pracujeme na tom - chceme to udělat pro uživatele co nejjednodušší a tedy automaticky načítat časy spínání HDO, tedy vysoký a nízký tarif. Bohužel ale získat tyto časy pro všechny naše zákazníky od konkrétních distributorů není nic jednoduchého (tak aby to bylo automatizované) a proto to možná dopadne nutností uživatele tyto časy zadávat ručně na nějaké období dopředu. Jakmile tyto vyřešíme, tak začneme zobrazovat ceny včetně distribuce, našeho poplatku a DPH a pak to chování WR bude jasně viditelné (samotné nás to občas mate, protože DPH je procento a tudíž roste s cenou a to člověk “nevidí jen pohledem na DT cenu”)
dává smysl tam zanést degradaci baterky tím, že se nenabíjí - zamyslíme se, jak to tam nejlépe dostat včetně vašeho návrhu. Už jsme to několikrát řešili, jen to zatím nemělo implementační prioritu.
Také bych uvítal kdyby Proteus v plánu zobrazoval hodinové ceny s vaším poplatkem a DPH. Případně ať si to může každý nastavit ve své konfiguraci podle sebe. Díky za vaši skvělou práci.
Dobrý den. Zdá se, že se změnou grafiky přišla změna algoritmu. Dnes mi v noci nabíjel baterii do 87 %, přestože cena v noci nebyla vlastně vůbec výhodná, předpověď počasí ukazovala, že bude od rána svítit a cena bude od ráno nulová. To bylo úplně mimo. Cenu nabíjení mám nastavenou na 2,50 Kč, aby zbytečně nenabíjel. Jak se dá takovému chování zabránit? Děkuji.
algoritmus je pořád stejný. Aktuálně se zdá, že Proteus u vás predikuje vysoké spotřeby na pondělní odpoledne, kdy predikuje že mají přijít vysoké ceny (nad 5Kč) a současně u vás predikuje velmi vysoké spotřeby v tyto hodiny a k tomu velmi nízké výroby. Začal se tak na to připravovat už dnes v noci.
Kolega to ještě prověřuje a dá případně větší detail.
Bohužel náš způsob predikcí spotřeby (což je vážený průměr za danou hodinu ve dni za 8 týdnu zpět) tu aktuální kombinaci faktorů (nabíjení EV v různé časy dne podle toho jaká je cena na SPOTu, výkyvy počasí, ale také ty extrémní ceny na spotu kolem 20:00) úplně nedává a u vás se to nejspíše potkalo tak, jak píšu výše.
Máme v plánu se tento týden nad tím sejít a udělat nějaké změny, protože nejste jediný, kde se tohle děje. Vesměs všichni co mají velké náhle spotřeby (EV) mají často problémové plány (včetně mě), které sice jsou číselně správně, ale počítají s velkou spotřebou, která se nakonec nestane v ten daný čas (EV).
Řešením je dočasně přepínat do manuálu než se nám podaří tento problém adresovat
To samé dělá jakákoliv větší spotřeba. Například to že jsme před týdnem přijeli z dovolené a pustila se během 4x pračka a sušička neznamená, že jí pustíme další týden znovu.
To vysvětluje proč se to chová divně. Nejspíš by to mělo být očištěné o extrémy, protože pokud jsem v danou hodinu jednou potřeboval výrazně víc než v ostatních osmi týdnech, tak není moc pravděpodobné, že to je něco, co se bude opakovat.
S predikcí spotřeby jsem si dost hrál u sebe v Home Assistentovi (ať už přímo nebo EMHASS) a nakonec jsem skončil u tupého zadání spotřeby v noci a přes den, protože se mi žádnou předpověď nepodařilo dostat do lápe fungujícího stavu než tohle. Victron DynamicESS je na tom s odhady spotřeby taky pro mě úplně nepoužitelně.
DESS evidentně používá též hodinový vážený průměr - vynášíme si jejich spotřeby do grafů a ta křivka je identická k naší, jen je posazená jinak vysoko, takže evidentně jiné váhy.
Řešení jsou prakticky dvě:
začít napřímo ovládat všechny ty větší spotřeby a tedy z predikci udělat plán - tzn. už není potřeba je predikovat, protože víme co to je, v jakém je to stavu a kdy se to bude zapínat (smart charging EV, smart ohřívání bojlerů, aku. nádrží atd.) toto je long-term cíl pro DG. Samozřejmě to znamená ohromné množství práce a tedy to bude “trvat”
nechat uživatele ty spotřeby zadávat - ideálně nějak snadno z pohledu UX - tedy udělat “šablony” pro EV, sauny, bojlery atd. a uživateli dát možnost říci, že se to dané zařízení stane tehdy a tehdy - je to prakticky manuální zastupné řešení bodu 1), ale výrazně rychleji dosažitelné - toto je něco co chceme implementovat velice brzo a následně postupně tyto “manuální šablony” převádět do automatického řízení viz bod 1)
Rozumím tomu, co to rozhazuje. Nahřívání bojlerů a bazénu jede na automat, ale to je 2, respektive 3,5 kW, celkem 25 kWh. Potom se nabízejí 2 auta, celkem 130 kWh. Nabíjení přes Victron EV je variabilní a v podstatě se zapíná jen při přebytcích. Což je v létě většinou přes den. Samozřejmě i auta se někdy úplně nabijou, a spotřeba vůbec nepřijde. Rozumím tomu, že se s tím dá jen velmi těžko pracovat, protože je to závislé nejenom na počasí, ale také na spotřebě aut. Na druhou stranu, když to večer vidím, nemůžu dělat nic jiného, než úplně vypnout celé řízení. Nejsem totiž schopen nabíjení baterie od 4 ráno nijak jinak zamezit. V podstatě by mi stačilo zamezit nebíjení baterie ze sítě třeba v nastavení.
přesně tak, proto ten bod 2, ať si to můžete upravit ručně a zapomenout na to a stane se to tak jak chcete - jde vlastně o možnost změnit ten plán na delší dobu než aktuální hodinu ale současně člověk není schopný to v hlavě spočítat co je vlastně následně nejvýhodnější - tzn. chceme tam dát možnost zadat nějaké parametry co a jak a Proteus to pak podle toho přepočítá.
O co jde - ono totiž když člověk bude chtít jit třeba do sauny večer v 8 - tedy v čas nejvyšších cen, tak ekonomicky bude nejlepší nabít baterku z FVE skrze den a pak ji např. od 17:00 až do 20:00 držet plně nabitou a používat na spotřebu v těchto hodinách elektřinu ze sítě (samozřejmě záleží na jeji ceně, všech poplatcích, DPH, distribuci vs amortizace baterie vs. kolik je úspora za použití baterky oproti sauně v těch 20:00) a použít baterii až na tu saunu. Jinými slovy čím dříve Proteus o této spotřebě, kterou sám nepredikoval, ví, tím lépe se na to dokáže připravit - když se to dozví hodinu před tak už s tím zpětně nic neudělá (býval by nabil nebo třeba naopak nevybíjel v předchozích hodinách, kdyby to věděl).
Toto spustíme už brzo - pak to jen začneme postupně měnit do “automatického” režimu skrze reálnou integraci daného zařízení.
@David Mohu mit prosim jeste doplnujici dotaz k cenam elektriny se kterou Proteus pocita pro nakup a prodej?
V nedeli se mi Proteus ve 13:00 rozhodl nabit baterii ze site z 63% na 100% pri cene elektriny -0,04 Kc a pak zakazat pretoky z FVE na nasledujici hodiny.
Realne me ale nakup elektriny pres Delta Green stal 0,31 Kc jestli se nepletu (protoze + 0,35 Kc vase marze), takze strategie byla zcela nesmyslna, v muj neprospech - Proteus mel nechat nabit postupne baterii ze slunicka.
Dle meho nazoru, Proteus by se mel rozhodnout nabit baterii ze site na 100% pokud je cena elektriny skutecne zaporna (tedy mene jak -0,35 v mem pripade). Jeste me napada jestli se pak ty panely zbytecne neničí když se jen “hřejou”, tedy možná by se tam dala uvažovat ještě nějaká konstanta k tomu.
Je to skutecne chyba / nedostatek na vasi strane ktery driv nebo pozdeji budete adresovat?
Nejsem z Deltagreen, ale kouknutím na obrázek se domnívám, že ta volba byla z několika důvodů:
2 hodiny předtím při zakázaných přetocích na normální provoz se nabily 2 procenta baterky → za mě to vypadá na blbé počasí
tzn. algoritmus pravděpdoobně předpokládal (na základě předpovědi, kterou nevidím), že se ani odpoledne nestihne baterka nabít - rozhodně ne z 63% na 100%. takže při nejnižší odpolední ceně nabil baterku, aby měl na večer případně prodej - zase nevím, jestli ten den realizoval prodej do sítě.
Za mě cena za odebranou elektřinu převýšila riziko, kdy by spolehal na nabití ze slunce, k tomu by nedošlo a vy byste večer nakupoval za 4 Kč…
Sám si také někdy musím říkat, že algoritmus pracuje s pravděpodobnostmi, predikcí a minimalizací ztrát. Tzn. že pokud by člověk (a důležité je říci, že až zpětně) vidí, že to šlo udělat lépe neznamená, že to mohl algoritmus vědět. Mnohdy je lepší rozhodnutí:aby zisk byl nižší díky nějaké řízené ztrátě (nebo ani ne ztrátě, jako poplatcích za nákup například) a byl na 90% správný odhad, než s 60% pravděpodobností spoléhat, že udělám o 10% více na prodeji.
Proteus stojí na lineárním programování tzn. je to čistá matematická optimalizace vstupů a hledání nejoptimálnější cesty. Bohužel ale dva ze vstupů jsou predikce výroby (to je ten přesnější, ač daleko od 100% přenosti) a predikce spotřeby (to je ten více chybový, obzvláště když jsou tam nárazově velké spotřeby v různé časy - používáme vážený průměr dané hodiny ve v daném dni v týdnů za osm týdnů zpět s větší váhou blíže k současnosti).
Nedá se na to koukat jen jak se to rozhodlo na základě dané hodiny - je potřeba brát v potaz celých 48 hodin se kterými Proteus pracuje - jinými slovy, pokud bude v noci elektřina za korunu a odpoledne bude za 5 korun a predikovaná velká spotřeba, je výhodnější nabít plnou baterku za korunu a následně to použít odpoledne místo čerpání ze sítě za 5Kč - to že se to nabíjelo za korunu a ne za nula není chyba, matematicky (ekonomicky) to stále dává smysl.
Každopádně budeme teď nasazovat ještě nový design pro plán kde bude více inormací k tomu, proč to udělalo co to udělalo a i jaké jsou predikce výroby vs spotřeby (resp. co převažuje) aby to dalo více informací k tomu, proč se to rozhodlo tak jak se rozhodlo.
Diky moc za info, to bylo poprve co se mi Proteus rozhodl nabit baterku na 100% - tak jsem si to zkoreloval s tou zapornou cenou elektriny a prislo mi ze je v algoritmu chyba - ze nepocita s vasi marzi.
Prijde mi ze statisticky ani historicky nemel duvod nabijet baterii na 100%, tak se tesim az bude Proteus uvadet i hodnoty vstupu podle kterych ridil plan abych mu vice rozumnel.
Konecne se mi podarilo zachytit plan Protea ktery mi nedava smysl, tak posilam screenshot. Dnes je 15.7. a spotove ceny na zitra 16.7. jsou jiz zname.
Z nejakeho zahadneho duvodu Proteus alternuje mezi “Normalni provoz” a “Spotreba ze site misto z baterie” i kdyz podle ceny elektriny to nedava smysl.
Zajimalo by me, proc na 11:00 a na 13:00 nenaplanoval “Spotrebu ze site misto z baterie” kdyz na 9:00 mi naplanoval spotrebu ze site a to je elektrina nejdrazsi.
S novým designem plánu přijde i vysvětlivka, že “spotřeba ze sítě místo z baterie” neznamená, že se vše v danou hodinu bere ze sítě - FVE panely normálně jedou a primárně se vše pokrývá z nich - jen na co panely nebudou stačit, se vezme ze sítě. Čistě číselně - pokud by Proteus predikovat spotřebu 4001 Wh a výrobu 4000Wh, tak tam spadne “Spotřeba ze sítě místo z baterie” ač se reálně použije jen 1Wh ze sítě (kdyby ty predikce byly na 1Wh přesné) a pokud by predikoval spotřebu 3999Wh při výrobě 4000Wh, tak tam spadne “Normální provoz”.
Pokusím se ještě předběhnout otázku, proč na 12:00 má spotřebu se sítě místo z baterie když predikce spotřeby je dle obrázku menší, než predikce výroby - zde simulace těch stovek možných “odchylek” predikcí vyšla tak, že je lepší být na straně spotřeby ze sítě při téhle nízké ceně než to brát draze z baterky (jinými slovy např. z 200 simulací vyšlo 120 tak, že to může dopadnou nakonec reálnou větší spotřebou a čistě číselně je lepší tedy baterku chránit a raději nakoupit, protože to co uchráním prodám pak mnohem výhodněji v těch 19:00) ač realita nejspíše bude, že se ze sítě nepoužije vůbec nic - ale to je to co jsem popisoval výše, Proteus se snaží pracovat i s mitigací rizika spojené s nesymetrickou cenou pro nákup a prodej. Tedy potenciální ztráta použítí energie z baterie a tedy neprodeji večer v 19:00 je větší, než nákup případného nedostatku ze sítě ve 12:00 a “ochránění” baterie do toho večerního vybíjení-
abych mu vice rozumnel.
