Chci se zeptat, jak vyřešit nebo zda již někdo řešil řízení FVE na spotu s Proteus pokud je v systému vytěžování přetoků do ohřevu teplé vody pomoci vytěžovače (v mém případě GBO Aku). To co Proteus “vidí” jako přetok nemusí být pravda a v případě, že chce například prodávat, tak se může stát, že vše nebo část skončí v teplé vodě. Navíc ani nemůže s touto spotřebou nějak počítat při plánování. GBO i střídač mám připojený do Home Assistanta, mohu GBO automatizací přepnout do stavu ON, OFF nebo Vytěžování. Ale jak zjistit kdy to udělat a jak donutit Proteus aby s tímto vším počítal? Má to řešení?
toto je velký problém který obecně vedeme pod názvem “Wattrouter” 
bohužel dokud tyhle krabičky jen bezhlavě tlačí přetoky do loadu zařízení k ním připojených, tak to nemá řešení - navic to monitorujeme a když nám nesedí data ze střídače oproti datům z elektroměru distribuce, tak tyhle domácnosti pak odpojujeme i z flexiblity - protože jim platíme za elektřinu co měla být doručena do sítě, ale reálně skončila v jejich bojleru.
Ten problém je trochu složitější - ono nevadí že je tam nějaká spotřeba - například to, že v rámci UP flexibility někdo zapnul i další spotřebu, to je ok, vadí, pokud to zapínání spotřeby navíc sedí přesně s našimi příkazy - což bohužel přesně tyhle krabičky ze své podstaty dělají.
Brzy nabídneme API kde budou informace z Protea co aktuálně dělá (jak flexiblita, tak řízení na spotu) a při posílání energie z baterie do sítě bude potřeba si toto api připojit “nějak” k této krabičce aby se blokovalo její chování, jinak jak popisuji, dojde k vyřezení z poskytování flexibility 
1 Like
Dobře, děkuji. Je mi jasné, že z pohledu využívání flexibility je to problém. V případě, že bych flexibilitu zatím nepoužíval, jaký bude mít “wattrouter” dopad na plánování Protea? Jak píšete, to že existuje nějaká spotřeba mimo střídač, tj. nesedí data ze střídače se skutečností od distributora, monitorujete. Upravujete nějak na základě tohoto rozdílu algoritmus řízení FVE? Pokud by existovalo API o kterém píšete, bylo by jednoduché v případě flexibility, případně při plánovaném prodeji do sítě vypnout ohřev bojleru resp. vynutit ohřev ze sítě. V řádu kolika týdnů/měsíců by mohlo být API k dispozici? Existují nějaká doporučení kdy bojler ohřívat s ohledem na plán Protea? Děkuji.
To slibujete více než rok
Proteus nemá šanci o té spotřebě krabičky vědět, takže se chová, jako kdyby tam nebyla a tedy plánuje prodeje do sítě za účelem výdělku za prodej, ale ten se neděje, protože to skončí např. v tom bojleru.
nejrychlejší řešení je tuto krabičku přestat používat
jinak je potřeba tu krabičku blokovat při jakémkoliv commandu, který se snaží vybíjet baterii do gridu - což je:
Flexibilita UP
prodej místo nabíjení
prodej z baterie do sítě
zákazníků, kteří jsou schopni využít API, je minimum. Bavíme se max o stovkách, spíše desítkách.
Produkt ale stavíme pro stovky tisíc zákazníků - z toho bohužel vychází priorita pro vytvoření takové API - velice nizká (jinými slovy: stojí to mnoho úsilí/peněz na naší straně toto udělat, ale využití (návratnost i v podobě spokojení zákazníků) bude minimální). Proto to trvá a ještě bude - ale chceme to udělat v rámci API pro připojení zařízení, které neplánujeme integrovat, ale necháme třetí strany je integrovat.
S tím API se bavíme o pár měsících nebo spíš rok a víc? Končí mi fixace na “Elektřina pro soláry” u ČEZ, již nějakou dobu mám zapojený DeltaLink a nyní zvažuji využít Vaše služby a Proteus. Samozřejmě alternativou je vše řídit sám na spotu pomoci automatizací HA, ale do toho se mi moc nechce. Proto se smažím zjistit co mohu očekávat od Protea do budoucnosti. Ohřev vody a vytěžování jen z přetoků, zvlášť v kritických měsících jara a podzimu je pro mě důležité a je to podstatná část spotřeby. Proto to nemohu jen tak odpojit. Hledám tedy možnosti jak využít Proteus ale i výhodný ohřev vody. Myslím, že podobný požadavek musí mít mnoho Vašich klientů - nabíjeni elektroauta nebo ohřev vody v bazénu a podobné spotřeby.
najde na githubu kod, co vytvořil jeden z našich zákazníků, kde si bere ty proteus commandy přímo z rohraní protea - tedy udělal to API “za nás” - tak do té doby jde použít to
Ale samozřejmě používá naše API mezi backendem a frontendem, které často měníme, takže se mu to bude rozbíjet, tak je potřeba s tím počítat.
Naše oficiální API nedokážu říci, ideální sledovat - je to konkrétně ta jediná položka v připravujeme https://roadmap.deltagreen.cz/tabs/5-pripravujeme
Já mám 200 L bojler na 3F 4kW, ohřev vody mě jednou deně spotřebuje něco mezi 6-10kWh, 2-2,5h je na 72C. Jaký je problém nastavit aby se každý den sepnul když bude baterie na 90% a vypnul když SOC klesne na 80%? Mám 28,6 kWh kapacitu baterie. Proč jen přetoky? Teď mám výrobu 7200 W, bojler a spotřeba domu při ohřevu bojleru dělá dohromady 4800W, 2500W jde ještě do baterie. Když budu čekat napřetoky, tak pak bych posílal do sítě teď za aktuální spot 0,52 Kč, proč?
Až se ohřeje bojler, zapne se klimatizace, pračka, mička.
Můžu posílat do sítě jen 8kW. Baterie tedy zvládnou 8+5kW, když Proseus bude chtít flexibilitu…
Ps.: myslím si že je účinější (levnější) ohřát bojler rychle za 2h, než za 6-8h pomalu z přetoků 1-2kW
1 Like
O API bych určitě měl zájem. Nejlépe i s nějakou notifikací v případě flexibility. Abych právě v době, kdy je zájem o elektřinu vypnul bojler a nabíjení auta a naopak při záporné ceně elektřiny zapnul vše co je možné. Mám celou domácnost “chytrou”, ale chybí mi napojení na Delta green.
Nešlo by vzít jednu verzi tohoto API, dodělat k němu OAuth2 autentizaci a zveřejnit k němu popis? Nemuselo by to být tolik práce a myslím, že by to hodně pomohlo - dala by se tím upravovat konfigurace (mě trápí predikce spotřeby v zimě, protože klouzavý průměr za pět týdnů nebere v potaz spotřebu TČ závislou na venkovní teplotě). Byl by základ, do kterého se dají dodělat další funkce - třeba signalizace povelů flexibility.
bohužel ta odpověď je taková “byrokratická” - dělat to jen pro nadšence jako vy má malý dopad (nízký počet konzumentů této služby), tzn. s ohledem na to, co všechno chceme udělat má toto nízkou prioritu - ale protože i tak to chceme nabídnout, přilepili jsme to k API pro výrobce zařízení, které neintegrujeme napřímo my, ale aby jej mohli integrovat oni (první kdo toho API používá je infigy). K tomu ale potřebujete plnou podporu toho API ale hlavně dokumentaci - proto to trvá
Hele, někde jste psali, že ta implementace API je docela jednoduchá, ale na druhou stranu se o tom bavíme už skoro rok. Chápu, že to není pro každého, ale co tu tak čtu, tak mi přijde, že skoro každej má HA. Každopádně si myslím, že nějaká forma API pro flexibilitu, aby se daly jednoduše integrovat další spotřebiče když je povel DOWN a také, abych ty velké spotřebiče mohl vypnout, když je povel UP by se přece hodilo. Zároveň s tím, by bylo vhodné integrovat řízení, nebo jen oznámení chodu těchto velkých spotřebičů. které by pak Proteus nebral v potaz při predikci spotřeby a to by ji velmi výrazně zpřesnilo. To je přece v zájmu všech ne?
skrze scan lokální sítě vidíme že tam je nebo není HA a reálně ho vidíme u méně jak 10% - a to je naše zákaznická báze hodně “tech” oproti průměrnému zákazníkovi s FVE.
Tzn. určitě to není funkce pro masy a i kdyby to byla práce na den, nedostalo by se to skrze náš systém prioritizování (který má velkou váhu pro výpočet priority s ohledem na počet zákazníků, kterých se daná featura týká).
K té integraci dalších spotřebičů - takto jak to píšete to nikdy nebude. Aby se dala flexibilita odměňovat, musíme tu energii na tom zařízení měřit. Tzn. pokud by se například někdo rozhodl nabízet myčku (cíleně říkám extrém), musel by nejdříve k ní přidělat realtime měření energie například skrze shelly zásuvku, ze které to pak můžeme vyčítat. Tím se nám to celé začíná dost zesložiťovať - není to jen API s UP a DOWN commandy, je to API, kde se pravidelně odesílají data o měření 24/7 z daného zařízení směrem k nám, obráceným směrem pak chodí ty commandy.
Navíc se ihned stane, že někdo udělá virtuální zařízení, které bude něco posílat po celou dobu a jakmile přijde command, tak to začne posílat upravené hodnoty, aby to vypadalo, že to dělá co má, ale reálně je to jen virtuální zařízení - dostane odměny ale reálně nic nedodal - prostě nás jen podvedl, protože věříme jeho datům. Z toho důvodu musíme implementovat kontrolní mechanismy oproti měření FVE a distribučnímu měření.
A najednou je z toho projekt na týdny, spíše měsíce
Vše co píšete je samozřejme pochopitelné. Vadí mi tam jen jedna věc, výpočet dopadu na zákazníky. Trochu si možná neuvědomujete, že pokud něco takového začnete otevřeně umět, nabalí se na to jako sněhová koule spousta kutilů (v pozitivním slova smyslu), která doposud vůbec vaším zákazníkem není, takže o nich nemůžete vědět.
Já znám několik několik lidí, kteří by do DG nejspíše šly, ale jen za předpokladu, že “nebudou házeny klacky pod nohy” a bude to ekonomicky dávat smysl. Tedy přeloženo, budete v tomto otevřená platforma/firma - ano, jistě to zabere nějaký čas a tudíž prostředky, ale házet to do škatulky “není dostatečný zájem” mi nepřijde moudré. Zároveň děkuji za to, že to neházíte přes palubu úplně, jen jen to na konci seznamu a jednou k tomu snad doiterujete (a nejlépe se u toho budete bít do hlavy, proč jste to neudělali dříve :D).
Já bych strašně rád abyste uměli všechno co potřebuji já (auto, vytěžovací boiler, TČ, miner, …) a nemusel se o to nijak starat. Zároveň chápu, že priority jsou jinde. Takže mi právě proto dává extrémní smysl, se připojit na nějaké API, které mi umožní signalizovat vám mé možnosti, predikci, komandovat mě co mám a nemám dělat a já už si na své straně zařídím, jestli tou energii zrovna nabiju auto, nebo ohřeju boiler, nebo jen nabiju baterii ve FVE. A pochopil jsem, že Infigy přesně tohle dělá? Stejně tak bych předpokládal, že pokud takové komandování selže, musíte tohle obecně korigovat tím, že začnete zbytek portfolia komandovat trochu jinak. Pletu se?
ad HA, to není jediná platforma a i když ji také mám, tak zrovna z řízením energie tam nějak nepočítám. Rád bych si to udělal na své vlastní platformě (sic trochu silné slovo). Ale úplně mi bude dávat smysl, když někdo zbouchá plugin do HA, který tohle bude umět implementovat a bude jej umět používat kdekdo s širokým dopadem.
ad podvádění, jistě to vnáší komplexitu, nadruhou stranu bych očekával, že příslušné kontrolní mechanizmy musíte používat i pro stávající portfolio zákazníků. Už jen pro neúmyslně chybně zapojené měření na patě domu.
Zatím musím každé ráno chodit vypínat “prodej do sítě” za mrzkou cenu, místo toho, aby se tato přebytečná energie využila lépe.
1 Like
to povdávění je hlavní důvod, proč to API stále není.
Aktuálně čteme ty data přímo ze zařízení skrze kód, který jsme sami napsali - aby nám někdo začal podstrkovat falešná data, musel by se hodně hodně snažit - reálně by musel zjistit, co všechno z těch FVE čteme (skrze šifrované spojení) a všechny tyto endpointy (data) nasimulovat, jinak se ta komunikace rozbije - ještě by musel dokázat skrze nějakou svojí proxy, že jí budeme považovat za to reálné zařízení. Netvrdím, že je to nemožné, ale to množství práce, které by do toho muselo padnout na straně toho, kdo chce podvádět, je ohromné a velice v nepoměru s tím, co za to může pak získat.
Jakmile ale uděláme API na integraci dalších zařízení třetí stranou, situace se dost mění. To podvádění je pak velice jednoduché, protože my v rámci toho API musíme věřit datům, co nám chodí. Aktuální “stav přemýšlení” nad tím je, že to neotevřeme komukoliv, ale jen výrobcům daného zařízení oproti smlouvě mezi námi a jimi, kde budou nést finanční zodpovědnost za případné chyby.
To otevření “komukoliv” pak bude hodně limitované - bude potřeba každé takové zařízení měřit skrze podporované měření - velice pravděpodobně Shelly zásuvky atd. - tzn. když si někdo bude chtít připojit cokoliv mu dává smysl (jeho speciální wallbox nebo bojler atd.) tak to bude muset být připojené skrze podporované měření, které integrujeme my (abychom tomu mohli věřit) a následně si daný integrátor implementuje pouze UP a DOWN commandy přímo do daného zařízení za tímto měřením.
To není dobrá cesta. To efektivně znamená klacky pod mé nohy. A to podvádět opravdu nechci a nehodlám.
Vždyt pro vás je kritické měření na patě domu, a tam má ještě elektroměr distribuce. Ty data z toho přepokládám máte (sic se zpožděním). Ale na odhalení podvádění to přece bohatě stačí. Ne?
Co se děje v domě, přece není až tak podstatné, jestli tu energii spotřebuju nějak pokoutně přímo z baterek mimo měření, nebo ji výrobím nepřiznánou další FVE je přece úplně jedno? Stejně je to moje energie
Trochu laický dotaz:
Řekněme uživatel co nemá všechno chytré jako to chce yanecisco.
Co se vyúčtuje, když flexibilita dá pokyn vybíjet baterku do sítě na 10 minut (6kW) a minutu poté se mi zvedne spotřeba domu na 12kW (náhoda je blbec), takže začne tahat 6kW ze sítě?
- při současné implementaci
- při implementaci jak by to chtěl yanecisco
Nechápu, o čem to tu hovoříte - proč takové složitosti? Reálná data přece vidíte, když čtete data z FVE - vidíte co jde z/do gridu. Takže když pošlete příkaz UP nebo DOWN, tak reálně ihned uvidíte kolik kW tam teče a dá se to měřit. Na to přece nepotřebujeme Shelly zařízení nebo další nesmysly. O tom API tu píšete tuším už od loňského srpna, kolega Hicl od loňského prosince, takže už to je reálně několik měsíců.
aktuálně děláme flexibilitu tzv. “na zařízení” - tzn. nehraje roli pata domu, ale co dělá dané zařízení. V našem konkrétním případě je to baterie.
Pokud tedy pošleme UP command na baterii a ta se začne posílat do sítě, ale vy přijdete a zapnete si rychlovarnou konvici, tak za to není žádný postih - ta baterka se na příkaz vybíjí a to je to hlavní, co se hodnotí a za co dostáváte zaplaceno.
Pokud přejdeme, jak navrhujete, na měření na patě domu, tak ta zapnutá rychlovarka vám bude pokutována - tzn. pokud před aktivací je na patě domu 0W a my zavoláme UP, a následně uvidíme na patě domu např. 2000W, protože jste si zapnuli pečení, rychlovarku a k tomu ještě nabíjení auta a baterka sice jede plným výkonem ven, ale pokrývá jen spotřebu těchto zapnutých spotřebičů a ani na to nestačí, proto odběr ze stíě navíc 2kW - tak vám pošleme k zaplacení ty 2kW krát čas krát cena odchylky - což mohou být často klidně stokoruny za každou kWh “co jste šli proti”.
Proto to děláme na zařízení - všichni se zde na foru, ale i na FB vyjádřili, že nikdy nechtějí být za flexibilitu pokutování - měření na patě domu nejde dělat bez pokutování. Měření na zařízení nám umožňuje vidět přímo to zařízení a ignorovat ty spotřeby okolo.
Pokud chceme nabídnout připojení dalších zařízení a dělat vyhodnocení na zařízení (tedy bez pokut) tak to obnáší vše co píšu výše a jinak to prostě fyzicky dokázat nelze.
Pokud jste ochotni riskovat ty pokuty, za to že někdo v domácnosti zapnul něco proti nám v času commandu a být vyhodnoceni na základě paty domu, pak takové API můžeme vystavit klidně zítra - bude ale potřeba podepsat smlouvu o těch pokutách, že za ně ručíte a že to můžeme případně vymáhat.
Chápu, že se vám mohou ty věci zdát triviální, ale nejsou - dělat pak závěry “že je to přeci snadné” a tím nepřímo naznačovat, že jsme asi neschopní je něco, co nehodlám tolerovat - jsme v tom, co děláme několikanásobně více transparentní než kdokoliv jiný na trhu - častokrát platíme odměny zákazníkům ze svého, ač jsme za to nedostali zaplaceno (např. blackout) - tyto “narčení” mě pak vždy nutí přemýšlet, zda má vůbec smysl se o něco snažit, když to nakonec vždy stejně skončí “hejtem” . . .