Atributy ceny a posunutý čas

[Bojkas1985]

Ahoj, snad to nebude vadit, že píšu česky, vzhledem k tomu, že se jedná o ceny z českého OTE. :) 1.) Rád bych se zeptal, jestli čas v atributech není trochu posunutý. Dle OTE je cena za první hodinu 00:00-00:59:59 158,06 euro za MWh, což znamená 3,84 Kč/kWh, ale v atributech máš od nulté hodiny 3,65, což zase odpovídá dle OTE času 01:00-01:59:99. Přitom na samotném stavu seznoru je to korektně, tedy v tuto hodinu je dle senzoru 5,76 Kč a dle OTE také 5,76 Kč. Jde to i vidět, kde atributy končí, na 22h, namísto 23. 2.) Vím, že to může být pro některé zbytečné, ale mohla by být zajímavá volba vytvoření senzoru, který by určoval čas, kdy začíná nejnižší kumulace cen dle nastavení. Například, chci nabíjet 3h, v nastavení bych nastavil 3h a senzor by mi ukázal, že nejnižší kumulativní cena začíná dnes v 01:00:00 a končí 03:59:59.

Jinak, naprosto skvělej počin, předtím jsem používal ten od Grinca, ale tam mi vadilo, že nemá další den po vyhlášení cen a každodenní hodinový výpadek.

Díky Bojkas

[rnovacek]

1) Myslím, že časy jsou v pořádku. Ty atributy ukazují čas v UTC (pozná se to podle toho +00:00 na konci). Je to hodinový posun oproti času v Česku (2 hodiny při letním čase). Asi by se dalo použít nastavení Home Assistantu, kde je časová zóna.

2) Dobrý nápad, jen nevím jak to uchopit. Pro někoho by bylo lepší X hodinový spojitý interval, pro někoho jiného 3 samostatné hodinové intervaly.

[Bojkas1985]

1.) oki, minimálně mám teď jasno, v případné automatizaci s tím budu počítat. :) Děkuji

2.) To první si myslím, že bude užitečnější pro nás s FVE na spotu. :) Například pro nabíjení baterií. No druhý by se dalo uchopit tak, že by si vytvořil senzor, který by řadil ceny od nejnižších do atributů, takže by se z toho dalo i brát více, či méně hodin. Případně v nastavení by se určilo, kolik by se mělo vytvořit senzorů (nevím, jestli to lze).

PS: není třeba v plánu vystavení do HACS, nebo přímo do ofiko integrace? :)

[rnovacek]

Pro nabíjení baterií přece není důležitý spojitý interval. Za 3x jednu hodinu se nabije stejně jako za 3 spojité hodiny. Co přidat senzor, který by říkal kolikátá nejlevnější hodina dne to je. Např.:

0:00 - 4,5 Kč - 3 1:00 - 6 Kč - 5 2:00 - 5 Kč - 4 3:00 - 1 Kč - 1 4:00 - 10 Kč - 6 5:00 - 2 Kč - 2 ....

Pak by se pro tu nespojitou variantu daly spouštět spotřebiče když "senzor <= 3" - byly by to 3 nejlevnější hodiny. Jiný spotřebič by mohl mít "senzor > 20", který by ho vypnul při nejvyšších cenách.

Líbilo by se mi vymyslet něco podobně univerzálního i pro tu spojitou variantu.

[rnovacek]

HACS nebo ofiko by asi šlo, ale nemám s tím zkušenosti.

[Bojkas1985]

No já to samozřejmě vnímám ze svého pohledu. :) Třeba včera jsem ručně nastavoval na dnešní den akumulaci tepla do podlahy ze sítě od 00 do 4h, jelikož jsem měl prázdnou baterii. Navíc, je pro mě osobně důležitá ta spojitost u baterií, kdy často bývá nejlevnější cena blízko sebe. Střídač si dokáže na nabíjení baterie ze sítě vzít jen 5kW, nejčastěji jsem tak nabíjel v noci, abych měl baterii na celý den. Kdybych nabil baterii hodinu v 00:00 a další nejlevnější hodina by byla ve 17h, tak je reálná šance, že vybiju těch 50%, následně budu odebírat za nejvyšší cenu v průběhu dne a pak se nabije opět 50%. Mám trochu obavu, že v tom nespojitém by to mohl být problém, když nebude nižší než 3, tak se to vlastně nespustí. Pokud budu potřebovat třeba prát, musím spíš znát nejnižší hodnotu, respektive dvě po sobě jdoucí, protože se prostě ten den prát musí

