HomeAssistant ja sähköpörssiohjaus

heebo1974 · 16 Joulukuu 2022

Ei ihan lähtenyt testi termostaatin kanssa lennolle.

Temez · 16 Joulukuu 2022

Nonni, sieltä puuttui yksi "| float". Toimisikohan

Koodi:

"{{ 22 + 2*states('sensor.shf_control_factor_1') | float }}"

.

Float-kohdan perään voi sitten laittaa | round(0), jos haluaa kokonaislukuja tai sitten | round(1), jos vaikkapa haluttu ulostulo on yhden desimaalin tarkkuudella.

Edit: sulut tuon pyöristämisen kanssa tärkeitä.

Koodi:

"{{ (22 + 2*states('sensor.shf_control_factor_1') | float) | round(1) }}"

heebo1974 · 16 Joulukuu 2022

Temez sanoi:
Koodi:

"{{ (22 + 2*states('sensor.shf_control_factor_1') | float) | round(1) }}"

Onko kyseinen koodi suomeksi jotakuinkin näin:
Aseta lämpötila 22 +/- 2 mukaan perustuen control factorin taikoihin ja pyöristä se yhden desimaalin tarkkuudella ?

heebo1974 · 16 Joulukuu 2022

Hitto kun osaamista ei ole ja kaikenlaisia graafivisioita pyörii päässä.
Esim. Loin tuollaisen graafin, missä näkyy pörssisähkön hinta ja sitten olisi lattialämmityksen pyyntilämpötila siinä samassa.
No jouduin luomaan helpperin, johon tuo shf control factor kirjoittaa aina arvon kun se muuttuu (no nyt ihan vain tunti kerrallaan).
No tietty törmäsin siihen ongelmaan, että niin eihän se lämmityksen pyynti näy kuin kuluvaan hetkeen asti, joten ilmeisesti pitäisi taas keksiä joku datagenerator rimpsu apex chartille joka osaisi laskea kokopäivän eteenpäin niitä arvoja.

Vähän sotkuinen tällähetkellä tuo lämpötila, kun sohlasin noita arvoja käsin.

Tässä vielä apex chartti.. (varmaan paljon turhaa jne sisällä, kun pohja kopsailtu eri graafista.

YAML:

type: custom:apexcharts-card
experimental:
  color_threshold: true
now:
  show: true
  color: '#ff0000'
apex_config:
  forceNiceScale: true
  chart:
    height: 165%
graph_span: 24h
yaxis:
  - id: pyynti
    show: true
    min: 17
    max: 24
    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: Lattialämmityksen pyynti vs. pörssisähkö.
span:
  start: day
  offset: +0h
series:
  - entity: input_number.test_lattialampo
    yaxis_id: pyynti
    name: Lämpötila
    type: line
    unit: °C
    extend_to: now
    stroke_width: 2
    show:
      legend_value: false
      in_header: false
      name_in_header: false
      extremas: true
  - 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(), entity.attributes.data[index]["PriceWithTax"]*100];
      });
    show:
      header_color_threshold: true
      legend_value: false
      in_header: false
      name_in_header: false
      extremas: true

Temez · 16 Joulukuu 2022

Tämä ei nyt ole ihan täydellinen mallinnus, mutta jotain tämän suuntaista?

YAML:

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: Lattialämmityksen pyynti vs. pörssisähkö.
span:
  start: day
  offset: +0h
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(), entity.attributes.data[index]["PriceWithTax"]*100];
      });
    show:
      header_color_threshold: true
      legend_value: false
      in_header: false
      name_in_header: false
      extremas: true
  - entity: sensor.shf_electricity_price_now
    yaxis_id: pyynti
    name: Pyyntilämpötila
    unit: C
    extend_to: now
    type: area
    curve: stepline
    opacity: 0.02
    group_by:
      func: last
      duration: 60m
    stroke_width: 1
    data_generator: |
     var temp_default = 22;
     var temp_diff = 2;
     var pmax = entity.attributes.today_max;
     var pmin = entity.attributes.today_min;
     var data = entity.attributes.today_prices;
     var output = [];
     for (var i = 0; i<24; ++i){
         var k = temp_default + temp_diff*(2*(pmax-data[i])/(pmax-pmin)-1);
         output.push([start.getTime()+i*3600000,k]);
     }
     return output;
    show:
      header_color_threshold: true
      legend_value: false
      in_header: false
      name_in_header: false
      extremas: true

Koelli · 16 Joulukuu 2022

Sukke sanoi:
Tähän vähän taustaa. Valitettavasti itselläni ei ole niin hyvää osaamista, että saisin näistä mitään järkevää jaettavaa aikaiseksi.

Linkki tuulivoiman tuotantoennusteen tunnittaiseen päivitysaineistoon: https://data.fingrid.fi/fi/dataset/wind-power-generation-forecast-updated-every-hour

Tuosta API-tietoa: https://data.fingrid.fi/fi/dataset/...resource/389cda12-9438-42d4-a5dd-0499b346a8c0

Tuosta APIn yleistä ohjeistusta, API-avaimen saa automaattisesti heti rekisteröitymisen jäleen: https://data.fingrid.fi/fi/pages/api

Tuossa JSON-muotoisen haun parametreistä teknisempää tietoa: https://data.fingrid.fi/open-data-api/#!/events-controller/getEventsJsonUsingGET

Olen toteuttanut tuon itse siten, että Node Red hakee HTTP requestilla kerran tunnissa päivitetyt tiedot. Halutussa formaatissa (apexcharts-cardin ymmärtämässä) tyrkkään tiedot HAn MQTT-sensoriin, josta tiedot haetaan apexcharts-cardille näytettäväksi. API on siitä hyvä, että myös historiatieto löytyy.

katso liitettä 82919

Kehtaisitko vähän avata tätä Node Red:n sisältöä? Kiinnostaa, mutta devaajan taidot lähellä nollaa.

Lisäyksenä toki, eli Node RED on olemassa ja kopioinut sen hakemaan ENTSO-E:stä SPOT-hinnat. Mutta itse blokkien sisällöt kopioinut muilta.

heebo1974 · 16 Joulukuu 2022

Temez sanoi:
Tämä ei nyt ole ihan täydellinen mallinnus, mutta jotain tämän suuntaista?
katso liitettä 82954

Toimii, mutta tämä lähestymistapa ei tainnut käyttää sitä SHF Control hommelia ? Olisi ollut kiva kokeilla eri kertoimia ja sinusoidal/linearin vaikutuksia.

Eli tavallaan olisi helpottanut kertoimien hakua omiin tarpeisiin, vaikka eihän noilla mitään dramaattisia vaikutuksia varmaan ole.

Temez · 16 Joulukuu 2022

