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

Käyttäjä89

Aktiivinen jäsen
Sattuisko keltään löytymään fiksua template käsittelyä rajapinnasta lukemiseen jolla vältyttäisiin moiselta ilmiöltä ?
En ole tuohon tarkemmin tutustunut, mutta käsitykseni mukaan jos tieto tulisi MQTT:n kautta niin silloin viimeisin tieto voisi jäädä talteen.
Vaatisi että nuo arvot joita nyt rest sensorilla luetaan ohjattaisiinkin MQTT topic puolelle ja sitten taas tuo template itsessään käyttäisi noita MQTT puolen arvoja.


Ehkä on muitakin vaihtoehtoja, mutta tuo voisi olla kiertotie jos muuta ei keksi.
 

ttk2

Aktiivinen jäsen
Itse toteutin lopulta tämän niin, että haen API:lta TodayAndDayForward ja talletan sen tiedostoon (muistaakseni tunnin välein, mutta voisi se olla paljon harvemminkin). Ja sitten luen tiedostosta arvot tälle tunnille sekä neljälle seuraavalle tunnille. Näin API:a ei oikeastaan tarvitse kovin usein kutsua.

Jokin tässä jäi vielä itseäni kaivelemaan, mutta en enää muista, että mikä. Hyvin tämä on ainakin toiminut.

Neljä seuraavaa tuntia haen siksi, että pystyn näyttämään mihin suuntaan hinta on kehittymässä ja samalla lasken niille tunneille myös keskiarvon.

Itse konfiguraatio taitaa olla jossain täällä jo, mutta kopioidaan tähän nyt joka tapauksessa.

Downloaderin enablointi:

YAML:
downloader:
  download_dir: downloads

Automaatio, joka hakee hinnat tiedostoon:

YAML:
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://api.spot-hinta.fi/TodayAndDayForward
      filename: spot-prices.json
      overwrite: true
mode: single

Sensorit (tässä vain nykyhetki ja seuraava tunti), jotka päivittyvät usein, tosin ihan paikallisena operaationa, joka vain parsii hinnat aiemmin haetusta tiedostosta:

YAML:
sensor:
  - platform: command_line
    name: "Spot price"
    scan_interval: 15
    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"
    scan_interval: 15
    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

Template-sensorit, jotka hakevat tämän tunnin ja tulevien tuntien hinnat omiksi sensoreikseen:

YAML:
  - platform: template
    sensors:
      el_price_0h:
        friendly_name: "Sähkön hinta +0h"
        unit_of_measurement: "c/kWh"
        value_template: >-
          {{ state_attr('sensor.spot_price', 'PriceWithTax') | float * 100 }}
      el_price_0h_rank:
        friendly_name: "Sähkön hinta +0h Rank"
        unit_of_measurement: "c/kWh"
        value_template: >-
          {{ state_attr('sensor.spot_price', 'Rank') | int }}
      el_price_1h:
        friendly_name: "Sähkön hinta +1h"
        unit_of_measurement: "c/kWh"
        value_template: >-
          {{ state_attr('sensor.spot_price_1h', 'PriceWithTax') | float * 100 }}

Ja viimeisenä keskiarvon muodostaminen tuleville tunneille:

YAML:
  - platform: min_max
    name: "Sähkö +4h keskihinta"
    type: mean
    round_digits: 3
    entity_ids:
      - sensor.el_price_1h
      - sensor.el_price_2h
      - sensor.el_price_3h
      - sensor.el_price_4h

Eihän tämä nyt enää yksinkertaista ole, mutta onnistuu ihan HA:n omin rakennuspalikoin ja yleisesti tunnetuilla komentoriviryökaluilla curl ja jq. Eikä rasita API:a liian usein toistuvilla tarpeettomilla pyynnöillä.
 

pamppu

Vakionaama
Näetkö @dbwarrior että mikä on HTTP statuskoodi ollut noissa virhetilanteissa? En ihan päässyt kiinni, mikä ongelma on... mutta koskaan ei saa olettaa koodauksessa että joku asia toimii _aina_ :)

Tuossahan logissa oli ”name does not resolve”, eli paikallinen DNS -ongelma, ei tuo ole edes päässyt yrittämään apia.
 

VesA

