HomeAssistant ja sähköpörssiohjaus

[Lartsa]

Moikka,

Mikäköhän olisi kätevin tapa saada käyttöliittymään yhden rivin tieto (kellonaika) koska halvimmat tunnit alkavat? Ja slideri jolla valitaan tuntien määrä. Tämä helpottaisi pesukoneiden ajastusta sopivalle ajankohdalle.

 

[Kake]

Moi taas.

Olisiko raadilla ajatusta, kuinka väsätä tällainen tarvittava muuttuja ja Apex-graafi.

Haluaisin ko. graafiin tuon sinisen kuvaajan siten, että kertoo lämmitystarpeen koko kuluvalle vuorokaudelle tunneittain. Tällä hetkellä näyttää vain menneisyden ja nykyhetken oikein. Ajatus on työstää tuota vielä myöhemmin siten että osaa verrata nykyistä tuntihintaa seuraaviin, ja tehostaa tai pudottaa lämmitystä sen mukaan. Tähän on hatara ajatus jo logiikasta (perustuen sensor.shf_average_price_next_hours sensoriin).

Mutta kaipaisin ymmärrystä, miten saisin tuohon siniseen käppyrään laskennan koko päivälle.

Nykyinen Koodi:

type: custom:apexcharts-card
experimental:
color_threshold: true
graph_span: 24h
show:
last_updated: true
loading: false
now:
show: true
color: red
label: Now
apex_config:
yaxis:
- id: second
decimalsInFloat: 2
tickAmount: 10
forceNiceScale: true
apex_config:
tickAmount: 4
- id: first
min: -2
max: 2
opposite: true
decimalsInFloat: 0
tickAmount: 1
forceNiceScale: true
apex_config:
tickAmount: 4
xaxis:
labels:
datetimeFormatter:
hour: HH
span:
start: day
header:
show: false
series:
- entity: sensor.nordpool_kwh_fi_eur_3_095_024
yaxis_id: second
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
group_by:
func: first
duration: 60min
- entity: sensor.control
yaxis_id: first
type: line
color: blue
stroke_width: 1
name: Control
group_by:
func: last
duration: 60min
fill: last

Tuo control - sensorin arvo määräytyisi seuraavasti:
- jos tunnin x rank on suurempi kuin slider1:n arvo, arvoksi tulee -1
- jos tunnin x rank on pienempi kuin slider2:n arvo, arvoksi tulee 1
- muissa tapauksissa arvo on 0

 

[dillon]

Moi taas.

Olisiko raadilla ajatusta, kuinka väsätä tällainen tarvittava muuttuja ja Apex-graafi.

Haluaisin ko. graafiin tuon sinisen kuvaajan siten, että kertoo lämmitystarpeen koko kuluvalle vuorokaudelle tunneittain. Tällä hetkellä näyttää vain menneisyden ja nykyhetken oikein. Ajatus on työstää tuota vielä myöhemmin siten että osaa verrata nykyistä tuntihintaa seuraaviin, ja tehostaa tai pudottaa lämmitystä sen mukaan. Tähän on hatara ajatus jo logiikasta (perustuen sensor.shf_average_price_next_hours sensoriin).

Mutta kaipaisin ymmärrystä, miten saisin tuohon siniseen käppyrään laskennan koko päivälle.

katso liitettä 95962

Nykyinen Koodi:


Tuo control - sensorin arvo määräytyisi seuraavasti:
- jos tunnin x rank on suurempi kuin slider1:n arvo, arvoksi tulee -1
- jos tunnin x rank on pienempi kuin slider2:n arvo, arvoksi tulee 1
- muissa tapauksissa arvo on 0

Control sensorista pitää tehdä template, joka laskee ne arvot attribuutteihin joka tunnille valmiiksi. Samaan tapaan kuin tässä lasketaan control factorit:

  - sensor:
    - name: SHF Control Factor 0-1
      unique_id: shf_control_factor_0-1
      unit_of_measurement: factor
      icon: mdi:gauge
      state: '{{ (states("sensor.shf_control_factor_1") | float(1) /2 + 0.5) }}'
      availability: '{{ state_attr("sensor.shf_control_factor_1", "today_values") is iterable }}'
      attributes:
        today_values: >
            {% set output = namespace(value=[]) %}
            {% for value in state_attr("sensor.shf_control_factor_1", "today_values") %}
                {% set output.value = output.value + [ value | float /2 + 0.5 ] %}
            {% endfor %}
            {{ output.value }}

Ja sitten piirto pitää tehdä niin, että otetaan arvot tuolta attribuuteista samaan tapaan kuin tuossa laittamassasi koodissa haetaan sähkön hinnat (data_generator -kohta).

 

[Kake]

Control sensorista pitää tehdä template, joka laskee ne arvot attribuutteihin joka tunnille valmiiksi. Samaan tapaan kuin tässä lasketaan control factorit:

  - sensor:
    - name: SHF Control Factor 0-1
      unique_id: shf_control_factor_0-1
      unit_of_measurement: factor
      icon: mdi:gauge
      state: '{{ (states("sensor.shf_control_factor_1") | float(1) /2 + 0.5) }}'
      availability: '{{ state_attr("sensor.shf_control_factor_1", "today_values") is iterable }}'
      attributes:
        today_values: >
            {% set output = namespace(value=[]) %}
            {% for value in state_attr("sensor.shf_control_factor_1", "today_values") %}
                {% set output.value = output.value + [ value | float /2 + 0.5 ] %}
            {% endfor %}
            {{ output.value }}

