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

mobbe

Vakionaama

jamo1

Jäsen
Yhden kärjen peräs AEG ls07 ja Telemecanique kaataa välil shellyn, Hager E321 ei aiheuta ongelmia. Vaikka näyttö menee pimeeks, scriptit jää taustalle pyörimään. Näyttö herää henkiin kun käyttää virrat pois.
 

Majava

Tulokas
Tätä ei mielestäni tarvitse tehdä. HA kyllä osaa muodostaa sen id:n itsekin ihan hyvin. Esim. "Sähkön hinta +1h" -> "sensor.sahkon_hinta_1h".

Yleisesti ottaen kannattaa tänne noita konffeja kopioidessa käyttää suoraan "koodiblokkia", eli viestieditorista valitsee kuvasymbolin oikealta puolelta kolme pistettä ja sen alta </>, joka avaa dialogin, johon koodin voi liittää. Tyypiksi jos laittaa yaml noille HA:n konffeille, niin lukija saa helpommin koodista selvää.

Sisennykset etenkin ovat sellaisia, joita ei oikein muuten saa tarkistettua. Itsekin uskon, että sisennykset tuolla nyt ovat olleet pielessä.
YAML:
# Loads default set of integrations. Do not remove.
default_config:
automation: !include automations.yaml

# Text to speech
tts:
  - platform: google_translate
sensor:
  - platform: rest
    name: "Sähkön hinta"
    resource: https://api.spot-hinta.fi/JustNow
    method: GET
    device_class: monetary
    force_update: true
    json_attributes:
      - DateTime
      - PriceWithTax
      - PriceNoTax
      - Rank
    state_class: measurement
platform: template
sensors:
      el_price:
        friendly_name: "Sähkön hinta nyt"
        unit_of_measurement: "c/kWh"
        value_template: "{{ state_attr('sensor.sahkon_hinta', 'PriceWithTax') | float * 100 }}"
      el_price_rank:
        friendly_name: "Sähkön hinnan järjestysluku"
        value_template: "{{ state_attr('sensor.sahkon_hinta', 'Rank') | int }}"

No nyt varmaan saa paremmin selvää, eilen kiiressä nakkasin copy pastet sen enempää miettimättä lopputulosta.
Löytyykö jostain ohjeet miten sisennykset kuuluu tehdä jotta menee oikein?
Tällaiset herjat tälläkertaa
Integration error: sensors - Integration 'sensors' not found.
Integration error: platform - Integration 'platform' not found.
 

Mikki

Hyperaktiivi
Tuossa se taitaa ainakin mättää... siis pitäisi rakenne olla kai näin tuossa lopussa. Siis sisennykset ja viiva puuttuu....

YAML:
- platform: template
    sensors:
      el_price:
        friendly_name: "Sähkön hinta nyt"
        unit_of_measurement: "c/kWh"
        value_template: "{{ state_attr('sensor.sahkon_hinta', 'PriceWithTax') | float * 100 }}"
      el_price_rank:
        friendly_name: "Sähkön hinnan järjestysluku"
        value_template: "{{ state_attr('sensor.sahkon_hinta', 'Rank') | int }}"
 

janti

Moderaattori
Ylläpidon jäsen
Onko kukaan kokeillut IFFT yhdistämistä tähän APIin? Mulla olisi IFFT yhdistettynä yksi Nediksen älypistorasia, jolla voisi kokeilla tätä pörssisähköohjausta. :cool:

EDF:llä (Ranskassa) on tuolla IFFT:ssä oma kytkentä pörssisähköohjaukseen

Samoin Elektrumilla (Virossa)

=> Koskahan tulee Fingrid? :cool:
 
Viimeksi muokattu:

mobbe

Vakionaama
Ei näillä mitään järkevää saa aikaiseksi etenkin lämmityksen ohjaukseen tarvitaan enemmän älyä kuin tuntihinta onko alle tai yli hintarajan lisäksi pilvipalveluita ohjaukseen pitäisi pyrkiä välttämään
 

Mikki

Hyperaktiivi
Viimeksi muokattu:

ttk2

Aktiivinen jäsen
En tiedä mitään niin typerää ideaa, kuin rakentaa ohjelmointikieli, jossa koodin ulkonäkö vaikuttaa sen toimintaan. Onkohan tuon yamlin takana sama aivokuollut porukka, joka on python-kielen oksentanut.
Hehehe, sattumalta itselleni tuo Python on aina sopinut hyvin käteen. Niin sitä ollaan erilaisia.