In Memoriam
Tuossahan logissa oli ”name does not resolve”, eli paikallinen DNS -ongelma, ei tuo ole edes päässyt yrittämään apia.
Ainakin meidän Huawei:n 5G-purkki koittaa toimia jonkinlaisena DNS proxyna / cachena ja sotkee DNS-pyyntöjä - erityisesti Microsoftin kovin monikerroksiset ja runsaat CNAME listat aiheuttavat sen että se lopullinen A-recordi ei koskaan tule.
 

Jullikka

Jäsen
Itse toteutin lopulta tämän niin, että haen API:lta TodayAndDayForward ja talletan sen tiedostoon (muistaakseni tunnin välein, mutta voisi se olla paljon harvemminkin). Ja sitten luen tiedostosta arvot tälle tunnille sekä neljälle seuraavalle tunnille. Näin API:a ei oikeastaan tarvitse kovin usein kutsua.

Jokin tässä jäi vielä itseäni kaivelemaan, mutta en enää muista, että mikä. Hyvin tämä on ainakin toiminut.

Neljä seuraavaa tuntia haen siksi, että pystyn näyttämään mihin suuntaan hinta on kehittymässä ja samalla lasken niille tunneille myös keskiarvon.

Itse konfiguraatio taitaa olla jossain täällä jo, mutta kopioidaan tähän nyt joka tapauksessa.

Downloaderin enablointi:

YAML:
downloader:
  download_dir: downloads

Automaatio, joka hakee hinnat tiedostoon:

YAML:
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://api.spot-hinta.fi/TodayAndDayForward
      filename: spot-prices.json
      overwrite: true
mode: single

Sensorit (tässä vain nykyhetki ja seuraava tunti), jotka päivittyvät usein, tosin ihan paikallisena operaationa, joka vain parsii hinnat aiemmin haetusta tiedostosta:

YAML:
sensor:
  - platform: command_line
    name: "Spot price"
    scan_interval: 15
    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"
    scan_interval: 15
    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
Itse toteutin sinun esimerkillä samaan tapaan tiedoston lataukseen asti, tiedosto haetaan klo 14:55.

Sen jälkeen aiemmin haetusta tiedostosta, eli ennustettavista tunneista seuraavaan päivään klo 15 saakka jaetaan 8 kallista ja 8 halpaa tuntia omiksi tiedostoiksi, alla olevalla komennolla, tämä siis configuration.yaml-tiedostossa:

shell_command:
spot_kalliit_tunnit: jq '[.[15:40] | sort_by(.PriceWithTax) | reverse | limit(8; .[])] | sort_by(.DateTime)' downloads/spot-prices.json > downloads/kalliit-tunnit.json
spot_halvat_tunnit: jq '[.[15:40] | sort_by(.PriceWithTax) | limit(8; .[])] | sort_by(.DateTime)' downloads/spot-prices.json > downloads/halvat-tunnit.json

Tämän jälkeen haetaan seuraava halpa/kallis tunti sensoreihin:
- platform: command_line
unique_id: seuraava_halpa_tunti
name: "Seuraava halpa tunti"
command: jq --arg timestamp "{{ as_timestamp(now()) | timestamp_custom('%Y-%m-%dT%H') }}" '[.[] | select(.DateTime >= $timestamp) | .] | sort_by(.DateTime) | .[0]' downloads/halvat-tunnit.json
json_attributes:
- DateTime
- PriceWithTax
- PriceNoTax
- Rank
- platform: command_line
unique_id: seuraava_kallis_tunti
name: "Seuraava kallis tunti"
command: jq --arg timestamp "{{ as_timestamp(now()) | timestamp_custom('%Y-%m-%dT%H') }}" '[.[] | select(.DateTime >= $timestamp) | .] | sort_by(.DateTime) | .[0]' downloads/kalliit-tunnit.json
json_attributes:
- DateTime
- PriceWithTax
- PriceNoTax
- Rank
- platform: template
sensors:
seuraavan_halvan_tunnin_ajankohta:
unique_id: "ajankohta_seuraava_halpa_tunti"
friendly_name: "Seuraavan halvan tunnin ajankohta"
value_template: >
{% set halpa = as_timestamp(state_attr('sensor.seuraava_halpa_tunti', 'DateTime')) | timestamp_custom("%a %d %m %H:%M") %}
{{ halpa }}
seuraavan_kalliin_tunnin_ajankohta:
unique_id: "ajankohta_seuraava_kallis_tunti"
friendly_name: "Seuraavan kalliin tunnin ajankohta"
value_template: >
{% set kallis = as_timestamp(state_attr('sensor.seuraava_kallis_tunti', 'DateTime')) | timestamp_custom("%a %d %m %H:%M") %}
{{ kallis }}