heebo1974 sanoi:
Toimii, mutta tämä lähestymistapa ei tainnut käyttää sitä SHF Control hommelia ? Olisi ollut kiva kokeilla eri kertoimia ja sinusoidal/linearin vaikutuksia. Eli tavallaan olisi helpottanut kertoimien hakua omiin tarpeisiin, vaikka eihän noilla mitään dramaattisia vaikutuksia varmaan ole.

Joo, ei tosiaan ollut. Se SHF Control Function Factor itseasiassa kyllä vetää aika nopsaan ne "ääripäät" joko arvoon -1 tai +1 eli. Voisi olla tietysti ihan järkevää laskeskella ne arvot jo valmiiksi tuonne anturin attribuutteihin, niin ei tarvitsisi sitten tuolla ApexChartin puolella niitä generoida.

Samalla mietin, että voisi luoda jonkun pohjan tuosta Lovelace-konffista, että saisi suoraan "perus-dashboardin", jossa voisi olla muun muassa tuo "SHF Control Factorin" kuvaaja valmiina. Noh, pitää pohtia ja katsoa, kun seuraava inspiraatiohetki iskee. Voisi olla ehkä ihan hyvää palautumista lumitöistä

Sukke · 16 Joulukuu 2022

Koelli sanoi:
Kehtaisitko vähän avata tätä Node Red:n sisältöä? Kiinnostaa, mutta devaajan taidot lähellä nollaa.

Lisäyksenä toki, eli Node RED on olemassa ja kopioinut sen hakemaan ENTSO-E:stä SPOT-hinnat. Mutta itse blokkien sisällöt kopioinut muilta.

Jos olisin koodari, voisin laittaa koko flow:n jakoon, mutta oma räpellys on varmaan juuri ja juuri toimiva ilman ja luultavasti hyvien koodaustapojen vastainen. Laitoin kuitenkin alle kuvan flow:n palikoista. Ehkä joku osaavampi tekee tuulivoimaennusteesta valmiin ja toimintavarman ratkaisun suoraan HA:lle.

Periaate on seuraava:

inject-nodella asetetaan "x-api-key" eli Fingridiltä saatu tunnus ja laitetaan viesti kerran tuntiin eteenpäin
seuraavaksi satunnainen viive
function-nodella haetaan nykyinen päivämäärä ja sen perusteella asetetaan viestiin "start_time" ja "end_time"
http request -node lisää aiemmin lisätyt (ja APIn vaatimat) parametrit ("x-api-key", "start_time", "end_time") http request -kyselyyn
- URL: https://api.fingrid.fi/v1/variable/245/events/json
- Tietolaji 245 = tuulivoiman tuotantoennuste tunneittain
json-node muuttaa vastauksen JavaScript-objectiksi
function-nodella luodaan vastauksesta MQTT-viesti, jonka HA/apexcharts-card lopulta lukee
- tässä myös asetetaan kerran tunnissa kuluvan tunnin tuotantoennuste
mqtt out -nodella lähetys MQTT käsittelijälle (täytyy olla HA:ssa asennettu ja konfiguroitu)
vihreät debug-nodeja auttamaan virheiden metsästyksessä, debug-näkymä on kultaakin arvokkaampi

En ymmärtänyt näistä kuukausi kaksi sitten yhtään mitään, mutta sitkeä yritys ja erehdys -taktiikka on jotain hedelmää tuottanut. JavaScriptiähän näissä tarvitsee ja itsekin sitä opiskellut tässä samalla nollatasolta lähtien. Voin kyllä yrittää auttaa vaikka YV:llä, jos lähdet tähän tutustumaan. HAssa tarvitsee olla sitten asetettu MQTT-sensori tätä varten, itselläni sahko/tuulivoiman_tuotantoennuste1h -niminen.

JSON:

{
  "aikaleima": [
    1670976000000,
    1670979600000,
    1670983200000,
    1670986800000,
    1670990400000,
    1670994000000,
    1670997600000,
    1671001200000,
    1671004800000,
    1671008400000,
    1671012000000,
    1671015600000,
    1671019200000,
    1671022800000,
    1671026400000,
    1671030000000,
    1671033600000,
    1671037200000,
    1671040800000,
    1671044400000,
    1671048000000,
    1671051600000,
    1671055200000,
    1671058800000,
    1671062400000,
    1671066000000,
    1671069600000,
    1671073200000,
    1671076800000,
    1671080400000,
    1671084000000,
    1671087600000,
    1671091200000,
    1671094800000,
    1671098400000,
    1671102000000,
    1671105600000,
    1671109200000,
    1671112800000,
    1671116400000,
    1671120000000,
    1671123600000,
    1671127200000,
    1671130800000,
    1671134400000,
    1671138000000,
    1671141600000,
    1671145200000,
    1671148800000,
    1671152400000,
    1671156000000,
    1671159600000,
    1671163200000,
    1671166800000,
    1671170400000,
    1671174000000,
    1671177600000,
    1671181200000,
    1671184800000,
    1671188400000,
    1671192000000,
    1671195600000,
    1671199200000,
    1671202800000,
    1671206400000,
    1671210000000,
    1671213600000,
    1671217200000,
    1671220800000,
    1671224400000,
    1671228000000,
    1671231600000,
    1671235200000,
    1671238800000,
    1671242400000,
    1671246000000,
    1671249600000,
    1671253200000,
    1671256800000,
    1671260400000,
    1671264000000,
    1671267600000,
    1671271200000,
    1671274800000,
    1671278400000,
    1671282000000,
    1671285600000,
    1671289200000,
    1671292800000,
    1671296400000,
    1671300000000,
    1671303600000,
    1671307200000,
    1671310800000,
    1671314400000,
    1671318000000,
    1671321600000
  ],
  "tuuliTuotantoennuste": [
    "0.558",
    "0.623",
    "0.628",
    "0.640",
    "0.710",
    "0.757",
    "0.782",
    "0.800",
    "0.765",
    "0.689",
    "0.793",
    "0.858",
    "0.876",
    "0.827",
    "0.911",
    "0.933",
    "0.909",
    "0.810",
    "0.743",
    "0.668",
    "0.635",
    "0.584",
    "0.540",
    "0.468",
    "0.474",
    "0.495",
    "0.595",
    "0.753",
    "0.977",
    "1.178",
    "1.450",
    "1.851",
    "2.237",
    "2.477",
    "2.645",
    "2.719",
    "2.920",
    "2.958",
    "2.779",
    "2.609",
    "2.479",
    "2.493",
    "2.522",
    "2.476",
    "2.416",
    "2.279",
    "2.126",
    "2.217",
    "2.137",
    "2.058",
    "2.075",
    "1.939",
    "1.728",
    "1.635",
    "1.604",
    "1.578",
    "1.605",
    "1.654",
    "1.803",
    "2.026",
    "2.144",
    "2.254",
    "2.462",
    "2.624",
    "2.646",
    "2.731",
    "2.720",
    "2.759",
    "2.845",
    "3.009",
    "3.143",
    "3.179",
    "3.156",
    "3.128",
    "3.162",
    "3.159",
    "3.164",
    "3.189",
    "3.208",
    "3.201",
    "3.224",
    "3.232",
    "3.236",
    "3.151",
    "3.076",
    "3.036",
    "3.015",
    "2.917",
    "2.792",
    "2.648",
    "2.421",
    "2.132",
    "1.918",
    "1.721",
    "1.514",
    "1.339",
    "1.200"
  ],
  "tuuliTuotantoennusteNyt": "2.624"
}

