HomeAssistant ja sähköpörssiohjaus

villho

Tulokas
Okei. Saahan tästä toki monimutkaisenkin jos haluaa harrastaa.
Juuri tuo.

Tällä hetkellä meillä ei itse asiassa ole mitään insentiiviä optimoida latausta sähkönhinnan kannalta muuten kuin, että pitää huolen latauksen osumisesta halvemmalle yösähkölle 22-7 välille (meillä päiväsähkö ~15 cent/kWh ja yösähkö ~10 cent/kWh veroineen ja siirtokuluineen). Jos haluaa viedä homman pidemmälle, niin sallii latauksen tuona aikana, mutta autosta säätää latausrajan ja halutun lähtöajan, jolloin auto hoitaa latauksen aloittamisen oikeaan aikaan, minkä seurauksena akku ja kabiini ovat lähtöhetkellä lämpimät. Tätä enempää ei sinänsä tällä hetkellä voi optimoida. Mutta sitten tullaankin siihen harrastamiseen....

P.S: Se vielä sivumainintana, että sähköauton akkua ei pidä täytenä säilyttää ja koska kyseessä eivät meillä ole hälläväliä-liisariautot, minkä akkujen kunnolla ei ole mitään merkitystä, niin akun mahdollisimman hyvän kunnon säilyttämiseksi on kummassakin autossa normaalikäytössä latausraja säädetty 60 %:iin. Tuota sitten säädetään sen mukaan, kun on seuraavalle päivälle ajotarvetta tiedossa. Hybrideissä tilanne on hieman eri, koska akun yläpäässä on enemmän bufferia, joten sillä ei ole aivan niin suurta merkitystä, jos akku näyttääkin 100 %. Lisäksi hybrideissä on usein tarve mahdollisimman täydelle akulle lähtiessä, koska ajomatka sähköllä on usein rajoittava tekijä. Sähköautoissa (mikäli auto/akun koko on omaan ajoprofiiliin oikein valittu) 100 % akulle ei ole tarvetta kuin harvoin.
 

anssi99

Tulokas
miten haluat nuo "halvat tunnit" määrittää
Käytän siis lämmityksen aloitukseen triggerinä "SHF Cheapest period hours start" ja nyt en tiedä miten lopettaisin lämmityksen kun "SHF Cheapest period hours" määräämä aika on kulunut. Tarkoitus siis varata lattiaan ylilämpöä ja lämmittää vesivaraaja halvimpien tuntien aikana ja muuna aikana ylläpitää lattiassa pienempää lämpötilaa.
 

Sukke

Aktiivinen jäsen
Juuri tuo.

Tällä hetkellä meillä ei itse asiassa ole mitään insentiiviä optimoida latausta sähkönhinnan kannalta muuten kuin, että pitää huolen latauksen osumisesta halvemmalle yösähkölle 22-7 välille (meillä päiväsähkö ~15 cent/kWh ja yösähkö ~10 cent/kWh veroineen ja siirtokuluineen). Jos haluaa viedä homman pidemmälle, niin sallii latauksen tuona aikana, mutta autosta säätää latausrajan ja halutun lähtöajan, jolloin auto hoitaa latauksen aloittamisen oikeaan aikaan, minkä seurauksena akku ja kabiini ovat lähtöhetkellä lämpimät. Tätä enempää ei sinänsä tällä hetkellä voi optimoida. Mutta sitten tullaankin siihen harrastamiseen....

P.S: Se vielä sivumainintana, että sähköauton akkua ei pidä täytenä säilyttää ja koska kyseessä eivät meillä ole hälläväliä-liisariautot, minkä akkujen kunnolla ei ole mitään merkitystä, niin akun mahdollisimman hyvän kunnon säilyttämiseksi on kummassakin autossa normaalikäytössä latausraja säädetty 60 %:iin. Tuota sitten säädetään sen mukaan, kun on seuraavalle päivälle ajotarvetta tiedossa. Hybrideissä tilanne on hieman eri, koska akun yläpäässä on enemmän bufferia, joten sillä ei ole aivan niin suurta merkitystä, jos akku näyttääkin 100 %. Lisäksi hybrideissä on usein tarve mahdollisimman täydelle akulle lähtiessä, koska ajomatka sähköllä on usein rajoittava tekijä. Sähköautoissa (mikäli auto/akun koko on omaan ajoprofiiliin oikein valittu) 100 % akulle ei ole tarvetta kuin harvoin.

Jossain välissä olisi tarkoitus tehdä sähköauton lataukselle ohjausta halvimmille tunneille. Tulossa tosin yksivaihelataukseen kykenevä malli ja maksimitehoksi jää 3,6 kW eli latausaika voi ajoittain tulla optimoinnin esteeksi. Samoja periaatteita lämmityksen kanssa on ja ainakin osittain voin tuota omaa räpellystä hyödyntää, toivottavasti.

