Díky za update. Určitě využijeme.
Mám dotaz: prosím o info, zda ty upravené hodnoty predikcí spotřeby se nějak propisují do budoucího algoritmu nebo s tím nepočítá. Pořád čekám na něco, co mi z modelu vyignoruje nabíjení EV. Bohužel tím mám pokažený celou predikci spotřeby, jelikož vyzobávám spoty a neodráží to reálnou spotřebu domácnosti. Pokud bych si tu predikci předem upravoval a Proteus nebral tu zvýšenou spotřebu do budoucna v potaz, tak časem bych EV asi z modelu dostal. Díky za odpověď.
mě by se taky líbilo možnost zadat predikce spotřeby na všechny dny dopředu. Takhle to musím každý den naklikávat pořád dokola. A nefunguje to dobře na mobilu (android)
Dobrý den, Danieli. V tuto chvíli se algoritmus ještě stále učí na základě reality, ale máme v plánu jeho zdokonalení tak, aby se učil na základě vašich úprav predikcí. Pavla, Delta Green
Honzo, dobrý den. Když říkáte “na všechny dny dopředu”, kolik těch dnů máte na mysli? 
Pavla, Delta Green
můj dům potřebuje 15 kWh za den, všechno ostatní je odložitelná flexibilní spotřeba a vytěžování přebytků. Takže přes den spotřeba cca 1 kW/h a v noci 0,4 kW/h.
Přemýšlel jsem že kdyby se integrovala Tesla tak by šlo spotřebu odečíst, ale já mám plno dalších spotřebičů na přebytky, teď třeba topím elektrickou troubou, když je hezky.
Mám to taky tak nějak - spotřeba je cca 15kWh za den, zbytek je už vytěžovačka řízená HA (bojler, akumulační nádrž, přímotopy v koupelnách). Dokonce i pračku už jsem naučil ženu pouštět jen ve slunné dny. 
Nicméně zadávat na každý den dopředu po hodinách predikci spotřeby je dost pracné. Spíš by bylo lepší mít to avizované API pro flexibilitu do HA (MQTT), které by mohlo fungovat i na tohle, tzn. by se do Protea dostala informace, že běží tyto vytěžovače a v jakém příkonu a nemusel by je započítávat do predikce spotřeby domu.
mě se zdá že DeltGreen bude delegovat tyto integrace na Infigy, protože na to nemají čas, možná že je integrace ČEPS složitější než odhadovali?
Nebudu zakládat nové téma, ale všiml jsem si že v tužtičce v editaci čísel (cílové nabití baterie) je obyčejný input. Kdyby to byl input typu number tak v telefonu se nabídne číslová klávesnice a editace bude jednoduší. Díky.
@Anna dobrý postřeh, takže FYI 
Když jsme u toho učícího algoritmu:
Jeden den je špička FVE v 11:00 a já zapnu ohřev vody a další spotřebiče.
Další den je špička FVE ve 14:00 a já zapnu zase nějaké spotřebiče v tu dobu.
Je z toho učící algoritmus nějak moudrý?
“učící” je silné slovo
Funguje to jako průměr posledních 5ti týdnů dané hodiny daného dne.
Tzn. předpověď spotřeby pro pondělí 14:00 až 15:00 je průměr spotřeby za tuto hodinu (14:00 až 15:00) za pět pondělí zpět.
Ano, je to jednoduchý klouzavý průměr - ale vězte, že jsme na tom strávili hodně času a aplikovali i ML s různými vylepšeními (ensemble) a zatím nic neporazilo ten klouzavý průměr - ani ChatGPT/Gemini ne
Nápad:
Zkoušeli jste nějaké zapomínání (vážení v čase)? Tzn. hodnota z posledního týdne má největší váhu a hodnota pět týdnů stará má nejmenší váhu v tom klouzavém průměru? Rychleji by se adaptovalo na změnu chování/zimu/léto…
Omlouvám se, mám za sebou první týden, takže ještě možná nevím co všechno to umí: Bylo by tam nějaké zaškrtávátko, jako že tento den nepoužít v učení (protože je tam extrémní nestandardní spotřeba).
ono tam to vážení nějaké myslím je, teď si nejsem jistý, měnili jsme to tolikrát, že už trošku nevím, jaká verze je ta aktuální.
Obecně tohle prostě nefunguje dobře u kohokoliv kdo má EV a nabíjí v různé časy a v různé dny v týdnu (což tak nějak používání EV vyžaduje :)) stejně tak když má někdo automatizace co mu sepínají spotřebu v závislosti na výrobě atd.
Upřímně, nemá to ideální řešení - API na úpravu spotřeby bude umět integrovat a správně zasílat desítky našich zákazníků? My ale potřebujeme řešení pro desetitisíce lidí, pro “průměrného uživatele s FVE”.
Cílíme k tomu, že jakmile ovládáme i EV, tak už máme pod kontrolou “většinu” flexibilního výkonu a tedy ta chyba predikcí už bude mnohem menší. Samozřejmě pokud má někdo doma např. saunu, tak ta flexibilní není a tu prostě nikdy netrefíme, pokud ten člověk nechodí do sauny pořád stejně v daný den a hodinu
Tohle je optimalizace, na které se dají strávit měsíce, utratit desítky milionů a získat desetiny max jednotky procent přesnosti a to ještě navíc “na portfoliu” ale ne na jednotlivcích (u někoho nějaká změna funguje lépe, ale u někoho ta samá změna funguje mnohem hůře).
Po EV to pak doplníme ještě o nějaké módy typu “dovolená” ale největší přesnost bude vždy a pouze, když to člověk vyplní ručně skrze “tužtičku” když ví že chce jít do sauny večer například.
Určitě za režim dovolená bych se moc přimlouval. Nebo obecně, člověk by si mohl ukládat nějaké templaty a pojmenovat, které aplikuje na konkrétní kalendářní dny.
Já třeba bych si uložil template 700W od 8 do 17 hodiny, zbytek 200W a až pojedu na dovolenou, tak to tam plácnu na X dní dopředu. A když jsou dva dny před mým návratem domů dobré ceny na spotu, zapnu na dálku teplou vodu, ale to nemění nic na tom, že můj template platí až do konce mé dovolené
Já chápu, že predikce spotřeby při nabíjení EV vpodstatě nejde jinak, než že vám to klient oznámí. Za mě ale vidím velký problém v predikci spotřeby pokud mám TČ, jehož spotřeba je závislá na venkovní teplotě. Tam jsou průměry v topné sezóně, jakkoliv vážené, prakticky vždycky mimo místu 
Presně…
To už mi taky vrtalo hlavou
i kdybychom udělal api na predikce, jak k nám tyhle predikce dostanete na 24h dopředu aby to sedělo? Jde mi o to TČ konkrétně
No, na hrubý odhad, ono to spíš bude nějaká jednoduchá funkce celkové tepelné ztráty domu, COP a venkovní teploty zprůměrovaná za jeden nebo dva dny.
To by si Proteus mohl počítat sám, ale já vím, další funkcionalita…
Tohle spočítat asi není složité, ale získat ty data od průměrného uživatele je ten problém 
Ale zamyslíme se
Návrh:
Do nastavení dáte zaškrtávátko Topná sezona, které si uživatel zaškrtne na podzim a odškrtne na jaře.
Do pokročilého nastavení dáte
no a pak ten vzorec na požadavek tepla je nějak lineárně rozdíl venkovní a pokojové teploty krát ztráta budovy
a z toho nějaký vzorrec na COP je tuším nějaký logaritmus či co …
sorry, je to tak nějak narychlo vysypané , snad to dává smysl