Näitä sensoreita käytetään sitten automaatiossa, näyttää osimoilleen alla olevalta. Ennen seuraavan päivän hintojen julkaisua keskihinta näyttää samaa tälle päivälle ja huomiselle, koska ne lasketaan kerran vuorokaudessa.
1666336847982.png



Summa summarum, tapoja on monia, tämäkään tuskin täydellinen.
 

seppos

Jäsen
EDIT 20221026: Sehän toimi kuten pitää..
Käyttö yhä omalla vastuulla, pyörii nyt tuossa pöytä Shellyssäni, ei edes vielä minulla sähkökaapissa



Laiton juuri hyvin beta-version shelly-scriptistäni
https://github.com/sutinse/shelly

Varsinainen scripti

On hyvin beta, muutaman tunnin olen reposta löytyvän node.js:n ominaisuuksia siirtänyt.
Olen pyöritellyt nyt teon aikaan pöydälläni jatkojohtoon liittämässäni Shelly 2.5PM, en vielä laittanut ohjaamaan sähkökeskukseen Shelly Pro 4PM:ää (rouvan pelko, että beta-koodi ei toimi...)

Shellyn tukema mJS on niin rajoittunut, mutta niiiiin kiinnostava. Vihdoinkin microprosessoriin saa omaa logiikaa ilman c/c++.
mJS ei tue esim. Date-olioita, joten on haettava Shellyltä config, jossa palauttuu kellonaika (hh:mm)
Javascript ei ole minun natiivin kieli (java on)...

Hintojen hakuun käyttää Mikkin loistavia rajapintoja
Yleiskonfig:
  • kuinka usein ajastin looppaa, esim 1min välein
  • Fallback -aikaväli (esim 01-05) jolloin laite on päällä, jos hintoja ei saada haettua
Laitteen eri outputille voi määritellä
  • hommankumman profiilin
  • tuntimäärän jonka laite on päällä profiilin mukaisesti
Hinnat haetaan kerran aina tunnin vaihtuessa (jos ensimmäisellä ajastin kerralla ei saada, yritetään uudestaan seuraavalla kerralla, aina joka loop kerralla yritetään).
Jos hintoja ei saada haettua, käytetään Fallback-aikoja.

Profiili1:
Profiili2:
  • esim lämminvesivaraaja
  • Hakee peräkkäiset halvimmat tunnit
  • Kuinka monta peräkkäistä tuntia (esim 3h) laite on päällä

Jos joku kokeilee käyttää ja on ongelmia, voisi lisäillä tuonne githubin issue...

Muutamat printtaukset (mm. hintojen hausta voi halutessaan poistaa...)

// TODO
Jossain vaiheesa kun taas aikaa löytyy, voisi toteuttaa tuon halpojen hintojen aikaan päälläolon...
Ja kaivaa kuinka mJS:ssä saa number konvertoitua Stringiksi...

Toteutukseen apuna oli tuo hieman simppelimpi


Toiminta testattu 26.10.2022
- halvimmat ajat ti 25.2022 klo 21-24
- halvimmat ajat ke 26.2022 klo 00-01 (rank 3) sekä 01-04 (rank 1,2,4)

Profiili 1 suoritus, asetettu config halvimmat peräkkäiset tunnit: 3h
21:01:16 päälle
00:01:16 pois
02:01:16 päälle
05:01:16 pois

Profiili 0 suoritus: asetettu config halvimmat mitkä tahansa tunnit: 4 h
21:01:16 päälle
01:01:16 pois (tunti 00-01 rank 3, pitää pysyä päällä)
02:01:16 päälle
05:01:16 pois
Sinällään tulee "hassu" tulos kun kahden vuorokauden halvimmat tunnit on likes pötköön 21-05, vuorokausi vaihtuu vain välissä. Tulee yli 1.5 vuorokauden katko ensimmäiseen vuorokautteen kun aika alkaa vasta 21.
Mutta säästää toki eniten.
 