YAML on kaiketi saanut alkunsa, koska xml:n käyttäminen on moneen tarkoitukseen turhan hankalaa. Wikipedian mukaan:

YAML is a human-readable data-serialization language.

Tuotahan käytetään kyllä monessa paikassa, mm. Ansiblen konffeissa HA:n lisäksi.

Se on kyllä totta, että notepadin kanssa toimiessa sekä Python että YAML ovat molemmat ikäviä tuottaa. Toisaalta taas Vi ja Emacs pärjäävät noiden kanssa mainiosti ja sehän riittää, koska miksi vaihtaa editoria aina joka 30:s vuosi? :grandpa:

Mielestäni on ollut kuitenkin aika huono idea valita YAML HA:n konfiguraatioiden kieleksi. Se on harrastajille ja kehittäjille varmaan ihan hyvä vaihtoehto, mutta todennäköisesti on hidastanut HA:n käyttöönottoa ja leviämistä. Toisaalta moni asia (koko ajan enemmän ja enemmän) onnistuu käyttöliittymästä ilman tiedostojen editointia ja YAML on siellä vain taustalla.

Juuri siksi olisi käyttäjäystävällisempää, jos tämä Mikin API olisi käytettävissä HA:ssa oman integraationsa kautta omalla käyttöliittymällään. Kyllä sen joku näppärä vielä tekee, jos API pysyy käytössä tarpeeksi pitkään ja käytön määrä kasvaa nykyisellä kulmakertoimella.

API on varmaan kohta valmiina levitettäväksi myös muille Entso-E hinta-alueille :)
 

Sukke

Aktiivinen jäsen
Hehehe, sattumalta itselleni tuo Python on aina sopinut hyvin käteen. Niin sitä ollaan erilaisia.

YAML on kaiketi saanut alkunsa, koska xml:n käyttäminen on moneen tarkoitukseen turhan hankalaa. Wikipedian mukaan:

YAML is a human-readable data-serialization language.

Tuotahan käytetään kyllä monessa paikassa, mm. Ansiblen konffeissa HA:n lisäksi.

Se on kyllä totta, että notepadin kanssa toimiessa sekä Python että YAML ovat molemmat ikäviä tuottaa. Toisaalta taas Vi ja Emacs pärjäävät noiden kanssa mainiosti ja sehän riittää, koska miksi vaihtaa editoria aina joka 30:s vuosi? :grandpa:

Mielestäni on ollut kuitenkin aika huono idea valita YAML HA:n konfiguraatioiden kieleksi. Se on harrastajille ja kehittäjille varmaan ihan hyvä vaihtoehto, mutta todennäköisesti on hidastanut HA:n käyttöönottoa ja leviämistä. Toisaalta moni asia (koko ajan enemmän ja enemmän) onnistuu käyttöliittymästä ilman tiedostojen editointia ja YAML on siellä vain taustalla.

Juuri siksi olisi käyttäjäystävällisempää, jos tämä Mikin API olisi käytettävissä HA:ssa oman integraationsa kautta omalla käyttöliittymällään. Kyllä sen joku näppärä vielä tekee, jos API pysyy käytössä tarpeeksi pitkään ja käytön määrä kasvaa nykyisellä kulmakertoimella.

API on varmaan kohta valmiina levitettäväksi myös muille Entso-E hinta-alueille :)

Lähdin jokin aika sitten vasta-alkajana kokeilemaan Pythonia. Sainkin kaikenlaista hauskaa tehtyä, mutta totesin, ettei siitä Home Assistantin kanssa ole hyötyä. Tai olisi siitä, mutta Node Red on osoittautunut itselleni oivaksi työkaluksi. Toki sitä varten joudun opettelemaan JavaScriptiä.

Virheellisistä sisennyksistä ei ole kyllä minkäänlaista ongelmaa, jos vain valitsee sopivan ohjelman. PyCharmin kanssa Pythonin naputtelu oli aloittelijallekin lähes tulkoon ilo. Ja kielestähän oppii helposti perusteet, vaikka itsellänikin ainoa kunnon kosketus ohjelmointiin on yksi 5 op kurssi joskus 10+ vuotta sitten. Tein Pythonilla jo itselleni tuntihintojen haun Entsoe-e:sta ja samoin säätietojen haun Yr.no-rajapinnasta. Lisäksi ehdin naputella jo datojen käsittelyä, kunnes hoksasin, että HA:n kanssa on toinenkin vaihtoehto.

