HomeAssistant ja sähköpörssiohjaus

[marpelto]

Eli jos tätä Temezin lisäosaa käyttää, niin siellä on suoraan tuo "SHF Electricity price now" sensori euroina.

Hmm.."Temezin lisäosa" ?

Riittäisikö NordPool koodi configuration.yaml
price_in_cents: false


nordpool:

sensor:
- platform: nordpool
# Should the prices include vat? Default True
VAT: True
# What currency the api fetches the prices in
# this is only need if you want a sensor in a non local currency
currency: "EUR"
# Option to show prices in cents (or the equivalent in local currency)
price_in_cents: false
# Helper so you can set your "low" price
# low_price = hour_price < average * low_price_cutoff
# low_price_cutoff: 0.95
# What power regions your are interested in.
# Possible values: "DK1", "DK2", "FI", "LT", "LV", "Oslo", "Kr.sand", "Bergen", "Molde", "Tr.heim", "Tromsø", "SE1", "SE2", "SE3","SE4", "SYS", "EE"
region: "FI"
# How many decimals to use in the display of the price
precision: 3
# What the price should be displayed in default
# Possible values: MWh, kWh and Wh
# default: kWh
price_type: kWh

 

[marpelto]

Ainakin tuohon muuttui sentit EURoiksi

 

[Mikki]

Hmm.."Temezin lisäosa" ?

Taitaa olla Temezin YAML jo ohittanut monella tavalla Nordpool integraation aikaa sitten.

GitHub - 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.

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

 

[marpelto]

Taitaa olla Temezin YAML jo ohittanut monella tavalla Nordpool integraation aikaa sitten.

GitHub - 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.

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

Hianoa...itse aloittelin Home Assistantin kanssa. En ole kaikkeen perehtynyt.
Kokillaan tuotaa seuraavaksi..

 

[marpelto]

Noniin..hyvältä näyttää. Kiitos vaan vinkistä Mikki

 

[Kake]

Onpa mainio homma tää SHF! Olen varmasti tyhymä, mutta löytyykö jostain pikaohjetta parametrien käyttöön? Yritin oikeasti löytää githubista ja täältä, muttei osunut silmään

 

[Temez]

Onpa mainio homma tää SHF! Olen varmasti tyhymä, mutta löytyykö jostain pikaohjetta parametrien käyttöön? Yritin oikeasti löytää githubista ja täältä, muttei osunut silmään

Ei taida olla tosiaan noista kirjoitettu. Mutta koetetaanpa tässä nyt jotain vinkkiä antaa. Helpointa lienee parametrien ymmärtämiseen nähdä, että mitä ne tekevät. Eli seuraa ensin Githubin ohjetta, että saat ApexChartilla pörssisähkön hintakuvaajan näkyville. Sitten lisää uusi kortti samalla ohjeella, mutta tällä koodilla:

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

Voit sitten kokeilla, että millaisen kuvaajan se antaisi esim. tämän päivän hinnoilla. Pitäisi tulla joku tämmöinen suurinpiirtein:

SHF Control Function vaikuttaa vähän siihen, että miten jyrkästi tullaan maksimi- ja minimiarvoon. Ja käyrän jyrkkyyttä saa säädettyä SHF Control Funtion Factorilla. Yllä olevissa kuvissa vähän esimerkkiä, että miten arvot voisivat vaikuttaa.

Sellainen kommentti vielä, että tätä jatkuvaa ohjausta ei oikein oltu mietitty 100% loppuun asti eli voi olla pöljäkin toteutustapa minulta. Tämä ottaa nyt lähinnä huomioon vain hinnanvaihtelun suhteellisena verraten päivän maksimihintaan. Jos hinnat pyörivät vaikkapa 5-6 sentin paikkeilla koko päivän, niin kuvaaja kumminkin vetäisi ohjauksen nollaan päivän kalleimpina kohtina. Eikä toisaalta takaa, ettei kämppä pakkasilla menisi liian kylmäksi. Toisaalta eipä se kai haittaa, että aina kalleimmat hetket olisivat pienellä sähkönkäytöllä, kun silloin ehkä eniten saastuttavaa sähköntuotantoakin käynnissä? Ja kyllä tästä ehkä silti hyötyä on, että saa helposti ohjattua jonkin ohjattavan laitteen pyyntilämpötilaa korkeammaksi halvemmille hetkille (kunhan sitten tekee sen automaatiosäännön niin, että pysyy mukavissa lämpötiloissa itselle). Ehkä jokainen voi sitten tehdä lämpötilakompensoinnin tai hintakompensointia automaatiossa tähän päälle. Luulen, että käyttötapaukset tässä vaihtelevat niin paljon, etten siksi tehnyt kuin tuon -1 ja +1 sekä 0-1 välillä vaihtelevat anturit avuksi ja jokainen saa sitten siitä soveltaa.

Otan mielelläni palautetta vastaan.

 

[Kake]

Ei taida olla tosiaan noista kirjoitettu. Mutta koetetaanpa tässä nyt jotain vinkkiä antaa. Helpointa lienee parametrien ymmärtämiseen nähdä, että mitä ne tekevät. Eli seuraa ensin Githubin ohjetta, että saat ApexChartilla pörssisähkön hintakuvaajan näkyville. Sitten lisää uusi kortti samalla ohjeella, mutta tällä koodilla:

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

Voit sitten kokeilla, että millaisen kuvaajan se antaisi esim. tämän päivän hinnoilla. Pitäisi tulla joku tämmöinen suurinpiirtein:
katso liitettä 83152katso liitettä 83153katso liitettä 83154
SHF Control Function vaikuttaa vähän siihen, että miten jyrkästi tullaan maksimi- ja minimiarvoon. Ja käyrän jyrkkyyttä saa säädettyä SHF Control Funtion Factorilla. Yllä olevissa kuvissa vähän esimerkkiä, että miten arvot voisivat vaikuttaa.

