Dobrý den @jan.hicl
uvažovali jste o možnosti vypnutí vybíjeni baterie do sítě? Nechtěl bych zbytečně cyklovat baterii když nemusím. Nejde mi primárně o zisk z přebytku. Ty umím využít automaticky pro klimatizaci nebo ohřev tuv.
Druhá část se týká EV. Uvažuji wallbox k FVE Victronu a chci se zeptat jestli můžete rozepsat co v tomto plánujete. Rozhoduji se jaky wallbox a je tedy nejlepší jit do Victronu? I s ohledem, ze výhledově plánujete je ovládat? Díky moc za odpověď.
Nepracuji pro DeltaGreen, tak mě neberte jako oficiální zdroj.
Podle dat které zatím mám se ukazuje, že cyklovat LFP baterii můžete bez omezení, protože vydrží nesmyslný počet cyklů, pokud ji máte ve správné teplotě vydrží 30 let denního cyklování.
Já mám wallboxy victron a jsem s nimi spokojený, i když jsem si musel napsat zimní nabíjení ze sítě podle spotových cen sám v HomeAssistent https://youtu.be/egUPr2L4hvg
Zdravím Honzo,
díky vaše videa sleduji 
mě nejde ani o cyklování, jako spíš si nechávat v baterce rezervu, kdyz budu spotřebovávat více než naplánuje systém. Jako včera, kdy jsem měl nabitou plnou baterii, v 18h začal vybijet do sítě z baterky na 61%. No a do rána jsem měl 20%. Ráno začíná slunce pozvolna a kdyz si uděláme snídani, tak musí brát zbytečně ze sítě protože minSoC je dosažené. Přitom jsem tam mel v baterce dost, kdyby ji nevybil.
Dnes je podobny slunecni den s drahou 18h, ale dnes prekvapive nic neprodava a rano v 6h v planu mam 45%.
Algoritmus bere v potaz predikce spotreby a vyroby… Bohuzel predikovat spotrebu domacnosti je slozite a obsahuje to nejakou nepresnost. Pak se muze stat situace, kterou jste popsal a to, ze “nezbyde” rano na snidani, protoze algoritmus pocital s tim, ze bude spotreba nizsi. Zaroven je ale mozne, ze cena elektriny byla i s distribuci levnejsi nez cena z baterie. Nebo si algoritmus spocital, ze je vynosnejsi spotrebovat elektrinu ze site (i kdyz je drazsi nez amortizace baterie), protoze na ni “prodela” mene, nez vecer vydelal na prodeji. Chtelo by to videt vase konkretni data… Zkousel jsem dohledat podle data tady na foru, ale nejsem si uplne jisty spravym dekodovanim 
Mimochodem, posouvani vyroby v case timhle stylem (ulozim do baterie a pak dodam do site) velmi vyrazne zvysuje zisky z FVE. U moji FVE to za zari bylo o cca 300kc z celkoveho uctu 1000kc. Do budoucna budou tyhle situace cim dal tim castejsi a financne zajimavejsi…
Co se tyka wallboxu, tak aktualne pracujeme na integraci OCPP, coz je standartizovany protokol pro komunikaci s wallboxem. Nepodporuji ho vsechny wallboxy, ale je jich celkem dost a najdete je zde: https://openchargealliance.org/participants/
Wallbox Victronu je za nas take v poradniku, ale zatim jsme na nej neslyseli zadnou chvalu a tak jsme v tom nijak zasedne nepokrocili. Chvalu jsem slysel na go-e a to hlavne z pohledu integrovatelnosti do domacich automatizaci. Ale na to, ze to je defacto chytry meric spotreby, tak mi to prijde celkem draha sranda Osobne mam tesla wallbox a ten integrovat ani nejde - chytrost je na strane auta, ktere jde hezky povelovat, takze to resime mimo wallbox.
S tím vybíjením baterie na 20% ráno mám také zkušenost, jak jsem popsal v tomto vlákně WafeRider / Proteus - zkušenosti, na což mi bohužel nikdo neodpověděl. Jak píšu, tak bych osobně v nastavení WaveRidera hodnotu Minimální nabití (%) raději chápal, jako minimální stav baterie, pod který nemá algoritmus vybíjet, ale nepoužívat tuto hodnotu pro nastavování SOC limitu na Victronu. Nebo v nastavení udělat tyto hodnoty dvě s daným významem, protože já v tom rozdíl vidím.
@MikeTe tam je bohužel problém v tom, že nelze snadno toto dokázat - jen skrze Scheduled charging, to pak ale rozbije zase jiné věci. Proto používáme mSoC, ale rozumím, že v tom vidíte rozdíl.
Každopádně pokud nechci, aby se něco takového dělo, jsou dvě možnosti - nastavit ohromnou cenu amortizace a pak se reálně vybíjení do sítě nikdy nestane a nebo v Nastavaní zakázat přetoky úplně.
Taky mě výše uvedená problematika štve. Ráno vybité na min. SOC, (ESS #1), je 8 hod. ráno, ceny vysoké, slunce nic moc. Tepelko začíná 3,5 kW ohřívat vodu v bojleru (bojler nemá spirálu) spotřeba sice za dobu ohřevu cc 0,6 kWh, ale za cenu např. 3 kč. Fakt by to nějak nešlo řešit?
ESS#1 je nadřazené jakémukoliv řízení. Bohužel toto se dělo na victronech vždycky - jakmile v noci padne nabití baterky na mSoC, tak victron čeká na první paprsky a ihned s prvním výkonem na solárech to spadne do ESS#1 modu a je to tam do doby, než se zvedne SoC o 3% - řeší se to na victron forum už několik let ale Victron vypadá, že to nehodlá řešit
A omezit ovládání v Proteovi, aby nikdy neklesl pod min.SOC +3% ??? Reaguji i na Vaši odpověď kolegovi MikeTe viz výše.
Jediná možnost jak dokázat, aby byla baterie nad mSoC je skrze Plánované nabití (Scheduled Charging) - to je to co jsem psal že rozbije zase fungování jiných věcí (testovali jsme) a tudíž to není řešení. Jiné další řešení bohužel nevidíme - hlavně cokoliv dáme dohromady bude jen “workaround” ale ne řešení příčiny a to je nelogická implementace jak funguje ESS#1 na straně FW přímo od Victronu
Smutné je, že oni si v rámci DESS udělali ještě novou proměnnou, kde je možné nastavit jaké nabití se má brát jako nejnižší pro fungování algoritmu, dle mého přesně z tohoto důvodu, aby jim to nepadalo do ESS#1, bohužel toto nastaveni není ale možno nastavit skrze MQTT - jen skrze jejich rozhraní ručně
Nemohl by tohle dělat Proteus? Tedy mít nastavené dva SOC limity - jeden skutečný pro střídač a jeden pro plánování. Tím by vznikl i dodatečný prostor pro odběr z baterie když se netrefí predikce (což je problém, na který jsem při zkoušení Protea narazil já).
Mohl - ale není to 100% - pokud se “netrefí” hodně, tak i tak dojde k vybití na limit mSoC. Každopádně mělo by to snížit počet výskytů, kdy se tato situace stane.
Problém je v tom, že Proteus když vidí, že je SoC pod mSoC, tak naplánuje nabíjení - tzn. pokaždé kdyby došlo k tomu, že SoC bude pod tímto limitem mSoC pro plánování, tak by ihned začal nabíjet zpět.
Snažíme se vymyslet jak toto udělat, abychom na tom nestrávili tolika času/práce - přeci jen je to problém spíše na straně firmwaru od Victronu a tím pádem je to za nás čas, který jsme mohli věnovat jiným věcem jako třeba smart charging elektroaut nebo připojení tepelných čerpadel 
Já se reálně víceméně nedostávám do popisované situace (ESS#1), akorát mi přišlo, že dva limity by mohly řešit i můj problém. Víc jsem to rozepsal v samostatném vlákně:
Jak píšu výše, tak výše uvedené chování Protea mi prostě nevyhovovalo a proto jsem si to prostě vyladil automatizacema nějak v HA a Protea nyní nepoužívám. Mě třeba vždy vybíjelo baterii pod mSOC noční zavlažování, protože délku zavlažování mi zase OpenSprinkler počítá podle počasí, takže nelze přesně říct, zda to spotřebuje 1 nebo 2 kW. Výpočty i odhad spotřeby jsem si v HA nakonec vyřešil celkem přesně, ale stejně to někdy spadlo pod mSOC (20%). Vyřešil jsem to tedy tak, že mám v HA automatizaci, která se vykoná případně v nočních hodinách, pokud se SOC blíží hodnotě mSOC, ale předpověď říká, že hned od svítání začne svítí slunce a zisky budou dostatečné. V tomto případě automatizace sníží mSOC na 15%, což zaručí, že Victron nespadne do módu Low SOC a reálně se s SOC nakonec stejně dostanu na max. 19-20%, takže baterie nijak neždímu do minima.
Já si taky pořád myslím, že v Proteovi by pořád mohli být ty limity 2. Jeden je mSOC z Victronu, ale pro výpočty vybíjení a hranice spotřeby se bude používat vždy třeba mSOC + 3%.