HomeAssistant ja sähköpörssiohjaus

[-Teme-]

Olisiko Temez iso rypistys lisätä "SHF Electricity price now":lle atribuutteihin vielä nämä ?

Today min notax
Today avg notax
Today max notax
Tomorrow min notax
Tomorrow avg notax
Tomorrow max notax

En kyllä onnistunut ottamaan tuosta perus sensoristakaan PriceNoTax arvoa.
No puolen vuoden tauon jälkeen vähän kesäterässä. Taitaa vaatia data atribuuttia ja jotain koodia, joka parsii sen siitä.

Tälleen nuo näytti tulleen, lisää spot-price pakettiin SHF Electricity price now alle

  - sensor:
    - name: SHF Electricity price now NoTax
      unique_id: shf_electricity_price_now_no_tax
      unit_of_measurement: "€/kWh"
      device_class: monetary
      state: '{{ state_attr("sensor.shf_electricity_price", "data")[states("sensor.shf_idx")|int+now().hour]["PriceNoTax"] }}'
      attributes:
        today_prices_notax: '{{ (state_attr("sensor.shf_electricity_price", "data"))[states("sensor.shf_idx")|int:states("sensor.shf_idx")|int+24] | map(attribute="PriceNoTax") | list }}'
        tomorrow_prices_notax: '{{ (state_attr("sensor.shf_electricity_price", "data"))[states("sensor.shf_idx")|int+24:] | map(attribute="PriceNoTax") | list }}'
        today_min_notax: '{{ state_attr("sensor.shf_electricity_price_now", "today_prices") | min }}'
        today_avg_notax: '{{ state_attr("sensor.shf_electricity_price_now", "today_prices") | average | round(4) }}'
        today_max_notax: '{{ state_attr("sensor.shf_electricity_price_now", "today_prices") | max }}'
        tomorrow_min_notax: '{{ state_attr("sensor.shf_electricity_price_now", "tomorrow_prices") | min | default("unknown") }}'
        tomorrow_avg_notax: '{{ state_attr("sensor.shf_electricity_price_now", "tomorrow_prices") | average("unknown") }}'
        tomorrow_max_notax: '{{ state_attr("sensor.shf_electricity_price_now", "tomorrow_prices") | max | default("unknown") }}'

 

[heebo1974]

Tälleen nuo näytti tulleen, lisää spot-price pakettiin SHF Electricity price now alle

Hmm. Joku vielä mättää.
Kuluvan tunnin notax toimii, mutta min,avg ja max arvot ovat verollisia.

 

[heebo1974]

No ohitin tuon nyt toistaiseksi apex chart kikkailulla.

Ideana tässä on siis, sellainen (hih) manuaalinen automaatio.

Eli tein sellaisen pienen visuaalisen apex chart kortin, josta voin manuaalisesti laskeskella ja pähkäillä, että mitä laittaisin oman LVV:n aurinkoenergian varttinetotus automaation myyntirajaksi.

Eli kun pörssisähkössä aurinkoenergian myynnistä saa pörssisähkön sen hetkisen korvauksen ilman 24% alvia ja sitten taas yöllä jos lämmittelee LVV:tä ostosähköllä, niin siitä taas pitää maksaa pörssin lisäksi verot ja siirtomaksut.

Esim:
Siirtomaksu yöllä 4.19c/kWh sis. verot jne.
Pörssisähkö yöllä 5c/kWh sis verot
--> Yhteensä 9.19c/kWh

Näin päivällä pitäisi siis auringon paistaessa saada verottomasta pörssisähköstä vähintään se 9.2c/kWh,

Jos siis päivällä auringon paistaessa sähkön veroton hinta on vaikka 8c, niin LVV:tä pidellään päällä, kun taas jos sähkön veroton hinta on yli tuon 9.2 c/kWh, niin sitten LVV saa olla pois päältä ja sähkö myydään. Toki tässä on vaikka mitä muuttujia, esim. LVV on jo kuuma, joten silloin kaikki menee automatik myyntiin.

Tätä tässä haen, ja osaaminen ei mitenkään riitä tuon automatisointiin.
Ja muutenkin näitä tulee tarkkailtua kokoajan, joten eipä tuota "myyntirajaa" niin iso vaiva ole käsin vaihdella.

 

[tk-]

No ohitin tuon nyt toistaiseksi apex chart kikkailulla.

Ideana tässä on siis, sellainen (hih) manuaalinen automaatio.

Eli tein sellaisen pienen visuaalisen apex chart kortin, josta voin manuaalisesti laskeskella ja pähkäillä, että mitä laittaisin oman LVV:n aurinkoenergian varttinetotus automaation myyntirajaksi.

Eli kun pörssisähkössä aurinkoenergian myynnistä saa pörssisähkön sen hetkisen korvauksen ilman 24% alvia ja sitten taas yöllä jos lämmittelee LVV:tä ostosähköllä, niin siitä taas pitää maksaa pörssin lisäksi verot ja siirtomaksut.

Esim:
Siirtomaksu yöllä 4.19c/kWh sis. verot jne.
Pörssisähkö yöllä 5c/kWh sis verot
--> Yhteensä 9.19c/kWh

Näin päivällä pitäisi siis auringon paistaessa saada verottomasta pörssisähköstä vähintään se 9.2c/kWh,

Jos siis päivällä auringon paistaessa sähkön veroton hinta on vaikka 8c, niin LVV:tä pidellään päällä, kun taas jos sähkön veroton hinta on yli tuon 9.2 c/kWh, niin sitten LVV saa olla pois päältä ja sähkö myydään. Toki tässä on vaikka mitä muuttujia, esim. LVV on jo kuuma, joten silloin kaikki menee automatik myyntiin.

Tätä tässä haen, ja osaaminen ei mitenkään riitä tuon automatisointiin.
Ja muutenkin näitä tulee tarkkailtua kokoajan, joten eipä tuota "myyntirajaa" niin iso vaiva ole käsin vaihdella.

Automaattisesti tuon saisi esimerkiksi Pörssärin avulla ☝ toki siitä menee sitten harrastelun ilo kokonaan pois

 

[heebo1974]

Automaattisesti tuon saisi esimerkiksi Pörssärin avulla ☝ toki siitä menee sitten harrastelun ilo kokonaan pois

Juu ja yksi arvaamaton pilvipalvelu lisää. Ei toki millään pahalla.
Ja ongelmat eivät välttämättä edes johdu pilvestä, vaan omasta nettiyhteydestä.

 

[tk-]

Juu ja yksi arvaamaton pilvipalvelu lisää. Ei toki millään pahalla.
Ja ongelmat eivät välttämättä edes johdu pilvestä, vaan omasta nettiyhteydestä.

No ei kai tuo sen enempää ole pilvipalvelu kun spot-hinnan rajapintakaan. Ei kai sieltäkään hinnat tule ilman nettiyhteyttä? Pörssäristä hintojen sijaan sieltä tulee tietokanta-asetusten perusteella kyselyhetkellä muodostettu json koska laite kytketään päälle ja koska pois. Parin viikon päästä muuttuu aikaleimoihin. Tulisi sieltä ne hinnatkin mukana jos se olisi NordPoolin lisenssiehtojen mukaan sallittua.

