Proč se večer vybíjí baterie do sítě za 2,65 Kč, aby se ráno kupovalo za 4,55 a 4,43 Kč?

rozumím - máte pravdu, i tohle je problém - ale ten zase zmizí ve chvíli, kdy to EV řídíme my. Ale ano, zůstane to pro věci které neřídíme, ale které reagují na přetoky.

Obecně to má dvě cesty řešení:

  • naše predikce spotřeby “nachytřit” o to, aby se snažili reflektovat i to, že jsou tam spotřebiče, které jsou “závislé” na predikci výroby - tzn. že se pouští jen když hodně svítí atd.
  • umožnit uživatelům tyto spotřeby “vyřadit” z toho, aby se počítali do predikcí

druhá možnost je pro nás hračka implementovat, ale ohromný “vopruz” pro uživatele to zadávat - ano, ti co umí alespoň trošku programovat nebo automatizovat, tak to vyřeší, ale my musíme hledat řešení pro všechny.

První možnost je pak ideální pro všechny, ale extrémně složitá (nákladná) na naší straně + pravděpodobnost, že to bude 100% správně je prakticky nulová . . .

Tzn. pokusíme se udělat nějak kombinaci obojího - jen je potřeba to pořádně promyslet a otestovat

2 Likes

Zdravím,

chápu, že tu neexistuje triviální řešení pro všechny uživatele a pro všechny typy invertorů a scénářů spotřeb. Jako “low hanging fruit” ale vidím např. Solax invertor + Solax EVC - z EVC lze číst jeho režim i spotřebu. A v režimu Green je tahle masivní (= objemem hodně ovlivňující) spotřeba snadno identifikovatelná jako “závislá na přetocích” a počasí, atd. Pro začátek by bylo super mít tuto spotřebu “vyjmutou” ze spotřeby domu, nebo aspoň barevně označenou.
btw, je velká škoda, že tohle neukazuje ani ofiko Solax aplikace.

/PL

1 Like

Zdravím,
přimluvil bych se, že pokud je pro vás hračka dát pokročilejším uživatelům nějakou možnost to nějak automatizovat, tak prosím dejte. Myslím, že nás je to celkem dost, co máme HA a umíme nějaké ty automatizace.
Děkuji.

Dnes jsem zaznamenal opět jednu podivnost, ve 12 hodin bylo v plánu nabíjení baterie ze sítě, ze slunka šlo tou dobou skoro 3kW, ale jak to začalo nabíjet ze sítě, tak to úplně shodilo výrobu z panelů. Je hezké, že se učíte vypínat výrobu z panelů, ale to dává smysl jen při výrazné záporné nákupní ceně a ne když je cena 2,76 Kč. Musel jsem opravit plán na danou hodinu a pak hned výroba z panelů zase naskočila - viz. graf.

Jojo, tohle máme v plánu s integraci solax wallbox, což už bude snad brzy

1 Like

Bohužel jsme výrobu nevypnuli - je to pořád ten samý problém s victrony - ten co mají v known issues už několik let :confused: upřímně mi došly nápady jak tenhle jejich problém řešit takže nejspíše vyhodíme victrony z poskytování flexibility úplně když jsou nabité baterie …

Tak my tam to pravidlo máme, ze kdyz už je nabito tak se nevybere ten stridac do down flexibility, děláme to ale podle soc baterky a u vas bohuzel soc dela toto

Neni možné aby baterie takhle rychle poskočila nahoru a dolu - značí to její velký problém s balancováním článku (resp velké rozbalancování)

Sorry, ale ve 12 hodin, kdy ten problém nastal jsem měl baterii na 50%. Ty skoky na 95% bohužel Victron dělá, když nemá komunikaci s baterií, což teď moc nemám, protože mám servisní baterii, než mi opraví moji.

No, ten problém zůstává pořád stejný.

Vaše bms hlásila max nabíjecí proud 0A díky tomu skoku. To způsobí omezení výroby FVE (když jsou vypnuté přetoky)

Pokud byla baterka reálně na 50%, pak bych očekával info od BMS, ze se muze nabijet, to se ale nestalo - byla tam nula :confused:

Pořád si nějak nerozumíme - první “skok” jak říkáte byly někdy ve 12:48. Ale já mluvím a i v grafu to je zakroužkované o tom vypnutí výroby, které nastalo ve 12:00. A to byl z BMS nabíjecí proud na 140 A, takže tím to nebylo. Byl nastavený nesmyslně vysoký GridSetPoint, takže bral všechno ze sítě a PV se utlumilo.

Vliv vysoko nastaveného gridsetpointu jsem osobně testoval několik hodin na několika různých Victron instalací - liší se to podle AC/DC couplingu

U DC couplingu to funguje tak, že když přestřelíme setpoint, veškerá FVE jde jen do baterky a consumption jde ze sítě