Liitteet

  • ShellyPeriodPrices3h.png
    ShellyPeriodPrices3h.png
    176,3 KB · Katsottu: 140
  • ShellyRankedPrices4h.png
    ShellyRankedPrices4h.png
    167,9 KB · Katsottu: 124
Viimeksi muokattu:

hanks

Aktiivinen jäsen
Ny sain pari uutta Lolin D1 Miniä ja yritin kokeilla tehdä MLP:n pörssisähköohjauksen ESPHomella. En ole aikaisemmin koodaillut Home Assistant juttuja, ja oppimiskäyrä on aika jyrkkä. Jokainen muutos YAML-konffiin vaan vaatii mikrokontrollerin uuden ohjelmoinnin ja flässäyksen mikä hidastaa oppimista. Lisäksi ESPHomessa ei ole kaikkia komponentteja saatavilla, kokeilin tuota ttk2:n esimerkkiä, niin tyssäsi heti ekaan, tuohon downloaderiin.

ESPHomessa olis kuitenkin http_request ja JSON:iakin se osaa parsia. Sain aikaiseksi yksinkertaisen koodin joka hakee senhetkiset hintatiedot, mutta kun pitäis alkaa parsimaan JSON:ia, niin muisti loppuu kesken. Tämmönen virhe tuli logiin.

Koodi:
[11:08:00][E][json:073]: Could not allocate memory for JSON document! Requested 0 bytes, free heap: 34544
[11:08:00][W][http_request:081]: HTTP Request failed; URL: http://http://api.spot-hinta.fi/JustNow; Error: connection failed

Että se siitä...

tämmöisen koodin sain aikaiseksi (tuo 1 minuutin intervalli oli testiä varten).

Koodi:
http_request:
  esp8266_disable_ssl_support: true
  useragent: esphome/esp32dev
  id: http_request_data

time:
  - platform: homeassistant
    id: homeassistant_time
    timezone: Europe/Helsinki

    on_time:
      - seconds: 0
        minutes: /1
        then:
          - http_request.get:
              url: http://http://api.spot-hinta.fi/JustNow
              verify_ssl: false
              on_response:
                then:
                  - lambda: |-
                      json::parse_json(id(http_request_data).get_string(), [](JsonObject root) {
                        id(rank).publish_state(root["Rank"]);
                      });

sensor:
  - platform: template
    name: "Rank"
    id: rank
    icon: mdi:chevron_double_up

Toki voisin tehdä täysin saman toiminnallisuuden kuin ESPEasyssä käyttäen JustNowRank apia, mutta en tiedä olisiko siitä jotakin iloa. No saisi siitä jotakin infoa Home Assistantin dashboardille, mutta pahaksi onneksi hintatietoja ei kun JSON:in parsimiseen ei muisti riitä.

Muuten, tuli mieleen että miten YAML:iin voi koodata "alirutiinin" tuon http API:n kutsumiseen ja vastauksen parsimiseen, jotta sen voisi liipaista bootin jälkeen ja ajastetusti kerran tunnissa. Tuntuu hölmöltä että sama koodi pitäisi kirjoittaa kahteen kertaan.
 

Temez

Aktiivinen jäsen
ESPHomessa olis kuitenkin http_request ja JSON:iakin se osaa parsia. Sain aikaiseksi yksinkertaisen koodin joka hakee senhetkiset hintatiedot, mutta kun pitäis alkaa parsimaan JSON:ia, niin muisti loppuu kesken. Tämmönen virhe tuli logiin.
Tulkitsin, että sinulla pyörii myös HomeAssistant. Silloin ei kannata ladata ESPin kautta noita hintatietoja vaan voit laittaa HomeAssistantin lataamaan tiedot suoraan. Tässä custom_componenttina (ei virallisesti tuettu integraatio, mutta yhteisö tukee best efforttina) Nordpoolin hinnanlatauksiin: https://github.com/custom-components/nordpool . Vaihtoehtoisesti jollakulla taisikin olla jo esimerkkikoodia, joka latailee tästä api.spot-hinta.fi:stä dataa myös (kuten esim. tuo ttk2:sen) Home Assistantiin ilman ESPHomea tai mikrokontrolleria (tosiaan tuo ttk2:sen koodi ei liity ESPHomeen vaan on HomeAssistantin YAML-konfiguraatiota).