Ville-Veikko · 16 Joulukuu 2022

Temez sanoi:
Mallailin vähän tuonne HomeAssistantin puolelle nyt tuota siirtomaksua. Privachatissa oli puhetta Mikin kanssa siitä, että tekisikö tuota suoraan API:n puolelle, mutta tuntui syntyvän suht helposti tänne Home Assistantin päähänkin.

katso liitettä 82940

Tosin kävi käpy äsken ja onnistuin ylikirjoittamaan kyseisen konffin. Mutta olisiko tämmöiselle tilausta? Yö/päiväsiirto + samalla saa spottisähkön marginaalin myös mukaan.

Itseäni kiinnostaisi alkaa simuloimaan eri siirtotuotteiden hintaeroa toteutuneella sähkönkäytöllä. Shelly EM3 olisi jo kulutusta mittaamassa, mutta pitäisi jaksaa kehitellä zydeemi joka laskisi siirtohinnan tuntitasolla jokaiselle sirtomuodolle (Yleissiirto vs Vuodenaikasiirto vs yösiirto.)
Sitten vähän utility meteriä ja graafia perään :hmm:

Perusmaksukin tulisi ottaa laskennassa huomioon jotta näkisi millaisella käytöllä mikin tuote olisi edullisin. Ei nimittäin ole ihan yksinkertaista päätellä onko yösiirto vai vuodenaikasiirto se halvempi vaihtoehto vuositasolla. Yleissiirtoon nähden kumpikin lienee edullisempia jos yleensä sähköä käyttää merkittävän määrän. Esimerkiksi Elenian hinnasto.

Temez · 16 Joulukuu 2022

Sukke sanoi:
Jos olisin koodari, voisin laittaa koko flow:n jakoon, mutta oma räpellys on varmaan juuri ja juuri toimiva ilman ja luultavasti hyvien koodaustapojen vastainen. Laitoin kuitenkin alle kuvan flow:n palikoista. Ehkä joku osaavampi tekee tuulivoimaennusteesta valmiin ja toimintavarman ratkaisun suoraan HA:lle.

Innostuin nyt kokeilemaan, että miten tämä onnistuisi HA:lla. Ja heti kärkeen pitää sanoa, että hienoa omistautumista, jos olet pienellä kokemuksella lähtenyt yrittämään. Se on hieno juttu ja tosiaan tärkeintä on, että olet saanut datan tulemaan sisään NodeRedillä!

Datan saisi ladattua HA:han tämmöisellä YAML-konffilla (kunhan tuonne laittaa oman x-api-key:n ja halutessaan muokkaa noita päivämäärähakuja):

YAML:

sensor:
  - platform: rest
    resource_template: https://api.fingrid.fi/v1/variable/245/events/xml
    name: SHF Test Wind
    value_template: 'OK' # static value as sensor is not updated regularly
    headers:
      x-api-key: "CENSORED"
    params:
      start_time: "{{ (now() - timedelta(days = 1)).strftime('%Y-%m-%dT%H:00:00Z') }}"
      end_time: "{{ (now() - timedelta(days = -1)).strftime('%Y-%m-%dT%H:00:00Z') }}"
    json_attributes:
      - "events"
    scan_interval: 3600

Kuvaajakoodi tässä:

YAML:

type: custom:apexcharts-card
now:
  show: true
  color: '#ff0000'
yaxis:
  - id: production
    show: true
    decimals: 0
    align_to: 1
    apex_config:
      tickAmount: 4
      seriesName: pyynti
      forceNiceScale: true
show:
  last_updated: false
header:
  standard_format: false
  show: true
  show_states: true
  colorize_states: true
  title: Tuulituotanto
graph_span: 48h
span:
  start: day
  offset: +0h
series:
  - entity: sensor.shf_test_wind
    yaxis_id: hinta
    name: Wind forecast
    extend_to: now
    type: area
    curve: stepline
    group_by:
      func: last
      duration: 60m
    stroke_width: 1
    data_generator: |
      return entity.attributes.events.event.map((d, index) => {
        return [new Date(d["start_time"]).getTime(), entity.attributes.events.event[index]["value"]*1];
      });
    show:
      header_color_threshold: true
      legend_value: false
      in_header: false
      name_in_header: false
      extremas: true

Tällä sai aikaan tämmöistä:

Temez · 16 Joulukuu 2022

Ville-Veikko sanoi:
Itseäni kiinnostaisi alkaa simuloimaan eri siirtotuotteiden hintaeroa toteutuneella sähkönkäytöllä.

Tätähän voisi varmaan tehdä Excelillä? Omalta firmalta saa ainakin ulos excelissä edellisen 12kk sähkönkäytön. Siihen sitten vähän näpräilyä, että saa vuorokauden tunnin ulos ja sen perusteella siirtohinta + vähän summailua. Vai mitä sulla oli ajatuksissa? Jotenkin Shellyn kanssa tehdä jonkinlaista muuta analyysia?

Jossain vaiheessa itse laskeskelin tuota yösiirron kannattavuutta, mutta muistaakseni perusmaksu nousi niin paljon ainakin omalla verkkoyhtiöllä, että olisi kesät talvet pitänyt 1300+ kWh/kk saada siirrettyä päivältä yölle, että olisi saanut perusmaksun eron kuitattua (liekö sitten oikein laskun). Eikä se oikein itsellä onnistu, kun ei ole isoa varaajaa

Ville-Veikko · 16 Joulukuu 2022

Joo, Excelillä tuon kerran jo tuon teinkin (ja totesin että ennen tulossa olevaa lämmitysmuodon vaihtoa ei kannata vaihtaa yösähköön vaikka auton lataisikin aina yöllä). mutta tuo vuodenaikasiirto olisi mielenkiintoinen tapaus selvittää. Ja minulla on tulossa Vilpin perään se isompi varaaja jolla voisi ehkä siirtää osan päiväajan sähkönkäytöstä yölle...

Jos laittasi sensorit laskemaan vuorokautiset siirtohinat kaikille kolmelle siirtomuodolle (tuntihinnassa jyvitettynä perusmaksu) voisi katella reaaliaikaisesti graafeista mikä siirtotuote maksaisi mitäkin. Näköjään tässä koetan speksata itselleni pienen koodausaskareen...

