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%.
Zdravím,
také jsme narazil aktuálně na ten problém s ESS#1 - Low SOC versus Proteus na Victronu. Na ráno Proteus naplánuje prodej z baterie, jde dolu až na např. nastavených 20%, pak Victron nahodí ESS#1 a začne hned baterii nabíjet na cca 22-23%, hlavně ze sítě (a to vetšinou zrovna za draho). A někdy pak i od další hodiny pře-plánuje znova vybíjení do 20% a jede to znova…
Podle me mne by opravdu by dobré, kdyby na Proteovi:
buď byly dvě nastavení Min SOC, jedno “soft” pro plánování a druhé “hard” to co opravdu nastaví na Victronu. (S omezením že první musí být stejné nebo vyšší než druhé.)
nebo jen jedno, ale aby Proteus na to nastavení na Victronu nesahal a nechal ho na uživateli. (Nyní to je tak, že když změním ručně Min SOC na Victronu, tak mi ho Proteuse vzápětí přepíše)
Kdyby to šlo, nastavil bych si např. plánování jen do min 20%, ale na Victronu nechal min 15%, a pak by se to - obykle - mělo chovat správně.
Pro DG, prosím, toto by byla snadná oprava…
Nelze to takto vyřešit - Proteus, jakmile detekuje stav baterky nižší než mSoC, tak naplánuje okamžitě nabíjení - tzn kdykoliv by to spadlo pod ten “soft” limit, ihned by se to snažil vracet zpět.
Upřímně tuhle Victron funkci moc nechápu, ostatní střídače nic takového nemají a evidentně tim nijak netrpí
Každopádně máme na to vyzkoušený “hack”, můžete ho vyzkoušet i ručně - jakmile se spustí tenhle mód na victronu (ESS#1 low soc) tak řučně změnit msoc o pět procent níže a po pár vteřinách vrátit zpět (nebo počkat až to vrátí proteus sam zpět - stane se to nejdéle za 10s) a ten mod zmizí
Takto to už máme sepsané jako implementační změnu a jakmile se k tomu dostaneme, tak to naprogramujeme.
PS: pokaždé když tohle někdo řeší, tak nás nezapomene obvinit, že to děláme pro sebe, protože vyděláme na poplatcích. Realita je, že výkupy za 450kc/MWh dotujeme, ta odchylka stojí více než ten poplatek. Stejně tak jako dotujeme provoz automatického řízení. Tyhle obvinění fakt “bolí” a přemýšlím, že kdokoliv nás takto obviní, tak začne platit reálné náklady za výkup ale i provoz automatické řízení …
Nějak nerozumím, proč by to tak nešlo vyřešit…
Když už Proteus detekuje stav nižší než mSOC, tak ať si klidně naplánuje nabíjení, to je v pořádku. Ale když by ty limity byly dva, tak by to běžně pod ten jeho vyšší nepadalo, a neměl by tedy ani důvod to dělat. A zároveň by Victron, který by měl nastaven ten nižší limit, neměl důvod dělat nabíjení kvůli ESS#1.
A nebo prostě nechat u Protea jen jeden - ale změnit, aby Proteus na ten limit na Victronu nesahal. A v Nastavení třeba přidat pro jistotu poznámku, že je to limit pro plánování, který má být stejně nebo lehce vyšší, jako je na FVE nastaveno. Ostatně, tohle nastavení není zrovna asi nic, co by se často měnilo. (Mimoichodem, upřesnění popisu by se hodilo i u Nabíjecích výkonů, aby bylo zřejmé že nic neomezují ale jsou jen pro plánování)
BTW já Vás neobviňuji naopak oceňuju někdy trpělivost vysvětlovat.
Jak dokážeme aby se baterie nevybila pod ten “soft” limit ?
No aby se baterie nevybila pod “soft” limit sice nezaručíte, ale jak si např. Proteus naplánuje pro danou hodinu vybíjení baterie s cílem třeba 20%, tak aspoň jak to pozoruju u mne tak se docela trefuje, takže běžně bych nečekal že to bude nějak často a výrazně padat pod ten “soft” limit.
Aha ale už možná rozumím, kde je ještě zrada: on přeplánovává jednou za hodinu, takže když by se to zrovna stalo, že klesne pod soft limit, tak by na to zareagoval ne hned ale až v celou hodinu.