Mutta asiaan (tai offtopiciin): kannattaa asentaa Home Assistantiin lisäosa Studio Code Server. Tuon kanssa ei sisennykset mene väärin ja taitaa se muistakin virheellisyyksistä ilmoitella. Olikos täällä muuten Home Assistantille oma ketjunasa jo olemassa?

Minulla saattaa Mikin API-jäädä kohta pois käytöstä. Tällä hetkellä se ohjaa edelleen yhden Philips Hue -lampun kirkkautta ja värilämpötilaa tuntihinnan perusteella. Mutta nyt tulee tuntihinnat tännekin jo suoraan Entso-e:sta. Ehkä Mikin API:n voisi virittää varalle, jos Mikillä oli muitakin lähteitä datalle Entso-e:n lisäksi...
 

Majava

Tulokas
Tuossa se taitaa ainakin mättää... siis pitäisi rakenne olla kai näin tuossa lopussa. Siis sisennykset ja viiva puuttuu....

YAML:
- platform: template
    sensors:
      el_price:
        friendly_name: "Sähkön hinta nyt"
        unit_of_measurement: "c/kWh"
        value_template: "{{ state_attr('sensor.sahkon_hinta', 'PriceWithTax') | float * 100 }}"
      el_price_rank:
        friendly_name: "Sähkön hinnan järjestysluku"
        value_template: "{{ state_attr('sensor.sahkon_hinta', 'Rank') | int }}"
Näillä ohjeilla rupesi toimimaan, kiitos!
 

EJMV

Tulokas
Seuraavaksi sitten spot-hinta.fi integraatio Home Assistantiin :) Tuolla voisi vaikuttaa ainakin siihen kuinka usein apia kutsutaan ja toteuttaa vaikkapa ajastetun hintojen haun kerran vuorokaudessa ja sensoreiden päivittämisen optimaalisesti siten, että käyttäjän ei tarvitse asiaan isommin perehtyä. Toimisi niin, että käyttäjän on vaikea tehdä virheitä.

Tämä ehdotus tietysti hiukan kieli poskessa, kun näitä integraatioita olisi sitten vailla yksi jos toinenki automaatiojärjestelmä. Sen verran kuitenkin totuutta mukana, että ihan kaikkien ei tarvitse osata tai haluta tehdä yaml-konfiguraatioita, jos käyttöliittymässä saisi hiirellä kliksuttamalla saman aikaan.

Sen jälkeen Shellyyn joku vastaava integraatio, jos siinä on sellainen mahdollisuus.

Koska Mikillähän on rajattomasti vapaa-aikaa ;D
Jos jotain tällaista ilmestyy, niin itken ilosta. Tällä hetkellä odottelee neljä melcloudiin liitettyä ILP:tä tuolla järkevää Nordpool pohjaista ohjaustapaa, kun omat taidot ei mitenkään riitä ja eipä näytä kukaan muukaan tehneen järkevää integrointia vielä.
Ei tarvitsisi olla mitään graafeja, kunhan vain olisi sellaiset ohjeet, ettei mene samantien sormi suuhun. Shellyjen kanssa pärjää, kun dokumentaatio on niin hyvää Mikillä.

Noista toiminnoista maksaisin rahaakin, mutta eihän niitä saa kaupallisilta tahoilta. Nykyisessä tilassa olevistakin skripteistä olisi mukava antaa kehittäjälle edes jotain tunnustusta. Mun mielestä Mikillä on olemassa kohta potentiaalinen tuote käsissään. Eniten kysyntää on nimenomaan sähköstä maksettua hintaa vähentävälle toimintalogiikalle. Toisekseen logiikan helpolle implementoinnille. Molemmissa Mikki pärjäisi sopivalla tiimillä. Ruotsalaisilla on Tibber, mutta meillä ei vielä mitään vastaavaa.
 

KarHe