Sellainen kommentti vielä, että tätä jatkuvaa ohjausta ei oikein oltu mietitty 100% loppuun asti eli voi olla pöljäkin toteutustapa minulta. Tämä ottaa nyt lähinnä huomioon vain hinnanvaihtelun suhteellisena verraten päivän maksimihintaan. Jos hinnat pyörivät vaikkapa 5-6 sentin paikkeilla koko päivän, niin kuvaaja kumminkin vetäisi ohjauksen nollaan päivän kalleimpina kohtina. Eikä toisaalta takaa, ettei kämppä pakkasilla menisi liian kylmäksi. Toisaalta eipä se kai haittaa, että aina kalleimmat hetket olisivat pienellä sähkönkäytöllä, kun silloin ehkä eniten saastuttavaa sähköntuotantoakin käynnissä? Ja kyllä tästä ehkä silti hyötyä on, että saa helposti ohjattua jonkin ohjattavan laitteen pyyntilämpötilaa korkeammaksi halvemmille hetkille (kunhan sitten tekee sen automaatiosäännön niin, että pysyy mukavissa lämpötiloissa itselle). Ehkä jokainen voi sitten tehdä lämpötilakompensoinnin tai hintakompensointia automaatiossa tähän päälle. Luulen, että käyttötapaukset tässä vaihtelevat niin paljon, etten siksi tehnyt kuin tuon -1 ja +1 sekä 0-1 välillä vaihtelevat anturit avuksi ja jokainen saa sitten siitä soveltaa.

Otan mielelläni palautetta vastaan.

Juu kyllä mun mielestä tässä kovastikin ideaa on! Mulla on pörssisähköön siirtyminen edessä mahdollisesti vasta maaliskuussa, mutta tässä on nyt hyvin aikaa koeponnistaa eri ohjaustapoja. Käyttökohteita löytyy kattolämmityksestä lattialämmitykseen ja ILP:iin (no lattialämmitystermarit vielä tulossa postissa mutta kumminkin). Kattolämmityksessä varmasti hyöty minimaalinen, mutta lattioiden varaaminen tuntuis hyvältä ajatukselta, samoin ILP:in pyyntilämpötilan nosto asteella jos tietyt ehdot täyttyy.

Tuo kuvaaja jo selkeyttikin toimintaa, kiitos siitä. Ajatus on siis, että nykyiseen pyyntilämpötilaan lisätään tuo "Ohjaus"? Omalla kohdalla tuossa tulee ensimmäinen haaste, kun huonetermarit ymmärtää vain asteen tarkkuutta. Toki tuon voi pyöristää koodilla, mutta voisiko ohjaukselle olla jo valmiiksi olemassa helper joka kertoo desimaalitarkkuuden, mun tapauksessa pienin mahdollinen säätö olisi 1 aste.

 

[Temez]

Ajatus on siis, että nykyiseen pyyntilämpötilaan lisätään tuo "Ohjaus"? Omalla kohdalla tuossa tulee ensimmäinen haaste, kun huonetermarit ymmärtää vain asteen tarkkuutta. Toki tuon voi pyöristää koodilla, mutta voisiko ohjaukselle olla jo valmiiksi olemassa helper joka kertoo desimaalitarkkuuden, mun tapauksessa pienin mahdollinen säätö olisi 1 aste.

Joo. Automaatioissa Templatella onnistuu tosiaan pyöristykset ja ohjaukset. Tai siis Templateja joutuu kuitenkin käyttämään, kun ei muuten onnistu käsittääkseni automaatiossa käsky "aseta ILPin tavoitelämmöksi anturin X arvo". Siihen ei kauhean paha rasti ole lisätä Templatella sitten suoraan offsettia (esim. 20 pohjalämmöksi) ja kerrointa tuolle "Ohjaukselle" (esim. 2*ohjausarvo, jolloin ulos tulisi lukuja 0-2) eli esim. jotain tämmöistä (huomioi, että aiemmasta esimerkistä poiketen tässä kuvassa offset=22 ja ohjausanturiksi valittu versio, jonka arvo vaihtelee -1 ja +1 välillä, jolloin tuo antaa kokonaislukuja 20-24 välillä riippuen hinnasta):

Tuosta saisi hiukan yksinkertaisemman, jos tekisi UI:n puolella pari helperiä (offset, kerroin, pyöristysvalinta), mutta edelleen pitäisi tehdä tuo Template silti samalla tavalla automaation puolelle muotoon:

data:
  temperature: "{{ states('sensor.some_sensor') | float }}"

Että onko hirveä ero sitten?

 

[heebo1974]

Nyt olisi price_margins-haarassa tämmöinen koeversio: https://github.com/T3m3z/spotprices2ha/tree/price_margins

Pitäisi olla yhteensopiva muiden toteutusten kanssa eli jos et laita Price1- tai Price2-arvoja ja Price2:sen start/stop-aikaleimoja, niin toimii kuten ennenkin.

Edit: Rank ei nyt seuraa noita lisämaksuja vaan perustuu ihan puhtaasti Mikin API:n antamaan tietoon energianhinnan perusteella.

Hmm. Minulta meni vähän ohi tämä lisämaksu osio ? Onko tarkoitus ympätä sähkönsiirrot mukaan vai mitä näillä oli tarkoitus tehdä ?

 

[Temez]

Hmm. Minulta meni vähän ohi tämä lisämaksu osio ? Onko tarkoitus ympätä sähkönsiirrot mukaan vai mitä näillä oli tarkoitus tehdä ?

