Spot-hinta.fi - Yksinkertainen pörssiohjaus API ja sitä käyttävät automaatioskriptit

[hanks]

@hanks : kysymys tuosta ESP Eesyn httpstä. Saisiko tuossa kohtaa missä räpsyrät relettä tehtyä uuden http kutsun?

En näe mitään estettä sille, mutta en nyt pääse kokeilemaan.

 

[roots]

Kuluttajien osalta ei taida yksikään firma kertonut miten käy.

Ja onko mittarit kaikilla varttimittaukseen kykeneviä?

Ei varmaan ole vielä kerrottavaa, niille riittää kun Fingrid aloittaa tuon vyöryn...

Ei ne kaikki mittarit varmaan vielä ole siihen kykeneviä, oma taitaa olla kun joskus speksejä vilkaisin. Toisaalta itselle ei vielä toukokuussa ole merkitystä onko vai ei... mieluusti vois vaikka siirtyä kymmenenkin vuotta.

 

[jmaja]

Mikäs muuten tekee JSONista hyvän tällaiseen? Mulle ainakin olisi helpompi vaikkapa päivämäärä ja sitten 24 hintaa vaikkapa pilkuilla erotettuna.

Milläs noita helpoiten käsittelee shell scripteissä tai vaikkapa awk:lla? Pitäis ensin saada taulukoksi.

 

[hanks]

Milläs noita helpoiten käsittelee shell scripteissä tai vaikkapa awk:lla? Pitäis ensin saada taulukoksi.

Jos saat asennetun ympäristöösi jq komennon, sillä voi parsia jsonia shellissä.

 

[jmaja]

Jos saat asennetun ympäristöösi jq komennon, sillä voi parsia jsonia shellissä.

Niin katselin ja kai sen saa. En ole vielä kokeillut.

 

[Mikki]

Mikäs muuten tekee JSONista hyvän tällaiseen? Mulle ainakin olisi helpompi vaikkapa päivämäärä ja sitten 24 hintaa vaikkapa pilkuilla erotettuna.

Milläs noita helpoiten käsittelee shell scripteissä tai vaikkapa awk:lla? Pitäis ensin saada taulukoksi.

Kyllä se lienee aika standardi jos halutaan hakea tietoa. Mutta tosiaan tuollaiset pelköt "päätökset" voi tehdä pelkällä http statuksella mikä on helpoin parsia aina.

Tai siten yksi arvo kuten tuo tämän hetken rank. Mutta jos on useita tietokenttiä niin json on hyvä melkein kielellä kuin kielellä. Pienen opiskelun jälkeen myös helpointa.

Ja kuten tuossa home assistantissa sai luettua suoraan ilman koodausta.

 

[Mikki]

Jos antaa ulos paikallisaikaleimoja, niin sitten mukana pitää olla myös UTC-offset (meillä siis +02:00 tai +03:00). Nyt näyttää API antavan oikeaoppisesti ISO 8601-aikaleimat, hyvä hyvä. Vielä perään tuo aikavyöhyketieto, niin kesäaikakin hoituu oikein. Toki sitten API ei enää ole ihan niin läpisimppeli kuin nyt.

Asia on nyt korjattu... päivämäärät on muodossa:
"DateTime": "2022-09-11T00:00:00+03:00",

Sinänsä kaikki JSON parserit ymmärtää nämä standardi-päivämäärät. Yleensä vaikeuksia tulee vain silloin kun standardeista poiketaan. Vaikka äkkiseltään tuollainen päivämäärä näyttää vähän "hankalalta".

 

[ttk2]

Viikonloppuna rele on toivottavasti jo paikoillaan ohjaamassa varaajaa.

Eilen kävi asentaja laittamassa wifi-releen sähkökeskukseen. Samalla teki pieniä ylläpitotöitä ja purki vanhoja energiavaraajan ohjauksia ja muuta vanhaksi jäänyttä uuden alta pois. Aina hyvä, kun siistitään, järkeistetään ja jätetään "työpaikka" selkeämmäksi ja ylläpidettävämmäksi kuin mitä se oli aloitettaessa. Koskee näemmä yhtälailla sähkö- kuin koodaustöitä, varmaan monia muitakin hommia.

Kytkennän jälkeen käänsin varaajan termarin lukemaan 65°C, että saisin paremmin näkymään liikettä lämpötilakäyrällä. Sitten joskus ennen klo 21 HA:sta rele tilaan "on" ja seuraamaan mitä tapahtuu:

Joskus ennen klo 22 jälleen manuaalisesti rele tilaan "off" ja odottamaan yön halpoja tunteja. Yöllä lämmityssyklit 00-01 ja 05-07.

Lämpötila ei saavuta likimainkaan termariin asetettua arvoa 65°, mutta tämä taitaa johtua heikkotasoisesta mittausjärjestelystä: DS18B20 ujutettu vaan styroksin alle terästä vasten. Tämä ei ole ongelma, koska en tarvitse tässä absoluuttista oikeaa arvoa, ainoastaan hiukan parempaa ymmärrystä lämpötilamuutoksista ja niiden nopeuksista, joihin en päässyt ihan perus-sähkövaraajan tapauksessa käsiksi ilman omaa anturointia.

Nyt on ollut sen verran kallista sähköä öisinkin tarjolla, että pitää miettiä pitäisikö halvempaan aikaan ylilämmittää varaajaa varmuuden vuoksi ja tuolla omalla anturoinnilla päätellä kannattaako seuraavana yönä lämmittää ollenkaan (käytännössä varmaan aktivoivan "rankin" tullessa kohdalle tarkastella anturin antamaa lämpötilaa ja antaa toisinaan signaalin lipua ohi). 300 litrainen käyttövesivaraaja jäähtyy jollain (vakio)nopeudella tietyssä lämpötilassa, joten voi olla, että moinen monimutkaistus ei kannata tai että yhtään mitään sillä ei ainakaan säästä. Tämä selviää kokeilemalla ja noita lämpötilakuvaajia jälkikäteen tutkimalla.

OT: Sähkökeskuksen kannen alta paljastui mm. kolme kontaktoria, jotka ennen ohjasivat energiavaraajan kolmea 6 kW vastusta. Eiköhän niille jotain käyttöä vielä keksitä, mutta nyt ne otettiin tieltä pois. Wifi-rele on nelikanavainen, joten kytkettiin lämminvesivaraajan ohjaukseen yksi kanava ja loput kolme johdotettiin valmiiksi riviliittimeen, mutta jätettiin toistaiseksi odottamaan hyvää ajatusta siitä mitä voisi ja kannattaisi ohjata. Kiukaan ohjaus olisi yksi mahdollinen polku; kalleimmilla tunneilla 250W muhimisvastus saataisiin pois kuluttamasta. Tulevilla sähkön hinnoilla ei kyllä enää saunota yhtä usein kuin ennen, joten voi olla, että tämä vuodelle 1998 leimattu pikkuhiljaa jo vaihtokunnossa oleva ainavalmis vaihtuukin tavalliseksi kiukaaksi.

Energiavaraaja ja yhteensä 18 kW vastusteho olisi voinut tässä kohtaa olla hyvä keino saada kulutusta keskitettyä halvoille tunneille. Mutta myöhäistä on nyt rypistellä, se 1800l energiavaraaja purettiin pois jo viisi vuotta sitten ja korvattiin invertteri-mlp:lla. Tila tuli tarpeeseen ja muita vakioselityksiä.

 

[Mikki]

Näetkö muuten @ttk2 että kuinka usein se "REST"-anturi hakee tiedot? Jollakulla on vähän kireä timeri kuitenkin, näyttäisi tulevan jostainpäin 14 /JustNow hakua minuutissa. Ihan niin usein ei tiedot vaihdu

Koska rajapinnat on avoimet, niin tuolla on rajoitus päällä että kuinka paljon suorituksia vuorokaudessa saa mennä läpi. Se on nyt asetettu aika tiukalle luokkaan 3 requestia per sekunti.

"Denial of Wallet" on jonkinlainen riski aina kun koodataan pilveen softaa. Azuressa on onneksi "jarru", mikä lyö pelin poikki jos tulee hillitön kuorma.

 

[ttk2]

HA:ssa tuolla rest-sensorilla on muistaakseni oletuksena 30s pollausväli. En ole sitä itse tuossa muuttanut, mutta voisihan se ehkä harvemminkin olla.

Jos pollaisi vaikka viiden minuutin välein, niin pahimmillaan suora rankilla ohjaaminen tuhlaisi halvasta tunnista jo 8,3% ennen kuin rele älyäisi mennä päälle. 30s tuhlaa vain alle prosentin - kirppukin on lihaa Ja jos seuraava tunti on oikein kallis, niin pidemmällä pollausajalla tehoa käytettäisiin kalliiseen aikaan ihan turhaan.