Laturi on jo ja alkeellinen kuormanhallinta myös. Oikea virtamittaus tosin vielä uupuu, mutta satunnaisen virran kanssa laturin ohjaus jo toimii. Autokin uupuu vielä, mutta talven aikana pitäisi olla toiminnassa.

Saako autosta tilatietoa eli esim. varaustilaa HA:han. Tänne on tulossa Leaf ja sille näyttäisi integraatio pilven kautta olevan. Onko tuo yleinen ominaisuus? Ei tarvitsisi syöttää manuaalisesti arpoa latausaikaa tai -tehoja, kun määrittää vaan tavoitetilan varaukselle.
 

ankl

Jäsen
Käytän siis lämmityksen aloitukseen triggerinä "SHF Cheapest period hours start" ja nyt en tiedä miten lopettaisin lämmityksen kun "SHF Cheapest period hours" määräämä aika on kulunut. Tarkoitus siis varata lattiaan ylilämpöä ja lämmittää vesivaraaja halvimpien tuntien aikana ja muuna aikana ylläpitää lattiassa pienempää lämpötilaa.
Itse (koitan) minimoida sähkön kulutusta kalliina tunteina käyttämällä SHF Control factoria säätämään VILP (Pansu) lattialämmityksen offsettia. Ajatuksena siis että halpoina tunteina ladataan laattaan lämpöä ja kun siirrytään kalliimmille tunneille niin tavoitelämpöä (offset) lasketaan ja pumpun ei tarvitse tehdä (niin paljon) töitä tavoitelämmön saavuttamiseksi. Lattialämpöä en siis pyri ohjaamaan ON/OFF tyyppisesti.

Käyttöveden tuoton taas teen (koitan tehdä) niin että lataan VILP varaajan (force DWH mode) kun vuorokauden halvin tunti alkaa (SHF Cheapest period hours start). Lataukseen (pari sataa litraa) menee tyypillisesti puolisen tuntia ja kun lämminvesivaraajan tavoitelämpö saavutetaan niin pumppu osaa itsekseen lopettaa käyttöveden lämmityksen. Varaaja sitten pitää lämpönsä 12h-24h riippuen kuinka ahkerasti suihkua käytetään.

Saas nähdä kuinka luotettavasti automatisointi onnistuu, kuinka paljon euroja säästyy ja kuinka paljon sivuvaikutuksia (esim huonelämmön vaihtelu) tapahtuu.
 

Temez

Aktiivinen jäsen
Käytän siis lämmityksen aloitukseen triggerinä "SHF Cheapest period hours start" ja nyt en tiedä miten lopettaisin lämmityksen kun "SHF Cheapest period hours" määräämä aika on kulunut. Tarkoitus siis varata lattiaan ylilämpöä ja lämmittää vesivaraaja halvimpien tuntien aikana ja muuna aikana ylläpitää lattiassa pienempää lämpötilaa.
Helpointa on tehdä niin, että yksi automaatio, jossa triggerinä tuo aiempi ehto (ja se sinulla ilmeisesti on jo hanskassa). Sitten siihen samaan automaatioon seuraavaksi stepiksi viive x tuntia (taisi olla nimellä "Wait until time has passed" tai lotain, en muista tarkkaan) , jonka jälkeen sitten sen varauksen poiskytkentä.

Delayn saa sellaiseksi myös, että viive olisi dynaamisesti sen käyttöliittymän puolella olevan "SHF Cheapest period hours" verran, mutta ehkä helpointa kokeilla tätä ensin staattisella x tuntia suoraan automaatiossa?
 

heebo1974

Aktiivinen jäsen
Itse en oikein osannut myöskään käyttää tuota "SHF cheapest period hours":ia.
Paljon helpommin onnistui Rankeillä ja hinnoilla. :)

Eli esim näin:

YAML:
alias: LVV ohjaus pörssisähkön mukaan
description: ""
trigger:
  - platform: state
    entity_id:
      - sensor.shf_rank_now
condition: []
action:
  - delay:
      hours: 0
      minutes: 0
      seconds: 5
      milliseconds: 0
  - choose:
      - conditions:
          - condition: state
            entity_id: binary_sensor.shf_rank_acceptable
            state: "on"
        sequence:
          - service: switch.turn_on
            data: {}
            target:
              device_id: fb29b232e383c3a990c44aa5070ebfda
      - conditions:
          - condition: and
            conditions:
              - condition: state
                entity_id: binary_sensor.shf_rank_acceptable
                state: "off"
              - condition: numeric_state
                entity_id: sensor.shf_electricity_price_now
                below: 0.035
            enabled: true
        sequence:
          - service: switch.turn_on
            data: {}
            target:
              device_id: fb29b232e383c3a990c44aa5070ebfda
            enabled: true
      - conditions:
          - condition: and
            conditions:
              - condition: state
                entity_id: binary_sensor.shf_rank_acceptable
                state: "off"
              - condition: numeric_state
                entity_id: sensor.shf_electricity_price_now
                above: 0.035
        sequence:
          - service: switch.turn_off
            data: {}
            target:
              device_id: fb29b232e383c3a990c44aa5070ebfda