Sukke · 16 Joulukuu 2022

Temez sanoi:

Innostuin nyt kokeilemaan, että miten tämä onnistuisi HA:lla. Ja heti kärkeen pitää sanoa, että hienoa omistautumista, jos olet pienellä kokemuksella lähtenyt yrittämään. Se on hieno juttu ja tosiaan tärkeintä on, että olet saanut datan tulemaan sisään NodeRedillä!

Datan saisi ladattua HA:han tämmöisellä YAML-konffilla (kunhan tuonne laittaa oman x-api-key:n ja halutessaan muokkaa noita päivämäärähakuja):

YAML:

sensor:
  - platform: rest
    resource_template: https://api.fingrid.fi/v1/variable/245/events/xml
    name: SHF Test Wind
    value_template: 'OK' # static value as sensor is not updated regularly
    headers:
      x-api-key: "CENSORED"
    params:
      start_time: "{{ (now() - timedelta(days = 1)).strftime('%Y-%m-%dT%H:00:00Z') }}"
      end_time: "{{ (now() - timedelta(days = -1)).strftime('%Y-%m-%dT%H:00:00Z') }}"
    json_attributes:
      - "events"
    scan_interval: 3600

Kuvaajakoodi tässä:

YAML:

type: custom:apexcharts-card
now:
  show: true
  color: '#ff0000'
yaxis:
  - id: production
    show: true
    decimals: 0
    align_to: 1
    apex_config:
      tickAmount: 4
      seriesName: pyynti
      forceNiceScale: true
show:
  last_updated: false
header:
  standard_format: false
  show: true
  show_states: true
  colorize_states: true
  title: Tuulituotanto
graph_span: 48h
span:
  start: day
  offset: +0h
series:
  - entity: sensor.shf_test_wind
    yaxis_id: hinta
    name: Wind forecast
    extend_to: now
    type: area
    curve: stepline
    group_by:
      func: last
      duration: 60m
    stroke_width: 1
    data_generator: |
      return entity.attributes.events.event.map((d, index) => {
        return [new Date(d["start_time"]).getTime(), entity.attributes.events.event[index]["value"]*1];
      });
    show:
      header_color_threshold: true
      legend_value: false
      in_header: false
      name_in_header: false
      extremas: true

Tällä sai aikaan tämmöistä:
katso liitettä 82977

Hieno esimerkki! Arvelinkin, että tämä menee aika suoraviivaisesti HA:n puolella, jos vain osaa. Tuossa YAMLissa on jotain, mikä on tehnyt siitä itselleni hankalaa aloittaa. En ole tosin varsinaisesti edes yrittänyt. Pythonilla aloitin syksyllä harrastukset, mutta totesin, että menee HA:n kanssa hankalaksi. Node Redin kanssa on onnistunut moni asia, mutta onhan tuo HA:n oma YAML varmaan useimmiten lopulta yksinkertaisin.

Taipumusta on kyllä tehdä asiat omalla tavalla ja varmaan tulee aika monesti kiivettyä puuhun takaperoisesti.

Temez · 16 Joulukuu 2022

Sukke sanoi:
Hieno esimerkki! Arvelinkin, että tämä menee aika suoraviivaisesti HA:n puolella, jos vain osaa. Tuossa YAMLissa on jotain, mikä on tehnyt siitä itselleni hankalaa aloittaa. En ole tosin varsinaisesti edes yrittänyt. Pythonilla aloitin syksyllä harrastukset, mutta totesin, että menee HA:n kanssa hankalaksi. Node Redin kanssa on onnistunut moni asia, mutta onhan tuo HA:n oma YAML varmaan useimmiten lopulta yksinkertaisin.

Taipumusta on kyllä tehdä asiat omalla tavalla ja varmaan tulee aika monesti kiivettyä puuhun takaperoisesti.

Lopputulos ratkaisee ja tosiaan tärkeintä on, että esim. se tuuliennustedata tulee läpi. Itse olen enemmän "koodari", mutta arvostan paljon sitä, että on intoa yrittää ja koettaa. Ja nykyiset low-code/no-code systeemit mahdollistavatkin sitten onneksi myös paljon ilman koodinpätkän kirjoittamista.

Temez · 17 Joulukuu 2022

heebo1974 sanoi:
Toimii, mutta tämä lähestymistapa ei tainnut käyttää sitä SHF Control hommelia ? Olisi ollut kiva kokeilla eri kertoimia ja sinusoidal/linearin vaikutuksia. Eli tavallaan olisi helpottanut kertoimien hakua omiin tarpeisiin, vaikka eihän noilla mitään dramaattisia vaikutuksia varmaan ole.

No nyt olisi Githubissa kuluvan päivän arvot sensorin attribuuteissa.

Ja tässä niitä lukeva kuvaajakonffi:

YAML:

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: Lattialämmityksen pyynti 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_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, 22+2*d];
      });
    show:
      header_color_threshold: true
      legend_value: false
      in_header: false
      name_in_header: false
      extremas: true

atomato · 17 Joulukuu 2022

Sain Husdata+Homeassistant kombon toimimaan. Etsimäni säädin olikin termostaatti joten sitä piti ohjata automaatiossa termostaattina eikä lukuna.

Testissä sliderin avulla 10h "kovaa lämpöä" halvoilla tunneilla ja 14h "lämmityksen pienennystä. Eli lasken ulkolämmön ofsettiä (kerron pumpulle että pakasstuu->pumppu nostaa kiertoveden lämpöä tai nostan ulkolämmön ofsettiä mikäli haluan vähemmän lämpöä->kerron pumpulle että ulkona lauhtuu ->vähemmän sähkönkulutusta. Tuntuu toimivan. Eilen kun oli yöllä kova pakkanen oli aamulla sisällä jopa vähän kuuma (23,5c) ja päivän sekä illan pumppu huilaili enemmän jolloin sisälämpö taas normaalimpi 22,0c. Laskuvaraa lämpökäyrässä on vielä paljon. Testailut jatkuu.

Sukke · 17 Joulukuu 2022

atomato sanoi:
Sain Husdata+Homeassistant kombon toimimaan. Etsimäni säädin olikin termostaatti joten sitä piti ohjata automaatiossa termostaattina eikä lukuna.

Testissä sliderin avulla 10h "kovaa lämpöä" halvoilla tunneilla ja 14h "lämmityksen pienennystä. Eli lasken ulkolämmön ofsettiä (kerron pumpulle että pakasstuu->pumppu nostaa kiertoveden lämpöä tai nostan ulkolämmön ofsettiä mikäli haluan vähemmän lämpöä->kerron pumpulle että ulkona lauhtuu ->vähemmän sähkönkulutusta. Tuntuu toimivan. Eilen kun oli yöllä kova pakkanen oli aamulla sisällä jopa vähän kuuma (23,5c) ja päivän sekä illan pumppu huilaili enemmän jolloin sisälämpö taas normaalimpi 22,0c. Laskuvaraa lämpökäyrässä on vielä paljon. Testailut jatkuu.

