Forum
Řešením by mohlo být vypnout u bloku Optimalizátor spotových cen režim "Spotové ceny", přepnout jej do režimu "Absolutní" a cenu si pro každou hodinu vypočítat sám.
Jenže to by znamenalo získat si ceny pro příští den pomocí virtuálního vstupu z OTE - to lze a je to snadné.
Dále si zjistit časy nízkého a vysokého tarifu. V tom je háček. Nevím, jak ČEZ nebo PRE, ale EGD má časy v json souboru v takové struktuře, která nelze pomocí HTTP příkazu pro virtuální vstup zpracovat.
To proto, že HTTP příkaz neumí pracovat s regulárními výrazy, ale jen s výrazně jednodušším "vyhledáváním" v textu. Jenže ten json, který sem posílal @Dáda https://www.vodnici.net/community/postid/40232/
má časy v podobě "casy":{"od":"00:00:00","do":"06:00:00"},{"od":"22:00:00","do":"23:59:00"} přižemž těch prvků "od-do" tam může být libovolný počet (podle toho, kolik distributor udělá bloků s VT za den). A podle mě tohle nelze prostředky pro HTTP příkaz parsovat.
Další nápad je tedy na parsování použít blok "program", což je PicoC, ale ani to nebude úplně bez bolesti. Asi by bylo možné napsat program, který z textového vstupu vybere časy. Ale textový vstup pro blok program je omezen na 4096 znaků a asi by to celé bylo náročné na výkon a možná i zatěžovalo SD kartu.
Díval jsem se i po jiném zdroji dat od EGD, který by bylo možné zpracovat jednoduchými prostředky HTTP příkazu, ale nic kloudného jsem neobjevil. Neví někdo?
Nejjednodušší mi tedy příjde nechat si ceny včetně ceny distribuce spočítat na něčem jiném a do Loxone si pak pro jednotlivé hodiny natahat už hotový výpočet, ten napojit na blok Optimalizátor přepnutý do režimu "Absolutní" a je to.
Pokud to "něco jiného" nemáme, tak je asi nejlepší řešení používat vzorce s IF, jak je v tomto vláknu uvedeno.
Případné komentáře k výše uvedenému velmi vítány 🙂
@rpav Přesně tak 😆
Do konce roku 2024 jsem VT a NT neřešil - minimální rozdíl.
Od začátku roku 2025 už ale rozdíl mezi VT a NT je vyšší, tak jsem to zatím řešil za pomocí zanořených IF. Ale je zde pak ten problém, když pak distributor změní časy. Nutnost předělat vzoreček.
Jelikož k Loxone používám i HA. Tak jsem to zatím vyřešil v HA - zde načítám z API ČEZ časy spínání VT a NT pro můj EAN. To dělám každých 24h. Následně používám integraci Home Assistant Czech Energy Spot Prices.
A pak z toho přes automatizaci vypočtu pro každou hodinu finální cenu. Výsledek jsem si pak pro kontrolu zobrazil v Apexcharts v HA.
Funguje to spolehlivě. Poslední krok, ke kterému jsem se ještě nedostal, bude zpřístupnit API pro Loxone, a budu ceny načítat z HA. Asi přes režim: Relativní
Výhoda ještě oproti načítání SPOT přímo v Loxone je, že v HA mám ceny dřív (po 13. hodině) 😉
Nevýhoda celého řešení je pak samozřejmě závislost na dalším zařízení.
@dragot
Ano, to jsme na to úplně stejně 🙂
Taky jsem doiteroval k tomu, že k Loxonu si ještě pořídím HA, jako méně spolehlivý, méně robustní, méně konzervativní nástroj, ze kterého bude možné cucat zajímavé data do Loxonu.
Tím propojením se teprve budu zabývat (teď ještě řeším HW pro HA, aby mi to neuvařilo SD kartu), ale nebylo by od věci na to založit nové vlákno. Zatím mi jako dobrý kandidát přijde toto:
@barak-chytrak Tu dobu, kdy je NT a VT by šlo dynamicky řešit kalendářem, ne?
Pak klidně může být jiná každý den v týdnu, nejen o víkendu.
Asi by bylo nejjednodušší vzít nějakej ten blok výběru, nastavit mu na vstupu ceny za NT a VT a kalendářem přepínat, která cena je na výstupu a tím pak jen nakrmit ten blok SPOTových cen.
@johny_mnemonic Jde o situaci, kdy NT/VT je v jiné hodiny než o víkendu. Ten blok má k dispozici jenom dva dynamický vstupy. Ty by jsi pro vzoreček potřeboval, aby jsi mohl parametrizovat, který ty hodiny je nízký a který vysoký tarif (ten vzoreček, co jsem posílal tam má hardcoded hodiny: 10, 12, 14 a 17). Pokud o víkendu jsou ty hodiny, kdy je levný jiné než v týdnu, tak to tam není jak dostat.
V poslední verzi Loxone configu je opraven bug výpočtu celkové ceny elektřiny dle zadaného vzorce.
@barak-chytrak Asi už rozumím kde je problém. Myslel jsem, že ten vzoreček počítá cenu pro aktuální hodinu a proto jsem psal, že by bylo lepší na to použít kalendář. Pokud počítá cenu pro všechny hodiny celého dne, tak to s kalendářem fungovat nebude.
Pokud by počítal aktuální cenu, tak by stačil jen jeden vstup true/false (1/0), kdy ve vzorečku jen v hodinu, kdy dostane na vstupu 1 započítá hodnoty pro VT a když 0, tak pro NT.
Hodnoty distribuce pro NT/VT se mění jednou ročně, takže ty není potřeba předávat přes vstupy, ty můžou být v tom vzorečku natvrdo. Nicméně blok vzorec má čtyři vstupy, takže není problém do něj připojit jak hodnoty VT/NT, tak výstup z kalendáře a na výstupu tak mít správnou cenu pro aktuální hodinu.
Pokud ten vzorec počítá ceny pro všechny hodiny na 24h dopředu, dal by se problém víkendových časů asi vyřešit jeho větší komplexitou, kdy by porovnával nejen hodinu, ale ještě taky den v týdnu a pro 6 a 7 den by měl v sobě jiné hodiny než pro dny 1-5.