mode: single

Tuolla saa yhdellä automaatiolla lämminvesivaraajan päälle tai pois rankkien mukaan ja lisäksi vielä erityisen halvan pörssisähkön ollessa kyseessä on LVV myös päällä.

Lattialämmitysten kanssa vähän samanlainen lähestymistapa, mutta on/offin sijaan käytetään eri lämpötiloja.

YAML:
alias: Lattialämmityksen (ET,KHH) ohjaus pörssisähkön mukaan.
description: ""
trigger:
  - platform: state
    entity_id:
      - sensor.shf_rank_now
    enabled: true
    for:
      hours: 0
      minutes: 0
      seconds: 0
condition: []
action:
  - delay:
      hours: 0
      minutes: 0
      seconds: 5
      milliseconds: 0
  - choose:
      - conditions:
          - condition: and
            conditions:
              - condition: state
                entity_id: binary_sensor.shf_price_acceptable
                state: "on"
              - condition: numeric_state
                entity_id: sensor.shf_electricity_price_now
                below: 0.035
        sequence:
          - service: climate.set_temperature
            data:
              temperature: >-
                {{ (20 + 3*states('sensor.shf_control_factor_0_1') | float) |
                round(0) }}
            target:
              device_id:
                - 02cbfabf43024013bb64eab9d0130f59
                - 0cfb62d912278dd07d5323429896a272
            enabled: true
      - conditions:
          - condition: and
            conditions:
              - condition: state
                entity_id: binary_sensor.shf_price_acceptable
                state: "on"
              - condition: numeric_state
                entity_id: sensor.shf_electricity_price_now
                above: 0.035
        sequence:
          - service: climate.set_temperature
            data:
              temperature: >-
                {{ (19 + 3*states('sensor.shf_control_factor_0_1') | float) |
                round(0) }}
            target:
              device_id:
                - 02cbfabf43024013bb64eab9d0130f59
                - 0cfb62d912278dd07d5323429896a272
            enabled: true
      - conditions:
          - condition: state
            entity_id: binary_sensor.shf_price_acceptable
            state: "off"
            enabled: true
        sequence:
          - service: climate.set_temperature
            data:
              temperature: >-
                {{ (18 + 3*states('sensor.shf_control_factor_0_1') | float) |
                round(0) }}
            target:
              device_id:
                - 02cbfabf43024013bb64eab9d0130f59
                - 0cfb62d912278dd07d5323429896a272
            enabled: true
mode: single

Joku voisi tosin lämmittää enemmän lattioita kun sähkö on kallista perustuen siihen, että silloin on todennäköisesti kylmää.
Täällä on menty vain säästö edellä, ei mukavuus. :D
 
Viimeksi muokattu:

anssi99

Tulokas
Delayn saa sellaiseksi myös, että viive olisi dynaamisesti sen käyttöliittymän puolella olevan "SHF Cheapest period hours" verran, mutta ehkä helpointa kokeilla tätä ensin staattisella x tuntia suoraan automaatiossa?
Onnistumisen iloa:). Sain toimimaan ao. ajastimella. Kun se siirtyy lepotilaan voin vaihtaa ylläpitolämpötilaan.
action:
- service: timer.start
data:
duration: '{{states(''input_number.shf_cheapest_period_slider'')|int *60*60}}'
target:
entity_id: timer.halvat_tunnit_ajastin
 

marpelto