Aktiivinen jäsen
Olikos täällä muuten Home Assistantille oma ketjunasa jo olemassa?
Sitä just mietin kanssa, että tais jossain jo olla oma ketjunsa shellylle ja Mikin apille, niin olisko järkeä jo tässä vaiheessa eritellä HA-Mikin api omaksi ketjuksi, ettei sekoiteta sitä enempää tänne?
 

Mikki

Hyperaktiivi
Sitä just mietin kanssa, että tais jossain jo olla oma ketjunsa shellylle ja Mikin apille, niin olisko järkeä jo tässä vaiheessa eritellä HA-Mikin api omaksi ketjuksi, ettei sekoiteta sitä enempää tänne?
Voisihan se olla, kun HomeAssistantin kanssa on vielä perkaamatta sääohjattu lämmitys ja sitten tietysti tuo oikea Integraatio, mikä varmaankin olisi järkevä juttu kuten mainittua.

Tallensin tuon HomeAssistant skriptin malliksi Pastebiniin, kun näihin ketjuihin ne hukkuu herkästi:

Ja @Sukke: API hakee toissijaisesti nyt tiedot Viron kantaverkkoyhtiön tarjoamasta avoimesta API'sta (https://dashboard.elering.ee). Että kysy vaan tästä spot-hinta.fi jos Entso-E ei vastaa (kun se ei vastaa: on siellä suht usein katkoja rajapinnassa kuitenkin).
 

jed

Jäsen
Sellainen huomautus HomeAssistant käyttäjille, että RESTFul sensorissa taitaa olla 30 sekunnin välein oletuksena hakutiheys. Ja jos on useampaan API:iin tuolla tiheydellä kyselyitä eri sensoreilla, tulee yhdestä IP osoitteesta turhan paljon trafiikkia. Tai miksei yhdelläkin sensorilla.

Tänään ainakin yksi käyttäjä on löytänyt "429" Throttling rajan tuolla tavalla, kutsuen /JustNow ja /CheapestPeriod rajapintoja. RESTFul sensorin YAMLiin kun asettaa "scan_interval" tagiin päivityksen vaikka parin-kolmen minuutin välein, niin voi välttää tuota 429 virhettä.

platform: rest
scan_interval: 120
Minun lähestyminen asiaan on scan_interval jätti-isoksi ja sensorin päivitys tasatunteihin tai muulla halutulla ajalla automaation avulla

YAML:
alias: Pörssisähkö hae nykyinen hinta
description: ""
trigger:
  - platform: time_pattern
    minutes: 0
condition: []
action:
  - service: homeassistant.update_entity
    data: {}
    target:
      entity_id: sensor.porssisahko_hinta_nyt_entso_e_api
mode: single
 
Viimeksi muokattu:

Hempuli

Töllintunaaja
Joskus kauan sitten tein cron:lla ajastukset muuhun kuin tasatunteihin tyyliin 3, 12, 27, 48 minuuteille. Oli tuosta jotain iloa virheiden selvityksessä, mutta myös kuormantasauksessa. Nykyisin kesä- ja talviaikaan taitaa olla eri systeemit, mutta tuolloin emme laittaneet ajastuksia aamukolmen ja -neljän väliin, vaikka pannut pyörivätkin UTC-ajassa.
 

Jaakkoo

Tulokas
ajattelin ohjata shelly pro2 relettä jossa kaksi kärkeä, toista dynaamisella ja toista staattisella koodilla. yhdistinkin nämä näppärästi mutta ei oikein toimi. mikä meni vikaan vai onko edes mahdollista? :D

let CONFIG =
{
UpdateFrequence: 2 * 60000, // Oletus on kahden minuutin välein (millisekunteja). Älä hae tiheämmin.
RankAtZeroDegrees: "5", // "Rank", eli halvimpien tuntien lukumäärä kun ulkolämpötilaennuste on 0°C
RankAdjusterPercentage: "15", // Prosentti jolla "Rank" muutetaan ulkolämpötilan muuttuessa yhdellä asteella
MinimumRank: "3", // Vähimmäis 'Rank' kun lämpötila nousee plussalle ja Rank pienenee
PriceAlwaysAllowed: "10", // "Halvat hinnat talteen". Eli hinta jolloin aina on sallittua lämmitys
PostalCode: "00100", // Postinumero jonka alueen lämpötilaennustetta rajapinta tutkii
Rank: "5", // Jos tunnin 'rank' on tämä tai sen alle, hyväksytään tunti
PriceAllowed: "10", // Jos hinta on alle tämän rajan, tunti sallitaan rankista huolimatta.
Relay1: "0", // Releen ohjaus. Jos käytössä on useampireleinen Shelly, valitse tähän oikea rele 0...3.
Relay2: "1", // Releen ohjaus. Jos käytössä on useampireleinen Shelly, valitse tähän oikea rele 0...3.

};

