HomeAssistant ja sähköpörssiohjaus

dillon

Jäsen
Hmm, olenkohan ainoa, jolla SHF ei selvinnyt talviaikaan siirtymisestä? Hinnat on tunnin myöhässä.
Kyllä täällä ainakin tänään näyttää oikein. Eilisestä en ole varma kun en tarkistanut.

Mutta HA:n utility meter ei näköjään selvinnyt. Päivälaskurit on resetoitu viime yönä vasta 01 eikä 00.
 

exrx

Jäsen
Hmm, olenkohan ainoa, jolla SHF ei selvinnyt talviaikaan siirtymisestä? Hinnat on tunnin myöhässä.

Kyllä täällä ainakin tänään näyttää oikein. Eilisestä en ole varma kun en tarkistanut.

Mutta HA:n utility meter ei näköjään selvinnyt. Päivälaskurit on resetoitu viime yönä vasta 01 eikä 00.

Tämä olikin näköjään user error: Mulla oli niin vanha versio spot-price.yaml:sta että ei osannut talviaikasiirrosta. Päivitin uusimpaan, ja homma rupesi toimimaan.
 

Temez

Aktiivinen jäsen
Pientä hiljaiseloa taas hetki tullut. Meille tuli perheenlisäystä, joten aktiivinen kirjoittelu jäänyt vähemmälle. Varmaan aktiivisuustaso vaihtelee tässä lähiviikkoina kovastikin.
Lisäsin tuohon SHF-pakettiin neljännenkin sensorin, eli "SHF Price AND Rank acceptable". En tiedä onko tuolla kuinka paljon käyttöä, mutta saa vähän tiukemmilla ehdoilla käynnistettyä jotain tiettyä automaatiota, kun molempien pitää olla asetettujen arvojen sisällä.
Tästä taisitkin aiemmin jo puhua. Voisin lisäillä peruspakettiinkin tuon, koska sen lisääminen on todella nopea homma. Tilausta tälle ehkä on?

Vaikka ilmalämpöpumpun pyyntilämpötilan määrittämiseen. Normipyynti + 2 x Factor esimerkiksi, jolloin halvimmalla tunnilla pyyntiin tulee kaksi lisäastetta.
Juurikin näin. Ajatuksena oli tuoda jokin aloittelijan helposti käyttöönotettava systeemi, jolla saa halvoilla tunneilla nostettua lämpöä ja/tai laskettua kalliilla.

Tämmöinen avustava graafi tuon tutkimiseen tuli joskus tehtyä. Eli kun sähkö oli yöllä halvimmillaan, niin "SHF Control Factor 0-1" -sensorin arvo on 1. Kalleimmailla tunnilla sen arvo on 0. Näin voi ilmalämpöpumpulle käskeä, että pyyntilämpötila on (22 °C + 2°C*"SHF Control Factor 0-1") pyöristettynä haluttuun tarkkuuteen (templatena esim {{ (22 + states('sensor.shf_control_factor_0_1') | float * 2) | round(0) }} ). Silloin ILPin lämpötilapyynti vaihtelisi 22°C ja 24°C välillä riippuen kuluvan ajanhetken kalleudesta.
1698822110019.png

Koodi:
type: custom:apexcharts-card
experimental:
  color_threshold: true
now:
  show: true
  color: '#ff0000'
apex_config:
  forceNiceScale: true
  chart:
    height: 165%
yaxis:
  - id: pyynti
    show: true
    decimals: 2
    align_to: 1
    apex_config:
      tickAmount: 4
      seriesName: pyynti
  - id: hinta
    show: true
    opposite: true
    min: 0
    max: ~25
    decimals: 2
    align_to: 1
    apex_config:
      tickAmount: 4
show:
  last_updated: false
header:
  standard_format: false
  show: true
  show_states: true
  colorize_states: true
  title: Ohjaus vs. pörssisähkö.
span:
  start: day
  offset: +0h
update_delay: 2s
series:
  - entity: sensor.shf_electricity_price
    yaxis_id: hinta
    name: Pörssisähkö c/kWh
    extend_to: now
    type: area
    curve: stepline
    opacity: 0.02
    group_by:
      func: last
      duration: 60m
    stroke_width: 1
    data_generator: |
      return entity.attributes.data.map((d, index) => {
        return [new Date(d["DateTime"]).getTime(), d["PriceWithTax"]*100];
      });
    show:
      header_color_threshold: true
      legend_value: false
      in_header: false
      name_in_header: false
      extremas: true
  - entity: sensor.shf_control_factor_0_1
    yaxis_id: pyynti
    name: Ohjaus
    unit: C
    type: area
    curve: stepline
    opacity: 0.02
    stroke_width: 1
    data_generator: |
      return entity.attributes.today_values.map((d, index) => {
        return [start.getTime()+index*3600000, d];
      });
    show:
      header_color_threshold: true
      legend_value: false
      in_header: false
      name_in_header: false
      extremas: true
Vaikka joskus on saattunutkin ne halvimmat tunnit keskiyön molemmin puolin niin ei se ole haitannut eikä lämmin vesi ole loppunut. Nyt oli kyllä mennyt päälle kello 7, rank 1 mutta ainakin shf rank now käppyrä loppuu kello 12 joten en tiedä milloin tulee se rank 2 tunti. Onkohan tarkoituksella noin, että näyttää kyllä eilisen muttei tänään vaikka ne ovatkin jo tiedossa?
katso liitettä 89310
Tähän taidettiinkin jo vastailla, mutta tosiaan tämä on HomeAssistantissa "sensori", jonka arvo oli tarkasteluhetkellä 13. Ja kuvaaja näyttää HomeAssistantin tietokantaansa tallentamaa historia-arvoa eli mitä Rank on ollut joskus aiemmin.

Rank-tiedot ovat kuitenkin HomeAssistantissa olemassa jo kyllä "tulevaisuuteen". Sensorit vain näyttävät arvoja nykyhetkestä. Tässä apex-chart-koodi, jolla saat hinnan ja Rankin näkymään myös tulevaisuuteen graafina:
1698827911005.png


Koodi:
type: custom:apexcharts-card
now:
  show: true
  color: '#ff0000'
apex_config:
  xaxis:
    tooltip:
      enabled: false
yaxis:
  - id: rank
    show: true
    decimals: 0
    apex_config:
      forceNiceScale: true
      title:
        text: Rank
  - id: price
    show: true
    opposite: true
    decimals: 2
    apex_config:
      forceNiceScale: true
      title:
        text: c/kWh
show:
  last_updated: false
header:
  standard_format: false
  show: true
  show_states: true
  colorize_states: true
  title: Price and Rank without extra fees
span:
  start: day
  offset: +0h
