HomeAssistant ja sähköpörssiohjaus

[dillon]

Tämä hieno koodi, joka ilmoittelee vuorokauden tunneille onko vilp vai öljy kannattavampaa, lakkasi toimimasta jo keväällä, kun lämmityskauden jälkeen latailin HA:n päivityksiä. Onkohan @Temez vielä linjoilla? Olitko omissa systeemeissä tätä käyttänyt ja mahdollisesti jo korjannut? Koitin jo tuota tutkailla ja testailla mutta ei vaan taidot tahdo riittää.

Joka tapauksessa tuohon Weather data systeemin muutokseen ongelma liittyy ja vaikka esim Met.no sääennusteessa näkee tunneittain hinnat, niin se ei pysty tuota enään hyödyntämään.

Tuo liittynee siihen että uudessa weather-palvelussa ei enää löydy automaattisesti sensoria jossa olisi tuntiennuste attribuuttina. Se pitää itse tehdä templatella. Alla esimerkki. Eli tässä se tuntiennuste löytyy sensor.weather_koti_hourly:n attribuutista forecast joka pitää laittaa tuohon koodiisi weather.kotipaikka tilalle.

template:
  - trigger:
      - platform: time_pattern
        minutes: /30
      - platform: homeassistant
        event: start
    action:
      - service: weather.get_forecasts
        data:
          type: hourly
        target:
          entity_id: weather.kotipaikka
        response_variable: forecast_data
    sensor:
      - name: Weather koti hourly
        unique_id: weather_koti_hourly
        state: '{{ forecast_data["weather.kotipaikka"].forecast[0].condition }}'
        attributes:
          temperature: '{{ state_attr("weather.kotipaikka", "temperature") }}'
          humidity: '{{ state_attr("weather.kotipaikka", "humidity") }}'
          pressure: '{{ state_attr("weather.kotipaikka", "pressure") }}'
          wind_bearing: '{{ state_attr("weather.kotipaikka", "wind_bearing") }}'
          wind_speed: '{{ state_attr("weather.kotipaikka", "wind_speed") }}'
          condition: '{{ forecast_data["weather.kotipaikka"].forecast[0].condition }}'
          forecast: '{{ forecast_data["weather.kotipaikka"]["forecast"] }}'

 

[jämä67]

Kiitokset vinkeistä! Jatketaan harjoitteluja ja testailuja heti kun taas ehtii. Pääsi kanssa eilen illalla jo hiukan käyrryille videoiden avustuksella ja developer toolsin Actions ja template osissa sain jo jotain onnistumaankin. Varsinaista koodia en vielä saanut pelittämään.
edit: Hienosti menee jo sääennusteet uuteen sensoriin ja koodi tekee jo listan jo template editorissa. Jotain pientä kipua vielä omissa koodeissa listan tuonnissa varsinaiseen sensoriin, mutta eiköhän se täsä selviä ennen lämmityskauden alkua.

 

[Martta]

Morjesta, ensimmäistä kertaa kirjoittamassa tälle foorumille.

Otin nyt omaan Mitsubishi ILP:in ohjaukseen tuon blueprintin (click), joka säätää jatkuvasti pyyntilämpötilaa sähkön hinnan mukaan. Sain pienellä ähräyksella ja mistään mitään ymmärtämättä homman pelittämään, mutta nyt haluaisin muokata tuota blueprintin toimintaa erilaiseksi.

Tuo blueprint (click) sanoo tekevänsä seuraavaa:

... continuously control for example a thermostat temperature during the day based on relative difference to the max price of today

Eli pyyntiä säädetään suhteessa maksimihintaan. Tuo on minusta vähän huono, koska yksittäisen tunnin hinta voi heilauttaa koko päivän lämmityksen aivan toisenlaiseksi.
esim:
Tilanne 1) Jos koko vuorokauden hinta on suunnilleen sama, mutta yksi tunti onkin todella kallis, niin ILP pöhöttää lähes koko päivän maksimilämmöillä.
Tilanne 2) jos tuota yhtä kallista tuntia ei ole, niin pyyntilämpötila heiluu asetettujen maksimiarvojen välillä pitkin päivää.

Haluaisinkin mielummin systeemin, jossa kyseisen tunnin "Rank" mäppäytyisi suoraan pyyntilämpötilaan esim. 18 - 23 Celsiuksen välillä. Mitenkähän tuon saisi tehtyä? Jotenkin kauhean vaikeaselkoiselta tuntuu nuo HomeAssistantin "koodaaminen".

 

[haraldh]

Minulla on pari automaatiota jotka ohjaavat ilmalämpöpumppujen termostaattia niin että mikäli "SHF Price acceptable" on kyllä tai "SHF Rank acceptable" on kyllä niin silloin asetan termostaatin 2 astetta korkeammalle. Jos on kallis hinta tai tunnin rank on yli asetetun rajan niin 2 astetta matalemmalle lämpötilapyynnille. Muoks, käytän itse asiassa tuota "SHF Price or Rank acceptable" kilkettä.

 

[Luukku]

Morjesta, ensimmäistä kertaa kirjoittamassa tälle foorumille.

Otin nyt omaan Mitsubishi ILP:in ohjaukseen tuon blueprintin (click), joka säätää jatkuvasti pyyntilämpötilaa sähkön hinnan mukaan. Sain pienellä ähräyksella ja mistään mitään ymmärtämättä homman pelittämään, mutta nyt haluaisin muokata tuota blueprintin toimintaa erilaiseksi.

Tuo blueprint (click) sanoo tekevänsä seuraavaa:

Eli pyyntiä säädetään suhteessa maksimihintaan. Tuo on minusta vähän huono, koska yksittäisen tunnin hinta voi heilauttaa koko päivän lämmityksen aivan toisenlaiseksi.
esim:
Tilanne 1) Jos koko vuorokauden hinta on suunnilleen sama, mutta yksi tunti onkin todella kallis, niin ILP pöhöttää lähes koko päivän maksimilämmöillä.
Tilanne 2) jos tuota yhtä kallista tuntia ei ole, niin pyyntilämpötila heiluu asetettujen maksimiarvojen välillä pitkin päivää.