Joo, tämähän se oli eli saat yö/päiväsiirrot ja sähköyhtiön marginaalin mukaan. Päivän aikana tosin hinnat vaihtelee niin paljon, ettei ehkä isoa eroa tällä saa ohjauksiin, mutta voi se johonkin hintarajaan tai ehkä siihen "n halvinta peräkkäistä tuntia" ehkä vaikuttaa tunnin johonkin suuntaan.

 

[marpelto]

Moi...pieni sivukysymys
Minulla on omat 3-vaihe kWh laskurit MLP:lle (sensor.energy_mlp) ja sähköauton lataukselle (sensor.energy_ev).
Kuinka voin laskea lämpöpumpun/EV:n käyttämän sähkön hinnan per tunti?


Esim. sensor.energy_mlp * sensor.shf_electricity_price_now
sensor.energy_ev * sensor.shf_electricity_price_now

 

[Ville-Veikko]

Moi...pieni sivukysymys
Minulla on omat 3-vaihe kWh laskurit MLP:lle (sensor.energy_mlp) ja sähköauton lataukselle (sensor.energy_ev).
Kuinka voin laskea lämpöpumpun/EV:n käyttämän sähkön hinnan per tunti?


Esim. sensor.energy_mlp * sensor.shf_electricity_price_now
sensor.energy_ev * sensor.shf_electricity_price_now

Itse tein vastaavan virityksen siirtohintakustannuksen laskemiseen. Ensin tein Utility Meter -helperin energialle. Se nollataan tunneittain. Tuo pöljä käyttöliittymä ei anna muuttaa nollausjaksioa jälkikäteen niin kannattaa laittaa kerralla oikein. No voihan noita olla useita eri ajanjaksolle.

Sitten vaan kertoman omaan sensoriinsa kilowatit yksikkohinnalla niin saat tuntikohtaisen kustannuksen.

    yleissiirtokulu:
      unique_id: "380"
      friendly_name: yleissiirtokulu
      device_class: monetary
      unit_of_measurement: "snt"
      value_template: " {{states('input_number.yleiss_hinta') | float * states('sensor.tunninenergia') | float}}"

HOX! graafeja värkätessä kannattaa laittaa group_by max ja sama ajanjakso kuten utility sensorissa, muuten arvot on puutaheinää. Esimerkikisi näin.

 

[Temez]

Päädyin koodailemaan eilen illalla. Ei ole vielä täysin valmista, mutta minikevytversio tuosta Fission tyyppisestä ohjauksesta tai siis tosiaankin pikkuosa siitä (ja on vielä aika kämäinen, mutta julkaisen silti tänne, jos tästä olisi jollekin iloa). Jinja2:sen rajoituksista johtuen piti hiukan soveltaa, että sai aikaan tämän, mutta ehkä tämä tyhjää parempi on?

Toisessa ketjussa oli puhetta Fission korvaamisesta. Koetin eilen huvikseni kokeilla, että saisiko sitä "ohjaus halvimmille tunneille monella eri lämmittimellä" ja jotain alkua voisi tuossa olla.

 

[Ville-Veikko]

sensor. yaml on ihan oikea paikka. Sori jäi 2 riviä pois kun mulla on pitkä rivi noita template sensoreita ja tuo esimerkki oli listan keskellä. Muistaakseni HA tukee kahta tapaa miten tiedoston rakenne on joko toistat platformin joka sensorille tai sttien listaat tyypeittäin samat sensorit yhteen kuten minä tässä nyt. Mä olen laittanut nuo unique_id arvot käsin noihin (oma numerosarja / konfiguraatiotiedosto) tarkistas ettei mene olemassa olevien päälle.

kokeileppas tätä:

- platform: template
  sensors:
    yleissiirtokulu:
      unique_id: "380"
      friendly_name: yleissiirtokulu
      device_class: monetary
      unit_of_measurement: "snt"
      value_template: " {{states('sensor.shf_electricity_price_now')| float * states('sensor.tunninenergia') | float}}"

 

[marpelto]

hahhaa..kerkesin just poistamaan viestin..kun kekkasin itsekin.
ja tuli muuten ihan samalla lailla

 

[marpelto]

Pitääköhän odotella tunti, ennekuin sensor näyttää mitään..
Nyt on "Unavailable"

--- ääh. Huomasin vian

 

[Ville-Veikko]

Todennäköisesti se alkaa näyttämään jotain vasta ekan tunnin jälkeen. Mitäs se tuolla states sivulla kertoo, onko collecting -tilassa?

 

[aol]

Tapahtuiko jouluaattona jotain erityistä, kun täällä kolmen eri HA instanssin pörssisähköohjaus meni jumiin? Kaikissa tässä threadissa mainittu lisäosa. Kaikki tokeni rebootilla, mutta siihen asti kaikki olivat jääneet jumiin "kalliin pörssisähkön tilaan". Graafi oli tyhjä ja pörssiohjauksen sensorit sanoivat "unavailable". Yksi HA instansseista oli jumissa vielä joulupäivänä kunnes viimein pääsin reboottaamaan sen.

 

[Mikki]

Rajapinnoissa oli kyllä pieni katko iltapäivästä eilen. Oli pieni bugin poikanen jonka korjasin. Olisiko osunut päivitys juuri skriptin päivityshetkeen?

Mutta sinänsä tuota voisi varmaan tutkaista mitä tuo tekee jos esim. Vaihtaa väärän API osoitteen... Esim. Sen URLin lopun vaihtaa joksikin xyz että API antaa 404 koodia. Jos kutsu epäonnistuu niin pitäisihän sen toipua kun API taas vastaa?

 

[Ville-Veikko]