update_delay: 2s
series:
  - entity: sensor.shf_electricity_price
    yaxis_id: price
    name: Electricity price c/kWh
    extend_to: now
    type: area
    curve: stepline
    opacity: 0.02
    group_by:
      func: last
      duration: 60m
    stroke_width: 1
    data_generator: |
      return entity.attributes.data.map((d, index) => {
        return [new Date(d["DateTime"]).getTime(), d["PriceWithTax"]*100];
      });
    show:
      header_color_threshold: true
      legend_value: false
      in_header: true
      name_in_header: true
      extremas: true
  - entity: sensor.shf_electricity_price
    yaxis_id: rank
    name: Rank now (current day)
    extend_to: now
    type: area
    curve: stepline
    opacity: 0.02
    group_by:
      func: last
      duration: 60m
    stroke_width: 1
    data_generator: |
      return entity.attributes.data.map((d, index) => {
        return [new Date(d["DateTime"]).getTime(), d["Rank"]];
      });
    show:
      header_color_threshold: true
      legend_value: false
      in_header: true
      name_in_header: true
      extremas: false
 

Temez

Aktiivinen jäsen
Onko kenelläkään muuten havaintoja, että tällä kertaa olisi mennyt kellojen siirron vuoksi jotain kuralle/rikki uuden 0.2.X versioiden kanssa?
 

haraldh

Vakionaama
Suuret kiitokset näistä, ja onnitteluja! Otanpa heti nuo sun Apexchartsit käyttöön! Tuolla toisella ja tehokuvaajalla täysleveässä moodissa saan itse asiassa minulle fissiosta tutun näkymän aikaiseksi. Tässähän alkaa tuntumaan oikein kotoisalta, etenkin kun säätöja pääsee tekemään eikä tarvitse odottaa että tekeekö "Kehittäjä" tai ei, jos edes viitsii vastaila.

Teen itseasiassa nyt vain automaatiolla niin että asetan pyynnin +2°C jos rank on ok tai hinta on ok sillä helperillä. Nyt vasta selvisi miten tuo factor pitää käyttää. Loistavaa! Dokumentointiin vaan kaikille käyttöön.
 
Viimeksi muokattu:

Temez

Aktiivinen jäsen
Liittyen noihin automaatioihin ja erilaisiin graafeihin. Voisin ehkä lisäillä Githubiin omaan kansioonsa erilaisia valmiita Apex-graafeja erilaisiin tarkoituksiin. Ja toiseen kansioon sitten erilaisia automaatio-blueprinttejä, joista voi lähteä liikkeelle. Mallia esimerkiksi juurikin tämä pyyntilämpötilan vaihto SHF Control Factorin perusteella.

EDIT: tänne voisi sitten joukkoistamalla myös foorumilaiset laitella pull requesteilla uusia graafipohjia ja automaatio-blueprinttejä, jottei asioiden kehittyminen ja helpottuminen jäisi vain yhden (välillä poissaolevan) henkilön ajankäytön priorisoinnin varaan.
 

Temez

Aktiivinen jäsen
Teen itseasiassa nyt vain automaatiolla niin että asetan pyynnin +2°C jos rank on ok tai hinta on ok sillä helperillä. Nyt vasta selvisi miten tuo factor pitää käyttää. Loistavaa! Dokumentointiin vaan kaikille käyttöön.
Sellainen huomio kuitenkin tuosta SHF Control Factorista, että se oli sellainen "kokeilu", jolla pakettiin sai jotain "muuta arvoa välillä A-B hinnan perusteella" ohjausta toisin kuin ennen sitä kaikki oli enemmän tai vähemmän on/off-tyyppistä ohjausta. Ohjauslogiikka tuskin on kaikkein paras ja parempia tapoja olisi varmasti myös ohjaukseen. Luulen, että nyt tuolla ohjauksella voi olla välillä liian kuuma ja välillä liian kylmä riippuen siitä, että miten iso osa tunneista on lähellä päivän maksimia tai minimiä. Noh, kuitenkin jotain, jolla saa jo ohjausta ja myös säästöjä mahdollisesti aikaan.

Jos ei muuta saa aikaan, niin harrastuksen, johon uppoaa kaikki vapaa-aika :)
 

haraldh

Vakionaama
Tämmöinen avustava graafi tuon tutkimiseen tuli joskus tehtyä. Eli kun sähkö oli yöllä halvimmillaan, niin "SHF Control Factor 0-1" -sensorin arvo on 1. Kalleimmailla tunnilla sen arvo on 0. Näin voi ilmalämpöpumpulle käskeä, että pyyntilämpötila on (22 °C + 2°C*"SHF Control Factor 0-1") pyöristettynä haluttuun tarkkuuteen (templatena esim {{ (22 + states('sensor.shf_control_factor_0_1') | float * 2) | round(0) }} ). Silloin ILPin lämpötilapyynti vaihtelisi 22°C ja 24°C välillä riippuen kuluvan ajanhetken kalleudesta.
katso liitettä 89647
Kertoisitko tarkemmin miten teet sen ohjauksen?

Miten SHF Control Function Factor eroaa SHF Control Factorista?
 
Viimeksi muokattu:

Temez

Aktiivinen jäsen
SHF Control Function -valinta ja SHF Control Function Factor -arvo ovat loppukäyttäjän syöttämiä parametreja. Niiden perusteella sitten syntyy arvot sensoreihin "SHF Control Factor 0-1" ja "SHF Control Factor +-1", joita voi käyttää ohjaukseen.

Nämä jatkuvan ohjauksen sensorit ottavat nyt päivän maksimi- ja minimihinnan erotuksen ja skaalaavat sitten nykyisen sähkönhinnan joko arvoksi välille 0 ja 1 tai -1 ja +1. Hommaan vaikuttavat aiemmin mainitut kaksi parametria. Control Function muuttaa lähinnä ulostuloarvon muotoa ääripäiden lähellä. Ja Function Factor taas vaikuttaa käytännössä siihen, että "kauanko hengaillaan ääripäissä". Mitä isompi arvo, niin sitä kauemmin hengaillaan siellä ääripäässä. Pari esimerkkikuvaa:
1698837532438.png
1698837519274.png

Yksinkertainen esimerkki: Control Function = Linear ja Function Factor = 1 eli käytännössä suoraan lineaarinesti laskettu ilman kertoimia. Jos tänään kallein hinta on 10c/kWh ja halvin 2 c/kWh ja juuri nyt hinta 6c/kWh, niin ohjaukseksi tulee 1- 6/(10-2) = 0,25. Se voisi sitten tuossa ILP-esimerkkissa tarkoittaa pyyntilämpötilaa 22 + 0,25*2 = 22,5 astetta (päivän aikana pyynti vaihtelisi 22-24 välillä).