Je pravda, že by to chtělo ve spojitém větší univerzálnost, co když budu chtít po půlnoci nabíjet baterie pro dům a pak večer třeba nabíjet EV.

Možná to nějak spojit třeba v nastavení. Určily by se třeba tři denní bloky, kde by se dalo nastavit počet hodin. Zkusím se ještě zamyslet.

[Jirka43]

Je spíš otázka důležitost spínání na víc hodin. U podlahového topení, EV, bojleru je to jedno a to jsou ty velké spotřebiče. U pračky, myčky atd., mě zajímá 1. levná hodina kdy mají spotřebu největší (ohřev vody) a pokud program "přeleze" do další hodiny, tak se tím už moc netrápím. Co se týká FVE tak baterie taky nabíjím po půlnoci, kdy je dlouhodobě cena nejnižší, bohužel to mám nastaveno natvrdo, nemůžu RCT nabíjení řídit HA a přes den prodávám na SPOTu.

[rnovacek]

Tak ta baterka se taky přece nemusí nabíjet v kuse. Podle mě spíš chcete 3 nejlevnější hodiny v noci, aby ráno byla baterie nabitá. To už je ale spíš na nějaký další systém nad HA, kde půjdou udělat komplexnější podmínky (NodeRed, PyScript nebo něco takového). Nevím, jestli by se dala nějaká taková podmínka udělat přímo v HA, asi dost těžko.

Něco ve smyslu vypočítej medián z "pořadí hodin podle ceny" do šesti ráno a zapni nabíjení v hodinách, kdy je to pořadí nižší než ten medián.

[rnovacek]

Já to zatím řeším ručně - napsal jsem si aplikaci, která přes HA umožňuje plánovat topení a nabíjení po čtvrt hodinách:

[Bojkas1985]

Jen pro inspiraci, kdysi mi někdo na HA Comunitě pomohl napsat (komplet napsal on :D ) template, který zobrazí první začínající hodinu ve dvouhodinovce, kdy je kumulativní cena nejnižší. Použil bych klidně toto, ale nejsem schopen to napasovat na tvůj senzor, jelikož Grinco má jednoduché hodiny. Navíc, je to pro mě dost složité a pro další možné uživatele taky. Chtělo by to "něco", co by mohl použít i úplný BFU, protože se zdá, že dost lidí přechází na spot úmyslně, kvůli tomu, že na něm ceny mohou být nižší, ale ne vyšší než 6kč kvůli stropu. Bohužel to ukazuje jen hodinu, žádné detaily jako je cena. {% set ns = namespace(attr_dict=[]) %} {%- set f = ((states.sensor.current_ote_energy_cost.attributes)|list)[0:24] %} {%- for e in f%} {%- set ns.attr_dict = ns.attr_dict + [(e, state_attr('sensor.current_ote_energy_cost', e))] %} {%- endfor %} {%- set price_map = dict(ns.attr_dict) %} {%- set price_sort = price_map.values()|list %} {%- set keys_list = price_map.keys()|list %} {%- set ns = namespace(combo=[]) %} {%- for p in keys_list %} {%- set p = p|int %} {%- if p < 24 %} {%- set ns.combo = ns.combo + [(p, ((price_sort)[p-1] + (price_sort)[p])|round(2))] %} {%- else %} {%- set ns.combo = ns.combo + [(24, ((price_sort)[23] + (price_sort)[0])|round(2))] %} {%- endif %}{%- endfor %} {%- set mapper = dict(ns.combo) %} {%- set key = mapper.keys()|list %} {%- set val = mapper.values()|list %} {%- set val_min = mapper.values()|min %} {{ key[val.index(val_min)] }} {{ state_attr('sensor.current_ote_energy_cost', 24) }}

[Jirka43]