Haluaisinkin mielummin systeemin, jossa kyseisen tunnin "Rank" mäppäytyisi suoraan pyyntilämpötilaan esim. 18 - 23 Celsiuksen välillä. Mitenkähän tuon saisi tehtyä? Jotenkin kauhean vaikeaselkoiselta tuntuu nuo HomeAssistantin "koodaaminen".

Kynnysarvosensorit on myös käteviä säätötyökaluja. Kannattaa tutustua. Jos esim sähkönhinta pysyy tiettyjen arvojen sisällä niin normi lämpö, mutta jos ylittää jonkun rajan niin sitten muuttaa lämpöpyyntiä.
Ensin pitää tehdä se sensori ja sitten automaatio seuraa sitä.
Apureista löytyy.

 

[Tekniikkatulitaloon]

Morjesta, ensimmäistä kertaa kirjoittamassa tälle foorumille.

Otin nyt omaan Mitsubishi ILP:in ohjaukseen tuon blueprintin (click), joka säätää jatkuvasti pyyntilämpötilaa sähkön hinnan mukaan. Sain pienellä ähräyksella ja mistään mitään ymmärtämättä homman pelittämään, mutta nyt haluaisin muokata tuota blueprintin toimintaa erilaiseksi.

Tuo blueprint (click) sanoo tekevänsä seuraavaa:

Eli pyyntiä säädetään suhteessa maksimihintaan. Tuo on minusta vähän huono, koska yksittäisen tunnin hinta voi heilauttaa koko päivän lämmityksen aivan toisenlaiseksi.
esim:
Tilanne 1) Jos koko vuorokauden hinta on suunnilleen sama, mutta yksi tunti onkin todella kallis, niin ILP pöhöttää lähes koko päivän maksimilämmöillä.
Tilanne 2) jos tuota yhtä kallista tuntia ei ole, niin pyyntilämpötila heiluu asetettujen maksimiarvojen välillä pitkin päivää.

Haluaisinkin mielummin systeemin, jossa kyseisen tunnin "Rank" mäppäytyisi suoraan pyyntilämpötilaan esim. 18 - 23 Celsiuksen välillä. Mitenkähän tuon saisi tehtyä? Jotenkin kauhean vaikeaselkoiselta tuntuu nuo HomeAssistantin "koodaaminen".

Ymmärrän kysymyksen hyvin, mutta vasta viikko sitten aloin itsekin HA:lla leikkimään joten täydellistä vastausta en pysty antamaan. Tuota nykyistä automaatiota voisi modata esim vähentämällä pyyntölämpötilasta RANK/10 ja säätämällä alkuperäisen vaihteluvälin hieman pienemmäksi. Eli itse tekisin tuolla rank säädölle oman sensorin jonka sitten vähentäsin asetusarvosta.

Yritin nyt turata vähän jotain konkreettistakin ja lisäsin vielä että ottaa huonelämpötilankin (sensor.1_temperature_humidity_sensor_temperature) mukaan tuohon säätöön eli tämmöinen koodin pätkä /homeassistant/configuration.yaml tiedostoon:

template:
  - sensor:
        name: "lampotilan_pudotus"
        unit_of_measurement: "°C"
        state: >
          {% set rank = states('sensor.shf_rank_now') | float %}
          {% set lampotila = states('sensor.1_temperature_humidity_sensor_temperature') | float %}
          {{  ((rank / 10 + (lampotila-22)) /2 ) | round(1, default=0) }}

ja tämän näköiseksi /homeassistant/blueprints/automation/T3m3z/continuous-control.yaml tiedosto:

blueprint:
  name: 'SHF: Adjust Climate entity target temperature based on SHF Control Factor.'
  domain: automation
  source_url: https://github.com/T3m3z/spotprices2ha/blob/main/blueprints/automation/shf-spotprices2ha/continuous-control.yaml
  author: shf-spotprices2ha
  input:
    min_value:
      name: Minimum value
      description: Minimum value that is going to be set. For example 22 Celsius for
        heatpump temperature.
      default: 22
      selector:
        number:
          min: -1000000000.0
          max: 1000000000.0
          step: any
          mode: box
    max_raise:
      name: Maximum raise from minimum value.
      description: If minimum value is 22 and maximum raise is 2, then control values
        will be between 22 and 24.
      default: 2
      selector:
        number:
          min: -1000000000.0
          max: 1000000000.0
          step: any
          mode: box
    entity:
      name: Entity
      description: Only used if trigger type is Entity Trigger. Select random entity
        if using Time Trigger.
      selector:
        entity:
          filter:
          - domain:
            - climate
            - input_number
          multiple: false
variables:
  min_value: !input min_value
  max_raise: !input max_raise
  entity: !input entity
trigger:
- platform: state
  entity_id: sensor.shf_control_factor_0_1
action:
- if:
  - condition: template
    value_template: '{{ ''input_number.'' in entity }}'
  then:
  - service: input_number.set_value
    entity_id: !input entity
    data:
      value: '{{ min_value + states(''sensor.shf_control_factor_0_1'') | float * max_raise - states(''sensor.lampotilan_pudotus'') | float
        }}'
  else:
  - service: climate.set_temperature
    entity_id: !input entity
    data:
      temperature: '{{ min_value + states(''sensor.shf_control_factor_0_1'') | float
        * max_raise - states(''sensor.lampotilan_pudotus'') | float
         }}'

Ja vielä muistutus lopuksi että omalla vastuulla koska itsekin ihan amatööri.

 

[Luukku]

Tässä ympättynä samaan automaatioon kynnyssensori rank yli 10 muuttaa ilpin asetusta ja jos "rank 10" sensori on pois päältä niin tekee eri toiminnon.

 

[Luukku]

description: ""
mode: single
trigger:
  - platform: state
    entity_id:
      - binary_sensor.rank_10_kynnys
    to: "on"