Husdata tulossa tännekin. Eikös siinä ollut aika monta ohjausvaihtoehtoa? MQTT, Modbus ja HTTP ainakin?

Mitä laitetta ohjaat Husdatalla?

atomato · 17 Joulukuu 2022

Sukke sanoi:
Husdata tulossa tännekin. Eikös siinä ollut aika monta ohjausvaihtoehtoa? MQTT, Modbus ja HTTP ainakin?

Mitä laitetta ohjaat Husdatalla?

MQTT koodi on aika pitkälti valmiina ainakin tämän pumpun osalta Husdatan ohjeissa. Jonkin verran piti muokata esim nimiä että pelasi. Sillä siis ohjaan.

IVT C6. Rego 1000 ohjaimella.

heebo1974 · 17 Joulukuu 2022

Itse tein nyt sellaisen automaation lattialämmityksille, että kun SHF Rank vaihtuu, tarkastetaan onko SHF Price acceptable, ja jos on termostaattien lämpötila valitaan SHF Control Factor_0_1 avulla 19+3. Jos SHF Price acceptable ei täyty valitaan lämpötila SHF Control Factor_0_1 avulla 18+3.

Kiitos Temezille ja Mikille paljon tämän mahdollistamisesta.

EDIT: Kylppäriin muuten sama, mutta vielä vähän lämpimämmäksi.

Koelli · 17 Joulukuu 2022

Rakensin HA:n automaatiot kuormien automaattiselle alasajolle Fingridin API:sta saatavien reaaliaikaisten sähköpula- ja järjestelmän käyttötilannetietojen mukaisesti.

Tästähän nyt ei kansalainen "hyödy" mitään, pois lukien ehkä sen, että ennen kuin esimerkiksi verkko on kaatumassa, voidaan sammuttaa ILPit, LVV:t ja muut ohjattavat kuormat ja mahdollisesti estää niitä menemästä joissain tilanteissa rikki.

Jos tällainen jollain tasolla kiinnostaa, niin voin toki jakaa muidenkin käyttöön.

Temez · 18 Joulukuu 2022

Koelli sanoi:
Jos tällainen jollain tasolla kiinnostaa, niin voin toki jakaa muidenkin käyttöön.

Vaikuttaa oikein mielenkiintoiselta. Ja ehkä tuosta voisi olla hyötyä tuonne Github-pakettiinkin, jotta ihmiset saisivat esittämälläsi tavalla tiputettua kuormaa mahdollisen sähköpulan uhatessa. Tai ainakin olisi helpot työkalut sen mahdollistamiseksi.

EDIT: jos se siis sinulle sopii, että nappaisin ajatuksen sinne puolelle.

Sukke · 18 Joulukuu 2022

Koelli sanoi:
Rakensin HA:n automaatiot kuormien automaattiselle alasajolle Fingridin API:sta saatavien reaaliaikaisten sähköpula- ja järjestelmän käyttötilannetietojen mukaisesti.

Tästähän nyt ei kansalainen "hyödy" mitään, pois lukien ehkä sen, että ennen kuin esimerkiksi verkko on kaatumassa, voidaan sammuttaa ILPit, LVV:t ja muut ohjattavat kuormat ja mahdollisesti estää niitä menemästä joissain tilanteissa rikki.

Jos tällainen jollain tasolla kiinnostaa, niin voin toki jakaa muidenkin käyttöön.

Laittaisitko linkin näihin kyseisiin tietoihin? Nämä ilmeisesti siis reaaliaikaisia tietoja ja näihin perustuvat ohjaukset vastaa todelliseen tarpeeseen?

TeemuB · 18 Joulukuu 2022

Koelli sanoi:
Rakensin HA:n automaatiot kuormien automaattiselle alasajolle Fingridin API:sta saatavien reaaliaikaisten sähköpula- ja järjestelmän käyttötilannetietojen mukaisesti.

Tästähän nyt ei kansalainen "hyödy" mitään, pois lukien ehkä sen, että ennen kuin esimerkiksi verkko on kaatumassa, voidaan sammuttaa ILPit, LVV:t ja muut ohjattavat kuormat ja mahdollisesti estää niitä menemästä joissain tilanteissa rikki.

Jos tällainen jollain tasolla kiinnostaa, niin voin toki jakaa muidenkin käyttöön.

Laita ehdottomasti jakoon! Itse olen pohtinut tuota samaa nimenomaan kotiautomaatiojärjestelmien ja muun aateekoon näkökulmasta - tietokoneet ja verkkolevyt kun eivät tykkää siitä, jos virrat katoavat kesken kaiken - eli voisi jonkun shutdown-signaalin lähettää valituille laitteille (ja vaikka notifikaation HA:n käyttöliittymään).

Koelli · 18 Joulukuu 2022

Temez sanoi:
Vaikuttaa oikein mielenkiintoiselta. Ja ehkä tuosta voisi olla hyötyä tuonne Github-pakettiinkin, jotta ihmiset saisivat esittämälläsi tavalla tiputettua kuormaa mahdollisen sähköpulan uhatessa. Tai ainakin olisi helpot työkalut sen mahdollistamiseksi.

EDIT: jos se siis sinulle sopii, että nappaisin ajatuksen sinne puolelle.

Painotan, että olen tässä hyödyntänyt muiden kontribuutiota ja kuin sattumalta, Home Assistantin communityssä tästä tuli ketju vastaan, josta pystyin kopioimaan toimivat sensori-määritykset konfiguraatioon. Sen lisäksi, tämä on laadultaan kehnoa ja oikeissa käsissä varmastikin tästäkin saisi hyvin paketoidun kokonaisuuden.

Se disclaimerista. Laitan jakoon sensori-määritykset, Apex Charts -graafit, sekä omasta HA:sta automaatiot YAML:na, sensuroiden tietyt tiedot johtuen laitteiden nimeämiskäytänteistä.

Koelli · 18 Joulukuu 2022

Sähköpulan ja sähköverkon tilan automaatiot

Palvelu, josta tiedot haetaan: Fingrid API. Luo tunnus ja saat sähköpostiisi yksilöllisen API-avaimen.

Luo HA:n konfiguraatioon sensorit sähköpulalle ja sähköverkon tilalle:

Koodi:

- platform: rest
  resource_template: "https://api.fingrid.fi/v1/variable/336/events/json?start_time={{ (now()-timedelta(hours=4)).strftime('%Y-%m-%dT%H:%M:%SZ') }}&end_time={{ (now()+timedelta(hours=12)).strftime('%Y-%m-%dT%H:%M:%SZ') }}"
  name: SHF Sähköpula
  value_template: "{{ value_json.0.value }}"
  headers:
    x-api-key: "TÄHÄN_API_AVAIN"
  json_attributes_path: $.0
  json_attributes:
    - value
    - start_time
    - end_time
  scan_interval: 120