To je na mě dost složité, snad mně syn poradí :-) Pro nabíjení EV potřebuji podle stavu baterie zjistit jen hodnotu 1. až 6. nejlevnější hodiny tu potom jen provnávat v hodinových cyklech nabíjení. Zkusíme rozpitvat ten kod pro dvouhodinovku protože tam už filtrování je.

[Bojkas1985]

@Jirka43 ale to je na senzor od Grinca, ten má nevýhodu toho, že občas na hodinu při přepočtu vypadl, je potřeba přepočítat na kačky a hlavně neumí druhý den.

[rnovacek]

@Jirka43 Tohle navržené řešení by to mělo snadno řešit. Dávalo by vám to takhle smysl?

[Jirka43]

Zkusím to tak udělat. Druhý den, mě zatím netrápí, protože na nabíjení stačí 6 hodin a na spotu 23. a 24. hodina nebývají nejlevnější. NT mám 22-6 hodin.

[Bojkas1985]

Tak zrovna dnes by se to hodilo, večer jsem nastavil dobití 50% baterie a nastavil to blbě, takže jsem do rána vstoupil s prázdnou baterkou a odběrem ze sítě za více peněz, než bylo potřeba. :D Osobně bych asi dokázal pracovat s původní myšlenkou, která jednoduše zobrazuje pořadí cen od nejlevnějšího, na to bych asi zvládl něco sesmolit. Asi nějaká podmínka ve stylu "IF následující cena po nejlevnější v první pětce THEN pokračuj". Možná by to bylo i nakonec lepší, pokud budu pracovat i s předpovědí počasí, tak si prostě nabiju část v noci a pokud bude další cena až odpoledne, tak si dobiju více. Jen by to chtělo ty atributy oddělit datem, nebo today/tomorrow, možná dát každý den na vlastní entitu dnes/zítra? Pořadí, čas, cena, den 1 23 1,2 today 2 05 1,8 today 3 22 5 today

Co myslíte pánové?

EDIT: Tady je dokumentace k tomu, jak lze publikovat do HACS https://hacs.xyz/docs/publish/start

[Bojkas1985]

@rnovacek nějaký progres? :) Případně další nápady?

[rnovacek]

Zatím žádný progress, protože jsem zatím nepřišel na žádný univerzální systém, který by pokrýval nějaké větší množství scénářů.

[joshuaaaaa]

Asi oba hledáme něco jako je toto..

https://www.creatingsmarthome.com/index.php/2022/09/17/home-assistant-nord-pool-spot-prices-and-how-to-automate-devices-for-cheapest-hours/

jinak moc děkuji rnovacek :)

[joshuaaaaa]

Jde to upravit podle .. https://github.com/custom-components/nordpool ?

[mnagovicz]

Ahoj hezky připraveno. Používal jsme Grinco, ale tohle je vychytanější. Mám jen malý trabl. Od včerejška co mám nainstalováno mi to nechce načíst graf, stále píše loading. Nevíte proč?

Atributy to načítá:

[rnovacek]

@mnagovicz to vypadá, jako by apexcharts nějak nemohlo najít data. Zkuste se podívat, jestli to neukazuje nějaké chyby v Chrome DevTools (pravé tlačítko na stránce Developer Tools -> Inspect -> přepnout na Console). Případně nareportovat do apexcharts-card https://github.com/RomRider/apexcharts-card

[mnagovicz]

@mnagovicz to vypadá, jako by apexcharts nějak nemohlo najít data. Zkuste se podívat, jestli to neukazuje nějaké chyby v Chrome DevTools (pravé tlačítko na stránce Developer Tools -> Inspect -> přepnout na Console). Případně nareportovat do apexcharts-card https://github.com/RomRider/apexcharts-card

prosim te, jsem trochu lama, kde hledat Chrome DevTools? :-)

[rnovacek]

Jak píšu - kdekoli na stránce zmáčknout pravé tlačítko myši - vybrat Developer Tools -> Inspect -> přepnout na Console. Pak ideálně znovu načíst stánku a udělat screenshot.

[rnovacek]

Aha, tak možná jen "Inspect", bez toho "Developer Tools". Alespoň tedy v Chromu. V jiných prohlížečích to může být trochu jinak.