Alkaa mennä jo melko laihialaisiksi nämä tarkastelut, myönnettäköön.

 

[Mikki]

Juu ei mitään 5 minuuttia. Minuutti on hyvä tahti. Eikä per 30 sekuntiakaan ollenkaan paha. Mutta 4 sekunnin välein haku on jo todellista laihialaista menoa.

 

[kotte]

Kyllä se lienee aika standardi jos halutaan hakea tietoa. Mutta tosiaan tuollaiset pelköt "päätökset" voi tehdä pelkällä http statuksella mikä on helpoin parsia aina.

On se jossakin maailmassa de facto interface-standardi, mutta kyllä xml on ihan samalla lailla standardi (ja todellisuudessa aika helppo jäsennellä ja tulkita sekin, jopa ilman tähän tarkoitettua kirjastoa sopivalla merkkijono-orientoituneella välineellä). Mutta json on ihan OK mielestäni myös.

 

[ttk2]

Juu ei mitään 5 minuuttia. Minuutti on hyvä tahti. Eikä per 30 sekuntiakaan ollenkaan paha.

Koitan laittaa hetkeksi logitusta päälle ja varmistan, etten turhaan kysele APIsta liian usein.

EDIT: on se 30s välein:

2022-09-11 23:21:53
2022-09-11 23:22:23
2022-09-11 23:22:53

 

[kotte]

Ainakin Entso-E:n hintahistoria kertoo, että viime syksynä 31.10 oli hintadatassa 25 tuntia, ja klo 3 alkavilla kahdella peräkkäisellä tunnilla oli hieman eri hinta: 60,06 € ja 60,03 €.

Tuo taisi tosiaan aikanaan olla noin kuin väitin, mutta Entso-E:n kaudella kaikki on hiottu tarkemmin, ikään kuin "saksalaistettu". Tosiaan, kannattaa prosessoida kaikki UTC-pohjaisena, niin pääsee paljosta sotkusta. Tuon olisi suonut Microsoftinkin aikoinaan ymmärtäneen, kun Windowsin aikaraamiston väsäsi (liekö suunnittelutkin, ainakin hieman?).

 

[Harrastelija]

Siis kyse pörssisähköjen hinnan kyselystä?
Tarviiko sitä kysellä kuin kerran vuorokaudessa ja aina kun laite/softa käynnistyy?
Vai vaatiiko tuo paikallisesti ylimääräistä, vaikeasti toteutettavaa koodia?

 

[Mikki]

Siis kyse pörssisähköjen hinnan kyselystä?
Tarviiko sitä kysellä kuin kerran vuorokaudessa ja aina kun laite/softa käynnistyy?
Vai vaatiiko tuo paikallisesti ylimääräistä, vaikeasti toteutettavaa koodia?

Tuossa on pari erilaista API:a: jos haetaan kuluvan päivän tai huomisen hinnat listauksena, niin sitten tietty kerran päivässä riittää.
Ja sitten on nuo reaali-aikaisemmat API:t, jotka on tarkoitettu kotiautomaation käyttöön. Ne on tarkoituksella äärikevyet, että niitä voi kyllä kutsua tiheämmin.

"Tyhmissä" mikrokontrollereissa esimerkiksi ei mitään monimutkaisia ajastuksia voine tehdä. Eikä kannata edes.
Ja ei... ei vaadi mitään vaikeaa koodia nuo rajapinnat. Juurikaan yksinkertaisemmiksi niitä ei käsitykseni mukaan voi tehdä.

 

[ttk2]

Siis kyse pörssisähköjen hinnan kyselystä?
Tarviiko sitä kysellä kuin kerran vuorokaudessa ja aina kun laite/softa käynnistyy?
Vai vaatiiko tuo paikallisesti ylimääräistä, vaikeasti toteutettavaa koodia?

Tässä taitaa olla meneillään koe siitä kuinka API-suunnittelulla voidaan pitää se asiakaspää aivan minimaalisena.

Olen kyllä melko varma, että missään muualla ei ole vastaavaa API:a, jolle voidaan tehdä kutsu:

HEAD http://www.spot-hinta.fi/JustNowRank/3

Ja saada ohjaustieto kolmelle halvimmalle tunnille vuorokaudessa. Se on aika kevyt operaatio, kun käyttää HEAD eikä GET metodia, niin palvelimen ei tarvitse edes muodostaa tai lähettää vastauksen bodya kun pelkät vastauksen headerit riittää

Toi menee jo melkein nörttihuumorin puolelle, mutta kuvitellaan, että näitä pollaajia on muutama miljoona. Vielä on vähän matkaa siihen, mutta API:n osalta on minimalisointi tehty tuota silmällä pitäen.

 

[Harrastelija]

Mulle nuo API hommelit ei ole niin tuttuja.
Riittääkö justnow funktioille kutsu kerran tunnissa? Esim minuutin tai sekunnin yli tasan? Responsehan voi muuttua vain tasalta. Kannattaako tuota tiheämpään pollata?
No, nämä mun kysymykset ei varsinaisesti liity APIin vaan käyttäjään.

 

[Mikki]

Ja saada ohjaustieto kolmelle halvimmalle tunnille vuorokaudessa. Se on aika kevyt operaatio, kun käyttää HEAD eikä GET metodia, niin palvelimen ei tarvitse edes muodostaa tai lähettää vastauksen bodya kun pelkät vastauksen headerit riittää

Toi menee jo melkein nörttihuumorin puolelle, mutta kuvitellaan, että näitä pollaajia on muutama miljoona. Vielä on vähän matkaa siihen, mutta API:n osalta on minimalisointi tehty tuota silmällä pitäen.

Hei tuo oli hyvä huomio. Ei ollut HEAD metodille toteutusta. Nyt on ja se palauttaa pelkän statuskoodin, ei bodya. Periaatteessa joo, kyllä miljoonia pollaajia voisi olla jos joku maksaa Azuren laskun

 

[hanks]

Mulle nuo API hommelit ei ole niin tuttuja.
Riittääkö justnow funktioille kutsu kerran tunnissa? Esim minuutin tai sekunnin yli tasan? Responsehan voi muuttua vain tasalta. Kannattaako tuota tiheämpään pollata?
No, nämä mun kysymykset ei varsinaisesti liity APIin vaan käyttäjään.

Tuossa minun esimerkissä kutsun JustNowRank-APIa kerran tunnissa, silloin kun se on voinut muuttua. Laitoin tarkoituksella minuutin yli, jotta status olisi varmasti päivittynyt.

ESPeasyssä on onneksi NTP clientti, joka pitää kellon oikeassa ajassa. Se onkin tarpeen koska Lolin D1 mini -mikrokontrollerissa on todella epätarkka kello.

Edit: niin ja lisäksi on kutsu bootin jälkeen, sähkökatkojen varalta. Liekö niitä odotettavissa ensi talvena.

 

[Käyttäjä89]

Koska rajapinnat on avoimet, niin tuolla on rajoitus päällä että kuinka paljon suorituksia vuorokaudessa saa mennä läpi. Se on nyt asetettu aika tiukalle luokkaan 3 requestia per sekunti.

"Denial of Wallet" on jonkinlainen riski aina kun koodataan pilveen softaa. Azuressa on onneksi "jarru", mikä lyö pelin poikki jos tulee hillitön kuorma.

Azure Funktioissa onneksi inhimillinen tuo hinnoittelu ja ns ilmaiseksikin pääsee jo pitkälle. Toki jos suosio yllättää niin kaippa siitä voi alkaa ihmisiltä jotain lahjoitusta kustannusten kattamiseksikin alkaa pyytämään. Hieno toteutus kyllä rajapinnasta ja ajatus tuntien järjestämisestä halpuuden mukaan on kyllä hieno.

 

[ttk2]

Mulle nuo API hommelit ei ole niin tuttuja.
Riittääkö justnow funktioille kutsu kerran tunnissa? Esim minuutin tai sekunnin yli tasan? Responsehan voi muuttua vain tasalta. Kannattaako tuota tiheämpään pollata?
No, nämä mun kysymykset ei varsinaisesti liity APIin vaan käyttäjään.

Kyllä tuossa on paljon mahdollisuuksia asiakaspään järkevöittämiselle. Naivi ensimmäinen toteutus onnistuu helposti, mutta sen jälkeen on syytä miettiä, että käyttääkö ilmaista resurssia enemmän kuin olisi kohtuullista.

Omalla kohdallani halusin päästä mahdollisimman nopeasti kokeilemaan tuota toisaalla ehdottamaani ajatusta Rankista. Home Assistantissa pollaus ja rest-sensori olivat yksinkertaisin tapa lähteä liikkeelle, mutta toteutus (josta yaml ketjun alkupuolella) aiheuttaa turhia kyselyjä, joista varmasti pystyy pääsemään eroon, kunhan opettelee HA:n tarjoamia mahdollisuuksia hiukan paremmin.

Kiinnostusta olisi myös rajapinnan kokeiluun mikrokontrollerin kanssa. Tällaisissa tilanteissa sitä oppiikin parhaiten, kun on joku konkreettinen ja hyvin rajattu tarve, jonka pyrkii täyttämään.

 

[Jullikka]

Tuossahan voi tosiaan säätää tuota hakuehtoa scan_interval-määrityksellä. Oletus tosiaan 30sek, voisi olla harvempikin. Vielä kun osaisi jotenkin ajaa noita automaatiota viivästetysti, jotta ehtisivät mukaan sensorin päivittyessä. Vaihtoehto on tosiaan tehdä myös omat automaatiot, jossa triggerinä pelkästään tuntihinnat tai nuo rankit.

 

[pamppu]

Mä en nyt ihan sisäistä että miksi pitäisi tehdä toteutus jossa pollataan 120 kertaa tunnissa apia. Ei tuo nyt energiatehokasta vihreätä koodia ole Laiskaa koodausta on, ulkoistetaan päätöksen teko pilveen. Mutta se ei sitten toimi ja tee lämmityspäätöksiä, jos vaikka netti putoaa.

Riittää tasan yksi kutsu kerran illassa, joka pyytää seuraavalle vuorokaudelle x kpl halvimpia tunteja. Ja sitten vaan toimitaan sen mukaan. Toimii, kunhan se netti edes illalla kerran toimii. Ja siinä voi olla retry-logiikka.

 

[ttk2]

Tein tänään automaation, joka hakee päivän tuntihinnat tiedostoon. Tällä hetkellä se vielä ajetaan kerran tunnissa, mutta eihän sen oikeasti tarvitsisi pyörähtää kuin kerran.

Tuota paikallista tiedostoa voidaan lukea vaikka kuinka usein ja parsia sieltä tietyt tunnit niiden aikaleimoilla, jolloin saavutetaan se, että sensoritieto voi päivittyä vaikka joka minuutti, mutta palvelinta ei turhaan pommiteta kutsuilla. Tuo minuuteittain päivittyminen siksi, että sensorin päivittymisestä emittoituva eventti on se, jota releen ohjaus kuuntelee.

Tämä tapa on tietysti palvelimelle parempi, mutta se äärimmäinen yksinkertaisuus menetetään. Ja tämä nyt koskee nimenomaan tuota Home Assistant -konfigurointia, joka paljastui mielestäni tarpeettoman rajoittuneeksi tässä suhteessa. Siellä pystyy ajamaan rajoitettuja Python-skriptejä (HA on toteutettu Pythonilla), mutta yritin pysyä pelkissä yaml-konfiguraatioissa. Vaan rajat tulivat vastaan. Jos alusta on sellainen, johon tuotetaan ohjelmakoodia, niin olen samaa mieltä tuosta laiskasta koodauksesta.

Nyt HA:n dashboardille luetaan tämän hetken hinta ja järjestysnumero sekä kurkataan muutaman tunnin verran tulevaisuuteen ja näytetään hintatieto myös niille tunneille. Tämä vastaa kysymykseen "lämmittäisinkö saunan nyt heti, vai kannattaako odottaa vielä pari tuntia?".

 

[Mikki]

Kyllä tarkoitus noissa rajapinnoissa on, että niitä voisi käyttää tyhmilläkin laitteilla. Siksi nuo yksinkertaiset APIt joita tarvii sitten pollata vähän useammin. Siis kerran tunnissa vaihtuu tiedot nyt mutta mikrokontrolleriin ei hurjaa älyä saa koodattua että ihan ok joku kerran minuutissa pollaus.

Nuo listaukset vaatii enemmän koodausta sitten mutta joo saa vuorokauden lokaalin kopion mikä tietty lisää varmuutta. Ja mahdollistaa hienompaa seurantaa kuten yllä.

Rajapinnat itsessään toiminee aika pomminvarmasti kun nuo Azuren palvelut on oikeasti vankkoja toimimaan. Mutta hakevan laitteen nettiyhteys voi toki olla heikko lenkki.

