HomeAssistant ja sähköpörssiohjaus

hemaris

Aktiivinen jäsen
Nuo viiveet pois kytkemiseen on vähän ongelmallisia. Meillä on ainakin melko usein sähkökatkoja. Minä olen käyttänyt tällaista:
Samaa mieltä,

nuo viiveet sopii muutaman minuutin odotuksiin, mutta pidemmissä voi tulla ongelmia. Itse olen myös nähnyt että ainakin zwave-kytkimissä näkee hyvin harvakseltaan tilanteita joissa komento ei joko ole mennyt perille tai sitten kytkimeen tulee joku härökomento joka laittaa sen päälle. Olen päätynyt käyttämään countereita ja sen lisäksi tuplavarmistusta näihin tilanteisiin.

Eli komentojen perille menon varmistan laittamalla sen päällekytkentä-automaatioon muutaman minuutin viiveen ja sitten saman on/off komennon uudestaan.

Harvinaisiin virhetilanteisiin jossa kytkin päättää mennä päällee itsestään olen laittanut automaation joka triggeröityy esim 5minuutin välein ja kytkee kytkimen (tai joukon kytkimiä) pois päältä ellei sillä ole esim counter-tietoa jonka vuoksi se pidetään päällä. Tälläisestä esimerkkinä on auton lämppäri+sisätilanlämmitin, joiden en todellakaan halua jäädä vahingossa päälle päiväkausiksi - ja tällaista on siis tapahtunut ennen noita varmistuksia.

Näitä virhetilanteita näki zwave-laitteissa HA:n aiemmassa inkarnaatiossa kohtalaisen usein, mutta ne ovat vähentyneet lähes nollaan uuden Zwave-js :n myötä. En tiedä että onko esim shellyissä vastaavia ongelmia.
 
Viimeksi muokattu:
  • Tykkää
Reactions: tk-

tk-

Aktiivinen jäsen
Nuo viiveet pois kytkemiseen on vähän ongelmallisia. Meillä on ainakin melko usein sähkökatkoja. Minä olen käyttänyt tällaista:
Aloin tätä ajatusta vielä mielessä jatkojalostamaan tuon edellisen kommentin perusteella, eli jos triggerinä ei olisikaan tuo state change, mikä saattaa mennä ohi syystä tai toisesta tai muuten vaan jäädä toteutumatta laitepäässä. Vaan tätä automaatioa ajaisi time-triggerillä 5-15min välein. Mielestäni lopputulos pitäisi silloin olla sama ja toimintaperiaate olisi sama mikä tuntuu toimivan kuin se kuuluisa pikajunan vessa tuossa Shelly- ja Python-skriptissäkin missä ohjauslooppi ajetaan aina tasavartein. Laitan testiajoon tällaisen ja raportoin sitten miten kävi.

Toki tuo state change toimii myös melko varmalla todennäköisyydellä sähkökatkon kanssa, koska hetken tuo ohjaussensori ehtii olla -1 ennenkuin vaihtaa tuon oikean tilan. Ja tarvittaessa toki kytkee myös päälle unohtuneen laitteen pois.

Täytyy kehitellä tuota halvimman ajanjakson ha:n puolella etsivää sensoria siihen suuntaan, että siinäkin olisi sitten nuo päälläolotunnit aina attribuuttina joita voisi sitten käyttää samantapaisella logiikalla automaatioon, eli 5-15min aikavälillä tarkistetaan mikä tunti on menossa ja luetaan sensorista kuuluuko sen olla päällä vai pois. Se olisi ehkä kaikista varmatoimisin ratkaisu.

Itse olen myös nähnyt että ainakin zwave-kytkimissä näkee hyvin harvakseltaan tilanteita joissa komento ei joko ole mennyt perille tai sitten kytkimeen tulee joku härökomento joka laittaa sen päälle. Olen päätynyt käyttämään countereita ja sen lisäksi tuplavarmistusta näihin tilanteisiin.

Eli komentojen perille menon varmistan laittamalla sen päällekytkentä-automaatioon muutaman minuutin viiveen ja sitten saman on/off komennon uudestaan.
Tuossa HA:ssa kyllä tuntuu tulevan jatkuvasti vastaan erilaisia yllätyksiä mitä ottaa huomioon. Nytkin kun olisi tällä vuorokaudella ollut tuossa testisensorissa halvin 4h jakso klo 00 alkaen, niin eipä se sitten triggeröitynytkään päälle kun tuo sensorin tila päivitettiin vasta vuorokauden vaihtuessa, eli samalla kellonlyömällä kun aikaleima olisi pitänyt olla jo automaation käytettävissä jotta se triggeröityy. Tuosta toki selviäisi ihan vaan sillä, että aikaleiman muodostaisi niin, että se päällekytkentä tapahtuu aina vaikka 10 sekuntia yli tasatunnin. Mutta tuntuu, että tuo pelkkä aikaleimaan perustuva ohjaus tuottaa kyllä enemmän päänvaivaa ja potentiaalisia ohjauksen epäonnistumisia. Ja mielestäni se ei oikein täytä toimivan automaation kriteereitä.
 
Viimeksi muokattu:

Ilpo55

Jäsen
Tuossa HA:ssa kyllä tuntuu tulevan jatkuvasti vastaan erilaisia yllätyksiä mitä ottaa huomioon. Nytkin kun olisi tällä vuorokaudella ollut tuossa testisensorissa halvin 4h jakso klo 00 alkaen, niin eipä se sitten triggeröitynytkään päälle kun tuo sensorin tila päivitettiin vasta vuorokauden vaihtuessa, eli samalla kellonlyömällä kun aikaleima olisi pitänyt olla jo automaation käytettävissä jotta se triggeröityy.
Minusta helpereitä käytettäessä ei aikaleimaongelmaa tule. Automaatio laittaa Lvv:n kytkentäajat helpereihin jo klo 18:00.
Lisäksi minulla on varmistukseksi erillinen automaatiot mikä lähettää s-postit, kun kytkentä on tai off tapahtuu.