[mnagovicz]

poznas z toho neco?

[rnovacek]

Potřebuju vidět záložku Console :)

[mnagovicz]

:-)

[rnovacek]

To už je lepší. Vidím SyntaxError z apexcharts-card.js. To bude asi ono. Zkus znovu zkopírovat ten yaml. Je to nějaký divný, říká to že je tam neočekávaný znak : a přitom tam není.

[Bojkas1985]

@mnagovicz zkus vytvořit kartu jako manuální, vymaž vše co tam je a dej tam ten kód.

[mnagovicz]

Díky moc oběma za radu, už to jede :-)

[rnovacek]

Plán na rozšíření:

1. Přidat sensor, který bude ukazovat, kolikátá hodina dle pořadí právě je. Tak, aby se případná automatizace dala udělat přes sensor <= 3 - bude běžet 3 nejlevnější hodiny za den (nesouvisle).
2. Pro souvislý běh by možná šlo přidat "konfiguraci", kde by se vybralo, jak dlouhý souvislý úsek bude, a podle toho by se vytvořil nový binární senzor (on pro souvislý úsek X hodin, jinak off, skutečné hodiny začátku a konce úseku by mohli být v atributech senzoru, aby se daly zobrazit v UI). Takto by mohlo jít přidat i více senzorů.

Nemám na to v poslední době moc času, tak nevím, kdy se k tomu dostanu. Tak mezitím prosím dejte nějakou zpětnou vazbu, zda by to takhle bylo využitelné

[Bojkas1985]

@rnovacek Snad nevadí, že ti tykám, je to zvyk. :⁠-⁠) 1.) Asi úplně nerozumím. Tedy když nastavím senzor <=3, tak se spustí dle pořadí? Tedy bude 24 hodnot seřazených dle cen Pořadí/začátek/cena 01/10:00/2 Kč 02/15:00/3 Kč 03/23:00/4 Kč V tomto případě bude podmínka true v 10, 15 a 23h, chápu to správně? Bude tam i to, o který den se jedná? Aby tam nebylo třeba 48h, kdy první dvě ceny budou dnes ve 01h a 02h a třetí pak vyjde na zítra ve 23h.

2.) Asi by bylo dobré, aby těch senzorů mohlo být více. Osobně si svou automatizaci představuju tak, že bude fungovat na základě více faktorů. Třeba, pokud mám v baterii méně než 15%, tak nastav nabíjení co nejdříve na 2h. Pokud je v baterii více než 50%, stačí mi hodina.

Asi první část by pomohla v tuto chvíli nejvíc a bude pravděpodobně "nejjednodušší", ne?

PS: poslední hodinu nejede senzor, ale předpokládám, že je to chyba OTE, který taky nefunguje. Jak často se to aktualizuje, mám pocit, že to ráno normálně jelo, takže až pozdější nefunkčnost serveru to celé rozbila.

[Vojcekjeborec]

Zdravím, já mám vyřešené nabíjení elektromobilu pro čas 22:00 až 6:00. Nabíjení je spuštěno podle toho kolik hodin je potřeba nabíjet a pak se vybírají nejlevnější hodiny. kdyby někdo měl zájem, když tak sem hodím (nejedná se o spojité nabíjení). Ale chci se zeptat, jak vyřešit časový posun u těch cen pro jednotlivé hodiny. Je to oproti OTE posunuto o dvě hodiny a změna pásma nefunguje. Nemá někdo nějaké řešení? Na funkci to nemá vliv, ale oku to vadí :)

[rnovacek]

@Bojkas1985 nevadí :)

1. Jo, tak nějak. Viděl bych to, že to bude vždy v intervalu od půlnoci do půlnoci. Čili dneska tam bude pořadí aktuální hodiny v rámci dnešního dne a od půlnoci tam budou pořadí hodin na zítra. Uvažoval jsem dělat to od poledne, kdy se na OTE objeví čísla na další den, ale bylo by to asi méně intuitivní a navíc by mohl být problém s přepočítáním hodin, když by tam přibyl následující den...

PS: jo, je to kvůli nefunkčnímu webu OTE, udělal jsem na to issue #2.

[Bojkas1985]