Joitakin kuvia asiasta löytyy täältä:
 

Temez

Aktiivinen jäsen
Githubissa kyseltiin, että saisiko hinnat euroista senteiksi. Eurohinnat tulivat Mikin API:n tarjoaman datan kautta puolivahingossa. En lähtenyt tekemään muutosta, koska varmaan aika monella menisi kaikenlaista rikki muutoksesta.

Laittelin tästä nyt kuitenkin äänestystä pystyyn Githubissa emoji-reaktioilla: https://github.com/T3m3z/spotprices2ha/issues/20#issuecomment-1788814567

Osalla teistä ei välttämättä ole Github-tunnusta, joten tehdään tähän vastaava. Reagoi tähän viestiin seuraavasti:
- hinnat sentteinä olisi parempi: peukku ylös
- hinnat euroina parempi: Love/sydänsilmä-emoji
- ei väliä: Haha/itkunauru-emoji

Älkää äänestäkö kahdessa paikassa.
 

Temez

Aktiivinen jäsen
Liittyen noihin automaatioihin ja erilaisiin graafeihin. Voisin ehkä lisäillä Githubiin omaan kansioonsa erilaisia valmiita Apex-graafeja erilaisiin tarkoituksiin. Ja toiseen kansioon sitten erilaisia automaatio-blueprinttejä, joista voi lähteä liikkeelle. Mallia esimerkiksi juurikin tämä pyyntilämpötilan vaihto SHF Control Factorin perusteella.
Tulin nyt perehtyneeksi HomeAssistantin Automation Blueprintteihin. Niiden kautta tämä onnistuu mukavasti.

Tein Rank/Price/RankOrPrice/RankAndPrice-automaatioita varten tämmöisen blueprintin (disclaimer: huonosti testattu vielä ja käyttökokemuksia kaivataan):

Importin pitäisi lähteä käyntiin klikkaamalla tätä linkkiä (aseta "Your Instance URL" seuraavalla sivulla, jos se ei ole jo oikein): https://my.home-assistant.io/redire...ub.com/T3m3z/606e4763cbab9f11225d0dbe0be3e78b

Blueprint näyttää sitten "asetuksia tehdessä" tältä:
1698993925630.png


Myöhemmin kyseinen blueprint löytyy Settings -> Automations & Scenes -> Blueprints, jonka kautta voi tehdä useita uusia automaatioita tarvittaessa.

Olisiko jonkinlainen patteristo blueprinttejä hyvä juttu tähän spotprices2ha-pakettiin? Luulisin itse, että olisi. Ainakin tuo käyttöliittymän suhteen saisi aloittelijat taas astetta helpommin liikkeelle esim. tässä tapauksessa, kun ei tarvitsisi miettiä, että mikäs näistä sensoreista tulisi ottaa nyt automaation triggeriksi jne.
 

haraldh

Vakionaama
Blueprintit oli varmaan sitä mitä etsin silloin kun kysyin miten factoreita käytetään. Hienoa.

Sellainen tuli Mieleen että millä tavalla HA:n automaatiot käyttäytyvät jos SHF on ns. rikki? Ilmalämpöpumppujen pyynti jää viimeisimpään tilaan, vai meneekö kaikki price ja rankit clear-tilaan ja ohjaukset joko off tai madallettuun pyyntiin?
 

Temez

Aktiivinen jäsen
Sellainen tuli Mieleen että millä tavalla HA:n automaatiot käyttäytyvät jos SHF on ns. rikki? Ilmalämpöpumppujen pyynti jää viimeisimpään tilaan, vai meneekö kaikki price ja rankit clear-tilaan ja ohjaukset joko off tai madallettuun pyyntiin?
No tämän jätin alunperin pakettia käyttävän henkilön vastuulle, että koettaa reagoida haluamallaan tavalla poikkeuksiin. Koetin tätä lyhyesti aikanaan pohtia, mutta tulin siihen tulokseen, että ohjattavia laitteita ja myös haluttuja fallback-tiloja on niin erilaisia, että ei ollut mielestäni järkevää lähteä paketilla sitä ratkomaan.
 

Mikki

Hyperaktiivi
Se että SHF on rikki voi johtua kolmesta pääsyystä: 1) Spot-hinta.fi palvelu on pois pelistä jostain syystä 2) Internet-yhteys on poikki pitkään 3) HomeAssistant laite hajoaa kunnolla joko softapuolelta tai rautapuolelta.

Jos talonsa lämmitystä vaikka laittaa HomeAssistantin varaan, niin kannattaa tosiaan miettiä varasuunnitelmat, jos ei hommat menekkään syystä tai toisesta putkeen. Virhepaikkoja on kuitenkin useita.
 

Kaimax

Jäsen
SHF Control Function -valinta ja SHF Control Function Factor -arvo ovat loppukäyttäjän syöttämiä parametreja. Niiden perusteella sitten syntyy arvot sensoreihin "SHF Control Factor 0-1" ja "SHF Control Factor +-1", joita voi käyttää ohjaukseen.

Nämä jatkuvan ohjauksen sensorit ottavat nyt päivän maksimi- ja minimihinnan erotuksen ja skaalaavat sitten nykyisen sähkönhinnan joko arvoksi välille 0 ja 1 tai -1 ja +1. Hommaan vaikuttavat aiemmin mainitut kaksi parametria. Control Function muuttaa lähinnä ulostuloarvon muotoa ääripäiden lähellä. Ja Function Factor taas vaikuttaa käytännössä siihen, että "kauanko hengaillaan ääripäissä". Mitä isompi arvo, niin sitä kauemmin hengaillaan siellä ääripäässä.
Tuosta SHF Control Factor +-1 ohjauksesta, onko mahdollista saada kiinteillä arvoilla lineaarisesti säätymään? Esim. kun sähkön hinta on 1c/kWh ohjaus olisi +1, sähkön hinta on 5c/kWh ohjaus olisi 0 ja sähkön hinta on 10c/kWh ohjaus olisi -1.
 

Temez

Aktiivinen jäsen
Tuosta SHF Control Factor +-1 ohjauksesta, onko mahdollista saada kiinteillä arvoilla lineaarisesti säätymään? Esim. kun sähkön hinta on 1c/kWh ohjaus olisi +1, sähkön hinta on 5c/kWh ohjaus olisi 0 ja sähkön hinta on 10c/kWh ohjaus olisi -1.
Tämä olisi varmaan käyttökelpoinen, mutta voi olla vaikea ehkä käyttöliittymän kautta saada helppokäyttöiseksi aloittelijalle. Lähinnä se, että eri henkilöillä voi olla eri määrä haluttuja asetuspisteitä. Joku haluaa saman määrän kuin sinä ja toinen haluaa 5c/kWh = ohjaus -0,8 ja 10c/kWh = -1. Jos joku keksii, että miten tämän esittäisi käyttöliittymässä ilman yamlin editointia kätevästi, niin voisin ympätä suoraan pakettiin. Muuten tulee ehkä kokeneemmille käyttäjille koodiesimerkiksi.