Jos ne asetukset olisi paikallisesti tehtynä ja lähetettäisiin url-kyselyn mukana, niin olisiko tuo sitten vähemmän pilvipalvelu? Samallalailla tuo ohjaustieto silloinkin muodostettaisiin.

Mutta kunhan ehdotin, itse rakentamalla saa juuri haluamansa.

 

[heebo1974]

No ei kai tuo sen enempää ole pilvipalvelu kun spot-hinnan rajapintakaan. Ei kai sieltäkään hinnat tule ilman nettiyhteyttä? Pörssäristä hintojen sijaan sieltä tulee tietokanta-asetusten perusteella kyselyhetkellä muodostettu json koska laite kytketään päälle ja koska pois. Parin viikon päästä muuttuu aikaleimoihin. Tulisi sieltä ne hinnatkin mukana jos se olisi NordPoolin lisenssiehtojen mukaan sallittua.

Mutta kunhan ehdotin itse rakentamalla saa juuri haluamansa.

Tottakai avoimin mielin. Ja miksei voisi kokeilla.
Jotenkin vaan, yrittää pysyä mahdollisimman paljon lokaalina. Ja no onhan se pörssäri taas yksi rajapinta lisää.
Joku voisi laskea todennäköisyyksiä ongelmiin, mitä useampi pilvipalvelu on mukana.

Ei siinä pörssäri vaikuttaa todella mielenkiintoiselta. En vaan oikein tiedä miten hyödyntää esim. noita hienoja lämpötilaennusteita tmjs.
Siis jos perus sähkölämmitteinen talo. Muutamat lattialämmöt (etäohjattavia), ikkunoiden alla olevia sähköpattereita (manuaalisia), takka (manuaalinen ), Ilmalämpöpumppu (niin aataminaikanen, ettei mitään etä juttuja), LVV ohjattavissa.

Eli muutamat lattiat ja LVV ainoat, jota pystyn ohjailemaan.

btw.. Miksei pörssäri voi olla locaali lisäosa esim. HA:lle. Miksi se vaatii pilven ?

 

[tk-]

Tottakai avoimin mielin. Ja miksei voisi kokeilla.
Jotenkin vaan, yrittää pysyä mahdollisimman paljon lokaalina. Ja no onhan se pörssäri taas yksi rajapinta lisää.
Joku voisi laskea todennäköisyyksiä ongelmiin, mitä useampi pilvipalvelu on mukana.

Ei siinä pörssäri vaikuttaa todella mielenkiintoiselta. En vaan oikein tiedä miten hyödyntää esim. noita hienoja lämpötilaennusteita tmjs.
Siis jos perus sähkölämmitteinen talo. Muutamat lattialämmöt (etäohjattavia), ikkunoiden alla olevia sähköpattereita (manuaalisia), takka (manuaalinen ), Ilmalämpöpumppu (niin aataminaikanen, ettei mitään etä juttuja), LVV ohjattavissa.

Eli muutamat lattiat ja LVV ainoat, jota pystyn ohjailemaan.

btw.. Miksei pörssäri voi olla locaali lisäosa esim. HA:lle. Miksi se vaatii pilven ?

Tuo ohjauslogiikka on kirjoitettu phplla ja se hakee asetukset tällä hetkellä tietokannasta. Kyllähän tuon periaatteessa voisi tehdä myös pythonilla suoraan Home Assistantiin, mutta ei meidän resurssit riitä ylläpitämään logiikkakoodia sekä asetusliittymää kahdella eri kielellä.

Siksi on helpompi tehdä se ohjauslogiikka tuolla palvelimella, ja sitten asiakaspäässä jää tehtäväksi vain se ohjauksen tekeminen käytäntöön yksinkertaisella päälle/pois -logiikalla. Palvelin ei sammu ainakaan seuraavaan 15 vuoteen, mutta jos sitten niin käy, niin nuo php-koodit laitetaan kyllä jakoon.

Periaatteessa aika pienellä vaivalla olisi tehtävissä semmoinen rajapinta mihin urlin mukana voi lähettää haluamansa ehdot ja saa sitten ohjaukset vastauksena.

Edit: Ja itseasiassa ehkä tärkein syy on se NordPoolin antama lupa palveluun kunhan ei jaeta hintatietoa eteenpäin. Siksi ohjaus on pakko välittää tuntikohtaisena 1/0 ja jatkossa aikaleimoilla.

 

[heebo1974]

Tuo ohjauslogiikka on kirjoitettu phplla ja se hakee asetukset tällä hetkellä tietokannasta. Kyllähän tuon periaatteessa voisi tehdä myös pythonilla suoraan Home Assistantiin, mutta ei meidän resurssit riitä ylläpitämään logiikkakoodia sekä asetusliittymää kahdella eri kielellä.

Siksi on helpompi tehdä se ohjauslogiikka tuolla palvelimella, ja sitten asiakaspäässä jää tehtäväksi vain se ohjauksen tekeminen käytäntöön yksinkertaisella päälle/pois -logiikalla. Palvelin ei sammu ainakaan seuraavaan 15 vuoteen, mutta jos sitten niin käy, niin nuo php-koodit laitetaan kyllä jakoon.

Periaatteessa aika pienellä vaivalla olisi tehtävissä semmoinen rajapinta mihin urlin mukana voi lähettää haluamansa ehdot ja saa sitten ohjaukset vastauksena.

Noniin, ymmärrän jo paremmin ja tämä valaisi asiota jo paljon. Näin se menee, kun ei ole perillä toteutustavoista mitenkään.
Ja en todellakaan ole pörssäriä vastaan tmjs. mitenkään. Itseasiassa saattaa olla, että pitää ehkä kokeilla.

Edit: Ja voihan sitä rinnalle ainakin ottaa testiin.

 

[tk-]

Noniin, ymmärrän jo paremmin ja tämä valaisi asiota jo paljon. Näin se menee, kun ei ole perillä toteutustavoista mitenkään.
Ja en todellakaan ole pörssäriä vastaan tmjs. mitenkään. Itseasiassa saattaa olla, että pitää ehkä kokeilla.

Edit: Ja voihan sitä rinnalle ainakin ottaa testiin.

Joo en minä usko, että kukaan vastaan olisi! Ajattelen ennemmin niin, että aina jos on epätietoisuutta, niin dokumentaatiossa ja omassa ulosannissa on täsmentämisen paikka…

 

[Temez]

Tuohon "Cheapest Period" -asiaan liittyen olen hiukan pohtinut jatkojalostusta, kun HA 2023.07:ssa tuli uusi ominaisuus, että scriptit voivat palauttaa dataa automaatioille.