Jäsen
Miten arvon raati on integroinut sähkönkulutuksen HA:n?
Itselläni on Energomonitor(https://www.energomonitor.com) ja APIn kautta saan saman kulutuksen myös HAhan.. ongelmana on API key on vaimassa vain 30 pv. Tämä on vähän hankalaa...joten löytyykö parempi konsti?
Voinko käyttää HAn GPIO nastaa ja ajaa Optiselta anturilta pulssidataa suoraan IO nastaan?
 

marpelto

Jäsen
Taisinkin jo löytää...

binary_sensor:
- platform: rpi_gpio
sensors:
- port: 18
name: "xxxx"
unique_id: "yyyy"
bouncetime: 80
pull_mode: "DOWN"
 

marpelto

Jäsen
Mulla on tällä hetkellä EVlle, MLPlle omat 3-vaihe mittarit joissa led pulssinäyttö ja siitä Energomonitorin pulssilaskuri (optosense). Ja tietysti päämittarilla omansa joka seuraa kokonaiskulutusta. Eli APIn kautta saan samat tiedot HAlle. Voisi tietysti tutkia saisiko APIn salasanaa vaihdettua automaattisesti 30pvn välein jollain scriptillä...sehän olisi paras vaihtoehto.
Mutta pitääpä tutkia ESPHome vaihtoehtoa, mulla kun lojuu laatikoissa varmaan tusina ESP32ia
 

Temez

Aktiivinen jäsen
Noniin, taas jonkinasteisesti edes sorvin ääressä. Marginaaleista ja siirtohinnoista ei kuulunut ongelmia, joten ymppäsin ne nyt main-haaraan: https://github.com/T3m3z/spotprices2ha

Katsotaan sitten seuraavaksi datanlatauksen haasteita ja aiemmin puhuttua ongelmaa "cheapest period" -osuuden kanssa.
 

heebo1974

Aktiivinen jäsen
Mietin tässä, että esim. huomiselle (04.01.) halvimmat tunnnit osuu vasta iltaan, niin voisiko tuota mikkin uutta "priorityHours" systeemiä ympätä tähän lisäosaan mukaan ? Juurikin LVV lämmitykseen tuo olisi kätevä. Toki manuaalisesti voi heittää vähän enemmän sallittuja ränkkejä huomiselle, mutta miksei automaatiollakin hoituisi tulevaisuudessa. :)
 

Mikki

Hyperaktiivi
Mietin tässä, että esim. huomiselle (04.01.) halvimmat tunnnit osuu vasta iltaan, niin voisiko tuota mikkin uutta "priorityHours" systeemiä ympätä tähän lisäosaan mukaan ? Juurikin LVV lämmitykseen tuo olisi kätevä. Toki manuaalisesti voi heittää vähän enemmän sallittuja ränkkejä huomiselle, mutta miksei automaatiollakin hoituisi tulevaisuudessa. :)

Taitaisi mennä yksinkertaisesti niin, että vaihdat yamliin URLksi tämän:

Tuolla saat rankit 1-8 osumaan yötunneille. Ja sitten jos Rankilla ohjaat vaikka kolme tuntia, niin osuu varmasti yöajan kolmelle halvimmalle tunnille.
 

Temez

Aktiivinen jäsen
Tapahtuiko jouluaattona jotain erityistä, kun täällä kolmen eri HA instanssin pörssisähköohjaus meni jumiin? Kaikissa tässä threadissa mainittu lisäosa. Kaikki tokeni rebootilla, mutta siihen asti kaikki olivat jääneet jumiin "kalliin pörssisähkön tilaan". Graafi oli tyhjä ja pörssiohjauksen sensorit sanoivat "unavailable". Yksi HA instansseista oli jumissa vielä joulupäivänä kunnes viimein pääsin reboottaamaan sen.
Noniin. Tähän ongelmaan vähän fiksiä. Huomasin, että datanlatauksen epäonnistuessa katoaa sensoreista kaikki sisältö. Korjattu ongelmaa pistämällä data talteen ja säilömällä sitä kunnes uutta saatavilla. Lisäksi toipumista ongelmatapauksista paikattu. Saatavilla versio 0.1.7: https://github.com/T3m3z/spotprices2ha
 

Temez

Aktiivinen jäsen
Pää vähän jumissa
Minulla on tuo SHF-paketti asennettuna ja saanen sillä toteutettua haluamani, mutta havaitsin yhden outouden (bugi?) tänään. SHF haki uudet hinnat seuraavalle vuorokaudelle ja tämä triggeröi omassa setupissani laskennan tarvittaville lämmitystunneille seuraavaksi vuorokaudeksi (syötteenä lämpötilaennuste ja tämän taakse portaittain määrätty lämmitystuntien määrä).
Tähän liittyen olen nyt vähän ajatukset jumissa. Olisi helppoa laittaa, että anna vuorokauden halvin x tuntia, mutta tuo kyseinen tuntipätkä voisi oikeasti olla järkevää sijoittaa joskus vuorokauden vaihtumisen kohtaan. Onko mielestänne liian rajatapaus vai pitäisikö tuo ottaa huomioon? Yksi ongelma on se, että jos laskenta tapahtuu esim. HA:n käynnistyessä, niin erilaiset konffimuutokset voisivat saada aikaan useita "SHF Cheapest periodeja" putkeen.

Vai olisiko järkevää, että halvin hetki napattaisiin aina ~kello 14 uuden datan tullessa seuraavan 24h ajalle? Silloin yleisimmin halvimmat yölle sijoittuvat tunnit saisi aina maksimikäyttöön vaikka ne ajoittuisivat kahdelle eri päivälle.
 
  • Tykkää
Reactions: BUK

Temez