@rnovacek to jsem rád. :⁠-⁠)

1.) Tak možná udělat 2 senzory? Dnešní a zítřejší den? To by možná bylo nejlepší, nebude se v tom člověk ztrácet a bude to jasné rozlišitelné, když se automatizace spusti večer, nebude zbytečné koukat do dnešního dne, ale na ten zítřejší.

[rnovacek]

@Vojcekjeborec myslíte ty hodiny v atributech toho senzoru? Je to v UTC. Dostat to do lokálního času by šlo nějak takhle:

{%- for dt_string, value in states.sensor.current_spot_electricity_price.attributes.items() -%}
  {% if dt_string.startswith('20') %}
    {%- set dt = dt_string | as_datetime() | as_local %}
    {{ dt }}
  {% endif %}
{%- endfor -%}

[Vojcekjeborec]

@rnovacek Děkuji, toto řešení mě nenapadlo. Snažil jsem se upravit skript, ale potom to nefungovalo. Akorát si moc nevím rady s tím, kam tuto část kódu nahrát nebo co s tím udělat. Do configuration.yaml ?

[mkh595]

Zdravím,

taky si myslím že časy v atributech jsou o hodinu posunuté. Nejnižší cena je čtvrtou a pátou hodinu dle OTE

Což je 3 a 4 UTC, ale senzor má 2 a 3 UTC, jako by bral pořád letní čas

a špatně to zobrazí i graf, kde je čas převeden do UTC+1

[rnovacek]

Já to chápu tak, že to co OTE ukazuje jako hodina 1 není v jednu hodinu, ale je to první hodina dne, čili 0:00 až 1:00

100% jistý si nejsem, jestli se někomu podaří najít nějaké vysvětlení (ideálně nějaká dokumentace na stránkách OTE), tak to opravím.

[mkh595]

Máš pravdu, je to číslo hodiny.

https://www.ote-cr.cz/cs/dokumentace/dokumentace-elektrina/files_dokumentace/uzivatelsky_manual_webove_sluzby_ote.pdf

[mkh595]

Zítřejší rozdíl mezi maximem a minimem přímo vybízí ráno nabít, večer prodat zpět.

[Bojkas1985]

@rnovacek ahoj, chápeš to správně, na OTE znamená "1" 00:00-01:00, u tebe "1" znamená od 01:00. Je to jen o stavu mysli, vím jak to je, podle toho s tím pracuju. Momentálně mi přijde logičtější tvá verze. :)

[jirimissbach]

HACS nebo ofiko by asi šlo, ale nemám s tím zkušenosti.

Já to pomocí HACS nainstaloval. Stačí přidat https://github.com/rnovacek/homeassistant_cz_energy_spot_prices jako custom repository. Jediné co chybí je nějaký extra popisek (info.md) a pak nějaké další parametry případně (hacs.json) https://hacs.xyz/docs/publish/start

Jinak výborná práce. CO se týče definice levných hodin, určitě by se hodily obě možnosti

• Entita která je on v případě že probíhá levná hadina (X definovaných hodin uživatelem) - ideální pro nabíjení domácí baterie s podmínkou SoC
• Entita která je on v případě že je detekováno X spojitých hodin jako nejlevnější spojité pásmo - ideální pro nabíjení BEV

[jirimissbach]

@mkh595 Těch 5 entit jsou udělané pomocí template nad state_attr? Podobné jsem chtěl zrovna o víkendu udělat až jsem zjistil že nevím jak používat statistics ve spojení se state attributes. Nechci to tady @rnovacek plevelit, ale můžete mě prosím nakopnout/nasdílet example? Díky

[rnovacek]

Mám v plánu tyhle věci (min a max, s časem jako atribut) v příští verzi přidat. Taky bych chtěl přidat možnost mít ty atributy v lokální časové zóně místo UTC. Pak senzor na nejlevnější hodiny a nejlevnější spojitý úsek. Další věc, kterou bych rád, je možnost upravit cenu, zvlášť pro prodej a zvlášť pro nákup - aby se dalo připočíst DPH a třeba poplatky za distribuci.

Plánů hodně, ale času málo. Bohužel nemůžu slíbit, kdy se mi s tím podaří nějak více pohnout.