Tällöin saisi tehtyä SHF-pakettiin valmiin scriptin, jolle voisi kertoa sekä alku- että loppuajan + halutun tuntimäärän ja se palauttaisi sieltä halvimman x tunnin ajanjakson. Jokainen voisi sitten tehdä oman automaationsa ja mahdollisesti useita, että "anna halvin 5 tunnin pätkä sähköauton lataamiseen ja tallenna se helpperiin Start EV Charging" tai "anna halvin 2h illan aikana, jossa pestä pyykkiä".

Jokainen voisi sitten omien tarpeidensa mukaan tehdä 1-N kpl helppereitä ja automaatioita, jotka tiettyyn kellonaikaan laskisivat halvimman halutunpituisen ajanjakson. Tämä vasta ajatuksen tasolla, mutta jospa se tästä koodiksi tulisi jossain vaiheessa.

Heips! Lyhyesti kiireisille; uusi beta-versio tarjolla: https://github.com/T3m3z/spotprices2ha/tree/v0.2.0-draft

Tässä olisi nyt isolta osalta uudelleenkirjoitettu "Beta-versio" pitkän hiljaiselon jälkeen (siviilielämä vaatinut paljon, joten ei ole näihin harrastuksiin oikein ehtinyt). En vielä työntänyt tätä tuonne Github master-haaraan, sillä ajattelin kysäistä hiukan ajatuksia/kommentteja, että vaikuttaako hyvältä teidän mielestänne: https://github.com/T3m3z/spotprices2ha/tree/v0.2.0-draft

Pakettia on kirjoitettu nyt suurelta osin uusiksi, jotta toimisi paremmin (ainakin toivottavasti) esim. talviajan alkaessa. Vähemmän ainakin virheitä tulee logille nyt. Käytön puolesta pitäisi olla aika vähän vaihtunut. Ehkä jotain kuvaajien koodeja joutuu tekemään uudestaan, sillä en ihan 100% taaksepäin yhteensopivuutta voi taata.

Suurin muutos on se, että jatkossa voit kysellä scriptillä kysymyksen "anna halvin 2h yhtäjaksoinen pätkä tänään kello 15 ja 22". Samalla katosi vanha "SHF Cheapest Period Start", jotta ei ole päällekkäisiä ominaisuuksia.

Pikaohjeet tämän käyttöön:
1. Luo uusi aloitusajankohdan helpperi: Settings->Devices&Services->Helpers->Create Helper->"Date and/or time" + valitse "Time".
2. Tee uusi automaatio tämän esimerkin pohjalta (https://github.com/T3m3z/spotprices2ha/blob/v0.2.0-draft/example-of-cheapest-period-automation.yaml). Vaihda entity_id-riville kohdassa 1 luodun helperin ID. määrittele "start", "end" ja "hours"-riveille halutut arvot (today_at('15:00') voi esimerkiksi olla hyvä, lisäesimerkkejä täältä: https://www.home-assistant.io/docs/configuration/templating/#time). Määrittele itse, että milloin tämä automaatio ajetaan eli milloin laskenta tapahtuu.
3. Käytä kohdassa 1 luotua helperiä jonkin automaation triggerinä:

 

[tk-]

Heips!

Tässä olisi nyt isolta osalta uudelleenkirjoitettu "Beta-versio" pitkän hiljaiselon jälkeen (siviilielämä vaatinut paljon, joten ei ole näihin harrastuksiin oikein ehtinyt). En vielä työntänyt tätä tuonne Github master-haaraan, sillä ajattelin kysäistä hiukan ajatuksia/kommentteja, että vaikuttaako hyvältä teidän mielestänne: https://github.com/T3m3z/spotprices2ha/tree/v0.2.0-draft

Pakettia on kirjoitettu nyt suurelta osin uusiksi, jotta toimisi paremmin (ainakin toivottavasti) esim. talviajan alkaessa. Vähemmän ainakin virheitä tulee logille nyt. Käytön puolesta pitäisi olla aika vähän vaihtunut. Ehkä jotain kuvaajien koodeja joutuu tekemään uudestaan, sillä en ihan 100% taaksepäin yhteensopivuutta voi taata.

Suurin muutos on se, että jatkossa voit kysellä scriptillä kysymyksen "anna halvin 2h yhtäjaksoinen pätkä tänään kello 15 ja 22". Samalla katosi vanha "SHF Cheapest Period Start", jotta ei ole päällekkäisiä ominaisuuksia.

Pikaohjeet tämän käyttöön:
1. Luo uusi aloitusajankohdan helpperi: Settings->Devices&Services->Helpers->Create Helper->"Date and/or time" + valitse "Time".
2. Tee uusi automaatio tämän esimerkin pohjalta (https://github.com/T3m3z/spotprices2ha/blob/v0.2.0-draft/example-of-cheapest-period-automation.yaml). Vaihda entity_id-riville kohdassa 1 luodun helperin ID. määrittele "start", "end" ja "hours"-riveille halutut arvot (today_at("15:00") voi esimerkiksi olla hyvä, lisäesimerkkejä täältä: https://www.home-assistant.io/docs/configuration/templating/#time). Määrittele itse, että milloin tämä automaatio ajetaan eli milloin laskenta tapahtuu.
3. Käytä kohdassa 1 luotua helperiä jonkin automaation triggerinä:
katso liitettä 88282

Edelleen ihmettelen miksi hinnat täytyy laittaa tuollaiseen erilliseen attribuutti-dictionaryyn tälle ja huomiselle päivälle, kun periaatteessa ja käytännössäkin niiden lukeminen on aivan yhtä helppoa aikaleiman mukaan siitä spot-hinnan palvelimen muodostamasta jsonista mikä itsessään on tallennettu samaan sensoriin myös.

Vähentää kummasti erilaisia virheen mahdollisuuksia kun ei käytä tuollaista välivaiheen tallennusta ja sen vaatimia lisähelpereitä.

 

[Temez]

Edelleen ihmettelen miksi hinnat täytyy laittaa tuollaiseen erilliseen attribuutti-dictionaryyn tälle ja huomiselle päivälle, kun periaatteessa ja käytännössäkin niiden lukeminen on aivan yhtä helppoa aikaleiman mukaan siitä spot-hinnan palvelimen muodostamasta jsonista mikä itsessään on tallennettu samaan sensoriin myös.

Vähentää kummasti erilaisia virheen mahdollisuuksia kun ei käytä tuollaista välivaiheen tallennusta ja sen vaatimia lisähelpereitä.

Alunperin hinnat tuli tallennettua sensorin attribuutteihin listana, koska Nordpool custom_componentissa (https://github.com/custom-components/nordpool) oli laitettu tuollaiset päiväkohtaiset "tänään/huomenna"-listat hinnoista sensorin attribuuteissa. Jos nyt siis näihin viittasit. Ajatuksena oli se, että siirtyminen olisi helpompaa tarvittaessa suuntaan tai toiseen. Tämä minun tekemä kikkareeni syntyi alunperin siitä, kun erilaisissa keskusteluissa oli valitettu Nordpool-integraation asentamisen vaikeutta.

Tässä versiossa 0.2.0 pääosa ellei kaikki menee jo niin, että se käyttää Jinjan selectattr-filtteriä hakeakseen haluamiaan tuloksia, jolloin nuo floatteja sisältävät arrayt ovat vain yhteensopivuuden vuoksi jäljellä.

Välissä on toinen sensori vielä siksi, että jos netti on alhaalla ja tulee hakuhetki rest-sensorille, niin se menee tilaan unavailable ja loppupäivän hintatiedot katoavat. Siksi tässä versiossa sensor.shf_data toimii "välimuistina".

Eihän tämä mikään eleganttiuden ja estetiikan riemuvoitto ole. Tämä on monen asian osalta kompromissi, joka muodostui kokeilun kautta. Designin taustalla vaikuttavia tekijöitä olivat: A) yksi tiedosto (tällä hetkellä ~300 riviä), joka helppo laittaa paikalleen, B) käyttää HomeAssistantin perussettiin kuuluvaa Restful-sensoria tiedonlataukseen, jotta sitä ei tarvitse keksiä uudelleen, C) ei olisi yhtä raskas ylläpitää kuin "oikea" integraatio (no, tästä en tiedä, että toteutuiko vai ei) ja D) olla semmoinen paketti, jota voi lämmitysharrastelija jatkojalostaa "suhteellisen" helposti ilman, että täytyy olla täysverinen Python-koodari (esimerkkinä täällä nähdyt notax-lisäykset).