Kirjoitin Template-sensorin koodin, jolla saat haluamasi aikaiseksi. Alla esimerkki. Map-muuttujaan pitää kertoa hinta €/kWh ja haluttu ohjausarvo tuossa kohtaa. Välit koodi laskee automaattisesti sen perusteella. Eli luot Template -helperin käyttöliittymän kautta ja siihen tämä koodi, niin saat haluamasi ohjauksen ulos.

Python:
{# List of (price, output) values. Set first and last one to be far enough from actual expected values. Values in between points are calculated.  #}
{% set map = [
              (-1000, 1), 
              (0.01,  1),
              (0.05,  0),
              (0.10, -1),
              (1000, -1)
             ] | sort(attribute='0') %}

{% set value = states('sensor.shf_electricity_price_now') | float %}
{% set upper = (map | selectattr("0", 'gt', value) | list) %}
{% set lower = (map | selectattr("0", 'le', value) | sort(attribute='0', reverse=True)| list) %}
{{ (value-lower[0][0])*(upper[0][1]-lower[0][1])/(upper[0][0]-lower[0][0]) + lower[0][1] }}
 

Temez

Aktiivinen jäsen
Kirjoitin Template-sensorin koodin, jolla saat haluamasi aikaiseksi. Alla esimerkki. Map-muuttujaan pitää kertoa hinta €/kWh ja haluttu ohjausarvo tuossa kohtaa. Välit koodi laskee automaattisesti sen perusteella. Eli luot Template -helperin käyttöliittymän kautta ja siihen tämä koodi, niin saat haluamasi ohjauksen ulos.
Tähänhän voi nyt tietysti laittaa outputiksi suoraan vaikka asteita eikä arvoja -1 ja +1 välillä. Voi silloin työntää kyseisen arvon ilman helperiä vaikkapa automaatiossa climate.set_temperature-servicellä laitteen pyyntilämpötilaksi.
 

ederopaa

Jäsen
Saitko siis toimimaan vai jäikö vielä ongelmia? Koetan kuitenkin tähän alle kuvata vähän ohjeen tynkää kuvankaappauksin.

  1. Helperin luonti: Settings -> Devices & Services -> Helpers -> Button: Create Helper -> Date and/or time
    katso liitettä 88983
  2. Halvimman ajan laskenta: Settings -> Automations & scenes -> Button: Create automation -> Create new automation
    1. Ylälaidasta kolme pistettä -> Edit in YAML
    2. Kopioi kenttään täältä esimerkkikoodi: https://github.com/T3m3z/spotprices2ha/blob/main/example-of-cheapest-period-automation.yaml
    3. Ylälaidasta kolme pistettä -> Edit in visual editor. Pitäisi näyttää tältä:katso liitettä 88984
    4. Vaihda haluamasi triggeri tilalle.
    5. Muuta ensimmäistä scriptiä niin, että siinä on haluamasi alkuajankohta (huom! kannattaa miettiä suhteessa triggeriin), loppuajankohta ja tuntimäärä.
      1. Tämä esimerkiksi kello 16:55 triggeröitynä hakisi halvimman 2h jakson 17-21 väliltä.
        katso liitettä 88985
      2. Tämä taas hakee halvimman pätkän seuraavan 12h ajalta aloittaen seuraavasta tasatunnista:katso liitettä 88986
      3. Timedeltaa voi myös yhdistellä today_at-pätkiin. Tällä saa halvimman 3h pätkän alkaen seuraavasta tasatunnista huomiseen kello 18 asti. Huom! Jos huomisen hintoja ei ole saatavilla, niin sitten koodi palauttaa halvimman 3h pätkän saatavilla olevasta datasta.katso liitettä 88988
    6. Lopuksi korvaa viimeisessä kohdassa haluamasi helper target -> entity_id -kohtaan. Tässä esimerkissä HomeAssistant ehdottaa oikeaa entity_id:tä, kun alkaa kirjoittamaan input_datetime.wash...katso liitettä 88989
    7. Tallenna/save
  3. Nyt on helper olemassa ja automaatio, joka tietyn triggerin kohdatessaan laskee halutun pituisen pätkän alkuajankohdan. Viimeinen osuus on jonkin toimenpiteen käynnistys toisella automaatiolla. Sen voi tehdä näin:katso liitettä 88990

Tässä siis nyt kuvankaappauksin vähän ohjeentynkää. Toivottavasti saat toimimaan.

Tässä oli vähän ajatuksena, että näin tehtynä voit tehdä erilaisia helpereitä eri tarkoituksiin vaikka 10kpl etkä ole sidottu yhteen. Ja toisaalta jokainen voi määrittää halutun ajanjakson, jolta hinta haetaan. Jotkut haluavat sen olevan vuorokausi alkaen keskiyöstä, toinen vuorokausi alkaen kello15, kolmas taas 6h välein jne. riippuen käyttötarkoituksesta.
Moi @Temez ,

Palailen vielä tähän. Käytän tätä tosiaan latauksen aloittamiseen. Mulla logiikka on nyt semmoinen, että kun kytken auton laturiin automaatio tarkistaa onko aika ennen "lataustunteja". Jos aika on ennen lataustunteja sammuu laturi ja jää odottamaan halpoja tunteja. Se toimii hyvn jos aika on saman vuorokauden aikana aina klo 0:00 asti. Jos aika on seuraavana päivänä esim. klo 01:00 niin logiikka katsoo, että ollaan halvan ajan jälkeisessä ajassa ja antaa auton latautua. Oisko hyvää vinkkiä miten tuon sais paremmin toimimaan?

Ja iso kiitos tekemsätäsi työstä!
 

Temez

Aktiivinen jäsen
Moi @Temez ,

Palailen vielä tähän. Käytän tätä tosiaan latauksen aloittamiseen. Mulla logiikka on nyt semmoinen, että kun kytken auton laturiin automaatio tarkistaa onko aika ennen "lataustunteja". Jos aika on ennen lataustunteja sammuu laturi ja jää odottamaan halpoja tunteja. Se toimii hyvn jos aika on saman vuorokauden aikana aina klo 0:00 asti. Jos aika on seuraavana päivänä esim. klo 01:00 niin logiikka katsoo, että ollaan halvan ajan jälkeisessä ajassa ja antaa auton latautua. Oisko hyvää vinkkiä miten tuon sais paremmin toimimaan?
Hei! Voisitko laittaa nykyisestä automaatiosta vaikka pari kuvaa, jotta pääsisin kärryille, että millainen nykytoteutuksesi on?
Ja iso kiitos tekemsätäsi työstä!
Ollos hyvä :) Ei tämä paketti kaikille paras ole eikä suinkaan täydellinen, mutta onpahan yksi vaihtoehto lisää automatisointiin :)
 