condition: []
action:
  - device_id: oma kone
    domain: climate
    entity_id: b09f28c400b59997cc345133d5a37c50
    type: set_preset_mode
    preset_mode: eco
  - if:
      - condition: state
        entity_id: binary_sensor.rank_10_kynnys
        state: "off"
      - condition: numeric_state
        entity_id: sensor.shf_electricity_price_now
        below: 0.13
    then:
      - device_id: oma kone
        domain: climate
        entity_id: b09f28c400b59997cc345133d5a37c50
        type: set_preset_mode
        preset_mode: none

 

[Martta]

Ymmärrän kysymyksen hyvin, mutta vasta viikko sitten aloin itsekin HA:lla leikkimään joten täydellistä vastausta en pysty antamaan. Tuota nykyistä automaatiota voisi modata esim vähentämällä pyyntölämpötilasta RANK/10 ja säätämällä alkuperäisen vaihteluvälin hieman pienemmäksi. Eli itse tekisin tuolla rank säädölle oman sensorin jonka sitten vähentäsin asetusarvosta.

Rankin jakolasku onkin nerokkaan yksinkertainen ratkaisu tähän! En tajunnutkaan, että rank on ihan tavallinen kokonaisluku siinä missä muutkin muuttujat ja sitä voisi suoraan hyödyntää yksinkertaisilla jako ja kertolaskuilla. Tuosta alkuperäisestä blueprintistä oikeastaan kun vain korvaan tuon laskukaavan olemaan RANK/24, niin saan suoraan "normalisoitua" rankin 0.0 - 1.0 välille. Kaava olisi siis pseudokoodina MINIMI_PYYNTI + ( RANK/24 ) * MAX_NOSTO, missä minimipyynti olisi esim. 18 astetta ja MAX_NOSTO 3 astetta, niin säätelis sitten 18 - 23 asteen välillä lämpötilaa.

Kun käytän RANKkia laskennan perusteena sähkön suhteellisen hinnan sijasta, pysyy lämmityksen määrä vuorokauden aikana "vakiona". Näin yhden tunnin korkea piikki ei saa koko muuta päivää näyttämään algoritmin silmissä halvalta. Ja muutenkin pelkästään RANK huomioimalla on hieman helpompi ennakoida paljonko asuntoon pumpataan lämpöä päivän aikana.

 

[haraldh]

Miten tuo varttitase ja tämä integraatio? Muuttuuko rank niin että se on 0 - 96?

 

[Temez]

Miten tuo varttitase ja tämä integraatio? Muuttuuko rank niin että se on 0 - 96?

Joo, näin se taitaa olla. Heti kun datalähteeseen ilmestyy enemmän hinta-arvoja eli mennään siihen varttiaikatauluun, niin sensori "SHF Rank now" alkaa näyttää sitten suurempia lukuja.

En kokeillut, mutta koodia pienessä univajeessa koetin tulkkailla.

 

[haraldh]

Pitäisikö tässä olla joku /4 vipu softassa, ja sitten kun käyttäjä on säätänyt rajansa uusiksi voisi laittaa varttitaseen päälle omassa HA:ssa?

 

[Mikki]

Pitäisikö tässä olla joku /4 vipu softassa, ja sitten kun käyttäjä on säätänyt rajansa uusiksi voisi laittaa varttitaseen päälle omassa HA:ssa?

Ajatus on APIn suhteen että nykyinen toimii kuten nykyäänkin, eli 24h ja tunneille varteista lasketut keskihinnat. Ihan vain etei riko mitään. Varttihommat on sitten API päässäkin joku uusi parametri tai url.

 

[grendy]

Pienillä muokkauksilla, kyllä. Kiitos paljon.

type: custom:apexcharts-card
experimental:
  color_threshold: true
now:
  show: true
  label: Nyt
graph_span: 24h
apex_config:
  annotations:
    position: back
  chart:
    height: 300px
  legend:
    showForSingleSeries: true
  plotOptions:
    bar:
      borderRadius: 1
  yaxis:
    - id: second
      decimalsInFloat: 2
      tickAmount: 10
      forceNiceScale: true
    - id: first
      decimalsInFloat: 1
      tickAmount: 1
      forceNiceScale: true
      opposite: true
  xaxis:
    labels:
      datetimeFormatter:
        hour: HH
all_series_config:
  show:
    offset_in_name: false
header:
  title: ' '
  show: true
  show_states: true
  colorize_states: true
span:
  start: day
  offset: +0h
series:
  - entity: sensor.nordpool_kwh_fi_eur_3_095_024
    yaxis_id: first
    type: column
    color: green
    float_precision: 4
    stroke_width: 1
    name: Tänään
    show:
      in_header: false
      legend_value: false
      extremas: true
    data_generator: |
      return entity.attributes.raw_today.map((start, index) => {
        return [new Date(start["start"]).getTime(), entity.attributes.raw_today[index]["value"]];
      });
    color_threshold:
      - value: 0
        color: purple
      - value: 3
        color: green
      - value: 6
        color: orange
      - value: 12
        color: red
  - entity: sensor.nordpool_kwh_fi_eur_3_095_024
    yaxis_id: first
    attribute: current_price
    name: Hinta nyt
    color: green
    type: column
    show:
      in_chart: false
    float_precision: 2
  - entity: sensor.nordpool_kwh_fi_eur_3_095_024
    yaxis_id: first
    attribute: average
    name: Keskiarvo
    type: column
    color: pink
    float_precision: 2
    stroke_width: 1
    group_by:
      duration: 2d
    show:
      in_chart: false
      legend_value: false
  - entity: sensor.nordpool_kwh_fi_eur_3_095_024
    yaxis_id: first
    attribute: max
    type: column
    color: orange
    float_precision: 2
    stroke_width: 2
    name: Max
    group_by:
      duration: 2d
    show:
      in_chart: false
      legend_value: false
  - entity: sensor.nordpool_kwh_fi_eur_3_095_024
    yaxis_id: first
    attribute: min
    type: column
    color: green
    float_precision: 4
    stroke_width: 2
    name: Min
    group_by:
      duration: 2d
    show:
      in_chart: false
      legend_value: false
  - entity: sensor.temp_control_24h
    yaxis_id: second
    type: line
    color: blue
    stroke_width: 1
    name: Heat Control
    show:
      in_header: false
      legend_value: false
      extremas: true
    group_by:
      func: last
      duration: 60min
      fill: last
    data_generator: |
      return entity.attributes.data
        .map((d, i) => {
          return [new Date().setHours(i,0,0,0), d];
        });