EDIT: lisätään vielä E) eli mahdollisimman vähän hakuja per päivä = HomeAssistant säilöö dataa, jotta pärjätään mahdollisten nettikatkojen yli. Tämä palikka syntyi kuitenkin aikana, jolloin ei tiedetty, että tuleeko kiertäviä sähkökatkoja vai ei ja tuolloin oli ainakin osittain epävarmaa, että miten tietoliikenne sitten toimii.

EDIT2: kylläpäs muisti palailee pätkittäin, lisätään vielä F) valmis setti erilaisia antureita ja hintarajasysteemejä sun muita, jotta aloitteleva harrastaja saa nopeasti aikaan jotain.

 

[Temez]

Ainiin ja onhan tuossa tosiaan niitä ominaisuuksia, että pystyy lisäämään yösähkölle eri hinnat kuin päivälle. Siksi data käsitellään kertaalleen läpi ja talletetaan sensorin attribuuttiin, jotta sinne saadaan kokonaishinta. Saman toki saisi Mikkin API:sta helposti myös parametreilla.

 

[tk-]

Alunperin hinnat tuli tallennettua sensorin attribuutteihin listana, koska Nordpool custom_componentissa (https://github.com/custom-components/nordpool) oli laitettu tuollaiset päiväkohtaiset "tänään/huomenna"-listat hinnoista sensorin attribuuteissa. Jos nyt siis näihin viittasit. Ajatuksena oli se, että siirtyminen olisi helpompaa tarvittaessa suuntaan tai toiseen. Tämä minun tekemä kikkareeni syntyi alunperin siitä, kun erilaisissa keskusteluissa oli valitettu Nordpool-integraation asentamisen vaikeutta.

Tässä versiossa 0.2.0 pääosa ellei kaikki menee jo niin, että se käyttää Jinjan selectattr-filtteriä hakeakseen haluamiaan tuloksia, jolloin nuo floatteja sisältävät arrayt ovat vain yhteensopivuuden vuoksi jäljellä.

Välissä on toinen sensori vielä siksi, että jos netti on alhaalla ja tulee hakuhetki rest-sensorille, niin se menee tilaan unavailable ja loppupäivän hintatiedot katoavat. Siksi tässä versiossa sensor.shf_data toimii "välimuistina".

Eihän tämä mikään eleganttiuden ja estetiikan riemuvoitto ole. Tämä on monen asian osalta kompromissi, joka muodostui kokeilun kautta. Designin taustalla vaikuttavia tekijöitä olivat: A) yksi tiedosto (tällä hetkellä ~300 riviä), joka helppo laittaa paikalleen, B) käyttää HomeAssistantin perussettiin kuuluvaa Restful-sensoria tiedonlataukseen, jotta sitä ei tarvitse keksiä uudelleen, C) ei olisi yhtä raskas ylläpitää kuin "oikea" integraatio (no, tästä en tiedä, että toteutuiko vai ei) ja D) olla semmoinen paketti, jota voi lämmitysharrastelija jatkojalostaa "suhteellisen" helposti ilman, että täytyy olla täysverinen Python-koodari (esimerkkinä täällä nähdyt notax-lisäykset).

EDIT: lisätään vielä E) eli mahdollisimman vähän hakuja per päivä = HomeAssistant säilöö dataa, jotta pärjätään mahdollisten nettikatkojen yli. Tämä palikka syntyi kuitenkin aikana, jolloin ei tiedetty, että tuleeko kiertäviä sähkökatkoja vai ei ja tuolloin oli ainakin osittain epävarmaa, että miten tietoliikenne sitten toimii.

EDIT2: kylläpäs muisti palailee pätkittäin, lisätään vielä F) valmis setti erilaisia antureita ja hintarajasysteemejä sun muita, jotta aloitteleva harrastaja saa nopeasti aikaan jotain.

Nuo selectattr-filtterit on kyllä todella elegantti tapa hakea tietoa noista attribuuteista!

Lähinnä meinasin vaan sitä, että kun ne säilötään nimenomaan tuohon hintasensorin attribuutteihin mikä on taas sitten pohjana kaikelle muulle. Tietyllä tapaa se selkeyttää toimintaa, mutta siinä on riskinä se, että jos syystä tai toisesta yhdenkin attribuutin teko epäonnistuu, niin koko paketti lakkaa toimimasta.

Siksi itse mietin, että onko toimintavarmempi niin, että niille lasketuilla attribuuteille olisi mieluummin kaikille vaan oma sensorinsa. Toki se tekee taas sitten koodista monimutkaisempaa.

HA:n kanssa nämä kompromissit on kyllä aina jonkinmoinen haaste. Josko nyt mikään ei vähään aikaan muuttuisi taustalla…

 

[Temez]

Nuo selectattr-filtterit on kyllä todella elegantti tapa hakea tietoa noista attribuuteista!

Lähinnä meinasin vaan sitä, että kun ne säilötään nimenomaan tuohon hintasensorin attribuutteihin mikä on taas sitten pohjana kaikelle muulle. Tietyllä tapaa se selkeyttää toimintaa, mutta siinä on riskinä se, että jos syystä tai toisesta yhdenkin attribuutin teko epäonnistuu, niin koko paketti lakkaa toimimasta.

Siksi itse mietin, että onko toimintavarmempi niin, että niille lasketuilla attribuuteille olisi mieluummin kaikille vaan oma sensorinsa. Toki se tekee taas sitten koodista monimutkaisempaa.

HA:n kanssa nämä kompromissit on kyllä aina jonkinmoinen haaste. Josko nyt mikään ei vähään aikaan muuttuisi taustalla…