Ja sitten piirto pitää tehdä niin, että otetaan arvot tuolta attribuuteista samaan tapaan kuin tuossa laittamassasi koodissa haetaan sähkön hinnat (data_generator -kohta).

Juu ao. tapaista koittanut värkätä. Toi state pelittää mutta en ymmärrä miten tuo output.value pitäisi muotoilla että arvon saa tunti tunnilta tuonne attribuutteihin

- sensor:
- name: Control profile
unique_id: control_profile
unit_of_measurement: factor
icon: mdi:gauge
state: >
{% if states('sensor.shf_electricity_price_now') > states('input_number.kallis_sahko_rank') %}
-1
{% elif states('sensor.shf_electricity_price_now') < states('input_number.halpa_sahko_rank') %}
1
{% else %}
0
{% endif %}

availability: '{{ state_attr("sensor.control_profile", "today_values") is iterable }}'
attributes:
today_values: >
{% set output = namespace(value=[]) %}
{% for value in state_attr("sensor.shf_control_factor_1", "today_values") %}
{% set output.value = output.value ... %}
{% endfor %}
{{ output.value }}

 

[dillon]

Juu ao. tapaista koittanut värkätä. Toi state pelittää mutta en ymmärrä miten tuo output.value pitäisi muotoilla että arvon saa tunti tunnilta tuonne attribuutteihin

Esim. näin:

- sensor:
   - name: Control profile
     unique_id: control_profile
     unit_of_measurement: factor
     icon: mdi:gauge
     state: >
       {% if states('sensor.shf_rank_now') > states('input_number.kallis_sahko_rank') %}
         -1
       {% elif states('sensor.shf_rank_now') < states('input_number.halpa_sahko_rank') %}
         1
       {% else %}
         0
       {% endif %}        
     availability: '{{ state_attr("sensor.control_profile", "today_values") is iterable }}'
     attributes:
       data: >
        {% set output = namespace(value=[]) %}
        {% for p in state_attr("sensor.shf_electricity_price_now", "data") %}
          {% set cfactor = 0 %}
          {% if p.Rank | int > states('input_number.kallis_sahko_rank') | int %}
            {% set cfactor = -1 %}
          {% elif p.Rank | int < states('input_number.kallis_sahko_rank') | int %}
            {% set cfactor = 1 %}
          {% endif %}
          {% set output.value = output.value + [cfactor] %}
        {% endfor %}
        {{ output.value }}

Huom, tässä tulee mukana myös huomisen tunnit jos ne on tiedossa. Jos haluat rajata määrän 24:ään, muuta viimeinen rivi näin:

{{ output.value[:24] }}

Edit: Tuossa statessa vertaat shf_electricity_price_now vs. kallis_sahko_rank. Pitäisikö kuitenkin hinnan sijaan verrata rankiin, eli sensor.shf_rank_now? Korjasin tuohon esimerkkiin näin.

 

[Kake]

Esim. näin:

- sensor:
   - name: Control profile
     unique_id: control_profile
     unit_of_measurement: factor
     icon: mdi:gauge
     state: >
       {% if states('sensor.shf_rank_now') > states('input_number.kallis_sahko_rank') %}
         -1
       {% elif states('sensor.shf_rank_now') < states('input_number.halpa_sahko_rank') %}
         1
       {% else %}
         0
       {% endif %}      
     availability: '{{ state_attr("sensor.control_profile", "today_values") is iterable }}'
     attributes:
       data: >
        {% set output = namespace(value=[]) %}
        {% for p in state_attr("sensor.shf_electricity_price_now", "data") %}
          {% set cfactor = 0 %}
          {% if p.Rank | int > states('input_number.kallis_sahko_rank') | int %}
            {% set cfactor = -1 %}
          {% elif p.Rank | int < states('input_number.kallis_sahko_rank') | int %}
            {% set cfactor = 1 %}
          {% endif %}
          {% set output.value = output.value + [cfactor] %}
        {% endfor %}
        {{ output.value }}

Huom, tässä tulee mukana myös huomisen tunnit jos ne on tiedossa. Jos haluat rajata määrän 24:ään, muuta viimeinen rivi näin:

{{ output.value[:24] }}

Edit: Tuossa statessa vertaat shf_electricity_price_now vs. kallis_sahko_rank. Pitäisikö kuitenkin hinnan sijaan verrata rankiin, eli sensor.shf_rank_now? Korjasin tuohon esimerkkiin näin.

Kiitos dillon. Joo oikeassa olet, tarkoitus on Rankkiin verrata. toi oli käpy.

Muokkasin tuota hieman eteenpäin, Developer templatessa tämä äkkiseltään näytti toimivan, mutta configuration.yaml:iin kun tuon väkäsin niin restartatessa antaa arvoksi vain unavailable. Varmaan lähellä ollaan mutta jossain on vielä pientä häikkää.

template:
  - sensor:
    - name: Temp Control
      unique_id: temp_control
      unit_of_measurement: factor
      icon: mdi:gauge
      state: >
        {% if states('sensor.shf_rank_now') >= states('input_number.kallis_sahko_rank') %}
          -1
        {% elif states('sensor.shf_rank_now') <= states('input_number.halpa_sahko_rank') %}
          1
        {% else %}
          0
        {% endif %}        
      availability: '{{ state_attr("sensor.temp_control", "today_values") is iterable }}'
      attributes:
        data: >
         {% set output = namespace(value=[]) %}
         {% for p in state_attr("sensor.shf_electricity_price_now", "data") %}
           {% set cfactor = 0 %}
           {% if p.Rank | int >= states('input_number.kallis_sahko_rank') | int %}
             {% set cfactor = -1 %}
           {% elif p.Rank | int <= states('input_number.halpa_sahko_rank') | int %}
             {% set cfactor = 1 %}
           {% else %}
             {% set cfactor = 0 %}
           {% endif %}
           {% set output.value = output.value + [cfactor] %}
         {% endfor %}
         {{ output.value }}

 

