HomeAssistant - Yleinen support topic

Kide

Jäsen
Aika samanlainen omassa, laitetaan nyt tämäkin oheen, hieman eri mausteilla:

YAML:
# Weather forecast from Meteorologisk institutt (Met.no).
# Response fields can be checked with action (Developer tools > Actions)
#   action: weather.get_forecasts
#   target:
#    entity_id: weather.forecast_home
#   data:
#    type: daily
# Notice that entity ID for template sensors currently appear to be based on the name, not unique_id
# -https://community.home-assistant.io/t/template-sensor-unique-id-is-ignored/485206/2
template:
  - trigger:
      - trigger: time_pattern
        hours: /1
        #minutes: /1 # For debugging
      - platform: homeassistant
        event: start
    action:
      - action: weather.get_forecasts
        data:
          type: daily
        target:
          entity_id: weather.forecast_home
        response_variable: daily
    sensor:
      - name: Weather forecast temperature today
        state: "{{ daily['weather.forecast_home'].forecast[0].temperature }}"
        unit_of_measurement: °C
      - name: Weather forecat temperature tomorrow
        state: "{{ daily['weather.forecast_home'].forecast[1].temperature }}"
        unit_of_measurement: °C
      - name: Weather forecast temperature day after
        state: "{{ daily['weather.forecast_home'].forecast[2].temperature }}"
        unit_of_measurement: °C

Laitetaan siis configuration.yaml tiedostoon.
 

jussi

Vakionaama
Mun on tarvinnu poistaa molemmat 2025 core-päivitykset, kun liki kaikki hyytyy. Onko kukaan muu huomannu vastaavaa? Joku niissä rikkoo ainakin mun systeemiä sen verran, että toiminta takkuaa aika vahvasti. Viimeisellä 2024 puolen corella toimii.

Nyt on saatu toi aurinkopaneliakin mittaava pic-prossulla tehty vehje naitettua esp-palikan kautta home assistanttiin. Vaihdoin siihen pienemmän virta-anturin, niin sain resoluutiota lisää ja harhailu väheni reilusti. Otin jo käyttöön 0,1A tarkkuuden. Tekoälyä kiusaamalla sain sit soveltamalla tehtyä myös energialaskurin template-sensoreilla.
Muutaman viikon päästähän sitä saattaa jo päästä taas testailemaankin, kun aurinko vähän vielä kiipee ylemmäs.
 

Espejot

Hyperaktiivi
Mikä nyt olisi paras tapa saada pörssihinnat HA? Victronon on nyt naitettu MQTT avulla mutta sielä ei pääse käsiksi spottitietoihin. API keyn san ENTSO-E:stä. Ajatuksena olisi saada muutama Victronille 1) milloin ladataan aina 2) milloin ei pureta verkkoon. En siis etsi viittä halvinta tuntia. Kaiken kaikiaa YAML on aika sekavan oloinen kieli, pitänee katsoa joku tutoriaali. Mutta simmoiseen käsitykseen jäin että jos haluaa laskea aritmeettisia laskutoimituksia niin se täytyy(kannataa tehdä muilla ohjelmointikielillä...kö? Onko jollain linkata hyv'än tutoriaalia YAML kieleen kun ei viitsis pelkästään copy pasteta...
 

Ville-Veikko

Aktiivinen jäsen
Mikä nyt olisi paras tapa saada pörssihinnat HA? Victronon on nyt naitettu MQTT avulla mutta sielä ei pääse käsiksi spottitietoihin. API keyn san ENTSO-E:stä. Ajatuksena olisi saada muutama Victronille 1) milloin ladataan aina 2) milloin ei pureta verkkoon. En siis etsi viittä halvinta tuntia. Kaiken kaikiaa YAML on aika sekavan oloinen kieli, pitänee katsoa joku tutoriaali. Mutta simmoiseen käsitykseen jäin että jos haluaa laskea aritmeettisia laskutoimituksia niin se täytyy(kannataa tehdä muilla ohjelmointikielillä...kö? Onko jollain linkata hyv'än tutoriaalia YAML kieleen kun ei viitsis pelkästään copy pasteta...
Ite olen tykännyt kovasti tästä täällä palstalla alkunsa saaneesta paketista https://github.com/T3m3z/spotprices2ha siinä tulee mukana paljon käyttökelpoista jota voi jalostaa lisääkin.

Eikai YAML ole mikään ohjelmointikieli, enemmänkin markup, kuten xml tai json. Home Assistantiin on koodattu oma template parseri johon vois sotkea ohjauskoodien sisään Pythonia ja Jinja -parseria. Melko karsee aluksi mutta kaikkeen tottuu...
Alkuun pääsee kun menee HA:n developer-tools/template -sivulle, siellä on linkit dokumentaatioon ja siinä ruudussa on helppo kokeilla omiakin sovelluksia.

Ja pyydä kokeeksi Copilotilta ihan suomeksi template sensori, saatat yllättyä positiivisesti...
1737460021774.png

YAML:
template:
  - sensor:
      - name: "Hintaero kalleimman ja halvimman ajanjakson välillä"
        unit_of_measurement: "€/kWh"
        state: >
          {% set prices = state_attr('sensor.shf_electricity_price', 'data') | map(attribute='PriceWithTax') | list %}
          {% set max_price = prices | max %}
          {% set min_price = prices | min %}
          {{ max_price - min_price }}
 

maanma

Vakionaama
YAML ei ole kieli vaan asetustiedosto malli samalla tapaa kuin .properties. Molemmissa samat asiat eri tavalla esitettynä.

1kk kokemuksella
Homeassistant näyttää olevan omanlaisensa toimintaympäristö, jossa esim muuttuja yms. on tapauskohtainen scope. Käsittely perustuu yleensä ylhäältä alaspäin kirjoitettuihin melko vakiomuotoisiin asetuksiin. En ole vielä nähnyt missään ei tarkkoja kuvauksia näistä.

Koodattujen ehtojen käsittelykieli on jinja.

Lähes kaikki ohjeet ovat käytännössä suorakoodauksia configuration.yaml, mistä säännöt ladataan muistiin.

Käyttöliittymän kautta ohjaukset on yleensä vaikeampi tehdä, koska esim. Automaatio = Trigger rakenne, joka on jaettu kolmeen lohkoon. Edes YAML kirjoitus tilassa ei tunnu sallivan Trigger sensoreita.

Apurit ovat tärkeimpiä seuranta elementtejä, joille Template kautta voi koodata itsenäisen toisista antureista ym. riippuvan arvon asetustoiminnon. Templatet kannattaa aina rakentaa tietolähde kerrallaan katsoakseen, että se arvo oikeasti tulevat niiden lähteistä, niin että järjestelmä ymmärtää ne. Esim välillä rivinvaihto haittaa ja välillä ei. Välillä toimii ilman implisiittistä datan muotoa kuvaavaa filtteriä ja välillä ei.

Ongelmaksi nousee usein, mikä on se palautuva muoto, jos alusta ei ymmärtänyt. Välillä se on unknown, none, is defined jne. Lopputulos muuttuu tietysti, jos perässä on implisiittistä datan muotoa kuvaavaa filtteri.
 

hemaris

Aktiivinen jäsen
YAML ei ole kieli vaan asetustiedosto malli samalla tapaa kuin .properties. Molemmissa samat asiat eri tavalla esitettynä.

1kk kokemuksella
Homeassistant näyttää olevan omanlaisensa toimintaympäristö, jossa esim muuttuja yms. on tapauskohtainen scope. Käsittely perustuu yleensä ylhäältä alaspäin kirjoitettuihin melko vakiomuotoisiin asetuksiin. En ole vielä nähnyt missään ei tarkkoja kuvauksia näistä.

Koodattujen ehtojen käsittelykieli on jinja.

Lähes kaikki ohjeet ovat käytännössä suorakoodauksia configuration.yaml, mistä säännöt ladataan muistiin.

Käyttöliittymän kautta ohjaukset on yleensä vaikeampi tehdä, koska esim. Automaatio = Trigger rakenne, joka on jaettu kolmeen lohkoon. Edes YAML kirjoitus tilassa ei tunnu sallivan Trigger sensoreita.

Apurit ovat tärkeimpiä seuranta elementtejä, joille Template kautta voi koodata itsenäisen toisista antureista ym. riippuvan arvon asetustoiminnon. Templatet kannattaa aina rakentaa tietolähde kerrallaan katsoakseen, että se arvo oikeasti tulevat niiden lähteistä, niin että järjestelmä ymmärtää ne. Esim välillä rivinvaihto haittaa ja välillä ei. Välillä toimii ilman implisiittistä datan muotoa kuvaavaa filtteriä ja välillä ei.

Ongelmaksi nousee usein, mikä on se palautuva muoto, jos alusta ei ymmärtänyt. Välillä se on unknown, none, is defined jne. Lopputulos muuttuu tietysti, jos perässä on implisiittistä datan muotoa kuvaavaa filtteri.

Eniten itseäni HAssa häiritsi alussa YAML syntaksin kryptisyyden lisäksi globaalien muuttujien puute. Päädyin itse käyttämään githubista löytyvää custom integraatiota:

Helpereillä pystyy nykyään tekemään saman asian, mutta itse tykkään edelleen näistä globaaleista muuttujista omissa automaatioissani.
 

haraldh

Vakionaama
Haluatko tosiaan sen hinnan, vai sen suhteellisen hinnan vuorokauden muihin tunteihin nähden?

Yksi sensori on sensor.shf_average_price_next_hours ja sen saa liukusäätimellä asetettua näyttämään n tuntia eteenpäin. Noita voi tietenkin tehdä itse lisää, vaikka juuri seuraavan tunnin hinta.
 
Viimeksi muokattu:

Espejot

Hyperaktiivi
Haluatko tosiaan sen hinnan, vai sen suhteellisen hinnan vuorokauden muihin tunteihin nähden?

Yksi sensori on sensor.shf_average_price_next_hours ja sen saa liukusäätimellä asetettua näyttämään n tuntia eteenpäin. Noita voi tietenkin tehdä itse lisää, vaikka juuri seuraavan tunnin hinta.

Oikeastaan tässä vaiheessa haluan hinnan koska haluan ladata akut jo hinta alle x1 ja estää purun jos hinta alle x2. Siis tämä nyt tässä vaiheessa ajatuksena. Kun nyt saan jotakin aikaseksi niin katson sitten johtaako tämä mihinkään. HA hieman mietityttää kuinka paljon vaatii huolenpitoa kun ei ole "tee valmiiksi ja unohda" vaan rikkoutumisia tuntuu tapahtuvan.
 
Viimeksi muokattu:

Pretor

Aktiivinen jäsen
HA hieman mietityttää kuinka paljon vaatii huolenpitoa kun ei ole "tee valmiiksi ja unohda" vaan rikkoutumisia tuntuu tapahtuvan.
Rohkeasti vaan kimppuun. Ei oo hetkeen vapaa-ajasta puutetta, kun raapii päätä ja miettii mitä kaikkea keksisi säätää.
Kunhan pääsee sinuiksi tuon kanssa, niin ei siinä lopulta niin hirveästi ole huolenpitoa. Päivitykset tietty voi aina vähän jännittää, että mitäs tällä kertaa, mutta sen takia on backupit keksitty
;D
 

maanma

Vakionaama
Onkos joku ehtinyt rakennella fingrid apeista jotain tuon tapaista kuin tuo forecan hintasääpuntari ?
- Kokonaiskulutuksesta saa 24 tunnin ennusteen, 15min tarkkuudella
- Tuulesta saa 36 tunnin ennusteen, 15 min tarkkuudella
- Kaukolämpövoimalaitosten tuotto, 3 min tarkkuudella tätä voinee käyttää refenssinä ainakin muutossuunnan kulmakertoimeen.
- Sähköboilerien kulutus, reaaliaikainen data 1min

Optiona
Dayahed transmission capacity
- EE-FI
- SE1-FI
jne
 
Viimeksi muokattu:

jussi

Vakionaama
Taas tarttis keksiä, miten tollanen esp-8266 palikka nodemcu-mallia resetoidaan ihan tyhjäksi. Viimesen lisätyn softan jälkeen ei kytkeydy enää verkkoon, eikä softaannu johdollakaan. Vilkuttaa vaan lediä, mutta mitään ei tapahdu.
Olihan siinä virhe koodissa, mutta ei mitään hirveen kriittistä minusta. Vaan kuoli se siitä huolimatta.
Ikävästi ainoo "hyllyssä" oleva vapaa vehje ja just nyt olis tarvinnu, kun ajatus on sidottu siihen hommaan. Kerkeen unohtaa homman nyanssit ennenku kiinaposti tuo uusia tänne...

E: Ja oho, just tätä kirjotellessa siihen näyttöön ilmesty oikee kellonaika. Eli onhan sen pakko olla verkossa... Vaan ei näköjään päivity kuitenkaan kun älyttömän hitaasti, 5 min ottaa niin aika korjaantuu. Ja näköjään resetoi ittensä vähän väliä.
 
Viimeksi muokattu:
K

korsteeni

Vieras
käyt hakemassa, jos ei vielä ole esp easy, siinä tulee mukana kullekin muistikoolle täydellinen tyhjennys, on helppo käyttää ja saa useimmat anturit suoraa klickkailemalla, lähettää datan minnevain jne
on esp killukoiden ala-aste aloituksen suhteen eikä paha vaikkei siitä luovukaan esmes to esphome

 

jussi

Vakionaama
käyt hakemassa, jos ei vielä ole esp easy, siinä tulee mukana kullekin muistikoolle täydellinen tyhjennys, on helppo käyttää ja saa useimmat anturit suoraa klickkailemalla, lähettää datan minnevain jne
on esp killukoiden ala-aste aloituksen suhteen eikä paha vaikkei siitä luovukaan esmes to esphome

En keksiny miten tuota käytetään. Binääreistä löysin esptool.exen, joka vaan vilahti ruudulla. Readme antoi paljon mahdollisuuksia tehdä jotain väärin, kun en tuosta palikasta enää saa edes selville paljonko siinä oli muistia.
 
K

korsteeni

Vieras
En keksiny miten tuota käytetään. Binääreistä löysin esptool.exen, joka vaan vilahti ruudulla. Readme antoi paljon mahdollisuuksia tehdä jotain väärin, kun en tuosta palikasta enää saa edes selville paljonko siinä oli muistia.
minä teen tuolla flasher.exellä
1737643065638.png
 
K

korsteeni

Vieras
Mistä noista paketeista se löyty? Kun niitähän oli monta siinä tarjolla.
enpä ole aikoihin ottanut uusia joten en huomannut että puuttuu paketista, onhan siellä muita mutta kun kaikki voi tehdä niin monella tavoin
tuon voi ladata erikeenkin, olen käyttänyt kun tuli aina paketin mukana, nyt käytän ihan visul studio ohjelmaa
esmes täältä löytyy
 

jussi

Vakionaama
enpä ole aikoihin ottanut uusia joten en huomannut että puuttuu paketista, onhan siellä muita mutta kun kaikki voi tehdä niin monella tavoin
tuon voi ladata erikeenkin, olen käyttänyt kun tuli aina paketin mukana, nyt käytän ihan visul studio ohjelmaa
esmes täältä löytyy
Tossa linkin flasherissa näyttäs just erase-toiminto puuttuvan. Sen taidan tarvita, kun toi palikka on jumissa.
 

-Teme-

Vakionaama
Oikeastaan tässä vaiheessa haluan hinnan koska haluan ladata akut jo hinta alle x1 ja estää purun jos hinta alle x2. Siis tämä nyt tässä vaiheessa ajatuksena. Kun nyt saan jotakin aikaseksi niin katson sitten johtaako tämä mihinkään. HA hieman mietityttää kuinka paljon vaatii huolenpitoa kun ei ole "tee valmiiksi ja unohda" vaan rikkoutumisia tuntuu tapahtuvan.
T3m3zin paketti ja tekee template sensorin sille seuraavalle tunnille
YAML:
template:
  sensor:
  - name: "Electricity price next"
    unique_id: electricity_price_next
    unit_of_measurement: "c/kWh"
    state: >
      {% set next_hr = state_attr("sensor.shf_electricity_price", "data")[states("sensor.shf_idx")|int+now().hour +1] %}
      {{ next_hr["PriceWithTax"] | float * 100 | round(3) | default(none)  }}
 

jussi

Vakionaama
enpä ole aikoihin ottanut uusia joten en huomannut että puuttuu paketista, onhan siellä muita mutta kun kaikki voi tehdä niin monella tavoin
tuon voi ladata erikeenkin, olen käyttänyt kun tuli aina paketin mukana, nyt käytän ihan visul studio ohjelmaa
esmes täältä löytyy
No joo, tuosta se lähti, ei suoraan kyllä mutta vihjeitä arpomalla. Tän illan puuhasteluista olis tullu jo pieni romaani tai tietokirjakin...
Pääasia kuiten oli, että toi ESPEasy suostu flashaamaan palikan, kun kaikki muut kieltätyi. Sitä piti vaan huijata tiedostonimillä, kun ei sitä kiinnosta kun omat binäärinsä. Ja niillehän mulla ei ole käyttöä. Homma alko varmistumaan, kun tallessa oli vilppiä lukevan MiniD1 palikan .bin file ja naamioin sen näyttämään easyesp fileeltä. Ajoin flashin, ja heti vilpin liikenne sotkeentui HAssa. Kun kaksi samaa yritti yhteyttä. Eli softaus onnistui.
Tein sitten ihan uuden esp-laitteen perusmuotoisella koodilla HAssa. Otin sen .bin fileen ja taas nimeä huijaamalla ajoin flashin easyesp:llä.
Sinnehän se uus ilmesty "online". Korjasin koodin viimeseen toimivaan ja lataus meni ihan wlanin kautta. Kuollut palikka on taas elossa.

Josta vois palata siihen kuolemaan. Saako yaml koodissa olla kahdessa kohdassa lambda: |- määrittely? Uart: kohdassa omansa ja display: kohdassa omansa. Jotenkin tuohon se kuolema liittyi.
 

jussi

Vakionaama
Näköjään riittää pelkästään se uart käsittely sekottamaan ton. Nyt laitoin täsmälleen saman koodin kun kahdessa D1_mini levyssä toimii, tuossa nodemcu versiossa menee jotain sekasin. Karvatkin pitäs kyllä olla samoilla numeroilla ainakin rx ja tx osalta.
Ilmestyy kyllä verkkoonkin, mutta kun pyytää lokia, niin connection lost heti...
 

jussi

Vakionaama
Näköjään riittää pelkästään se uart käsittely sekottamaan ton. Nyt laitoin täsmälleen saman koodin kun kahdessa D1_mini levyssä toimii, tuossa nodemcu versiossa menee jotain sekasin. Karvatkin pitäs kyllä olla samoilla numeroilla ainakin rx ja tx osalta.
Ilmestyy kyllä verkkoonkin, mutta kun pyytää lokia, niin connection lost heti...
Näyttää nyt siltä että tolla kortilla ei voi käyttää uartin rx oletusporttia gpio3, se on se mikä sotkee kaiken. Vaihdoin sen gpio13 rxd2 porttiin, niin jopa alko toimimaan ainakin alustavasti lokin mukaan. Muutetaas kytkentäkin vastaamaan tuota ja katotaan mitä tapahtuu...
E: Ja niinhän kaikki toimii. Pikkunäyttö toimii, ja rx karva poimii kiertovesipumppujen ohjaimelta tiedot kattilasta, varaajasta ja auurinkokeräimen lämmöstä.
 
Viimeksi muokattu:

jussi

Vakionaama
Nyt kun sain ton pumppuohjaimen kirjottamaan lokia HAn tauluun, niin huomasinkin et joku häiriköi Picin ad-muunninta aikas reilusti ja arvot hyppelee. Oma näyttö päivittyy niin hitaasti, kun kierrättää viittä arvoa, ettei siinä ole tuota huomannutkaan. Tosin se näyttökomponentti lokin mukaan käyttää liikaa aikaa, joka vaikuttaa luetun sarjadatan näkymiseen lokissa ainakin, saadut arvot on kyllä ihan järkeviä sinänsä.
 
Hokasinpa että jos asuu suht lähellä tiesääasemaa, niin digitrafficilta saa aika hyvän oman sääaseman.
Täytä koodiin oman asemasi ID
Väkästelin muutaman sensorin testiin.
Tiesääasemat kartalla: https://liikennetilanne.fintraffic.fi/share/?13927o5x-u
Asemien id: https://tie.digitraffic.fi/api/weather/v1/stations
Yksittäisen aseman data: https://tie.digitraffic.fi/api/weather/v1/stations/ASEMAN_ID/data
Selitykset: https://tie.digitraffic.fi/api/weather/v1/sensors

Löytyy myös täysi api josta saisi kaikenlaista mielenkiintoista irti kun vaan osaisi. Esimerkiksi milloin se oma tie on viimeksi aurattu, tai aura-autojen liikkeet. Onkos muut tehneet näillä tiedoilla jotain?

YAML:
sensor:
  - platform: rest
    resource: https://tie.digitraffic.fi/api/weather/v1/stations/ASEMAN ID NUMERO/data
    method: GET
    name: "Digitraffic Weather Data"
    json_attributes:
      - sensorValues
    value_template: ""
    scan_interval: 300
 
  - platform: template
    sensors:
      digitraffic_ilma_lampo:
        friendly_name: "Lämpötila"
        unique_id: "5967c35d-e9ae-4afd-8212-9160c41465d2"
        value_template: "{{ state_attr('sensor.digitraffic_weather_data', 'sensorValues') | selectattr('id', 'equalto', 1) | map(attribute='value') | first }}"
        unit_of_measurement: "°C"
      digitraffic_tie_lampo:
        friendly_name: "Tien lämpö"
        unique_id: "6a3f8b65-2b0e-4e5f-a25c-1e5d7d1e49cb"
        value_template: "{{ state_attr('sensor.digitraffic_weather_data', 'sensorValues') | selectattr('id', 'equalto', 2) | map(attribute='value') | first }}"
        unit_of_measurement: "°C"
      digitraffic_keskituuli:
        friendly_name: "Keskituuli"
        unique_id: "7d4b72e0-2ac3-4b27-9cdd-19e1f91841f5"
        value_template: "{{ state_attr('sensor.digitraffic_weather_data', 'sensorValues') | selectattr('id', 'equalto', 16) | map(attribute='value') | first }}"
        unit_of_measurement: "m/s"
      digitraffic_maksimituuli:
        friendly_name: "Maksimituuli"
        unique_id: "8f1c7b63-4e6e-4c38-9310-4c99ec1ed5bb"
        value_template: "{{ state_attr('sensor.digitraffic_weather_data', 'sensorValues') | selectattr('id', 'equalto', 17) | map(attribute='value') | first }}"
        unit_of_measurement: "m/s"
      digitraffic_ilmankosteus:
        friendly_name: "Ilmankosteus"
        unique_id: "9e4c92d3-5f7f-4b48-9328-6e1f78a2c4e9"
        value_template: "{{ state_attr('sensor.digitraffic_weather_data', 'sensorValues') | selectattr('id', 'equalto', 21) | map(attribute='value') | first }}"
        unit_of_measurement: "%"
      digitraffic_sade_intensiteetti:
        friendly_name: "Sateen intensiteetti"
        unique_id: "ad2f6c3b-5c1e-4b2f-9de4-4d7c5e8f9a61"
        value_template: "{{ state_attr('sensor.digitraffic_weather_data', 'sensorValues') | selectattr('id', 'equalto', 23) | map(attribute='value') | first }}"
        unit_of_measurement: "mm/h"
      digitraffic_nakyvyys_km:
        friendly_name: "Näkyvyys"
        unique_id: "bd5e8b7a-6a4f-4d1e-9b5e-7e2d8b2f8c9d"
        value_template: "{{ state_attr('sensor.digitraffic_weather_data', 'sensorValues') | selectattr('id', 'equalto', 26) | map(attribute='value') | first }}"
        unit_of_measurement: "km"
      digitraffic_sade:
        friendly_name: "Sade"
        unique_id: "ce6f8b4a-7b5f-4c1d-9c7e-8e3d9b2f7a4f"
        value_template: >
          {% set sensor_values = state_attr('sensor.digitraffic_weather_data', 'sensorValues') %}
          {% if sensor_values %}
            {% set sensor_value = sensor_values | selectattr('id', 'equalto', 22) | list %}
            {% if sensor_value and sensor_value[0].get('sensorValueDescriptionFi') %}
              {{ sensor_value[0].sensorValueDescriptionFi }}
            {% else %}
              No valid description found
            {% endif %}
          {% else %}
            No data available
          {% endif %}
      digitraffic_sateen_olomuoto:
        friendly_name: "Sateen olomuoto"
        unique_id: "df7f9b3a-8c5e-4d1b-9c9d-9e3c9b5e8a7f"
        value_template: >
          {% set sensor_values = state_attr('sensor.digitraffic_weather_data', 'sensorValues') %}
          {% if sensor_values %}
            {% set sensor_value = sensor_values | selectattr('id', 'equalto', 25) | list %}
            {% if sensor_value and sensor_value[0].get('sensorValueDescriptionFi') %}
              {{ sensor_value[0].sensorValueDescriptionFi }}
            {% else %}
              No valid description found
            {% endif %}
          {% else %}
            No data available
          {% endif %}
      digitraffic_tien_pinta:
        friendly_name: "Tien pinta"
        unique_id: "f8a1b2c3-9d4e-4e1d-9e7e-8a3d9b5f6c7b"
        value_template: >
          {% set sensor_values = state_attr('sensor.digitraffic_weather_data', 'sensorValues') %}
          {% if sensor_values %}
            {% set sensor_value = sensor_values | selectattr('id', 'equalto', 27) | list %}
            {% if sensor_value and sensor_value[0].get('sensorValueDescriptionFi') %}
              {{ sensor_value[0].sensorValueDescriptionFi }}
            {% else %}
              No valid description found
            {% endif %}
          {% else %}
            No data available
          {% endif %}
 
Viimeksi muokattu:

maanma

Vakionaama
Onkos joku ehtinyt rakennella fingrid apeista jotain tuon tapaista kuin tuo forecan hintasääpuntari ?
Hintasääpuntaria on käsitelty

Eka ajatus toteutuksesta olisi se, että tämän pohjalta voisi säätää lämpöbufferia. Omassa toteutuksessa lämpöbufferin tehtävä on toimia mittaus/suunnitelu ym. kalliin hinnan yleisbufferina. 18 astetunnin nykybufferilla menee tyydyttävästi 2 vrk yli riippuen ylilatauksen tilanteesta. 30% ylilataus on tällä hetkellä sallittu kun hinta on riittävän halpa.
 

jussi

Vakionaama
Mulla tulee esp-lokiin paljon noita varoituksia hitaasta komponentista. Tarviiko, tai voiko asialle tehdä jotain esm. koodia korjaamalla?
Koodi:
[18:02:46][D][uart_debug:069]: Received byte: 0x00 (Reversed: 0x00)
[18:02:46][W][component:237]: Component mdns took a long time for an operation (104 ms).
[18:02:47][W][component:238]: Components should block for at most 30 ms.
[18:02:47][W][component:237]: Component display took a long time for an operation (1031 ms).
[18:02:47][W][component:238]: Components should block for at most 30 ms.
[18:02:47][D][uart_debug:069]: Received byte: 0x00 (Reversed: 0x00)
[18:02:48][W][component:237]: Component display took a long time for an operation (307 ms).
[18:02:48][W][component:238]: Components should block for at most 30 ms.
[18:02:48][D][uart_debug:069]: Received byte: 0x00 (Reversed: 0x00)
[18:02:48][D][uart_debug:069]: Received byte: 0x00 (Reversed: 0x00)
[18:02:48][D][uart_debug:069]: Received byte: 0x00 (Reversed: 0x00)
[18:02:48][D][uart_debug:069]: Received byte: 0x02 (Reversed: 0x40)
[18:02:48][D][uart_debug:069]: Received byte: 0x94 (Reversed: 0x29)
[18:02:48][D][uart_debug:069]: Received byte: 0xF8 (Reversed: 0x1F)
[18:02:48][D][uart_debug:069]: Received byte: 0x7C (Reversed: 0x3E)
[18:02:48][D][uart_debug:069]: Received byte: 0x80 (Reversed: 0x01)
[18:02:48][D][uart_debug:069]: Received byte: 0x9E (Reversed: 0x79)
[18:02:48][D][uart_debug:103]: Processing packet: 39 00 00 00 00 00
[18:02:48][D][uart_debug:113]: State: Kaikki pois
[18:02:48][D][text_sensor:064]: 'Pumput käynnissä': Sending state 'Kaikki pois'
[18:02:48][D][sensor:093]: 'Varalla': Sending state 0.00000 °C with 1 decimals of accuracy
[18:02:48][D][sensor:093]: 'Varalla vain': Sending state 0.00000 % with 1 decimals of accuracy
[18:02:48][D][uart_debug:103]: Processing packet: 40 29 1F 3E 01 79
[18:02:48][D][sensor:093]: 'Varaajan ylälämpö': Sending state 41.00000 °C with 1 decimals of accuracy
[18:02:48][D][sensor:093]: 'Varaajan alalämpö': Sending state 31.00000 °C with 1 decimals of accuracy
[18:02:48][D][sensor:093]: 'Kattilan lämpö': Sending state 62.00000 °C with 1 decimals of accuracy
[18:02:48][D][sensor:093]: 'Aurinkokeräimen lämpötila': Sending state 1.00000 °C with 1 decimals of accuracy
[18:02:48][W][component:237]: Component uart took a long time for an operation (133 ms).
[18:02:48][W][component:238]: Components should block for at most 30 ms.
[18:02:48][D][homeassistant.sensor:024]: 'sensor.powercollector2_power_consumption_momentary': Got state 3.70
[18:02:48][D][sensor:093]: 'sähköä kuluu nyt': Sending state 3.70000  with 1 decimals of accuracy
[18:02:48][D][homeassistant.sensor:024]: 'sensor.powercollector2_power_consumption_momentary': Got state 3.66
[18:02:48][D][sensor:093]: 'sähköä kuluu nyt': Sending state 3.66000  with 1 decimals of accuracy
[18:02:48][W][component:237]: Component display took a long time for an operation (307 ms).
[18:02:48][W][component:238]: Components should block for at most 30 ms.
[18:02:49][D][homeassistant.sensor:024]: 'sensor.powercollector2_power_consumption_momentary': Got state 3.68
[18:02:49][D][sensor:093]: 'sähköä kuluu nyt': Sending state 3.68000  with 1 decimals of accuracy
 

grendy

Vakionaama
Millasilla kaavoilla laskette COPia tai pumpun antotehoa? Mun kaavoissani Heat Pump Thermal Power menee sulatuksen aikana isosti pakkaselle (-7kW - -7,5kW) ja tän ansiosta myös COP on -12 pahimmillaan sulatuksen aikana. Tekee ison loven myös tietysti VILPin kokonais-copiin. Onhan se selkeä että sulatuksen aikana VILP ei tuota lämpöä vaan kuluttaa pikemminkin energiaa, mutta kumpi on oikeampi tapa laskea COP, niin että antoteho minimi on 0W vai antaako sen vaan mennä miinukselle?

Esimerkkitapaus sulatuksesta jossa arvojen annetaan mennä miinukselle:

1738495054007.png
 
K

korsteeni

Vieras
täällä on varmaan esp32 käyttäjiä.
oletteko saaneet ds2482 toimimaan siinä ja yleensäkin onewiren.
minulla on muutama sd18b20 anturi ollut vaihtelevalla menestyksellä kymmenisen vuotta es8266 kiinni, toimineet kuitenkin, mutta nyt kun kokeilin tuota ds2482 niin en saanut dataa ulos, herjailikin, kokeilin sitten io pinneihin suoraan 20 kpl ds18b20 mutta ei se tunnu handlaavan niitäkään kun pari kappaletta ja nekin pinni/kappale ja muutenkin oli kuin täi tervassa, ei oikein vauhtia ollenkaan
 

haraldh

Vakionaama
Millasilla kaavoilla laskette COPia tai pumpun antotehoa? Mun kaavoissani Heat Pump Thermal Power menee sulatuksen aikana isosti pakkaselle (-7kW - -7,5kW) ja tän ansiosta myös COP on -12 pahimmillaan sulatuksen aikana. Tekee ison loven myös tietysti VILPin kokonais-copiin. Onhan se selkeä että sulatuksen aikana VILP ei tuota lämpöä vaan kuluttaa pikemminkin energiaa, mutta kumpi on oikeampi tapa laskea COP, niin että antoteho minimi on 0W vai antaako sen vaan mennä miinukselle?
Minua kiinnostaa vain COP silloin kun lämmitetään, ainakin tällä hetkellä. Sen takia leikkaan pois kaikki piikit kuvaajista.
 

Pretor

Aktiivinen jäsen
Millasilla kaavoilla laskette COPia tai pumpun antotehoa? Mun kaavoissani Heat Pump Thermal Power menee sulatuksen aikana isosti pakkaselle (-7kW - -7,5kW) ja tän ansiosta myös COP on -12 pahimmillaan sulatuksen aikana. Tekee ison loven myös tietysti VILPin kokonais-copiin. Onhan se selkeä että sulatuksen aikana VILP ei tuota lämpöä vaan kuluttaa pikemminkin energiaa, mutta kumpi on oikeampi tapa laskea COP, niin että antoteho minimi on 0W vai antaako sen vaan mennä miinukselle?
Jos tuo kovasti häiritsee niin tee template-sensor ja sinne sitten kriteeriksi esim. sulatus pitää olla inactive COPpia laskiessa.
Saat myös tehtyä template-sensorin jolla otat talteen pelkät sulatukset.

Sinänsähän tuo on ehkä "oikeampi" luku, kun se sisältää sulatuksetkin. Ei niiden vaikutus mitään järisyttävän suurta ole. Kelistä/ajankohdasta/ilmasta/sulatustiheydestä tietty hieman riippuu, mutta hatusta heittäen jossain 0.1-0.2 välillä. Vuositasolla kuitenkin tasoittuu.
Mulla esim. vuosi-COP tälle vuodelle näyttää tällä hetkellä 3.15 ilman sulatuksia ja sulatusten kanssa 3.07.
 

Ville-Veikko

Aktiivinen jäsen
Minua kiinnostaa vain COP silloin kun lämmitetään, ainakin tällä hetkellä. Sen takia leikkaan pois kaikki piikit kuvaajista.
Samalla logiikalla minäkin lasken. Kun se sulatuksessa käytetty energia jo aiemmin tuotettu ja laskee tuoton nollana sulatuksen ajan, mutta mittaa sähkön kuitenkin koko ajalta, äkkiseltään ajateltuna ei nyt ihan kauheasti pidemmän ajan keskiarvo vihkoon mene.

Daikinissa muuten defrost -tila on aktiivisena minuttitolkulla pidempään mitä tuotto pysyy negatiivisena. Mä tein templaten joka palauttaa lämmitystehoksi nollaa niin pitkään kuin paluuvesi on kylmenmää kuin sisäänmeno.
 

Tekniikkatulitaloon

Aktiivinen jäsen
Haluaisin saada aurinkovoimalan tuoton Home Assistanttiin, mutta voimalan Froniuksesta puuttuu verkkoyhteys. Verkkoon yhdistettävyyden sijaan on Invertteriin liitetty GEF:fin seurantalaite ja tuotantoa sekä tehoa pystyy seurailemaan Vision palvelusta. Sain hyvän idean hakea tuotantotiedot Visionista HA:n web scraperillä, mutta eihän se nyt tunnu onnistuvan millään. Ainut mitä olen onnistun tuolta nettisivulta hakemaan on tekstikenttien tiedot, mutta mitään numeroita ei tule vaan sensorit näyttää tyhjää.

https://vision.gef.fi/93eda5f2-c40f-400a-96df-3d6fcc8a5c02/

Tuossa on Hyvinkään sairaalan vastaava seurantasivu kun omaa en viitsi jakaa siinä näkyvien osoitetietojen vuoksi.

Tällä koodilla esim sensori näyttää tyhjää.

Koodi:
scrape:
  - resource: https://vision.gef.fi/93eda5f2-c40f-400a-96df-3d6fcc8a5c02/
    scan_interval: 15
    headers:
      User-Agent: Mozilla/5.0
      Viewport-Width: 1440
    sensor:
      - name: Vision
        select: "body > div.container-fluid > div:nth-child(5) > div > div.col-xl-5.d-table.offset-xl-1.box > div.d-table-row.h-30.box-bottom > div:nth-child(2) > span"
        value_template: '{{ value.split(" ")[0].replace(",", ".") | float }}'
        unit_of_measurement: "W"

Tekoälyn kanssa pähkäillyt ongelmaa ja vaikuttaa, että datan kaapimiseksi tarvitaan monimutkaisempaa koodia ja vaikka AI sitä suoltaakin innokkaasti ei homma pelitä enkä oikein tiedä miksi.

Osaisiko joku ratkaista tiedonhaku ongelman tai ohjata oikeaan suuntaan? Tarvisin siis hetkellisen tehon ja/tai päivän tuoton sivulta Home Assistanttiin.
 

tjani

Aktiivinen jäsen
Osaisiko joku ratkaista tiedonhaku ongelman tai ohjata oikeaan suuntaan? Tarvisin siis hetkellisen tehon ja/tai päivän tuoton sivulta Home Assistanttiin.
YAML:
rest:
  resource: "https://vision.gef.fi/api/v1/plant/93eda5f2-c40f-400a-96df-3d6fcc8a5c02/"
  sensor:
    - name: power
      value_template: "{{ value_json['power']['production'] /1000 }}"
   
    - name: production today
      value_template: "{{ value_json['energy']['production']['today'] /1000 }}"

Tästä varmaan pääset etiäpäin?
Laitat tuon API osoitteen selaimeen niin näet mitä kaikkea saat sieltä halutessasi ongittua.
 

Tekniikkatulitaloon

Aktiivinen jäsen
YAML:
rest:
  resource: "https://vision.gef.fi/api/v1/plant/93eda5f2-c40f-400a-96df-3d6fcc8a5c02/"
  sensor:
    - name: power
      value_template: "{{ value_json['power']['production'] /1000 }}"
  
    - name: production today
      value_template: "{{ value_json['energy']['production']['today'] /1000 }}"

Tästä varmaan pääset etiäpäin?
Laitat tuon API osoitteen selaimeen niin näet mitä kaikkea saat sieltä halutessasi ongittua.
Kylläpä on yksinkertaisen kaunista. Yritin ampua selkeästi tykillä kärpästä. o_O

Ja pääsen tästä etiäpäin odottelemaan huomista miten teholukemat päivittyy sensoreihin ja ehkä virittelemään kuorman ohjauksia.
 

jussi

Vakionaama
Mikä mulla on tossa väärin, kun tuo energialaskenta ei ole kumuloituva?
Koodi:
template:
  - sensor:
      - name: "Aurinkopaneelin teho"
        state_class: measurement
        device_class: power
        unique_id: "Solar power"
        unit_of_measurement: W
        state: >
          {% set voltage = states('sensor.aurinkomittaukset_panelien_j_nnite') | float(0) %}
          {% set current = states('sensor.aurinkomittaukset_panelien_virta') | float(0) %}
          {{ (voltage * current) | round(2) }}
#template:
  - sensor:
      - name: "Aurinkopaneelin energia"
        unique_id: "aurinkopaneelin_energia"
        unit_of_measurement: "kWh"
        device_class: energy
        state_class: total_increasing
        state: >
          {{ states('sensor.aurinkopaneelin_teho') | float * (5 / 60 / 1000) }}
 
Back
Ylös Bottom