Jotain häikkää on. Ilmeisesti aattona klo 14 jälkeen toimiva automaatio ei ollut saanut ladatua tämän päivän hintadataa. Käynnistin Home Assistantin aamulla uusiksi -> korjaantui. Tänään oli ilmeisesti sama ongelma päällä, noin tunti sitten (klo 14:32) ajoin käsin Automaation "Intelligent update of electricity price sensor" ja huomisen hinnat ilmmantuivat graafeille.

 

[Mikki]

Hinnat tulee EntsoEstä usein vasta muutaman minuutin yli 14:00. Tänään näyttäisi 14:03 tulleen lokille että hinnat tuli. Onko tuossa HAssa tasan 14:00 haku? Enpäs ole tarkkaan katsonut miten se tekee sen.

 

[Ville-Veikko]

Jos tuon oikein tulkitsen niin random delay 30 -300 sek. Eli voi huonolla tuurilla tulla kysely liian äkkiä?

 

[heebo1974]

Joku häikkä eilen tosiaan oli. Ajelin tuota intelligent updatea useaan otteeseen 14 jälkeen. Hmm. Olikohan että vasta joskus klo 16 aikaan sain datan ladattua.

 

[Mikki]

Mitäs tuo "states" juttu tarkistaa, joka keltaisella on?

Ja tosiaan entäs tuo "Hours". Jos se on aina tasan 14:00, niin voisi olla hyvä että se olisi vaikka 14:03. Onnistuuko? Ja tuo random-osuus vaikka range(0,120)|random ... pari minuuttia hajontaan riittää hyvin.

 

[Temez]

Mites pitkään @Mikki vikatilanne oli päällä? Minullakin instanssi valitteli huonoja tuloksia, mutta toipui itsestään illalla.

Hakuajankohtaa ja intervallia voidaan muuttaa kyllä, jos jokin muu ajankohta parempi. Poikkeustilanteiden osalta testausta on suoritettu lähinnä vain niin, että poikkasin netin itseltä ja sitten ajoin päivitystä ja katsoin, että toipuu siitä.

Mitäs tuo "states" juttu tarkistaa, joka keltaisella on?

Sensor.shf_idx:n tila, joka kertoo, että pitääkö hinnoista alkaa katsomaan indeksiä 0 vai 24 alkaen. Kun lataus tapahtuu nyt kerran päivässä, niin tuo idx sitten toimii helperinä monessa paikassa, että saa oikean vuorokauden hinnat.

Ja tosiaan entäs tuo "Hours". Jos se on aina tasan 14:00, niin voisi olla hyvä että se olisi vaikka 14:03. Onnistuuko? Ja tuo random-osuus vaikka range(0,120)|random ... pari minuuttia hajontaan riittää hyvin.

Joo, nyt se automaatio ajetaan tunnin välein. Conditionissa on tarkistus sitten siitä, että milloin sitä oikeasti tarvitsee ladata (mm. rajoitus, että vasta kello 14 jälkeen ja jos sensorissa ei ole riittävästi dataa). Jos haluaa laittaa menemään aina 15 yli, niin hours alle lisää "minutes: 15".

 

[Mikki]

Tuo ongelma oli klo 14-16 välillä. Sorruin vähän "If it aint'broken, dont fix it" juttuun. Vähän vaikea sanoa tarkkaan aikaa kun api ei ollut alhaalla vaan osa requesteista epäonnistui.

Rakensin APIn taustalle entistä tukevamman cachen ja siinä kävi pieni koodauserhe ja C# HttpClientti tietyin välein jumitti ja boottasi API instanssin (Azure functionin), joita on kuormasta riippuen 2-10 kerrallaan ajossa. Mutta nyt pitäisi olla aika tukeva, kun bugi on korjattu.

Tähän HA yamliin sanoisin että tee @Temez tai joku muu hyvä retry-systeemi vain jos joku requesti feilaa. Nyt raja per IP osoite per API on 150 requestia tunnissa. Joten jos logiikan tekisi niin että HA päivittää klo 14 jälkeen vaikka 5 min välein kunnes tiedot on saatu... olisi täysin ok.

Pienikin "random" tekijä toki on hyvä kun kellot tuppaa olemaan kaikilla synkassa

 

[Temez]

Pitääpä tässä lähipäivinä katseskella, ei ole iso muutos. Voi mennä muutama päivä ennen kuin saan tehtyä, kun nyt poissa koneen äärestä. Ja samalla pitäisi sitä virheenkäsittelyä parantaa myös noin yleensäkin siellä HA:n päässä

 

[Mikki]

Ei muuta kuin joku HA guru tekemään PRää Temezille niin ei tarvi yksin koodailla. Huominen on kuitenkin joutilas päivä useimmille.

 

[villho]

Huikeasti kiitoksia tämän toteutukseen osallistuneille. Piti rekisteröityä foorumille, jotta pääsen erikseen kiittämään ja kommentoimaan.

Oma setuppi:

• HA:n ohjaamana käytetään meidän maalämpöpumppua. Tällä hetkellä, nykyisellä sähkösopparilla tosin yksinkertaisesti vain niin, että lämmitysveden tuottaminen sallitaan halvemmalla yösähköhinnalla (sekä siirto- että sähkösopparissa omat hinnat näille), eli toteutus on helppo, koska vuorokaudessa on vain kaksi kiinteää ajankohtaa: toinen lämmityksen sallimiselle ja toinen sen kieltämiselle.
• Ensi syksynä siirryttäneen pörssisähköön, joten valmistelen HA:ta siihen, että se osaa pyöritää MLP:a vuorokauden halvimpana ajankohtana tarvittavan ajan. Tarvittava aika määräytyy seuraavan päivän lämpötilaennusteesta. Logiikka ja automaatiot tälle on jo käytännössä tehty (kiitos tuon SHF-paketin) - nyt vain seuraan, miten logiikka toimii.