Oheisessa kuvassa ylin "painonappi" manuaalista ohjausta varten. Tuo näyttää myös ohjauksen tilan. Alimmalla liukukytkimellä valitaan käytetäänkö ohjausta. Sillä voi ohjauksen ottaa pois, jos ei olla kotona. Lisäksi kytkentäaikoja (helpereiden arvoja) voi tuossa muuttaa manuaalisesti.
 

Liitteet

  • LVV_ohjaus.jpg
    LVV_ohjaus.jpg
    23,7 KB · Katsottu: 100

tk-

Aktiivinen jäsen
Minusta helpereitä käytettäessä ei aikaleimaongelmaa tule. Automaatio laittaa Lvv:n kytkentäajat helpereihin jo klo 18:00.
Lisäksi minulla on varmistukseksi erillinen automaatiot mikä lähettää s-postit, kun kytkentä on tai off tapahtuu.

Oheisessa kuvassa ylin "painonappi" manuaalista ohjausta varten. Tuo näyttää myös ohjauksen tilan. Alimmalla liukukytkimellä valitaan käytetäänkö ohjausta. Sillä voi ohjauksen ottaa pois, jos ei olla kotona. Lisäksi kytkentäaikoja (helpereiden arvoja) voi tuossa muuttaa manuaalisesti.
Tämä on kyllä yksi sinällään toimivalta kuulostava tapa, mutta siinä on mukana kuitenkin käyttäjä itse, eli päivittäin periaatteessa pitää olla tietoinen onko tullut mailia. Tuossakin kuitenkin jää potentiaalisia vikakohtia, eli jos klo 18 ei olekaan tiedossa seuraavan päivän hinnat, jos ha on juuri tasan sillä hetkellä boottaamassa kun automaatio pitäisi kytkeä päälle/pois jne. Toki siihenkin voi rakentaa virheensietoa, että jos hinnat ei ole tiedossa, niin kytketään vaikka päälle klo 2 ja pois klo 5.

Itse en kuitenkaan halua semmoista automaatioa mikä lähettää jatkuvasti viestiä toimiessaan, vaan sen pitäisi olla senverta varmatoiminen, että kun se on ollut "hiljaa" niin voin olettaa, että se toimii kunhan laiterikkoja ei tapahdu. Laiterikkoihin varautuminen on taas sitten aivan oma osansa tätä ongelmaa. Ja sitä periaatetta tässä juuri taustalla yritän pohdiskella, että mikä olisi se kaikista varmin tapa, ja täältä on tullut jo erinomaisen hyviä ajatuksia.
 

Ilpo55

Jäsen
Hyviä huomioita.

>Tämä on kyllä yksi sinällään toimivalta kuulostava tapa, mutta siinä on mukana kuitenkin käyttäjä itse, eli päivittäin periaatteessa pitää olla tietoinen onko tullut mailia.

Ei tarvitse olla tietoinen. Se on ollut vain varmistus näin alkuvaiheessa. Helppo olisi muuttaa niin, että s-posti tulee vain jos On tai Off jää pois.

>Toki siihenkin voi rakentaa virheensietoa, että jos hinnat ei ole tiedossa, niin kytketään vaikka päälle klo 2 ja pois klo 5.

Jos huomisen hinnat eivät ole tiedossa, on helpereissä ed. ajat ja automaatio käyttää niitä. Ei siis jää sen takia vesi lämpiämättä.
Lvv:hen voisi tietty laittaa vielä lämpötilan mittauksen (esim.Shelly Plus 1+ (Shelly Plus Add-On + DS18B20)), millä voi varmistaa veden lämpiämisen.

Tärkeintä se, että kytkentä-ajat määritellään etukäteen, heti kun ne ovat tiedossa.
Kytkentäaikojen asetukset voisi tietty lisätä siihen automaatioon mikä hakee hinnat.
Minulla on oma automaatio mikä yrittää hakea spotti-hinnat 14:15 alkaen 15 min välein kunnes onnistuu.
 
  • Tykkää
Reactions: tk-

tk-

Aktiivinen jäsen
Hyviä huomioita.

>Tämä on kyllä yksi sinällään toimivalta kuulostava tapa, mutta siinä on mukana kuitenkin käyttäjä itse, eli päivittäin periaatteessa pitää olla tietoinen onko tullut mailia.

Ei tarvitse olla tietoinen. Se on ollut vain varmistus näin alkuvaiheessa. Helppo olisi muuttaa niin, että s-posti tulee vain jos On tai Off jää pois.

>Toki siihenkin voi rakentaa virheensietoa, että jos hinnat ei ole tiedossa, niin kytketään vaikka päälle klo 2 ja pois klo 5.

Jos huomisen hinnat eivät ole tiedossa, on helpereissä ed. ajat ja automaatio käyttää niitä. Ei siis jää sen takia vesi lämpiämättä.
Lvv:hen voisi tietty laittaa vielä lämpötilan mittauksen (esim.Shelly Plus 1+ (Shelly Plus Add-On + DS18B20)), millä voi varmistaa veden lämpiämisen.

Tärkeintä se, että kytkentä-ajat määritellään etukäteen, heti kun ne ovat tiedossa.
Kytkentäaikojen asetukset voisi tietty lisätä siihen automaatioon mikä hakee hinnat.
Minulla on oma automaatio mikä yrittää hakea spotti-hinnat 14:15 alkaen 15 min välein kunnes onnistuu.
Kyllä tuo tosiaan vaikuttaa siinä määrin varmistetulle, että ei tuossa kylmä suihku yllätyksenä voi tulla. Hyvä ajatus on tuo edellisten arvojen säilyminen jos uusia ei syystä tai toisesta saada tehtyä. Kuitenkin nuo halvimmat jaksot keskimäärin osuu aika usein samaan ajankohtaan.
 
Viimeksi muokattu:

heebo1974

Aktiivinen jäsen
Kyllä tuo tosiaan vaikuttaa siinä määrin varmistetulle, että ei tuossa kylmä suihku yllätyksenä voi tulla. Hyvä ajatus on tuo edellisten arvojen säilyminen jos uusia ei syystä tai toisesta saada tehtyä. Kuitenkin nuo halvimmat jaksot keskimäärin osuu aika usein samaan ajankohtaan.
Maailma ei varmaan räjähdä, jos joltain tunnilta jää joskus LVV päälle tai pois päältä. :)

