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é

[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í.

[Bojkas1985]

@rnovacek měl si čas to otestovat? :⁠-⁠) Láká mě to prostě aktualizovat a otestovat ze své strany.
Edit: tak jsem si nemohl pomoc a musel jsem aktualizovat. 🙃
1.) Pokud dám nastavit počet kumulativních hodin, případné dodatečné náklady v nastavení, nezůstane uloženo, nic se nestane.
2.)
a) Senzor current_spot_electricity_hour_order krásně ukazuje pořadí nejlevnějších hodin, nešel by přidat i další na zítřejší den? Ten senzor s hodinovými atributy.
b) Případně tam dodat třeba i cenu jako parametr?
c) co znamena ta barevná linka hour order?

[rnovacek]

1.) Počet kumulativních hodin a dodatečné náklady ještě nefungují, zatím jsem ty senzory zakomentoval.

2a.) Myslíš udělat ještě jeden senzor, který by to ukazoval pro zítřek? Co by měl za aktuální hodnotu? Možná by šlo přidat zítřek jako další hodinové atributy, ale pak nevím, jak to počítat. Další interval 1-24? To by znamenalo, že buď jedna nebo dvě hodnoty budou mít pořadí 1 - nejlevnější dnes a nejlevnější zítra (jen když už máme data pro zítřek).
2b.) Jak si to představuješ? Do atributů? Nebude už tam toho moc?
2c.) Nevím, co tím myslíš. Byl by screenshot?

[Bojkas1985]

1.) Ach tak, oki. :⁠-⁠)

2a) a musí tam být aktuální hodnota? Nemůže tam být hodnota nejlevnější? Osobně bych to určitě nemíchal dohromady, pak by to bylo opravdu matoucí. Určitě by byl vhodnější vlastní senzor s atributy jako je to u tohoto, jen na druhý den.
2b) teď je tam datum a druhý pak pořadí, tak bych to udělal jako datum, cena a pořadí?
2c) posílám

[rnovacek]

2a) Senzor jsem přidat, hodnota je Unknown dokud nepřijdu na to, co tam dát lepšího. Kolikátá hodina dne je nejlevnější mi přijde neintuitivní, když ten senzor pro dnešek tam má pořadí aktuální hodiny
2b) Přidal jsem i cenu, jen nevím, jestli tam toho teď není moc
2c) Hodnota toho senzoru je pořadí aktuální hodiny podle ceny. A jelikož je to bezrozměrná veličina, tak tam HA ukazuje tenhle graf pro diskrétní hodnoty (aspoň si to myslím).

[Bojkas1985]

2a) super. Uvidím až ve 13h. :⁠-⁠) Možná tam dát stav, jestli už ty ceny jsou na druhý den načtené? Pak by se mohla dát automatizace něco ve stylu, if loaded then ...
2b) máš pravdu, je tam celkem přetlak s tou cenou. Jinak, myslel jsem, že to pořadí by bylo na konci. Proč to nemá vlastní sloupec, ale je to oddělené čárkou? Nešlo by ty sloupce i pojmenovat? :⁠-⁠)
2c) ach tak! Dobrý vědět, užitečný stav.

[rnovacek]

2a) Dobrý nápad! To by šlo.
2b) Problém je, že ty atributy nejde nijak formátovat. Je to vlastně slovník v Pythonu, čili dvojice "klíč-hodnota" a hodnota musí být něco, co se dá převést do JSONu. To co tam je teď je seznam [cena, pořadí]. Můžu ty dvě věci přehodit, ale nic moc lepšího asi nevymyslím.

[janhicl]

Ahoj, všem! Bohužel jsem objevil vaší integraci na HA až teď :( Podle toho, jak na to koukám, tak @rnovacek udělal kus skvělé práce a bohužel jí trošku v Nano green duplikujeme. Zároveň ale máme více času se do pustit, tak možná dává smysl nějak spojit síly. Máme ceny spotu jak dle market ceny, tak ceny pro spotřebu i výrobu očištěné o marži obchodníka, máme bool senzory na nejlevnějších X hodin. Budeme přidávat i nejlevnější spojité hodiny, nejlevnější v peak a off-peak hodinách. Díky tomu, že počítání distribuce je náš denní chleba, tak budeme přidávat i to. Rádi pomůžeme posunout integraci a rádi se inspirujeme s tím, co může pomoci... Naše první verze integrace zatím zde

@rnovacek nějaký nápad, jak bychom mohli pomoci? Chápu, že chcete být nezávislí na dodavateli, ale určitě není problém mezi sebou něco sdílet...

[rnovacek]

@janhicl Pěkná práce. Jsem mimochodem váš zákazník :)

Pojďme na tu diskuzi udělat novou issue: #3

[mkh595]

@rnovacek V souborech je složka test a test_hass. Jak se dá spustit a debugovat tento kód?

Třeba 'pip3 install -U homeassistant' uvedený ve skriptu run-hass.sh nějak neskončí

[rnovacek]

U mě pip3 install -U homeassistant normálně proběhne. Zkusil bych pip3 uninstall homeassistant a pak pip3 install -U homeassistant. Máte to v nějakém virtual environment?

[jirimissbach]

výborná integrace, čekám na PPP ale už si připravuji automatizace na ovládání GoodWe a nabíjení aut přes smart wallbox. Tenhle thread už je poměrně dlouhý, nechtělo by to udělat separátní issue na jednotlivé= feature requests aby se v tom @rnovacek vyznal?

Líbí se mi idea počtu kumulovaných X hodin, to bude fungivat pro auto dobře. Co tak ale přidat nějaké dalši funkce jako například

median - is the current hour price below the median?
price quartile - display quartile number based on the hour price (0 - 4)

A případně přidat cenu za distribuci kterou by bylo možné měnit podle tarifu (např externí entita která by obsahovala cenu za distribuci která se mění podle šasu/sazby)

[rnovacek]

Ano prosím, udělejme separátní issues pro každý požadavek. Tady to zavřu a prosím vytvořte nové issues (ideálně pro každou součást) ať to můžeme prodiskutovat.