Minulla on tuo SHF-paketti asennettuna ja saanen sillä toteutettua haluamani, mutta havaitsin yhden outouden (bugi?) tänään. SHF haki uudet hinnat seuraavalle vuorokaudelle ja tämä triggeröi omassa setupissani laskennan tarvittaville lämmitystunneille seuraavaksi vuorokaudeksi (syötteenä lämpötilaennuste ja tämän taakse portaittain määrätty lämmitystuntien määrä).

Tämä laskenta päivitti lasketun tuntilukeman "SHF Cheapest period hours":iin, minkä jälkeen oli tarkoitus ottaa MLP:n käyttölogiikalle pumpun sallittu käynnistymisajankohta "SHF Cheapest period start":ista. Outous tulikin siinä, että tämän jälkeen "SHF Cheapest period start" antoi kellonajan, mikä on menneisyydessä. Sinänsä se teki homman ihan oikein, koska pörssihinta viime yönä oli tulevaa yötä edullisempi, eli tuntihintoja sokeasti katsottaessa halvin ajanjakso antamilleni tunneille tosiaan alkoi jo viime yönä, mutta kun haluan ohjata MLP:n käynnistymistä aina kertaalleen vuorokaudessa (käytännössä laskea seuraavan käynnistymisajankohdan aina seuraavan vuorokauden pörssihintojen tultua saataville), minua ei auta, että ehdotettu MLP:n käynnistymisajankohta onkin menneisyydessä.

Eli olisiko tuohon mahdollista saada logiikkaa, että kun "SHF Cheapest period start" lasketaan uudelleen, olisi palautettava ajankohta aina tulevaisuudessa (aikaisintaan seuraava tasatunti)? Vai onko logiikassa tälle jo joku mahdollisuus, minkä olen vain missannut?

Homma on tietysti kimurantti, jos "SHF Cheapest period hours" annetaan niin suuri arvo, että ajanjakso menee pidemmälle kuin mitä pörssisähkön hinta on tiedossa...

 

[Temez]

Eli olisiko tuohon mahdollista saada logiikkaa, että kun "SHF Cheapest period start" lasketaan uudelleen, olisi palautettava ajankohta aina tulevaisuudessa (aikaisintaan seuraava tasatunti)? Vai onko logiikassa tälle jo joku mahdollisuus, minkä olen vain missannut?

Hyvä ehdotus, tätä pitänee parantaa. Vähän pitäisi ehkä miettiä, että mikä olisi sopivin logiikka. Nyt tosiaan aloitusajankohdaksi voisi tulla mikä tahansa ajankohta tiedossa olevien hintojen alusta loppuun asti. Olisiko se sitten niin, että lataushetken jälkeen halvin pätkä, joka voi siirtyä esim. seuraavalle päivälle seuraavan latauksen yhteydessä, jos silloin on halvempaa?

(Ja kiitos kiitoksista!)

 

[villho]

Olisiko se sitten niin, että lataushetken jälkeen halvin pätkä, joka voi siirtyä esim. seuraavalle päivälle seuraavan latauksen yhteydessä, jos silloin on halvempaa?

Niin, mielestäni tuon pitäisi mennä tosiaan juuri noin, että sillä hetkellä, kun koodia pyydetään tarjoilemaan halutun mittainen halvin yhtenäinen jakso, se tarjoilee sen vain tulevaisuuden tunnettujen tuntien sisältä. Eli alkaen aikaisintaan seuraavasta tasatunnista, päättyen viimeistään tuolla hetkellä viimeiseen hinnaltaan tunnettuun tuntiin.

Jos pyydetyn ajanjakson pituus on lyhyempi kuin hinnaltaan tunnettujen tuntien määrä, logiikka on suoraviivainen. Mutta jos pyydetään vaikkapa halvinta yhtenäistä 12 tunnin jaksoa ja hintoja on tiedossa vain seuraaville 10 tunnille, niin tuolloin käytös voisi olla vaikkapa niin, että vaikka käyttäjä syöttääkin liukusäätimellä "SHF Cheapest period hours" arvon 12, niin koodi vaihtaa sen automaattisesti 10:een ja sen jälkeen antaa "SHF Cheapest period start":ssä seuraavan tasatunnin ajankohdan (koska hintoja tiedossa vain seuraavalle 10 tunnille, eli kaikki tunnetut tunnit pitää hyödyntää).

Ohjeena paketin käyttäjille voisi tällöin olla, että mikäli koodin haluaa tarjoilevan vähänkään pidempää käyttöjaksoa tulevalle ~vuorokaudelle, kannattaa tuo laskenta suorittaa heti uusien hintojen tultua saataville. Myöhemmin tuntihintoja ei välttämättä ole tiedossa tarpeeksi pitkälle pidempää käyttöjaksoa pyydettäessä.

***

Sivumainintana: itse ajattelin hyödyntää pakettia mahdollisesti myös sähköauton lataamisessa; ensiksi HA:lle kerrotaan haluttu prosenttilisäys auton akkuun (taustalla pitää tietysti olla tieto, paljonko prosentteja saadaan / tunti), HA laskee sitten tarvitun latausajan, mikä tarjoillaan tuolle SHF-paketille ja vastauksena saadaan latauksen aloitusaika. Tässä hommaa vaikeuttaa se, että latauksen halutaan usein olevan valmis esim. klo 7.00. Jos tiedossa on kuitenkin tuulinen päivä, voi pörssisähkön hinta olla halvempi vasta päivällä.