Temez

Aktiivinen jäsen
Kirjoitin Template-sensorin koodin, jolla saat haluamasi aikaiseksi. Alla esimerkki. Map-muuttujaan pitää kertoa hinta €/kWh ja haluttu ohjausarvo tuossa kohtaa. Välit koodi laskee automaattisesti sen perusteella. Eli luot Template -helperin käyttöliittymän kautta ja siihen tämä koodi, niin saat haluamasi ohjauksen ulos.

Python:
{# List of (price, output) values. Set first and last one to be far enough from actual expected values. Values in between points are calculated.  #}
{% set map = [
              (-1000, 1),
              (0.01,  1),
              (0.05,  0),
              (0.10, -1),
              (1000, -1)
             ] | sort(attribute='0') %}

{% set value = states('sensor.shf_electricity_price_now') | float %}
{% set upper = (map | selectattr("0", 'gt', value) | list) %}
{% set lower = (map | selectattr("0", 'le', value) | sort(attribute='0', reverse=True)| list) %}
{{ (value-lower[0][0])*(upper[0][1]-lower[0][1])/(upper[0][0]-lower[0][0]) + lower[0][1] }}
Tein tästä Blueprintin Home Assistantiin. Seuraavan linkin takaa pitäisi onnistua importtaus, kunhan Instance URL on laitettu kohdalleen seuraavalla sivulla: https://my.home-assistant.io/redire...ub.com/T3m3z/93aa109b84eeb41659525bd195c14c7e

1699453871746.png
 

Pretor

Aktiivinen jäsen
Kivoja pikkuylläreitä taas HA:n päivityksen jälkeen, kun ei kaasu virtaa :D:
moorgaas.jpg


Miksi tuo muuten viittaa GAS-sensoriin (ja sitä myöten Clear/Detected), kun tuohan näytti olevan Power-sensori, jolla pitäisi olla ON/OFF tilat.

Viittaan siis tähän binary-sensor -dokumentointiin:

lisää edittiä:
Nyt vasta huomasin, että liiketunnistimetkin ilmoittelee tuon Clear -> Ei kaasua. Detected näkyy molemmissa suomentamattomana.
 
Viimeksi muokattu:

Temez

Aktiivinen jäsen
Kivoja pikkuylläreitä taas HA:n päivityksen jälkeen, kun ei kaasu virtaa :D:
...
lisää edittiä:
Nyt vasta huomasin, että liiketunnistimetkin ilmoittelee tuon Clear -> Ei kaasua. Detected näkyy molemmissa suomentamattomana.
Heh, no tämäpäs jännä. Mutta ei lie vaikuttane automaatioihin, joten lähinnä kosmeettinen juttu?
 

Temez

Aktiivinen jäsen
Tein tästä Blueprintin Home Assistantiin. Seuraavan linkin takaa pitäisi onnistua importtaus, kunhan Instance URL on laitettu kohdalleen seuraavalla sivulla: https://my.home-assistant.io/redirect/blueprint_import/?blueprint_url=https://gist.github.com/T3m3z/93aa109b84eeb41659525bd195c14c7e

katso liitettä 89933
Tämän pitäisi toimia nyt itseasiassa minkä tahansa "haluan muuttaa sensorin x numeerisen arvon muutamalla asetuspisteellä toiseksi arvoksi" -tapauksiin. Voisi vaikka vuorokauden keskilämpötilan perusteella vaihtaa sallittujen Rank-tuntien määrää tai jotain vastaavaa.
 

ederopaa

Jäsen
Hei! Voisitko laittaa nykyisestä automaatiosta vaikka pari kuvaa, jotta pääsisin kärryille, että millainen nykytoteutuksesi on?

Ollos hyvä :) Ei tämä paketti kaikille paras ole eikä suinkaan täydellinen, mutta onpahan yksi vaihtoehto lisää automatisointiin :)
Tässäpä noita on:

1699456970709.png
1699456979398.png

1699456987211.png
 

Temez

Aktiivinen jäsen
@ederopaa : onko sinulla sitten vielä jokin kolmas automaatio, joka aloittaa latauksen, kun halvimmat tunnit ovat menossa? Nyt minusta näyttää siltä, että kello 15 katsotaan halvin aika 15-06 välillä. Ja jos auton tullessa kotiin halvin aika on joko menossa tai mennyt, niin aloitetaan lataus. Vaikka oikeasti saattaakin olla niin, että halvin pätkä on 15-21 ja auto tulee kotiin 23, niin lataus aloitetaan vaikka halvin aika olisi jo mennyt? Ja toisaalta jos auto tulee kotiin kello 17:23 ja halvin aika alkaa 18:00, niin mikään ei tunnu käynnistävän latausta.

Mieleen tulee ainakin se, että kannattaa tarkistaa tuon input_datetime.car_charging_start on tyypiltään "Date and Time". Muutoin voi käydä niin, että automaatiot ja tarkastukset toimivat vuorokauden sisällä, mutta eivät seuraavan vuorokauden puolelle mentäessä. Esimerkkinä alta noiden Input Datetimejen käytöstä triggereinä ja eroista, jos esim. on pelkkä pvm tai pelkkä aika valittu helperiä luodessa:
1699466447552.png


Koetin puoliksi sokkona kirjoittaa sinulle automaation, joka tekisi nyt kaiken tarvittavan. Automaatio triggeröityy nyt joko auton mennessä laturiin tai jos aiemmin laskettu halvin 6h pätkä kotiintulon ja seuraavan aamukuuden välillä toteutuu alkaa. Jos auto tulee kotiin, niin lasketaan halvin ajanhetki ja talletaan se. Viiden sekunnin tauon jälkeen tarkistus, että auto on kotona. Jos on, niin tarkistetaan, että onko aiemmin laskettu ajanhetki mennyt vai ei. Jos on, aloitetaan lataus. Jos ei ole mennyt, niin stopataan lataus. Automaatio käynnistyy sitten myöhemmin uudestaan lasketun ajanhetken tullessa kohdalle. Ajankohtaa ei lasketa uudelleen, koska automaatio ei triggeröitynyt auton laturiin kytkemisestä.
YAML:
alias: Korolla charge at home 2
description: ""
mode: single
trigger:
  - trigger: plugged_in
    platform: device
    device_id: 9943b72f9079
    entity_id: 2dbe5e9b10d8
    domain: binary_sensor
    id: CarCameHome
    alias: Car came home
  - trigger: null
    platform: time
    at: input_datetime.car_charging_start
    id: StartCharge
    alias: Charging time started