Koodi:

- platform: rest
  resource_template: "https://api.fingrid.fi/v1/variable/209/events/json?start_time={{ (now()-timedelta(hours=4)).strftime('%Y-%m-%dT%H:%M:%SZ') }}&end_time={{ (now()+timedelta(hours=12)).strftime('%Y-%m-%dT%H:%M:%SZ') }}"
  name: SHF Sähköverkon tila
  value_template: "{{ value_json.0.value }}"
  headers:
    x-api-key: "TÄHÄN_API_AVAIN"
  json_attributes_path: $.0
  json_attributes:
    - value
    - start_time
    - end_time
  scan_interval: 120

Tämän jälkeen käynnistä HA uudelleen, jotta saat aktivoitua sensorit.

Luodaan Graafit sensoreille Apex Charts:lla:

Koodi:

type: custom:apexcharts-card
update_interval: 1m
header:
  show: true
  title: Sähköverkon tila
  show_states: true
  colorize_states: true
apex_config:
  yaxis:
    min: 0
  legend:
    show: false
graph_span: 1d
span:
  start: day
experimental:
  color_threshold: true
series:
  - entity: sensor.shf_sahkoverkon_tila
    type: area
    curve: stepline
    stroke_width: 0
    extend_to: now
    show:
      name_in_header: true
      in_header: raw
      header_color_threshold: true
    color_threshold:
      - value: 1
        color: lime
      - value: 2
        color: yellow
      - value: 3
        color: red
      - value: 4
        color: black
      - value: 5
        color: blue
  - entity: sensor.shf_sahkopula
    type: area
    curve: stepline
    stroke_width: 0
    extend_to: now
    show:
      name_in_header: true
      in_header: raw
      header_color_threshold: true
    color_threshold:
      - value: 0
        color: lime
      - value: 1
        color: yellow
      - value: 2
        color: red
      - value: 3
        color: black
yaxis:
  - decimals: 0
    max: 5
    min: 0
    apex_config:
      tickAmount: 5

Ja sitten luodaan automaatiot, johon määritellään, että jos sähköpula on ilmeinen (status 2), tai sähköverkon tila heikentynyt/sähköpula (status 2), ajetaan kuormat alas:

Koodi:

alias: Sähköpula laitteet OFF
description: ""
trigger:
  - platform: state
    entity_id:
      - sensor.shf_sahkopula
    attribute: value
    to: "2"
  - platform: state
    entity_id:
      - sensor.shf_sahkoverkon_tila
    attribute: value
    to: "2"
condition: []
action:
  - service: switch.turn_off
    data: {}
    target:
      entity_id:
        - switch.xxxxxx
        - switch.xxxxxx
        - switch.xxxxxx
        - switch.xxxxxx
        - switch.xxxxxx
        - switch.xxxxxx
        - switch.xxxxxx
      device_id:
        - xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
        - xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
        - xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
        - xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
        - xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
        - xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
        - xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
        - xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
        - xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
        - xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
  - service: switch.turn_on
    data: {}
    target:
      entity_id: switch.xxxxxxxxxxxxx
  - service: notify.mobile_app_MATKAPUHELIMESI_NIMI
    data:
      message: Sähköpulan ja/tai sähköverkon tilan takia laitteet sammutettu
      title: Sähköpula / sähköverkon häiriö
mode: single

Koelli · 18 Joulukuu 2022

Sukke sanoi:
Laittaisitko linkin näihin kyseisiin tietoihin? Nämä ilmeisesti siis reaaliaikaisia tietoja ja näihin perustuvat ohjaukset vastaa todelliseen tarpeeseen?

Suorat linkit näihin kahteen tietoon ovat:

Sähköpulan reaaliaikainen tieto
Sähköverkon reaaliaikainen tila

Ja kyllä, molemmat ovat täysin reaaliaikaisia (päivitys 3min välein) ja uskoisin, että näiden läpi mahdolliset sähköpula- ja/tai verkon häiriötilanteet tulevat nopeimmin, kuin minkään muun kanavan.

Temez · 18 Joulukuu 2022

Hyvältä vaikuttaa ja hyvä nosto tämä "sähköpula-API". Rajapinnasta saa näemmä historiadataa ja uusin tulos on max 3 min vanha. Tuossa aamulla mallailin itsekin tuota sensorin koodia ja tämmöistä silloin syntyi:

Koodi:

sensor:
  - platform: rest
    resource_template: https://api.fingrid.fi/v1/variable/336/events/xml
    name: SHF Electricity shortage
    unique_id: shf_electricity_shortage
    value_template: '{{ value_json.events.event.value }}'
    headers:
      x-api-key: "CENSORED"
    params:
      start_time: "{{ (utcnow() - timedelta(minutes = 3)).strftime('%Y-%m-%dT%H:%M:%SZ') }}"
      end_time: "{{ (utcnow() + timedelta(hours = 2)).strftime('%Y-%m-%dT%H:00:00Z') }}"
    scan_interval: 180

Muutamia parannusehdotuksia toteutukseesi (voi olla myös aivopieruja seassa minulta):

Fingridin API odottaa aikaleimoja UTC-ajassa, joten templateissa utcnow() saa aikaan vähän eri ajankohdalta dataa. Ellei sitten Home Assistantisi pyöri UTC-ajassa? Vertailua voi tehdä Developer Toolsien puolella kokeilemalla eri Templateja.
Otat anturin arvoksi nyt templatella "{{ value_json.0.value }}", joka palauttaa ensimmäisen Fingridin API:n tarjoaman tuloksen. Koska start_time on -4h nykyhetkestä ja käytät paikallista aikaa, niin Fingridin API:n palauttaman tulossarjan ensimmäinen taitaa olla -2h paikallista aikaa. Eli anturissa on 2h vanha tulos. Vai onko? Anturin attribuuteista sen pitäisi selvitä, kun näemmä poimit start_timen ja end_timen anturin attribuuteiksi.
- En osaa sanoa, että auttaisiko tähän vaihtaa arvoksi "{{ value_json.-1.value }}". Pythonissa listan viimeisen eli tässä tapauksessa uusimman arvon saa listoista indeksillä -1. Jos tämä ei toimi, niin sitten ehkä pitää ottaa sopivasta indeksistä se "oikea arvo" tai muutta start_timea.
Automaatioissa kannattanee myös huomioida tilanne, jossa jostain syystä hypättäisiin suoraan alemmalta tasolta tasolle 3. Fingridin sivuilla kuvataan, että myös äkillisessä tilanteessa hypitään järjestyksessä tasot 1-3, mutten tosiaan tiedä, että voiko olla mahdollista hypätä suoraan tasolta 1 tasolle 3 jonkin ison voimalaitoksen tippuessa alas? Ja toisaalta en tiedä, että mitkä vasteajat näissä on siinä, että Fingrid soittaa jakeluyhtiölle ja miten nopeasti jakeluyhtiö saa tiputettu verkosta kuluttajia pois. Ja missä välissä data on ehtinyt tulla APIin saataville. Eli aikamoista spekulaatiota tämä, kun en tiedä.
- Laitteiden automaattinen palautus käyttöön voisi olla hyvä jatkokehitys verkon tilan normalisoituessa. Tai ainakin jokin automaatio, joka koettaisi pitää kämppää lämpimänä.