Itselläni noi perustuu aina joka tunnilla tapahtuvaan Rank tsekkaukseen. Eli jos jostain kummansyystä jollain tunnilla ei tila vaihdu, niin eiköhän se seuraavalla tunnilla sitten vaihdu ?
 
  • Tykkää
Reactions: tk-

tk-

Aktiivinen jäsen
Maailma ei varmaan räjähdä, jos joltain tunnilta jää joskus LVV päälle tai pois päältä. :)
Näinhän se varmaan tosielämässä menee jos tekee vain itselle, mutta sitten jos on tarkoituksena harrasteprojektin nimissä tehdä julkiseen jakoon, niin ei se sitten enää saisi tuollalailla mennä..:)
 

tk-

Aktiivinen jäsen
Kokeilen nyt semmoista systeemiä, että tuon päällekytkennän aikaleimasensorin attribuutteihin lasketaan myös halutun jakson mittainen poiskytkentäaika, ja siitä arvosta tehdään sitten toinen sensori.

Automaatiolla niitä sitten mielestäni pitäisi pystyä ohjaamaan niin, että esim 15min välein laukaistaan automaatio, joka kytkee laitteen päälle jos kello on noiden kahden aikaleiman välissä ja muuten kytkee pois.

Tästä sovellutuksesta toki puuttuu vikasieto kokonaan jos hinnat ei päivity, ja nuo aikaleimat muuttuu sen takia nollaksi. Lähtökohtaisesti ajattelisin, että jokaiselle ohjattavalle laitteelle tulisi olla lisäksi olemassa oma automaationsa mikä kanssa laukaistaan esim 15min välein, ja sen ohjaukset toteutetaan vain jos hintatiedot ei ole käytettävissä. Tuossa omassa versiossa on erikseen sensori on/off tarkistamaan onko vuorokauden hintadata käytössä vai ei, ja sitä voi sitten käyttää tuon vikatilaohjauksen ehtona.

Näyttökuva 2023-6-1 kello 20.21.55.png

Näyttökuva 2023-6-1 kello 20.23.13.png

Koodi löytyy osoitteesta https://github.com/Porssari/HomeAssistant-client/blob/6b69bff3dbe0dbbd647725e16a06d5eedf390169/control addons/experimental/cheapest_period_trigger/cheapest_period_trigger.yaml jos joku haluaa tuota muokata myös tuota spot-hinnan jsonia tukemaan. Testailin templaattieditorissa tuota, niin toimii myös niinä päivinä oikein kun kelloa käännetään.

EDIT: itseasiassa tuo edellinen automaatio kytkee tuon plugin aina pois vaikka hintadataa ei olisi tiedossa. Eli oikeastaan varatila täytyykin rakentaa tähän samaan. Tuo json_data -sensori on binäärisensori löytyykö jsonista kuluvalle vuorokaudelle vähintään 23 aikaleimaa, ja jos löytyy se saa tilan on, muuten off. Eli päivitetyssä versiossa tuota aikaleimaohjausta käytetään kun tuo json_data on "on" ja muuten kytketään päälle välillä 01-05. Josko se tällälailla jo olisi toimiva... Omalla vastuulla saa testata, en vielä takaa tuon toimivan oikein.

YAML:
alias: Shelly trigger
description: ""
trigger:
  - platform: time_pattern
    minutes: /15
    seconds: "15"
condition: []
action:
  - if:
      - condition: state
        entity_id: binary_sensor.porssari_json_prices
        state: "on"
    then:
      - if:
          - condition: time
            after: sensor.porssari_water_heating_on
            before: sensor.porssari_water_heating_off
        then:
          - type: turn_on
            device_id: ae3bf886b71fd20222b8542be6841dc2
            entity_id: switch.shellyplug_s_3ce90ed81792
            domain: switch
        else:
          - type: turn_off
            device_id: ae3bf886b71fd20222b8542be6841dc2
            entity_id: switch.shellyplug_s_3ce90ed81792
            domain: switch
    else:
      - if:
          - condition: time
            after: "01:00:00"
            before: "05:00:00"
        then:
          - type: turn_on
            device_id: ae3bf886b71fd20222b8542be6841dc2
            entity_id: switch.shellyplug_s_3ce90ed81792
            domain: switch
        else:
          - type: turn_off
            device_id: ae3bf886b71fd20222b8542be6841dc2
            entity_id: switch.shellyplug_s_3ce90ed81792
            domain: switch
mode: single
 
Viimeksi muokattu:

jalih

Jäsen
Kokeilen nyt semmoista systeemiä, että tuon päällekytkennän aikaleimasensorin attribuutteihin lasketaan myös halutun jakson mittainen poiskytkentäaika, ja siitä arvosta tehdään sitten toinen sensori.

Automaatiolla niitä sitten mielestäni pitäisi pystyä ohjaamaan niin, että esim 15min välein laukaistaan automaatio, joka kytkee laitteen päälle jos kello on noiden kahden aikaleiman välissä ja muuten kytkee pois.
Kyselen varmaan tyhmiä, mutta eikö HA:ssa ole tapahtumajonoa tai järjestettyä tapahtumalistaa mistä nuo päälle/pois tapahtumat käsiteltäisiin automaattisesti ajallaan ilman, että laukaistaisiin joku automaatio itse aina tietyin väliajoin?

Omassa ohjelmassani tapahtumajono tai järjestetty tapahtumalista on tuntunut hyvin toimintavarmalta toteutustavalta.
 

tk-

Aktiivinen jäsen
Kyselen varmaan tyhmiä, mutta eikö HA:ssa ole tapahtumajonoa tai järjestettyä tapahtumalistaa mistä nuo päälle/pois tapahtumat käsiteltäisiin automaattisesti ajallaan ilman, että laukaistaisiin joku automaatio itse aina tietyin väliajoin?

Omassa ohjelmassani tapahtumajono tai järjestetty tapahtumalista on tuntunut hyvin toimintavarmalta toteutustavalta.
Voisi tuon automaation tehdä niinkin, että kun aika täsmää noiden päälle- tai poiskytkennän kanssa niin automaatio laukaistaan. Moni täällä taitaa niin tuon ohjauksen hoitaakin.