action:
  - if:
      - condition: trigger
        id: CarCameHome
    then:
      - service: script.cheapest_hours
        data:
          start: "{{ now() - timedelta(minutes=30) }}"
          stop: "{{ today_at('6:00') + timedelta(hours=24) }}"
          hours: 6
      - service: input_datetime.set_datetime
        data:
          timestamp: "{{ result['start'] }}"
        target:
          entity_id: input_datetime.car_charging_start
    alias: >-
      Check if Car came just home. If yes, calculate cheapest period. Otherwise
      do nothing.
  - delay:
      hours: 0
      minutes: 0
      seconds: 5
      milliseconds: 0
    alias: >-
      Delay for just in case to allow Input Datetime to be set before
      proceeding.
  - alias: Check that Car is at home. If yes, continue. If not, do nothing.
    if:
      - condition: state
        state: home
        entity_id: device_tracker.korolla_location_tracker
    then:
      - alias: >-
          Check if charging start time has passed. If yes, start charge. If not,
          stop charge.
        if:
          - condition: time
            after: input_datetime.car_charging_start
        then:
          - type: turn_on
            device_id: 9943b72f9079885a12
            entity_id: 2995d4364c7a7914b9
            domain: switch
          - service: notify.mobile_app_ne2213
            data:
              message: Lataus aloitettu.
        else:
          - type: turn_off
            device_id: 9943b72f9079885a12
            entity_id: 2995d4364c7a7914b9
            domain: switch
          - service: notify.mobile_app_ne2213
            data:
              message: Lataus kytketty pois.

EDIT: toimivuutta en voi taata ja kirjoitusvirheitä voi olla. Kannattaa testata huolella.
 
Viimeksi muokattu:

ederopaa

Jäsen
@ederopaa : onko sinulla sitten vielä jokin kolmas automaatio, joka aloittaa latauksen, kun halvimmat tunnit ovat menossa? Nyt minusta näyttää siltä, että kello 15 katsotaan halvin aika 15-06 välillä. Ja jos auton tullessa kotiin halvin aika on joko menossa tai mennyt, niin aloitetaan lataus. Vaikka oikeasti saattaakin olla niin, että halvin pätkä on 15-21 ja auto tulee kotiin 23, niin lataus aloitetaan vaikka halvin aika olisi jo mennyt? Ja toisaalta jos auto tulee kotiin kello 17:23 ja halvin aika alkaa 18:00, niin mikään ei tunnu käynnistävän latausta.

Mieleen tulee ainakin se, että kannattaa tarkistaa tuon input_datetime.car_charging_start on tyypiltään "Date and Time". Muutoin voi käydä niin, että automaatiot ja tarkastukset toimivat vuorokauden sisällä, mutta eivät seuraavan vuorokauden puolelle mentäessä. Esimerkkinä alta noiden Input Datetimejen käytöstä triggereinä ja eroista, jos esim. on pelkkä pvm tai pelkkä aika valittu helperiä luodessa:
katso liitettä 89956

Koetin puoliksi sokkona kirjoittaa sinulle automaation, joka tekisi nyt kaiken tarvittavan. Automaatio triggeröityy nyt joko auton mennessä laturiin tai jos aiemmin laskettu halvin 6h pätkä kotiintulon ja seuraavan aamukuuden välillä toteutuu alkaa. Jos auto tulee kotiin, niin lasketaan halvin ajanhetki ja talletaan se. Viiden sekunnin tauon jälkeen tarkistus, että auto on kotona. Jos on, niin tarkistetaan, että onko aiemmin laskettu ajanhetki mennyt vai ei. Jos on, aloitetaan lataus. Jos ei ole mennyt, niin stopataan lataus. Automaatio käynnistyy sitten myöhemmin uudestaan lasketun ajanhetken tullessa kohdalle. Ajankohtaa ei lasketa uudelleen, koska automaatio ei triggeröitynyt auton laturiin kytkemisestä.
YAML:
alias: Korolla charge at home 2
description: ""
mode: single
trigger:
  - trigger: plugged_in
    platform: device
    device_id: 9943b72f9079
    entity_id: 2dbe5e9b10d8
    domain: binary_sensor
    id: CarCameHome
    alias: Car came home
  - trigger: time
    at: input_datetime.car_charging_start
    id: StartCharge
    alias: Charging time started
action:
  - if:
      - condition: trigger
        id: CarCameHome
    then:
      - service: script.cheapest_hours
        data:
          start: "{{ now() - timedelta(minutes=30) }}"
          stop: "{{ today_at('6:00') + timedelta(hours=24) }}"
          hours: 6
      - service: input_datetime.set_datetime
        data:
          timestamp: "{{ result['start'] }}"
        target:
          entity_id: input_datetime.car_charging_start
    alias: >-
      Check if Car came just home. If yes, calculate cheapest period. Otherwise
      do nothing.
  - delay:
      hours: 0
      minutes: 0
      seconds: 5
      milliseconds: 0
    alias: >-
      Delay for just in case to allow Input Datetime to be set before
      proceeding.
  - alias: Check that Car is at home. If yes, continue. If not, do nothing.
    if:
      - condition: state
        state: home
        entity_id: device_tracker.korolla_location_tracker
    then:
      - if:
          - conditions:
              - condition: time
                after: input_datetime.car_charging_start
        then:
          - type: turn_on
            device_id: 9943b72f9079885a12
            entity_id: 2995d4364c7a7914b9
            domain: switch
          - service: notify.mobile_app_ne2213
            data:
              message: Lataus aloitettu.
        else:
          - type: turn_off
            device_id: 9943b72f9079885a12
            entity_id: 2995d4364c7a7914b9
            domain: switch
          - service: notify.mobile_app_ne2213
            data:
              message: Lataus kytketty pois.
        alias: >-
          Check if charging start time has passed. If yes, start charge. If not,
          stop charge.

EDIT: toimivuutta en voi taata ja kirjoitusvirheitä voi olla. Kannattaa testata huolella.
Iso kiitos!!! Täytyy testailla.
 

Temez

Aktiivinen jäsen
Iso kiitos!!! Täytyy testailla.
Korjasin vielä koodista tuohon alkuperäiseen viestiin pari virhettä. Kunnon testiä en saanut nyt kuitenkaan sille tehtyä, joten ehkä joutuu tuota vielä korjaamaan ennen kuin saat automaation tallennettua. Visuaalinen editori onneksi kertoo ongelmista aika mukavasti noiden automaatioiden kanssa.
 

Temez

Aktiivinen jäsen
Täältä löytyis nyt omasta branchistaan pari blueprinttiä, joiden lyhyet kuvaukset tiedostojen sisällä description-rivillä: https://github.com/T3m3z/spotprices2ha/tree/blueprints/blueprints/automation/shf-spotprices2ha

