Predikce spotřeby je čistě průměr té dané hodiny toho daného dne za posledních několik týdnů. Predikce výroby nehraje roli v predikci spotřeby
Takže to je tím, že pokud je záporná prodejní cena, tedy hodně svítí, tak v pracovní dny ohřívám TUV patronami v bojleru, takže je tam několik hodin spotřeba navíc 4,5kW, která není, pokud nejsou záporné prodejní ceny.
Je to podobný případ, jak jste zmiňovali, že nebudete nabíjení EV zahrnovat do predikce spotřeby, tak ani tato spotřeba při záporných prodejních cenách by se tam asi neměla započítávat. Až bude hotová integrace s HA, tak by se mohlo označovat , které spotřebiče se nemají započítávat do predikcí, jako nabíjení EV, ohřev TUV patronami atd…
1 Like
jo jo, tohle bude dělat problém.
Označovat spotřebu která nemá být počítána je problém - my vidíme jen celkovou spotřebu, nevíme z čeho přesně se to skládá - na to by bylo potřeba mít nějaké vlastní měření, např. skrze shelly atd což je přesně to, co chceme udělat
Tohle je u mě příčina špatných predikcí. Mám tepelné čerpadlo, takže jeho spotřeba závisí na teplotě poměrně významně a při zimním a jarním kolísání mezi kladnými a zápornými teplotami je rozdíl ve spotřebě více než dvojnásobný. Navíc mám i teplovodní kolektory, takže když svítí slunce, jako třeba teď v březnu, tak přes den čerpadlo neběží vůbec.
rozumím, ale věřte, že jsme zkoušeli různé ML modely, dokonce to zadali i “naivně” přímo do chatGPT, ať nám udělá predikci pro nějaké odběrné místo na základě historických dat a výsledek byl . . . výrazně horší, než “hloupý” klouzavý průměr.
Ve vylepšení těch predikcí se dá utratit miliony korun a vylepšení bude - marginální - proto pustíme tu úpravu predikcí, ať si to každý upraví podle svého než se snažit o zlepšování predikcí (ač teda ještě nějaké mírné zlepšení v plánu máme)
3 Likes
Odpovědí by mohla být transparentnost. Ideálně můžete třeba ukázat (předpokládaný) výsledek nastaveného plánu (lhostejno zda manuálního nebo automatického) v korunách. Něco jako ETA u navigací.
Cut-over třeba denně 14:00.
Jako baselines (nebo aspoň finální srovnání pro dané “kolo”) by mohly být vedle ukázané i výsledky režimu “normální provoz” a “full auto”.
Vedlejším efektem sice bude “soutěž” Hele, jak to manuálně uřídím líp než automat, ale to by ve finále mělo mít jen další benefity.
Ano, to jsme chtěli několikrát udělat, ale není to reálné - k tomu potřebujeme vědět, co by se na dané FVE - resp, v dané domácnosti dělo bez našeho řízení a to prostě jsou čistě odhady = bude to vždy nepřesné.
Např. pokud Proteus v noci nabije a přes den svítí ještě trošku slunce (zimní období) a i to nabije mírně baterii - jak pak zjistíme “jaká elektřina” z baterie se použila v následnou hodinu oproti spotřebě (ta nabitá Proteem nebo ta z FVE?) Když pak Pretues vybíjí do gridu, je to prodej, který by se normálně neděl atd.
Jediná cesta je simulace, tzn. vytvořit model, co se snaží hledat baseline (jak by to vypadalo bez řízení) - který nebude triviální = nemarginální objem práce a tedy i peněz, za něco, co vlastně nemá žádnou hodnotu krom “argumentace” - z toho důvodu jsme to zavrhli a raději místo toho uděláme integraci dalších zařízení 
Mnooo… Nechci zdržovat polemikou, nicméně…
Jde o víc než jen o samoúčelnou argumentaci. Já tam vidím edukaci uživatelů, verifikaci (třebas i vaší vlastní efektivity… to koneckonců nějak dělat musíte) a nakonec i marketing.
Otázku ceny energií v bateriích asi nechápu. Když natankuju do auta 10 l @ 40 Kč a 10 l @ 30Kč, tak mám v nádrži 20 l @ 35Kč. (Příklad se zimou: Extra dobíjení ze Slunce mi jen slevňuje náklad na každou kWh sedící v baterii. Ať už pak ke spotřebě nebo k prodeji.)
Změna podmínek za běhu je jasná. I proto ta analogie s navigací… Mění se doprava, objevují se uzavírky a random události, řidič někdy zastaví, jindy jede rychleji a jindy se odchýlí. To všechno vede k updatům ETA. A někdy i výběru zcela jiné trasy.
Nechtěl jsem se pouštět moc do detaílů, proto jsem to napsal tak jak jsem napsal, ale ok, více detailů
Abychom věděli, co by se dělo bez nás, tak potřebujeme “sjet” simulaci, co by se tam bez nás dělo - ok, vezmeme zpětně reálnou spotřebu každou hodinu, reálnou výrobu každou hodinu, vyjde nám z toho kolik by šlo z baterky a kolik do baterky - so far so good - a teď ten problém - jaký je aktuální procento nabití baterie? Abychom věděli, zda se to v tu danou hodinu do baterie ještě vejde nebo naopak zda je tam ještě dostatek energie na pokrytí spotřeby (delty nad výrobu)
Abychom ho zjistili, musíme znát v každý okamžik její stav nabití - jenže jak ho zjistit? My víme kolik přibude a kolik ubude každou hodinu - takto se to dá zpětně přičítat a odčítat ale kde je toho celého začátek? Mno a odpovědí je, že v čase, kdy uživatel zapnul automatizaci - tzn. museli bychom dělat simulace stavu nabití baterie - resp. počítat to paralelně s provozem automatického řízení, každou hodinu, od chvíle co byl automat spuštěň.
Samozřejmě ale nabíjení a vybíjení baterie má nějakou ztrátu - máme vysledováno že se to liší mezi značkami FVE, ale i mezi střídači dané značky - záleži na faktorech jako AC vs DC coupling - někdo používá obojí (AC a DC coupling souběžně) tzn. není reálné to počítat pro každého zvlášť, museli bychom použít nějakou konstantu/aproximaci - což nese problém, že to není přesně a tedy se to začne rozjíždět v čase - tzn. čím déle má automat zapnutý a čím déle musíme simulovat stav nabití baterie “bez řízení” tím více je to nepřesné a tedy nesmyslné.
= stojí to spousty práce a tedy peněz a výsledkem je něco, co je velice nepřesné a to tím více, čím déle běží automatizace
Ale dejte vědět, pokud máte jiný algoritmus, jak počítat ekonomiku neřízené FVE zatím co je ale reálně řízená, abychom to mohli srovnávat
Otázka prioritizace je jasná. Nezpochybňuju ani náhodou.
Jde o simulaci, může mít řadu assumptions. A předpokládat se dá i pravidelný reset /sync (zejména) míry nabití.
Upravovat lze v iteracích.
Algoritmus samozřejmě nemám. 
Ono reset začátku se dá udělat jen ve chvíli kdy víme že soc baterie by byl shodný mezi řízenou a neřízenou “realitou”. Coz jsme si původně mysleli že je noc - kdy to dojde na msoc, jenže data ukazují že to neni pravda, protože proteus často něco “schovává” v baterce na ranní spotřebu. Tím nám ten ideálně každodenní “synchronizační” bod SoC baterek pro tyto dvě reality mizí a jediný je jen při zapnutí automatizace.
Ale když kohokoliv napadne nejaké řešení, budeme jen rádi!
(Victron to treba ve VRM počítá tak ze počítá jen cenu za kolik nakoupil vs cena za kolik prodal - tedy počítá jen mod nákupu a prodeje. To ale samozřejmě neni kompletní, protože ten finanční výpočet za mody, kdy to blokuje vybíjení nebo nabíjení - což hraje velkou roli - tam úplně chybí. Je to ale složité, tak tam dali alespoň tohle, můj názor ale je, źe hodnota jejich výpočtu je prakticky nulová 