Tuon heat_control sensorin idea on, että voin liukukytkimillä määrittää vuorokaudelle kalliit tunnit esim. 4 kpl, ja halvat tunnit esim. 5 kpl. Muut tunnit ovat sitten normitunteja lämmitysmielessä. Tämän perusteella voi ohjata ILP:iä, lattia- ja kattotermostaatteja suorasähkötalossa.

Vastaava periaate mulla on jo käytössä, mutta halusin nähdä ennakkoon ns. "lämmityssuunnitelman" vuorokaudelle. Tämä mahdollistui nyt, kiitokset siitä Dillonille.

Lopputulos:
katso liitettä 96005

Seuraava steppi olisi tehdä toinen sensori, joka osaisi verrata tuntia X tuntien X+1 - X+2 keskiarvoon. Mikäli seuraavien tuntien keskiarvo olisi kertoimen Y (helper) verran suurempi tai pienempi kuin hetken X hinta, tämän perusteella voisi ohjata ennakkoon lämpöjä ylös tai alas. Ajatus oli hyödyntää sensor.shf_average_price_next_hours sensoria tähän. Mutta tosiaan, homma on hieman monimutkaisempi koska tuo vertailu pitäisi tehdä koko vuorokauden ajalta verraten jokaista tuntia seuraaviin pariin tuntiin.

No, jos joku innostuu tätä jossain kohtaa värkkäämään niin bueno. Ei tuo koodaaminen oo omaa osaamista yhtään, vaikka IT-alalla olenkin.

Täällä toinen IT-alalla oleva joka ei koodaamisesta oo ikinä innostunut, mutta siitä olisin kyllä innostunut, että saisin Daikinin VILPin pörssiohjaukseen HA:n kautta! Joko automaattisesti juuri X määrää kalleimpia tunteja pois päältä tai sitten halvimpien kautta, mutta kalleimmat olisi järkevin jättää omasta mielestä pois. Oisko tästä sellasta entistä dummympää versioo kun en ymmärtänyt tota "sensor.temp_control_24h" juttua yhtään, että pitäiskö sellanen sensori tehdä johonkin ja jotenkin vai hä? .. Oon vielä erittäin dummy näissä HA-asioissa. HA:n etusivu alkaa näyttään ihan hyvältä, mutta nyt kaipaisi sitten tähän pörssisähköön jotain automaatiota. Samaineen Nordpool-sensori on asenenttu ja tuo apex-charts. Eli offset-säätöä -1 tai -2C tietyille kalleille tunneille.

 

[haraldh]

Tee uusi automaatio jossa triggeri on "When SHF Price or Rank acceptable changes to On" ja action on "Climate: set target temperature". Ei tarvitse koodata. Tämä edellyttäen että sinulla on siis A) ILP näkyvissä ja käytettävissä Home Assistantissa ja B) sinulla on tuo SHF / Spot-hinta.fi integraatio käytössä joka löytyy tuosta; https://github.com/T3m3z/spotprices2ha .

Itsellä on pyynti X 18 tuntia vuorokaudesta, ja 6 tuntia X - 2°C. Tuon kynnyksen voi säätää liukusäätimestä.

 

[grendy]

Tee uusi automaatio jossa triggeri on "When SHF Price or Rank acceptable changes to On" ja action on "Climate: set target temperature". Ei tarvitse koodata. Tämä edellyttäen että sinulla on siis A) ILP näkyvissä ja käytettävissä Home Assistantissa ja B) sinulla on tuo SHF / Spot-hinta.fi integraatio käytössä joka löytyy tuosta; https://github.com/T3m3z/spotprices2ha .

Itsellä on pyynti X 18 tuntia vuorokaudesta, ja 6 tuntia X - 2°C. Tuon kynnyksen voi säätää liukusäätimestä.

Ei löydy vielä SHF:ää mutta monta kertaa se tätä ketjua selatessa tuli vastaan, eli otetaas siitä sitten projekti perehtyä siihen!

 

[haraldh]

Minusta tuntuu että tämä ketju käsittelee nimenomaan tuota SHF-integraatiota. Ketjun viestissä #2 kerrotaan asennuksesta.

 

[grendy]

Minusta tuntuu että tämä ketju käsittelee nimenomaan tuota SHF-integraatiota. Ketjun viestissä #2 kerrotaan asennuksesta.

Joo yleensä lähden selaan aina lopusta kohti alkua kun voi olla jo vanhimmissa viesteissä hommat vanhentunut käsiin.

Nyt on jonkin sortin automaatio yritetty räpeltää tuohon. Se on kaikissa HA automaatioissa jäänyt vähän epäselväksi, että jos nyt yritin tehdä automaation mikä muuttaa VILPin lämpötilaoffsettiä -1C kun:

When SHF Rank acceptable changes from On to Off​

And if

If SHF Price acceptable is Off​

Then do

Climate 'Set target temperature' on VILP Leaving Water Offset -1C​

niin pitääkö kaikille automaatioille tehdä aina vasta-automaatio, vai osaako toi nyt palata takaisin offsettiin 0C kun noi automaation ehdot ei täyty?

Tässä muuten vielä toi YAML jos joku haluaa naureskella .. Max rank allowed pistin 20 ja max price allower 0,13€. Eli idea on että jos hinta on alle 13snt niin saa käydä 24/7 ihan sama mikä arvo rankilla on. Mutta jos hinta on yli 13snt niin sitten 4 kalleinta tuntia menisi -1C offsetillä.