Ovat huonosti testattuja, mutta jos jotakuta kiinnostaa kokeilla, niin tuolta kokeilemaan ja antamaan palautetta!

Homma toimii nyt beta-vaiheessa näin (myöhemmin kun saan Githubissa päähaaraan tämän, niin import onnistuu parilla napin painalluksella):
  1. Mene sivulle https://github.com/T3m3z/spotprices2ha/tree/blueprints/blueprints/automation/shf-spotprices2ha
  2. Avaa haluamasi blueprint
  3. Kopioi osoiteriviltä url
  4. Mene Home Assistantissa Settings -> Automations -> Blueprints -> Import blueprint
  5. Syötä vaiheessa 3 kopioitu URL ->Preview -> Import
  6. Avaa uusi Blueprint, syötä asetukset ja tallenna. Nauti! Myös bugit kuuluvat hintaan!
 
Täältä löytyis nyt omasta branchistaan pari blueprinttiä, joiden lyhyet kuvaukset tiedostojen sisällä description-rivillä: https://github.com/T3m3z/spotprices2ha/tree/blueprints/blueprints/automation/shf-spotprices2ha

Ovat huonosti testattuja, mutta jos jotakuta kiinnostaa kokeilla, niin tuolta kokeilemaan ja antamaan palautetta!

Homma toimii nyt beta-vaiheessa näin (myöhemmin kun saan Githubissa päähaaraan tämän, niin import onnistuu parilla napin painalluksella):
  1. Mene sivulle https://github.com/T3m3z/spotprices2ha/tree/blueprints/blueprints/automation/shf-spotprices2ha
  2. Avaa haluamasi blueprint
  3. Kopioi osoiteriviltä url
  4. Mene Home Assistantissa Settings -> Automations -> Blueprints -> Import blueprint
  5. Syötä vaiheessa 3 kopioitu URL ->Preview -> Import
  6. Avaa uusi Blueprint, syötä asetukset ja tallenna. Nauti! Myös bugit kuuluvat hintaan!
Kiitos mahdottoman hienosta avusta yhteisölle. .md fileenhän saisi suoran napin my home assistanttiin, niin ei tarvitsisi edes copy-pasteta. https://my.home-assistant.io/faq/

EDIT: Niin, mainitsitkin edellä että kun ehdit, niin nappulat syntyy...
 

Temez

Aktiivinen jäsen
Kiitos mahdottoman hienosta avusta yhteisölle.
:hattu: Jos kokeilet noita, niin anna toki palautetta. Eli mitä noista kokeilit, toimiko, oliko käyttö intuitiivista. Minusta tuntuu, että noiden blueprinttien avulla saa intuitiivisemmaksi noiden käyttämisen kuin mitä sillä, että pitäisi itse keksiä automaatiot nollista. En ollut vain aiemmin tajunnut, että noinhan ne esimerkki-automaatiot kannattaa tehdä, jotta niistä saa kopioitavia. Joskus kävi mielessä, että voisi tehdä kirjoitussuojatut automaatiot pakettiin pohjalle ja niistä sitten kopiota, mutta parempi tämä blueprint-systeemi on. Voi piilottaa taustalle kaikkea tärkeää, mutta käyttäjän näkökulmasta vaikeaa/epäoleellista.
.md fileenhän saisi suoran napin my home assistanttiin, niin ei tarvitsisi edes copy-pasteta. https://my.home-assistant.io/faq/

EDIT: Niin, mainitsitkin edellä että kun ehdit, niin nappulat syntyy...
Joo. Teinkin tänne jo valmiiksi ne napit, mutta osoittavat main branchiin. Eli tulevat sitten käyttöön, kun siirrän päähaaraan Githubissa nuo koodit ja muut hilavitkuttimet. Toivoisin ensin vain käyttökokemuksia esim. foorumilaisilta.
 

haraldh

Vakionaama
Minunkin on nostettava hattuni, aivan mahdottoman hienoja juttuja. En ymmärrä vielä pätkääkään Blueprinteistä, mutta se ei vähennä ollenkaan työtä mitä teette. Kiitos.

edit: Ilmeisesti voi tuolla shf-spotprices2ha Blueprintillä säätää *laitekohtaisesti* montako tuntia ja/tai hintarajan alla pitäisi olla päällä. Loistavaa!
 
Viimeksi muokattu:

Temez

Aktiivinen jäsen
edit: Ilmeisesti voi tuolla shf-spotprices2ha Blueprintillä säätää *laitekohtaisesti* montako tuntia ja/tai hintarajan alla pitäisi olla päällä. Loistavaa!
Joo, siellä kansiossa on tosiaan useampi blueprint, jotka tekee vähän eri asioita. Mutta tuolla "rank-automation.yaml"-tiedostolla onnistuu juurikin nuo rank/hintarajat.
 

Temez

Aktiivinen jäsen
Täältä löytyis nyt omasta branchistaan pari blueprinttiä, joiden lyhyet kuvaukset tiedostojen sisällä description-rivillä: https://github.com/T3m3z/spotprices2ha/tree/blueprints/blueprints/automation/shf-spotprices2ha

Ovat huonosti testattuja, mutta jos jotakuta kiinnostaa kokeilla, niin tuolta kokeilemaan ja antamaan palautetta!

Homma toimii nyt beta-vaiheessa näin (myöhemmin kun saan Githubissa päähaaraan tämän, niin import onnistuu parilla napin painalluksella):
  1. Mene sivulle https://github.com/T3m3z/spotprices2ha/tree/blueprints/blueprints/automation/shf-spotprices2ha
  2. Avaa haluamasi blueprint
  3. Kopioi osoiteriviltä url
  4. Mene Home Assistantissa Settings -> Automations -> Blueprints -> Import blueprint
  5. Syötä vaiheessa 3 kopioitu URL ->Preview -> Import
  6. Avaa uusi Blueprint, syötä asetukset ja tallenna. Nauti! Myös bugit kuuluvat hintaan!
Nämä blueprint-automaatiot ovat nyt testikäytössä pyörineet reilun vuorokauden minulla ja vaikuttaisivat toimivan. Jollei kuulu kummia, niin laitan ne lähipäivinä Githubissa main-haaraan.
 

Temez

Aktiivinen jäsen
Githubissa kyseltiin, että saisiko hinnat euroista senteiksi. Eurohinnat tulivat Mikin API:n tarjoaman datan kautta puolivahingossa. En lähtenyt tekemään muutosta, koska varmaan aika monella menisi kaikenlaista rikki muutoksesta.

Laittelin tästä nyt kuitenkin äänestystä pystyyn Githubissa emoji-reaktioilla: https://github.com/T3m3z/spotprices2ha/issues/20#issuecomment-1788814567