Eli jos pakettia haluaa kehittää vielä enemmän, niin siinä voisi olla yhtenä käyttäjäsyötteenä kellonaika (tasatunti), mikä on käyttöjakson takarajana, sanotaan tätä vaikkapa "SHF Cheapest period deadline":ksi. Omassa tapauksessani tuo menisi seuraavasti:

1. Käyttöjakson päättymisen takaraja syötteenä "SHF Cheapest period deadline": esim. "7:00", mikäli latauksen pitää olla valmis klo 7.
2. "SHF Cheapest period hours" syötteeksi HA:n laskemana (tälle oma logiikkani) vaikkapa "4" tuntia
3. Mikäli käyttöjakson päättymisellä ei olisi rajoituksia, halvin 4 tunnin käyttöjakso voitaisiin hyvinkin saada vasta myöhemmin aamupäivällä/päivällä, mutta koska käyttäjä on valinnut takarajaksi "7:00", niin SHF tarjoilee alkamisajan nykyhetken ja seuraavan klo 7:00:n välillä, sanotaan vaikkapa 2:00-6:00
4. "SHF Cheapest period start" saa arvon "28.12.2022 4:00:00" seuraavalle päivälle.

Tämä ylläoleva on kuitenkin täysin nice-to-have:ä, ja toimikoon vain ideana jatkokehitykselle. Jo nykyisellään tuo on todella hyvä setti - etenkin, jos tuo aiemmin esille tuomani asia on mahdollista saada muutetuksi.

 

[Ville-Veikko]

Kannattaakos tuon auton kohdalla välittää akun varaustasosta pätkääkään? Ainakaan jos käytössä on hybridi, tai arkiajossa tulee niin vähän ajoa et vuorokauden pari halvinta tuntia riittää lataamaan akun joko täyteen tai niin paljon että selviää seuraavaan halpaan jaksoon? Itse aktivoin laturin joka päivä kahdelle halvimmille tunneille, auto ottaa virtaa jos akkuun sopii...

 

[Sukke]

Omassa räpellyksessä on lähinnä odoteltu odottamattomia bugeja ja tehty pieniä viilauksia. Tarkastelu on nyt tunneittain tiedossa tuntihintojen loppuun saakka, mutta historiaa otetaan mukaan, jos tuntihintoja on jäljellä alle 24 (tarkastelujakson pituus minimissään 24 h). Alla muutama kuva tältä päivältä ennen ja jälkeen uusien tuntihintojen. Kuvat taas jostain syystä hieman suttuisia, vaikka ennen lähetystä näyttää terävältä.

Tuntivalinta näyttäisi suurin piirtein toimivan, vaikka en aina tiedä miksi tai miksi ei. Tässä käytetään hyväksi muita HA:n tietoja, jotka päivittyvät aina tunnin alussa ja siitä on pientä murhetta tämän osalta, kun tiedot voi tarkastelutunnin alussa olla "vanhentuneita". Täytyy ehkä muutella jotain tai paljonkin lopulliseen versioon. Tästähän puuttuu edelleen laitteen ohjaus kokonaisuudessaan, mutta ei ole vielä laitettakaan... Antaa tämän nyt ruksuttaa niin tulee virheitä esiin ja on jotain, jonka pohjalta tehdä jatkokehitystä (ja harrastaa...).

Spoiler: HA ja tuntivalinta

Lila toteuma osoittaa lämmitystunteja ja sinertävät palkit käynnissä olevaa / tulevia lämmitystunteja. Tarkastelu on tiedossa olevien tuntihintojen loppuun. Lämpötilaennusteen perusteella arvioitu sallittujen tuntien määrä on 9,9 h/vrk. Koska koko yö on yhtenäisesti sallittuja tunteja on tuntimäärä täyttynyt. Jäljellä olevat palkit (arvona 2) kuvaa tuntihinnan perusteella (alle 15 c/kWh) mukana olevia tunteja. Jos halpoja tunteja ei olisi, ei palkkeja olisi lainkaan näkyvissä.

Jakson sallittujen tuntien keskihinnassa on ollut hieman häikkää, sen taisin tämän kuvan jälkeen korjailla (mukana oli vain tulevat pakolliset lämmitystunnit, ei lainkaan menneitä).

Uudet tuntihinnat saapuneet. Jakson ennustettu lämpötila pienentynyt ja tuntitarve / vrk vähentynyt. Jokin tieto ei ollut HA:ssa vielä uusien tuntihintojen jälkeen päivittynyt, joten tuntitarve on vielä nollissa. Tiedot tässä siis sikäli virheelliset. Pitäisi selvittää, mikä tieto viivästyttää päivittymistä. Nyt tasatunti + 5 minuuttia päivitys on osittain vanhoilla tiedoilla ja aiheuttaa itselleni hieman päänvaivaa. Sallitut tunnit (palkit arvoihin 2 ja 3,5) tulee tuntihintojen ei arvioidun lämmitystarpeen perusteella.

Lämmitystarve ja "suunnitelma" päivittynyt. Tuon suunnitelman perusteella ei ohjausta varsinaisesti tehdä kuin kuluvan tunnin osalta, loppu on vain visualisointia varten. Jokaisen tunnin kohdalla ohjaus ajetaan uudelleen päivitetyillä tiedoilla. Apexcharts-cardin extremas ei jostain syystä toimi.

Tässä näkyy pieni omituisuus, kun kalliiden tuntien aikana ei ole lämmitystä, mutta tuntitarve kuitenkin pikkuhiljaa pienenee (kaksi ensimmäistä palkkia muuttuneet "vapaaehtoisiksi" lämmitystunneiksi eli ovat mukana hinnan vuoksi). Tavallaan nykyinen tarkastelu unohtaa menneen lämmityksen, kunnes tuntihintoja on taas alle 24 jäljellä. Ehkä se historia pitäisi pitää mukana vähintään -12 h verran. Toisaalta ei ennen uusiakaan lähtötietoja ollut pakollisia lämmitystunteja luvassa jäljellä olevien tuntihintojen aikana (ensimmäinen kuva) - palkit olivat vain halpojen tuntien vuoksi mukana.