Joku tuollainen kalenteripohjainen scheduler näyttää olevan, mutta en ole ainakaan itse perehtynyt siihen sen tarkemmin. Ehkä sitäkin voisi halutessaan hyödyntää?

Mutta tuo vartin välein tarkistus tuossa on enimmäkseen sillä ajatuksella, että edelläkin on tuotu esiin tilanteita missä yksittäinen käsky ei syystä tai toisesta aina menekään perille. Ei tuo minun mielestä hirveästi resurssia vie vaikka tuollaisia automaatioehtoja ajaakin tasaisin väliajoin. Lähinnä sen tehtävä on varmistaa, että laitteet ovat siinä tilassa kun kuuluu olla.
 

jalih

Jäsen
Mutta tuo vartin välein tarkistus tuossa on enimmäkseen sillä ajatuksella, että edelläkin on tuotu esiin tilanteita missä yksittäinen käsky ei syystä tai toisesta aina menekään perille. Ei tuo minun mielestä hirveästi resurssia vie vaikka tuollaisia automaatioehtoja ajaakin tasaisin väliajoin. Lähinnä sen tehtävä on varmistaa, että laitteet ovat siinä tilassa kun kuuluu olla.
Miten ratkaiset ongelman laitteiden kanssa, joita voi ohjata joko "älyohjauksella" tai lisäksi perinteisesti esimerkiksi painonapilla? Ohittaako vartin välein tehtävä tarkastus tehdyn "käsiohjauksen"? Mielestäni oikea vaihtoehto olisi kuitenkin vasta varsinaisen seuraavan aikaohjaustapahtuman tullessa.
 
  • Tykkää
Reactions: tk-

-Teme-

Vakionaama
Backup ohjauksena LVV:tä ohjaavaan shellyyn laitoin 46h turn on timerin joka kytkee releen päälle edellisestä turn off hetkestä
Toinen timer on turn off joka kytkeytyy 1h58min kuluttua turn on hetkestä
Tälleen ohjaus on lokaalisti laitteessa ja vikasieetoisempi kuin ulkoisen ohjauksen kautta
 

tk-

Aktiivinen jäsen
Miten ratkaiset ongelman laitteiden kanssa, joita voi ohjata joko "älyohjauksella" tai lisäksi perinteisesti esimerkiksi painonapilla? Ohittaako vartin välein tehtävä tarkastus tehdyn "käsiohjauksen"? Mielestäni oikea vaihtoehto olisi kuitenkin vasta varsinaisen seuraavan aikaohjaustapahtuman tullessa.
Tuo olikin hyvä huomio! En osannut vielä ottaa asiaa ollenkaan huomioon. Sen voisi tehdä vaikka niin, että laittaa switchin jonka tila luetaan osana tuota automaatioehtoa. Ja kun switch päällä, laite ”pakko-ohjataan” päälle. Halutessaan voi vaikka laittaa vielä timerin joka liipaistaan kun switch kytketään päälle ja switch palautetaan off-tilaan, eli laite palautetaan automaattiohjaukselle kun aika on kulunut.

Tässä on mielestäni aika monta hyvää tapaa tehdä tämä oikein ja asiaan liittyy juurikin noita muuttujia. Eli halutaanko mahdollisuus manuaaliohjaukseen, halutaanko vielä varmistaa paikallisesti itse ohjauslaitteessa asiaa jne.

Juuri siksi kyselenkin, kun itseäni kiinnostaa mahdollisimman moni erilainen tapa hoitaa tämä asia, ja yritän löytää keinon joka ottaa yhdessä yamlissa ja yhdessä automaatiossa mahdollisimman monta eri vaihtoehtoa huomioon.
 
Viimeksi muokattu:

Ilpo55

Jäsen
Tälleen ohjaus on lokaalisti laitteessa ja vikasieetoisempi kuin ulkoisen ohjauksen kautta
Kannatan lokaalia ohjausta, mikäli laite tukee sitä, kuten Shelly.
Shellylle voisi spottihintojen saavuttua kerralla "lähettää" On/Off ajastukset.
Minulla on käytössä lvv:n ohjauksessa Nobö rele ja se ei tue lokaalia ohjausta, joten jodun ohjaamaan relettä suoraan HA:lla.
Auton latauksessa käytän lokaalia ohjausta, niin että latauksen aloitusajan lähetän autolle etukäteen. Auto sitten itsenäisesti aloittaa latauksen.

Minulla on pari kertaa Shelly kadonnut verkosta, vaikka siinä on kiinteä IP. Tuokin asia kannattaa huomoida.
(Ongelma on luultavasti ollut reitittimessä, koska reitittimen bootti on auttanut.)
 
Viimeksi muokattu:

-Teme-

Vakionaama
Tuo olikin hyvä huomio! En osannut vielä ottaa asiaa ollenkaan huomioon. Sen voisi tehdä vaikka niin, että laittaa switchin jonka tila luetaan osana tuota automaatioehtoa. Ja kun switch päällä, laite ”pakko-ohjataan” päälle. Halutessaan voi vaikka laittaa vielä timerin joka liipaistaan kun switch kytketään päälle ja switch palautetaan off-tilaan, eli laite palautetaan automaattiohjaukselle kun aika on kulunut.
Shellyissä jotka itsellä toimii sähköisen lattialämmityksen termostaatteina, on justiinsa tuo sitch detached modessa. Tällä hetkellä se toimii kuorman alennuksen indikaattorina - eli kun kiukaan napsauttaa päälle kiukaan kuormanohjaus kääntää sähkökaapin shelly pro releen kytkimen ON-asentoon, joka triggeröi haluttujen termostaattien kytkimet ON-asentoon.
Automaati huomaa että laitteen kuormanalennus swi on pällä, jolloin termostaatin status on off
Tulevaisuudessa ajatus tehdä kuorman hallinta dynaamisemmaksi jossa tutkitaan jokaisen vaiheen kokonaiskuormaa ja sen perusteella kytketään kuormia on/off jotta pääsulakkeet ei napsu.
 

Sukke