[dillon]

Kiitos dillon. Joo oikeassa olet, tarkoitus on Rankkiin verrata. toi oli käpy.

Muokkasin tuota hieman eteenpäin, Developer templatessa tämä äkkiseltään näytti toimivan, mutta configuration.yaml:iin kun tuon väkäsin niin restartatessa antaa arvoksi vain unavailable. Varmaan lähellä ollaan mutta jossain on vielä pientä häikkää.

katso liitettä 95980

template:
  - sensor:
    - name: Temp Control
      unique_id: temp_control
      unit_of_measurement: factor
      icon: mdi:gauge
      state: >
        {% if states('sensor.shf_rank_now') >= states('input_number.kallis_sahko_rank') %}
          -1
        {% elif states('sensor.shf_rank_now') <= states('input_number.halpa_sahko_rank') %}
          1
        {% else %}
          0
        {% endif %}       
      availability: '{{ state_attr("sensor.temp_control", "today_values") is iterable }}'
      attributes:
        data: >
         {% set output = namespace(value=[]) %}
         {% for p in state_attr("sensor.shf_electricity_price_now", "data") %}
           {% set cfactor = 0 %}
           {% if p.Rank | int >= states('input_number.kallis_sahko_rank') | int %}
             {% set cfactor = -1 %}
           {% elif p.Rank | int <= states('input_number.halpa_sahko_rank') | int %}
             {% set cfactor = 1 %}
           {% else %}
             {% set cfactor = 0 %}
           {% endif %}
           {% set output.value = output.value + [cfactor] %}
         {% endfor %}
         {{ output.value }}

Se on unavailable kun tuo templaten availability: yrittää katsoa onko tällä sensorilla itsessään attribuuttia today_values, joka on lista. Unohdin näköjään sen korjata tuohon esimerkkiin. Siinä pitäisi käyttää jotain sellaista toisen sensorin arvoa, jota tämä template hyödyntää, eli esim:

    availability: '{{ state_attr("sensor.shf_electricity_price_now", "data") is iterable }}'

 

[Kake]

Se on unavailable kun tuo templaten availability: yrittää katsoa onko tällä sensorilla itsessään attribuuttia today_values, joka on lista. Unohdin näköjään sen korjata tuohon esimerkkiin. Siinä pitäisi käyttää jotain sellaista toisen sensorin arvoa, jota tämä template hyödyntää, eli esim:

    availability: '{{ state_attr("sensor.shf_electricity_price_now", "data") is iterable }}'

Juu nythän tuo näyttäisi toimivan. data_generatorin osalta joutuu myös nöyrtymään. en saa kiinni miten tuo pitäisi muotoilla.

Jaksaako joku vielä vääntää rautalankaa miten tuosta tehdään apex graafi. Lähinnä toi data-generator osuus on epäselvä.

Kiitän ja kumarran

 

[kallek]

Mulla on 2 lämmityspiiriä käytössä L1 =patteriverkko, L2=lattialämmitys, (koodi pistää lämmönpudotuksen päälle molempiin piireihin) siksi 2 parametria. Jätä toinen pois jos ei tarvetta.
Katso asetukset -välilehdeltä, onko siellä asetettu Lämmönpudotus (menovesi) kohtaan jotakin. Jos 0 niin ei vaikuta mitenkään. Menovesi-info sivulta näkee joitan osviittaa miten Oumanni on arponut lämpönsä.

HA ei näytä K/P -kytkimen tilan muutosta ilman että arvo kysytään Oumannilta uudestaan. Kun testailet, päivitä Oumannin hallintasivu, se ei pysy mukana jos vierestä ampuu säätäjä purkille. Ja toki kannattaa vilkasta mitä Oumanni vastasi curlille, sen näet kohdetiedostosta /config/oumanltp2.txt Mulla on triggerit päivitysautomaatiossa. Jätin sen pois eilisestä esimerkistä ku ajattelin että sotkisi vaan. Kytkimen tilan muutos päivittää tilat aina. Tuo oli viksuinta mitä viime syksynä tuohon keksin. En jaksanut kyhätä erillistä automaatiota vaan ajan tuota samaa.

- id: '1'
  alias: Ouman-toiminnot
  description: Automaattinen kirjautuminen Ouman EH800, lämpötilojen luku, 5min välein
  trigger:
  - platform: time_pattern
    minutes: /5
  - platform: state
    entity_id:
    - switch.eh800ltp
    from: 'on'
    to: 'off'
  - platform: state
    entity_id:
    - switch.eh800ltp
    from: 'off'
    to: 'on'
  - platform: state
    entity_id:
    - switch.eh800releohjaus
    from: 'on'
    to: 'off'
  - platform: state
    entity_id:
    - switch.eh800releohjaus
    from: 'off'
    to: 'on'
  condition: []
  action:
  - service: shell_command.ouman_logon
    data: {}
  - delay:
      hours: 0
      minutes: 0
      seconds: 1
      milliseconds: 0
  - service: shell_command.ouman_data
    data: {}
  mode: single