alias: VILP -1C kun Rank acceptable OFF
description: VILP -1C kun Rank acceptable OFF
triggers:
- trigger: state
entity_id:
- binary_sensor.shf_rank_acceptable
from: "on"
to: "off"
conditions:
- condition: state
entity_id: binary_sensor.shf_price_acceptable
state: "off"
actions:
- action: climate.set_temperature
metadata: {}
data:
temperature: -1
target:
entity_id: climate.vilp_leaving_water_offset
mode: single

 

[Ville-Veikko]

niin pitääkö kaikille automaatioille tehdä aina vasta-automaatio, vai osaako toi nyt palata takaisin offsettiin 0C kun noi automaation ehdot ei täyty?

Makuasia, molemmissa on puolensa. On-off tyyppisen toiminnon saa if -ehdolla jossa on ehto jolloin tehdään jotakin ja else lohkoon sen vastinpari. Esimerkiksi näin:

 

[grendy]

Makuasia, molemmissa on puolensa. On-off tyyppisen toiminnon saa if -ehdolla jossa on ehto jolloin tehdään jotakin ja else lohkoon sen vastinpari. Esimerkiksi näin:

katso liitettä 101561

Kiitos vinkistä! Kokeilin tehdä tuolla saman asian .. Nyt ei ookkaan hetkeen tiedossa kovia sähkönhintoja joten toimivaksi toteaminen jää sit myöhemmäksi

 

[timop]

Kannattaa harkita sitä timerin käyttöä ettei esim home assistantin buuteissa jää virrat päälle tai pois. Onhan siinä vähän jumppaa muutella nuo jos on paljon.
Hyvä opastus video

 

[Ville-Veikko]

Kannattaa harkita sitä timerin käyttöä ettei esim home assistantin buuteissa jää virrat päälle tai pois. Onhan siinä vähän jumppaa muutella nuo jos on paljon.

Totta turiset, sopivaan kohtaan bootti niin keskenhän nuo automaatiot menee. Pitääpä silmäillä nuo läpi onko jotain kriittistä jäänyt huomioimatta. Delay oli helpoin tapa hoitaa sammutus eikä aikoinaan tullut asiaa enemmän ajateltua.

Kiinteät ajastukset on helppo tehdä scheduler cardilla: https://github.com/nielsfaber/scheduler-card tuon olen todennut toimivan luotettavasti. Jännä että noin perusasiaan ei HA:ssa ole vieläkään ominaisuutta, vaan HACSin kautta piti etsiä ratkaisu.

 

[timop]

Delayllä itekki tein kaikki ja yleensä ei ongelmia.joskus joku jumi kun buuttia tai muuten vaa ha restarttia.
kunnes törmäsin tuohon.
Noissa on hyvä kun nakkaa timerin kuikkaan niin sitä voi käskyttää sieltäkin (start, pause, cancel, finish).
Schedulercard on myös tuttu, sillä tehtyjä ei kylläkään ohjauksia tällä hetkellä.

 

[grendy]

Makuasia, molemmissa on puolensa. On-off tyyppisen toiminnon saa if -ehdolla jossa on ehto jolloin tehdään jotakin ja else lohkoon sen vastinpari. Esimerkiksi näin:

Nyt meni sormi suuhun enkä ihan tajunnut tota näemmä. Eli tosiaan tarkoitus oli saada 4 kalleimmalle tunnille (rank acceptable) VILP lämpötilaoffset -1C kun hinta on yli 13snt (price acceptable). Joo toimii hienosti, mutta tosiaan sitten kun kerran on tullut tällainen -1C tunti, ei palatakaan enää 0C offsettiin. Luulin että toi ELSE-olisi tehnyt tuon palautuksen, mutta ei se niin toiminutkaan.

Eli kuten kysäsin aiemminkin niin pitääkö tällaisille automaatioille olla joku päinvastainen automaatio, eli tässä tapauksessa about sama automaatio mutat päinvastaisilla arvoilla noissa SHF-sensoreissa? Vai pitäiskö toi ELSE tai joku muu vastaava lause olla jotenkin eri tavalla konffattu? Esimerkiksi että toi skripti ajetaan joka tunti tms? Koska jos ajan ton skriptin niillä tunneilla kun on halpaa ja rank on hyvä niin sitten toi kyllä palauttaa ELSEn mukaisesti offsetin 0C. Heelp!

alias: VILP -1C kun Rank ja Price acceptable OFF, ELSE-versio
description: VILP -1C kun Rank ja Price acceptable OFF, ELSE-versio
triggers:
- trigger: state
entity_id:
- binary_sensor.shf_rank_acceptable
from: "on"
to: "off"
conditions: []
actions:
- if:
- condition: state
entity_id: binary_sensor.shf_price_acceptable
state: "off"
then:
- action: climate.set_temperature
metadata: {}
data:
temperature: -1
target:
entity_id: climate.vilp_leaving_water_offset
else:
- action: climate.set_temperature
metadata: {}
data:
temperature: 0
target:
entity_id: climate.vilp_leaving_water_offset
mode: single

 

[Ville-Veikko]

Nyt meni sormi suuhun enkä ihan tajunnut tota näemmä. Eli tosiaan tarkoitus oli saada 4 kalleimmalle tunnille (rank acceptable) VILP lämpötilaoffset -1C kun hinta on yli 13snt (price acceptable). Joo toimii hienosti, mutta tosiaan sitten kun kerran on tullut tällainen -1C tunti, ei palatakaan enää 0C offsettiin. Luulin että toi ELSE-olisi tehnyt tuon palautuksen, mutta ei se niin toiminutkaan.

Eli kuten kysäsin aiemminkin niin pitääkö tällaisille automaatioille olla joku päinvastainen automaatio, eli tässä tapauksessa about sama automaatio mutat päinvastaisilla arvoilla noissa SHF-sensoreissa? Vai pitäiskö toi ELSE tai joku muu vastaava lause olla jotenkin eri tavalla konffattu? Esimerkiksi että toi skripti ajetaan joka tunti tms? Koska jos ajan ton skriptin niillä tunneilla kun on halpaa ja rank on hyvä niin sitten toi kyllä palauttaa ELSEn mukaisesti offsetin 0C. Heelp!