Aktiivinen jäsen
Noniin. Tähän ongelmaan vähän fiksiä. Huomasin, että datanlatauksen epäonnistuessa katoaa sensoreista kaikki sisältö. Korjattu ongelmaa pistämällä data talteen ja säilömällä sitä kunnes uutta saatavilla. Lisäksi toipumista ongelmatapauksista paikattu. Saatavilla versio 0.1.7: https://github.com/T3m3z/spotprices2ha
Tässä myös muutettu datanlatauslogiikkaa niin, että jos ei ole saatu ladattua esim. nettiyhteyden rikon takia TAI ladattu data on sykkyrässä (ainakin se joulun paikkeilla tapahtunut ongelmatapaus pitäisi jäädä haaviin) TAI dataa ei ole kello 14 jälkeen huomiselle vielä tiedossa --> koeta 15min välein käynnistää lataus. Latauksessa 60-600s hajautus. Jos kaikki menee hyvin, niin pitäisi siis tulla data kohdalleen 14:01-14:10 tai sitten seuraavassa latauksessa 14:16-14:25 välisenä aikana eli vähän aikaisemmin kuin aiemmin. Mutta ei kuitenkaan hirveästi hakuja lisää.
 

Sukke

Aktiivinen jäsen
Omassa räpellyksessä on lähinnä odoteltu odottamattomia bugeja ja tehty pieniä viilauksia. Tarkastelu on nyt tunneittain tiedossa tuntihintojen loppuun saakka, mutta historiaa otetaan mukaan, jos tuntihintoja on jäljellä alle 24 (tarkastelujakson pituus minimissään 24 h). Alla muutama kuva tältä päivältä ennen ja jälkeen uusien tuntihintojen. Kuvat taas jostain syystä hieman suttuisia, vaikka ennen lähetystä näyttää terävältä.

Tuntivalinta näyttäisi suurin piirtein toimivan, vaikka en aina tiedä miksi tai miksi ei. Tässä käytetään hyväksi muita HA:n tietoja, jotka päivittyvät aina tunnin alussa ja siitä on pientä murhetta tämän osalta, kun tiedot voi tarkastelutunnin alussa olla "vanhentuneita". Täytyy ehkä muutella jotain tai paljonkin lopulliseen versioon. Tästähän puuttuu edelleen laitteen ohjaus kokonaisuudessaan, mutta ei ole vielä laitettakaan... Antaa tämän nyt ruksuttaa niin tulee virheitä esiin ja on jotain, jonka pohjalta tehdä jatkokehitystä (ja harrastaa...).

Lila toteuma osoittaa lämmitystunteja ja sinertävät palkit käynnissä olevaa / tulevia lämmitystunteja. Tarkastelu on tiedossa olevien tuntihintojen loppuun. Lämpötilaennusteen perusteella arvioitu sallittujen tuntien määrä on 9,9 h/vrk. Koska koko yö on yhtenäisesti sallittuja tunteja on tuntimäärä täyttynyt. Jäljellä olevat palkit (arvona 2) kuvaa tuntihinnan perusteella (alle 15 c/kWh) mukana olevia tunteja. Jos halpoja tunteja ei olisi, ei palkkeja olisi lainkaan näkyvissä.

Jakson sallittujen tuntien keskihinnassa on ollut hieman häikkää, sen taisin tämän kuvan jälkeen korjailla (mukana oli vain tulevat pakolliset lämmitystunnit, ei lainkaan menneitä).
katso liitettä 83399

Uudet tuntihinnat saapuneet. Jakson ennustettu lämpötila pienentynyt ja tuntitarve / vrk vähentynyt. Jokin tieto ei ollut HA:ssa vielä uusien tuntihintojen jälkeen päivittynyt, joten tuntitarve on vielä nollissa. Tiedot tässä siis sikäli virheelliset. Pitäisi selvittää, mikä tieto viivästyttää päivittymistä. Nyt tasatunti + 5 minuuttia päivitys on osittain vanhoilla tiedoilla ja aiheuttaa itselleni hieman päänvaivaa. Sallitut tunnit (palkit arvoihin 2 ja 3,5) tulee tuntihintojen ei arvioidun lämmitystarpeen perusteella.
katso liitettä 83400

Lämmitystarve ja "suunnitelma" päivittynyt. Tuon suunnitelman perusteella ei ohjausta varsinaisesti tehdä kuin kuluvan tunnin osalta, loppu on vain visualisointia varten. Jokaisen tunnin kohdalla ohjaus ajetaan uudelleen päivitetyillä tiedoilla. Apexcharts-cardin extremas ei jostain syystä toimi.
katso liitettä 83401

Tässä näkyy pieni omituisuus, kun kalliiden tuntien aikana ei ole lämmitystä, mutta tuntitarve kuitenkin pikkuhiljaa pienenee (kaksi ensimmäistä palkkia muuttuneet "vapaaehtoisiksi" lämmitystunneiksi eli ovat mukana hinnan vuoksi). Tavallaan nykyinen tarkastelu unohtaa menneen lämmityksen, kunnes tuntihintoja on taas alle 24 jäljellä. Ehkä se historia pitäisi pitää mukana vähintään -12 h verran. Toisaalta ei ennen uusiakaan lähtötietoja ollut pakollisia lämmitystunteja luvassa jäljellä olevien tuntihintojen aikana (ensimmäinen kuva) - palkit olivat vain halpojen tuntien vuoksi mukana.