Parametrejä on näppärä selvitellä Selaimen Developer Toolsilla. Network -välilehdellä näkyy hyvin mitä selain juttelee Oumannin purkin kanssa. Kuvissa Lämpötilan pudotus aka Kotona/possa. Oululaisen logiikan mukaan siinä on 3 arvoa, joista käytännössä 0 ja 2 aiheuuttaa samanlaisen toiminnan, eli kumpikaan ei laske lämpötiloja. 2 on kiva jäynä HA:n binary sensorille. En muista sainko tuon kakkosen koskaan toimimaan oikein.
Kotona =0
Ei K/P -ohjausta = 2
Poissa = 1
katso liitettä 84340
katso liitettä 84341
katso liitettä 84342

Huomasin että vielä helpommin luvut saa selville maalaamalla samassa näkymässä esim L1 menoveden lämpötilan ja painamalla uudelleen hiiren oikeata nappia ja tarkista. Näyttää suoraan oikean kohdan elements puolella

 

[dillon]

Juu nythän tuo näyttäisi toimivan. data_generatorin osalta joutuu myös nöyrtymään. en saa kiinni miten tuo pitäisi muotoilla.

Jaksaako joku vielä vääntää rautalankaa miten tuosta tehdään apex graafi. Lähinnä toi data-generator osuus on epäselvä.

Kiitän ja kumarran

Toimisko suunnilleen näin:

  - entity: sensor.control
    yaxis_id: first
    type: line
    color: blue
    stroke_width: 1
    name: Control
    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];
        });

 

[Kake]

Toimisko suunnilleen näin:

  - entity: sensor.control
    yaxis_id: first
    type: line
    color: blue
    stroke_width: 1
    name: Control
    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];
        });

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:

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.

 

[heebo1974]

Hmm.. Päivitin tässä pitkästä aikaa tuon spot-price.yaml:n ja nyt jostain syystä oma forkki

resource: https://api.spot-hinta.fi/TodayAndD...rityHours=0,1,2,3,4,5,6,7&priorityHoursRank=4

ei taidakkaan toimia, sillä jostain syystä SHF Rank Now näyttää tällähetkellä (klo 16) rankkia 2, vaikka pitäisi näyttää 6:sta.
Eli rank 2 olisi pitänyt olla jo yöllä klo 1. Muistaakseni aikaisempi spot-price.yaml oli versiota 0.2.0, joten onko tuohon tullut jotain isomaa muutosta sen jälkeen, joka voisi vaikuttaa tuohon toimintaan ? Vai mistä pitäisi alkaa etsiä vikaa ?

EDIT: sensor.shf_data:ssa on tiedot juuri niinkuin pitääkin. Miten SHF Rank Now voi ilmoittaa eri tietoja? Siirryin taas puolen vuoden tauon jälkeen pörssiin, niin tietysti asiat alkoivat kiinnostaa eritavalla kuin hetki sitten. Eli en nyt voi olla satavarma siitä toimiko se edellinenkään spot-price versio oikein.

 

[heebo1974]

Tein vielä testin jossa poistin priority hour forkin.
Tässä tulokset rank tunneista priority hoursin kanssa ja ilman.
Mitään vaikutusta SHF Rank Now entityyn ei tuo tee.

No priority:

Priority

Sinänsä ilkeä bugi/ominaisuus, koska tällä hetkellä näyttäisi että pörssi on suht halpaa iltapäivisin. Ja oma LVV jää yöllä lämmittämättä ja näin ollen suurempi todennäköisyys sille että aamupäivä suihkut on viileämpiä.

 

[MarjoC]

@Temez onkohan kukaan maininnut, mutta en ainakaan huomannut viestiä aiheesta. Päivitin uusimpaan versioon ja sen jälkeen automation period-end ei ole enään toiminut. Alla koodi, jolla ajan siis lämpötilan korotuksen halpojen tuntien aikana. Mikä voisi olla syynä? Päälle laitto toimii moitteetta. Samoin halvempien tuntien haku. Period-end ei näytä triggeröityvän ollenkaan…

alias: Ouman korotus lämpötilaan
description: ""
use_blueprint:
  path: T3m3z/cheapest-period.yaml
  input:
    hours: 6
    stop: "{{ now() + timedelta(hours=24) }}"
    trigger_type: Time Trigger
    entity: binary_sensor.shf_price_acceptable
    helper: input_datetime.time_helper
    action:
      - condition: state
        entity_id: binary_sensor.shf_price_acceptable
        state: "on"
      - service: switch.turn_on
        data: {}
        target:
          entity_id: switch.ouman_lampotila_korotus
      - service: timer.start
        data:
          duration: "6:00:00"
        target:
          entity_id: timer.helper_timer
    trigger_time: "18:15:00"
    conditions: []
    action_on:
      - condition: state
        entity_id: input_boolean.oljy
        state: "off"
      - delay:
          hours: 0
          minutes: 0
          seconds: 30
          milliseconds: 0
      - service: switch.turn_on
        target:
          entity_id: switch.ouman_lampotila_korotus
        data: {}
      - service: notify.notify
        data:
          message: korotus laitettu päälle.
    action_off:
      - condition: state
        entity_id: switch.ouman_lampotila_korotus
        state: "on"
      - service: switch.turn_off
        target:
          entity_id: switch.ouman_lampotila_korotus
        data: {}
      - service: notify.notify
        data:
          message: Korotus laitettu pois päältä.

 

[MarjoC]

Tämä ongelma sattuu aina silloin jos lopetusaika (period-stop) sattuu samoihin aikoihin tai sen jälkeen, kun pyöräyttää tuon cheapest_hours scriptin. Näitä on nyt sattunut jonkin verran, kun tuo halvin jakso on sattunut keskelle päivää. Yöllä näyttäisi toimivan ihan niin kuin pitääkin.

 

[heebo1974]

