Voit nyt itse sen Cheapest period klo 18-18 tehdä, kuten tuossa ylempänä jo oli puhetta. Sehän tässä uudessa paketissa nimenomaan oli yhtenä ideana/ominaisuutena.
HomeAssistant ja sähköpörssiohjaus
- Keskustelun aloittaja Temez
- Aloitettu
-
- Avainsanat
- homeassistant kotiautomaatio nordpool pörssisähkö
Kappas, jotenkin jättänyt sen huomioitta kun mitään kiinteää jaksoa ei ollut etsinnässä vaan vain ne yksittäiset tunnit
Edit: tuo ymmärtääkseni kuitenkin on yhtenäisen jakson feature, eli ei mahdollista hakea esim 6 halvinta tuntia klo 18-18 väliltä
Noh, nyt menty näillä säädöillä lattialämmöille ja LVV:lle on oma automaatio 18-18 jaksolle
Viimeksi muokattu:
- Keskustelun aloittaja
- #563
Kiitos -Teme- raportoinnista! Ehdin näin korjata isot ongelmat ennen kuin julkaisen tätä eteenpäin Githubissa master-haaraan.
Yritin kerrankin nyt vähän panostaa tähän, ettei turhia virheitä tulisi logille
Koetin tätä kurkata, mutta mielestäni edellisessä versiossa 0.1.11 ja tämä 0.2.0:n draftissa on tuo sliderin nimi samassa muodossa:
spotprices2ha/spot-price.yaml at main · T3m3z/spotprices2ha
Simple copy-paste approach to fetch data from api.spot-hinta.fi (see https://spot-hinta.fi) to Home Assistant. Includes simple sensors and UI elements to ease automation work. - T3m3z/spotprices2ha
github.com
spotprices2ha/spot-price.yaml at v0.2.0-draft · T3m3z/spotprices2ha
Simple copy-paste approach to fetch data from api.spot-hinta.fi (see https://spot-hinta.fi) to Home Assistant. Includes simple sensors and UI elements to ease automation work. - T3m3z/spotprices2ha
github.com
Viittaatko siis juuri tuohon kohtaa koodia, jota korjasit vai jonnekin muualle?
Olisikohan tälle "molemmat ehdot täyttyvät"-versiolle kenties jollakin muulla foorumilaisella käyttöä?
Tuollaisen scriptin kyllä tekee nopeastikin. Enemmän ehkä mietin sitä, että miten sitä scriptin palautetta oikein järkevästi käsittelisi/minne sen tallentaisi? Helperit voivat ehkä olla siihen vaikeita. Jos tähän keksisi hyvän paikan tallentaa tiedot niin, että aloittelijakin pääsee liikkeelle, niin sitten tuon voisi ympätä osaksi pakettia.
Itsellä on semmoinen systeemi tehtynä, että on triggerillä päivittyvä Template-sensor, jonka attribuutteihin lasken muiden antureiden perusteella - mm. juuri sääennusteesta ja lisäksi auringonsäteilyennusteesta - sensorin attribuutteihin talteen A) jokaisen tulevan tunnin ennustetun energiantarpeen ja B) ohjaustiedot eri lämmityslähteille. Ehkä sinulla voisi olla jotain tämmöistä omassa projektissasikin. Tai jos keksitään ne halvimpien tuntien talletus jotenkin kivaksi, niin lisätään tähän pakettiin.
- Keskustelun aloittaja
- #564
Kahvitauolla pohdiskelin tätä. Tämmöisellä saa halvimmat tunnit listana. Tätä voi kokeilla Developer Tools ->Template -valikon kautta. Tuota voinee jotenkin hyödyntää sitten automaatioissa.
Python:
{% set start = now() %}
{% set end = start + timedelta(hours=24) %}
{% set hours = 3 %}
{{ (state_attr('sensor.shf_data', 'data') |
selectattr("Timestamp", "ge", start | as_timestamp) |
selectattr("Timestamp", "lt", end | as_timestamp) |
sort(attribute="TotalPrice"))[:hours] }}Palauttaa listana esim. tässä tapauksessa 3 halvinta tuntia, joiden ei tarvitse olla peräkkäin. (Tuon voisi ehkä vielä sortata Timestampin mukaan, jos haluaa nuo vielä aikajärjestyksessä.)
Minulla ei ollut viimeistä 0.1.11 pakettia asennettuna vaan 0.1.3, johon olen GitHubista poiminut tehtyjä muutoksia ja lisännyt/muuttanut niiden perusteella asioita itselle, eli tuo on mennyt itseltä ohi. Ja kyllä, ovat 0.1.11 ja 0.2.0 paketissa yhdenmukaisestiKoetin tätä kurkata, mutta mielestäni edellisessä versiossa 0.1.11 ja tämä 0.2.0:n draftissa on tuo sliderin nimi samassa muodossa:
spotprices2ha/spot-price.yaml at main · T3m3z/spotprices2ha
Simple copy-paste approach to fetch data from api.spot-hinta.fi (see https://spot-hinta.fi) to Home Assistant. Includes simple sensors and UI elements to ease automation work. - T3m3z/spotprices2haspotprices2ha/spot-price.yaml at v0.2.0-draft · T3m3z/spotprices2ha
Simple copy-paste approach to fetch data from api.spot-hinta.fi (see https://spot-hinta.fi) to Home Assistant. Includes simple sensors and UI elements to ease automation work. - T3m3z/spotprices2ha
Viittaatko siis juuri tuohon kohtaa koodia, jota korjasit vai jonnekin muualle?
Tuossa voisi n.klo 18 liipasta sääennusteen ja aurinkoetuottonnusteen haut, joiden tuloksen perusteella edetään.
Pitääkin miettiä mitä huonekohtaisiin attribuutteihin tulee kerätä, esim workday tomorrow yes/no jolloin voi pudottaa työhuoneiden lämpötilaa seuraavan jakson ajaksi.
Hienosäätö vai pitäisikö kutsua kuitenkin karkea on/off säätö tapahtuu kuitenkin tuon plänin ohella vielä paikallisesti livenä termostaatin toimesta, takan lämmitys tms jotka jättää lämmitystarpeen pois
Kiitos, pitääkin tutustua listojen hyödyntämiseen enemmän
- Keskustelun aloittaja
- #566
Jos oikein yksinkertaista toteutusta haluaa, niin voisi vaikka 17:50 hakea kolme halvinta tuntia. Näistä kalleimman tunnin hinta talteen vaikkapa Template-sensoriin. Sitten voi automaatio olla niin, että "jos hinta <= kallein halvimmista 3 tunnista" -> automaatio käynnistyy ja tekee jotain. Silloin ei tartteisi listojen kanssa ihmetellä. Ainoa haaste voi olla se, että jos sattuukin juuri niin, että vaikkapa halutun ajanjakson halvimmuusjärjestyksessä tuntien 3, 4, ja 5 hinta olisikin sattumalta sama. Tällöin yksinkertaistettu "lasketaan hintaraja ja ajetaan <= hinnoilla" -automaatio saattaisi pyöriä liian kauan. Koodin suhteen yksinkertaisempi, mutta lisää vähän semmoista "tämä ei ehkä tee aina täsmälleen sitä mitä haluat" -riskiä.
Alla nyt jotain tämän suuntaista, joka palauttaisi kalleimman hinnan halvimman 3h joukosta.
Python:
{% set start = now() %}
{% set end = start + timedelta(hours=24) %}
{% set hours = 3 %}
{{ ((state_attr('sensor.shf_data', 'data') |
selectattr("Timestamp", "ge", start | as_timestamp) |
selectattr("Timestamp", "lt", end | as_timestamp) |
sort(attribute="TotalPrice"))[:hours] | last)["TotalPrice"] }}Hauska nähdä miten eri tavalla muut käsittelevät ohjaustunteja! Itselläni on yksinkertaisesti hinnat taulukossa koska taulukon indeksihän kertoo suoraan mikä tunti on kyseessä. Nyt, kun toisesssa taulukossa on tallennettuna indeksien numerot, niin on helppo ja nopea käsitellä tätä hintataulukon indeksit tallentavaa taulukkoa. Koodaan ohjaukset bittitasolla kompaktiin muotoon siten, että tunti vastaa bittiä ja tallennan KV-tietokantaan. Purettaessa koodaus saadaan "päällä" tuntien indeksit suoraan numerojärjestyksessä ilman tarvetta lajitella. Nyt, kun tuosta hakee peräkkäiset tuntiryhmät niin on helppo muodostaa kaikki "päälle/pois" tapahtumat kerralla ohjausjonoon.
- Keskustelun aloittaja
- #568
Yksinkertainen on kaunista ja kuulostaa toimivalta. Käyttötapaus myös määrittelee, että mikä on paras ratkaisutapa. Tai ainakin vaikuttaa.
Aiemmat versiot tästä HomeAssistant-paketista olivat jotain tuon suuntaista, että tuntinumeroa käytettiin indeksinä esim. juuri kuluvan tunnin hintaa näytettäessä. Sain Githubiin Issueita siitä, että tuo aiheutti talviajasta kesäaikaan siirryttäessä ongelmia, joten päädyin siksi erilaiseen ratkaisuun.
Lisäksi vuorokauden vaihtuessa tuli haasteita siitä, että kun HA:ssa en voinut (tai no, tämä on vale - olisi voinut, mutta olisi monimutkaistanut koodia mielestäni aika paljon) määrittää sensorien päivitysajankohtia. Kävi niin, että pikkiriikkisen hetken saattoi näkyä edellispäivän hinta tunnille 0 eikä kuluvan päivän hinta tunnille 0. Tämä nyt tietysti oli kuitenkin toteutuksen bugi, kun en ollut otannut aiemmin huomioon tuota "ajojärjestystä" HA:n sisällä.
- Keskustelun aloittaja
- #569
Tämäkin on nyt toivottavasti historiaa uuden version myötä. Jos haluatte kokeilla, niin täällä sitä olisi tarjolla (vielä erillisessä branchissa, jotta ehditään saada käyttökokemuksia ennen "virallista julkaisua"): https://github.com/T3m3z/spotprices2ha/tree/v0.2.0-draft
Nyt on ainakin itsellä siistimpää kuvaajaa syntyy, jossa ei tuollaisia yllätyspiikkejä. Minulla hintoihin on ympättynä siirtokulut, joten siksi kaikki hinnat ~+5snt/kWh. 11.9. näkyy piikki alaspäin kello 7:40, mutta se johtuu siitä, että hetkellisesti laitoin siirtokulut nollaksi (eli graafissa -5snt/kwh).
Pitää kokeilla uusi versio kun tulee sopiva väli aikaa. Nyt vanhemmalla versiolla näyttäisi siltä että yö-/päiväsiirron hinnoittelu ei toimi tuossa SHF Electricity price now:ssa, vaan se on aina päivähinnalla. Toki ongelma voi löytyä peiliin katsomalla, mutta kohta kun lämmityskausi alkaa niin täytyy paneutua tuohon tarkemmin. Ilmeisesti tuollaisesta ongelmasta ei ole muut valitelleet?
heebo1974
Jäsen
Tässä ei näyttäisi olevan tuota SHF Electricity price now NoTax sensoria ja näytti rivit niin erilaisilta, että jätin kokeilematta.
Ehkä ajan kanssa olisin saattanut saada muokattua sen samaan muotoon. En viitsinyt rikkoa omaa automaatiota tuon puutteen takia.
EDIT: Taisi vielä mennä minulla -Teme- ja Temez sekaisin. Eihän tämä edes kuulunut alkuperäiseen julkaisuun, vaan oli -Teme-:n tekemä forkki minulle.
- Keskustelun aloittaja
- #572
Tässä ei näyttäisi olevan tuota SHF Electricity price now NoTax sensoria ja näytti rivit niin erilaisilta, että jätin kokeilematta.
Ehkä ajan kanssa olisin saattanut saada muokattua sen samaan muotoon. En viitsinyt rikkoa omaa automaatiota tuon puutteen takia.
EDIT: Taisi vielä mennä minulla -Teme- ja Temez sekaisin. Eihän tämä edes kuulunut alkuperäiseen julkaisuun, vaan oli -Teme-:n tekemä forkki minulle.
Jos nyt onnistuin tekemään tämän, niin tässä voisi olla kustomoitu sensorisi uudessa formaatissa, mutta samoilla nimillä kuin mitä -Teme-:n tekemässä esimerkissä. En kokeillut omassa HA:ssani.
YAML:
- sensor:
- name: SHF Electricity price now NoTax
unique_id: shf_electricity_price_now_no_tax
unit_of_measurement: "€/kWh"
device_class: monetary
state: '{{ (state_attr("sensor.shf_data", "data") | selectattr("Timestamp", "lt", now() | as_timestamp) | list)[-1]["PriceNoTax"] | round(4) }}'
availability: '{{ state_attr("sensor.shf_data", "data") | selectattr("Timestamp", "ge", now() | as_timestamp ) | list | length > 0 }}'
attributes:
all_prices_notax: '{{ state_attr("sensor.shf_data", "data") | selectattr("Timestamp", "ge", today_at("0:00") | as_timestamp) | map(attribute="PriceNoTax") |list }}'
today_prices_notax: '{{ state_attr("sensor.shf_data", "data") | selectattr("Timestamp", "ge", today_at("0:00") | as_timestamp) | selectattr("Timestamp", "lt", today_at("23:59") | as_timestamp) | map(attribute="PriceNoTax") |list }}'
tomorrow_prices_notax: '{{ state_attr("sensor.shf_data", "data") | selectattr("Timestamp", "ge", today_at("23:59") | as_timestamp) | map(attribute="PriceNoTax") |list }}'
today_min_notax: '{{ this.attributes.today_prices | default([0]) | min }}'
today_avg_notax: '{{ this.attributes.today_prices | default([0]) | average | round(4) }}'
today_max_notax: '{{ this.attributes.today_prices | default([0]) | max }}'
tomorrow_min_notax: '{{ this.attributes.tomorrow_prices | default([0], true) | min }}'
tomorrow_avg_notax: '{{ this.attributes.tomorrow_prices | default([0], true) | average | round(4) }}'
tomorrow_max_notax: '{{ this.attributes.tomorrow_prices | default([0], true) | max }}'Ville-Veikko
Jäsen
Heippa @Temez
Ja kiitokset päivityksestä, kivasti on pelannut kun olen parisen päivää olen katsellut. Tänään tuli tarvista halvimman jakson etsinnälle ja ihmetttää cheapest period scriptin käytös. Vaikuttaisi siltä että scripti palauttaa jakson alun 2h liian aikaiseksi. Esimerkissä yritän löytää halvimman tunnin, script löytää huomisen klo 21, kun halvin hinta on huomenna klo 23. Pistin hakujaksoksi tässä nyt 1h kun on selvempää esittää ongelma, sama 2h edistäminen tulee myös muihin jaksojen pituuksiin. Kuvasta näet miten olen ajan kysynyt.
Hyvä, kun otit tuon asian puheeksi! Korjasin nyt oman toteutukseni käsittelemään oikein nuo kellojen siirrot.
Ville-Veikko
Jäsen
Äh, ei koodissa ollut mitään vikaa, mulla oli yösiirtohinnan alku ja loppuajat syötettynä ristiin, vaihdoin ne oikeinpäin ja alkoi taas toimimaan.
Kiitokset vielä kerran @Temez debuggiavusta!
- Keskustelun aloittaja
- #576
Eipä mitään! Hyvä, että syy outoudelle löytyi.
Jos joku muu haluaa debugata näitä, niin tässä koodinpätkä, joka tulostaa tunneittain ulos kuluvan päivän energianhinnan, siirtohinnan ja yhteishinnan:
Tällä on helppo tarkistaa, että ovathan tunneittain arvot odotusten mukaiset.
- Keskustelun aloittaja
- #577
Siirtohintojen lisäyslogiikka on allekirjoittaneelta huonosti dokumentoitu noin muutenkin. Pitääpä ottaa todo-listalle. Price1 on voimassa Price2:sen "SHF Price2 start" -ajankohtaan asti, josta lähtien Price2 voimassa "SHF Price2 stop" -ajankohtaan asti. Sen jälkeen taas Price1.
Eli esimerkin kautta seuraavat alkuarvot
Price1 = 0.03 €/kWh
Price2 = 0.05 €/kWh
Price2 start = 07:00
Price2 stop = 22:00
tuottaisivat tuloksen, että siirtohinta on 0.03 €/kWh 0-7 sekä 22-24 ja 0.05 €/kWh aikavälillä 7-22.
Syötetyistä ajankohdista otetaan huomioon vain tunnit eikä minuutteja. Minulla oli näihin validointiautomaatiotakin kirjoitettuna, mutta ei ole koskaan tainnut eksyä osaksi pakettia. Pitänee ehkä sekin lisätä.
Eli esimerkin kautta seuraavat alkuarvot
Price1 = 0.03 €/kWh
Price2 = 0.05 €/kWh
Price2 start = 07:00
Price2 stop = 22:00
tuottaisivat tuloksen, että siirtohinta on 0.03 €/kWh 0-7 sekä 22-24 ja 0.05 €/kWh aikavälillä 7-22.
Syötetyistä ajankohdista otetaan huomioon vain tunnit eikä minuutteja. Minulla oli näihin validointiautomaatiotakin kirjoitettuna, mutta ei ole koskaan tainnut eksyä osaksi pakettia. Pitänee ehkä sekin lisätä.
Mites tuohon saisi toisen SHF Electricity price now -sensorin niin, että se ei lisää noita ylimääräisiä kustannuksia tuohon hintaan (SHF Price1/Price2).
Eli olisi tuo perus SHF Electricity price now -sensori, joka näyttää sen hetkisen sähkön hinnan ja sen lisäksi olisi esim. SHF Electricity price now Total -sensori, joka sitten näyttäisi kokonaishinnan, jos on lisännyt esim. marginaalit/siirrot/yötaksat.
Eli olisi tuo perus SHF Electricity price now -sensori, joka näyttää sen hetkisen sähkön hinnan ja sen lisäksi olisi esim. SHF Electricity price now Total -sensori, joka sitten näyttäisi kokonaishinnan, jos on lisännyt esim. marginaalit/siirrot/yötaksat.
Ihan mielenkiinnosta, kuinka toimii jos vuorokauden halvimpien tuntien jakso loppuu puolilta öin ja seuraavan vuorokauden halvimpien tuntien jakso alkaa puolilta öin? Käyttääkö silloin puolenyön aikaan ohjaus kontaktorin pois päältä ja laittaa heti takaisin päälle vai korjataanko tuo ohjaus aina automaattisesti samalla kun seuraavan vuorokauden tunnit on saatu yhdeksi yhtenäiseksi ohjausjaksoksi?
- Keskustelun aloittaja
- #582
Jos sinulla on käytössä se uudempi beta-versio tästä paketista, niin korvaamalla "TotalPrice" kohdat sanalla "PriceWithTax" pitäisi saada haluamasi kaltainen sensori. Lisäksi kenttiin unique_id ja name sitten sopivat tekstit.
En ole kokeillut alla olevaa, mutta tämän jos lykkäisee oikeilla sisennyksillä spot-price.yaml-tiedostoon esim. jo olemassa olevan "SHF Electricity price now" -sensorin määrittelyn alle, niin pitäisi toimia.
YAML:
- sensor:
- name: SHF Electricity price with tax now
unique_id: shf_electricity_price_now_pricewithtax
unit_of_measurement: "€/kWh"
device_class: monetary
state: '{{ (state_attr("sensor.shf_data", "data") | selectattr("Timestamp", "lt", now() | as_timestamp) | list)[-1]["PriceWithTax"] | round(4) }}'
availability: '{{ state_attr("sensor.shf_data", "data") | selectattr("Timestamp", "ge", now() | as_timestamp ) | list | length > 0 }}'
attributes:
data: '{{ state_attr("sensor.shf_data", "data") }}'
all_prices: '{{ state_attr("sensor.shf_data", "data") | selectattr("Timestamp", "ge", today_at("0:00") | as_timestamp) | map(attribute="PriceWithTax") |list }}'
today_prices: '{{ state_attr("sensor.shf_data", "data") | selectattr("Timestamp", "ge", today_at("0:00") | as_timestamp) | selectattr("Timestamp", "lt", today_at("23:59") | as_timestamp) | map(attribute="PriceWithTax") |list }}'
tomorrow_prices: '{{ state_attr("sensor.shf_data", "data") | selectattr("Timestamp", "ge", today_at("23:59") | as_timestamp) | map(attribute="PriceWithTax") |list }}'
today_min: '{{ this.attributes.today_prices | default([0]) | min }}'
today_avg: '{{ this.attributes.today_prices | default([0]) | average | round(4) }}'
today_max: '{{ this.attributes.today_prices | default([0]) | max }}'
tomorrow_min: '{{ this.attributes.tomorrow_prices | default([0], true) | min }}'
tomorrow_avg: '{{ this.attributes.tomorrow_prices | default([0], true) | average | round(4) }}'
tomorrow_max: '{{ this.attributes.tomorrow_prices | default([0], true) | max }}'Mitä sitä turhia kokeilemaan ja käyttämään ylimääräistä aikaa, kun tekee kerralla toimivan
Hyvin siis näytti toimivan, kiitos!
Mikäköhän on syynä kun Apex-chart näyttää tältä? On nyt muutaman päivän ollut käppyrät piilossa, asensin jopa äsken tuon 0.2.0 betaversion ajatellen että jos se korjaisi jotain mutta eipä tehnyt... Kuitenkin jos lisään uuden Apex-kortin HA:ssa ja HA ehdottaa siihen jotain sensoreita niin niissä kyllä käppyrät näkyy oikein?
Itselläni on ollut samanlaisin ongelmia, en ole oikein päässyt selville että mistä johtuu. HA:n uudelleenkäynnistys palauttaa käppyrät, mutta ei ole varsinainen ratkaisu ongelmaan.
Tuota itsekin luulin ratkaisuksi ja eilen käynnistin HA:n mutta ei auttanut :/ Katsoinpa nyt HA:n lokeja ja hakusanalla shf löytyy tämmöisiä, jotain tuossa koodissa lienee pielessä:
Error while dispatching event for sensor.shf_electricity_price_now to <Job track state_changed event {'sensor.shf_control_factor_1', 'sensor.shf_electricity_price_now'} HassJobType.Callback <bound method TrackTemplateResultInfo._refresh of <TrackTemplateResultInfo {Template<template=({{ state_attr("sensor.shf_control_factor_1", "today_values")[now().hour] | default("Unknown") }}) renders=4>: <RenderInfo Template<template=({{ state_attr("sensor.shf_control_factor_1", "today_values")[now().hour] | default("Unknown") }}) renders=4> all_states=False all_states_lifecycle=False domains=frozenset() domains_lifecycle=frozenset() entities=frozenset({'sensor.shf_control_factor_1'}) rate_limit=None has_time=True exception=None is_static=False>, Template<template=({% set output = namespace(value=[]) %} {% for pnow in state_attr("sensor.shf_electricity_price_now", "today_prices") %} {% set pmin = state_attr("sensor.shf_electricity_price_now", "today_min") | float %} {% set pmax = state_attr("sensor.shf_electricity_price_now", "today_max") | float %} {% set value = max(min((2*(pmax - pnow) / (pmax - pmin)-1) * states('input_number.shf_control_function_factor') | float,1),-1) %} {% if states("input_select.shf_control_function" ) == "Linear" %} {% set output.value = output.value + [value | round(2)] %} {% else %} {% set output.value = output.value + [sin(value*pi/2) | round(2)] %} {% endif %} {% endfor %} {{ output.value }}) renders=10>: <RenderInfo Template<template=({% set output = namespace(value=[]) %} {% for pnow in state_attr("sensor.shf_electricity_price_now", "today_prices") %} {% set pmin = state_attr("sensor.shf_electricity_price_now", "today_min") | float %} {% set pmax = state_attr("sensor.shf_electricity_price_now", "today_max") | float %} {% set value = max(min((2*(pmax - pnow) / (pmax - pmin)-1) * states('input_number.shf_control_function_factor') | float,1),-1) %} {% if states("input_select.shf_control_function" ) == "Linear" %} {% set output.value = output.value + [value | round(2)] %} {% else %} {% set output.value = output.value + [sin(value*pi/2) | round(2)] %} {% endif %} {% endfor %} {{ output.value }}) renders=10> all_states=False all_states_lifecycle=False domains=frozenset() domains_lifecycle=frozenset() entities=frozenset({'input_number.shf_control_function_factor', 'input_select.shf_control_function', 'sensor.shf_electricity_price_now'}) rate_limit=None has_time=False exception=None is_static=False>, Template<template=(mdi:gauge) renders=6>: <RenderInfo Template<template=(mdi:gauge) renders=6> all_states=False all_states_lifecycle=False domains=frozenset() domains_lifecycle=frozenset() entities=frozenset() rate_limit=None has_time=False exception=None is_static=True>}>>>
00.00.00 – (VIRHE) components/sensor/__init__.py - Viesti esiintyi ensimmäisen kerran 21. syyskuuta 2023 klo 15.33.39 ja tämän jälkeen 2 kertaa
TemplateError('ValueError: Template error: float got invalid input 'unknown' when rendering template '{{ (states("sensor.shf_control_factor_1") | float /2 + 0.5) | default("Unknown") }}' but no default was specified') while processing template 'Template<template=({{ (states("sensor.shf_control_factor_1") | float /2 + 0.5) | default("Unknown") }}) renders=4>' for attribute '_attr_native_value' in entity 'sensor.shf_control_factor_0_1'
21. syyskuuta 2023 klo 15.33.39 – (VIRHE) Template - Viesti esiintyi ensimmäisen kerran 21. syyskuuta 2023 klo 15.33.38 ja tämän jälkeen 17 kertaa
Error while processing template: Template<template=({{ (states("sensor.shf_control_factor_1") | float /2 + 0.5) | default("Unknown") }}) renders=2>
21. syyskuuta 2023 klo 15.33.39 – (VIRHE) helpers/template.py - Viesti esiintyi ensimmäisen kerran 21. syyskuuta 2023 klo 15.33.38 ja tämän jälkeen 17 kertaa
heebo1974
Jäsen
Hmm.. Nyt vihdoin sain aikaiseksi tämän. Lätkäisin uuden version (v0.2.0-draft) + tuon notax forkin, jonka teit minulle. Hoplaa ja kaikki näyttäisi toimivan ihan normaalisti. Vähän ehkä hirvittää, että menikö muka näin helposti ?Tässä ei näyttäisi olevan tuota SHF Electricity price now NoTax sensoria ja näytti rivit niin erilaisilta, että jätin kokeilematta.
Ehkä ajan kanssa olisin saattanut saada muokattua sen samaan muotoon. En viitsinyt rikkoa omaa automaatiota tuon puutteen takia.
EDIT: Taisi vielä mennä minulla -Teme- ja Temez sekaisin. Eihän tämä edes kuulunut alkuperäiseen julkaisuun, vaan oli -Teme-:n tekemä forkki minulle.
Viimeksi muokattu:
Tänään IP kun haettiin uudet hinnat niin tuli nuo hintapylväät takaisin. Täytyy seurata että olisiko ongelma taas edessä huomenna aamulla. Jos on, niin kyse voisi olla vuorokauden vaihtumisesta.
- Keskustelun aloittaja
- #589
Jos käytätte tuota "uutta kokeiluversiota 0.2.0", niin siinä oli tosiaan epäyhteensopivuutta. Versioon sopivan kortin konffi löytyy täältä: https://github.com/T3m3z/spotprices...visualisations/current_electricity_price.yaml
Muistaakseni vanha kortti + tämän paketin versio 0.2.0 aiheuttivat sen, että tosiaan hinnat näkyivät vain 14-23:59 kuvaajassa.
Raportoikaa tännekin, että auttaako tuo "uusi korttikonffi". Ja kannattaa myös katsoa, että on uusin Apexcharts cardin versio: https://github.com/RomRider/apexcharts-card
Muistaakseni vanha kortti + tämän paketin versio 0.2.0 aiheuttivat sen, että tosiaan hinnat näkyivät vain 14-23:59 kuvaajassa.
Raportoikaa tännekin, että auttaako tuo "uusi korttikonffi". Ja kannattaa myös katsoa, että on uusin Apexcharts cardin versio: https://github.com/RomRider/apexcharts-card
- Keskustelun aloittaja
- #590
Viestissäsi mainitsemat virheet taitavat olla ennen versiota 0.2.0 olevista versioista. Siellä oli tiedossa oleva juttu, että HA:n käynnistyessä tuli logille kasa virheitä. Toiminnallisesti kaikki toimi suhteellisen okei, mutta osa sensoreista koetti hakea tietoa toisista sensoreista, jotka eivät olleet vielä valmiita. Ja se aiheutti virheitä. Tätä on koetettu korjata nyt tässä uudessa versiossa.
Voisit koettaa tätä, jos se auttaisi.
- Keskustelun aloittaja
- #591
Tämä oli tavoite, että vaikka konepellin alla pistettiin asioita uusiksi (parantaen monta pientä asiaa), niin ulospäin muuttuisi mahdollisimman vähän ja "backwards compatibility" olisi mahdollisimman hyvä. Ainoa "rikki" menevä asia taisi olla lähinnä se hinnat näyttävä kortti. Hienoa kuulla, että ainakin ensivaikutelman perusteella olen onnistunutHmm.. Nyt vihdoin sain aikaiseksi tämän. Lätkäisin uuden version (v0.2.0-draft) + tuon notax forkin, jonka teit minulle. Hoplaa ja kaikki näyttäisi toimivan ihan normaalisti. Vähän ehkä hirvittää, että menikö muka näin helposti ?
Minulla on vähän ajatuksena, että voisi kokeilla myös noita muita hinta-alueita tukea. Mikin hienossa API:ssa olikin nuo muut hinta-alueet jo tuettuna (Ruotsin alueet jne.).
heebo1974
Jäsen
Itselläni "oma" apex conffi ja siihen ei ainakaan päivitys vaikuttanut.
Sama havainto minulla eli kokeilin myös tuota aiempaa apex-korttia mutta molemmat näyttävät menevän rikki tod näköisesti vuorokauden vaihtuessa. Minulla on rinnalla myös Nordpool-integraatio ja sen apex. Se näyttää toimivan normaalisti. Täytyy tutkia näiden eroja.
Onko tuo rajapinta jotenkin muuttunut vai muistanko väärin, että palautti ennen aina 48h, eli edellisen päivän hinnat mukana kunnes seuraava päivä julkaistaan? Nyt näyttää palauttavan vain tämän vuorokauden hinnat, eli siellä on 48 tunnin sijasta vain 24 tuntia.
Tässä nyt heitto datageneratoriin miten se voisi ehkä toimia niin, että hintojen määrä vaihtelee, pitää vaan vaihtaa nuo attribuutit oikein kun minulla ei ole nyt ha tässä missä olisi shf ja pääsisi testaamaan.
Koodi:
let res = [];
for (const [key, value] of
Object.entries(entity.attributes.data)) {
let d = new Date(value.tähänaikaleima).getTime();
let p = parseFloat(value.tähänhinta);
res.push([d, p]);
}
return res.sort((a, b) => { return a[0] - b[0] });
Viimeksi muokattu:
Ei ole muuttunut. Noin on ollut aina.
Minulla oli siis monta päivää sellainen tilanne että graafi näytti tyhjää, vaikka hintatiedot kyllä näyttivät päivittyvän eli näkyi se kuluvan tunnin hinta. Tänä aamunakin vielä, mutta lähdin siitä reissuun ja tulin hetki sitten takaisin ja ihmetyksekseni nyt oli graafit palanneet, kuten näemmä hemarisillakin. Pitää yrittää tuo 0.2.0 -versiokin asentaa tässä jos ongelmat jatkuvat, mielestäni sen kyllä jo tein mutta ehkä asensin sen sitten väärin.
Ninnannunna
Jäsen
Jotain hämyä sen kortin conffissa on. Samaa vikaa täälläkin. Sen verran ehdin testaamaan, että kun jättää osan sensoreista pois niin näkyy.
Koodi:
type: custom:apexcharts-card
graph_span: 48h
experimental:
color_threshold: true
show:
last_updated: true
header:
title: Electricity price
show: true
show_states: true
colorize_states: true
span:
start: day
yaxis:
- min: 0
decimals: 2
apex_config:
forceNiceScale: true
now:
show: true
label: Now
series:
- entity: sensor.shf_electricity_price_now
show:
in_header: false
extremas: true
legend_value: false
type: column
color: lightgray
float_precision: 2
unit: c/kWh
data_generator: |
return entity.attributes.data.map((d, index) => {
return [d["Timestamp"]*1000, d["TotalPrice"]*100];
});
color_threshold:
- value: 0
color: 368f39
- value: 10
color: a3b34d
- value: 20
color: ffd57e
- value: 30
color: f18c56
- value: 40
color: de425b- Keskustelun aloittaja
- #599
Tämäpä suorastaan jännittävää. Onko kenelläkään haisua, että mikä voisi olla ns. yhdistävä tekijä ongelman alkamiselle? Tai jotain arviota alkamisajankohdasta? Jos porukalla keksittäisiin jokin yhdistävä juttu.
Minulla itsellä käytössä tästä spotprices2ha-paketista versio 0.2.0, Apex chart -kortista versio 2.0.4 ja HomeAssistantista 2023.9.1 enkä ole havainnut vastaavia ongelmia (paitsi alussa, kun vanha korttikonffi oli epäyhteensopiva spotprices2ha version 0.2.0 kanssa). Mutta esim. @Ninnannunna näyttää käyttävän sitä uudempaa korttikonffiversiota ja silti ongelmia
Voisikohan tuo Apex chart -kortin versio vaikuttaa? Vaikea auttaa, kun en oikein saa itse toistettua tätä vikaa. Yllä tiedot siitä, että millaisella setillä itsellä tuntuu nyt pelaavan ihan OK.
Puhelimella siis aamulla ~9:40 paikkeilla näytti tältä (hinnoissa siirtomaksut mukana):
Tietokoneella näyttää nyt 23.9. kello 21:09 tältä (hinnoissa siirtomaksut mukana):
Minulla itsellä käytössä tästä spotprices2ha-paketista versio 0.2.0, Apex chart -kortista versio 2.0.4 ja HomeAssistantista 2023.9.1 enkä ole havainnut vastaavia ongelmia (paitsi alussa, kun vanha korttikonffi oli epäyhteensopiva spotprices2ha version 0.2.0 kanssa). Mutta esim. @Ninnannunna näyttää käyttävän sitä uudempaa korttikonffiversiota ja silti ongelmia
Voisikohan tuo Apex chart -kortin versio vaikuttaa? Vaikea auttaa, kun en oikein saa itse toistettua tätä vikaa. Yllä tiedot siitä, että millaisella setillä itsellä tuntuu nyt pelaavan ihan OK.
Puhelimella siis aamulla ~9:40 paikkeilla näytti tältä (hinnoissa siirtomaksut mukana):
Tietokoneella näyttää nyt 23.9. kello 21:09 tältä (hinnoissa siirtomaksut mukana):
Ei tuossa toiminnassa oikein mitään logiikkaa huomaa. Minulla on nyt ajossa kaksi HA:ta. Toinen virtuaalikoneena Proxmoxilla (eilen asennettu) ja toinen on Raspilla jo aiemmin käytössä ollut. Raspiversiossa on uusin Apexcharts 2.0.4, spotprices2ha versio on 0.1.10 johon itse tehty pari korjausta liittyen control factor sensoreihin, niistä aiemmin tässä ketjussa. Ilmeisesti vastannee pitkälti virallista 0.1.11 versiota.. HA core on 2023.9.2. Proxmox versio on muutoin sama, mutta siinä on uusin spotprices2ha versio 0.2.0. Nyt aamulla katsottuna:
Raspiversio:
Proxmoxversio:
Eli vanhemmalla spotpices2ha versiolla oleva toimii tänä aamuna. Mutta siinäkin on ollut vastaavia katkoja, joten vika tuskin liittyy tuohonkaan. Ainiin vielä yksi ero noissa on. Raspiversiossa on HAOS versio 10.4 ja Proxmox versiossa 10.5.
Proxmoxversiossakin näkyi käppyrät eilen, mutta skaalaus siinä oli hitusen erilainen, lähti nollasta vaikka ihan sama koodi. En tutkinut asiaa sen ihmeemmin. En ole varma tuleeko ongelma päälle jos jossain sopivassa kohtaa menee käynnistämään HA:n uudelleen. Nyt kun tuo raspiversio on ollut ajossa jonkin päivän, niin mielestäni on toiminut ok. Jokin päivää sitten minulla oli vähän haasteita noiden kaatumisten kanssa, jolloin tuli useitakin bootteja. Silloin oli ongelmaa tuon käppyränkin kanssa, mutta en siitä silloin niin välittänyt kun oli muutakin haastetta
Raspiversio:
Proxmoxversio:
Eli vanhemmalla spotpices2ha versiolla oleva toimii tänä aamuna. Mutta siinäkin on ollut vastaavia katkoja, joten vika tuskin liittyy tuohonkaan. Ainiin vielä yksi ero noissa on. Raspiversiossa on HAOS versio 10.4 ja Proxmox versiossa 10.5.
Proxmoxversiossakin näkyi käppyrät eilen, mutta skaalaus siinä oli hitusen erilainen, lähti nollasta vaikka ihan sama koodi. En tutkinut asiaa sen ihmeemmin. En ole varma tuleeko ongelma päälle jos jossain sopivassa kohtaa menee käynnistämään HA:n uudelleen. Nyt kun tuo raspiversio on ollut ajossa jonkin päivän, niin mielestäni on toiminut ok. Jokin päivää sitten minulla oli vähän haasteita noiden kaatumisten kanssa, jolloin tuli useitakin bootteja. Silloin oli ongelmaa tuon käppyränkin kanssa, mutta en siitä silloin niin välittänyt kun oli muutakin haastetta
Viimeksi muokattu: