HomeAssistant - Yleinen support topic

Joksa

Aktiivinen jäsen
Joo ei taida onnistua muuten saada erilaisia hälytyksiä, kun jakaa ilmoitukset usempaan osaan. Vibralla näyttää olevan 4 erilaista asetusta.
 

Liitteet

  • vibra.PNG
    vibra.PNG
    70,2 KB · Katsottu: 116

dbwarrior

Vakionaama
Juu, 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.
Tällaisella sain nyt kaksi sensoria aikaiseksi joihin tallettuu tunnin pääteessä(xx:59:5:cool: tunnin taseen arvo pohjautuen siihen, onko se tunti ostoa vai myyntiä

YAML:
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"
 

Ilpo55

Jäsen
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"]];
      });
 

Liitteet

  • HA_SPH_E.jpg
    HA_SPH_E.jpg
    32,3 KB · Katsottu: 142

Ilpo55

Jäsen
Onko täällä kukaan kiinnostunut MyPeugeot (MyOpel, MyCitroen) appin korvaamisesta HA:n Add-on:illa?
Minä olen nyt pari kuukautta viritellyt ja käyttänyt HA:ssa pyörivää PSA Car Controller Add-onia Hybrin Peugeotille.
HA:lla toimii etäohjaus ja tietojen luku luotettavasti, mitä ei voi sanoa MyPeugeot appista. PSACC:lla näkee myös matkakohaisen sähkön kulutuksen ja ladatun sähkön määrän/lataus. Joskus PSACC yhdistää usempia matkoja yhdeksi matkaksi. Kartta näkymään en ole saanut toimimaan, mutta muuten OK.
Virittelin tuohon myös pörssisähköohjauksen (spot-hinta.fi), mikä asetaa etukäteen autolle halvimman latausajan. Latausajan pituus ja aloitusaika riipuu aina siitä paljonko autossa on latausta jäljellä. HA:lla on tieto auton jäljellä olevasta latauksesta.
Ohessa HA:n näkymä ohjaukseen, matkojen tiedot ja latauksien tiedot.

Voin kertoa lisää, jos joku tuota alkaa virittelemään.
 

Liitteet

  • psacc.jpg
    psacc.jpg
    83,7 KB · Katsottu: 120
  • psacc_trips.jpg
    psacc_trips.jpg
    64,2 KB · Katsottu: 123
  • psacc_charge.jpg
    psacc_charge.jpg
    51,4 KB · Katsottu: 130

Harrastelija

Vakionaama
Joskus PSACC yhdistää usempia matkoja yhdeksi matkaksi
Omassani (eri merkki) taitaa olla että kun pysähdys on yli 4h niin tulkitaan eri matkaksi.
Ajatus ilmeisesti että jos pysähtyy tankkaamaan, ruokatauolle, tupakille tms niin ei heti ”nollata” matkaa vaan tulkitaan että kyseessä on yksi pidempi matka.
 

Ilpo55

Jäsen
Tein vanhasta Raspberry Pi:stä realiaikaisen kWh-mittarin, joka lähettää tiedot HA:lle.
Raspi lukee fototransistorilla kWh-mittarin vilkkulediä.
Tuolla on helppo katsoa esim. kuinka kauan LVV lämpiää ja säätää ajoitus kohdalleen halvoille tunneille.

Kuvassa kehitysversio, mihin olen lisännyt näytön (kulutus nyt ja pörssihinta), sekä painonapin millä voi valita näyttöön ed. tunnin kulutuksen ja kuluvan vuorokauden kulutuksen. Näyttöä ja nappia ei HA:ta varten tarvita.

Voin kertoa lisää (raspin python-koodi ym.) , jos joku tuota alkaa virittelemään.
 

Liitteet

  • rasp_kWh.jpg
    rasp_kWh.jpg
    82,1 KB · Katsottu: 126
  • HA_kWh.jpg
    HA_kWh.jpg
    24,5 KB · Katsottu: 123

kurre orava

´niin pienen hetken rakkaus on lumivalkoinen...´
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"]];
      });
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.
 

Ilpo55

Jäsen
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.
Hyvä kysymys. En ole käyttänyt tuota automaatioon, kun minulla on suorasähkölämmitys ja ILP.

Tai no olen käyttänyt sitä Adidas-automaatioon. Katson illalla miten lämpötila kehityy. Jos näyttää tarpeelliselta niin olen laittanut "Adidakset" jalkaan ja käynyt kytkemässä rivitalotaloyhtiön rännilämmitykset päälle. Esim. tänä iltana en laita päälle, koska yöllä ei juurikaan mene pakkasella ja huomenna on kuitenkin 10 ast. lämmintä ja mahdollisesti jäätynyt vesi sulaa.

Mukavaa, että koodeista on sinulle hyötyä.
 

kurre orava

´niin pienen hetken rakkaus on lumivalkoinen...´
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.
 

Joksa

Aktiivinen jäsen
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.
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.
 

Sukke

Aktiivinen jäsen
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.

Jotain tuon suuntaista talven pimeinä tunteina väkersin Home Assistantin ja Node Redin kanssa. Kaikki ohjattavat laitteet olisi jo käytössä, mutta pörssisähkö ja aika lopullisen ohjauksen tekoon puuttuu.

Tuosta alla olevasta lainauksesta löytyy jotain tietoja. Valitettavasti oma osaaminen ei riitä sille tasolle, että näitä voisi julkaista.

Sisälämpötila pitäisi vielä jotenkin ottaa huomioon.

Tuntitarve arvioitu sen perusteella, että minimitunneilla lämmityslaitteen teho riittäisi kattamaan tarkastelujakson lämmöntarpeen.

Luultavasti teen tuosta jonkun kehitysversion ensi talvea varten, kun pörssisähkö saattaa olla itsellänikin silloin edessä.

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
 

Mikki

Hyperaktiivi
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.
 

Sukke

Aktiivinen jäsen
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.

Tässä olisi hyvä saada käyttöön tiedot ja tunnit niin pitkälle kuin mahdollista eli ettei tarkastelu olisi vuorokausikohtainen. Tosin silloinkin pitäisi ratkaista jotenkin se, ettei tule liian pitkiä taukoja lämmitykseen tai käyttöveteen - siihenkin taisi joku ratkaisu olla.

Täytyy miettiä itsekin tuota vähän simppelimmin. Ehkä yritän tehdä Node Rediin jonkun paikallisen "rajapinnan" hieman vastaavasti. Periaatteessa nyt olisi itsellä mahdollista ohjata maalämpöpumppua eli lämmitystä ja käyttövettä, IV-konetta ja sähköauton latausta.

Tai en tiedä onko tuossa isoa eroa onko tarkastelu vuorokausikohtainen vai ei. Lähinnä tilanteet, joissa käynnissä olevan vuorokauden "kalliit" tunnit onkin "edullisia" verrattuna seuraavaan vuorokauteen.
 

Mikki

Hyperaktiivi
Ei ole menneenä talvena kuulunut valituksia tuosta vuorokausikohtaisesta ohjauksesta. Nimittäin kyllä se lämmitystarve sen verran pitkä keskimäärin taloissa pakkasilla on, että automaattisesti ei tule liian pitkiä taukoja.

Suurimmat hyödyt saa kyllä kun karsii vain sitkeästi niitä kalleimpia tunteja pois maksimaalisen määrän vuorokaudesta. Yrittämällä optimoida tuosta vielä pidemmälle, todennäköisesti moninkertaistaa monimutkaisuuden ja lopputulosta parantanee aika marginaalisesti.

Tuossa "reaaliaikaisessa" ohjauksessa joka katsoo 24h eteenpäin lämpötilaennustetta on se etu, että se kokoajan mukauttaa "rank" arvoa kun mennään eteenpäin. Jos lämpötilat nousevat 24h aikana, rank pienenee ja jos kylmenee niin rank suurenee.
 

Mikki

Hyperaktiivi
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.
 

Koelli

Aktiivinen jäsen
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.
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ä.
 

Mikki

Hyperaktiivi
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ä.
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.
 

Koelli

Aktiivinen jäsen
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.
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.
 

Joksa

Aktiivinen jäsen
Niin, itsellä se on ollut asennettuna HACS: puolelta, mutta huomasin Nordpoolin integraatioiden puolelta. Virallisuudesta en tiedä, kaikki taitaa olla laitonta tai vähintään kiellettyä nykyisin. Entso on toinen mikä on itsellä käytössä, mutta vähemmällä.
 

Liitteet

  • nodrpool.PNG
    nodrpool.PNG
    32,4 KB · Katsottu: 122

Joksa

Aktiivinen jäsen
Niimpä tietenkin sekoilin, kun tuli dialogi josta voi määrittää asetukset (aikaisemmin piti kirjoitaa...)
Asiasta toiseen onko kukaan muu törmännyt 1-wire lämpötila-antureiden lukuongelmiin. Anturit saattavat randomisti lopettaa toimintansa tai toimia viikkoja ihan kunnolla. Johdossa (MHS1x4x0,5) n.20m on 15 lämpötila-anturia, saatu varmimmin toimimaan ylösvetovastuksen muutoksella 4,7k->3k ja lisäämällä konkka (tällä hetkellä 4700uF) tasaamaan jännitettä johdon päähän. Raspi 4, jännite 3.3V antureille.
 

tk-

Aktiivinen jäsen
Olen tuossa toisessa ketjussa ”markkinoinut” Pörssäriä otsikossa Shellyn ja keskustelun puolella micropython-sovellutuksen kanssa. Mutta aloin pohtia tätä omaa systeemiä, missä vanha ja luotettava talologger edelleen logittaa Nibeä, että saisiko helpoiten Home Assistantin kautta nuo komponentit toisiinsa yhdistettyä.

Eli pohjalla olisi json (esimerkki perässä neljällä ohjauskanavalla kanavien osalta, olen tuosta alun jättänyt pois ja siksi rakenne on virheellinen), joka tulee tuolta serveriltä ja siellä jokaiselle tunnille (key) annetaan arvo 0 tai 1 sen mukaan onko ohjattava laite päällä vai pois. Visio olisi, että tekisin tuonne sensorin jokaiselle kanavalle, joka ehdollisesti saa arvon on tai off tuon edellämainitun jsonin perusteella.

JSON:
"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.

Seuraava askel olisi rakentaa sitten asetusrajapinta siten, että Home Assistantin kautta pääsisi myös muuttamaan nuo ohjausparametrit. Näin ollen pelkkä logiikka jäisi enää tuonne ”pilveen”.
 
Viimeksi muokattu:

Sukke

Aktiivinen jäsen
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.

En osaa ottaa kantaa, miten paikallinen tallentaminen oikeasti kannattaa tehdä. Käytän itse Home Assistantia yhdessä Node Redin kanssa. Käytännössä niin, että kaikki datojen tarkastelut, pyörittelyt ja ohjauksen logiikat teen Node Redin puolella. Käytän omassa asennuksessa tietojen välittämiseen ja tallentamiseen aika paljon MQTT:ta eli tallennan Node Redistä lähteävät JSON-muotoiset tiedot myös MQTT:n topiciin. MQTT tuo yhden lisäosan ja muuttujan asennukseen eli ei välttämättä paras ratkaisu, mutta toimiva tuokin.
 

Ilpo55

Jäsen
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?
Tallentamispaikkaa ei tarvitse murehtia, se on jossain HA:n tietokannassa.
Koko json on yksittäisessä sensorissa, mistä sen voi sitten purkaa uusiksi sensoreiksi (kanaviksi).

Olisiko ao. esimierkistä apua:

(Yo. lainauksen teksti "Joo ei..." on ko. sivun ekan postauksen teksti, ei siis sen minun postauksen teksti. Linkki aukeaa kyllä oikeaan postaukseen.)

Siinä haetaan ensin json sensoriksi "SHF temperature 70700" mistä sitten tehdään 1. arvosta sensori "SHF temperature 70700 now"
 
Viimeksi muokattu:
  • Tykkää
Reactions: tk-

s282

Jäsen
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
 

Ilpo55

Jäsen
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

Kulutus [Wh] = pulssit minutissa * 0.5 * 60 (Eikös se ole noin, kun yksi pulssi vastaa 0.5 Wh?)

Oletko kokeillut tehdä Integration Helpperin?
 

Liitteet

  • Sum integral.jpg
    Sum integral.jpg
    18,7 KB · Katsottu: 107
Viimeksi muokattu:

s282

Jäsen
Kulutus [Wh] = pulssit minutissa * 0.5 * 60 (Eikös se ole noin, kun yksi pulssi vastaa 0.5 Wh?)

Oletko kokeillut tehdä Integration Helpperin?
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?

EDIT: Siis 0.5 pulssia vastaa 1Wh
 
Viimeksi muokattu:

Ilpo55

Jäsen
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?
No ihan väärin laskin. Siis yksi pulssi vastaa 2 Wh kulutusta.
Jos minutissa tulee 10 pulssia tarkoittaa se 20 Wmin. Jos tuo halutaan Wh pitää kertoa 60 (= minuttien määrä tunnissa). 20 * 60 = 1200 Wh

Template sensori YAML:lla voi hoitaa kerttolaskut. Katson löydänkö valmista esimerkkiä.
 

s282

Jäsen
Siis pulssimittari antaa valmiiksi Wh ei W, ei kai sitä enään tarvitse kertoa? Jos otetaan tuo esimerkkisi, ja se tulee koko tunnin ajan 10 pulssia minuutissa ja joka minuutin pulssit kertoisi 60 niin tuloshan olisi 20 *60 * 60 =72kWh
 

Ilpo55

Jäsen
Ei, kun pitää kertoa vain kerran 60, jotta saadaan arvio tunnin kulutuksesta [Wh = Watin tehoa tunnin ajan] ed. min. perusteella.

Jos taas haluat todellisen tunnin kulutuksen on nuo kaikki pulssit laskettava yhteen ed. tunnin ajalta ja kerrottava 2:lla.
Vastaavasti vuorokauden ajalta kaikki vuorokauden pulssit yhteen.

Ohessa minun kulutusmittauksen näkymä.
Hetkellinen kulutus on W (laskettu ed. min perusteella) ja tunnin kulutus Wh (lasketaan jatkuvasti ed. 60 min perusteella).
Laskenta ja pulssien mittaus suoritetaan Raspbery Pillä, mikä lähettää tiedot valmiinna HA:lle.
 

Liitteet

  • kulutus.jpg
    kulutus.jpg
    19,5 KB · Katsottu: 90

Ilpo55

Jäsen
Onko sinulla pulssitieto ed. minuutin pulssit vai pulssien summa jostain lähtien?
Minun ajatus perustui siihen, että minuutin välein saadaan vain ed. minuutin aikana kertyneet pulssit.
 

s282

Jäsen
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
 

Ilpo55

Jäsen
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
Mikä sinulla on sen pulssisensorin nimi ja mitä se nyt näyttää Developer Tools / States kohdassa?
Ohessa esim. minun kWh Day sensori.

HA:n Energy Dashboard osaa huolehtia kulutuksen näytöstä (tunti, päivä, kuukausi ja vuosi) sitten, kun sopiva sensori on käytettävissä.
 

Liitteet

  • kwh_day.jpg
    kwh_day.jpg
    51,6 KB · Katsottu: 112
Back
Ylös Bottom