Aktiivinen jäsen
Shellyissä jotka itsellä toimii sähköisen lattialämmityksen termostaatteina, on justiinsa tuo sitch detached modessa. Tällä hetkellä se toimii kuorman alennuksen indikaattorina - eli kun kiukaan napsauttaa päälle kiukaan kuormanohjaus kääntää sähkökaapin shelly pro releen kytkimen ON-asentoon, joka triggeröi haluttujen termostaattien kytkimet ON-asentoon.
Automaati huomaa että laitteen kuormanalennus swi on pällä, jolloin termostaatin status on off
Tulevaisuudessa ajatus tehdä kuorman hallinta dynaamisemmaksi jossa tutkitaan jokaisen vaiheen kokonaiskuormaa ja sen perusteella kytketään kuormia on/off jotta pääsulakkeet ei napsu.

Puolilämpimän varaston lattialämmitys pitäisi saada ohjattavaksi. Miten olet tuon Shellyllä toteuttanut tai millä Shellyllä?

Ajattelin vaihtoehtona, että laitan jonkun lämmityspatterin ohjattavan pistorasian taakse ja jätän lattialämmityksen minimille varalle.
 

Harrastelija

Vakionaama
Tulevaisuudessa ajatus tehdä kuorman hallinta dynaamisemmaksi jossa tutkitaan jokaisen vaiheen kokonaiskuormaa ja sen perusteella kytketään kuormia on/off jotta pääsulakkeet ei napsu.
Siirtoyhtiöillä on omia vaatimuksia esim yösähkön aloituspiikkien osalta. Niissä vaatimuksissa kuormanhallintaa ei tehdä talon pääsulakkeiden suojaamiseksi vaan koko verkon kannalta. Sama homma kiukaan kuorman ohjauksessa.

Itsekin aikoinaan sanoin sähkärille miksi noita rajoituksia tarvitaan kun sen vuoksi otettiin isommat sulakkeet jottei ”sähkö lopuisi kesken”.
Hulluahan se on että myydään eri kokoisia liittymiä ja sitten niitä ei saisikaan käyttää koko teholla. Tosin myydäänhän autojakin hevosilla joista (joillakin käyttäjillä) kaikki ei koskaan pääse laukalle.
 

-Teme-

Vakionaama
Puolilämpimän varaston lattialämmitys pitäisi saada ohjattavaksi. Miten olet tuon Shellyllä toteuttanut tai millä Shellyllä?

Ajattelin vaihtoehtona, että laitan jonkun lämmityspatterin ohjattavan pistorasian taakse ja jätän lattialämmityksen minimille varalle.
Lämmitys hoidettu Shelly (plus)1PM, addon ja Dallas sensori kombolla. Ohjaus Home Assistantilla, mutta lisäksi laitteissa ylä- ja alalämpötilan ohjaus.
 

-Teme-

Vakionaama
Siirtoyhtiöillä on omia vaatimuksia esim yösähkön aloituspiikkien osalta. Niissä vaatimuksissa kuormanhallintaa ei tehdä talon pääsulakkeiden suojaamiseksi vaan koko verkon kannalta. Sama homma kiukaan kuorman ohjauksessa.

Itsekin aikoinaan sanoin sähkärille miksi noita rajoituksia tarvitaan kun sen vuoksi otettiin isommat sulakkeet jottei ”sähkö lopuisi kesken”.
Hulluahan se on että myydään eri kokoisia liittymiä ja sitten niitä ei saisikaan käyttää koko teholla. Tosin myydäänhän autojakin hevosilla joista (joillakin käyttäjillä) kaikki ei koskaan pääse laukalle.
Pörssiohjauksen myötä piikit ovat muuttuneet, kun kello- ja älyohjauksia lisääntynyt. SPOT ohjauksessa eri lämmityspiirit on laitettu käynnistymään 60sekunnin sisällä randomilla ajanjaksolla. Tuo siis silloin kun hinta on määriteltyjen marginaalinen sisällä. Eli tuolla järjestelyllä estetään piikki että kaikki laitteet kytkeytyisi yhtäaikaisesti päälle.
Se mitä olen verkkoyhtiöstä selvittänyt, niin 50A pääsulakkeet pitäisi onnistua, itsellä kuitenkin vain 25A
 

Sukke

Aktiivinen jäsen
Lämmitys hoidettu Shelly (plus)1PM, addon ja Dallas sensori kombolla. Ohjaus Home Assistantilla, mutta lisäksi laitteissa ylä- ja alalämpötilan ohjaus.

Miten tuo on siis kytketty? Nyt meillä on termostaatti seinässä, mutta miten sen tilalle asentaa Shellyn?

Ei taida isot muutokset kannattaa eurojen puolesta. Ajatus oli lähinnä saada halvoille tunneille edes vähän ohjattua lämmitystä tai ainakin jättää kalleimmat tunnit välistä.
 

exrx

Jäsen
Mikähän mahtaa olla vikana, kun asensin tämän SHF:n Home Assistantiin, sensorit tulivat näkyville mutta hintatietoja ei vaan ilmaannu, ei vaikka käynnistän hinnan hakevan automaation käsin.

https://spot-hinta.fi/home-assistant/ löytyvällä minimalistisensoreilla saan kyllä tuon nykyhinnan näkyville.
 

heebo1974

Aktiivinen jäsen
Mikähän mahtaa olla vikana, kun asensin tämän SHF:n Home Assistantiin, sensorit tulivat näkyville mutta hintatietoja ei vaan ilmaannu, ei vaikka käynnistän hinnan hakevan automaation käsin.

https://spot-hinta.fi/home-assistant/ löytyvällä minimalistisensoreilla saan kyllä tuon nykyhinnan näkyville.
Se automaatio käynnistää random ajastimen, olikohan jopa 15min maksimissaan. Eli voi olla yksi syy, ettet vain ole odottanut tarpeeksi. Toiminto on tehty sen taikia, ettei kaikki hakisi samalla sekunnilla tietoa ja näin kuormittaisi serveriä niin paljon.
 

exrx

Jäsen
Se automaatio käynnistää random ajastimen, olikohan jopa 15min maksimissaan. Eli voi olla yksi syy, ettet vain ole odottanut tarpeeksi. Toiminto on tehty sen taikia, ettei kaikki hakisi samalla sekunnilla tietoa ja näin kuormittaisi serveriä niin paljon.
Olen nyt odottanut pari päivää, mutta hintoja ei vaan ilmaannu, eli tuosta ei taida olla kysymys.
 