Tästä myös nähtävissä, että seuraavaan iltaa olisi pitkä tauko odotettavissa, jos kolmea halvan hinnan (alle 15 c/kWh) tunteja ei olisi mukana. Tuo sallittu katko ja 8 h iskee siinä vaiheessa, kun 8 h tauko uhkaa tulla vastaan.
katso liitettä 83402

Tässä vielä hahmotelmaa käyttäjän säätimistä.
katso liitettä 83403

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.
sallitut tunnit ja spot-hinta 2 – kopio.jpg


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.
lämmitys- ja sallitut tunnit 21 – kopio.jpg


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".
lämmityksen_säätöä 3 – kopio.jpg
 
Viimeksi muokattu:

-Teme-

Vakionaama
Miten arvon raati on integroinut sähkönkulutuksen HA:n?
Shelly 3em monitoroi kokonaiskäyttöä. Jokainen lattialämmitystermostaatti korvattu shelly1PM+temp addon kombolla (13kpl), sekä iso liuta energian mittauksella varustettuja pistotulppia eri kohteissa (9*shelly, 8*ESPhome)
Vielä pitäisi saada 9 vaihetta energian luvun piiriin, niihin plänännyt jotakin ESPhome pohjaista lukijaa
Suuri kiitos @Temez tuosta paketista. Olen jalostanut siitä useamman sensorin eri piirien ohjaukseen
 

-Teme-

Vakionaama
ai hitto tuo SHF Control Factor +-1 toimii kivasti lattialämmityksen lämmön säätelyyn.
Pesuhuoneen sähköinen lattialämmitys vie normisti n.15kWh/vrk, n.45kWh eli 33% kokonaiskulutuksesta
Nyt laitoin tuon SHF Control Factor +-1 säätelemään sen lämpöä. Kun SPOT ylittää vrk keskiarvon alkaa CF pudottamaan termarin lämpöä 26ºC alas aina 23ºC asti. Edelleen max rate on 18 eli ne kaikkein kalleimmat tunnit on lämmittämättä.
Kulutus pitäisi näillä säädöillä laskea vähän, mutta ehkä merkittävin on siirtää sitä edukkaammille tunneille
 

Liitteet

  • 1672922039614.png
    1672922039614.png
    39,4 KB · Katsottu: 180

Kake

Jäsen
Tapahtuuko muilla sitä, että tuo kalenteri jääkin jumiin edelliseen päivään ja sen vuoksi jää liipaisu puuttumaan? Mulla tapahtuu tätä ehkä kerran viikossa. Viime yönä nyt viimeksi.

1673080604771.png
 

villho

Tulokas
Vai olisiko järkevää, että halvin hetki napattaisiin aina ~kello 14 uuden datan tullessa seuraavan 24h ajalle? Silloin yleisimmin halvimmat yölle sijoittuvat tunnit saisi aina maksimikäyttöön vaikka ne ajoittuisivat kahdelle eri päivälle.
Tämä kävisi ainakin minulle hyvin. Tällöin riittäisi tieto siitä, että SHF:n ehdottama halvimman jakson ajankohdat sijoittuvat klo 15 -> klo 15 väliin. Lopun logiikan voisi rakentaa tuon tiedon päälle.
 

Temez

Aktiivinen jäsen
Tapahtuuko muilla sitä, että tuo kalenteri jääkin jumiin edelliseen päivään ja sen vuoksi jää liipaisu puuttumaan? Mulla tapahtuu tätä ehkä kerran viikossa. Viime yönä nyt viimeksi.
Ei ole itselle osunut vastaan, mutten ole tuota itse aktiivisesti seurannutkaan. Jos/kun seuraavan kerran tapahtuu, niin kurkkaappa, että mikä arvo on anturissa "SHF Cheapest period start helper". Se on nimittäin se, jossa kellonaika lasketaan ja siitä se kopioidaan tuohon input_datetime-tyyppiseen olioon nimeltä "SHF Cheapest period start", jota sitten voi käyttää automaatioissa. Saadaan sitten tietää, että onko laskennassa vai missä vika.

Sellainen bugi on tiedossa, että halvin aika voi olla menneisyydessä, jos kaikki tulevaisuuden hinnat ovat kalliimpia kuin vaikkapa 4h sitten ollut hinta. Tätä meinasin fiksata ehtiessäni niin, että otettaisiin aina kello 14-15 paikkeilla (kun seuraavan vuorokauden hinnat tulevat) halvin pätkä seuraavalta 24h ajalta. Yöt kun tuppaavat olemaan halvempia kuin päivät. Saa sitten ehkä mahdolliset edut alkuyön halvoista tunneista, jos sattuisi halvin 6h pätkä alkamaan esim. 22:00.
 