Tuolla Nordpoolin Custom Componentilla saa tämmöistä ulos (attribuuteissa myös tuntihinnat tulevaisuuteen):
1666516481046.png

Käytän itse ESPHomea sitten laitteiden komentamiseen eli esimerkiksi vastuskäytön kieltoon omassa PILPissäni. ESPHomella sille mikrokontrollerille vain kerrottu, että "sinulla on tämmöinen rele/anturi pinnissä 5" ja sitten kaikki loppulogiikat ovat minulla Home Assistantin puolella (lukuunottamatta sellaisia, joiden pitää toimia vaikka wifi olisi särki - minulla ESPHomen automatiikka esimerkiksi sallii vastukset automaattisesti ilman eri komentoa, jos kattilan lämpötila laskee jostain syystä todella alas).

Tällöin vältät myös sen, ettei tarvitse koko aikaa olla ohjelmoimassa ESPiä uusiksi (vaikka se suhteellisen näppärää wifin yli onkin).
Pitäisiköhän tästä avata jokin oma lankansa näille HomeAssistantin puolella tehtäville koodeille? (Ja ehkä jokin selostus, että missä tapauksessa esphomella olisi järkevää ladata dataa suoraan ja milloin HomeAssistantilla.) Olisi ehkä aloittelijoille selkeämpi, ettei ole kahta eri paikkoihin tarkoitettua yaml-koodia sekaisin.
 

hanks

Aktiivinen jäsen
Tulkitsin, että sinulla pyörii myös HomeAssistant. Silloin ei kannata ladata ESPin kautta noita hintatietoja vaan voit laittaa HomeAssistantin lataamaan tiedot suoraan.
Totta, aprikoin tätä itsekin, mutta kun tuli lähdettyä samasta tilanteesta missä oltiin ESPEasyn kanssa ilman mitään "keskusjohtoa". Oma lanka olis poikaa HomeAssistant virittelyille, ettei sotketa tätä.

Ja kaiken lisäksi löysin bugin tuosta ylläolevasta koodista

Koodi:
          - http_request.get:
              url: http://http://api.spot-hinta.fi/JustNow

Copy-paste virheestä johtuen tuossa on http:// kahteen kertaan. Korjasin tuon, ja ihme ja kumma homma alkoikin toimimaan, ja muistikin riitti. Oli hieman harhaanjohtava se virheilmoitus aiemmin.
 

Temez

Aktiivinen jäsen
Home Assistantin puolesta löytyykin mukavasti Googlella hyviä esimerkkejä ja saa myös kivat käppyrät ohjeiden mukaan HomeAssistantin Dashboardille ihmeteltäväksi: https://www.creatingsmarthome.com/i...d-how-to-automate-devices-for-cheapest-hours/

Tuolla blogissa siis asennusohjeita, kuvaajakäppyröiden konffausohjeet Dashboardille ja sitten koodia, joka etsii x tunnin pituisen halvimman jakson. Meinasin alkaa selittämään tänne omia konffejani, mutta helpommalla taitaa sekä allekirjoittanut että muu lukija selvitä, kun katsoo valmista materiaalia eikä minun tajunnanvirtaa :) Soveltamisvaihtoehtoja sitten on tosiaan monia.

Alla nyt kuitenkin kiellon päälle itse käyttämäni template-sensori, joka palauttaa automaatioille True 7 kalleimman tunnin kohdalla, jos veroton hinta tuolloin on yli 10c/kwh.
YAML:
  - sensor:
    - name: "Nordpool expensive hours" # 7 most expensive hours will result in true
      state: >
            {{ states('sensor.nordpool_kwh_fi_eur_3_10_0') | float > 0.1 and (state_attr('sensor.nordpool_kwh_fi_eur_3_10_0','today') | sort(reverse=True))[6] <= states('sensor.nordpool_kwh_fi_eur_3_10_0') | float  }}
 

piizei

Tulokas
Loistava API, suuren kiitokset Mikille!

Säästi ison työn itseltäni, ja varmasti monelta muulta, sorttailla ja rankittää tuntihinnat. Sain helposti tehtyä Home Assistantille perus ohjaukset maalämpöpumpule Shelly releen kautta. Nyt haluaisin tarkemmin visualisoida, mitä kuluvana päivän tulee tapahtumaan sekä lisätä ohjaus parametreja ja logiikkaa. Törmäsin uutena HA säätäjänä sen puutteisiin aika nopeasti. JSON viestien (esim arrayt) käsittely tuntuu olevan erittäin haastavaa, enkä järkevää tapa edes löytänyt nopealla googlailulla. 255 merkin rajoite sensorin statelle taitaa isoimmat rajoitteet aiheuttaa.