Mutta kiva että kokeilijoita löytyy jo.

 

[ttk2]

Laitan vielä ne HA:n konfiguraation osaset, jos niistä on jälkeenpäin vielä jollekin jotain iloa. Ainakin itselleni snapshot, jos joskus rikon kaiken totaalisesti

Ensimmäiseksi määritin Downloader-komponentin configuration.yaml tiedostoon:

downloader:
  download_dir: downloads

Sitten automaatio automations.yaml tiedostoon (tämän pystyi tekemään täysin käyttöliittymästä kliksuttamalla):

alias: Fetch spot prices into a local file
description: ""
trigger:
  - platform: time_pattern
    hours: "*"
    minutes: "0"
    seconds: "05"
condition: []
action:
  - service: downloader.download_file
    data:
      url: https://www.spot-hinta.fi/TodayAndDayForward
      filename: spot-prices.json
      overwrite: true
mode: single

Sensorit, jotka lukevat tiedostosta:

  - platform: command_line
    name: "Spot price"
    command: jq --arg timestamp "{{ as_timestamp(now() + timedelta(hours=0)) | timestamp_custom('%Y-%m-%dT%H') }}" '.[] | select(.DateTime | contains($timestamp))' downloads/spot-prices.json
    json_attributes:
      - DateTime
      - PriceWithTax
      - PriceNoTax
      - Rank
  - platform: command_line
    name: "Spot price +1h"
    command: jq --arg timestamp "{{ as_timestamp(now() + timedelta(hours=1)) | timestamp_custom('%Y-%m-%dT%H') }}" '.[] | select(.DateTime | contains($timestamp))' downloads/spot-prices.json
    json_attributes:
      - DateTime
      - PriceWithTax
      - PriceNoTax
      - Rank

JSONit kaivetaan jq:lla. Ei näytä kivalta, varmasti suoraan koodaamalla pääsisi luettavampaan lopputulokseen.

 

[jmaja]

mutta mikrokontrolleriin ei hurjaa älyä saa koodattua

Kyllä saa. Ihan perusmikrokontrollerilla (8-bit AVR/PIC tms, 2 € kpl pienissä erissä) olisi helppo toteuttaa koko lämpöpumpun ohjaus. Graafinen käyttöliittymä ja nettiliitäntä vaatii jo vähän enemmän.

 

[Mikki]

Kyllä saa. Ihan perusmikrokontrollerilla (8-bit AVR/PIC tms, 2 € kpl pienissä erissä) olisi helppo toteuttaa koko lämpöpumpun ohjaus. Graafinen käyttöliittymä ja nettiliitäntä vaatii jo vähän enemmän.

Oho... Onko näin. Tiedän kyllä että aika taikoja noilla tehdään.

 

[hanks]

Mulla on toinenkin kiinanihme mikrokontrolleri, Lolin C3 mini, jossa on tehokkaampi ESP32-chippi ja firmwarena MicroPython tulkki. Jos jaksaisin ja ehtisin, voisin kokeilla tehdä spot-lämpötilaohjauksen sillä. MicroPythonissa onnistuu HTTPS-kutsut, JSON-parsinta ja NTP-synkkaus myös. Mutta tuo vaatisi vähän koodausta from scratch, kun taas ESPeasyssä sai halutun toiminnallisuuden vain määrittämällä pari simppleliä sääntöä (ja Mikin suosiollisella avulla tehdyn API:n).

 

[Käyttäjä89]

ESPeasyssä sai halutun toiminnallisuuden vain määrittämällä pari simppleliä sääntöä.

Mites tämä ESPeasy vertautuu esimerkiksi ESPHomeen? Vähän menee jo offtopic

ESPHome — ESPHome

ESPHome Homepage - Reimagining DIY Home Automation. ESPHome is a framework that tries to provide the best possible use experience for using IoT microcontrollers for Home Automation. Just write a simple YAML configuration file and get your own customized firmware.

esphome.io

Ainakin HomeAssistant käyttäjien keskuudessa suosittu, en ole vielä ehtinyt perehtyä olisiko tuosta standalone käyttöön. Paljon siellä ainakin on valmista kun vaan pelkkiä konfiguraatioita tekisi

 

[jmaja]

Oho... Onko näin. Tiedän kyllä että aika taikoja noilla tehdään.

