Hmm.."Temezin lisäosa" ?
Riittäisikö NordPool koodi configuration.yaml
price_in_cents: false
nordpool:
Viimeksi muokattu:
HomeAssistant ja sähköpörssiohjaus
- Viestiketjun aloittaja Temez
- Aloituspäivämäärä
-
- Tunnisteet
- homeassistant kotiautomaatio nordpool pörssisähkö
Riittäisikö NordPool koodi configuration.yaml
price_in_cents: false
nordpool:
Taitaa olla Temezin YAML jo ohittanut monella tavalla Nordpool integraation aikaa sitten.
GitHub - T3m3z/spotprices2ha: Simple copy-paste approach to fetch data from api.spot-hinta.fi (see https://spot-hinta.fi) to Home Assistant. Includes simple sensors and UI elements to ease automation work.
Simple copy-paste approach to fetch data from api.spot-hinta.fi (see https://spot-hinta.fi) to Home Assistant. Includes simple sensors and UI elements to ease automation work. - T3m3z/spotprices2ha
github.com
Hianoa...itse aloittelin Home Assistantin kanssa. En ole kaikkeen perehtynyt.Taitaa olla Temezin YAML jo ohittanut monella tavalla Nordpool integraation aikaa sitten.
GitHub - T3m3z/spotprices2ha: Simple copy-paste approach to fetch data from api.spot-hinta.fi (see https://spot-hinta.fi) to Home Assistant. Includes simple sensors and UI elements to ease automation work.
Simple copy-paste approach to fetch data from api.spot-hinta.fi (see https://spot-hinta.fi) to Home Assistant. Includes simple sensors and UI elements to ease automation work. - T3m3z/spotprices2ha
Kokillaan tuotaa seuraavaksi..
Ei taida olla tosiaan noista kirjoitettu. Mutta koetetaanpa tässä nyt jotain vinkkiä antaa. Helpointa lienee parametrien ymmärtämiseen nähdä, että mitä ne tekevät. Eli seuraa ensin Githubin ohjetta, että saat ApexChartilla pörssisähkön hintakuvaajan näkyville. Sitten lisää uusi kortti samalla ohjeella, mutta tällä koodilla:
Koodi:
type: custom:apexcharts-card
experimental:
color_threshold: true
now:
show: true
color: '#ff0000'
apex_config:
forceNiceScale: true
chart:
height: 165%
yaxis:
- id: pyynti
show: true
decimals: 2
align_to: 1
apex_config:
tickAmount: 4
seriesName: pyynti
- id: hinta
show: true
opposite: true
min: 0
max: ~25
decimals: 2
align_to: 1
apex_config:
tickAmount: 4
show:
last_updated: false
header:
standard_format: false
show: true
show_states: true
colorize_states: true
title: Ohjaus vs. pörssisähkö.
span:
start: day
offset: +0h
update_delay: 2s
series:
- entity: sensor.shf_electricity_price
yaxis_id: hinta
name: Pörssisähkö c/kWh
extend_to: now
type: area
curve: stepline
opacity: 0.02
group_by:
func: last
duration: 60m
stroke_width: 1
data_generator: |
return entity.attributes.data.map((d, index) => {
return [new Date(d["DateTime"]).getTime(), d["PriceWithTax"]*100];
});
show:
header_color_threshold: true
legend_value: false
in_header: false
name_in_header: false
extremas: true
- entity: sensor.shf_control_factor_0_1
yaxis_id: pyynti
name: Ohjaus
unit: C
type: area
curve: stepline
opacity: 0.02
stroke_width: 1
data_generator: |
return entity.attributes.today_values.map((d, index) => {
return [start.getTime()+index*3600000, d];
});
show:
header_color_threshold: true
legend_value: false
in_header: false
name_in_header: false
extremas: trueVoit sitten kokeilla, että millaisen kuvaajan se antaisi esim. tämän päivän hinnoilla. Pitäisi tulla joku tämmöinen suurinpiirtein:
SHF Control Function vaikuttaa vähän siihen, että miten jyrkästi tullaan maksimi- ja minimiarvoon. Ja käyrän jyrkkyyttä saa säädettyä SHF Control Funtion Factorilla. Yllä olevissa kuvissa vähän esimerkkiä, että miten arvot voisivat vaikuttaa.
Sellainen kommentti vielä, että tätä jatkuvaa ohjausta ei oikein oltu mietitty 100% loppuun asti eli voi olla pöljäkin toteutustapa minulta. Tämä ottaa nyt lähinnä huomioon vain hinnanvaihtelun suhteellisena verraten päivän maksimihintaan. Jos hinnat pyörivät vaikkapa 5-6 sentin paikkeilla koko päivän, niin kuvaaja kumminkin vetäisi ohjauksen nollaan päivän kalleimpina kohtina. Eikä toisaalta takaa, ettei kämppä pakkasilla menisi liian kylmäksi. Toisaalta eipä se kai haittaa, että aina kalleimmat hetket olisivat pienellä sähkönkäytöllä, kun silloin ehkä eniten saastuttavaa sähköntuotantoakin käynnissä? Ja kyllä tästä ehkä silti hyötyä on, että saa helposti ohjattua jonkin ohjattavan laitteen pyyntilämpötilaa korkeammaksi halvemmille hetkille (kunhan sitten tekee sen automaatiosäännön niin, että pysyy mukavissa lämpötiloissa itselle). Ehkä jokainen voi sitten tehdä lämpötilakompensoinnin tai hintakompensointia automaatiossa tähän päälle. Luulen, että käyttötapaukset tässä vaihtelevat niin paljon, etten siksi tehnyt kuin tuon -1 ja +1 sekä 0-1 välillä vaihtelevat anturit avuksi ja jokainen saa sitten siitä soveltaa.
Otan mielelläni palautetta vastaan.
Juu kyllä mun mielestä tässä kovastikin ideaa on! Mulla on pörssisähköön siirtyminen edessä mahdollisesti vasta maaliskuussa, mutta tässä on nyt hyvin aikaa koeponnistaa eri ohjaustapoja. Käyttökohteita löytyy kattolämmityksestä lattialämmitykseen ja ILP:iin (no lattialämmitystermarit vielä tulossa postissa mutta kumminkin). Kattolämmityksessä varmasti hyöty minimaalinen, mutta lattioiden varaaminen tuntuis hyvältä ajatukselta, samoin ILP:in pyyntilämpötilan nosto asteella jos tietyt ehdot täyttyy.
Tuo kuvaaja jo selkeyttikin toimintaa, kiitos siitä. Ajatus on siis, että nykyiseen pyyntilämpötilaan lisätään tuo "Ohjaus"? Omalla kohdalla tuossa tulee ensimmäinen haaste, kun huonetermarit ymmärtää vain asteen tarkkuutta. Toki tuon voi pyöristää koodilla, mutta voisiko ohjaukselle olla jo valmiiksi olemassa helper joka kertoo desimaalitarkkuuden, mun tapauksessa pienin mahdollinen säätö olisi 1 aste.
Joo. Automaatioissa Templatella onnistuu tosiaan pyöristykset ja ohjaukset. Tai siis Templateja joutuu kuitenkin käyttämään, kun ei muuten onnistu käsittääkseni automaatiossa käsky "aseta ILPin tavoitelämmöksi anturin X arvo". Siihen ei kauhean paha rasti ole lisätä Templatella sitten suoraan offsettia (esim. 20 pohjalämmöksi) ja kerrointa tuolle "Ohjaukselle" (esim. 2*ohjausarvo, jolloin ulos tulisi lukuja 0-2) eli esim. jotain tämmöistä (huomioi, että aiemmasta esimerkistä poiketen tässä kuvassa offset=22 ja ohjausanturiksi valittu versio, jonka arvo vaihtelee -1 ja +1 välillä, jolloin tuo antaa kokonaislukuja 20-24 välillä riippuen hinnasta):
Tuosta saisi hiukan yksinkertaisemman, jos tekisi UI:n puolella pari helperiä (offset, kerroin, pyöristysvalinta), mutta edelleen pitäisi tehdä tuo Template silti samalla tavalla automaation puolelle muotoon:
Diff:
data:
temperature: "{{ states('sensor.some_sensor') | float }}"Että onko hirveä ero sitten?
heebo1974
Aktiivinen jäsen
Hmm. Minulta meni vähän ohi tämä lisämaksu osio ? Onko tarkoitus ympätä sähkönsiirrot mukaan vai mitä näillä oli tarkoitus tehdä ?
Joo, tämähän se oli eli saat yö/päiväsiirrot ja sähköyhtiön marginaalin mukaan. Päivän aikana tosin hinnat vaihtelee niin paljon, ettei ehkä isoa eroa tällä saa ohjauksiin, mutta voi se johonkin hintarajaan tai ehkä siihen "n halvinta peräkkäistä tuntia" ehkä vaikuttaa tunnin johonkin suuntaan.
Moi...pieni sivukysymys
Minulla on omat 3-vaihe kWh laskurit MLP:lle (sensor.energy_mlp) ja sähköauton lataukselle (sensor.energy_ev).
Kuinka voin laskea lämpöpumpun/EV:n käyttämän sähkön hinnan per tunti?
Esim. sensor.energy_mlp * sensor.shf_electricity_price_now
sensor.energy_ev * sensor.shf_electricity_price_now
Minulla on omat 3-vaihe kWh laskurit MLP:lle (sensor.energy_mlp) ja sähköauton lataukselle (sensor.energy_ev).
Kuinka voin laskea lämpöpumpun/EV:n käyttämän sähkön hinnan per tunti?
Esim. sensor.energy_mlp * sensor.shf_electricity_price_now
sensor.energy_ev * sensor.shf_electricity_price_now
Itse tein vastaavan virityksen siirtohintakustannuksen laskemiseen. Ensin tein Utility Meter -helperin energialle. Se nollataan tunneittain. Tuo pöljä käyttöliittymä ei anna muuttaa nollausjaksioa jälkikäteen niin kannattaa laittaa kerralla oikein. No voihan noita olla useita eri ajanjaksolle.
Sitten vaan kertoman omaan sensoriinsa kilowatit yksikkohinnalla niin saat tuntikohtaisen kustannuksen.
Koodi:
yleissiirtokulu:
unique_id: "380"
friendly_name: yleissiirtokulu
device_class: monetary
unit_of_measurement: "snt"
value_template: " {{states('input_number.yleiss_hinta') | float * states('sensor.tunninenergia') | float}}"HOX! graafeja värkätessä kannattaa laittaa group_by max ja sama ajanjakso kuten utility sensorissa, muuten arvot on puutaheinää. Esimerkikisi näin.
Toisessa ketjussa oli puhetta Fission korvaamisesta. Koetin eilen huvikseni kokeilla, että saisiko sitä "ohjaus halvimmille tunneille monella eri lämmittimellä" ja jotain alkua voisi tuossa olla.
sensor. yaml on ihan oikea paikka. Sori jäi 2 riviä pois kun mulla on pitkä rivi noita template sensoreita ja tuo esimerkki oli listan keskellä. Muistaakseni HA tukee kahta tapaa miten tiedoston rakenne on joko toistat platformin joka sensorille tai sttien listaat tyypeittäin samat sensorit yhteen kuten minä tässä nyt. Mä olen laittanut nuo unique_id arvot käsin noihin (oma numerosarja / konfiguraatiotiedosto) tarkistas ettei mene olemassa olevien päälle.
kokeileppas tätä:
kokeileppas tätä:
Koodi:
- platform: template
sensors:
yleissiirtokulu:
unique_id: "380"
friendly_name: yleissiirtokulu
device_class: monetary
unit_of_measurement: "snt"
value_template: " {{states('sensor.shf_electricity_price_now')| float * states('sensor.tunninenergia') | float}}"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.
Rajapinnoissa oli kyllä pieni katko iltapäivästä eilen. Oli pieni bugin poikanen jonka korjasin. Olisiko osunut päivitys juuri skriptin päivityshetkeen?
Mutta sinänsä tuota voisi varmaan tutkaista mitä tuo tekee jos esim. Vaihtaa väärän API osoitteen... Esim. Sen URLin lopun vaihtaa joksikin xyz että API antaa 404 koodia. Jos kutsu epäonnistuu niin pitäisihän sen toipua kun API taas vastaa?
Mutta sinänsä tuota voisi varmaan tutkaista mitä tuo tekee jos esim. Vaihtaa väärän API osoitteen... Esim. Sen URLin lopun vaihtaa joksikin xyz että API antaa 404 koodia. Jos kutsu epäonnistuu niin pitäisihän sen toipua kun API taas vastaa?
Jotain häikkää on. Ilmeisesti aattona klo 14 jälkeen toimiva automaatio ei ollut saanut ladatua tämän päivän hintadataa. Käynnistin Home Assistantin aamulla uusiksi -> korjaantui. Tänään oli ilmeisesti sama ongelma päällä, noin tunti sitten (klo 14:32) ajoin käsin Automaation "Intelligent update of electricity price sensor" ja huomisen hinnat ilmmantuivat graafeille.
Mitäs tuo "states" juttu tarkistaa, joka keltaisella on?
Ja tosiaan entäs tuo "Hours". Jos se on aina tasan 14:00, niin voisi olla hyvä että se olisi vaikka 14:03. Onnistuuko? Ja tuo random-osuus vaikka range(0,120)|random ... pari minuuttia hajontaan riittää hyvin.
Ja tosiaan entäs tuo "Hours". Jos se on aina tasan 14:00, niin voisi olla hyvä että se olisi vaikka 14:03. Onnistuuko? Ja tuo random-osuus vaikka range(0,120)|random ... pari minuuttia hajontaan riittää hyvin.
Viimeksi muokattu:
Mites pitkään @Mikki vikatilanne oli päällä? Minullakin instanssi valitteli huonoja tuloksia, mutta toipui itsestään illalla.
Hakuajankohtaa ja intervallia voidaan muuttaa kyllä, jos jokin muu ajankohta parempi. Poikkeustilanteiden osalta testausta on suoritettu lähinnä vain niin, että poikkasin netin itseltä ja sitten ajoin päivitystä ja katsoin, että toipuu siitä.
Hakuajankohtaa ja intervallia voidaan muuttaa kyllä, jos jokin muu ajankohta parempi. Poikkeustilanteiden osalta testausta on suoritettu lähinnä vain niin, että poikkasin netin itseltä ja sitten ajoin päivitystä ja katsoin, että toipuu siitä.
Sensor.shf_idx:n tila, joka kertoo, että pitääkö hinnoista alkaa katsomaan indeksiä 0 vai 24 alkaen. Kun lataus tapahtuu nyt kerran päivässä, niin tuo idx sitten toimii helperinä monessa paikassa, että saa oikean vuorokauden hinnat.
Joo, nyt se automaatio ajetaan tunnin välein. Conditionissa on tarkistus sitten siitä, että milloin sitä oikeasti tarvitsee ladata (mm. rajoitus, että vasta kello 14 jälkeen ja jos sensorissa ei ole riittävästi dataa). Jos haluaa laittaa menemään aina 15 yli, niin hours alle lisää "minutes: 15".
Tuo ongelma oli klo 14-16 välillä. Sorruin vähän "If it aint'broken, dont fix it" juttuun. Vähän vaikea sanoa tarkkaan aikaa kun api ei ollut alhaalla vaan osa requesteista epäonnistui.
Rakensin APIn taustalle entistä tukevamman cachen ja siinä kävi pieni koodauserhe ja C# HttpClientti tietyin välein jumitti ja boottasi API instanssin (Azure functionin), joita on kuormasta riippuen 2-10 kerrallaan ajossa. Mutta nyt pitäisi olla aika tukeva, kun bugi on korjattu.
Tähän HA yamliin sanoisin että tee @Temez tai joku muu hyvä retry-systeemi vain jos joku requesti feilaa. Nyt raja per IP osoite per API on 150 requestia tunnissa. Joten jos logiikan tekisi niin että HA päivittää klo 14 jälkeen vaikka 5 min välein kunnes tiedot on saatu... olisi täysin ok.
Pienikin "random" tekijä toki on hyvä kun kellot tuppaa olemaan kaikilla synkassa
Rakensin APIn taustalle entistä tukevamman cachen ja siinä kävi pieni koodauserhe ja C# HttpClientti tietyin välein jumitti ja boottasi API instanssin (Azure functionin), joita on kuormasta riippuen 2-10 kerrallaan ajossa. Mutta nyt pitäisi olla aika tukeva, kun bugi on korjattu.
Tähän HA yamliin sanoisin että tee @Temez tai joku muu hyvä retry-systeemi vain jos joku requesti feilaa. Nyt raja per IP osoite per API on 150 requestia tunnissa. Joten jos logiikan tekisi niin että HA päivittää klo 14 jälkeen vaikka 5 min välein kunnes tiedot on saatu... olisi täysin ok.
Pienikin "random" tekijä toki on hyvä kun kellot tuppaa olemaan kaikilla synkassa
Viimeksi muokattu:
Huikeasti kiitoksia tämän toteutukseen osallistuneille. Piti rekisteröityä foorumille, jotta pääsen erikseen kiittämään ja kommentoimaan.
Oma setuppi:
Tämä laskenta päivitti lasketun tuntilukeman "SHF Cheapest period hours":iin, minkä jälkeen oli tarkoitus ottaa MLP:n käyttölogiikalle pumpun sallittu käynnistymisajankohta "SHF Cheapest period start":ista. Outous tulikin siinä, että tämän jälkeen "SHF Cheapest period start" antoi kellonajan, mikä on menneisyydessä. Sinänsä se teki homman ihan oikein, koska pörssihinta viime yönä oli tulevaa yötä edullisempi, eli tuntihintoja sokeasti katsottaessa halvin ajanjakso antamilleni tunneille tosiaan alkoi jo viime yönä, mutta kun haluan ohjata MLP:n käynnistymistä aina kertaalleen vuorokaudessa (käytännössä laskea seuraavan käynnistymisajankohdan aina seuraavan vuorokauden pörssihintojen tultua saataville), minua ei auta, että ehdotettu MLP:n käynnistymisajankohta onkin menneisyydessä.
Eli olisiko tuohon mahdollista saada logiikkaa, että kun "SHF Cheapest period start" lasketaan uudelleen, olisi palautettava ajankohta aina tulevaisuudessa (aikaisintaan seuraava tasatunti)? Vai onko logiikassa tälle jo joku mahdollisuus, minkä olen vain missannut?
Homma on tietysti kimurantti, jos "SHF Cheapest period hours" annetaan niin suuri arvo, että ajanjakso menee pidemmälle kuin mitä pörssisähkön hinta on tiedossa...
Oma setuppi:
- HA:n ohjaamana käytetään meidän maalämpöpumppua. Tällä hetkellä, nykyisellä sähkösopparilla tosin yksinkertaisesti vain niin, että lämmitysveden tuottaminen sallitaan halvemmalla yösähköhinnalla (sekä siirto- että sähkösopparissa omat hinnat näille), eli toteutus on helppo, koska vuorokaudessa on vain kaksi kiinteää ajankohtaa: toinen lämmityksen sallimiselle ja toinen sen kieltämiselle.
- Ensi syksynä siirryttäneen pörssisähköön, joten valmistelen HA:ta siihen, että se osaa pyöritää MLP:a vuorokauden halvimpana ajankohtana tarvittavan ajan. Tarvittava aika määräytyy seuraavan päivän lämpötilaennusteesta. Logiikka ja automaatiot tälle on jo käytännössä tehty (kiitos tuon SHF-paketin) - nyt vain seuraan, miten logiikka toimii.
Tämä laskenta päivitti lasketun tuntilukeman "SHF Cheapest period hours":iin, minkä jälkeen oli tarkoitus ottaa MLP:n käyttölogiikalle pumpun sallittu käynnistymisajankohta "SHF Cheapest period start":ista. Outous tulikin siinä, että tämän jälkeen "SHF Cheapest period start" antoi kellonajan, mikä on menneisyydessä. Sinänsä se teki homman ihan oikein, koska pörssihinta viime yönä oli tulevaa yötä edullisempi, eli tuntihintoja sokeasti katsottaessa halvin ajanjakso antamilleni tunneille tosiaan alkoi jo viime yönä, mutta kun haluan ohjata MLP:n käynnistymistä aina kertaalleen vuorokaudessa (käytännössä laskea seuraavan käynnistymisajankohdan aina seuraavan vuorokauden pörssihintojen tultua saataville), minua ei auta, että ehdotettu MLP:n käynnistymisajankohta onkin menneisyydessä.
Eli olisiko tuohon mahdollista saada logiikkaa, että kun "SHF Cheapest period start" lasketaan uudelleen, olisi palautettava ajankohta aina tulevaisuudessa (aikaisintaan seuraava tasatunti)? Vai onko logiikassa tälle jo joku mahdollisuus, minkä olen vain missannut?
Homma on tietysti kimurantti, jos "SHF Cheapest period hours" annetaan niin suuri arvo, että ajanjakso menee pidemmälle kuin mitä pörssisähkön hinta on tiedossa...
Hyvä ehdotus, tätä pitänee parantaa. Vähän pitäisi ehkä miettiä, että mikä olisi sopivin logiikka. Nyt tosiaan aloitusajankohdaksi voisi tulla mikä tahansa ajankohta tiedossa olevien hintojen alusta loppuun asti. Olisiko se sitten niin, että lataushetken jälkeen halvin pätkä, joka voi siirtyä esim. seuraavalle päivälle seuraavan latauksen yhteydessä, jos silloin on halvempaa?
(Ja kiitos kiitoksista!)
Niin, mielestäni tuon pitäisi mennä tosiaan juuri noin, että sillä hetkellä, kun koodia pyydetään tarjoilemaan halutun mittainen halvin yhtenäinen jakso, se tarjoilee sen vain tulevaisuuden tunnettujen tuntien sisältä. Eli alkaen aikaisintaan seuraavasta tasatunnista, päättyen viimeistään tuolla hetkellä viimeiseen hinnaltaan tunnettuun tuntiin.
Jos pyydetyn ajanjakson pituus on lyhyempi kuin hinnaltaan tunnettujen tuntien määrä, logiikka on suoraviivainen. Mutta jos pyydetään vaikkapa halvinta yhtenäistä 12 tunnin jaksoa ja hintoja on tiedossa vain seuraaville 10 tunnille, niin tuolloin käytös voisi olla vaikkapa niin, että vaikka käyttäjä syöttääkin liukusäätimellä "SHF Cheapest period hours" arvon 12, niin koodi vaihtaa sen automaattisesti 10:een ja sen jälkeen antaa "SHF Cheapest period start":ssä seuraavan tasatunnin ajankohdan (koska hintoja tiedossa vain seuraavalle 10 tunnille, eli kaikki tunnetut tunnit pitää hyödyntää).
Ohjeena paketin käyttäjille voisi tällöin olla, että mikäli koodin haluaa tarjoilevan vähänkään pidempää käyttöjaksoa tulevalle ~vuorokaudelle, kannattaa tuo laskenta suorittaa heti uusien hintojen tultua saataville. Myöhemmin tuntihintoja ei välttämättä ole tiedossa tarpeeksi pitkälle pidempää käyttöjaksoa pyydettäessä.
***
Sivumainintana: itse ajattelin hyödyntää pakettia mahdollisesti myös sähköauton lataamisessa; ensiksi HA:lle kerrotaan haluttu prosenttilisäys auton akkuun (taustalla pitää tietysti olla tieto, paljonko prosentteja saadaan / tunti), HA laskee sitten tarvitun latausajan, mikä tarjoillaan tuolle SHF-paketille ja vastauksena saadaan latauksen aloitusaika. Tässä hommaa vaikeuttaa se, että latauksen halutaan usein olevan valmis esim. klo 7.00. Jos tiedossa on kuitenkin tuulinen päivä, voi pörssisähkön hinta olla halvempi vasta päivällä.
Eli jos pakettia haluaa kehittää vielä enemmän, niin siinä voisi olla yhtenä käyttäjäsyötteenä kellonaika (tasatunti), mikä on käyttöjakson takarajana, sanotaan tätä vaikkapa "SHF Cheapest period deadline":ksi. Omassa tapauksessani tuo menisi seuraavasti:
1. Käyttöjakson päättymisen takaraja syötteenä "SHF Cheapest period deadline": esim. "7:00", mikäli latauksen pitää olla valmis klo 7.
2. "SHF Cheapest period hours" syötteeksi HA:n laskemana (tälle oma logiikkani) vaikkapa "4" tuntia
3. Mikäli käyttöjakson päättymisellä ei olisi rajoituksia, halvin 4 tunnin käyttöjakso voitaisiin hyvinkin saada vasta myöhemmin aamupäivällä/päivällä, mutta koska käyttäjä on valinnut takarajaksi "7:00", niin SHF tarjoilee alkamisajan nykyhetken ja seuraavan klo 7:00:n välillä, sanotaan vaikkapa 2:00-6:00
4. "SHF Cheapest period start" saa arvon "28.12.2022 4:00:00" seuraavalle päivälle.
Tämä ylläoleva on kuitenkin täysin nice-to-have:ä, ja toimikoon vain ideana jatkokehitykselle. Jo nykyisellään tuo on todella hyvä setti - etenkin, jos tuo aiemmin esille tuomani asia on mahdollista saada muutetuksi.
Kannattaakos tuon auton kohdalla välittää akun varaustasosta pätkääkään? Ainakaan jos käytössä on hybridi, tai arkiajossa tulee niin vähän ajoa et vuorokauden pari halvinta tuntia riittää lataamaan akun joko täyteen tai niin paljon että selviää seuraavaan halpaan jaksoon? Itse aktivoin laturin joka päivä kahdelle halvimmille tunneille, auto ottaa virtaa jos akkuun sopii...
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...).
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ä).
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.
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.
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.
Tässä vielä hahmotelmaa käyttäjän säätimistä.
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ä).
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.
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.
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.
Tässä vielä hahmotelmaa käyttäjän säätimistä.
Isot kiitokset kaikille jotka SHF:ää kehittelevät. Itselle ei YAML ole kovin tuttu ja ohjelmointi muutenkin on ollut pari kymmentä vuotta tauolla, niin en ihan omilla kyvyillä saanut täydellistä toteutusta aikaan. Eli neuvoa kaipaisin, kun haluan ohjata lämmitykset kovemmalle teholle pörssisähkön halpojen tuntien ajaksi. Ja päälle kytkennässä onnistuinkin automaation avulla. Mutta nyt en keksi miten palaisin halpojen tuntien jälkeen normaalilämmitykseen? Miten toteuttaisi triggerin, joka kertoisi halpojen tuntien päättyneen?
Meillä on kaksi sähköautoa, joita tyypillisesti ladataan yön aikana 60 %:iin, millä selvitään tulevan päivän tavallisista max. 150 km ajoista ilman sen suurempia miettimisiä. Jos seuraavana päivänä on tiedossa enemmän ajoa, niin tarvetta voikin olla esim. 80-90 % varaustasolle aamulla lähtiessä. Tällöin voisi tilanne mennä niin, että kun iltasella palaa kotiin, autossa vaikkapa 30 % ja tarvitsee aamulla akussa 80 %, niin HA:lle voisi syöttää tiedon, että tarvitsee +50 %-yksikköä varausta akkuun, HA laskee tuohon tarvittavan latausajan, valitsee tulevilta tunneilta slotin ja ohjaa laturit antamaan virtaa tuolloin.
Nykyisellään kiinteistössä ei ole lataukselle kuormanhallintaa, vaan kumpikin auto ladataan yön aikana kolmesta vaiheesta 8 ampeerilla (5,5 kW / auto). Tämä on riittänyt aina hyvin, koska autoille ei tule koskaan tilanteita, että kotiin saavutaan todella myöhään täysin tyhjällä akulla, minkä pitäisi olla taas aamulla varhain piripinnassa täysi. Meidän 25 A pääsulakkeetkin riittävät tälle hyvin, vaikka MLP tekisi legionellakuumennustakin samanaikaisesti (max. ottoteho vastuksille säädetty 4 kW).
Mikäli vielä tulevaisuudessakin tulee olemaan pörssisähköhinnoiltaan hulluja aikoja, voisi olla järkevää nostaa pääsulakkeiden koko 35 ampeeriin ja samalla nostaa autojen latausvirtaa. Tällöin on mahdollista ladata autot tarvittavaan tasoon lyhyemmässä ajassa (lue: vain muutaman halvan pörssisähkötunnin aikana). Toki 25 A -> 35 A nosto jo itsessään maksaa ja lisäksi se tuo isomman kuukausimaksun, joten ihan kevyin perustein ei tuohon kannata lähteä.
Ja kenties tämä ylläoleva on ihan täysin turhaa haihattelua; voi olla täysin perusteltua, että yksinkertaisesti säätää latauksen alkamaan klo 00:00 ja loppumaan klo 7:00 tai toki se loppuu jo aiemminkin, mikäli auton päästä säädetty latausraja tulee täyteen. Asiaa pitää ajatella myös siltäkin kannalta, että olisi hyvä, että akun lataus loppuu juuri ennen ajoon lähtöä, sillä tällöin akussa on latauksen sinne synnyttämää lämpöä, jolloin ajaminen on taloudellisempaa vrt. liikkeelle lähtö jo jäähtyneellä akulla. Eli se, että säästää pennin ladatessaan akkua vaikkapa neljä tuntia klo 0:00 alkaen, voi tarkoittaa, että häviääkin kaksi penniä ensimmäisen 50 ajokilometrin aikana myöhemmin aamulla.
Miten olet määrittänyt itsellesi "halvat tunnit"?
SHF-paketissahan ovat jo attribuutit:
SHF Price acceptable On/Off
SHF Rank acceptable On/Off
SHF Price or Rank acceptable On/Off
Nämä käyttävät käyttäjän syötteitä: "SHF Max Price allowed" ja/tai "SHF Max Rank allowed" riippuen siitä, miten haluat nuo "halvat tunnit" määrittää - joko tietty valittu hintakynnys (hankalaa, koska pörssisähkö voi päivästä toiseen vaihdella, toki tätäkin voi päivittää automaatiolla) TAI niin, että vuorokaudesta valitaan X määrä halvimpia tunteja, joiden aikana lämmitys sallitaan. Tuota tuntimäärää voidaan päivittää vaikkapa sääennusteen perusteella. Halvat tunnit toki usein sijoittuvat yölle, joten sitten riippuu kiinteistön lämmönvarauskyvystä, että voidaanko lämmitystunnit hoitaa kaikki yön aikana vai pitääkö olla joku takaraja, milloin lämmitys käynnistetään päivällä uudelleen hinnasta riippumatta.
Tämän jälkeen automaation triggerinä on State-muutos Off->On->Off jossain noista kolmessa attribuutissa, miten nyt sitten haluatkaan. Halvat tunnit päättyvät, kun tapahtuu muutos On->Off.
Saako kysyä tässä ketjussa ihan tyhmiä perus HA automaatiokyssäreitä.
Sciprti:
alias: Säädä lattialämpö kerran tunnissa
description: >-
säädetään lattialämpöä +-2 astetta perusasetuksesta (+2) pörssisähkön
mukaisesti
trigger:
- platform: time_pattern
hours: /1
condition: []
action:
- service: input_number.set_value
target:
entity_id: input_number.heishamon_heatshift_z1
data: "{{ 2 + 2*states('sensor.shf_control_factor_1') | int }}"
mode: single
Virheilmoitus (kun yritän ajaa automaation käsin testin vuoksi):
Error: Error rendering data template: Result is not a Dictionary
Sciprti:
alias: Säädä lattialämpö kerran tunnissa
description: >-
säädetään lattialämpöä +-2 astetta perusasetuksesta (+2) pörssisähkön
mukaisesti
trigger:
- platform: time_pattern
hours: /1
condition: []
action:
- service: input_number.set_value
target:
entity_id: input_number.heishamon_heatshift_z1
data: "{{ 2 + 2*states('sensor.shf_control_factor_1') | int }}"
mode: single
Virheilmoitus (kun yritän ajaa automaation käsin testin vuoksi):
Error: Error rendering data template: Result is not a Dictionary
Okei. Saahan tästä toki monimutkaisenkin jos haluaa harrastaa. Mulla on tosin vain 1 hybridiauto joka lataa tyhjästä täyteen 1,5 tunnissa 7,3 kW teholla. joten sen kanssa ei tarvitse paljoa arpoa miten se kannattaa ladata. Jos joskus päädyn täyssähköön niin ainakin aloitan samalla tyylillä. 2 h latausta vuorokaudessa saatavissa autolle vuorokauden halvimmilla tunneilla -> meidän ajoilla akku olisi käytännössä aina täynnä ilman mitään ajatustyötä...
Tuosta taisi puuttua value: elementti. Koitanpa näin:
action:
- service: input_number.set_value
target:
entity_id: input_number.heishamon_heatshift_z1
data:
value: '{{ 2 + 2*states(''sensor.shf_control_factor_1'') | int }}'