Hmm.. Päivitin tässä pitkästä aikaa tuon spot-price.yaml:n ja nyt jostain syystä oma forkki

resource: https://api.spot-hinta.fi/TodayAndD...rityHours=0,1,2,3,4,5,6,7&priorityHoursRank=4

ei taidakkaan toimia, sillä jostain syystä SHF Rank Now näyttää tällähetkellä (klo 16) rankkia 2, vaikka pitäisi näyttää 6:sta.
Eli rank 2 olisi pitänyt olla jo yöllä klo 1. Muistaakseni aikaisempi spot-price.yaml oli versiota 0.2.0, joten onko tuohon tullut jotain isomaa muutosta sen jälkeen, joka voisi vaikuttaa tuohon toimintaan ? Vai mistä pitäisi alkaa etsiä vikaa ?

EDIT: sensor.shf_data:ssa on tiedot juuri niinkuin pitääkin. Miten SHF Rank Now voi ilmoittaa eri tietoja? Siirryin taas puolen vuoden tauon jälkeen pörssiin, niin tietysti asiat alkoivat kiinnostaa eritavalla kuin hetki sitten. Eli en nyt voi olla satavarma siitä toimiko se edellinenkään spot-price versio oikein.

Kyllähän tuo nyt vaikuttaa selkeästi siltä, että nykyinen SHF Rank Now entity ei käytä enää api.spot-hinta.fi:n antamaa Rankkiä, vaan valitsee sen itse hintojen perusteella. Joten tuo käyttämäni resource rivi ei toimi enää niinkuin ennen. Temez vaikuttaisi olevan estynyt jostain syystä, joten osaisiko joku muu guru vääntää uuden esim. "SHF Rank Now2" sensorin, joka kaivaisi Rankit niinkuin api.spot-hinta.fi ne suoltaa.

 

[dillon]

Kyllähän tuo nyt vaikuttaa selkeästi siltä, että nykyinen SHF Rank Now entity ei käytä enää api.spot-hinta.fi:n antamaa Rankkiä, vaan valitsee sen itse hintojen perusteella. Joten tuo käyttämäni resource rivi ei toimi enää niinkuin ennen. Temez vaikuttaisi olevan estynyt jostain syystä, joten osaisiko joku muu guru vääntää uuden esim. "SHF Rank Now2" sensorin, joka kaivaisi Rankit niinkuin api.spot-hinta.fi ne suoltaa.

Joo, se tosiaan lasketaan uusiksi ilmeisesti siksi että siirtohinnat tulee huomioitua jos käyttäjä näin haluaa.

Tällaisella templatella saat rankin suoraan datasta:

  - sensor:       
    - name: SHF Rank now from api data
      unique_id: shf_rank_now_from_api_data
      unit_of_measurement: Rank
      state: '{{ (state_attr("sensor.shf_data", "data") | selectattr("Timestamp", "lt", now() | as_timestamp) | list)[-1]["Rank"] | int }}'
      availability: '{{ state_attr("sensor.shf_data", "data") | selectattr("Timestamp", "ge", now() | as_timestamp ) | list | length > 0 }}'

 

[Antt]

Apex Charts kortti väreillä jos joku tarvitsee:

type: custom:apexcharts-card
graph_span: 24h
header:
title: Energy price today (snt/kWh)
show: true
experimental:
color_threshold: true
span:
start: day
now:
show: true
label: Now
series:
- entity: sensor.nordpool_kwh_fi_eur_3_095_024
type: column
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: -100
color: Blue
- value: 0
color: green
- value: 10
color: yellow
- value: 15
color: Red

huominen:

type: custom:apexcharts-card
graph_span: 1d
header:
title: Energy price tomorrow (snt/kWh)
show: true
experimental:
color_threshold: true
span:
start: day
offset: +1d
series:
- entity: sensor.nordpool_kwh_fi_eur_3_095_024
type: column
data_generator: |
return entity.attributes.raw_tomorrow.map((start, index) => {
return [new Date(start["start"]).getTime(), entity.attributes.raw_tomorrow[index]["value"]];
});
color_threshold:
- value: -100
color: Blue
- value: 0
color: green
- value: 10
color: yellow
- value: 15
color: Red

 

[Kaimax]

Miten saisin laskettua seuraavan päivän sää ennusteesta keskilämpötilan, käytän FMI sää palvelua.

 

[dillon]

Miten saisin laskettua seuraavan päivän sää ennusteesta keskilämpötilan, käytän FMI sää palvelua.

Mulla on ensin tällainen helper, jolla saa tuntiennusteen yhden sensorin attribuutteihin listana (korvaa kaikki "weather.kotipaikka" sillä weather entityllä mitä käytät):

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"] }}'

Sitten esim. seuraavalla templatella saat huomisen keskilämpötilan:

template:
  - sensor
    - name: "Temperature forecast tomorrow avg"
      unique_id: temperature_forecast_tomorrow_avg
      unit_of_measurement: °C
      state: >
        {{ state_attr("sensor.weather_koti_hourly", "forecast") |
              selectattr("datetime", "gt", today_at("23:59").isoformat()) |
              selectattr("datetime", "lt", (today_at("23:59") + timedelta(hours=24)).isoformat()) |
              map(attribute='temperature') | list | average | round(1) }}
      availability: '{{ state_attr("sensor.weather_koti_hourly", "forecast") is iterable }}'

 

[aNT7I]

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):

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ä:

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

Kukaan innostunut korjaamaan tätä koodia, kun Fingrid päivitti tuon rajapintansa JSON-tietorakenteiseksi?
Pitäisi tuo platform osuus korjailla.

 

[Kaimax]

