plánuje přesně obráceně - ví že ceny jsou asymetrické a tudíž cokoliv prodat a pak to muset brát zpět je pro něj mnohem větší váha než skončit s energií navíc - tzn. realita věci je přesně obráceně než píšete.
To proč se to teď děje je proto, že se rychle mění počasí mezi slunečnými a zataženými dni a ten průměr posledních 5 týdnů dané hodiny v daném dni prostě dělá bordel - lítá to nahoru dolů jak se mění spotřeba díky topení a ten průměr to jen vyhladí a je někde uprostřed (mimo).
umožnímě měnit plán a měnit i predikce spotřeby, uživatel si pak vybere co mu vyhovuje upravit více (změnit uplně plán nebo jen změnit predikce a nechat to protea spočítat)
Já určitě nechci, aby mé výhrady vyznívali nějak kriticky. Jenom mě právě mrzí, že Protea nemůžu používat neustále, nechat ho zapnutýho a zapomenout na něj. Sám jsem vývojář, takže určitě chápu, jak dokážou být zákazníci nevděční . Berte to spíše obchodně a prozákaznicky, protože i já jsem Delta Green doporučil několika lidem. Pokud ale nebudou ty lidi spokojeni nebo budou mít pocit, že ten algoritmus nefunguje dobře, tak se to rozkřikne, bude vám to kazit jméno a budou hledat jiná řešení a dodavetele / odběratele elektřiny. To pak bude mít i vliv na počet zákazníků a to obchodování s flexibilitou, které má bý pro vás výdělečnější, jak sám píšete.
To podsekávání spotřeby přes noc mi dělá Proteus v těchto slunných dnech pravidelně. V noci nemám žádnou mimořádnou spotřebu, takže odhadovaná spotřeba by přece měla odpovídat průměru z předchozích týdnů. Přesto mi Proteus večer plánuje vždy tak o 10 % větší vybití než je potřeba na spotřebu v noci a ráno při prvních odběrech po východu slunce vždy spadne do Low SOC, protože je na min. SOC a slunce ještě svítí slabě. Nebo ještě kolikrát ty poslední procenta baterie ráno vybije do sítě. Já mám pouze drahou VT distribuci, takže v podstatě vždy na tom tratím, když to tahá ráno z gridu.
já jsem i zkoušel řešení, že victron skrze scheduled charing zastavíme cíleně 5% nad msoc a držíme ho tam do rána a až když vyleze slunce, tak to pustíme, aby nespadl na msoc a nespustil ess low soc - bohužel ta “mrcha” to i přes jasné procento scheduled charging nechává spadnout až 3% pod to co je nastaveno.
tzn. řešení je pak nebýt 3% nad msoc, ale spíše cca 7% - chvíli jsme to měli takto a ozvali se lidi, proč to držíme zbytečně do rána 7% nad msoc, že to mohli využít pro sebe . . .
Za mě dává smysl jen ten hack rychle podlézt aktuální msoc a vrátit se zpět a donutit ho skrze to vylézt z ess low soc.
Pro vysvětlení mé frustrace - solax, goodwe atd jsou “všechno stejné instalace” a tudíž cokoliv pro ně děláme, funguje plošně - Victron je modulární a kažád instalace téměř unikátní - už několikrát jsme něco udělali jako řešení nějakého problému a pak se ukázalo, že to funguje ok jen pro lidi s DC couplingem, ale dělá to bordel pro lidi s AC couplingem (třeba řízení výkonu skrze setpoint dělá fakt nepořádek pro lidi s AC couplingem kteří mají Fronius - ten to nedává a tak raději téměř vypíná výrobu kdykoliv se změní setpoint a pak pomalu asi 20s najíždí zpět - pokud přijde změna setpointu, tak se stane to samé znovu - reálně tak nejdou výkonově řídit, protože jinak zákazník přichází o FVE výrobu). Těch výjimek, hacků je tam hrozně moc a vždycky něco pro někoho zlepšíme a ihned to pro jinou skupinu victron zákazníků zase něco rozbije.
Na rovinu - lidi co umí programovat a baví je to to vždycky budou mít lepší než my, my se musíme snažit najít “cestu pro všechny” která prostě nebude na specifické Victron instalaci fungovat lépe než custom kód pro tu danou instalaci
Jak jsem popsal výše, tak mód ESS1 u mSoC ve Victronu nevidím jako ten primární problém a není tedy problém výhradně Victrona, jak říkáte. To, že tam dodatečně je ještě ESS1 problém tak ten je navíc, ale ani k němu nemusí dojít.
Já přes noc mám 300Wh spotřebu a s baterkou bych bohatě vystačil. Jenže Proteus na 6hod ráno naplánuje baterku na mSoC a s ohledem na plán spotřeby ještě večer část baterky prodá ven, aby to k ránu doiterovalo na mSoC a pak se dějou mnou popsané problémy.
Co tedy udělat řešení pro všechny? Reálné mSoC si zákazník nastaví na svojí FVE a plánovací mSoC pro Proteus si nastaví u vás? Takže si každý vybere, někdo si ty hodnoty nastaví stejně, někdo s rozdílem 5% někdo 10%.
PS: Davide, my vás tu nekritizujeme. Vaše komunikace a zpětná vazba se zákazníky je skoro unikátní a díky za to!!
Logika je jasná a srozumitelná a v tomto není rozpor. Model je postaven na hodinových odhadech. Jinak to asi nejde. Souhrnně tu hodinu budu mít plán i realitu správně. 1kwh na spotřebě v plánu i opravdu. Problém je distribuce té spotřeby v rámci hodiny, kdy mohu spotřebovávat 4kW 15minut a 0kW 45minut. Plán vyšel, ale reálně jsem musel 3kW vzít ze sítě. Proto se tu bavíme o nějakém bufferu - rozdílu mezi reálném mSoC a plánovacím mSoC.
Každopádně díky za diskusi, vím, že se snažíte udělat maximum pro všechny.
Pozn.: Někde jsem četl, že DESS od Victrona pracuje s dvěma limity (nekamenujte pokud to není pravda). Bohužel je mi k ničemu, protože neumí pracovat s vícetarifním plánem na spotu.
jj DESS má dva limity, ale “hajzlíci” ten druhý nemají v API a tudíž nejde používat externě (námi) - už jsme na to koukali
ale jak píšu, ten hack na ESS low soc by měl vyřešit to tančení kolem těch 3% ráno + umožnit změny řízení na další dobu nebo upravit predikce by mělo řešit ten zbytek.
Musíme k tomu ale dát nějaký “manuál” kde jsou popsané ty hlavní situace, které matou, aby to lidi neměli, i když je to vlastně správně - dáváme dohromady nějaký blog či micropage kde jsou ty případy, které často vyvolávají dotazy, popsané, proč jsou vlastně správně
Možná jsem to napsal špatně. Proteus plán udělá správně podle predikcí co má. Nezůstane tam ale žádná rezerva když se netrefí. Buďto nárazová spotřeba (třeba se přes noc něco peče v troubě) nebo věci závislé na počasí (za chvíli to bude třeba temperování skleníku nebo v létě zavlažovaní, kdy doba běhu čerpadla záleží na počasí a vlhkosti půdy). Nečekám, že někdy takovéhle bude Proteus schopný odhadnout, proto bych byl rád aby v plánu nechával rezervu. Mám relativně velkou baterii, takže prostoru tam je dost. Samozřejmě je otázka jestli vám to stojí za to implementovat, nebo jsem příliš okrajový případ .
Každopádně chci řešení o které se nebudu muset starat, takže každodenní ruční ladění plánů a predikcí není nic pro mě. Vzhledem k tomu, že poměrně slušné řízení už mám v Home Assistantu, tak pro mě do budoucna asi bude nejlepší varianta API pro flexibilitu a řídit si zbytek sám.
Jak řešíte skrze vlastní řízení tu nárazovou spotřebu v noci (např. to pečení) ? To stejně musíte někam jít zadat, aby se to správně přepočetlo.
Můj osobní pocit je, že se nepotkáváme v tom, co je ekonomicky výhodnější
Pokud je večer možný prodej za 6.5Kč/kWh a následně do doby než zase začne svítit slunce ( a tedy spotřeba se pokreje z výroby) jsou všechny hodiny co se spotřeby týče pod 6.5Kč/kWh (včetně všech poplatků, distribucí a DPH) tak se prostě vyplatí to vše poslat z baterie do sítě a pak to brát v průběhu noci zpět ze sítě - což je přesně to co se stalo.
To co popisujete, že by tam zůstala rezerva na noční pečení a na ráno na rychlovarku nebo cokoliv jiného na tom faktu nic nemění - naopak když si to tam necháte na tuhle spotřebu, tak jste místo toho, že jste to mohl prodat, použil proti spotřebě, kterou jste mohl pokrýt ale z gridu za nižší cenu než ten prodej - tedy ztráta.
jinými slovy, tenhle konkrétní případ dvou dní (středa a čtvrtek) se dá zjednodušit takto:
je úplně jedno, kolik je noční a ranní spotřeba, i kdyby byla 100kWh, pořád je pro vás výhodnější to vše prodat z baterie za 6.51Kč (čtvrtek) a brát to následně vše z gridu v těch hodinách potom, protože žádná z nich nebyla dražší včetně všechn poplatků a DPH než těch 6.51Kč/kWh - a toto přesně Proteus udělal
ještě možná takto - prostě prodat vše co mám za (vymyšlených) 200kč/kWh a pak jakoukoliv spotřebu brát zpět z gridu za 5Kč/kWh bude vždy výhodnější než neprodat a pokrýt si tu spotřebu z baterie a neplatit těch 5Kč/kWh - schválně jsem to nafoukl na 200Kč/kWh aby byl výrazně vidět ten ekonomický smysl
Na spoustu věcí mám predikce (třeba zavlažování nebo temperování skleníku), tim se mi výrazně omezí nečekaná spotřeba. Na druhou stranu predikci běžné spotřeby jsem nakonec jsem nakonec omezil na statickou křivku, která je na nastavená tak aby se do ní spotřeba většinou vešla (což je víceméně opačný přístup než Proteus, který se snaží trefit přesně). Ono s naším fungováním nějaký model těžko bude fungovat rozumně, protože čímkoliv hrozně pohne když jeden den jede třikrát pračka a sušička. Tohle pak spíš znamená, že další den bude nižší spotřeba…
Prodej večer a odběr v noci má smysl, ale Proteus to většinou udělal tak, že v noci se ještě jelo z baterky a ráno když byla elektřina drahá, tak se bralo ze sítě. Reálně ten prodej taky neumím udělat optimálně, můj algoritmus zase prodává málo . Subjektivně to vidím jako menší problém protože to vede k neefektivnímu prodeji a ne k drahému nákupu. Jestli to je reálně ekonomicky lepší ani neumím vyhodnotit.
Navíc teď už nechci prodávat vůbec nic, protože s rozumným plánováním všechny přebytky utopím v bazénu a teplé vodě. To byl vlastně původně důvod pro mojí automatizaci a predikce, aby se tepelné čerpadlo na bazénu pustilo, když budou přebytky větší než co bude potřeba na ohřev teplé vody. Ideálně se pustí už ráno, aby běželo co nejdéle. Spuštěním bazénu jsem se tak dostal do části roku kde predikce co dělá Proteus jsou už úplně mimo.
Pořád mě tam “dráždí” to polemizováni nad neefektivním prodejem vs nákupem. Pokud je cena prodeje vyšší než cena nákupu ve všech následující hodinách, tak nic není výhodnější než to prodat a pak koupit zpět. To je čistý matematický fakt
Pokud ráno přijde hodina která je dražší než cena za ten večerní prodej a výkon FVE ještě není schopny pokrýt spotřebu v tuto hodinu, pak ano, pak se vyplatí si něco málo na ráno nechat, ale jak psal Prokop:
pokud je ta hodina o halíře dražší než cena za ten večerní prodej, proteus tak riskuje ze ztráta bude maximálně tyto halíře. Kdyz neprodá a ráno pak neni ta elektřina nakonec potreba, tratí tim koruny. Proto se vždy rozhodne jit tou cestou s potenciálně nižší ztrátou.
Obecně sledujeme v těchto diskuzích, že má pro mnoho z vás velkou “emoční” hodnotu “nebrat z gridu” resp co největší soběstačnost. Koukal jsem se do detailu na DESS od victronu a evidentně bojovali s tim samým a proto dávají na výběr mezi “co nejvice finančně výhodné” a “co nejvíce soběstačné”. Je ale potřeba si uvědomit, ze to druhé neznamená nejvice výhodné (finančně). Jen to optimalizuje na co neumenší používání gridu - extrémem pak je situace kdyby elektřina byla pořád za nula, tak on i tak pojede hlavně z baterie (a tedy náklady skrze amortizaci) ač finančně dává největší smysl baterku úplně odstavit a jet jen z gridu.
Proteus je stavěny čistě na finanční optimalizaci, soběstačnost není jeho cílem - je to krásně vidět u zákazníků co si nastavili vysokou amortizaci baterie (3kc a vice) a jsou pak překvapení, že jakmile spadly ted ceny oproti prosinci, že proteus se snaží velice často blokovat nabíjení jejich baterie, protože skrze nižší cenu na spotu je proste finančně lepší vše co se ihned nespotřebuje posílat ven a následně kupovat zpět v pozdější hodiny a vubec nepoužívat baterii.
U mě je konkrétní případ 19.-20.3. Večer se prodalo za 5,06 Kč/kWh a ráno se nakoupilo za 8,50 Kč/kWh. Většinu noci se přitom brala spotřeba z baterie. Když by se to pokrylo v noci za 4,70 Kč/kWh, tak by to dávalo smysl a možná by to i vyšlo bez ranního odběru ze sítě. A ano má pro mě velkou emoční hodnotu nenakupovat za takovéhle peníze, když svítí slunce celý den a mohlo se to pokrýt z vlastní výroby.
Proteus to plánuje optimálně podle predikcí, akorát že predikce se dost často netrefí (aspoň u nás). V kombinaci s tím, že plánuje na minimální SOC, tak to pak typicky znamená drahý odběr ze sítě. Když predikce vyjdou, tak se chová podle očekávání. Takhle ho musím hlídat, občas so něj zasáhnout nebo řízení vypnout. Pak zase zapomenu ručně vypnout přetoky . Možná jsme prostě moc daleko od průměru a nemá smysl na nás Proteus optimalizovat.
“Emoční” hodnota - ano, moc pěkně pojmenované - sám se trochu “mračím”, když Proteus např. v noci jede ze sítě (ač by emočně nemusel, ekonomicky je to OK).
Moc moc se přimlouvám za “vyjmutí” nabíjení EV z predikcí tam - kde je to technicky možné - a kde se zjevně nabíjí a) ze sítě, b) “solar only” - u Solaxu Green mode.
Absolutní hodnota kWh-objemu nabíjení EV ze své velikosti značně likviduje směroplatnost takto počítané predikce spotřeby. Vidím to tam ještě mnoho dmů po té, co EV už těží jen ze slunce.
To stejné činí i spotřeby, které jsou iniciovány vlastní (zvýšenou) spotřebou v době záporných cen - bojlery, bazény, řízené nabíjení EV.
Stejně tak spotřeby, které se “zapnou” v době přetoků jako takových (Solaxí Smart Save mód Drycontactu, různé Wattroutery, atp.) jsou další “podmíněného” typu.
Tyto se asi budou hůře “detekovat”, aby šly případně odečíst. Ale pokud ano, vypovídací schopnost predikce spotřeby by se takto mohla zlepšovat. Což je ovšem jen mé hlasité uvažování a delší akademická debata. Asi vám tohle (vývojářům) nemusím říkat.
No - a kdyby v portále někdy v budoucnu existovala tlačítka jako:
“šetři baterii na dnes večer” - aka sauna
nebo
“režim dovolená do XX/YY” - tedy minimální spotřeba domu, žádné výkyvy, max. vydělávej
Koukal jsem co se u vás 19.-20.3. dělo. Jak píšete, prodej do sítě sám o sobě nebyl špatně, problém nastal, že algoritmus neudržel dostatečné nabití baterie do ranních drahých hodin. Vzhledem k vysoké distribuční sazbě VT u vás je ten rozdíl hodně vidět (a není to jen drobná nepřesnost).
Těch problémů je tam několik. Bohužel u nás v noci nastal výpadek, a algoritmus se až do ranních hodin nepřepočítával. Počítal tak s plánem který se naposledy počítal před 21h 19.3. (a ten ještě předpokládal, že energie bude stačit). Algoritmus tak neměl aktuální informace o stavu baterie, a plán se dynamicky neupravil. Tady věřím, že pokud by vše fungovalo jak má, tak by se nám podařilo do ranních hodin ušetřit energie výrazně více.
Druhý koncepční problém je, že plánujeme na hodinových intervalech. A model si myslel, že od 7h, bude vaše domácnost soběstačná z FVE. Tady budeme muset model upravit. Tento problém nenastává jen u vás, kde ikdyby to za hodinový průměr platilo, první část hodiny typicky energie chybí. Možné řešení je model počítat v menší než hodinové granularitě, ale není to úplně triviální úprava (a je to výpočetně výrazně náročnější). Poslední problém jsou predikce, kde se nikdy netrefíme úplně přesně ale musíme naše modely vylepšit.
Platí ale také co jsem psal ve vlákně vedle. Není realistické trefit zůstatek na baterii úplně přesně. A v případě, že energie v baterii zbyde, je náklad s tím spojený ve dnech jako 20.3. relativně vysoký. Prodejní cena je přes poledne 0, a každá volná kapacita na baterii má tak velkou hodnotu. Ale máte pravdu, u vás konkrétně to chování algoritmu v tento den neobhájí. S vysokými rozdíly v distribučních sazbách je ta citlivost na chyby vysoká.
Máme v plánu postupně přidávat možnosti jak chování algoritmus ovlivnit, ať už přímo přeplánovat, nebo upravovat vstupy, které do modelu jdou. Tak aby mohl člověk řízení přizpůsobit konkrétním parametrům domácnosti.
To odečítání velkých spotřeb, typicky aut, jsme testovali. Problém byl, že model spotřebu vyhodil ale uživatel nyní nemá možnost jak ji do modelu zpět přidat (mimo manuální úpravu v danou hodinu). Což je především pro noční hodiny dost problematické. Odsunuli jsme tak řešení do doby, než se implementujeme možnost uživatel do modelu nebo jeho vstupů zasáhnout. Tady doufám dojde k posunu brzy.
tak ještě pro info, k tomu problému s Victron ESS#1, třeba se to bude někomu hodit.
Udělal jsem u sebe pokus, jak se to chová, když je mSOC na FVE nastaveno nižší než na Proteovi. Použil jsem jednoduché udělátko v node-red přímo na Victroním Cerbu, které když přijde změna mSOC - u mne na 20% (hodnota nastavená v Proteovi), tak ho hned přehodí na 15% (udržuje tedy 15).
Ráno byla trochu větší spotřeba než Proteus odhadoval. SOC kleslo až k 15%, tam zabralo ESS#1 a začalo to pomalu baterii dobíjet. Proteus jel dál v režimu Normální provoz, a v celou další hodinu jen upravil plán - ponechal Normální provoz a cílové SOC dal 20%.
Čili tohle chování je z mého pohledu ok - nenastal tam ten problém, že ESS#1 nabije baterii na mSOC+3% a Proteus se ji vzápětí snaží zase vybít, a případně i v následující celou hodinu přeplánuje znova vybíjení na mSOC a celé se to opakuje (což jsem předtím opravdu někdy i pozoroval).
Takhle vypadá ten flow v node-red, kdyby se to někomu hodilo:
Můj názor tedy je: pokud by se to nějak řešilo na straně Protea, tak čistší a univerzálnější řešení (jak už zmiňovali jiní, pomohlo by ne jen pro ten ESS problém), než přidávat hack se snížením a hned zase vracením mSOC jen pro Victrony, by bylo opravdu jen změnit aby Proteus na ten mSOC na straně FVE prostě nesahal (a do popisu v nastavení dát, že je to hodnota pro plánováni, doporučená stejná nebo lehce vyšší než je nastaveno na FVE).
. Berte to spíše obchodně a prozákaznicky, protože i já jsem Delta Green doporučil několika lidem. Pokud ale nebudou ty lidi spokojeni nebo budou mít pocit, že ten algoritmus nefunguje dobře, tak se to rozkřikne, bude vám to kazit jméno a budou hledat jiná řešení a dodavetele / odběratele elektřiny. To pak bude mít i vliv na počet zákazníků a to obchodování s flexibilitou, které má bý pro vás výdělečnější, jak sám píšete.
.
. Možná jsme prostě moc daleko od průměru a nemá smysl na nás Proteus optimalizovat.