Äkkivilkasulla fiba lienee triggerissä ota molemmat to ja from ehdot pois, se ei nyt laukee kun toiseen suuntaan.

 

[grendy]

Äkkivilkasulla fiba lienee triggerissä ota molemmat to ja from ehdot pois, se ei nyt laukee kun toiseen suuntaan.

Mutta niin sen pitäisikin mennä. Eli rankin mukainen karsinta ainoastaan jos on liian kallista sähköä. Ei oo tarkoitus toimia toiseen suuntaan. Ainut miten tota pitäis saada parannettua on se, että sitten kun molemmat ehdot täyttyy juuri tuossa järjestyksessä, niin sen jälkeen kun tilanne "normalisoituu ja noi ehdot ei enää täyty, niin tulee paluu normitilanteeseen eli offset -1C -> 0C.

Eilen ja tänään tuli ekaa kertaa siis todettua että ehdot toimi just niinkun halus, mut tilanne ei normalisoitunut ollenkaan, vaikka hinta olis pudonnut miinukselle.

 

[Karvakuono]

Vika tuossa triggerissä, kuten V-V jo totesi. Else haaraan ei mennä, kun automaatio ajetaan vain kun binary_sensor.shf_rank_acceptable menee ON -> OFF. Halvan tunnin tullessa vastaan binary_sensor.shf_rank_acceptable menee OFF -> ON.

 

[Pretor]

Mutta niin sen pitäisikin mennä. Eli rankin mukainen karsinta ainoastaan jos on liian kallista sähköä. Ei oo tarkoitus toimia toiseen suuntaan. Ainut miten tota pitäis saada parannettua on se, että sitten kun molemmat ehdot täyttyy juuri tuossa järjestyksessä, niin sen jälkeen kun tilanne "normalisoituu ja noi ehdot ei enää täyty, niin tulee paluu normitilanteeseen eli offset -1C -> 0C.

Eilen ja tänään tuli ekaa kertaa siis todettua että ehdot toimi just niinkun halus, mut tilanne ei normalisoitunut ollenkaan, vaikka hinta olis pudonnut miinukselle.

Niin... jos laitat käsin valot päälle OFF -> ON, niin sammuuko ne valot ON -> OFF ilman, että sammutat ne käsin?
Jos nyt käsket sen automaation "laittaa valot päälle", niin pitäähän sen automaationkin tietää milloin ne valot sammutetaan, tai muuten ne jää palamaan hamaan tulevaisuuteen asti.
Eli kyllä, tuolla tavalla tarvitset toisen päinvastaisen automaation sille OFF -> ON muutokselle.

Laita esim. automaatioon triggeriksi tuon rank-attribuutin vaihtuminen mihin tahansa muotoon (eli ON, tai OFF). Sen jälkeen sitten automaatio laukaisee halutun toiminnan sen mukaan kumpi siellä sattuu olemaan sillä hetkellä päällä.
If ON, then...
If OFF, then...
Silloin se laukaisee saman automaation sisällä eri toiminnan ON ja OFF -tiloille ilman, että molemmille (ON->OFF & OFF->ON) pitää olla määritetty oma erillinen automaatio.


Toi automaatioiden teko noista "palikoista" on nykyään helpottunut/monipuolistunut aika paljonkin. Mulla on vieläkin joitain noita alkuaikojen automaatioita, jossa tosiaan on ensin automaatio jollekin toiminnolle ja sitten sille toinen vasta-automaatio omana automaationa. Nykyään niin paljon helpompi tehdä kaikki saman automaation alle.

 

[grendy]

Aah okei, tottakai. Onhan toi ihan loogista. Ei varmaan yllätä ketään että koodaaminen on ollut inhokkihommaa koko elämän kun ei oikein logiikkaa oo sisäistänyt.

Kokeilin nyt tuon"ota pois molemmat ehdot to ja from pois ja testaan että noinko toi logiikka toimii. Nyt ainakin visual editorissa lukee "When SHF Rank acceptable changes state or any attributes" joten sen pitäisi sen perusteella laueta molempiin suuntiin, mutta tosta actionsin ifistä en oo ihan varma toimiiko. Mutta se selvinnee tunnin sisään. Jos ei toimi niin sitten pitää lukea ajatuksella Pretorin viesti .. Kiitos kun jaksatte yksinkertaista opastaa!

alias: VILP -1C kun Rank ja Price acceptable OFF, ELSE-versio
description: VILP -1C kun Rank ja Price acceptable OFF, ELSE-versio
triggers:
- trigger: state
entity_id:
- binary_sensor.shf_rank_acceptable
conditions: []
actions:
- if:
- condition: state
entity_id: binary_sensor.shf_price_acceptable
state: "off"
- condition: state
entity_id: binary_sensor.shf_rank_acceptable
state: "off"
then:
- action: climate.set_temperature
metadata: {}
data:
temperature: -1
target:
entity_id: climate.vilp_leaving_water_offset
else:
- action: climate.set_temperature
metadata: {}
data:
temperature: 0
target:
entity_id: climate.vilp_leaving_water_offset
mode: single

 

[Pretor]

En muista onko tuossa SHF-paketissa nykyään oma binary.sensor tuolle Rank & Price Acceptable. Ei tarvitse välttämättä kahta eri sensoria käyttää triggereissä.
Sen jälkeen voi siis käyttää triggerinä sitä, että kummatkin on ON, tai OFF (sen toisen sensorin lisäksi, jossa riittää, että jompi kumpi on ON, tai OFF).
Jos ei ole, niin sen saa itsekin lisättyä sinne spotprice-yamliin:

  - binary_sensor:
    - name: "SHF Price and Rank acceptable"
      unique_id: shf_price_and_rank_acceptable
      device_class: power
      state: '{{is_state("binary_sensor.shf_rank_acceptable", "on") and is_state("binary_sensor.shf_price_acceptable", "on") }}'

 

[grendy]