Mulla on ensin tällainen helper, jolla saa tuntiennusteen yhden sensorin attribuutteihin listana (korvaa kaikki "weather.kotipaikka" sillä weather entityllä mitä käytät):

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"] }}'

Sitten esim. seuraavalla templatella saat huomisen keskilämpötilan:

template:
  - sensor
    - name: "Temperature forecast tomorrow avg"
      unique_id: temperature_forecast_tomorrow_avg
      unit_of_measurement: °C
      state: >
        {{ state_attr("sensor.weather_koti_hourly", "forecast") |
              selectattr("datetime", "gt", today_at("23:59").isoformat()) |
              selectattr("datetime", "lt", (today_at("23:59") + timedelta(hours=24)).isoformat()) |
              map(attribute='temperature') | list | average | round(1) }}
      availability: '{{ state_attr("sensor.weather_koti_hourly", "forecast") is iterable }}'

Päivitin HA:n niin lakkasi toimimasta. Onko mitään vinkkiä antaa miksen saa arvoa anturille?

Automaatio antaa kuitenkin arvon.

Anturi ei kuitenkaan saa arvoa, paitsi tämän hetken lämpötilan (alin kuva)

 

[dillon]

Päivitin HA:n niin lakkasi toimimasta. Onko mitään vinkkiä antaa miksen saa arvoa anturille?

Automaatio antaa kuitenkin arvon.
katso liitettä 97483

Anturi ei kuitenkaan saa arvoa, paitsi tämän hetken lämpötilan (alin kuva)
katso liitettä 97484


katso liitettä 97485

En tiedä mikä tuo automaatio on. Ymmärtääkseni tätä ei voi tehdä automaationa vaan templatena yaml-koodissa kuten tuossa laittamassani esimerkissä.

Template editoriin ei voi laittaa yamlia, se on vain Jinja-koodin testaamiseen, eli keskimmäisessä kuvassa virhe tulee siitä.

Laitoin itse uusimman 2024.5.2 päivityksen eikä se muuttanut mitään.

 

[-Teme-]

Kukaan innostunut korjaamaan tätä koodia, kun Fingrid päivitti tuon rajapintansa JSON-tietorakenteiseksi?
Pitäisi tuo platform osuus korjailla.

ensimmäinen tehtävä on rekisteröidä uusi developer API key - muutosten jälkeen pitää olla uudentyyppinen key
sensorin rivit on lähes muuttumattomat, vain dataset osoite on vaihtunut. Itsellä tuo haettava aika on hieman eri kuin Temezillä mutta pidä start ja end ajat ennallaan. Nimen voi pitää vanhana niin saa käppyrät piirrettyä apex chart cardilla ilman muokkausta

platform: rest
resource_template: https://data.fingrid.fi/api/data?datasets=245
name: Fingrid Wind forecast
value_template: 'OK' # static value as sensor is not updated regularly
headers:
  x-api-key: !secret fingrid_new_key
params:
  startTime: "{{ (utcnow() - timedelta(days = 1)).strftime('%Y-%m-%dT%H:00:00Z') }}"
  endTime: "{{ (utcnow() + timedelta(hours = 36)).strftime('%Y-%m-%dT%H:00:00Z') }}"
  format: 'xml'
  pageSize: 1000
json_attributes:
  - "events"
scan_interval: 3600

 

[Sukke]

ensimmäinen tehtävä on rekisteröidä uusi developer API key - muutosten jälkeen pitää olla uudentyyppinen key
sensorin rivit on lähes muuttumattomat, vain dataset osoite on vaihtunut. Itsellä tuo haettava aika on hieman eri kuin Temezillä mutta pidä start ja end ajat ennallaan. Nimen voi pitää vanhana niin saa käppyrät piirrettyä apex chart cardilla ilman muokkausta

platform: rest
resource_template: https://data.fingrid.fi/api/data?datasets=245
name: Fingrid Wind forecast
value_template: 'OK' # static value as sensor is not updated regularly
headers:
  x-api-key: !secret fingrid_new_key
params:
  start_time: "{{ (utcnow() - timedelta(days = 1)).strftime('%Y-%m-%dT%H:00:00Z') }}"
  end_time: "{{ (utcnow() + timedelta(hours = 36)).strftime('%Y-%m-%dT%H:00:00Z') }}"
  format: 'xml'
  pageSize: 1000
json_attributes:
  - "events"
scan_interval: 3600

Olikos start_time nykyään startTime ja end_time endTime vai muistanko ulkoa juurikin päinvastoin?

 

[-Teme-]

Olikos start_time nykyään startTime ja end_time endTime vai muistanko ulkoa juurikin päinvastoin?

Olet oikeassa
Editoin sen ylle

 

[aNT7I]

Kiitokset molemmille!

 

[haraldh]

Säädän pyyntilämpötilaa ilmalämpöpumpussa niin että kalliimpien tuntien aikana pyynti on 2°C pienempi. No, nyt on niin lämmin ulkona että sammutin pumpun home assistantista. HA huomaa että onpas halpaa sähköä ja laittaa sen takaisin päälle, joka on loogista. Ajattelin että laitan ehdon että laita päälle ainoastaan jos hvac_mode: heating. Kun olen sammuttanut pumpun HA:sta hvac_mode: off.

Mutta ei tämä toimi, vaan jos ajan käsin "heat more when cheap" niin ILP sehän herää henkiin hvac_mode: heat tilaan. Miksi?

alias: MitsuILP heat more when rank or price is detected
description: ""
trigger:
  - platform: state
    entity_id:
      - binary_sensor.shf_price_or_rank_acceptable
    to: "on"
