Follow along with the video below to see how to install our site as a web app on your home screen.
Huomio: This feature may not be available in some browsers.
Tällaisella sain nyt kaksi sensoria aikaiseksi joihin tallettuu tunnin pääteessä(xx:59:5Juu, kurkkasin nopsaan ja näytti minun silmään että ratkaisu venyi siihen asti että saatiin kasaan infon tunnin tase arvon kehityksestä.
Tämä info olikin jo mullakin kasassa. Mutta sitten meni sormi suuhun, että miten "säilötään" myyntiin menneet tunnit ja miten säilötään ostoon menneet tunnit. Pohdin että joku päättely pitää olla ilmeisesti kerran tuntiin, että kumpaan laariin x:59:59 ajanhetken "tase" arvo lisätään.
template:
- sensor:
- name: hourly_energy_balance
state_class: measurement
device_class: energy
state: >
{{
states('sensor.hourly_energy_import') | float -
states('sensor.hourly_energy_export') | float
}}
#kerran tuntiin kasvatetaan Netto myynnit lukua, jos hourly_energy_balance on ollut oston puolella eli miinus puoella
- trigger:
- platform: time_pattern
hours: "*"
minutes: "59"
seconds: "58"
sensor:
- name: "Netto Myynnit"
state: >-
{% set import = states('sensor.hourly_energy_balance')|float(0) %}
{% if import < 0 %}
{{states('sensor.netto_myynnit')|float(0) + import}}
{% else %}
{{states('sensor.netto_myynnit')|float(0) }}
{% endif %}
unit_of_measurement: "kWh"
#kerran tuntiin kasvatetaan Netto ostot lukua, jos hourly_energy_balance on ollut oston puolella eli plussan puoella
- trigger:
- platform: time_pattern
hours: "*"
minutes: "59"
seconds: "58"
sensor:
- name: "Netto Ostot"
state: >-
{% set import = states('sensor.hourly_energy_balance')|float(0) %}
{% if import > 0 %}
{{states('sensor.netto_ostot')|float(0) + import}}
{% else %}
{{states('sensor.netto_ostot')|float(0) }}
{% endif %}
unit_of_measurement: "kWh"
sensor:
- platform: rest
scan_interval: 300
name: "SHF temperature 70700"
unique_id: shf_temperature_70700
resource: https://api.spot-hinta.fi/PostalCodeTemperatures/70700?HomeAssistant=true
force_update: true
value_template: 'OK'
json_attributes:
- "data"
template:
- sensor:
- name: SHF temperature 70700 now
unique_id: shf_temperature_70700_now
unit_of_measurement: "°C"
device_class: temperature
state: '{{ state_attr("sensor.shf_temperature_70700", "data")[0]["Temperature"] }}'
type: custom:apexcharts-card
show:
last_updated: true
apex_config:
chart:
zoom:
enabled: true
toolbar:
show: true
tools:
zoom: false
zoomin: true
zoomout: true
pan: false
reset: false
graph_span: 24h
experimental:
color_threshold: true
header:
title: Lämpötila- ja sade-ennuste / koti (24 h)
show: true
show_states: true
colorize_states: true
span:
start: hour
series:
- entity: sensor.shf_temperature_70700_now
color: '#00bfff'
name: ' '
unit: ' °C (nyt)'
show:
header_color_threshold: true
in_header: true
in_chart: false
color_threshold:
- value: -20
color: Blue
- value: -10
color: DodgerBlue
- value: -5
color: Cyan
- value: 0
color: Gold
- value: 5
color: Orange
- value: 10
color: Red
- entity: sensor.shf_temperature_70700
name: Lämpötila
color: '#00bfff'
show:
in_header: false
extremas: true
legend_value: false
type: column
data_generator: |
return entity.attributes.data.map((start, index) => {
return [new Date(start["TimeStamp"]).getTime(), entity.attributes.data[index]["Temperature"]];
});
color_threshold:
- value: -20
color: Blue
- value: -10
color: DodgerBlue
- value: -5
color: Cyan
- value: 0
color: Gold
- value: 5
color: Orange
- value: 10
color: Red
- entity: sensor.shf_temperature_70700
name: Sade
color: green
show:
in_header: false
extremas: false
legend_value: false
type: column
data_generator: |
return entity.attributes.data.map((start, index) => {
return [new Date(start["TimeStamp"]).getTime(), entity.attributes.data[index]["PrecipitationAmountMm"]];
});
Omassani (eri merkki) taitaa olla että kun pysähdys on yli 4h niin tulkitaan eri matkaksi.Joskus PSACC yhdistää usempia matkoja yhdeksi matkaksi
Kiitos mielenkiintoisesta vinkistä, pitihän tuo apinoida heti kun itse ei moiseen kykene.Sääennustus (lämpötila ja sade) postinumeroalueelle (tietysti spot-hinta.fi api:a hyödyntäen).
Tässä viimeisin versio koodeineen (postinumerolle 70700).
yaml koodit:
YAML:sensor: - platform: rest scan_interval: 300 name: "SHF temperature 70700" unique_id: shf_temperature_70700 resource: https://api.spot-hinta.fi/PostalCodeTemperatures/70700?HomeAssistant=true force_update: true value_template: 'OK' json_attributes: - "data" template: - sensor: - name: SHF temperature 70700 now unique_id: shf_temperature_70700_now unit_of_measurement: "°C" device_class: temperature state: '{{ state_attr("sensor.shf_temperature_70700", "data")[0]["Temperature"] }}'
Apex-grafiikan koodi (oletus 24h, +/- napeilla voi zoomata):
Koodi:type: custom:apexcharts-card show: last_updated: true apex_config: chart: zoom: enabled: true toolbar: show: true tools: zoom: false zoomin: true zoomout: true pan: false reset: false graph_span: 24h experimental: color_threshold: true header: title: Lämpötila- ja sade-ennuste / koti (24 h) show: true show_states: true colorize_states: true span: start: hour series: - entity: sensor.shf_temperature_70700_now color: '#00bfff' name: ' ' unit: ' °C (nyt)' show: header_color_threshold: true in_header: true in_chart: false color_threshold: - value: -20 color: Blue - value: -10 color: DodgerBlue - value: -5 color: Cyan - value: 0 color: Gold - value: 5 color: Orange - value: 10 color: Red - entity: sensor.shf_temperature_70700 name: Lämpötila color: '#00bfff' show: in_header: false extremas: true legend_value: false type: column data_generator: | return entity.attributes.data.map((start, index) => { return [new Date(start["TimeStamp"]).getTime(), entity.attributes.data[index]["Temperature"]]; }); color_threshold: - value: -20 color: Blue - value: -10 color: DodgerBlue - value: -5 color: Cyan - value: 0 color: Gold - value: 5 color: Orange - value: 10 color: Red - entity: sensor.shf_temperature_70700 name: Sade color: green show: in_header: false extremas: false legend_value: false type: column data_generator: | return entity.attributes.data.map((start, index) => { return [new Date(start["TimeStamp"]).getTime(), entity.attributes.data[index]["PrecipitationAmountMm"]]; });
Hyvä kysymys. En ole käyttänyt tuota automaatioon, kun minulla on suorasähkölämmitys ja ILP.Kiitos mielenkiintoisesta vinkistä, pitihän tuo apinoida heti kun itse ei moiseen kykene.
Saako lisäksi udella, millaisella /millaisilla automaatioilla olet tuota hyödyntänyt itse?
Mieleen tulee lähinnä ajatus et voisi hiukan etupainotteisesti nostaa VILP:n pyyntiä ennen kun kelit kylmenevät. Toisaalta tuossa täytynee nykytilanteessa huomioida myös sähkön hintaa näin pörssisähköllä kun operoi.
Muuttujia rupeaa siten olemaan useita.
Vielä kun tuon saisi siten, että käyttää met.no tuntiennustetta ja nordpoolin sähkönhintaa. Mutta kun ei oikein osaa niin on jäänyt tekemättä, apinointi on enemmän minunkin alaa.Sellainen automaatio on itselläni pyörinyt mielessä jossa VILP:n ohjaukseen hyödynnettäisiin ainakin sähköpörssihinnat ja lämpötilaennuste.
Ajatus perustuu oletukseen että kun vuorokauden keskiulkolämpötila on X astetta niin talon lämpimänä pitämiseen tarvitaan Y määrä kWh ja pörssihintojen perusteella noukitaan lämpöpumpulle tai muulle lämmönlähteelle tarvittava määrä tunteja (sopivalla hinnalla) energian tuottamiseen.
Toki tuossa on varmasti paljon lisäparametrejä esimerkiksi tuulen vaikutus, minkä verran energiaa kohteessa pystyy järkevästi varaamaan myöhempään käyttöön ja milloin on parempi tehdä se lämmitys ennemmin tarpeen mukaan.
Itse en osaa tuollaista ohjausta kirjoittaa mutta kaipa jossain vaiheessa joku osaava tuollaisenkin tekee mikä voi sit apinoida ja ehkä hiukan tuunata vielä omaan käytökseen.
Sellainen automaatio on itselläni pyörinyt mielessä jossa VILP:n ohjaukseen hyödynnettäisiin ainakin sähköpörssihinnat ja lämpötilaennuste.
Ajatus perustuu oletukseen että kun vuorokauden keskiulkolämpötila on X astetta niin talon lämpimänä pitämiseen tarvitaan Y määrä kWh ja pörssihintojen perusteella noukitaan lämpöpumpulle tai muulle lämmönlähteelle tarvittava määrä tunteja (sopivalla hinnalla) energian tuottamiseen.
Toki tuossa on varmasti paljon lisäparametrejä esimerkiksi tuulen vaikutus, minkä verran energiaa kohteessa pystyy järkevästi varaamaan myöhempään käyttöön ja milloin on parempi tehdä se lämmitys ennemmin tarpeen mukaan.
Itse en osaa tuollaista ohjausta kirjoittaa mutta kaipa jossain vaiheessa joku osaava tuollaisenkin tekee mikä voi sit apinoida ja ehkä hiukan tuunata vielä omaan käytökseen.
Oma räpellys saanut taas hieman uutta koodia ja muutaman käyttäjälle osoitetun valintamahdollisuuden.
Jos uhkaa tulla sallittua pidempi tauko, on nyt mukana myös kahden tunnin valinta siten, että sallittu tauon pituus täyttyy. Tuo olikin ihan hauska koodaustehtävä sallituista / mahdollisista tuntipareista ja näistä pareista edullisimman valinta. Huvikseni koodailin valinnan myös siten, että yhden tunnin tapauksessa vaihtoehtoisia tunteja tulee olla käyttäjän valitsema määrä tai muutoin tarkastellaan myös kahden tunnin tulos - tässä kahden tunnin ratkaisu voi tulla monella perusteella hylätyksi. Viimeksi mainittu tuli mukaan tilanteisiin, jossa yhdelle tunnille on vain muutama vaihtoehto ja ne sattuisi piikkihintoihin.
Sääennuste on tarvittavien tuntien määrittelyssä mukana nyt tuntihintojen loppuun saakka tai kuitenkin vähintään seuraavat 24 h. Extremas näyttää edelleen tuntihinnoissa väärin, mutta tuulivoiman tuottannossa oikein - ihme juttu. Muutama kuva taas spoilerissa.
Tämä alkaa olla nyt siinä vaiheessa, että voisi alkaa varsinaista ohjausta miettimään. Harmi vain, kun laitteisto puuttuu edelleen, niin en tiedä onko oikein mielekästä lähteä vielä ohjauspuolta miettimään. Harrastuksen vuoksi varmaankin aloittelen. En tiedä sotkeeko nämä postaukset ketjua, kun täällä taitaa tuo mainio SHF olla pääroolissa.
Sallituilla tunneillakin alkaa olla jo aika monta tunnusta käytössä:
1 -> Tuntihinta on alle hintarajan kaksi (valittavissa HA:ssa)
2 -> Tuntihinta on alle hintarajan yksi (valittavissa HA:ssa)
3 -> Tunti on rankin perusteella lämmitystunti (lämmitystarve / sallitut tunnit määritettävissä HA:ssa)
3.5 -> Tuntihinta poikkeaa tunnuksen 3 tunneista riittävän vähän (sentteinä ja prosentteina asetettu raja sekä maksimi sentteinä prosentteja varten, valittavissa HA:ssa)
4 -> Tauon katkaiseva tunti (yksi tunti riittää, tauon maksimipituus valittavissa HA:ssa)
4.5 -> Tauon katkaiseva tunti (kaksi tuntia tarvitaan, tauon maksimipituus valittavissa HA:ssa)
5 -> Jotain on mennyt pieleen, sallitaan lämmitys kuluvalle tunnille
Toteutuneita "lämmitystunteja" yllä esitettyjen tunnusten mukaisesti. Korkeat piikit katkomassa sallittua pidempiä taukoja. Otsikkoon voisikin lisätä myös toteutuneet sallitut lämmitystunnit.
katso liitettä 83647
Koko jakson tuntihintojen keskiarvo ei ole kovin paljoa sallittujen tuntien keskiarvoa suurempi. Kaksi tuntia on "suunnitelmassa" katkomassa liian pitkää taukoa - ensimmäinen näistä pitäisi olla arvoltaan periaatteessa 4.5, koska liittyy taukoon, joka edellytti kahden lisätunnin määrittämistä (näistä ensimmäinen jo toteutunut klo 14 alkaen). Ensimmäisen 4.5 jälkeen tuo tunti ei vaan enää tiedä, että onkin pari tuolle toiselle, kun laskenta pyörähtää uudelleen tunneittain.
katso liitettä 83648
Ei näistä parametreistä tahdo pysyä enää kärryillä. Otin kuitenkin matalalla kynnyksellä HA:n puolelle, ettei tarvitse kovakoodata (?) näitä ja muutokset onnistuu helposti "lennosta".
katso liitettä 83649
Spot-hinta.fi rajapinnasta löytyy tuollainen API, mutta se on ns. 200/400 API eli sitä pitäisi kysyä tunneittain.
Se käyttää lämmitystarpeen laskentaan 24h ulkolömpötilaennusteen keskiarvoa. Ja lämmitystuntien määrä lasketaan siihen suhteutettuna.
Säätiedot koordinaateilla tai postinumerolla haetaan yr.no palvelusta.
Nikkaroikaa siihen YAML niin saatte moisen ohjauksen aika helposti.
Nordpool näyttää siirtyneen HA:ssa virallisten integraatioiden puolelle.
Tietämättä yhtään mistään mitään, niin Nord Pool on se toimija, jonka kirjoihin ne hinnat muodostuvat, joten se on käytännössä datan alkulähde. Olisi erikoista, jos ne tulisivat niiden sivustolle jostain muualta, kuin omista järjestelmistä.Eikös tuossa ole edelleen ongelmana se, mistä ko. komponentti hakee datansa. Eli joku on reverse-engineerannut miten se Norpoolin HTML sivu hakee datansa ja sitten tuo HACS mokkula kursii samasta lähteestä tietonsa.
Eli periaatteessa jos Nordpool vaikka uusii sen sivunsa toisella tavalla tehdyksi, tuon HACS mokkulan toiminta loppuu kuin seinään. Vai olenko ymmärtänyt väärin että mistä tuo sen hakee?
Sivullahan ei datan lähdettä avoimesti edes kerrota, mikä on kumma juttu.
Siis tietenkin Nordpoolin omille sivuille tiedot tulee niiden omista järjestelmistä. Mutta kyse siis siitä että mistä tuo HACS paketti hakee tietonsa, kun sehän ei ole Nordpoolin tekemä tai tukema mitenkään.Tietämättä yhtään mistään mitään, niin Nord Pool on se toimija, jonka kirjoihin ne hinnat muodostuvat, joten se on käytännössä datan alkulähde. Olisi erikoista, jos ne tulisivat niiden sivustolle jostain muualta, kuin omista järjestelmistä.
Ymmärsin väärin, pahoittelut. Tuota NordPool-integraatiota en itse käytä ja yksi syy on tosiaan se, että se ei ole virallisesti tuettu ja olen käsittänyt, että jopa lisenssiehtojen vastainen. Lähinnä vain ajan kysymys, kun tuo lakkaa toimimasta IMO.Siis tietenkin Nordpoolin omille sivuille tiedot tulee niiden omista järjestelmistä. Mutta kyse siis siitä että mistä tuo HACS paketti hakee tietonsa, kun sehän ei ole Nordpoolin tekemä tai tukema mitenkään.
"Channel1":{"0":"0","1":"0","2":"0","3":"0","4":"0","5":"0","6":"0","7":"0","8":"0","9":"0","10":"0","11":"0","12":"1","13":"1","14":"1","15":"1","16":"1","17":"1","18":"0","19":"0","20":"0","21":"0","22":"0","23":"0"},
"Channel2":{"0":"1","1":"0","2":"0","3":"0","4":"0","5":"0","6":"1","7":"0","8":"0","9":"0","10":"0","11":"0","12":"1","13":"1","14":"1","15":"1","16":"1","17":"1","18":"0","19":"0","20":"0","21":"0","22":"0","23":"0"},
"Channel3":{"0":"0","1":"0","2":"0","3":"1","4":"0","5":"0","6":"0","7":"0","8":"1","9":"0","10":"0","11":"0","12":"0","13":"1","14":"1","15":"1","16":"1","17":"0","18":"0","19":"1","20":"0","21":"0","22":"0","23":"0"},
"Channel4":{"0":"1","1":"1","2":"1","3":"1","4":"1","5":"1","6":"1","7":"1","8":"1","9":"1","10":"1","11":"1","12":"1","13":"1","14":"1","15":"1","16":"1","17":"1","18":"1","19":"0","20":"0","21":"1","22":"0","23":"1"}}
Itselle on vielä parin päivän Home Assistant -opiskelun jälkeen osin epäselvää, että mihin tuo json kannattaisi tallentaa paikallisesti? Voiko koko jsonin tallentaa yksittäiseen sensoriin mistä sitä key kerrallaan voidaan lukea? Vai jokainen kanava omaksi sensorikseen? Onko järkeä sinällään purkaa tuota osiin jos siitä on tarkoitus kuitenkin tehdä se on/off- arvon antava ohjaussensori? Normaalitilanteessa serveri antaa uuden jsonin kerran tunnissa jos asetukset ei muutu palvelimella.
Tallentamispaikkaa ei tarvitse murehtia, se on jossain HA:n tietokannassa.Itselle on vielä parin päivän Home Assistant -opiskelun jälkeen osin epäselvää, että mihin tuo json kannattaisi tallentaa paikallisesti? Voiko koko jsonin tallentaa yksittäiseen sensoriin mistä sitä key kerrallaan voidaan lukea? Vai jokainen kanava omaksi sensorikseen?
Saan mqtt:n kautta sähkömittarin pulssista tiedon Home Assistanttiin, mikähän olisi yksinkertaisin keino muuttaa se Wh lukemaksi? Suhde on 500 pulssia/kWh ja minuutin välein tulee pulssitieto
Tarviikos pulssille tehdä muuta kuin kertoa kahdella niin saa Wh? Minkä takia pitäisi kertoa 60? En ainakaan graafisen liittymän puolelta löytänyt mihin voisi tuon laskutoimituksen laittaa, onnistuuko lisätä suoraan YAML:iin?Kulutus [Wh] = pulssit minutissa * 0.5 * 60 (Eikös se ole noin, kun yksi pulssi vastaa 0.5 Wh?)
Oletko kokeillut tehdä Integration Helpperin?
No ihan väärin laskin. Siis yksi pulssi vastaa 2 Wh kulutusta.Tarviikos pulssille tehdä muuta kuin jakaa kahdella niin saa Wh? Minkä takia pitäisi kertoa 60? En ainakaan graafisen liittymän puolelta löytänyt mihin voisi tuon laskutoimituksen laittaa, onnistuuko lisätä suoraan YAML:iin?
Mikä sinulla on sen pulssisensorin nimi ja mitä se nyt näyttää Developer Tools / States kohdassa?Juu minuutin välein tulee edeltävän minuutin pulssit, ja tarkoitus vaan summata pulssit ja muuntaa Wh.
Edim. Tunnin ja päivän ja kuukauden ajalta