Joo kyllä noilla voi tehdä todella paljon ja nopeasti. On vain totuttu siihen, että "pitää olla" vähintää Raspi tai PC, jolla saa jo ihan tolkuttomia lasketatehoja ja voi sitten käyttää kaikkea epätehokasta, kuten Excel-laskentaa, JavaScriptiä jne. Ei sellaisia tarvita perusjuttuihin.

Ei siis todellakaan ole temppu eikä mikään laskea noille 24:stä hinnasta ne millä kannattaa ajaa. Voi siihen millisekunti mennä.

Mietin tässä juuri miten määrittää järkevä ohjaus MLP:lle. Jotenkin varmaan hintasuhteista ja lämmitystarpeesta johtaisi sellaiseen, että teho rittää, sisälämpötila ei liikaa muutu ja halvinta sähköä käytettäisiin. Tarkoitus olisi muuttaa sisälämpötilatavoitetta. Anturia ei ole, joten tuo vain kylmästi muuttaa menolämpöä 3 C/1 C sisälämpö.

Koodi menee OpenWRT:tä pyörittämään WiFi-reitittimeen.

 

[hanks]

Palatakseni alkuperäiseen topicciin, spot-hinnan hyödyntämisen algoritmeissa voisi olla vielä kehitettävää. Nimittäin ei välttämättä kannattaisi ”tuijottaa” vain yhden vuorokauden hintoja ja ’rankkeja’ kerrallaan. Voi olla myös niin että kannattaisi jättää vuorokauden viimeisinä tunteina lämmittämättä jos yöllä seuraavan vuorokauden puolella olisi vielä halvempaa.

Esim. juuri tuleva yö on sellainen.

12.9. klo 23:00 hinta on sen vuorokauden halvin 10,96 snt/kWh, mutta seuraavan vuorokauden puolella olisi vielä reilusti halvempaa.

Mikä olisi järkevä algoritmi tuon mahdollisuuden käyttämiseen ilman että tulee mitään ikäviä sivuvaikutuksia?

 

[jmaja]

Mikä olisi järkevä algoritmi tuon mahdollisuuden käyttämiseen ilman että tulee mitään ikäviä sivuvaikutuksia?

Ei tuohon ole mitään yleispätevää algoritmia. Riippuu mitä tuossa säädetään. Vaikkapa käyttövedelle asia riippuu säiliön koosta sekä vedenkäytöstä että ajoituksesta. Jos iltasin mennään suihkuun, voi olla huono juttu päättää iltapäivällä, että mennään vielä loppuilta lämmittämättä, kun yöllä onkin halvempaa.

Talon lämmityksen osalta homma riippuu lämmitysjärjestelmän tehosta suhteessa tarpeeseen, lämmitysjärjestelmän varauskyvystä ja koko talon lämpökapasiteetista. Tuossakin tulee mukavuus vastaan. Voisihan sitä olla koko kalliin vuorokauden lämmittämättä, mutta olisi sitten useimmissa taloissa jo aika viileää ennen kuin taas lämmitetään.

Yksinkertaisimmillaan pitää laskea kuinka monta tuntia vrk tai tunnettu hintajakso pitää lämmittää ja valita halvimmat tunnit. Voi kuitenkin olla järkevämpää toisin päin eli valitaan X kalleinta tuntia, jolloin ei lämmitetä.

Lämmitysteho kääntäen verrannollinen hintaan niin, että vuorokaudelle tulee oikea kWh-määrä lämpöä? Lämpöpumpuissa ei taida yleensä olla suoraa tehosäätöä.

 

[jmaja]

Pitäishän algoritmin huomioida myös siirto ja sähkövero, jotta ei luule halvan olevan aivan niin halpaa.

 

[Mikki]

Pitäishän algoritmin huomioida myös siirto ja sähkövero, jotta ei luule halvan olevan aivan niin halpaa.

Öö... Eikai kun ne on samat riippumatta muuttuvasta hinnasta. Eihän tässä mitään itsepetosta yritetä vaan löytää tapoja ajaa keskihintaa alemmas käytetylle sähkölle.

 

[kotte]

Mikä olisi järkevä algoritmi tuon mahdollisuuden käyttämiseen ilman että tulee mitään ikäviä sivuvaikutuksia?

Koko saatavilla oleva tuntihinnasto kannattaa ottaa käsiteltäväksi. Dataahan on saatavilla luokkaa 22 tuntia ... 46 tuntia eteen päin, juuri puolen päivän jälkeen vähiten, alkuiltapäivästä tyypillisesti pisimpään.

