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.
spotřebu počítáme jako průměr posledních několika týdnů dané hodiny a daného dne - tzn “nepočítá se spotřebou” prostě není validní argument, pokud se ta spotřeba děje každé ráno pravidelně, tak tam v té predikci prostě je.
na tom celém mě nejvíce vadí, že se snažíme ohejbat Protea, což stojí enormní peníze skrze programátory, na neefektivitě, kterou dělá Victron. Četl jsem mnoho diskuzí na victron forum, kde si na to lidi stěžují, že tohle low soc chování je nesmysl a victron to ignoruje.
kvůli victronům máme v kodu už hrozně moc vyjímek, hacků a mnoho dalšího, reálně tyhle hacky stály v nákladech statisíce spíše miliony korun a stále to nekončí - já díky tomu, že mám victron, tak sám chodím s návrhy jak to řešit, ale celý dev tým je už na to alergický (nedívím se jim) protože už roky říkají, že to nemá konce. Bohužel už se začínám přiklánět na jejich stranu 
Dáme tam ten hack ne snižování msoc a vracení zpět, ale prostě tohle je problém victronu, vždycky byl a vždycky bude a nejde na tohle do nekonečna házet peníze
Já bych to chápal tak, že - kromě vyřešení toho ess1 problému - by rozdíl mezi soft a hard mSOC to byl v podstatě takový buffer ( polštář) pro všechny situace, kdy se SOC pohybuje kolem minima (nemusí být jen ráno) a odhad spotřeby se netrefil přesně.
Já vidím problém v tom, že Proteus plánuje hodně argesivně a když se predikce spotřeby netrefí, tak už není z čeho brát. U mě to v posledních dnes bylo typicky to, že večer vybije baterku tak, že má v plánu ráno být na msoc. Když pak v následujícíh dvanácti hodinách (dejme tomu) bude spotřeba vyšší, než byl plán, tak se bude zbytečně brát ze sítě. Tohle vůbec není specifické Victron a ESS#1. Kdyby místo toho večer nechal nějakou rezervu v plánu (a případně to naplánoval prodat ráno, když už bude jasné jak noc dopadla), tak se problému vyhne.
Je jasné, že to dělá kvůli maximalizaci zisku za prodej, ale mnohdy to nakonec místo toho skončí nakupováním v ranní špičce.
Já bych se rád ještě jednou zeptal na tu možnost vyřešit to snadno tím, že by mSOC limit byl stále jen jeden, ale Proteus by prostě nesahal na nastavení mSOC na straně FVE. Pak by to bylo jen na uživateli, zda si je nechá stejně, nebo si tam nechá rezervu. A na straně Protea by se hádám nemuselo měnit skoro nic, nebyl by to ani hack. Je tam něco co by tomuto řešení bránilo ?
Znovu, pokud je spotřeba domácnost v noci např 1kwh za hodinu a noc trvá dejme tomu 8 hodin a člověk má 10kwh baterku, znamenalo by to (při 20% msoc) že na ní proteus komplentě přestane sahat aby byla před nocí vždy 100% nabitá a dokázala pokrýt těch 8 hodin
Je to neefektivní úprava, která možná bude fungovat pro vás, protože tu baterku máte větší než spotřebu, ale nebude fungovat pro všechny - ozvou se ti, kteří mají situaci viz předchozí odstavec, proč proteus raději neprodal v noční špičce za 6.5kč a nebral zpět v noci za 5kč - což je výhodnější, než že to držel na noc nabité, aby se to pak postupně vybilo.
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.
1 Like
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!!
3 Likes
Příspěvek od Prokopa zde to hezky ilustruje, proč to Proteus večer vybíjí Přesnost predikce x editace plánu řízení - #8 od Prokop
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.