heebo1974

Aktiivinen jäsen
Olen nyt odottanut pari päivää, mutta hintoja ei vaan ilmaannu, eli tuosta ei taida olla kysymys.
Juu, ei sitten tietenkään. Olethan tehnyt nuo ns. patchit mistä on keskusteltu tässä lähaikoina ? Githubissa oleva versio ei suoraan toimi uusimpien HA versioiden kanssa.
 

Mikki

Hyperaktiivi
Ei joku jaksaisi tehdä toimivasta koodisfa PRää, voisi sitten ainakin siihen viitata jos joku tarvii toimivan koodin.

Olen muuten tietoinen että on tekeillä Hacs paketti tähän spot-hinta.fi. rajapintaan. Saa nähdä tuleeko siitä hyvä toteutus.
 

Samppa

Ylläpitäjä
Ylläpidon jäsen
Olen nyt odottanut pari päivää, mutta hintoja ei vaan ilmaannu, eli tuosta ei taida olla kysymys.

Alta kun copy-pastettaa spot-price.yaml tiedostoon sisällön entisen päälle, niin pitäisi kaiken toimia. Tiedostoa voi editoida esim File editor tai Studio Code server tms. lisäosalla. Löytyy seuraavan polun takaa:
1685809682790.png


HA:n uudelleenkäynnistys tai pelkkä yaml uudelleenlataus muutoksen jälkeen. Kuittaa kuin kävi, niin voisi tietenkin vaikka ekaviestin yhteyteen tämän laittaa. Käytännössä riittää että kolme riviä korjaa, mutta ajattelin että koko sisällön vaihto voi olla jopa nopeampi.

Tässä viestissä on kerrottu nuo kolme muutettavaa riviä erikseen:

Koko koodi (toimiva):
YAML:
# Start pack for Spot Price control.
# Version 0.1.11 lampopumput.info unofficial edit
#
# This is a copy-paste approach in order to get Finnish Electricity Spot Prices to Home Assistant.
# Initial implementation by Temez but feel free to further develop this.
# Special thanks to Mikki who has created the API where data is fetched. For more information see https://spot-hinta.fi/

# This is just a loader for the data which is stored in sensor attributes. Template sensors present actual data.
sensor:
  - platform: rest
    resource: https://api.spot-hinta.fi/TodayAndDayForward?HomeAssistant=true
    name: SHF Electricity price
    unique_id: shf_electricity_price
    scan_interval: 604800 # 7 days, update logic is in the automation
    value_template: 'OK' # static value as sensor is not updated regularly
    json_attributes:
      - "data"
  - platform: statistics
    name: "SHF Average Price 7 Days"
    entity_id: sensor.shf_electricity_price_now
    state_characteristic: mean
    unique_id: shf_average_7days
    precision: 4
    max_age:
      days: 7