Ah joo. Eli tarkoitat ristiriippuvuuksien poistoa vähentämällä ketjutusta, jolloin tulisi "puun oksien ja haarojen" sijaan enemmän tähtimäinen kuvio haut suorittavasta Restful-sensorista ulospäin?

 

[tk-]

Ah joo. Eli tarkoitat ristiriippuvuuksien poistoa vähentämällä ketjutusta, jolloin tulisi "puun oksien ja haarojen" sijaan enemmän tähtimäinen kuvio haut suorittavasta Restful-sensorista ulospäin?

Joo juuri niin! Ja toki en osannut lukea tuota koodia niin hyvin, että siinä oli "Legacya" joukossa ja nuo hintasensorit toimii nykyään tuon filtterin avulla suoraan siitä data-jsonista mikä haetaan.

Sitä mietin, että toimisiko noiden custom-hintojen kanssa semmoinen mitä tuolla Pörssärin serverilläkin käytetään, että luotaisiin tunti-offset niiden tariffien ja miksei spot-marginaalinkin avulla? Silloin ei tarvitsisi tallettaa noita hintojakaan uudelleen, vaan lisäisi vaan sen kyseisen tunnin offsetin aina kuluvan tunnin hintaan. Se offset-attribuutti voisi kuitenkin olla tuollainen 24 hinnan array, se ei haittaisi kelloja kääntäessäkään. Kausitariffikin menee tarvittaessa kahdella eri offsetillä, eli toista luetaan jos ei ole talviarkipäivä ja toista muulloin.

 

[Pretor]

Suurin muutos on se, että jatkossa voit kysellä scriptillä kysymyksen "anna halvin 2h yhtäjaksoinen pätkä tänään kello 15 ja 22". Samalla katosi vanha "SHF Cheapest Period Start", jotta ei ole päällekkäisiä ominaisuuksia.

Ei ole noiden helpereiden kanssa tullut tehtyä tuttavuutta ja näin illasta pää ihan tyhjä muutenkin, mutta onnistuuko nyt siis tehdä esim. kaksi eri helperiä tyyliin yölle omat ja päivälle omat halvimmat x-tunnin jaksot?

 

[Mikki]

Ei ole noiden helpereiden kanssa tullut tehtyä tuttavuutta ja näin illasta pää ihan tyhjä muutenkin, mutta onnistuuko nyt siis tehdä esim. kaksi eri helperiä tyyliin yölle omat ja päivälle omat halvimmat x-tunnin jaksot?

Mitä muuten ohjaatte kun pitää olla useita peräkkäisiä tunteja? Noin ei saa optimaalisinta ohjausta.... kohtahan tulee eteen, että tuntikin on pitkä aika kun hinta vaihtuu varteittain.

 

[Pretor]

Mitä muuten ohjaatte kun pitää olla useita peräkkäisiä tunteja? Noin ei saa optimaalisinta ohjausta.... kohtahan tulee eteen, että tuntikin on pitkä aika kun hinta vaihtuu varteittain.

Lämminvesivaraajalle riittää ne yön halvat pari tuntia, mutta lisäks tällä hetkellä on testissä ollut ajaa 500l varaaja 20'c ylilämpöön yöllä. Kunhan tässä ilmat vielä kylmenee ja lämmityskierto lähtee päälle, niin eihän tuo 1x/pv riitä. Suihkuttelutkin (puu)saunan ohessa kun osuu yleensä niihin illan kalleimpien hetkiin, niin normaalitilanteessa myös VILP käynnistyy automaattisesti, kun varaaja viilenee esilämmityskierukoiden takia.

Kunhan saisi aikaiseksi, niin pitäisi yrittää askarrella testiin control factorin avustuksella muuttuva lämmityspyynti ja katsoa miten se kylmillä keleillä toimisi.
Tällaisina tasaisesti erittäin halvan sähkön päivinä sekin tosin näyttää toimivan vähän hassusti +-5'c pyynnillä, kun testigraafia ajelen.

 

[-Teme-]

Iso kiitos Temezille paketin tekemisestä. Pitää tsekata tuota uutta versiota ja mahdollisesti siitä taas poimia herkut matkaan.
Pidän suuresti tuosta rakenteesta jossa sensorit mukavasti eriytetty ja valmisteltu wannabe koodereille.
Paketin koodia hyväksi käyttäen olen rakentanut jokaiselle 11 (sähkö)lattialämmitys alueelle oman ohjauspaketin joilla niitä ohjataan yksilöllisesti.

Ainoa mitä olen jäänyt kaipaamaan on buyMeCoffee linkki

Seuraava vaihe jota pitää miettiä on 15min intervallit ohjauksiin, sekä lämmitysalueiden priorisointiluokitus

 

[Temez]

Ei ole noiden helpereiden kanssa tullut tehtyä tuttavuutta ja näin illasta pää ihan tyhjä muutenkin, mutta onnistuuko nyt siis tehdä esim. kaksi eri helperiä tyyliin yölle omat ja päivälle omat halvimmat x-tunnin jaksot?

Joo, kyllä. Ja voit sitten tuolla laskennan käynnistävän automaation ajohetkellä vaikuttaa siihen, että milloin haluat laskennan suoritettavan. Vaikkapa, että töistä kotiin tullessa (esim. puhelimen sijainnin perusteella?) anna halvin 2h pätkä ajanhetkien nyt ja kello 21 välillä. Käyttötapaus voisi olla vaikkapa ilmoitus puhelimeen siitä, että "pyykinpesu halvinta kello 18 alkaen".

 

[Temez]

Mitä muuten ohjaatte kun pitää olla useita peräkkäisiä tunteja? Noin ei saa optimaalisinta ohjausta.... kohtahan tulee eteen, että tuntikin on pitkä aika kun hinta vaihtuu varteittain.

En itse tätä ominaisuutta käytä, mutta muistaakseni alun perin toiminnallisuuden kehittämisen taustalla olivat laitteet, joiden käynnistämisen jälkeen menee x tuntia aikaa jonkin toimenpiteen valmistumiseen. Itsellä on puoliälykäs pyykinpesukone, joka osaa jatkaa ohjelmaa sähkökatkoksen jälkeen. Sen voisi pistorasiareleellä tehdä sellaiseksi, että 1) lataa kone täyteen, 2) käynnistä ohjelma, 3) rele katkaisee sähköt, 4) sähköt kytketään takaisin päälle, kun halvin 2h pätkä saapuu.

Lämmityksen ohjaukseen tuo ei toki ole mikään paras, koska halvin "pätkä" ei välttämättä ole vuorokauden halvimmat x tuntia. Ja muutenkin varmaan monella se lämmitys on merkittävästi isompi kuluttaja kuin mitä esim. pyykinpesukoneet.

 

[Temez]

Kunhan saisi aikaiseksi, niin pitäisi yrittää askarrella testiin control factorin avustuksella muuttuva lämmityspyynti ja katsoa miten se kylmillä keleillä toimisi.
Tällaisina tasaisesti erittäin halvan sähkön päivinä sekin tosin näyttää toimivan vähän hassusti +-5'c pyynnillä, kun testigraafia ajelen.