Sukke

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

Kohti seuraavaa vaihetta eli lämmityksen ohjausta otetaan pieniä askeleita.

Toteutin nyt seurannan sallittujen tuntien määrälle eli minkälainen tuntimäärä on keskimäärin jäänyt käteen, kun mahdolliset lisätunnit ja tulevien tuntien "suunnitelma" on otettu huomioon. Lisätuntejahan voi tulla, jos sallittujen tuntien määrittämisen jälkeen tuntihinnat on riittävän alhaisia, tuntihinta poikkeaa riittävän vähän sallittujen tuntien keskiarvosta (olisikohan mediaan parempi...) tai pitkä tauko on katkaistu ylimääräisellä tunnilla.

Pientä virhettä ollut ehkä laskennassa "kehitysvaiheessa" niin on muutamat piikit mukana. Tuntitarve h/jakso on jäljellä ja tiedossa olevien tuntihintojen ajalle laskettu tuntitarve. Tuo keskimääräinen tuntitarve lasketaan mediaanina menneiden 12 h aikana lasketuista tuntitarpeista eli kun tarkastelu on jatkuva, päivittyy tuo tarvekin tunneittain. Toteuma-arvio kiipesi tunneittain 24h/vrk tasolle, kun sähkön hinta tipahti alle 10 c/h. Tuntitarve on pysynyt myös aika vakiona niin on suoraa viivaa tarpeessa ja arvioidussa toteumassa.

Tämä voisi toimia sitten huonelämpötilan lisäksi yhtenä lähtötietona, kun lämmityksen pyyntiä ohjataan. Jos toteumaennuste näyttää sallittuille tunneille 24 h/vrk ei ohjausta kovasti tarvitse painottaa. Toinen ääripää on sitten tilanne, jossa sallitut tunnit tulee nipin napin täyteen ja huonelämpötilakin sakkaa. Teoriatasolla mennään edelleen, mutta harrastus jatkuu.

lämmityksen tuntitarve ja toteumaennuste – kopio.jpg
 

timop

Aktiivinen jäsen
olisiko pöljä ajatus tehdä topicci mihin laittaa näitä home assistant spot automaatio ideoita samaan nippuun ?
 

jämä67

Aktiivinen jäsen
Kiitokset @Temez lle mahtavasta paketista!
Aloittelijaltakin onnistui lisääminen kivuttomasti githubin kautta ohjeita noudattaen.
Pohjalla minulla ihan se perus HA OS raspberry pi4:lle asennettuna.

HACS lisäosan kautta löytyi vielä tuki GPIO niks naks ohjauksille, mutta ei DHT22 kosteusmittausta ja KWh mittarin pulssitululoa.
Niitä varten tilasin ESP kortin, niin pääsee tutustumaan ESPHome maailmaankin.

Aika lailla valmiiseen ruokapöytään on päässyt, mutta täytyy alkaa perehtymään tarkemmin, josko osaisi itsekkin jotain tehdä.
 

timop

Aktiivinen jäsen
meinasin pokkana lainata tätä mutta, ei tuo nyt lähde päälle. muutin hintaakin isommaksi ja nostin rankkausta. kun automaatiosta ajoin run niin sitten se kyllä lähti päälle. mistähän tätä lähtisi purkamaan ? tai miten usein tuo tarkistaa. tein myös muutoksen tuohon.
edit: jaa se kertooki tuo kuikka että sitten kun tuo rank muuttuu.

YAML:
- condition: numeric_state
  entity_id: sensor.shf_electricity_price_now
  below: 0.035
  |
  V
- condition: numeric_state
  entity_id: sensor.shf_electricity_price_now
  below: input_number.shf_price_slider


Itse en oikein osannut myöskään käyttää tuota "SHF cheapest period hours":ia.
Paljon helpommin onnistui Rankeillä ja hinnoilla. :)

Eli esim näin:

YAML:
alias: LVV ohjaus pörssisähkön mukaan
description: ""
trigger:
  - platform: state
    entity_id:
      - sensor.shf_rank_now
condition: []
action:
  - delay:
      hours: 0
      minutes: 0
      seconds: 5
      milliseconds: 0
  - choose:
      - conditions:
          - condition: state
            entity_id: binary_sensor.shf_rank_acceptable
            state: "on"
        sequence:
          - service: switch.turn_on
            data: {}
            target:
              device_id: fb29b232e383c3a990c44aa5070ebfda
      - conditions:
          - condition: and
            conditions:
              - condition: state
                entity_id: binary_sensor.shf_rank_acceptable
                state: "off"
              - condition: numeric_state
                entity_id: sensor.shf_electricity_price_now
                below: 0.035
            enabled: true
        sequence:
          - service: switch.turn_on
            data: {}
            target:
              device_id: fb29b232e383c3a990c44aa5070ebfda
            enabled: true
      - conditions:
          - condition: and
            conditions:
              - condition: state
                entity_id: binary_sensor.shf_rank_acceptable
                state: "off"
              - condition: numeric_state
                entity_id: sensor.shf_electricity_price_now
                above: 0.035
        sequence:
          - service: switch.turn_off
            data: {}
            target:
              device_id: fb29b232e383c3a990c44aa5070ebfda