Tuosta tuli mieleen API:lle kehitys ehdotus, mikä olisi varmaan aika helppo tehdä, ja sallisi paljon uusia HA Dashboard parannuksia. Olisi hyvä, jos voisi pyytää tietyn rankin hinnan kuluneelta päivältä tyyliin https://api.spot-hinta.fi/PriceOfRank/{rank} . Sallisi helpommin tehtäväksi ohjauslogiikkaa, missä parametreinä sekä päivän rank että max tai min hinta.

Tai vaihtoehtoisesti, osaako joku kertoa, miten isompia json responseja pystyisi järkevästi HA:ssa pyörittelemään? Joku tässä ketjussa oli laittanut ne omaan tiedostoon ja sieltä jq:lla luki, mutta menee sen verran paljon HA natiivi ominaisuuksien ohi, etten ihan ensimmäisenä tuolle tielle haluaisi lähteä.
 

ttk2

Aktiivinen jäsen
Yksi vaihtoehto on mqtt, jonka avulla voi "julkaista" paljon suurempia payloadeja kuin 255 merkkiä pitkiä. Julkaistavalle viestille voi laittaa myös retain: true, jolloin arvo pysyy tallessa/luettavissa kunnes sen yli kirjoitetaan uusi arvo.

En ole tätä itse käyttänyt, mutta Googlaamalla on tullut vastaan. Pitää tutustua paremmalla ajalla.

Mikään pakko ei ole mqtt topic:iin kirjoittaa koko json-sanomaa, vaan voi parsia siitä haluamansa osat ja tallettaa ne osat. Tai sitten tallettaa mqtt:n avulla sen alkuperäisen json-sanoman ja myöhemmin parsii sitä sieltä ja tallettaa parsitutkin osat mqtt:n avulla.

Tämä nyt ainakin on "ha-natiivi" keino.

Mikki on myös ollut myötämielinen toteuttamaan lisäyksiä API:n silloin, kun niissä on hyvä ja laajasti käytettävissä oleva ajatus taustalla.
 

seppos

Jäsen
@Mikki
Saisiko vielä pienen lisäyksen tuohon halvimman periodin hakuun?

Tuo nykyinen
https://api.spot-hinta.fi/CheapestPeriod/3
palauttaa näköjään aina kysytyn kellonajan jälkeisen halvimman hetken (kuten on järkevää).

Aiheuttaa sen, että kun Shelly scriptissä käyn hakemassa aina tunnin vaihtuessa, periodin "pakenee"...
Nyt iffittelen että haetaan vain scriptin startissa tai vuorokauden vaihtuessa.
Sama saattaa tulla HA-miehillä vastaan.

eli jos voisi kysyä päivän halvimman jakson tyyliin
https://api.spot-hinta.fi/CheapestPeriod/3/Today
Palauttaisi siis saman päivän periodin (sinällään Green Coding mielessä käydä kysymässä samaa vastausta, mutta jos nämä hinnat joskus ovat dynaamisempia. Nyt haen vain aina tunnin vaihtuessa, eli 24 kertaa päivässä).
 

Mikki

Hyperaktiivi
Tuosta tuli mieleen API:lle kehitys ehdotus, mikä olisi varmaan aika helppo tehdä, ja sallisi paljon uusia HA Dashboard parannuksia. Olisi hyvä, jos voisi pyytää tietyn rankin hinnan kuluneelta päivältä tyyliin https://api.spot-hinta.fi/PriceOfRank/{rank} . Sallisi helpommin tehtäväksi ohjauslogiikkaa, missä parametreinä sekä päivän rank että max tai min hinta.

En ole nyt täysin varma ymmärsinkö tarpeen oikein. Mutta toimisiko tämmöinen ratkaisuna tarpeeseesi:

Eli palauttaa tuolla viimeisellä arvolla valitun "rankin" tiedot. Jos toimii ja keksit näille käyttöä HA:ssa, niin pistä pari mallikuvaa millaisen lopputuloksen sait aikaan. Ja muistutuksena, että API dokumentaatiota yritän ylläpitää täällä: https://api.spot-hinta.fi/swagger/ui
 