Osalla teistä ei välttämättä ole Github-tunnusta, joten tehdään tähän vastaava. Reagoi tähän viestiin seuraavasti:
- hinnat sentteinä olisi parempi: peukku ylös
- hinnat euroina parempi: Love/sydänsilmä-emoji
- ei väliä: Haha/itkunauru-emoji

Älkää äänestäkö kahdessa paikassa.
Tähän liittyen löytyikin mukavampi ratkaisu. HomeAssistant ei salli unif_of_measurement-kenttien templatointia, mutta YAMlissa onnistuikin ankkureilla ja aliaksilla syöttää esim. haluttu valuuttayksikkö kerralla useampaan paikkaan. Kts. tämä kommentti asiasta auki olevasta Issuesta: https://github.com/T3m3z/spotprices2ha/issues/20#issuecomment-1806187063
 

ederopaa

Jäsen
Korjasin vielä koodista tuohon alkuperäiseen viestiin pari virhettä. Kunnon testiä en saanut nyt kuitenkaan sille tehtyä, joten ehkä joutuu tuota vielä korjaamaan ennen kuin saat automaation tallennettua. Visuaalinen editori onneksi kertoo ongelmista aika mukavasti noiden automaatioiden kanssa.
Kuten epäilit, oli tosiaan vääränlainen date/time avustin, nyt uusi/oikea käytössä. Joku tässä tökkii, jota en ymmärrä. Lisäsin rivin "respose_variable: result". Herja, joka tulee on "Message malformed: extra keys not allowed @ data['action'][0]['then'][0]['respose_variable']".

YAML:
alias: Korolla charge at home 3
description: ""
mode: single
trigger:
  - alias: Car came home
    platform: device
    device_id: 9943b72f9079885
    domain: device_tracker
    entity_id: ccaf955597f6fbd
    type: enters
    id: CarCameHome
    zone: zone.home
  - trigger: null
    platform: time
    at: input_datetime.car_charging_start_2
    id: StartCharge
    alias: Charging time started
action:
  - alias: >-
      Check if Car came just home. If yes, calculate cheapest period. Otherwise
      do nothing.
    if:
      - condition: trigger
        id: CarCameHome
    then:
      - service: script.cheapest_hours
        data:
          start: "{{ now() - timedelta(minutes=30)}}"
          stop: "{{ today_at('6:00') + timedelta(hours=24)}}"
          hours: 6
        respose_variable: result
      - service: input_datetime.set_datetime
        data:
          timestamp: "{{ result['start'] }}"
        target:
          entity_id: input_datetime.car_charging_start_2
  - delay:
      hours: 0
      minutes: 0
      seconds: 5
      milliseconds: 0
    alias: >-
      Delay for just in case to allow Input Datetime to be set before
      proceeding.
  - alias: Check that Car is at home. If yes, continue. If not, do nothing.
    if:
      - condition: state
        state: home
        entity_id: device_tracker.korolla_location_tracker
    then:
      - alias: >-
          Check if charging start time has passed. If yes, start charge. If not,
          stop charge.
        if:
          - condition: time
            after: input_datetime.car_charging_start_2
        then:
          - type: turn_on
            device_id: 9943b72f907988
            entity_id: 2995d4364c7a79
            domain: switch
          - service: notify.mobile_app_ne2213
            data:
              message: Lataus aloitettu.
        else:
          - type: turn_off
            device_id: 9943b72f907988
            entity_id: 2995d4364c7a79
            domain: switch
          - service: notify.mobile_app_ne2213
            data:
              message: Lataus kytketty pois.
 

Temez

Aktiivinen jäsen
Kuten epäilit, oli tosiaan vääränlainen date/time avustin, nyt uusi/oikea käytössä.
Huomasin tässä, että Githubin ohjeisiin oli lipsahtanut se pelkkä ajan tallentava. Eli allekirjoittaneelta ohjeissa oli virhe. Siitä ehkä tullut sinullekin se virhe sitten?
Joku tässä tökkii, jota en ymmärrä. Lisäsin rivin "respose_variable: result". Herja, joka tulee on "Message malformed: extra keys not allowed @ data['action'][0]['then'][0]['respose_variable']".
Kirjoitusvirhe. Sen pitää olla "response_variable".
 

ederopaa

Jäsen
Huomasin tässä, että Githubin ohjeisiin oli lipsahtanut se pelkkä ajan tallentava. Eli allekirjoittaneelta ohjeissa oli virhe. Siitä ehkä tullut sinullekin se virhe sitten?
Kyllä se sieltä taisi tulla :)
Kirjoitusvirhe. Sen pitää olla "response_variable".
Katos vaan. Toi on helppo korjata, tulee näemmä sokeaksi noille.

No ei ihan poistunut, nyt tulee vielä "Message malformed: extra keys not allowed @ data['trigger']".

Tätä kohtaa kun testaa ajaa graafisesta editorista:

YAML:
service: input_datetime.set_datetime
data:
  timestamp: "{{ result['start'] }}"
target:
  entity_id: input_datetime.car_charging_start_2

Tulee virheilmoitus:

Virhe toimintoa suoritettaessa​

Error rendering data template: UndefinedError: 'result' is undefined

Sorry nää kyssärit...ja kiitos tosi paljon!
 

Temez

Aktiivinen jäsen
No ei ihan poistunut, nyt tulee vielä "Message malformed: extra keys not allowed @ data['trigger']".
Rivillä 13 taitaa olla ylimääräinen "trigger: null" -kohta. Ehkäpä tämmöinen voisi olla lähempänä?

YAML:
  - platform: time
    at: input_datetime.car_charging_start_2
    id: StartCharge
    alias: Charging time started

Virhe toimintoa suoritettaessa​

Error rendering data template: UndefinedError: 'result' is undefined
Tähän en osaa nyt kyllä oikein sanoa, että mitä se meinaa. Tuo response_variable-kohdan korjaaminen ei auttanut? EDIT: en huomannut eroa verraten tähän: https://github.com/T3m3z/spotprices2ha/blob/main/example-of-cheapest-period-automation.yaml

Sorry nää kyssärit...ja kiitos tosi paljon!
Ei mitään, kysyvä ei tieltä eksy :) Minulla vasteajat vaihtelevat välillä paljonkin, joten toivottavasti olet kärsivällinen. Koetetaan saada nyt tuo toimimaan sinulle. Yksi vaihtoehto voisi myös olla raapia tuosta nuo autoon liittyvät kohdat pois, jotta voitaisiin simuloida tuota ilman autoa = saisin sen toimimaan itselläni. Voisit sitten lisätä autoon liittyvät actionit myöhemmin.
 
Back
Ylös Bottom