Ja tosiaan vielä kiitos tämän API:n esille tuomisesta ja toteutuksista! Moni voinee tätä hyötykäyttää omissa toteutuksissaan.

Sukke · 18 Joulukuu 2022

Koelli sanoi:
Suorat linkit näihin kahteen tietoon ovat:

Sähköpulan reaaliaikainen tieto
Sähköverkon reaaliaikainen tila

Ja kyllä, molemmat ovat täysin reaaliaikaisia (päivitys 3min välein) ja uskoisin, että näiden läpi mahdolliset sähköpula- ja/tai verkon häiriötilanteet tulevat nopeimmin, kuin minkään muun kanavan.

Täytynee hankkia muutama Philips Huen RGB-lamppu niin voisi ainakin huvikseen testata näitä. Yhtä Huen lamppua ohjailen huvin ja urheilun vuoksi värilämpötilan ja kirkkauden osalta spot-hinnan mukaan, tässäkin RGB olisi parempi.

Kunhan saan Shellyn 3EM mittaamaan koko talon kulutusta, yritän saada lampun sykkimään hetkellisen kokonaiskulutuksen mukaan. En tiedä taipuuko HA tai Node Red tuommoiseen ohjaukseen kuinka helposti.

Temez · 18 Joulukuu 2022

Tulipa kokeiltua ja tämmöisellä tosiaan saisi sähköpulasta datan. Attribuutteihin saa talteen "historian" (muokkaa pituus start_time-rivillä) ja uusin arvo tulee näemmä nätisti indeksillä -1 anturin arvoksi.

YAML:

sensor:
  - platform: rest
    resource_template: https://api.fingrid.fi/v1/variable/336/events/xml
    name: Fingrid Electricity Shortage
    value_template: '{{ value_json.events.event[-1].value }}'
    headers:
      x-api-key: "CENSORED"
    params:
      start_time: "{{ (utcnow() - timedelta(minutes = 60)).strftime('%Y-%m-%dT%H:%M:%SZ') }}"
      end_time: "{{ (utcnow() + timedelta(days = 1)).strftime('%Y-%m-%dT%H:00:00Z') }}"
    json_attributes_path: "events"
    json_attributes:
      - "event"
    scan_interval: 180

Koelli · 18 Joulukuu 2022

Temez sanoi:
Tulipa kokeiltua ja tämmöisellä tosiaan saisi sähköpulasta datan. Attribuutteihin saa talteen "historian" (muokkaa pituus start_time-rivillä) ja uusin arvo tulee näemmä nätisti indeksillä -1 anturin arvoksi.

YAML:

sensor: - platform: rest resource_template: https://api.fingrid.fi/v1/variable/336/events/xml name: Fingrid Electricity Shortage value_template: '{{ value_json.events.event[-1].value }}' headers: x-api-key: "CENSORED" params: start_time: "{{ (utcnow() - timedelta(minutes = 60)).strftime('%Y-%m-%dT%H:%M:%SZ') }}" end_time: "{{ (utcnow() + timedelta(days = 1)).strftime('%Y-%m-%dT%H:00:00Z') }}" json_attributes_path: "events" json_attributes: - "event" scan_interval: 180

Kiitos, tämä toimii paremmin. Toki sensorin attribuutteihin timestampit tulostuvat muodossa +00h, joka on vain visuaalinen virhe. HA:n timezone on oikein, joten siitä ei ole kiinni. Niin se tosin teki tuolla aiemmallakin koodinpätkällä.

Jusii · 18 Joulukuu 2022

Temez sanoi:
Tosin kävi käpy äsken ja onnistuin ylikirjoittamaan kyseisen konffin. Mutta olisiko tämmöiselle tilausta? Yö/päiväsiirto + samalla saa spottisähkön marginaalin myös mukaan.

Olisi tilausta. Eilen aamusta paloi käpy, kun entso-e:n DNS oli nurin (nordpool integraation ongelmat palasi mieleen), niin otin tämän käyttöön. Mutta noiden lisäkulujen ymppäystä mukaan kaipaan.

Sukke · 19 Joulukuu 2022

Ensimmäinen testi sallittujen tuntien haarukoinnista HA:lla takana. Edelleen mennään jalat irti maasta ja teoriatasolla, kun ei ohjattavaa vielä ole. Ajatuksena on tehdä liukuva tarkastelu lämmitystarpeesta eli valitun ajanjakson (esim. -12 h ... + 24 h) tuntihintojen ja ulkolämpötilan perusteella määritetään optimaaliset tunnit lämmitystä varten. Tuntimäärät saa syöttää HA:ssa eri lämpötiloille ja välit interpoloidaan syötetyistä tunneista.

Omassa toteutuksessa ei ole vielä mukana historiatietoa menneistä sallituista tunneista eli nykyinen tarkastelu katsoo aina tulevaisuuteen. Pienellä lisäyksellä historiatiedon saa mukaan, jolloin tarkastelu on vähän enemmän oikea, kun toteutuneet lämmitystunnit saa mukaan.

Alla olevassa kuvassa sallittuID kertoo, onko menossa oleva tunti ns. lämmitystunti (numero 0 = ei sallittu). Numero 3 on rank-tiedon perusteella mukana oleva tunti (määräävä tekijä), numero 2 alemman hintarajan alittava tunti, numero 1 ylemmän hintarajan alittava tunti. Numerolla 4 on kuvattu tunti, joka on mukana sen vuoksi, ettei "lämmityskatko" tule liian pitkäksi - valintaperusteena halvin tunti siten, että lämmityskatkon ehto täyttyy. Tämä viimeisin tarkastelu ei ole tosin valmis, mutta alla olevassa esimerkissä sattui toimimaan. Aika näyttää tarvitseeko noita 4-tunteja lämmityksessä vai ennemmin ehkä käyttöveden kanssa.

Nämä ihan vain harjoituksia, mutta eiköhän nämä jossain muodossa tule aikanaan todelliseen ohjaukseenkin.

Alla muutama kuvakaappaus HA:sta.

lämmitys- ja sallitut tunnit – kopio.jpg