condition:
  - condition: state
    entity_id: climate.mitsubishi_rw_25_aircon
    attribute: hvac_action
    state: heating
action:
  - service: climate.set_temperature
    data:
      hvac_mode: heat
      temperature: 21
    target:
      entity_id:
        - climate.mitsubishi_rw_25_aircon
mode: single

Mitä teen väärin tai en ymmärrä?

 

[-Teme-]

Säädän pyyntilämpötilaa ilmalämpöpumpussa niin että kalliimpien tuntien aikana pyynti on 2°C pienempi. No, nyt on niin lämmin ulkona että sammutin pumpun home assistantista. HA huomaa että onpas halpaa sähköä ja laittaa sen takaisin päälle, joka on loogista. Ajattelin että laitan ehdon että laita päälle ainoastaan jos hvac_mode: heating. Kun olen sammuttanut pumpun HA:sta hvac_mode: off.

Mutta ei tämä toimi, vaan jos ajan käsin "heat more when cheap" niin ILP sehän herää henkiin hvac_mode: heat tilaan. Miksi?

alias: MitsuILP heat more when rank or price is detected
description: ""
trigger:
  - platform: state
    entity_id:
      - binary_sensor.shf_price_or_rank_acceptable
    to: "on"
condition:
  - condition: state
    entity_id: climate.mitsubishi_rw_25_aircon
    attribute: hvac_action
    state: heating
action:
  - service: climate.set_temperature
    data:
      hvac_mode: heat
      temperature: 21
    target:
      entity_id:
        - climate.mitsubishi_rw_25_aircon
mode: single

Mitä teen väärin tai en ymmärrä?

Kannattaa lisätä ulkolämpötila tuohon sääntöön

 

[Kaimax]

Säädän pyyntilämpötilaa ilmalämpöpumpussa niin että kalliimpien tuntien aikana pyynti on 2°C pienempi. No, nyt on niin lämmin ulkona että sammutin pumpun home assistantista. HA huomaa että onpas halpaa sähköä ja laittaa sen takaisin päälle, joka on loogista. Ajattelin että laitan ehdon että laita päälle ainoastaan jos hvac_mode: heating. Kun olen sammuttanut pumpun HA:sta hvac_mode: off.

Mutta ei tämä toimi, vaan jos ajan käsin "heat more when cheap" niin ILP sehän herää henkiin hvac_mode: heat tilaan. Miksi?

alias: MitsuILP heat more when rank or price is detected
description: ""
trigger:
  - platform: state
    entity_id:
      - binary_sensor.shf_price_or_rank_acceptable
    to: "on"
condition:
  - condition: state
    entity_id: climate.mitsubishi_rw_25_aircon
    attribute: hvac_action
    state: heating
action:
  - service: climate.set_temperature
    data:
      hvac_mode: heat
      temperature: 21
    target:
      entity_id:
        - climate.mitsubishi_rw_25_aircon
mode: single

Mitä teen väärin tai en ymmärrä?

Törmäsin melkein samaan ongelmaan, kun oli jäähdytys päällä ja asetus +24´C, niin automaatio korjasi asetus arvoa. Ratkaisin tämän muuttamalla asetus arvo muutoksen "if" lausekkeen perään ja alkoi toimimaan.

alias: ILP heat control price +-
description: ""
trigger:
- platform: state
entity_id:
- sensor.shf_electricity_price_now

condition: []
action:
- if:
- condition: state
entity_id: climate.ilp_panasonic_esp_home_panasonic_ac
state: heat
then:
- service: climate.set_temperature
data_template:
temperature: "{{ states.sensor.ilp_heat_control_price.state }}"
entity_id: climate.ilp_panasonic_esp_home_panasonic_ac
mode: single

 

[haraldh]

Ei ole ILP lähtenyt käyntiin yöllä enää, joten olen ilmeisesti ymmärtänyt väärin tuon "Run" napin. Onko niin että se ei aja automaatiota kuten normaalisti, vaan se ajaa vain sen loppukomennon välittämättä ehdoista?

edit: https://community.home-assistant.io...n-is-run-even-if-conditions-are-not-met/70742

 

[haraldh]

Kannattaa lisätä ulkolämpötila tuohon sääntöön

Oikeasti pitäisi laittaa ikkuna- ja oviantureita ja sammuttaa aina kun jokin on auki.

Mutta joo, jos ulkolämpötila on yli jotain olisi hyvä sammuttaa ILP:it kokonaan. Mikäköhän voisi olla hyvä lähtölämpötila?

 

[-Teme-]

Oikeasti pitäisi laittaa ikkuna- ja oviantureita ja sammuttaa aina kun jokin on auki.

Mutta joo, jos ulkolämpötila on yli jotain olisi hyvä sammuttaa ILP:it kokonaan. Mikäköhän voisi olla hyvä lähtölämpötila?

Oma automatiikka painaa ILP puhallukselle jos ovi/ikkuna on tilassa avoinna yli 1min ja tallettaa statuksen sceneen. Kun ovi/ikkuna suljetaan 2h kuluessa edellinen status palautetaan käyttöön, muutoin jää puhallukselle ja odottaa seuraavaa ohjausta. Oven/ikkunan avoinna oleminen myös estää muun ohjauksen toteutumisen.
Itsellä ILP siirtyy pois lämmitys ohjelmasta kun ulkona 3vrk mediaani lämpötila on yli 11°C, poikkeuksena jos yöllä laskee lämpö 5°C alle jolloin lämmitys profiili aktivoituu tarvittaessa (energian hinta ja sisälämpötila ratkaisee).
Jäähdytys profiili aktivoituu kun sisällä lämpötila ylittää 23°C ja ulkona on sitä lämpimämpää, jos ulkona on 21°C tai alle on kehoituksena jäähdyttää avaamalla terassin ovi. Jos terassin ovi on ollut avoinna yli 2min ja ulkolämpötila kohoaa yli 25°C sekä sisällä on 22°C tai alle tulee kehoitus sulkea ovi jotta ei turhaan lämmitä sisätilaa

 