En muista onko tuossa SHF-paketissa nykyään oma binary.sensor tuolle Rank & Price Acceptable. Ei tarvitse välttämättä kahta eri sensoria käyttää triggereissä.
Sen jälkeen voi siis käyttää triggerinä sitä, että kummatkin on ON, tai OFF (sen toisen sensorin lisäksi, jossa riittää, että jompi kumpi on ON, tai OFF).
Jos ei ole, niin sen saa itsekin lisättyä sinne spotprice-yamliin:

  - binary_sensor:
    - name: "SHF Price and Rank acceptable"
      unique_id: shf_price_and_rank_acceptable
      device_class: power
      state: '{{is_state("binary_sensor.shf_rank_acceptable", "on") and is_state("binary_sensor.shf_price_acceptable", "on") }}'

Se valmis sensori oli "rank OR price acceptable" joten en voinut käyttää .. Mutta okei joo, en tollasta olis todellakaan osannut tehdä.

Mutta vaikutti toimivan toi munkin muokattu viritys! Vähän pidempi koodi mutta en anna sen tässä haitata, kiitos avusta! Toivottavasti ei tuu takapakkia vielä toimivuuteen kun jotain odottamatonta tapahtuu

Seuraava steppi oliskin sitten muokata tuosta täydellinen, eli että osaisi Synergien ja Kapacity.io:n tyyliin nostaa myös offsettiä juuri ennen kalleita tunteja +1C:llä JOS taas eri ehdot täyttyy. Toistaiseksi jääkööt odottaan pöytälaatikkoon ton tekeminen.

 

[Ville-Veikko]

Mutta se selvinnee tunnin sisään.

Eipä sitä tarvitse odotella, Developer -States -sivulla voi tiloja muutella käsin. Tuo laukoo triggerit ja automaatiot samoin kuin ne toimisivat muutenkin. Nopea testata eikä tarvitse jännittää mitenköhän käy klo 4 aamuyöstä

 

[grendy]

Aika kivasti toiminut tää offset-automaatio! Tai siis home assistantin näkökulmasta ihan täydellisesti ilman ongelmia, mutta sen mitä käytännön tasolla oon huomannut Daikin Altherma 3R vilpin kanssa on se, että lähes joka kerta kun offset muuttuu "näillä keleillä" joko miinukselle tai plussalle takaisin nollaksi, laite vetää sulatuksen. En joka kerta, mutta mutulla ~80% kerroista. Ja jokainen sulatus taitaa kuitenkin viedä ylimääräistä energiaa "turhaan" niin olis kiva tietää että kuinkahan paljon sähköä/euroja lopulta tässä pörssisähköoptimoinnissa toistaiseksi on tullut voitettua edes .. Sehän riippuu tietysti siitäkin että onko noi 4 kalleinta tuntia peräkkäin jolloin muutoksia tulee vähemmän, vai onko se ripoteltu useampaan ryppääseen, jolloin potentiaalinen sulatusten määrä kasvaa.

No, kiinnostavaa on ainakin! Ja mitä nyt muita pörssisähköön liittymättömiä automaatioita oon viritellyt HA:lla niin onhan toi monipuolinen työkalu ei voi muuta sanoa. Olis varmaan pitänyt viritellä jo aikaisemmin kaapissa pölyttymässä ollut Raspberry tähän hommaan

 

[Pretor]

@grendy
Ihan mielenkiinnosta, että mitä lämpötiloja säädät? Meinaan ainakin pattereilla tuo 1'c säätö menovedessä on lähes yhtä tyhjän kanssa, jos 4'c vastaa sisälämpötilassa noin yhtä astetta.
Itse seisotan koko VILPiä kalliiden tuntien aikaan ulkolämpötilasta riippuen 1-8h. 500l varaaja antaa sillä aikaa reserviä sen minkä antaa pienen hetken.

 

[grendy]

@grendy
Ihan mielenkiinnosta, että mitä lämpötiloja säädät? Meinaan ainakin pattereilla tuo 1'c säätö menovedessä on lähes yhtä tyhjän kanssa, jos 4'c vastaa sisälämpötilassa noin yhtä astetta.
Itse seisotan koko VILPiä kalliiden tuntien aikaan ulkolämpötilasta riippuen 1-8h. 500l varaaja antaa sillä aikaa reserviä sen minkä antaa pienen hetken.

Lattialämmityksen offsettiä, eli -1C siitä mitä käyrä/asetukset ohjaa. Tällä hetkellä pyörii näemmä siinä 30C molemmin puolin. Mitään varaajaa ei meillä oo, eli vilp lämmittää ihan suoraan lattialämmitysvettä (ainoastaan, ei käyttövettä). Tää mun -1C "säästö" oli ihan vaan ensimmäinen testi minkä keksin tehdä, eli pitää testailla ihan reipasta pudotusta vaikka seuraavaksi jolloin kompura sammuu kokonaan, nythän se ei sammu mihinkään vaan laskee vaan vähän tehoja (käytännössä lähes huomaamattoman verran).

Daikinin ILPillähän on vähän sama homma, että tarveohjausta/pyyntiä kun muutti niin usein se johti sulatukseen, eli joku jatkumo siellä pettää kun kehtasi mennä koskeen asetuksiin kesken tasaisen suorittamisen

 

[Ville-Veikko]

Lattialämmityksen offsettiä, eli -1C siitä mitä käyrä/asetukset ohjaa. Tällä hetkellä pyörii näemmä siinä 30C molemmin puolin. Mitään varaajaa ei meillä oo, eli vilp lämmittää ihan suoraan lattialämmitysvettä (ainoastaan, ei käyttövettä). Tää mun -1C "säästö" oli ihan vaan ensimmäinen testi minkä keksin tehdä, eli pitää testailla ihan reipasta pudotusta vaikka seuraavaksi jolloin kompura sammuu kokonaan, nythän se ei sammu mihinkään vaan laskee vaan vähän tehoja (käytännössä lähes huomaamattoman verran).

Daikinin ILPillähän on vähän sama homma, että tarveohjausta/pyyntiä kun muutti niin usein se johti sulatukseen, eli joku jatkumo siellä pettää kun kehtasi mennä koskeen asetuksiin kesken tasaisen suorittamisen