template:
  - sensor:
    - name: SHF Idx # Helper for other sensors to get correct price/rank from array
      unique_id: shf_helper_idx
      state: '{{ 0 if state_attr("sensor.shf_electricity_price_now", "data")[0]["DateTime"][8:10] | int == now().day else 24 }}'
  - sensor:
    - name: SHF Rank now
      unique_id: shf_electricity_rank_now
      unit_of_measurement: Rank
      state: '{{ state_attr("sensor.shf_electricity_price_now", "data")[states("sensor.shf_idx")|int+now().hour]["Rank"] }}'
  - sensor:
    - name: SHF Electricity price now
      unique_id: shf_electricity_price_now
      unit_of_measurement: "€/kWh"
      device_class: monetary
      state: '{{ state_attr("sensor.shf_electricity_price_now", "today_prices")[now().hour] | default(none) }}'
      attributes:
        data: '{{ state_attr("sensor.shf_electricity_price", "data") if  state_attr("sensor.shf_electricity_price", "data") else state_attr("sensor.shf_electricity_price_now", "data") }}'
        all_prices: >
                   {% set output = namespace(value=[]) %}
                   {% for value in (state_attr("sensor.shf_electricity_price_now", "data")) | map(attribute="PriceWithTax") | list %}
                     {% if ((loop.index - 1) % 24) >= state_attr("input_datetime.shf_price2_start", "hour") and ((loop.index - 1) % 24) < state_attr("input_datetime.shf_price2_stop", "hour") %}
                       {% set output.value = output.value + [ value + states('input_number.shf_price2_slider') | float] %}
                     {% else %}
                       {% set output.value = output.value + [ value + states('input_number.shf_price1_slider') | float] %}
                     {% endif %}
                   {% endfor %}
                   {{ output.value if output.value | length > 0 else state_attr("sensor.shf_electricity_price_now", "all_prices") }}
        today_prices: '{{ (state_attr("sensor.shf_electricity_price_now", "all_prices"))[states("sensor.shf_idx")|int:states("sensor.shf_idx")|int+24] | list }}'
        tomorrow_prices: '{{ (state_attr("sensor.shf_electricity_price_now", "all_prices"))[states("sensor.shf_idx")|int+24:] | list }}'
        today_min: '{{ state_attr("sensor.shf_electricity_price_now", "today_prices") | min }}'
        today_avg: '{{ state_attr("sensor.shf_electricity_price_now", "today_prices") | average | round(4) }}'
        today_max: '{{ state_attr("sensor.shf_electricity_price_now", "today_prices") | max }}'
        tomorrow_min: '{{ state_attr("sensor.shf_electricity_price_now", "tomorrow_prices") | min | default("unknown") }}'
        tomorrow_avg: '{{ state_attr("sensor.shf_electricity_price_now", "tomorrow_prices") | average("unknown") }}'
        tomorrow_max: '{{ state_attr("sensor.shf_electricity_price_now", "tomorrow_prices") | max | default("unknown") }}'
  - sensor:
    - name: SHF Average price today
      unique_id: shf_average_electricity_price
      unit_of_measurement: "€/kWh"
      device_class: monetary
      state: '{{ state_attr("sensor.shf_electricity_price_now", "today_avg") }}'
  - sensor:
    - name: SHF Average price next hours
      unique_id: shf_average_electricity_price_next_hours
      unit_of_measurement: "€/kWh"
      device_class: monetary
      state: >
            {% set idx = states("sensor.shf_idx")|int + now().hour + 1 %}
            {{ (state_attr("sensor.shf_electricity_price_now", "all_prices"))[idx:idx+states("input_number.shf_price_avg_slider")|int] | average | round(3) }}
  - sensor:
    - name: SHF Cheapest period start helper
      unique_id: shf_cheapest_period_start_helper
      state: >
            {% set output = namespace(value=[]) %}
            {% set data = state_attr("sensor.shf_electricity_price_now", "all_prices")[15:39] %}
            {% set hours = states("input_number.shf_cheapest_period_slider") | int%}
            {%- for inval in data[:min(-hours+1, -1)] -%}
              {% set temp = namespace(value=[]) %}
              {%- set j = loop.index -1 -%}
              {%- for i in range(hours) %}
                {%- set temp.value = temp.value + [data[j+i]] -%}
              {%- endfor -%}
              {%- set output.value = output.value + [temp.value | average] -%}
            {%- endfor -%}
            {% set data2 = state_attr("sensor.shf_electricity_price_now", "data")[15:39] %}
            {{ data2[output.value.index(output.value|min)]["DateTime"] }}
  - sensor:
    - name: SHF Control Factor 0-1
      unique_id: shf_control_factor_0-1
      unit_of_measurement: factor
      icon: mdi:gauge
      state: '{{ (states("sensor.shf_control_factor_1") | float /2 + 0.5) | default(none) }}'
      attributes:
        today_values: >
            {% set output = namespace(value=[]) %}
            {% for value in state_attr("sensor.shf_control_factor_1", "today_values") %}
                {% set output.value = output.value + [ value | float /2 + 0.5 ] %}
            {% endfor %}
            {{ output.value }}

  - sensor:
    - name: SHF Control Factor +-1
      unique_id: shf_control_factor_+-1
      unit_of_measurement: factor
      icon: mdi:gauge
      state: '{{ state_attr("sensor.shf_control_factor_1", "today_values")[now().hour] | default(none) }}'
      attributes:
        today_values: >
            {% set output = namespace(value=[]) %}
            {% for pnow in state_attr("sensor.shf_electricity_price_now", "today_prices") %}
              {% set pmin = state_attr("sensor.shf_electricity_price_now", "today_min") | float %}
              {% set pmax = state_attr("sensor.shf_electricity_price_now", "today_max") | float %}
              {% set value = max(min((2*(pmax - pnow) / (pmax - pmin)-1) * states('input_number.shf_control_function_factor') | float,1),-1) %}
              {% if states("input_select.shf_control_function" ) == "Linear"  %}
                {% set output.value = output.value + [value | round(2)] %}
              {% else %}
                {% set output.value = output.value + [sin(value*pi/2) | round(2)] %}
              {% endif %}
            {% endfor %}
            {{ output.value }}
  - binary_sensor:
    - name: "SHF Rank acceptable"
      unique_id: shf_rank_acceptable
      device_class: power
      state: >
            {% set value = state_attr("sensor.shf_electricity_price_now", "data")[states("sensor.shf_idx")|int+now().hour] %}
            {{ value["Rank"] <= states("input_number.shf_rank_slider") | int }}
  - binary_sensor:
    - name: "SHF Price acceptable"
      unique_id: shf_price_acceptable
      device_class: power
      state: >
            {% set value = state_attr("sensor.shf_electricity_price_now", "today_prices")[ now().hour ] %}
            {{ value <= states("input_number.shf_price_slider") | float }}
  - binary_sensor:
    - name: "SHF Price or Rank acceptable"
      unique_id: shf_price_or_rank_acceptable
      device_class: power
      state: '{{ is_state("binary_sensor.shf_rank_acceptable", "on") or is_state("binary_sensor.shf_price_acceptable", "on") }}'

input_select:
  shf_control_function:
    name: SHF Control Function
    options:
      - Linear
      - Sinusoidal
    icon: mdi:gauge

input_number:
  shf_control_function_factor:
    name: SHF Control Function Factor
    min: 1
    max: 3
    step: 0.01
    icon: mdi:gauge
    mode: box
  shf_rank_slider:
    name: SHF Max Rank allowed
    min: 1
    max: 24
    step: 1
  shf_price_slider:
    name: SHF Max Price allowed
    min: 0
    max: 4
    step: 0.01
    unit_of_measurement: €/kWh
    icon: mdi:cash-lock
    mode: box
  shf_price_avg_slider:
    name: SHF Average price hours
    min: 1
    max: 24
    step: 1
    unit_of_measurement: h
    icon: mdi:cash-clock
  shf_cheapest_period_slider:
    name: SHF Cheapest period hours
    min: 1
    max: 24
    step: 1
    unit_of_measurement: h
    icon: mdi:cash-clock
  shf_control_factor:
    name: SHF Control Factor
    min: 0
    max: 1000
    mode: box
  shf_price1_slider:
    name: SHF Price1
    min: 0
    max: 1000
    step: 0.0001
    unit_of_measurement: €
    icon: mdi:cash-lock
    mode: box
  shf_price2_slider:
    name: SHF Price2
    min: 0
    max: 1000
    step: 0.0001
    unit_of_measurement: €
    icon: mdi:cash-lock
    mode: box

input_datetime:
  shf_cheapest_period_start:
    name: SHF Cheapest period start
    has_date: true
    has_time: true
  shf_price2_start:
    name: SHF Price2 start
    has_date: false
    has_time: true
  shf_price2_stop:
    name: SHF Price2 stop
    has_date: false
    has_time: true