[haraldh]

Pitää ilmeisesti hankkia vähän antureita

Pitää vähän miettiä miten pitäisi totetuttaa tällaisia automaatioita joissa on monta ehtoa, ja miten jotkut ehdot määräävät toistensa yli. Minulla on sama ongelma MUH Ilmavan automaatiossa että miten pitäisi käsitellä asioita kuten CO₂, ilmankosteus, kotona/poissa tila jne, mikä näistä on se määräävin ja miten ne kirjoitetaan automaatioiksi.

Et viitsisi vähän avata miten olet tehnyt yo. automaatiot?

 

[-Teme-]

Olen käyttänyt Node-Rediä automaatioiden tekoon. Kun ovi-/ikkunasensori on open, stoppaa ILP ohjaus heti alkuun.
Ulkolämpötila ohjaa prosessin eri flowlle, jossa kuitenkin se yö-ajan lämpötila muuttuja mukana joka siirtää taas siihen lämmitys prosessiin.
En ole keksinyt hyvää tapaa miten HA automaatioilla saa noita tehtyä rakentamatta massiivista if-else rakennetta.
HA on käytännössä vain sensorien keräämistä ja UI tarkoitusta varten - kaikki ohjaukset itsellä Node-Redissä

 

[Ninnannunna]

Olen käyttänyt Node-Rediä automaatioiden tekoon. Kun ovi-/ikkunasensori on open, stoppaa ILP ohjaus heti alkuun.
Ulkolämpötila ohjaa prosessin eri flowlle, jossa kuitenkin se yö-ajan lämpötila muuttuja mukana joka siirtää taas siihen lämmitys prosessiin.
En ole keksinyt hyvää tapaa miten HA automaatioilla saa noita tehtyä rakentamatta massiivista if-else rakennetta.
HA on käytännössä vain sensorien keräämistä ja UI tarkoitusta varten - kaikki ohjaukset itsellä Node-Redissä

Pitihän se alkaa testailemaan noderediä tähän. Mutta meinaa tyssätä heti alkuunsa.
Miten estää node redissä komennon lähettämisen joka kerran kun lämpötilasensorin arvo muuttuu, mutta ilpin tila ei? Tämä sama ongelma on HA:nkin automaatioiden kanssa.
Vai onko mulla jo lähtö väärin kun käytän state nodea "Ulkolämpö 3vrk >= 11" automaation lähtökohtana. Antaa arvot false tai true. Mutta laukaisee nämä tosiaan joka kerran kun lämpötila muuttuu.

 

[Ninnannunna]

Pitihän se alkaa testailemaan noderediä tähän. Mutta meinaa tyssätä heti alkuunsa.
Miten estää node redissä komennon lähettämisen joka kerran kun lämpötilasensorin arvo muuttuu, mutta ilpin tila ei? Tämä sama ongelma on HA:nkin automaatioiden kanssa.
Vai onko mulla jo lähtö väärin kun käytän state nodea "Ulkolämpö 3vrk >= 11" automaation lähtökohtana. Antaa arvot false tai true. Mutta laukaisee nämä tosiaan joka kerran kun lämpötila muuttuu.

No vastaanpa itselleni: Auttaa joskus kun kirjoittaa homman auki vaikkapa tänne Lähtökohta väärin, uskoakseni fiksumpi tapa on pollata lämpötilaa ja sitten switchillä määrittää mitä tehdään. Näin ei ainakaan minun järjenjuoksuni mukaan tule kuin yksi komento.

 

[Ninnannunna]

No vastaanpa itselleni: Auttaa joskus kun kirjoittaa homman auki vaikkapa tänne Lähtökohta väärin, uskoakseni fiksumpi tapa on pollata lämpötilaa ja sitten switchillä määrittää mitä tehdään. Näin ei ainakaan minun järjenjuoksuni mukaan tule kuin yksi komento.

Eipä toimi niinkään. Takaisin piirustuspöydälle.

 

[heebo1974]

Saakeli kun tuo node-red vaikuttaisi pätevältä. Todella iso kynnys vain alkaa siirtyä siihen, kun tällähetkellä omat automaatiot ovat suht hyvässä jamassa ihan perus HA automaatioilla.

Pystyykö niitä käyttämään yhtäaikaa. Eli siirtyisi pikkuhiljaa node-rediin ?

 

[Ninnannunna]

Saakeli kun tuo node-red vaikuttaisi pätevältä. Todella iso kynnys vain alkaa siirtyä siihen, kun tällähetkellä omat automaatiot ovat suht hyvässä jamassa ihan perus HA automaatioilla.

Pystyykö niitä käyttämään yhtäaikaa. Eli siirtyisi pikkuhiljaa node-rediin ?

No olen ratkaissut homman niin että automaatioita on kummassakin . Hälyttimet ja ruohonleikkuri noderedissä. Sinne on tosiaan helpompi tehdä monimutkaisia kuin ha:iin. Vaikka ha on kyllä mennyt automaatioissa pitkin harppauksin eteenpäin muutaman vuoden takaisesta.
Uskoisin että ilppikin hyvä noderedissä kunhan nyt pääsisi alkua pidemmälle ensin...