Nedostatek v algoritmu nebo žádoucí stav?

Všiml jsem si dnes (a vlastně možná u několikrát zpětně), že v případě záporných cen algoritmus se nikdy nesnaží nakupovat ze sítě do baterie. Nerozumím proč. Myslel jsem, že je to díky záporné ceně moc blízko nule atím pádem nevyjde celková cena včetně distribučních poplatků, ale zítra na Štědrý den v 16:00 bude cena -0.42. Což je docela dost. A systém celý den chce držet baterku na minimu. Tzn pojede ze sítě bez ohledu na cenu, spotřebu, cokoliv.

Podle mě je to špatně a mám cukání přepnout na DESS, abych se podíval na jeho plán. Protože tenhle zápor mi přijde docela zajímavý.
Je to záměr? Pokud ano, tak proč? A pokud ne, není to chyba například ignorací znaménka v rámci expression?

Díky

Nevyplatí se to kvůli amortizaci baterky - rozdíl mezi nejnižší a nejvyšší cenou ve dni musí být větší (po započtení distribuce a dph) než cena za amortizaci baterie - to se v žádném bodě neděje a proto je ekonomicky nejvýhodnější jen používat elektřinu ze sítě a baterii vůbec nepoužívat.

Ještě doplnim že zobrazená cena je bez našeho poplatku 0.35Kč/kWh - ten sám o sobě z toho udělá -0.07, distribuce to pak otočí kolem nuly do plusu a dph to ještě zvýší - rozdíl pak mezi touto cenou a nejvyšší cenou ve dni není vyšší než amortizace baterie (můžete si ji ale v nastavení změnit na co chcete, klidně na nulu).

Kdyby tedy WR nabijel, jen by prodražil cenu elektřiny o amortizaci a to by nakonec bylo dražší než ji používat přímo ze sítě s ohledem na dnešní ceny.

Až budou publikovány ceny na OTE pro 25.12. (Dnes kolem 13:00) a pokud tyto ceny budou výše, ještě může dojít ke změně plánu (ten se počítá každou hodinu) a baterie se nabije v těch 16:00 aby si tuto energii přenesl ba pondělní ráno, pokud tam budou ceny vyšší i po započtení amortizace.

Ok děkuji. Nějak mi nedošlo, že viditelné ceny jsou nákupní ceny spot, jelikož DESS uvádí už upravené.
Pak tomu rozumím. Mám tedy možná nějaký tip/tipy na možná vylepšení:

  1. bylo by hezké kromě standardní spot ceny vidět ceny skutečnou nákupní včetně vašich poplatků a distribuce - dás se asi udělat vzorec ala DESS (kde jsem dle odhadu roční spotřeby a výroby rozpočítával měsíční ceny na kWh)
  2. přišlo by mě zajímavé pracovat s korekcí predikce spotřeby/výroby. Podobný typ jsem psal i Dirkovi na DESS. Myslím to jako takovou cross-day dynamickou váhu nabíjení baterie. Podle mého v případě, že se dlouho drží baterie na minimu a současně se nepotkává predikce výroby/spotřeby s realitou, dle mého by se měla postupěm času zvyšovat výhodnot nabití baterie.
    Reálně se zvyšuje šance, že cena z nízké hladiny se pohne výše, kdy bude baterie vybitá a dojde tak k vyšším nákladům. jelikož jsou ceny známy jen den dopředu, právě tato váha by se snažila tento stav kompenzovat - je asi jedno, jetli je implementace klasická či s dopomocí nějakého machine learningu.
    Představa tedy je:
    baterie na minimu, jede se ze sítě, jak jste psal díky amortizaci se baterie nenabíjí. Každou hodinu se ale o nějakou hodnotu sníží koeficient ceny amortizace baterie. V určitém bodě při stávajícíc hladině cen bude výhodnější začít nabíjet baterii. Pokud se cena zvýší, koeficient se pomalu vrací zpět na 1.
    Samozřejmě jsou tam věci na odzkoušení - jaká je strmost křivky změn koeficientu, v případě začátku nabíjení baterie, co je pro danou hodinu cílové SOC, při jaké diferenci predikce/reálné situace, zda jako parametr používat i aktuální SOC atd. Ale jde mi o myšlenku.
    Ano, v určitých momentech vlastně je absolutní aktuální cena nabíjení baterie vyšší než nákup ze sítě, která ale bude s velkou pravděpodobností kompenzována při nejbližším pohybu ceny vzhůru
  1. pracujeme na tom - chceme to udělat pro uživatele co nejjednodušší a tedy automaticky načítat časy spínání HDO, tedy vysoký a nízký tarif. Bohužel ale získat tyto časy pro všechny naše zákazníky od konkrétních distributorů není nic jednoduchého (tak aby to bylo automatizované) a proto to možná dopadne nutností uživatele tyto časy zadávat ručně na nějaké období dopředu. Jakmile tyto vyřešíme, tak začneme zobrazovat ceny včetně distribuce, našeho poplatku a DPH a pak to chování WR bude jasně viditelné (samotné nás to občas mate, protože DPH je procento a tudíž roste s cenou a to člověk “nevidí jen pohledem na DT cenu”)

  2. dává smysl tam zanést degradaci baterky tím, že se nenabíjí - zamyslíme se, jak to tam nejlépe dostat včetně vašeho návrhu. Už jsme to několikrát řešili, jen to zatím nemělo implementační prioritu.

Také bych uvítal kdyby Proteus v plánu zobrazoval hodinové ceny s vaším poplatkem a DPH. Případně ať si to může každý nastavit ve své konfiguraci podle sebe. Díky za vaši skvělou práci.

1 Like