Joo, tämä on kyllä totta, että tuo toimii hassusti. En valitettavasti toteutusta tehdessä tuolloin ollut syventynyt asiaan riittävästi ja tämmöinen naiivi ohjaus nyt sattui ekana tulemaan mieleen (mentaliteetilla: "edes jotain on parempi kuin ei mitään", jotta myös aloitteleva harrastelija pääsisi alkuun). Foorumilla on puhuttu keskihajontaan liittyvästä ohjauksesta, joka voisi olla parempi. Jos jollakulla on tästä hyvä idea, niin voi laittaa Githubiin Pull Requestia.

 

[Temez]

Oma lämmitysoptimointiprojekti on ottanut tässä harppauksia eteenpäin. Koetan paikallisesti HomeAssistantissa laskea lämmitystarvetta päivittäin ~pörssihintojen saapuessa ja päätellä, että millä lämmönlähteellä ja mihin aikaan päästäisiin täyttämään energiantarpeet halvimmalla. Meni hetken aikaa kerätessä taustalle dataa, että sai laskeskeltua talon lämpökapasiteetin ja ihmisten sekä auringon keskimääräiset vaikutukset. Vielä pitäisi tehdä viimeiset automaatiosäännöt, että laskentatulos alkaisi vaikuttaa lattialämmityksen ohjaukseen automaattisesti, mutta aika lähellä ollaan.

Harmillisesti vaan näemmä Ilmatieteen laitoksen lämpötilaennuste (violetta käyrä) heittää jonkin verran sitten toteutuneeseen. Mutta talon keskilämpötila pysyi esimerkiksi viime yönä 21-7 aikavälillä 0,1 asteen päässä arvioidusta.

Kuvaajassa:

• Violetti viiva: FMI:n lämpötilaennuste
• Oranssi viiva: ulkolämpötila, oma mittaus
• Sininen viiva: arvioitu kulutus kWh per tunti (, josta vähennetty arvioitu hupisähkön ja auringon tuottama lämpö)
• Punainen viiva: auringon säteilyteho W/m2, joka vähennetään sopivalla kertoimella lämmitystarpeesta
• Palkit: poistoilmalämpöpumpun ohjaus halvimmille ajankohdille. Käytännössä nostaa lämpötilapyyntiä, jotta PILP pysyy palkkien ajankohdilla pyörimässä ja laskee sitä muina aikoina (+tulee säätämään jatkossa myös sitten vastuksien käyttöä). Lämmitysjärjestelmän sisälämpötilamittari pitää huolen, ettei talo sähellyksieni vuoksi pääse kuitenkaan jäätymään.

Laskenta sitten myös pyytää lämmittämään polttopuilla, jos sähkön hinta alkaa nousta eikä vastuksilla lämpöä saada "kilpailukykyiseen" hintaan.

Harrastusviilattavaa löytyy vielä aivan varmasti, sillä tämä on nyt "hintaoptimoitu", mutta todennäköisesti ei "mukavuusoptimoitu". Pitänee sitten kokemuksien mukaan tuoda sitä mukavuuden tunnetta vielä mukaan syksyllä/alkutalvesta.

 

[Smuli]

Onko niin että tuo SHF halvat tunnit ei tunnista noita miinukselle meneviä tunteja kun nyt on taas niin että halvimmat tunnit liipaisu taphtui kun hinta palasi plussalle?

 

[Temez]

Onko niin että tuo SHF halvat tunnit ei tunnista noita miinukselle meneviä tunteja kun nyt on taas niin että halvimmat tunnit liipaisu taphtui kun hinta palasi plussalle?

Pitääpäs tutkaista. Mutta kerrotko ensin, että mikä versio tästä paketista sinulla on käytössä (lukee spot-price.yaml tiedoston alussa) ja että mikä sensori tarkalleen on se, joka aiheuttaa ongelmia.

EDIT: ja ehkä vielä jos on antaa tietoa siitä automaatiosta, jossa koetat tätä käyttää. Ajatuksena siis se, että jos tässä on jotain vikaa, niin päästään puolin ja toisin mahdollisimman nopeasti kärryille. Kuvankaappaukset käyvät myös.

 

[Smuli]

Pitääpäs tutkaista. Mutta kerrotko ensin, että mikä versio tästä paketista sinulla on käytössä (lukee spot-price.yaml tiedoston alussa) ja että mikä sensori tarkalleen on se, joka aiheuttaa ongelmia.

EDIT: ja ehkä vielä jos on antaa tietoa siitä automaatiosta, jossa koetat tätä käyttää. Ajatuksena siis se, että jos tässä on jotain vikaa, niin päästään puolin ja toisin mahdollisimman nopeasti kärryille. Kuvankaappaukset käyvät myös.

Versio on 0.1.10

Mulla tuo ohjaa kahta shellyä.

Luulin että tuo cheapest period start hyppää taas yöllä mukaan tähän päivään, mutta se on edelleen eilisellä. Viime yönä se ei ole ottanut noita halvimpia olleenkaan ohjaukseen. Ja eilen aamulla kun tosiaan katsoin niin start oli ajoitettu tunnille jolloin oli ensimmäinen +merkkinen hinta tunnilla.

Ja eilen klo 15 kun automaatio meni päälle niin vielä 19:45 se ei ollut sammunut vaikka sen olisi pitänyt klo 19 sammua. Lokikirjasta ei myöskään löytynyt tietoa että olisi katkaissut automaation.

Tuo on joskus aiemminkin tehnyt saman että se ottaa tuon klo 15 tuonne, mutta yleensä se on kyllä viimeistään yöllä hypännyt taas oikeaan.

HA on nyt päivitetty 9.1 versioon. Mutta tämä oli 8.4 versiollakin näin.

 

[Temez]

Luulin että tuo cheapest period start hyppää taas yöllä mukaan tähän päivään, mutta se on edelleen eilisellä. Viime yönä se ei ole ottanut noita halvimpia olleenkaan ohjaukseen. Ja eilen aamulla kun tosiaan katsoin niin start oli ajoitettu tunnille jolloin oli ensimmäinen +merkkinen hinta tunnilla.

Tuo on joskus aiemminkin tehnyt saman että se ottaa tuon klo 15 tuonne, mutta yleensä se on kyllä viimeistään yöllä hypännyt taas oikeaan.

Kiitos infoista. Tuo kyseinen sensori ei tullut omaan käyttööni, joten sen toiminta on jäänyt vähälle seuraamiselle. Sen olisi tarkoitus laskea halvin pätkän tänään kello 15-huominen kello 14:59 välillä (eli pörssihintojen saavuttua päivittäin). Ajatuksena oli se, että joskus halvin yhtäjaksoinen pätkä saattaa alkaa yöllä ennen vuorokausirajan alkamista. Esim. eilen hintatietojen tullessa 10.9. 15:00 - 11.9. 14:59 välillä halvin hetki alkoi tosiaan jo eilen kello 15:00, mikä on siis version 0.1.10 logiikalla ihan koodaamani mukaista. Tosin vuorokausirajan ylittyessä tuon ei pitäisi pomppia, joten siinä lienee jokin vika.