Sukke · 19 Joulukuu 2022

Sukke sanoi:
Ensimmäinen testi sallittujen tuntien haarukoinnista HA:lla takana. Edelleen mennään jalat irti maasta ja teoriatasolla, kun ei ohjattavaa vielä ole. Ajatuksena on tehdä liukuva tarkastelu lämmitystarpeesta eli valitun ajanjakson (esim. -12 h ... + 24 h) tuntihintojen ja ulkolämpötilan perusteella määritetään optimaaliset tunnit lämmitystä varten. Tuntimäärät saa syöttää HA:ssa eri lämpötiloille ja välit interpoloidaan syötetyistä tunneista.

Omassa toteutuksessa ei ole vielä mukana historiatietoa menneistä sallituista tunneista eli nykyinen tarkastelu katsoo aina tulevaisuuteen. Pienellä lisäyksellä historiatiedon saa mukaan, jolloin tarkastelu on vähän enemmän oikea, kun toteutuneet lämmitystunnit saa mukaan.

Alla olevassa kuvassa sallittuID kertoo, onko menossa oleva tunti ns. lämmitystunti (numero 0 = ei sallittu). Numero 3 on rank-tiedon perusteella mukana oleva tunti (määräävä tekijä), numero 2 alemman hintarajan alittava tunti, numero 1 ylemmän hintarajan alittava tunti. Numerolla 4 on kuvattu tunti, joka on mukana sen vuoksi, ettei "lämmityskatko" tule liian pitkäksi - valintaperusteena halvin tunti siten, että lämmityskatkon ehto täyttyy. Tämä viimeisin tarkastelu ei ole tosin valmis, mutta alla olevassa esimerkissä sattui toimimaan. Aika näyttää tarvitseeko noita 4-tunteja lämmityksessä vai ennemmin ehkä käyttöveden kanssa.

Nämä ihan vain harjoituksia, mutta eiköhän nämä jossain muodossa tule aikanaan todelliseen ohjaukseenkin.

Alla muutama kuvakaappaus HA:sta.

katso liitettä 83094 katso liitettä 83093

Täytyikin aamulla katsoa, miltä tilanne näyttää nyt. Tämähän olikin tehty niin, että tuntitarve skaalataan jäljellä olevien sähkön tuntihintojen mukaiselle jaksolle. Sallittujen lämmitystuntien tilanne näyttää nyt alla olevalta, kun historiatietoja ei oteta huomioon (8,7 h / 24 h * 17 h = ~6 h). Aiemmat numeroiden 1 ja 4 tunnit on muuttuneet numeroksi 3, kun historiatietoja ei ole käytettävissä. Kuvaaja ei näytä HA:n historiatietoja oikein, kun arvo on pysynyt yön aikana muuttumattomana. Ilmeisesti sensoriin hetki sitten lisätty force_update: true voisi auttaa tähän. Sensorin historiatiedoista laitan seuraavassa vaiheessa toteutuneet lämmitystunnit mukaan tarkasteluun, toteutuksessa on vain muutama pieni (iso) kysymysmerkki.

Tuntitarve lasketaan nyt jäljellä olevien tuntihintojen sallimissa rajoissa (sisältäen edellisten 12 h mitatun ulkolämpötilatiedon). Tarpeenhan voisi laskea pidemmällekin ajalle tulevaisuuteen, kun käytössä on kuitenkin skaalaus käytettävissä olevien tuntihintojen mukaan. Tällöin sääennuste tulisi aina huomioitua riittävän pitkälle.

Mitä pitäisi tehdä, ettei foorumi tekisi näistä liitekuvista suttuisia? Edellisessä viestissä ylempi kuva näyttää ihan ok:lta, mutta nämä kuvaajat on jotenkin pehmeitä.

[

lämmitys- ja sallitut tunnit 2 – kopio.jpg

/SPOILER]

marpelto · 19 Joulukuu 2022

Moi...

Mielenkiintoinen keskustelu. En tiedä onko tämä jo sivuttu (en niin tarkaan kahlannut läpi) mutta..
...miten saisi graafin joka näyttää sähkön hinnan tunneittain kertomalla NordPool hinta ja käytetty energia?

Tässä NordPool sähkönhinta tunneittain

Ja tässä Sähkönkulutus (Energomonitor APIsta kaivettu) tunneittain
Miten muuten saan jaettua kulutuksen 1000lla eli lukema Wh--> kWh.

Ylläolevahan on käytännössä tehon tunnin keskiarvo watteina
eikö se sitten käytännössä ole Wh.

Mutta jos nuo inputit saisi kerrottua keskenään graafiin?

marpelto · 19 Joulukuu 2022

Kokeilin myös "Energy" valiokkoa samoilla inputeilla
Mutta sähkön hinta on mitä sattuu?

marpelto · 19 Joulukuu 2022

Tarkoitus tällä kaikella siis ennakoida tuleva sähkölasku

heebo1974 · 19 Joulukuu 2022

marpelto sanoi:
Tarkoitus tällä kaikella siis ennakoida tuleva sähkölasku

Energy valikko toimii, kunhan pörssihinta on euroina ei sentteinä.

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

Temez · 19 Joulukuu 2022

Jusii sanoi:
Olisi tilausta. Eilen aamusta paloi käpy, kun entso-e:n DNS oli nurin (nordpool integraation ongelmat palasi mieleen), niin otin tämän käyttöön. Mutta noiden lisäkulujen ymppäystä mukaan kaipaan.

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.

Temez · 19 Joulukuu 2022

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

Jos tästä saisi vähän kommentteja, että toimiiko vai ei, niin voisin sitten laittaa tuonne päähaaraan sen jälkeen. Ellei nyt hirveitä bugeja löydy.

HomeAssistant ja sähköpörssiohjaus

Aktiivinen jäsen

Aktiivinen jäsen

Aktiivinen jäsen

Aktiivinen jäsen

Aktiivinen jäsen

Aktiivinen jäsen

Aktiivinen jäsen

Aktiivinen jäsen

Aktiivinen jäsen

Aktiivinen jäsen

Aktiivinen jäsen

Aktiivinen jäsen

Aktiivinen jäsen

Aktiivinen jäsen

Aktiivinen jäsen

Aktiivinen jäsen

Tulokas

Aktiivinen jäsen

Tulokas

Aktiivinen jäsen

Aktiivinen jäsen

Aktiivinen jäsen

Aktiivinen jäsen

Jäsen

Aktiivinen jäsen

Aktiivinen jäsen

Aktiivinen jäsen

Aktiivinen jäsen

Aktiivinen jäsen

Aktiivinen jäsen

Aktiivinen jäsen

Jäsen

Aktiivinen jäsen

Aktiivinen jäsen

Jäsen

Jäsen

Jäsen

Aktiivinen jäsen

Aktiivinen jäsen

Aktiivinen jäsen