mode: single

Tuolla saa yhdellä automaatiolla lämminvesivaraajan päälle tai pois rankkien mukaan ja lisäksi vielä erityisen halvan pörssisähkön ollessa kyseessä on LVV myös päällä.

:D

Edit: hyvin pelaa tämä automaatio tuolla input_number.shf_price_slider:lla. En keksi rankille käyttö joten pidän aika isolla.
Meillä ei vielä ole pörssisähköä, ja nyt tuon varaajan olen sammuttanu päiväksi sulakkeista niin seon sen 45min -1,5h päällä riippuen onko ollut saunapäivä.
 
Viimeksi muokattu:

Temez

Aktiivinen jäsen
Minulla on tuo SHF-paketti asennettuna ja saanen sillä toteutettua haluamani, mutta havaitsin yhden outouden (bugi?) tänään. SHF haki uudet hinnat seuraavalle vuorokaudelle ja tämä triggeröi omassa setupissani laskennan tarvittaville lämmitystunneille seuraavaksi vuorokaudeksi (syötteenä lämpötilaennuste ja tämän taakse portaittain määrätty lämmitystuntien määrä).
Nyt olisi tähän tarjolla korjausta (tai ehkä se tuo uusia bugeja mukanaan, mutta katsotaan). Eli versio 0.1.9 Githubissa: https://github.com/T3m3z/spotprices2ha

Laskee halvimman ajanjakson aikavälillä tänään kello 15 - huomenna kello 15. Ajatuksena se, että kun hinnat tulevat siinä 14-15 välillä tietoon, niin sitten olisi mahdollista heti seuraavasta tasatunnista alkaa jonkun asian ohjaus. Ja nyt on rajoitettu, että ei oteta kello 15 edeltäviä tunteja huomioon, jottei mene kyseinen hetki menneisyyteen vahingossakaan. Ja toisaalta rajattu, ettei mennä huomisen kello 15 yli, jotta ainakin kerran per 24h olisi triggeri. Automatisoijat joutuvat sitten pohtimaan, että mitä tapahtuu, jos halvin 2h pätkä esim. oli tänään kello 12-14 ja huomista kohti mentäessä hinnat kallistuvat, jolloin uusi halvin pätkä voikin olla heti 15-17. Riippunee käyttötapauksesta, että onko tämä OK vai ei.
 

heebo1974

Aktiivinen jäsen
Miten saan kaivettua sensor.shf_electricity_price_now:stä PriceNoTax:in meneillään olevalle tunnille ?
Tarkoitus olisi luoda template sensori joka antaa verottoman hinnan. Tämä tulisi Energy dashboardin aurinkopaneelien käyttöön myynnissä, koska siitähän saadaan veroton "hyöty".

Jotain tällaista yritin, mutta tuloksetta:

YAML:
  - platform: template
    sensors:
      electricity_spot_price_euro_novat:
        device_class: monetary
        friendly_name: spot.hinta.fi veroton hinta juuri nyt (eur)
        unit_of_measurement: 'eur/kWh'
        value_template: >
            {{ (states('sensor.shf_electricity_price_now', 'PriceNoTax:') | float) }}
 

Temez

Aktiivinen jäsen
Miten saan kaivettua sensor.shf_electricity_price_now:stä PriceNoTax:in meneillään olevalle tunnille ?
Muuten näytti silmällä katsottuna hyvältä, mutta value_templateen voisi kokeilla jotain tämmöistä:
Koodi:
{{ state_attr("sensor.shf_electricity_price_now", "data")[now().hour]["PriceNoTax"] }}
Hakee tuolta raakadatan puolelta (sensorin sensor.shf_electricity_price_now state attribute "data") nykyisen tunnin indeksistä/kohdalta elementin "PriceNoTax".
 

Temez

Aktiivinen jäsen
Onkohan muuten muilla ollut havaintoja semmoisesta, että tänään olisi jäänyt HomeAssistanttiin tulematta huomisen hinnat?

Minulle kävi noin tänään ja tulkkasin niin, että Mikin API:sta tuli 14:08:11 25kpl hintoja haulla "TodayAndDayForward". Tekemäni päivityslogiikka tulkitsee kaikki >24kpl hintoja tilanteeksi, että on saatu haettua huomisen hinnat. Ehkä tätä pitää viilata.
 
Back
Ylös Bottom