function GetUrl() {

let url = "https://api.spot-hinta.fi/JustNowRankDynamic";
url += "?rankAtZeroDegrees=" + CONFIG.RankAtZeroDegrees;
url += "&rankAdjusterPercentage=" + CONFIG.RankAdjusterPercentage;
url += "&minimumRank=" + CONFIG.MinimumRank;
url += "&priceAlwaysAllowed=" + CONFIG.PriceAlwaysAllowed;
url += "&postalCode=" + CONFIG.PostalCode;

return url;
}

function Controller() {
Shelly.call("HTTP.GET", { url: GetUrl() },
function (res, error_code, error_msg, ud) {
if (res.code === 200) {
print("Relay1 on");
Shelly.call("Switch.Set", "{ id:" + CONFIG.Relay1 + ", on:true}", null, null); // Rele1 päälle
}
else if (res.code === 400) {
print("Relay1 off");
Shelly.call("Switch.Set", "{ id:" + CONFIG.Relay1 + ", on:false}", null, null); // Rele1 pois
}
else {
print("Error, relay1 on");
Shelly.call("Switch.Set", "{ id:" + CONFIG.Relay1 + ", on:true}", null, null); // Virhetilanne, Rele1 päälle
};
}, null);
function Control() {
Shelly.call("HTTP.GET", { url: "https://api.spot-hinta.fi/JustNowRank/" + CONFIG.Rank + "/" + CONFIG.PriceAllowed },
function (res, error_code, error_msg, ud) {
if (res.code === 200) {
print("Relay2 on");
Shelly.call("Switch.Set", "{ id:" + CONFIG.Relay2 + ", on:true}", null, null); // Rele2 päälle
}
else if (res.code === 400) {
print("Relay2 off");
Shelly.call("Switch.Set", "{ id:" + CONFIG.Relay2 + ", on:false}", null, null); // Rele2 pois päältä
}
else {
print("Error, relay2 on");
Shelly.call("Switch.Set", "{ id:" + CONFIG.Relay2 + ", on:true}", null, null); // Virhetilanne. Rele2 päälle.
};
}, null);

}

Timer.set(CONFIG.UpdateFrequence, true, function (ud) { Control(); }, null);
 

Mikki

Hyperaktiivi
ajattelin ohjata shelly pro2 relettä jossa kaksi kärkeä, toista dynaamisella ja toista staattisella koodilla. yhdistinkin nämä näppärästi mutta ei oikein toimi. mikä meni vikaan vai onko edes mahdollista? :D

On se mahdollista. Lisäsin nyt tuonne "Pastebiniin" skriptin, jolla asia pitäisi hoitua:

1668109450244.png
 
Viimeksi muokattu:

Jaakkoo

Tulokas
On se mahdollista. Ollos hyvä... versio 0.9: https://pastebin.com/wvbJf0yB

Lyhyesti testasin Shelly 1 Plussalla niin että yhtä relettä laitoin toisella rajapinnalla päälle ja toisella pois. Tuntui toimivan, hyvin rele räpsyi.
kätevää ja olipa nopeeta toimintaa. eipä tuo minun koodi ollut siellä päinkään, mutta empä näistä mitään ymmärräkkään ;D kiitos! tarviiko muuten vielä muutoksia pääsulake ja valvonta skriptiin. entäpä päivitystaajuus, aikaisemmissa 2min miksi tässä 3min?
 

Mikki

Hyperaktiivi
Nostin minuutilla sitä päivitystaajuutta kun ajetaan kaksi kyselyä. Mutta ei se katastrofi ole vaikka tiputat kahteen minuuttiinkin.
Mutta ei pitäisi tarvita muutoksia "pääsulake" eikä valvontaskriptiin.
 

Mikki

Hyperaktiivi
Nyt on päivitetty Shellyn "Staattinen" ja "Dynaaminen" skripti käsittelemään virhetilanteita paremmin:

Eli mahdollisuutena on määritellä tunnit, jolloin rele on päällä mahdollisessa virhetilanteessa. Lisäksi skripteissä on parannus mahdollisiin verkkoyhteysongelmiin. Jos haluaa kokeilla, niin riittää pelkkä ohjausskriptin päivitys. Ei muutoksia valvonta tai sulakeskriptiin.
 
Viimeksi muokattu:

Mikki

Hyperaktiivi
Nyt on myös kolmannessa Shelly pörssiskriptissä "varatunnit" mahdollista määritellä. Eli skriptissä, jolla voi ohjata kahta eri relettä.
Lisäksi siistin vähän skriptejä muutenkin, kommenttien osalta ainakin. Ja lisäsin tuonne erillisen "Lue minut" tekstin antamaan vähän selitystä skripteille. Jos huomaatte bugeja, niin pistäkää vaikka privaviestiä TAI kommentteja Pastebiniin.


Tilastotietona sen verran, että viimeisen 24h aikana on tehty 244 000 requestia rajapintoihin. Sellaisia IP-osoitteita joiden takana on selvästi automaatio on jossain 550-600 välissä. Rajapintoja sen lisäksi pingataan paljon satunnaisesti, kokeillen toiminnallisuutta ilmeisesti.
 
Viimeksi muokattu:

Mikki

Hyperaktiivi
Ja sitten vielä kerta kiellon päälle. Lisäsin nyt vielä Shelly-skripteihin "BoosterHours" parametrin, jolla voi pakottaa tietyt tunnit aina päälle. Ideana esimerkiksi käyttövesivaraajan priimaus illaksi, jos on sellainen tarve. Samalla korjasin yhden bugin tuosta yhdistelmä skriptistä, että kannattaa päivittää skripti, jos sitä kahden releen skriptiä käyttää.


Tein tuon "boosterHours" toiminnallisuuden serveripään toimintona, että se on muillekkin kuin Shellyille käytettävissä. Eli näihin rajapintoihin voi antaa optionaalisen query-parametrin "boosterHours", jolle tunnit pilkulla erotettuna:

https://api.spot-hinta.fi/JustNowRank/5?boosterHours=21,22 // klo 21 ja 22 aina sallittu
https://api.spot-hinta.fi/JustNowRank/5/10?boosterHours=20,21 //klo 20 ja 21 aina sallittu
https://api.spot-hinta.fi/JustNowRankDynamic?rankAtZeroDegrees=5&rankAdjusterPercentage=5&minimumRank=3&priceAlwaysAllowed=5&postalCode=00100&boosterHours=16,18,19 // klo 16, 18 ja 19 sallittu.

Swaggerista löytyy tarkemmat tiedot: https://api.spot-hinta.fi/swagger/ui

Nyt alkaa rajapinnat olemaan suhteellisen rikkaita toiminnallisuudeltaan. Toki kehitysideoita otetaan edelleen vastaan. Tuo "BoosterHours" tuli palstalta ideana, kiitos ideasta @mobbe.
 
Viimeksi muokattu:

Jimi

Jäsen
Oliko tuolla shelly scriptissä mahdollisuus käyttää myös käänteisesti niin että koskettimella voisi ohjata lämmityksen sulkuaikakosketinta eli shelly blokkaisi vain kalliit tunnit pois ja loput hoitaisi itse lämmityssysteemi.
 

Mikki

Hyperaktiivi
Oliko tuolla shelly scriptissä mahdollisuus käyttää myös käänteisesti niin että koskettimella voisi ohjata lämmityksen sulkuaikakosketinta eli shelly blokkaisi vain kalliit tunnit pois ja loput hoitaisi itse lämmityssysteemi.

No eihän tuo periaatteessa vaadi muuta kuin vaihdat pörssiohjaus-skriptissä "true" ja "false" relekytkennässä toisinpäin.
 

kayttajatunnus

Aktiivinen jäsen
Kysymys teille, jotka käytätte Shelly 1 plussaa.

Saako siinä asetettua ohjauksen joko skriptillä tai ulkoisella ohjauksella esim. Shelly H&T samanaikaisesti.

Tarkoituksena olisi siis yhdistää Shelly H&T lämpömittari järjestelmään jolloin saisi lämmityksen katkaistua kalleimpina Spot-tunteina tai kun huonelämpötila on riittävän korkea esim. kun aurinko paistaa sisään tai takka lämmittää.

Edit: Vähän aikaa asiaa tutkittuani varmaankin helpointa on lisätä lämpötilan haku toisesta Shellyn laitteesta suoraan tuohon skriptiin or-lausekkeen kanssa.
 
Viimeksi muokattu:

Vili55

Tulokas
Miten kannattaisi tuon Mikin skriptin pohjalta kehittää, että saisi tietyn n määrän peräkkäisten halvimpien tuntien perusteella releen päälle?
 

Grontti

Jäsen
Miten kannattaisi tuon Mikin skriptin pohjalta kehittää, että saisi tietyn n määrän peräkkäisten halvimpien tuntien perusteella releen päälle?
Vaihdat linkiksi vaikka https://api.spot-hinta.fi/CheapestPeriod/3

Tuo etsii 3 halvinta peräkkäistä tuntia.

@Mikki Myös täältä kiitokset erittäin hyvästä apista.

Osaakos joku sanoa että olenko väärässä, vai onko Home Assistant käyttäjänä loppujenlopuksi helpompi hakea vain yksi api data ja sitten säätää loput HA päässä? Tarkoitan siis että kun esimerkiksi sähkön hinta on saatavissa suoraan HA kautta ja eri laitteita joutuu kuitenkin ohjaamaan hieman erilaisilla parametreilla. Niin onko vaan helpompi käyttää apista vaikka Rank tietoa ja sitten loput tehdä HA päässä kun luo automaatioita?

Vai saanko mää automaatioon suoraan jotenkin tuon että hakee datan tuolta apista?
 

Mikki

Hyperaktiivi
Tuosta CheapestPeriodista vastaus pitäisi tosiaan parsia JSON.Parse() functiolla. Mutta se pitäisi muistaa skriptiä tehdessä, että tuo liukuu eteenpäin ajassa, eikä katso historiaa.

En ole kerinnyt miettiä tarkemmin miten tuon järkevimmin hyödyntäisi skriptissä. Tekemällä "Schedulen" Shellyyn olisi yksi strategia kyllä.

@Grontti : kiitos. Ja katsoitko tuolta pastebinistä HA skriptin, jolla saat sensorit "Hinta nyt" ja "Rank". Niden pohjalta sitten kutomaan automaatiota.
 

kayttajatunnus

Aktiivinen jäsen
Tuosta CheapestPeriodista vastaus pitäisi tosiaan parsia JSON.Parse() functiolla. Mutta se pitäisi muistaa skriptiä tehdessä, että tuo liukuu eteenpäin ajassa, eikä katso historiaa.

En ole kerinnyt miettiä tarkemmin miten tuon järkevimmin hyödyntäisi skriptissä. Tekemällä "Schedulen" Shellyyn olisi yksi strategia kyllä.

@Grontti : kiitos. Ja katsoitko tuolta pastebinistä HA skriptin, jolla saat sensorit "Hinta nyt" ja "Rank". Niden pohjalta sitten kutomaan automaatiota.
Kun tuon pastebinin koodin copypastettaa HA:n File Editoriin, se valittaa rivistä 20 (- platform: template). Tuo vaatii ainakin File Editorissa pari välilyöntiä rivin eteen ennen kuin hyväksyy.
 

roots

Hyperaktiivi
Kannattaiskos tonne viestiin #1 tehdä 'sisällysluettelo' tämän APIn voimassa olevista ominaisuuksista kun taitaa pyyntöjä tippua jo toista tai useampaakin kierrosta. Sieltä vois yhdestä viestistä kattoo jo onko kunkin haluama ominaisuus jo olemassa...
Itte viä mitään tartte mutta ei sitä tiedä jos joskus tarttee, eli jatkakaa hyvää jatkokehitys duunii. :cool:
 

Vili55

Tulokas
Tuosta CheapestPeriodista vastaus pitäisi tosiaan parsia JSON.Parse() functiolla. Mutta se pitäisi muistaa skriptiä tehdessä, että tuo liukuu eteenpäin ajassa, eikä katso historiaa.

En ole kerinnyt miettiä tarkemmin miten tuon järkevimmin hyödyntäisi skriptissä. Tekemällä "Schedulen" Shellyyn olisi yksi strategia kyllä.

@Grontti : kiitos. Ja katsoitko tuolta pastebinistä HA skriptin, jolla saat sensorit "Hinta nyt" ja "Rank". Niden pohjalta sitten kutomaan automaatiota.
Eli varmaan olisi helpoin tehdä schedule ja sitten taas päivittää schedule, kun edellinen schedule on toteutunut? Tämä nykyinenhän perustuu siihen, että palauttaa tuon rajapinnan kautta arvot 200 tai 400, jotka ohjaavat sitten tuota päälle/pois -logiikkaa.
 

Mikki

Hyperaktiivi
Eli varmaan olisi helpoin tehdä schedule ja sitten taas päivittää schedule, kun edellinen schedule on toteutunut? Tämä nykyinenhän perustuu siihen, että palauttaa tuon rajapinnan kautta arvot 200 tai 400, jotka ohjaavat sitten tuota päälle/pois -logiikkaa.
Joo... mutta ennenkuin lähdette kutomaan tuollaista skriptiä, niin voisi hetken tuumata onnistuisiko tehdä tuosta CheapestPeriodista 200/400 status version.

Ensimmäinen ajatus olisi sellainen, että URL voisi olla vaikka näin.
https://api.spot-hinta.fi/CheapestPeriod/3/Today?boosterHours=16,17

Tuo "Today" tarkoittaisi että ei ole liukuva 3 halvimman tunnin jakso, vaan kuluvan päivän. Ja 200 kertoisi jos ollaan sen sisällä ja 400 jos sen ulkona. Ja boosterHours optionaalisena parametrina. Miltäs kuulostaisi?
 

Vili55

Tulokas
Joo... mutta ennenkuin lähdette kutomaan tuollaista skriptiä, niin voisi hetken tuumata onnistuisiko tehdä tuosta CheapestPeriodista 200/400 status version.

Ensimmäinen ajatus olisi sellainen, että URL voisi olla vaikka näin.
https://api.spot-hinta.fi/CheapestPeriod/3/Today?boosterHours=16,17

Tuo "Today" tarkoittaisi että ei ole liukuva 3 halvimman tunnin jakso, vaan kuluvan päivän. Ja 200 kertoisi jos ollaan sen sisällä ja 400 jos sen ulkona. Ja boosterHours optionaalisena parametrina. Miltäs kuulostaisi?
Tämähän olisi toimiva. Voisi tuota logiikkaa ohjata rajapinnan kautta. Onko vaikea toteuttaa?
 

seppos

Jäsen
Tuo minun scriptini Profiililla 2 toimii juuri cheapest hour perusteella

Poikkeuksena muihin näkemiini scripteihin, hakee tuon halvimman periodin vain vuorokauden vaihtuessa (ja Profiili 1 vain tunnin vaihtuessa tunnin Rankin).
Ei anna "sielu" kirjoittaa Green Coding periaatteiden vastaista jatkuvaa pollausta apiin.

Lisäksi, jos kutsu ei onnistu (esim kutsuttava API ei vastaa), asettaa scriptissä konfiguroituina aikoina releen päälle.
 

Mikki

Hyperaktiivi
Tässä on nyt testiin sitten vastaava toiminnallisuus API:n päähän toteutettuna ns. 200/400 rajapintana (boosterHours on optionaalinen):

Tuossa @seppos on erinomaiset puolensa, että koodaa Green Codingin mukaisesti. Mutta serveripään toteutuksessa on oma etunsa, kun ajatellaan Arduinoja, tai muita tyhmiä laitteita joissa on hyvin rajalliset mahdollisuudet koodailla.

Mutta tosiaan hyvä olla monipuolisesti skriptejä, koska tarpeet vaihtelevat. Oikein siistiä koodia muutenkin sinulla @seppos.
 
Viimeksi muokattu:

Vili55

Tulokas
Molemmille toteutustavoille on käyttökohteensa. Kiitoksia @Mikki ja @seppos. Onko shellylle mahdollista lisätä Push tai Email notifikaatiot tuonne koodiin, josta näkisi toteutuneet päälle/pois tapahtumat relekanavakohtaisesti? Ja ehkä mahdolliset virheet...
 
Back
Ylös Bottom