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%.
1 Like
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…
2 Likes
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.
Ale jinak ten 5ti-procentní hack za mne ok, když to tam dáte budu spokojen
Souhlasím s tím, jak ten soft limit navrhuje kolega. Vždyť ten soft limit by byl pouze pro plánování. Čili pokud by plánování neodpovídalo skutečnosti a aktuální SOC pokleslo pod soft limit, tak se technicky nic dít nebude, akorát se musí FVE přepnout do normálního stavu (tedy žádné přetoky a prodeje do sítě).
Souhlasím s Pakem / Pakou? 
Ono totiž ESS#1 není ten primární problém! Tam by to ani nemělo dojít. Popíšu 3 problémy, které platí i pro jiné střídače, když Proteus naplánoval vybití baterie na mSoC třeba 20%.
Situace:
-
baterie je na mSoC, mám permanentní spotřebu 300-400W. Slunce teprve začíná dávat první W (desítky/stovky), a postupně než dosáhne výroba 300-400W, tak ji bere ze sítě za draho, protože jsem na mSoC a nemůžu si pomoct z baterky. To však není to nejhorší, ale principielně kupuju dráž než jsem večer předtím vybouchal baterku do sítě (v drtivé většině).
-
baterie je na mSoC a v domácnosti ráno začne aktivita, snídaně, vaření, koupelna atd. V kuchyni typicky spotřebiče jedou 2000W. Tj. dokud nemám na střeše 2kW tak opět kvůli nízké baterii musím brát nedostatek ze sítě za draho.
-
baterie je na mSoC a Proteus vidí nízké ceny kolem poledne a tak správně nastaví posunutí nabíjení baterie ze slunce na tyto hodiny a je v módu “Prodej do sítě místo nabíjení”. To je super, ale s baterkou jsem stále na mSoC a jakákoliv spotřeba nad mojí výrobu (bohužel nemám 10 nebo 20kWp na střeše) tak dotuju ze sítě za draho. A to v tyto dny trvá třeba i několik hodin třeba 9 nebo 10h dopoledne.
Tyto problémy jsou nezávislé na problému ESS1 chování. Proto Pako mluví o dvou SoC: mSoC pod který opravdu reálně baterka neklesne a “soft SoC limit” se kterým bude počítat Proteus.
Příklad mSoC 15%, soft SoC limit 20%. Proteus tedy pracuje s limitem 20% a když na to přijde a budu muset pokrýt vyšší spotřebu, tak bude schopen brát z baterky, protože může reálně klesnout na 15%.
Jinak kritikou bych se nenechával rozhodit. Děláte pionýrskou práci a vždy se najdou hejtři. Jediný parametr spokojenosti je, že vám přibývají klienti. BTW mému sousedovi jsem Deltu doporučil a už je u vás. To je to měřítko.
Držím palce.
2 Likes
Já jsem Pavel, i to mám jako jméno v profilu nastaveno, nevím proč to zobrazuje jen username. Ale jako pako si občas připadám
Jak čtu ten předchozí příspěvek, tak ono vlastně to, že by na to přeplánováním Proteus zareagoval až v další celou hodinu, by bylo možná i správně. Když by při poklesu po soft limit prostě jen přešel do Normálního režimu, a případné nabití zpět na soft mSOC řešil až příštím přeplánováním.
Ten problém je v tom ze i kdyz Proteus bude pracovat s limitem “kdekoliv nad reálným msoc” tak jakmile k němu dojede, tak to přepne do “normálního režimu” což je režim “bez řízení” a tedy vaše spotřeba v noci bude normálně pokračovat z baterie a ráno jsme přesně u toho samého problému
Ten ess low soc se pouští u victronu každé ráno ať tam neco řídíme nebo ne - jakmile je baterka na msoc a začne jen trošku svítit tak se přepne do ess low SoC aby vynutil ze veškerý FVE výkon půjde do baterky dokud neni 3% nad msoc a tedy veškerá spotřeba jde ze sítě. To se děje nezávisle na nás. Tzn. ten soft limit to neřeší, k vybití dojde pod něj tak nebo tak a následně se ráno zapne ess low soc.
Jediné funkční řešení jsme našli ze na pár vteřin snížíme msoc, to ho donutí vyskočit z ess low soc a pak to vrátíme zpět a on zůstane mimo (vrátí se tam pokud je spotřeba vyšší než výroba, ale pak to uděláme znovu a takhle pořád dokola dokud nezačne být výroba vyšší než spotřeba a už se na mSoC nedostane)
Pokud Proteus bude počítat v plánování s hodnotou “soft SoC limit” jak tomu říkáme tady, tj. 20% už předem, tak by k tomu podle mě nedošlo. Ráno by plus minus na 20% baterie byly podle přesnosti planovani a měl by tam rezervu 5% do mSoC. K aktivaci ESS1 by tedy došlo až když bych vyplácal ten buffer a to už by nenastávalo často (a třeba i se použil ten váš “hack”.
Jinými slovy Protea řídit tak, aby k ránu měl požadovaný buffer v baterce (třeba vždy těch 5% nebo i 10%) a večer by baterku nevybouchal tolik a něco si nechal.
Ale nejsem expert na Victron ani nevím jak přesně to řízení funguje. Jen popisuji problém, kterému čelím a inklinuji k vypánání automatickému řízení. Pak se zas připravuji o ty benefity odložení nabíjení, či auto zákaz přetoků při nízkýych cenách.
1 Like
Souhlasím s Danielem, který ty problémy s plánováním a řízením popsal přesně a podobně, jak já před pár dny (Přesnost predikce x editace plánu řízení - #2 od MikeTe).
Mně asi stále něco uniká
Pokud spotřeba domácnosti je přes noc taková, že ráno je baterka vybitá, tak žádný soft limit tohle neřeší - ta baterka jej projede a skončí na msoc.
To bychom museli cíleně začít ten buffer dělat tak velký aby i noční spotřeba nedostala baterku na msoc, ale to rozbije veškerou ekonomiku věci - místo toho aby třeba večer výhodně prodal a v noci jel z gridu za levnější ceny, tak tam uměle zůstane spousty kWh aby “vydržel do rána” a nespadl do ess low soc
Jak píše Daniel, tak podle mě se ten problém týká právě spíše plánování. Pokud jsou slunné dny, tak u mě se ten problém s Low SOC stává vždy ráno a ne v noci. Je to proto, že Proteus prostě plánuje vybití k východu slunce úplně na 20% (mic. SOC) a vůbec neuvažuje s ranní spotřebou, kterou nelze pokrýt ještě ze slunce. Zvlášť pokud Proteus ráno vždy hned od východu slunce naplánuje výrobu nebo prodej do sítě, takže do baterie se nic nedostane a je pořád na cca těch 20 %. Pokud se spustí ráno třeba konvice tak během chvíle to spadne do Low SOC a to jenom proto, že všechnu výrobu od východu slunce pouštěl jenom do sítě aniž by bral v potaz ranní spotřebu, kterou je potřeba pokrýt.