[mkh595]

template:
  - sensor:
    - name: "spot_price"
      state: >
        {{ this.attributes.diff | default(0) }}
      unit_of_measurement: Kč/kWh
      attributes:
        data: >
          {% set ns = namespace(minPrice = states('sensor.current_spot_electricity_price') | round(2), 
                                minTime  = states('sensor.date_time_iso') | as_datetime() | as_local,
                                maxPrice = states('sensor.current_spot_electricity_price') | round(2), 
                                maxTime  = states('sensor.date_time_iso') | as_datetime() | as_local,
                                diff     = 0,
                                now      = states('sensor.date_time_iso') | as_datetime() | as_local)%}
          {%- set ns.now = ns.now.replace(minute=00) %}
          {%- for dt_string, value in states.sensor.current_spot_electricity_price.attributes.items() -%}
            {% if dt_string.startswith('20') %}
              {%- set dt = dt_string | as_datetime() | as_local %}
              {% if dt > ns.now %}
                {% if value < ns.minPrice %}
                  {%- set ns.minPrice = value | round(2) %}
                  {%- set ns.minTime = dt %}
                {%- endif -%}
                {% if value > ns.maxPrice %}
                  {%- set ns.maxPrice = value | round(2) %}
                  {%- set ns.maxTime = dt %}
                {%- endif -%}
              {%- endif -%}
            {%- endif -%}
          {%- endfor -%}
          {% if ns.minTime < ns.maxTime %}
            {% set ns.diff = (ns.maxPrice - ns.minPrice) | round(2) %}
          {%- endif -%}
          {% set ns.minTime = ns.minTime.strftime('%d.%m.%Y %-H:%M') %}
          {% set ns.maxTime = ns.maxTime.strftime('%d.%m.%Y %-H:%M') %}
          {% set ns.now = "" %}
          {% set dict = (ns|string).split("<Namespace ")[1].split(">")[0] %}
          {% set dict = dict.replace("'","\"") %}
          {{ dict }} 
        price_max: > 
          {% set dict = state_attr("sensor.spot_price","data") -%}
          {{ dict.maxPrice | round(2) }}
        price_min: >
          {% set dict = state_attr("sensor.spot_price","data") -%}
          {{ dict.minPrice | round(2) }}
        time_min: >
          {% set dict = state_attr("sensor.spot_price","data") -%}
          {{ dict.minTime }}
        time_max: > 
          {% set dict = state_attr("sensor.spot_price","data") -%}
          {{ dict.maxTime }}
        diff: > 
          {% set dict = state_attr("sensor.spot_price","data") -%}
          {{ dict.diff | round(2) }}

[Vojcekjeborec]

@mkh595 Já to řešil přes trigger, bo jsem si říkal, že sensor běží pořád, což asi není úplně potřeba. Ale asi je to jedno. Tady mám např. entitu, kolikrát je max cena vyšší než min. Akorát jsem použil teda jinej senzor.

template:

• trigger:
  • platform: time at: "00:10" sensor:
  • name: "price_diff_x" state: > {% set attri = ((states.sensor.current_ote_energy_cost.attributes)|list)[0:24] %} {% set value = namespace(field=[]) %} {% set count = 0 |int %} {%- for count in attri -%} {% set value.field = value.field + [state_attr('sensor.current_ote_energy_cost', count)] %} {% set count = count + 1 |int %} {%- endfor %} {% set sort_value = value.field |sort %} {% set min_value = sort_value[0] %} {% set max_value = sort_value[23] %} {% set value_diff = max_value/min_value %} {% set value_diff = value_diff |round(1) %} {{ value_diff }}x

[Bojkas1985]

@rnovacek si se do toho pustil s vervou. :-) Kdy budeme moct testovat?

[rnovacek]

Hned jak budu mít trochu času to otestoval lokálně, snad přes víkend.

[mkh595]

Zajímalo by mě, zda je to chyba v datech OTE nebo je to spávná cena. Protože automatika to vyhodnotí jako nejnižší cenu a spustí nabíjení.

[Bojkas1985]

Na OTE to je taky, tak doufám že to nebude chyba u nich protože na to mám postavené nabíjení.