Viimeksi muokattu:

Mikki

Hyperaktiivi
@Mikki
Saisiko vielä pienen lisäyksen tuohon halvimman periodin hakuun?

Tuo nykyinen
https://api.spot-hinta.fi/CheapestPeriod/3
palauttaa näköjään aina kysytyn kellonajan jälkeisen halvimman hetken (kuten on järkevää).

Aiheuttaa sen, että kun Shelly scriptissä käyn hakemassa aina tunnin vaihtuessa, periodin "pakenee"...
Nyt iffittelen että haetaan vain scriptin startissa tai vuorokauden vaihtuessa.
Sama saattaa tulla HA-miehillä vastaan.

eli jos voisi kysyä päivän halvimman jakson tyyliin: https://api.spot-hinta.fi/CheapestPeriod/3/Today
Hmm.... Aika nopeasti jakso menee sitten historiaan, kun halvimmat tunnit tyypillisesti on aamuyönä. Ehkä tämän rajapinnan tarkoitus on kuitenkin tuumia vain eteenpäin asioita, eikä taaksepäin missään tilanteessa.
 
Moi!

Kiitos @Mikki erinomaisesta rajapinnasta! Rakentelin kaksi Shelly 1:sta, toinen huijaa lämpöpumpun (IVT HE17) ulkoanturia isolle lämpötilalle (manuaalisesti säädettävissä, 8-asentoinen kytkin, -40...+30) ja toinen pienelle lämpötilalle (samanlainen kuin se toinen). Jos kummankaan Shellyn rele ei vedä, silloin IVT menee oman lämpökäyrän mukaan.

Nyt haluaisin shellyjen toimivan näin:
- Eka shelly: tunti nyt on vuorokauden x kalleimman tunnin joukossa JA hinta on yli y, silloin rele päälle (IVT:lle korkea lämpötilatieto).
- Toinen shelly: tunti nyt on vuorokauden x halvimman tunnin joukossa ja JA hinta on alle y, silloin rele päälle (IVT:lle matala lämpötilatieto).

Tuolla saisi MLP:tä huijattua kumpaankin suuntaan, mutta vain silloin kun hinnan puolesta tarvitaan.

Olisiko jollain valmista Shelly-skriptikoodia? Javaa opiskelin 20 vuotta sitten, kai sen muistaisi jos alkaisi miettiä mutta osaatteko auttaa nopeammin? ;-)

-Antti
 

Mikki

Hyperaktiivi
Kiitos @Mikki erinomaisesta rajapinnasta!
......
Nyt haluaisin shellyjen toimivan näin:
- Eka shelly: tunti nyt on vuorokauden x kalleimman tunnin joukossa JA hinta on yli y, silloin rele päälle (IVT:lle korkea lämpötilatieto).
- Toinen shelly: tunti nyt on vuorokauden x halvimman tunnin joukossa ja JA hinta on alle y, silloin rele päälle (IVT:lle matala lämpötilatieto).
....
Olisiko jollain valmista Shelly-skriptikoodia? Javaa opiskelin 20 vuotta sitten, kai sen muistaisi jos alkaisi miettiä mutta osaatteko auttaa nopeammin? ;-)

Eipä kestä. Ja tuolta löydät skriptin pohjaksi, joita vähän tuunaamalla voit tehdä mainitsemasi asiat:
 

seppos

Jäsen
Hmm.... Aika nopeasti jakso menee sitten historiaan, kun halvimmat tunnit tyypillisesti on aamuyönä. Ehkä tämän rajapinnan tarkoitus on kuitenkin tuumia vain eteenpäin asioita, eikä taaksepäin missään tilanteessa.

Pikkaisen argumentoin vastaan...
esim. Today rajapinta palauttaa koko päivän tiedot

Samoin voisi olla tuo halvin jakso, että on mahdollisuus kysyä minä aikana tahansa halvinta jaksoa päivässä
Nykyinen /CheapestPeriod/{hours} voisi säilyä, mutta kysyttäessä
/CheapestPeriod/{hours}/Today palauttaisi vuorokauden halvimman periodin.