Tästä myös nähtävissä, että seuraavaan iltaa olisi pitkä tauko odotettavissa, jos kolmea halvan hinnan (alle 15 c/kWh) tunteja ei olisi mukana. Tuo sallittu katko ja 8 h iskee siinä vaiheessa, kun 8 h tauko uhkaa tulla vastaan.

Tässä vielä hahmotelmaa käyttäjän säätimistä.

 

[anssi99]

Isot kiitokset kaikille jotka SHF:ää kehittelevät. Itselle ei YAML ole kovin tuttu ja ohjelmointi muutenkin on ollut pari kymmentä vuotta tauolla, niin en ihan omilla kyvyillä saanut täydellistä toteutusta aikaan. Eli neuvoa kaipaisin, kun haluan ohjata lämmitykset kovemmalle teholle pörssisähkön halpojen tuntien ajaksi. Ja päälle kytkennässä onnistuinkin automaation avulla. Mutta nyt en keksi miten palaisin halpojen tuntien jälkeen normaalilämmitykseen? Miten toteuttaisi triggerin, joka kertoisi halpojen tuntien päättyneen?

 

[villho]

Kannattaakos tuon auton kohdalla välittää akun varaustasosta pätkääkään?

Meillä on kaksi sähköautoa, joita tyypillisesti ladataan yön aikana 60 %:iin, millä selvitään tulevan päivän tavallisista max. 150 km ajoista ilman sen suurempia miettimisiä. Jos seuraavana päivänä on tiedossa enemmän ajoa, niin tarvetta voikin olla esim. 80-90 % varaustasolle aamulla lähtiessä. Tällöin voisi tilanne mennä niin, että kun iltasella palaa kotiin, autossa vaikkapa 30 % ja tarvitsee aamulla akussa 80 %, niin HA:lle voisi syöttää tiedon, että tarvitsee +50 %-yksikköä varausta akkuun, HA laskee tuohon tarvittavan latausajan, valitsee tulevilta tunneilta slotin ja ohjaa laturit antamaan virtaa tuolloin.

Nykyisellään kiinteistössä ei ole lataukselle kuormanhallintaa, vaan kumpikin auto ladataan yön aikana kolmesta vaiheesta 8 ampeerilla (5,5 kW / auto). Tämä on riittänyt aina hyvin, koska autoille ei tule koskaan tilanteita, että kotiin saavutaan todella myöhään täysin tyhjällä akulla, minkä pitäisi olla taas aamulla varhain piripinnassa täysi. Meidän 25 A pääsulakkeetkin riittävät tälle hyvin, vaikka MLP tekisi legionellakuumennustakin samanaikaisesti (max. ottoteho vastuksille säädetty 4 kW).

Mikäli vielä tulevaisuudessakin tulee olemaan pörssisähköhinnoiltaan hulluja aikoja, voisi olla järkevää nostaa pääsulakkeiden koko 35 ampeeriin ja samalla nostaa autojen latausvirtaa. Tällöin on mahdollista ladata autot tarvittavaan tasoon lyhyemmässä ajassa (lue: vain muutaman halvan pörssisähkötunnin aikana). Toki 25 A -> 35 A nosto jo itsessään maksaa ja lisäksi se tuo isomman kuukausimaksun, joten ihan kevyin perustein ei tuohon kannata lähteä.

Ja kenties tämä ylläoleva on ihan täysin turhaa haihattelua; voi olla täysin perusteltua, että yksinkertaisesti säätää latauksen alkamaan klo 00:00 ja loppumaan klo 7:00 tai toki se loppuu jo aiemminkin, mikäli auton päästä säädetty latausraja tulee täyteen. Asiaa pitää ajatella myös siltäkin kannalta, että olisi hyvä, että akun lataus loppuu juuri ennen ajoon lähtöä, sillä tällöin akussa on latauksen sinne synnyttämää lämpöä, jolloin ajaminen on taloudellisempaa vrt. liikkeelle lähtö jo jäähtyneellä akulla. Eli se, että säästää pennin ladatessaan akkua vaikkapa neljä tuntia klo 0:00 alkaen, voi tarkoittaa, että häviääkin kaksi penniä ensimmäisen 50 ajokilometrin aikana myöhemmin aamulla.

 

[villho]

Mutta nyt en keksi miten palaisin halpojen tuntien jälkeen normaalilämmitykseen? Miten toteuttaisi triggerin, joka kertoisi halpojen tuntien päättyneen?

Miten olet määrittänyt itsellesi "halvat tunnit"?

SHF-paketissahan ovat jo attribuutit:

SHF Price acceptable On/Off​

SHF Rank acceptable On/Off​

SHF Price or Rank acceptable On/Off​

Nämä käyttävät käyttäjän syötteitä: "SHF Max Price allowed" ja/tai "SHF Max Rank allowed" riippuen siitä, miten haluat nuo "halvat tunnit" määrittää - joko tietty valittu hintakynnys (hankalaa, koska pörssisähkö voi päivästä toiseen vaihdella, toki tätäkin voi päivittää automaatiolla) TAI niin, että vuorokaudesta valitaan X määrä halvimpia tunteja, joiden aikana lämmitys sallitaan. Tuota tuntimäärää voidaan päivittää vaikkapa sääennusteen perusteella. Halvat tunnit toki usein sijoittuvat yölle, joten sitten riippuu kiinteistön lämmönvarauskyvystä, että voidaanko lämmitystunnit hoitaa kaikki yön aikana vai pitääkö olla joku takaraja, milloin lämmitys käynnistetään päivällä uudelleen hinnasta riippumatta.