U AC couplingu, pokud přestřelíme setpoint, tak FVE jde jak do spotřeby, tak do nabíjení (tzn. nikdy nedojde k limitaci FVE, dojde k nesplnění hodnoty gridsetpoint) - ono je to logické - ten AC coupled inverter je na AC straně - tzn. jeho cesta “po kabelu” vede přímo do spotřeby, Victron, pokud chce tuto energii použít na nabíjení baterky, tak jí musí aktivně usměrňovat z AC na DC a tím nabíjet baterku (u DC couplingu se nabíjení děje “samo od sebe”, protože MPPT trackery jsou připojené přímo na baterku, tedy victron střídač není v cestě mezi panely a baterkou - to je také důvod, proč se v DC couplingu nedá zakázat nabíjení baterky, protože nastavení proudu nabíjení baterky platí jen pro případ, že baterku nabíjí střídač, tedy z gridu, ale nabíjeci proud v DC couplingu řídí MPPT tracker).

Nicméně, kombinace Victron-Fronius má problém v tom, že když často měníme setpoint, Victron nejdříve ultumí Froniuse prakticky na nulu a následně začně postupně zvedat výkon (froniuse) až kam může a zbytek doplní z gridu - s každou změnou setpointu se toto opakuje znovu - výsledkem je, že když se to mění moc často, tak ten nájezd froniuse od nuly je tak častý, že je prakticky téměř pořád vypnutý.

Ty nájezdy jsou vidět zde:

Změníme u vás jak konkrétně děláme charge_from_grid - aktuálně to děláme skrze gridsetpoint abychom mohli plynule regulvoat výkon nabíjení a tedy reflektovali aktuální spotřebu, výrobu atd. a dosáhli cílového SoC dle plánu přesně na konci dané hodiny, zpět na scheduled charging, který jede vždy na maximum a tedy cílové procento dosáhne mnohem rychleji, což má nežádoucí efekt v tom, že pak nabíjení může jít více ze sítě než je potřeba

Co tím myslím - na příkladu

Pokud v první půl hodině bude zataženo, tak scheduled charging jede primárně ze sítě a nabije baterku max výkonem na cílové procenta např. za prvních 30 minut. Pokud ale v druhé půlhodině odejde mrak a FVE začne více vyrábět, tak baterka se mohla dostat na to cílové SoC z půlky i energii z FVE - v rámci řízeného nabíjení skrze gridsetpoint se tedy baterka nejdříve nabijí nižším výkonem z gridu a v druhou polovinu hodiny pak primárně z FVE (protože kalkulace gridsetpointu vychází i z aktuální výroby FVE)

to že se ten fronius chová tak jak popisuji v reakci na změnu gridsetpoint můžete snadno ověřit - zakažte Proteu ovládat vaší FVE a následně, když svítí slunce, změňte gridsepoint - třeba na +500W, a vždy fronius spadne na nulu a začne najíždět znovu zpět - když to následně upravíte třeba na +1000W, tak se to bude opakovat

Zkusil jsem, ale chová se to úplně jinak - k žádnému utlumení z panelů nedošlo i když jsem dal GridSetPoint na 5000, žádný skok na nulu u Froniuse. Zřejmě používáte ještě něco jiného, proč se to tak utlumovalo včera - nevím.

musí u toho být vypnuté přetoky - AC feed in disabled (protože pak musi Victron balancovat AC stranu - s povolenými pretoky není toto potřeba, může si “téct” jak chce)

Tady je kompletní log toho co jsme u vás v ten čas dělali

  1. je scheduled charging, který používáme pro “šetřit energii v baterii” - tento plán tam byl od 11:00 do 12:00

  2. toto jsou všechny příkazy, které jsme poslali v rámci “nabíjej ze sítě” - jde tedy jen o SetPoint, nic jiného nepoužíváme

  3. v 13:06 jsme detekovali, že tam někdo/něco z třetí strany nastavilo setpoint na 50W, tak to proteus začistil zpět na 0W. Následně od 13:13 pokračuje dále automatické řízení “nabíjení ze sítě” ale díky tomu, že už bylo SoC baterky na targetu, tak posílá Proteus nulu.

Nic jiného, než toto na obrázku, jsme tam neposlali (co není vidět, protože se to stalo mnohem dříve, je vypnutí přetoků skrze AC/DC feed in).

Ta výkonová regulace mezi Victron a Froniusem, když jsou vypnuté přetoky, je problematická - kolega Jan Hicl má stejný setup jako je ten váš a vysledovali jsme to u něj už dávno, otestovali a sepsali a potvrdili skrze stejně pospané problémy na victron forum - problém je, že neexistuje ideální řešení - jen hacky - buďto nabíjí moc rychle, ale nesnižuje výrobu panelů (scheduled charging) a nebo se děje toto, skrze acsetpoint - vydali jsme se cestou setpointu, páč si myslíme, že to dělá menší problém, ale máme tu úkol, založený mnou už několik měsíců zpět, že musíme umožnit na žádost resp stížnost, to přepnout zpět na scheduled charging pro ty, kteří si toho všimli :slight_smile:

EDIT: schoval jsem v obrázku část, kde je vidět ID střídače - sice to bez hesla nelze zneužít, ale i tak je více OK to nezobrazovat