#Automation for automatic updating of the sensor. Tries to reduce API load.
automation:
  - id: '1669453089221'
    alias: Intelligent update of electricity price sensor
    description: 'Tries to fetch new data every 15mins after 14 oclock local time. Condition stops unnecessary requests. Random delay disperses API calls.'
    trigger:
    - platform: time_pattern
      minutes: /15
      alias: Trigger every 15mins
    condition:
    - condition: template
      value_template: '{{ is_state("sensor.shf_electricity_price", "unavailable") or is_state("sensor.shf_idx", "unavailable") or (now().hour >= 14 and (states("sensor.shf_idx") | int > 0 or state_attr("sensor.shf_electricity_price", "data") | length <= 24)) }}'
      alias: Check if there isn't data for tomorrow and time is after 14 o'clock
    action:
    - delay: '{{ range(60, 600)|random }}'
      alias: Random delay in order to reduce API congestion
    - service: homeassistant.update_entity
      alias: Trigger the update of the sensor
      target:
        entity_id: sensor.shf_electricity_price
    mode: single
  - id: '1669453089222'
    alias: "Copy cheapest period to datetime sensor"
    description: "Copies cheapest period start from helper to datetime sensor for easier automations."
    mode: single
    trigger:
      - platform: state
        entity_id:
          - sensor.shf_cheapest_period_start_helper
    condition: []
    action:
      - service: input_datetime.set_datetime
        data:
          datetime: '{{ states("sensor.shf_cheapest_period_start_helper")[:19] | replace("T", " ") }}'
        target:
          entity_id: input_datetime.shf_cheapest_period_start
 

Samppa

Ylläpitäjä
Ylläpidon jäsen
Tässä liitetiedostona vielä valmiina yamlina. Eli tämän voi suoraan kopsata esim. file editorilla vanhan päälle, ei tarve copy-pastetella sisältöä käsin:
 

Liitteet

  • spot-price.yaml
    11,3 KB · Katsottu: 119

exrx

Jäsen
Tässä liitetiedostona vielä valmiina yamlina. Eli tämän voi suoraan kopsata esim. file editorilla vanhan päälle, ei tarve copy-pastetella sisältöä käsin:
No niin, tällähän se rupesi toimimaan. Kiitos!

Mikähän tuossa Githubin versiossa on pielessä verrattuna tähän?
 

Mikki

Hyperaktiivi
No niin, tällähän se rupesi toimimaan. Kiitos!

Mikähän tuossa Githubin versiossa on pielessä verrattuna tähän?
HA:han on tullut uusissa päivityksissä jotain rikkovia muutoksia, joita ei ainakaan hyvin ole dokumentoitu.

Aika monia integraatioita on hajoillut.
 

tk-

Aktiivinen jäsen
No niin, tällähän se rupesi toimimaan. Kiitos!

Mikähän tuossa Githubin versiossa on pielessä verrattuna tähän?
Home assistant lakkasi hyväksymästä string-arvoja sellaisiin sensoreihin minkä arvo pitäisi olla numeerinen device_class -asetuksen perusteella. Siellä on joissakin sensoreissa/attribuuteissa default-arvona ’unknown’, mikä ei sitten enää uusimmassa versiossa käy.

Itse ajattelisin, että joku bugi mahdollisti aiemmin virheellisen yaml-templaatin jotka nyt eivät sitten enää toimi kun kyseinen bugi on korjattu. Uskoisin kuitenkin logeissa näkyneen virhettä tuosta jo aikaisemminkin.
 
Viimeksi muokattu:

exrx

Jäsen
Olikos tässä SHF-paketissa joku helppo keino saada esitettyä kilowattitunnin hinta senteissä? Nyt tuo päivän hintakuvaaja esittää hinnat senteissä mutta SHF-sensorit euroissa.
 

-Teme-

Vakionaama
Miten tuo on siis kytketty? Nyt meillä on termostaatti seinässä, mutta miten sen tilalle asentaa Shellyn?

Ei taida isot muutokset kannattaa eurojen puolesta. Ajatus oli lähinnä saada halvoille tunneille edes vähän ohjattua lämmitystä tai ainakin jättää kalleimmat tunnit välistä.
Nykyinen termostaatti pois. Shelly kippoon - L jaetaan I ja Shellylle, N jaetaan Shellylle ja vastukselle, toinen vastuksen johto Shellyn O liitäntään. Add-On Shellyn selässä ja siihen Dallas sensori kiinni.
Lopulta koppoon umpikansi päälle
 

timop

Aktiivinen jäsen
Olikos tässä SHF-paketissa joku helppo keino saada esitettyä kilowattitunnin hinta senteissä? Nyt tuo päivän hintakuvaaja esittää hinnat senteissä mutta SHF-sensorit euroissa.
itse laitoin sensors.yamliin

YAML:
- platform: template
  sensors:
    porssihintanytsentteina:
      unit_of_measurement: c/kWh
      value_template: "{{ states('sensor.shf_electricity_price_now')| float * 100 |round(2) }}"
 

Ilpo55

Jäsen
Törmäsin jokin aika sitten ao. juttuun.
Jos hinta sattuu olemaan 0.0428 tulee yo. koodilla hiukka outo tulos:
Koodi:
{{ ('0.0428')| float * 100 | round(2) }}
= 4.279999999999999

Löysin siihen sitten toimivan ratkaisun
Koodi:
{{ "%.2f" | format("0.0428" | float*100 ) }}
= 4.28

Mistähän tuo mahtaa johtua?
 

Ilpo55

Jäsen
Toinen huomio:
Koodi:
"{{ states('sensor.shf_electricity_price_now')| float * 100 |round(2) }}"
Toimiiko round(2) tuossa ylipäätään?
Esim.
Koodi:
{{ ('0.03299')| float *100  |round(2) }}
=3.299
Eikös se pitäisi olla 3.30 tai 3.3?

Yhdet sulut lisää auttavat:
Koodi:
"{{ (states('sensor.shf_electricity_price_now')| float * 100) |round(2) }}"
 
Viimeksi muokattu:

tk-

Aktiivinen jäsen
Törmäsin jokin aika sitten ao. juttuun.
Jos hinta sattuu olemaan 0.0428 tulee yo. koodilla hiukka outo tulos:
Koodi:
{{ ('0.0428')| float * 100 | round(2) }}
= 4.279999999999999

Löysin siihen sitten toimivan ratkaisun
Koodi:
{{ "%.2f" | format("0.0428" | float*100 ) }}
= 4.28

Mistähän tuo mahtaa johtua?
Tuossa tuo round(2) taitaa filtteröidä vaan lukua 100 eikä tuota laskua. Eli nuo edellisessä olevat sulut auttanee tuossakin.
 
Back
Ylös Bottom