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).
Nevím, jak přesně myslíte “bude se snažit ihned s počátkem další hodiny nabijet zpět na msoc”, ale co jsem při tom pokusu pozoroval (je to kdyžtak vidět na mém účtu okolo 7:00 dnes) bylo: SOC bylo na 17% tedy pod mSOC, po přepočtu plánu zvolil Normální provoz, cílové SOC pro danou hodinu nastavil na 20%, a baterie se pak nabíjela normálně z panelů. Což mi přijde v zásadě ok.
už to vidím jak to tam přepisujete na 15%, tak to Proteus po chvíli vzdal (resp. nevzdal, ale zkouší to v mnohem pomalejším tempu), aby se nehádal do nekonečna a vyčetl si tu novou hodnotu a pracuje s ní - tzn. reálně plánuje oproti 15% mSoC teď, ač zadaných je 20%.
Zajímavé, jsem ani nevěděl, že bereme tu vyčtenou místo té zadané
Vida ho Ale aspoň se pak při dalším přeplánování držel 20% a nesnažil se např. znova vybíjet do 15% nebo tak něco.
Jinak to že si po přepočtu naplánuje nabíjeni, ať už na ten mSOC nebo třeba i vyšší, z panelů nebo i ze sítě, prostě tak jak mu to vyjde výhodně, tak to už bych vnímal jako v pořádku.
tak oprava, on plánuje s tím zadaným, ale nutí nabíjení na msoc na základě “ifu”, že soc < msoc - jste našel zajímavý hack
bohužel tohle nebude fungovat pro “průměrné” uživatele, oni prostě častokrát neví co je co, dokud jsme to nezačali forcovat, tak jsme pořád řešili stížnosti, proč to nevybil na zadané procento v proteovi a odpovědí bylo, že si na FVE dali msoc vejš než to procento k nám a to pak Proteus nedokáže vybít pod to mSoC.
Myslím si, že ten hack na snížení msoc a vrácení zpět to pro absolutní většinu vyřeší, protože si ani nevšimnou, že se něco takového děje a nám to sníží zatížení support linky. Uvidíme
Aktuálně nevím, proč se přes noc neplánuje Normální provoz, ale šetření v baterii a ráno budu mít baterii plnou. Je to proto, že jsem možná dřív dopoledne v pondělí dobíjel BEV? Nicméně dobíjení BEV pouštím podle výroby FVE, případně při velmi nízkých cenách v síti jako v neděli. Tedy pokud nesvítí slunce nebo je drahá elektřina, tak nabíjení BEV a jinou velkou spotřebu odložím asi jako většina lidí pokud můžou.
Nebo je to kvůli šetření energie na příští den kdy se očekává malá výroba?
.
. 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.
. Možná jsme prostě moc daleko od průměru a nemá smysl na nás Proteus optimalizovat.