Myös lämmön riittävyys pitäisi ottaa laskelmassa huomioon. Jos laskentaan on varaa satsata sen verran, mitä tehokkaalla PC:llä tms. pystyy, voisi ehkä toteuttaa dynaamisen ohjelmoinnin algoritmin, eli lähdetään vaan kokeilemaan tunteja jakson alusta eteenpäin (jättämällä myös tunteja välistä pois) laskien samalla vastaavaa kustannusta ja käytettyä sähköä niin, että varaston varastointimäärä pysyy asetettujen rajojen sisällä. Jos voidaan pysyä tunti, vartti tai edes usemman minuutin tasolla, tuo probleema pysyy käsittääkseni kompleksisuusmielessä hallittavana, koska "vasemman pään" kustannusta voidaan käyttää lähtökohtana "oikean puolen" jatketulle kulutusallokaatiolle. Osa tunneista, varttitunneista, minuuteista tms. voi tietenkin jäädä käyttämättä mistä kohtaa tahansa ja nuo "vasemman jakson" allokaatiot voi taulukoida valmiiksi ("vasemman" ja "oikean" jakson raja etenee laskennassa systemaattisesti vasemmalta oikealle, mikä pitää kompleksisuuden hallittavana sekä laskennan määrän että tallennustilan suhteen; "vasemman puolen" muisti muodostaa dimensioltaan polynomisen taulukon ja algoritmi tavallaan etsii optimaalista polkua tuon taulukon lävitse "vasemmalta" "oikealle" käyttäen taulukkoa siihenastisten polkujen kustannusten tallentajana).

Nämä nyt vain alustavina ajatuksina...

 

[jmaja]

Öö... Eikai kun ne on samat riippumatta muuttuvasta hinnasta. Eihän tässä mitään itsepetosta yritetä vaan löytää tapoja ajaa keskihintaa alemmas käytetylle sähkölle.

Mulla yösiirto on halvempi. Lisäksi varaaminen kuumaksi lyhyellä ajalla vie enemmän sähköä kuin tasaisen lämmön ylläpito. Lämpöpumpulla COP heikkenee ja lämpöhäviöt lisääntyvät, jos laatta tai varaaja on normaalia kuumempi.

Jos vielä laitetaan vastukset peliin lämpöpumpun lisäksi, menee reilusti enemmän sähköä.

 

[Mikki]

Eihän mikään kaikille sovi. Mutta esim. köyttövesivaraajan lämmitys on aikalailla järkevä ajastaa. Ja jos on suorasähkötalo lattialämmöllä niin herratähden ainakin väistää ns. Tappotunnit.

Eikä se nyt ihan niin selvää ole ainakaan minulle etteikö kannattaisi ajaa vähän korkeampaa lämpökäyrää halvimpina tunteina jos on lattiakierto betonilaatassa. Väkisin se lepuuttaisi pumppua seuraavina kallimpina tunteina.

Ainakin Niben asteminuuttiohjauksella se toimisi.

 

[jmaja]

Dataahan on saatavilla luokkaa 22 tuntia ... 46 tuntia eteen päin

Uudet hinnat tulee joskus 14:00 jälkeen. Siis 14:00 on vain 10 tuntia ja sitten kohta on lähes 34 tuntia tulevaisuuteen. Noiden 10 tuntien kohtalo on jo kertaalleen päätetty, mutta kannattaahan ne päivittää, kun tulee seuraava vrk.

Jos laskentaan on varaa satsata sen verran, mitä tehokkaalla PC:llä tms. pystyy, voisi ehkä toteuttaa dynaamisen ohjelmoinnin algoritmin, eli lähdetään vaan kokeilemaan tunteja jakson alusta eteenpäin (jättämällä myös tunteja välistä pois) laskien samalla vastaavaa kustannusta ja käytettyä sähköä niin, että varaston varastointimäärä pysyy asetettujen rajojen sisällä.

Ei tuo mitään PC:tä tarvitse, jos et ala FEMillä laskemaan lämpötilakenttiä. Yksinkertainen malli, jossa on rakennuksen ja lämmitysjärjestelmän lämpökapasiteetit, lämmitysteho ja häviöt ulos pyörii dynaamisen mallina vaikka siinä 8 bit mikrokontrollerissa liukulukulaskentana.