Možnost změny operací v plánu řízení je super. Díky tomu ale, že Proteus ne úplně dobře plánuje noční spotřebu (vždy ji plánuje nižší než je skutečnost), tak každý večer upravuji večerní procento vybíjení a zamknu noční operace na normální provoz až do rána. Ráno mu už nechávám naplánovanou automatickou operaci, což je nyní většinou Prodej do sítě místo nabíjení. Všimnul jsem si ale, že se tato operace ale nechová tak, jak bych předpokládál a to, že pouze přesmeruje zisky ze slunce. Pokud mi totiž ráno zůstane v dané hodině nějak procento nad min. SOC 20 %, tak i tato operace se pak snaží vybíjet o něco více a dosáhnout to cílové nabití (vybíjí tedy o něco více, než je výroba ze slunce mínus spotřeba). To plánované cílové nabití baterie nelze ale v této operaci manuálně změnit. Chci se tedy zeptat, zda by šlo doplnit změnu cílového nabití, anebo upravit chování režimu Prodej do sítě místo nabíjení tak, aby nedocházelo ke snižování procenta nabití baterie (cíl by měl by stejné procento nabití, jako bylo na začátku hodiny).
Ten prodej místo nabíjení má čistě jen posílat FVE do sítě, pokud se vybíjí baterie, je někde problém - kdy k tomu přesně došlo, ať to nemusím hledat v datech?
Díky
Myslím, že to bylo toho 20.6. a je to vidět i ve statistikách. Není tam nikde historie těch nastavených režimů, ale myslím, že 6-7h byl manuálně nastaven ještě normální režim a 7-8h byl už nastaven ten režim Prodej do sítě místo nabíjení (ale u téhle hodiny si nejsem jistý, jestli to bylo manuálně nebo Proteem). V plánu řízení pak měl Proteus vypočítáno nějaké hypotetické cílové SOC 20 %. Ve skutečnosti bylo na začátku v 7h SOC 25 %, ale to se snížilo do konce hodiny v 8h až na těch 20 %. Ve statistikách je pak vidět, že dodávka do sítě je každou minutu větší než výroba + spotřeba a že to Proteus částečně tahá i z baterie. Možná, jestli není nějaký problém s tím, že ten plán byl večer nastaven manuálně a až do té hodiny 7-8h byl předtím ten plán zamknutý.
Hmmm, problém je jinde.
Při tom modu prodej místo nabíjení děláme to, že ve smyčce měníme setpoint tak, aby vše co jde do baterie šlo místo toho do gridu - protože se ale mění poloha slunce, mraky, ale i spotřeba, je potřeba to dělat cyklicky a stále to upravovat podle aktuálních hodnot.
U vás ale máme tento problém:
konkrétně pak jde hlavně o tu fialovou čáru, která má být ideálně nula, protože jde o součet energie “produkované vs spotřebované”:
a bohužel jsou tam ohromné rozdíly, například v tento konkrétní bod:
To vlastně říká, že:
z gridu šlo 1.83, z PV 3.16, z baterie šlo 3.75 = celkem tedy 8,74kW výkon “výroby”
spotřeba ale byla jen 1.78kW a tedy rozdíl 6,96kW - energie která jde “nikam”. To je samozřejmě špatně a je to vetšinou způsobeno nesynchronním zasíláním dat z vaší FVE způsobené někde po cestě od vás do VRM cloudu a nebo z VRM cloudu k nám - děje se to u pár zákazníků, jste bohužel jeden z nich - pro přestavu, takto to vypadá u mě např.
není to u mě nula, ale sedí to mnohem více než u vás
budeme z tohoto důvodu předělávat victrony z VRM cloudu na DeltaLink, protože VRM má mnoho problému jako tento a naše řízení tím pak trpí - jako třeba v tomhle případě u vás, protože Proteus pak vlastně vůbec neví, jak přesně ta bilance výroby/spotřeby vypadá a kolika má posílat ven, aby se vše prodávalo a nenabíjelo
Díky za odpověď a vysvětlení. Barák je připojen přes WiFi. I když ten internet je rychlý a nemívám žádné výpadky ani pří sledování videa, tak je možné že pro upload těch dat do VRM to bude možná slabší a už to tak ideální nebude.
upřímně si myslím, že je problém na straně VRM - ty data tam častokrát prostě nejsou správně - máme implementováno mnoho filtrů, které hlídají kraviny - ne zřídka se stane, že VRM hlásí, že něčí FVE vyrábí v řádech MW - vždy jen na pár vteřin a pak to zase zmizí.
Bohužel v tom co jako DG děláme je přes 95% práce neviditelné v podobě toho, že “hot fixujeme” problémy třetí strany 
je to extrémně nákladné a bere nám to čas abychom se mohli věnovat těm věcem, které jsou vidět a mají hodnotu pro zákazníka (tohle má samozřejmě taky, protože bez toho to nebude fungovat správně, jen je prostě “šílený”, že abychom mohli vůbec neco vytvořit, musíme dát nejdříve měsíce práce do debuggingu a black box testování SW/FW třetích stran)