Vähän jyrkempää säätöä niin alkaa tapahtua. Mut ei siinä aina ole mitään järkeä. Hintaeroa pitää olla "riittävästi" jotta kannattaa rääkätä. Rank ei kerro hinnasta mitään, joten piti kehitellä jotain muuta.
Mä veivaan offsettia laskemalla hinnan eron seuraavan 6 tunnin keskihintaan (siirtohinta on mukana vertailussa kun mulla on yösiirto). Tekaisin ulkolämpötilariippuvaisen funkkarin jolla saan hintaeron skaalattua sopivaksi ohjausluvuksi +-10 astetta. Mitä kylmempää ulkona, sitä enemmän hinnassa pitää olla eroa että säädetään.

Homma toimii hyvin kun mulla on varaaja ja Ouman hoitamassa lämmitysverkkojen säädön, ylimääräinen lämpö jää varaajaan. Tänäänkin säätö on vaihdellut aamuyön +7 asteesta aamun -3 asteeseen. Aika usein aamun kalleimmat tunnit pumppu on pysähtyneenä kokonaan, tänäänkin 2h. Pysäytyksen hoitaa termostaatti. Kun varaajan keskilämpö = pumpun menoveden tavoite, termostaatti stoppaa pumpun. Pumppu uudestaan käyntiin kun keskilämpötila on 6 astetta alle tavoitteen. Koodi laittaa Oumanista poissa -tilan päälle siksi aikaa kun pumppu on seis. Tämä setup on meillä osoittautunut toimivaksi, en ole enää kuukauteen kajonnut tähän käsin.

Torpassa näillä keleillä lämpötilanvaihtelu on max asteen luokkaa. Hieman alkaa jäähtymään, jos hinta on laskussa pitkään jolloin pumppu tuottaa muutaman asteen viileämpää kuin patteriverkko tarvitsisi.

Parhaillaan pumppu himmailee offset -3 ja odottelee klo 22 alkavaa yösähköä ja halvempaa hintaa. Huomenna näkyy hinnat olevan tasaisempia, saa Altherma puksutella rauhassa.

Sähkönkulutukseen veivauksella ei loppupelissä taida suurta eroa olla. Jos antaisin käydä rauhassa, sellaiset n 50 kWh menisi silti vuorokaudessa näillä keleillä. Olen huomannut että COP paranee kun on kunnolla lämmitettävää, se osittain selittää asian.

 

[Pretor]

Hintaeroa pitää olla "riittävästi" jotta kannattaa rääkätä. Rank ei kerro hinnasta mitään, joten piti kehitellä jotain muuta.


Sähkönkulutukseen veivauksella ei loppupelissä taida suurta eroa olla.

Joo onhan tuossa itellä myös hintakin mukana ohjailemassa samaan aikaan, joten saattaa se VILP pyöriä 24h rankista riippumatta. Ei siis mennä pelkällä rankilla.

Ja lämmitys ottaa sen mitä ottaa, eli ei se kulutus siitä loppupeleissä muutu. Ideahan tuossa on vain vältellä niitä kalliita tunteja, vaikka sähköä meneekin saman verran loppupeleissä.
Kiritään lämpöä takaisin sitten halvemmilla tunneilla. Varsinkin noissa aamupäivän tunneissa voi olla todella isoja eroja.

 

[MarjoC]

Toimiiko nuo SHF:n blueprintit? Laitoin eilen kaksi uutta automaatiota (toisessa price or rank ja toisessa price and rank), joista price or rank ei mielestäni kyllä toimi ollenkaan. Laitoin rajaksi 0.2 Eur ja rankiksi 12 ja kone on kiinni ollut eilisestä. Ajanut tuon automaation eilen viimeksi, tosin tuo muuttuja ei ole tilaansakaan muuttanut. Aikaisemmin olen tehnyt omat automaatiot ja laittanut ne hinnan muutokseen kiinni. Silloin ainakin laukeaa automaatio aina kerran tunnissa. Mutta ideoita otetaan vastaan, miten saisin nyt tuon blueprintillä tehdyn automaation toimimaan. Vai luovutanko ja teen oman? Muuttuja binary_sensor.shf_price_or_rank_acceptable = on ja binary_sensor.shf_price_and_rank_acceptable = off tällä hetkellä, mutta vaikka ajan tuon automatiikan käsin, niin menee else haaraan ja laittaa laitteen off-tilaan. Muok: ei toimi tuo Price and Rank:kään. Otin nyt molemmat pois käytöstä ja kopioin kaikki rank muuttujat kahdeksi setiksi ja tein omat automaatiot. Harmi, koska nyt on tuplasetti SHF muuttujia käytössä, jotta saan eri aikaan LVV:n ja lämmityksen toimimaan...

 

[haraldh]

Miksi tämä automaatio ei triggeröidy kun sensor.shf_rank_now menee rajan alle?

alias: GaragetGree HEAT (+16°C) when rank < garaget max rank
description: ""
triggers:
  - entity_id:
      - sensor.shf_rank_now
    trigger: numeric_state
    below: input_number.garaget_max_rank
  - entity_id:
      - input_number.garaget_max_rank
    trigger: numeric_state
    above: sensor.shf_rank_now
conditions: []
actions:
  - data:
      preset_mode: none
    target:
      device_id: d41dda5c48f6bf5d84be046d5e0a4162
    action: climate.set_preset_mode
mode: single

Eilenkin oli yksi tunti muistaakseni 17-18 jolla oli rank 8. Ilmalämpöpumppu oli sitä huolimatta away tilassa vaikka rajana on 12.

edit: johtuu ilmeisesti tästä mun recorderin jumiinmenosta kun laitan saunan päälle. Kun sauna saavuttaa yli 39,9°C niin kaikki käppyrät muuttaa vaakaviivoiksi tunneiksi.

 

[MarjoC]

Onkohan mitään tietoa tarvitseeko tämä koodi päivitystä kun nyt kesäkuussa siirrytään 15 minuutin sykleihin kesäkuussa? @Temez?