Ja eilen klo 15 kun automaatio meni päälle niin vielä 19:45 se ei ollut sammunut vaikka sen olisi pitänyt klo 19 sammua. Lokikirjasta ei myöskään löytynyt tietoa että olisi katkaissut automaation.

Tämä paketti ei tuota tällä hetkellä sammutusajankohtaa. Eli sinun tulisi tehdä jokin automaatio, joka hoitaa sen poiskytkennän.

Olen tosin muuttamassa pakettia niin, että tuota kyseistä sensoria ei enää jatkossa olisi olemassakaan oletuksena. Tarkoituksena olisi mahdollistaa se, että jokainen voisi itse kontrolloida sitä, että milloin halvin ajanjakso lasketaan ja että miltä aikaväliltä. Eli voisit kokeilla tästä alla mainitusta postauksesta löytyvää draftia versiosta 0.2.0, jota muutenkin tehty virheensietoisemmaksi. Ajatuksena se, että tällöin voi myös jokainen luoda useita eri halvimman ajan pätkiä. Voisit siis tehdä "SHF Cheapest Period Start" -helperiä vastaavan helperin itse ja sitten vaikkapa kello 18 käynnistyvällä automaatiolla laskea seuraavan vuorokauden halvimman yhtäkestoisen 4h pätkän.

Heips! Lyhyesti kiireisille; uusi beta-versio tarjolla: https://github.com/T3m3z/spotprices2ha/tree/v0.2.0-draft
.....
Suurin muutos on se, että jatkossa voit kysellä scriptillä kysymyksen "anna halvin 2h yhtäjaksoinen pätkä tänään kello 15 ja 22". Samalla katosi vanha "SHF Cheapest Period Start", jotta ei ole päällekkäisiä ominaisuuksia.

EDIT: ohjeet tämän tekemiseen löytyvät postista #531 ja löytyy myös klikkaamalla ylläolevaa lainausta.

 

[Temez]

Yleinen kysymys: sattuuko kenties kenelläkään vielä olemaan käyttökokemuksia kerrottavaksi tästä v0.2.0:sta?

 

[Smuli]

Joo no nyt kun tosiaan sain aamukahvit naamaan ja koneen käymään niin joo se sammutus tulee HA:n automaatiosta 4h. Pitää kurkata miksi se ei katkaissut.

Mahtaako muuten olla niin että kun yritin tehdä eräälle laitteelle sammutus automaatiota ja latasin pelkän yamalin uudelleen niin se aloittaa alusta noi 4h laskurit jos vaikka 3h kohdalla lyö reload?

HA:n reboot ei tunnu vaikuttavan noiden toimintaan, palaavat aina bootin jälkeen järkiinsä, ainakaan en ole huomannut ongelmia.

 

[Temez]

Mahtaako muuten olla niin että kun yritin tehdä eräälle laitteelle sammutus automaatiota ja latasin pelkän yamalin uudelleen niin se aloittaa alusta noi 4h laskurit jos vaikka 3h kohdalla lyö reload?

Vaikea ihan varmaksi sanoa. Ainakin silloin aiempi suoritus katkaistaan, jos editoi sitä kyseistä automaatiota. Eli "Wait for time to pass (delay)"/delay voi olla vaarallinen tässä mielessä. Vaihtoehto voisi siis olla tallentaa helperiin haluttu lopetusajankohta ja sitten käynnistää sen perusteella toinen automaatio. Tällöin automaatiot olisivat päällä minimaalisen ajan ja toimisivat myös reboottien/vastaavien aikana normaalisti.

Kokeilin pikaisesti, niin käynnissä oleva automaatio tuntui selviävän hengissä, jos valitsi "Reload Automations" tai jos laittoi asetuksista "Quick Reload - Load new YAML configuration without a restart". Sen sijaan HomeAssistantin uudelleenkäynnistyksen yhteydessä tai sen kyseisen automaation sisältöä editoitaessa käynnissä oleva automaatio meni "cancellediksi". Sitä en kokeillut, että mitä tapahtuu, jos koko palvelimen käynnistää uudelleen.

Restartissa jopa lukee, että katkaisee kaikkea ajossa olevaa:

 

[Pretor]

Heips! Lyhyesti kiireisille; uusi beta-versio tarjolla: https://github.com/T3m3z/spotprices2ha/tree/v0.2.0-draft