Tämän jälkeen automaation triggerinä on State-muutos Off->On->Off jossain noista kolmessa attribuutissa, miten nyt sitten haluatkaan. Halvat tunnit päättyvät, kun tapahtuu muutos On->Off.

 

[ankl]

Saako kysyä tässä ketjussa ihan tyhmiä perus HA automaatiokyssäreitä.

Sciprti:

alias: Säädä lattialämpö kerran tunnissa
description: >-
säädetään lattialämpöä +-2 astetta perusasetuksesta (+2) pörssisähkön
mukaisesti
trigger:
- platform: time_pattern
hours: /1
condition: []
action:
- service: input_number.set_value
target:
entity_id: input_number.heishamon_heatshift_z1
data: "{{ 2 + 2*states('sensor.shf_control_factor_1') | int }}"
mode: single

Virheilmoitus (kun yritän ajaa automaation käsin testin vuoksi):
Error: Error rendering data template: Result is not a Dictionary

 

[Ville-Veikko]

Meillä on kaksi sähköautoa, joita tyypillisesti ladataan yön aikana 60 %:iin, millä selvitään tulevan päivän tavallisista max. 150 km ajoista ilman sen suurempia miettimisiä. Jos seuraavana päivänä on tiedossa enemmän ajoa, niin tarvetta voikin olla esim. 80-90 % varaustasolle aamulla lähtiessä. Tällöin voisi tilanne mennä niin, että kun iltasella palaa kotiin, autossa vaikkapa 30 % ja tarvitsee aamulla akussa 80 %, niin HA:lle voisi syöttää tiedon, että tarvitsee +50 %-yksikköä varausta akkuun, HA laskee tuohon tarvittavan latausajan, valitsee tulevilta tunneilta slotin ja ohjaa laturit antamaan virtaa tuolloin.

Nykyisellään kiinteistössä ei ole lataukselle kuormanhallintaa, vaan kumpikin auto ladataan yön aikana kolmesta vaiheesta 8 ampeerilla (5,5 kW / auto). Tämä on riittänyt aina hyvin, koska autoille ei tule koskaan tilanteita, että kotiin saavutaan todella myöhään täysin tyhjällä akulla, minkä pitäisi olla taas aamulla varhain piripinnassa täysi. Meidän 25 A pääsulakkeetkin riittävät tälle hyvin, vaikka MLP tekisi legionellakuumennustakin samanaikaisesti (max. ottoteho vastuksille säädetty 4 kW).

Mikäli vielä tulevaisuudessakin tulee olemaan pörssisähköhinnoiltaan hulluja aikoja, voisi olla järkevää nostaa pääsulakkeiden koko 35 ampeeriin ja samalla nostaa autojen latausvirtaa. Tällöin on mahdollista ladata autot tarvittavaan tasoon lyhyemmässä ajassa (lue: vain muutaman halvan pörssisähkötunnin aikana). Toki 25 A -> 35 A nosto jo itsessään maksaa ja lisäksi se tuo isomman kuukausimaksun, joten ihan kevyin perustein ei tuohon kannata lähteä.

Ja kenties tämä ylläoleva on ihan täysin turhaa haihattelua; voi olla täysin perusteltua, että yksinkertaisesti säätää latauksen alkamaan klo 00:00 ja loppumaan klo 7:00 tai toki se loppuu jo aiemminkin, mikäli auton päästä säädetty latausraja tulee täyteen. Asiaa pitää ajatella myös siltäkin kannalta, että olisi hyvä, että akun lataus loppuu juuri ennen ajoon lähtöä, sillä tällöin akussa on latauksen sinne synnyttämää lämpöä, jolloin ajaminen on taloudellisempaa vrt. liikkeelle lähtö jo jäähtyneellä akulla. Eli se, että säästää pennin ladatessaan akkua vaikkapa neljä tuntia klo 0:00 alkaen, voi tarkoittaa, että häviääkin kaksi penniä ensimmäisen 50 ajokilometrin aikana myöhemmin aamulla.

Okei. Saahan tästä toki monimutkaisenkin jos haluaa harrastaa. Mulla on tosin vain 1 hybridiauto joka lataa tyhjästä täyteen 1,5 tunnissa 7,3 kW teholla. joten sen kanssa ei tarvitse paljoa arpoa miten se kannattaa ladata. Jos joskus päädyn täyssähköön niin ainakin aloitan samalla tyylillä. 2 h latausta vuorokaudessa saatavissa autolle vuorokauden halvimmilla tunneilla -> meidän ajoilla akku olisi käytännössä aina täynnä ilman mitään ajatustyötä...

 

[ankl]

Saako kysyä tässä ketjussa ihan tyhmiä perus HA automaatiokyssäreitä.

Sciprti:

alias: Säädä lattialämpö kerran tunnissa
description: >-
säädetään lattialämpöä +-2 astetta perusasetuksesta (+2) pörssisähkön
mukaisesti
trigger:
- platform: time_pattern
hours: /1
condition: []
action:
- service: input_number.set_value
target:
entity_id: input_number.heishamon_heatshift_z1
data: "{{ 2 + 2*states('sensor.shf_control_factor_1') | int }}"
mode: single

katso liitettä 83415

Virheilmoitus (kun yritän ajaa automaation käsin testin vuoksi):
Error: Error rendering data template: Result is not a Dictionary

Tuosta taisi puuttua value: elementti. Koitanpa näin:

action:
- service: input_number.set_value
target:
entity_id: input_number.heishamon_heatshift_z1
data:
value: '{{ 2 + 2*states(''sensor.shf_control_factor_1'') | int }}'