Nythän jos kysyn klo 01 tuota /CheapestPeriod/{hours}, se palauttanee todennäköisesti jakson 02-05
Jos kysyn sitä nyt, klo 16:25, palauttaa
{
"DateTimeStart": "2022-10-24T21:00:00+03:00",
"DateTimeEnd": "2022-10-24T23:59:59+03:00",
"AveragePriceNoTax": 0.1854,
"AveragePriceWithTax": 0.2299
}
Liikkuva maali... Toisin pärjään kyllä tuolla vuorokauden vaihtuessa tehtävällä yhdelläkin kutsulla vuorokaudessa, on tietysti Green Coding mukaista, vältetään tekemästä turhia kutsuja...
 

Mikki

Hyperaktiivi
Noniin, nyt pitäisi toimia huomisen hinnat. Entso-E ei edelleenkään niitä palauta, mutta nyt on varalähde tiedolle klo 16:00 jälkeen ellei seuraavan päivän tietoja ole löydetty Entso-E kautta.
 

jmaja

Hyperaktiivi
Ei näytä vieläkään toimivan eikä nopeasti katsottuna ole mitään vikatiedotettakaan. Vai onko vika Nord Poolissa?
 

jmaja

Hyperaktiivi
Noniin, nyt pitäisi toimia huomisen hinnat. Entso-E ei edelleenkään niitä palauta, mutta nyt on varalähde tiedolle klo 16:00 jälkeen ellei seuraavan päivän tietoja ole löydetty Entso-E kautta.
Kiitos! Mikäs on varalähde? Ilmeisesti kesken edellisen kirjoitukseni alkoi pelittää.
 

Mikki

Hyperaktiivi
Kiitos! Mikäs on varalähde? Ilmeisesti kesken edellisen kirjoitukseni alkoi pelittää.
Krhm... sylttytehtaiden suunnalta se tulee, mutta jätetään mainitsematta kun tuota toivottavasti ei tarvitse käyttää. Pitäytyisin mieluummin ihan tuossa Entso-E:ssä.

Mutta en tosiaan löydä mitään syytä, miksei tiedot välity sen kautta nyt.
 

Olli K

Jäsen
Näitä päiviä on silloin tällöin. Syystä tai toisesta datan siirto NordPoolilta EntsoE:lle ei ole hirveän luotettava ja ilmeisesti jos kerran siirto epäonnistunut, niin päivän hintatiedot eivät myöhemminkään täydenny.

Laitoin huvikseni tästä huomautuksen Twitteriin . Kuka sattuu Twitteriä käyttämään, niin voi halutessaan käydä nostamassa tälle huomiota. En siis käytä tätä APIa, mutta huomasin saman ongelman puuttuvista tiedoista koodaamani Arskan kanssa.
 

Sukke

Aktiivinen jäsen
Toisessa ketjussa oli maininta, että Ylen teksti-tv:n sivulta löytyy myös tuntihinnat. Olisikohan nekin API:n kautta haettavissa. Siinäpä illalle tutustuttavaa.
 

hanks

Aktiivinen jäsen
API:ssa ei tainnut talviaikaan siirtyminen mennä oikein. Vai johtuuko ENTSO-E:stä?

10CFA4F5-F44A-4074-BBB8-64C7031884A9.jpeg
C03B33B6-38DC-4D89-B542-B93B0FC0CE56.jpeg
 
Viimeksi muokattu:

Mikki

Hyperaktiivi
Blah tätä tyhmää kellonkääntöä. Voi olla että meni arvaus väärin miten tuo Entso toimii.
 

Mikki

Hyperaktiivi
Tuo EntsoE rajapinta on kyllä aika ärsyttävä. Siinä on tämmöinen rakenne mitä pitää parsia.... siis alkuaika, loppuaika ja sitten "positiot" välillä. Tuo resolution sitten kertoo mikä on tuo "position".

Tuossa on vain se ero tavalliseen päivään että on 25 tuntia. Tosi rasittava loppujenlopuksi kun tuohon koodailee logiikan miten se kellonaika vaihtuu. Murr.... Olisi pikkuisen fiksumpi kun tuossa "position" kohdassa olisi kellonaika eikä typerä juokseva numero.

Mutta spot-hinta.fi tarkoitus on juuri tämä shaisse piilottaa. :)

1667147983446.png
 
Viimeksi muokattu:
Back
Ylös Bottom