Pikaohjeet tämän käyttöön:
1. Luo uusi aloitusajankohdan helpperi: Settings->Devices&Services->Helpers->Create Helper->"Date and/or time" + valitse "Time".
2. Tee uusi automaatio tämän esimerkin pohjalta (https://github.com/T3m3z/spotprices2ha/blob/v0.2.0-draft/example-of-cheapest-period-automation.yaml). Vaihda entity_id-riville kohdassa 1 luodun helperin ID. määrittele "start", "end" ja "hours"-riveille halutut arvot (today_at("15:00") voi esimerkiksi olla hyvä, lisäesimerkkejä täältä: https://www.home-assistant.io/docs/configuration/templating/#time). Määrittele itse, että milloin tämä automaatio ajetaan eli milloin laskenta tapahtuu.
3. Käytä kohdassa 1 luotua helperiä jonkin automaation triggerinä:

Kylläpä tuli taas hetken päätä hakattua seinään, kun ei luonnistunut automaation teko.
Vika oli tuossa pikaohjeessa

määrittele "start", "end" ja "hours"-riveille halutut arvot (today_at("15:00")

kun pitäisi olla muodossa

(today_at('15:00')

eli pitää korvata "-merkit '-merkillä.

Näyttää siis tältä omissa testeissä:

alias: SHF-testi2
description: ""
trigger:
  - platform: time
    at: "15:00:00"
condition: []
action:
  - service: script.cheapest_hours
    data:
      start: "{{ today_at('23:00') }}"
      stop: "{{ today_at('23:00') + timedelta(hours=7)}}"
      hours: 3
    response_variable: result
  - service: input_datetime.set_datetime
    data:
      timestamp: "{{ result['start'] }}"
    target:
      entity_id: input_datetime.shf_halvat_tunnit_23_06
mode: single

 

[Temez]

Kylläpä tuli taas hetken päätä hakattua seinään, kun ei luonnistunut automaation teko.
Vika oli tuossa pikaohjeessa

Pahoittelut. En pääse enää viestiä muokkaamaan. Sait ilmeisesti toimimaan lopulta? Ainakin oikealta tulokselta näyttää.

Kokeilin huvikseni, niin automaatioeditori käyttöliittymän kautta näemmä korvaa noita merkkejä ja saa homman hajoamaan. En tullut edes ajatelleeksi tuollaista, kun yamlia suoraan tiedostoon kirjoittaessa ei ole tuntunut olevan hipsujen määrillä väliä. Pitipä ihan tarkistaa ja on niissä eroa (mutta suurimman hikan taisi tehdä HomeAssistantin automaatioeditori) (lähde):

 

[Pretor]

Pahoittelut. En pääse enää viestiä muokkaamaan. Sait ilmeisesti toimimaan lopulta? Ainakin oikealta tulokselta näyttää.

Ei se mitään, rapatessa roiskuu. Kun ei itsellä ole sen kummmemmin muuta pintaa tähän hommaan, kuin copy-pastea ja kokeile -> muuta jotain ja kokeile, niin ei se aina helppoa ole saada jotain toimimaan. Sikäli kuvaohjeet toimii tumpelollekin paremmin.

Mutta kyllä tässä nyt pystyy rakentelemaan vähän eri tavalla päivän mittaan automaatioita tuon pohjalta, joten ihan hyvä uudistus, vaikka joutuukin vähän näkemään nyt itse enemmän vaivaa asioiden eteen, kun ei olekaan kaikki valmiina.

Aika erilaiselta näyttää eri aikoihin ajoitettuina variaatioina:

 

[Temez]

katso liitettä 88366

Jos sopii kysäistä, niin mihin muuten käytät näitä 3h pätkiä? Lämmität jotain vai millaista automaatiota? Mikki aiemmin pohti (ihan syystä minusta) näiden "halvin yhtäjaksoinen pätkä"-laskentojen mielekkyyttä, joten kaikki käyttökokemukset kiinnostavat.

 

[Pretor]

Jos sopii kysäistä, niin mihin muuten käytät näitä 3h pätkiä? Lämmität jotain vai millaista automaatiota? Mikki aiemmin pohti (ihan syystä minusta) näiden "halvin yhtäjaksoinen pätkä"-laskentojen mielekkyyttä, joten kaikki käyttökokemukset kiinnostavat.

Tällä hetkellä näin:

Lämminvesivaraajalle riittää ne yön halvat pari tuntia, mutta lisäks tällä hetkellä on testissä ollut ajaa 500l varaaja 20'c ylilämpöön yöllä. Kunhan tässä ilmat vielä kylmenee ja lämmityskierto lähtee päälle, niin eihän tuo 1x/pv riitä. Suihkuttelutkin (puu)saunan ohessa kun osuu yleensä niihin illan kalleimpien hetkiin, niin normaalitilanteessa myös VILP käynnistyy automaattisesti, kun varaaja viilenee esilämmityskierukoiden takia.

Kunhan saisi aikaiseksi, niin pitäisi yrittää askarrella testiin control factorin avustuksella muuttuva lämmityspyynti ja katsoa miten se kylmillä keleillä toimisi.
Tällaisina tasaisesti erittäin halvan sähkön päivinä sekin tosin näyttää toimivan vähän hassusti +-5'c pyynnillä, kun testigraafia ajelen.

Nuo on vasta ihan testin vuoksi tehtynä.
Jos noita 500l varaajan ylilämmityshetkiä päivän mittaan lisää ilmojen kylmetessä, niin kyllä tuohon riittää 2h jaksokin ja syklistä riippuen jopa 1h. Teen vaan valmiiksi noita, jotta vähän näkee miten noi käyttäytyy päivän mittaan ja voi sitten kokeilla eri variaatioita, kun lämmitystarve on isompi. Vaihtoehtona myös se SHF-rank mukaan ohjailu.
Itse asiassa myös pyykinpesu+astianpesukoneen molempien pesuohjelmat on sen noin 2.5h. Tosin ne ei ole millään tavoin automatisoituina.

 

[jalih]

mihin muuten käytät näitä 3h pätkiä? Lämmität jotain vai millaista automaatiota? Mikki aiemmin pohti (ihan syystä minusta) näiden "halvin yhtäjaksoinen pätkä"-laskentojen mielekkyyttä, joten kaikki käyttökokemukset kiinnostavat.

Yleensähän nuo vuorokauden halvimmat tunnit ovat peräkkäin, joten miksi ei olisi mielekästä lämmittää esimerkiksi lämminvesivaraajaa muutamalla vuorokauden halvimmalla peräkkäisellä tunnilla?

 

[hemaris]

Jos sopii kysäistä, niin mihin muuten käytät näitä 3h pätkiä? Lämmität jotain vai millaista automaatiota? Mikki aiemmin pohti (ihan syystä minusta) näiden "halvin yhtäjaksoinen pätkä"-laskentojen mielekkyyttä, joten kaikki käyttökokemukset kiinnostavat.

Itse olen käyttänyt kosteiden tilojen laatan lämmitykseen aamun halpoja tunteja, jolloin nostan lämpötilapyyntöä parilla asteella. Tähän menee kolmisen tuntia jonka jälkeen lämpötila nousee vielä yhden asteen pyyntilämpötilan saavuttamisen jälkeen. Lisäksi kalleimmille tunneille olen laittanut lämpötilapyynnin pudotuksen. Lattiaan saa varattua aika hyvin lämpöä ja menee noin 6-9 hr ennen kuin on tarvetta lämmittää uudestaan. Koska tulee normaalisti käytyä suihkussa aamulla, tulee aamuyön lämmityksestä bonuksena nopeampi lattioiden kuivaus. Talveksi olen siirtymässä pörssisähköön ja sitä varten olen ajatellut käyttää lämpötilan nostoa muutenkin kuin aamuisin

 

[-Teme-]

Yleinen kysymys: sattuuko kenties kenelläkään vielä olemaan käyttökokemuksia kerrottavaksi tästä v0.2.0:sta?

Sain tuon v.0.2.0 asennettua muokattua että toimii tuon edellisen kanssa rinnan (sensorit lisätty v2 syntaxilla)

Ensimmäinen huomio oli että none type errorit jääneet pois
Toinen oli että käytin edellisen version input_number slidereitä, niin "shf_prices_slider" oli muuttanut muotoa -> "shf_price_slider" joka oli helppo korjata
Lisäsin "SHF Price and Rank acceptable" option, koska se itsellä useassa paikassa käytössä

Ensivaikutelmat hyvät ja arvot näyttää seuraavan rinnan tuon vanhemman version kanssa.
Tuo ohjaa yhtä testi shellyä joka simuloi lattialämmitystermaria

Sellainen kehityspläni että oisko iso duuni kehittää Cheapest period esim klo 18-18 välille? Tällöin pystyisi tekemään plänit seuraavaan päivään esim paneelien tuoton jälkeen, sekä muokkaamaan lämmitystarvetta yhdessä 2023.9 mukana tullutta weather.get_forecast palvelun avulla

Käytössä on sähköllä toimiva osittain varaava lattialämmitys, joiden termostaatteja ohjaan yksilöllisesti. Käytännössä pilkkonut rank & price sensorit, sekä niille sliderit jokaiselle 11 erilliselle lämmitysalueelle omanaan ja on siellä +- factor myös jokaiselle. Nämä sitten includataan omana paketteina, mutta käyttävät yhteistä rest hakua, price_now ja rank_now jotka käytännössä jäljellä alkuperäisestä paketista