HomeAssistant ja sähköpörssiohjaus

E

ederopaa

Jäsen
Temez sanoi:
Rivillä 13 taitaa olla ylimääräinen "trigger: null" -kohta. Ehkäpä tämmöinen voisi olla lähempänä?

YAML: 
  - platform: time
    at: input_datetime.car_charging_start_2
    id: StartCharge
    alias: Charging time started

Tähän en osaa nyt kyllä oikein sanoa, että mitä se meinaa. Tuo response_variable-kohdan korjaaminen ei auttanut? EDIT: en huomannut eroa verraten tähän: https://github.com/T3m3z/spotprices2ha/blob/main/example-of-cheapest-period-automation.yaml
Klikkaa laajentaaksesi..
Ylimääräinen "trigger:null" taisi olla ratkaiseva, kiitos! Nyt vaan uudelleen testaamaan liveympäristössä auton kanssa.
Temez sanoi:
Ei mitään, kysyvä ei tieltä eksy :) Minulla vasteajat vaihtelevat välillä paljonkin, joten toivottavasti olet kärsivällinen. Koetetaan saada nyt tuo toimimaan sinulle. Yksi vaihtoehto voisi myös olla raapia tuosta nuo autoon liittyvät kohdat pois, jotta voitaisiin simuloida tuota ilman autoa = saisin sen toimimaan itselläni. Voisit sitten lisätä autoon liittyvät actionit myöhemmin.
Klikkaa laajentaaksesi..
Aivan mahtavaa että jaksat vääntää! En valita mitään! ;)

Oon vääntänyt näihin sun kehityksiin perustuen ekstralämpöjä maalämpöpumpulle kun tulee kylmemmät säät. Teet kyllä mahtavaa työtä harrastustesi parissa! Ovat todella hyödyllysiä!

Tällä saa mukavasti testailtua:
1699736235579.png
 
Viimeksi muokattu:
K

Kaimax

Jäsen
Onko seuraavien tuntien keskihinnan laskentaa mahdollista lisätä esim. 3 edellistä tuntia.
Nyt kun seuraavan päivän hintoja ei ole saatavilla, niin tällöin keskipäivän keskiarvo hinta nousee korkeaksi.
1699786101970.png
 
T

Temez

Aktiivinen jäsen
Kaimax sanoi:
Onko seuraavien tuntien keskihinnan laskentaa mahdollista lisätä esim. 3 edellistä tuntia.
Nyt kun seuraavan päivän hintoja ei ole saatavilla, niin tällöin keskipäivän keskiarvo hinta nousee korkeaksi.
Klikkaa laajentaaksesi..
Kaikkihan on mahdollista. Voidaan tehdä sinulle vaikka henk. koht. anturi tuon mittaamiseen tai jos käyttötapaus on hyvä, niin ympätä se osaksi pakettia. Kuvankaappauksen perusteella anturiin "SHF Average price next hours" lasketaan seuraavan 8h perusteella. Tuon verranhan sähkönhintoja on lähes aina tiedossa, koska huomisen hinnat tulevat ~ kello 14, jolloin juuri ennen sitä on tiedetty 14-23:59 hinnat eli ~10h hinnat. Tämä vaikuttaisi riittävän, jos todella haluat seuraavan 8h hintojen keskiarvon.

Eli miksi haluaisit, että otettaisiin myös taaksepäin historiaa mukaan keskiarvon laskentaan?

(Laittamasi kuvankaappauksen kuvaajassa oleva Average Price on koko vuorokauden keskihinta.)
 
timop

timop

Aktiivinen jäsen
olikos tähä 0.2.3 versioon seuraavan tunnin hinnan näyttämään jotain konstia? ollut informatiivisena näyttämänä
0.1.11 sen sai kun tein spot-price-omat.yaml ja sinne:
YAML: 
  - sensor:
    - name: SHF Electricity price next hour
      unique_id: shf_electricity_price_next hour
      unit_of_measurement: "€/kWh"
      device_class: monetary
      state: '{{ state_attr("sensor.shf_electricity_price_now", "all_prices")[states("sensor.shf_idx")|int + now().hour+1] }}'
 
T

Temez

Aktiivinen jäsen
timop sanoi:
olikos tähä 0.2.3 versioon seuraavan tunnin hinnan näyttämään jotain konstia? ollut informatiivisena näyttämänä
0.1.11 sen sai kun tein spot-price-omat.yaml ja sinne:
Klikkaa laajentaaksesi..
Kokeileppa tämmöistä:

YAML: 
  - sensor:
    - name: SHF Electricity price next hour
      unique_id: shf_electricity_price_next hour
      unit_of_measurement: "€/kWh"
      device_class: monetary
      state: '{{ (state_attr("sensor.shf_data", "data") | selectattr("Timestamp", "lt", (now() + timedelta(hours=1)) | as_timestamp) | list | last)["TotalPrice"] | round(4) }}'
 
K

Kaimax

Jäsen
Temez sanoi:
Kaikkihan on mahdollista. Voidaan tehdä sinulle vaikka henk. koht. anturi tuon mittaamiseen tai jos käyttötapaus on hyvä, niin ympätä se osaksi pakettia. Kuvankaappauksen perusteella anturiin "SHF Average price next hours" lasketaan seuraavan 8h perusteella. Tuon verranhan sähkönhintoja on lähes aina tiedossa, koska huomisen hinnat tulevat ~ kello 14, jolloin juuri ennen sitä on tiedetty 14-23:59 hinnat eli ~10h hinnat. Tämä vaikuttaisi riittävän, jos todella haluat seuraavan 8h hintojen keskiarvon.

Eli miksi haluaisit, että otettaisiin myös taaksepäin historiaa mukaan keskiarvon laskentaan?

(Laittamasi kuvankaappauksen kuvaajassa oleva Average Price on koko vuorokauden keskihinta.)
Klikkaa laajentaaksesi..
Mulla on energia varaaja jota lämmitän mm. lämpöpumpulla, nyt olen lämpöpumppua ohjannut antamalla x määrä käynti tunteja. Käynti tunteja lisätään tai vähennetään automaatiolla joka tarkistaa 2 kertaa tunnissa on energia varaajan lämpötila yli tai alle asetus arvon ja tämän mukaan lisätään tai vähennetään käynti tunteja lämpöpumpulta. Nyt kuitenkin ongelmaksi tullut kun käynti tunnit haetaan vuorokauden ajalta, jolloin halvimmat tunnit osuu vuorokauden alkuun.

Ajattelin muuttaa tuota ohjausta seuraavien tuntien perusteella, mutta törmäsin aamu päivän ongelmaan kun sähkön hinnat tulevat klo 14 ja yleensä vuorokauden kalleimmat tunnit osuu klo 7-12 välille. Tällöin ohjaavaksi (klo 8->) keskiarvo hinnaksi tulee aina nuo kalleimmat tunnit. Kun ottaisi 2-4h tuntia menneitä "halpoja" tunteja niin voisi päästä noista kalleimmista keskiarvo tunneista eroon ja odottaa klo 14 uusia tunteja, jos ei akuuttia lämmityksen tarvetta ole niin voisi toimia. jos uudet klo 14 jälkeen hinnat ovat myös kalliita, niin sitten on pakko niillä lämmittää.



Tuossa nykyisen tuntimäärä ohjauksen käyrä, joka ei optimaalisesti toimi mutta leikkaa päivän kalleimmat tunnit.
Olen rajannut sliderin 1-18h alueelle (voi olla että talvella tarvitsee antaa myös pois rajatut 6h). Näillä yli 0´C keleillä tuo sahaa min/max väliä mutta kun oli pakkas jakso niin aika hyvin jäi huojumaan 7-10h välille.
1699812200380.png


Rele ohjaus joka antaa pumpulle käynti luvat, jos hinta on alle kytkentä rajan.
1699811695045.png



Lisäys: Tuon ajattelin toimivan niin kun lämmitys tarvetta on vähän niin silloin haetaan kaikkien seuraavien tuntien keski (SHF average price hours=24h) ja kun lämmitys tarvetta on paljon niin haetaan seuraavien 8h keskiarvo. Tuon kyllä tulen todennäköisesti tulen rajaamaan siten että haetaan max 12 seuraavan tunnin keskiarvo, jolloin slider alue olis 1-12h.
 
Viimeksi muokattu:
T

Temez

Aktiivinen jäsen
Kaimax sanoi:
Mulla on energia varaaja jota lämmitän mm. lämpöpumpulla, nyt olen lämpöpumppua ohjannut antamalla x määrä käynti tunteja. Käynti tunteja lisätään tai vähennetään automaatiolla joka tarkistaa 2 kertaa tunnissa on energia varaajan lämpötila yli tai alle asetus arvon ja tämän mukaan lisätään tai vähennetään käynti tunteja lämpöpumpulta. Nyt kuitenkin ongelmaksi tullut kun käynti tunnit haetaan vuorokauden ajalta, jolloin halvimmat tunnit osuu vuorokauden alkuun.

Ajattelin muuttaa tuota ohjausta seuraavien tuntien perusteella, mutta törmäsin aamu päivän ongelmaan kun sähkön hinnat tulevat klo 14 ja yleensä vuorokauden kalleimmat tunnit osuu klo 7-12 välille. Tällöin ohjaavaksi (klo 8->) keskiarvo hinnaksi tulee aina nuo kalleimmat tunnit. Kun ottaisi 2-4h tuntia menneitä "halpoja" tunteja niin voisi päästä noista kalleimmista keskiarvo tunneista eroon ja odottaa klo 14 uusia tunteja, jos ei akuuttia lämmityksen tarvetta ole niin voisi toimia. jos uudet klo 14 jälkeen hinnat ovat myös kalliita, niin sitten on pakko niillä lämmittää.



Tuossa nykyisen tuntimäärä ohjauksen käyrä, joka ei optimaalisesti toimi mutta leikkaa päivän kalleimmat tunnit.
Olen rajannut sliderin 1-18h alueelle (voi olla että talvella tarvitsee antaa myös pois rajatut 6h). Näillä yli 0´C keleillä tuo sahaa min/max väliä mutta kun oli pakkas jakso niin aika hyvin jäi huojumaan 7-10h välille.
katso liitettä 90101

Rele ohjaus joka antaa pumpulle käynti luvat, jos hinta on alle kytkentä rajan.
katso liitettä 90100


Lisäys: Tuon ajattelin toimivan niin kun lämmitys tarvetta on vähän niin silloin haetaan kaikkien seuraavien tuntien keski (SHF average price hours=24h) ja kun lämmitys tarvetta on paljon niin haetaan seuraavien 8h keskiarvo. Tuon kyllä tulen todennäköisesti tulen rajaamaan siten että haetaan max 12 seuraavan tunnin keskiarvo, jolloin slider alue olis 1-12h.
Klikkaa laajentaaksesi..

Okei! Alla oleva custom-koodi auttanee tarpeisiisi. Muuta vain after/before sopivan mittaiseksi ja tee tästä Template-helper (Settings->Devices&Services->Helpers->Create Helper-> Template -> Template a sensor ja lisää alla oleva koodi State Template -kenttään (arvoja voi muokata jälkikäteen myös käyttöliittymän kautta . Tai jos halua tuosta lennosta muokattavan, niin tee pari lisäslideria (onnistuu tuolta Create Helperin kautta) ja laita after/before seuraamaan niitä.

YAML: 
{% set after = 3 %}
{% set before = 3 %}
{% set after = (now() + timedelta(hours=after)) | as_timestamp %}
{% set before = (now() - timedelta(hours=before+1)) | as_timestamp %}
{{ state_attr("sensor.shf_data", "data") | selectattr("Timestamp", "ge", before) | selectattr("Timestamp", "lt", after ) | map(attribute="TotalPrice") | average | round(3) }}
 
M

MarjoC

Jäsen
Temez sanoi:
Githubissa kyseltiin, että saisiko hinnat euroista senteiksi. Eurohinnat tulivat Mikin API:n tarjoaman datan kautta puolivahingossa. En lähtenyt tekemään muutosta, koska varmaan aika monella menisi kaikenlaista rikki muutoksesta.

Laittelin tästä nyt kuitenkin äänestystä pystyyn Githubissa emoji-reaktioilla: https://github.com/T3m3z/spotprices2ha/issues/20#issuecomment-1788814567

Osalla teistä ei välttämättä ole Github-tunnusta, joten tehdään tähän vastaava. Reagoi tähän viestiin seuraavasti:
- hinnat sentteinä olisi parempi: peukku ylös
- hinnat euroina parempi: Love/sydänsilmä-emoji
- ei väliä: Haha/itkunauru-emoji

Älkää äänestäkö kahdessa paikassa.
Klikkaa laajentaaksesi..
toivoisin, että myös euro hinta jää, koska käytän sitä energia-tabillä :)
 
T

Temez

Aktiivinen jäsen
MarjoC sanoi:
toivoisin, että myös euro hinta jää, koska käytän sitä energia-tabillä :)
Klikkaa laajentaaksesi..
Jesh! Itse olen eurojen kannalla juurikin siitä syystä, että € on se virallinen valuutta, jota käytämme. Ja niin näkee myös HomeAssistant, sillä dokumentaatiossaan sivulla https://developers.home-assistant.io/docs/core/entity/sensor/ kertovat SensorDeviceClass.MONETARY-anturien yksikköjen noudattavan ISO4217-standardia: https://fi.wikipedia.org/wiki/ISO_4217

Siellä on määritelty, että valuuttana toimii euro. Koetan kuitenkin saada aikaan virityksen, jolla jokainen voisi halutessaan itselleen vaihtaa yksiköksi c/kWh, mutta ns. "omalla vastuullaan".
 
E

ederopaa

Jäsen
Temez sanoi:
Rivillä 13 taitaa olla ylimääräinen "trigger: null" -kohta. Ehkäpä tämmöinen voisi olla lähempänä?

YAML: 
  - platform: time
    at: input_datetime.car_charging_start_2
    id: StartCharge
    alias: Charging time started

Tähän en osaa nyt kyllä oikein sanoa, että mitä se meinaa. Tuo response_variable-kohdan korjaaminen ei auttanut? EDIT: en huomannut eroa verraten tähän: https://github.com/T3m3z/spotprices2ha/blob/main/example-of-cheapest-period-automation.yaml


Ei mitään, kysyvä ei tieltä eksy :) Minulla vasteajat vaihtelevat välillä paljonkin, joten toivottavasti olet kärsivällinen. Koetetaan saada nyt tuo toimimaan sinulle. Yksi vaihtoehto voisi myös olla raapia tuosta nuo autoon liittyvät kohdat pois, jotta voitaisiin simuloida tuota ilman autoa = saisin sen toimimaan itselläni. Voisit sitten lisätä autoon liittyvät actionit myöhemmin.
Klikkaa laajentaaksesi..
Moi taas! ;)

Olen tässä hieman testaillut automaatiota ja se käynnistyy vaikka emme ole saavuttaneet halpoja tunrtea.

Tässä on vielä jännä mysteeri tai sit mä en vaan nää miksi automaatio ei toimi...

Elikkä ao. car charging start (date/time muuttuja) tässä asennossa:
1699993779891.png

Kun nyt n. klo 22:30 testaan aikaehtoa jälkeen ja ennen niin tulos on sama:
1699993961426.png


1699994046694.png


Mikähän jää huomaamatta...?
 

Liitteet

  • 1699994015377.png
    1699994015377.png
    213,8 KB · Katsottu: 48
T

Temez

Aktiivinen jäsen
ederopaa sanoi:
Moi taas! ;)

Olen tässä hieman testaillut automaatiota ja se käynnistyy vaikka emme ole saavuttaneet halpoja tunrtea.

Tässä on vielä jännä mysteeri tai sit mä en vaan nää miksi automaatio ei toimi...

Elikkä ao. car charging start (date/time muuttuja) tässä asennossa:
katso liitettä 90164
Kun nyt n. klo 22:30 testaan aikaehtoa jälkeen ja ennen niin tulos on sama:
katso liitettä 90165

katso liitettä 90167

Mikähän jää huomaamatta...?
Klikkaa laajentaaksesi..
Heh! Dokumentaatiosta selvisi, että nuo datetime-helperit triggereinä toimivat täsmälleen tiettynä ajanhetkenä laueten. Mutta Conditionina käytettynä ne eivät ota huomiin päivämääräosaa. Hauska ominaisuus :)

Ongelma ratkeaa muuttamalla kyseinen tarkistusehto template conditioniksi ja ehdoksi siihen (tarkista vielä tuo entityn eli input_datetime.car_charging_start_2 nimi, että se on oikein):
YAML: 
{{ now() > states('input_datetime.car_charging_start_2') | as_datetime | as_local}}
 
J

jytkis

Tulokas
Ehtoota!
Olen yrittänyt etsiä koodinpätkää internetin saloista lämminvesivaraajan ohjaukseen, kun en itse osaa tehdä, ...
Nyt lvv kytkeytyy kolmen halvimman tunnin aikana päälle, mutta mitä jos hinta onkin niin korkea että varaajan lämmitys kannattaakin jättää seuraavalle päivälle? Sekin on vielä helposti tehtävissä kyllä, mutta entäs jos hinta on sitä seuraavanakin päivänä taivaissa niin sitten alkaa lämmin vesi jo loppua.. Tähän kun löytyisi vaikkapa sellainen pätkä koodia (vaikkapa aika edellisestä päältä pois kytkeytymisestä)jonka ehdolla lvv voisi kytkeytyä päälle vaikka hinta olisikin edelleen kallista.
Eli selkeämmin selitettynä:
Jos hinta halpa -> lvv päälle 3 halvinta tuntia
Jos hinta kallis ja edellisestä päältäpois kytkeytymisestä < pitkä aika-> lvv ei mene päälle
Jos hinta kallis ja edellisestä päältäpois kytkeytymisestä > pitkä aika-> lvv menee päälle 3 halvinta tuntia

Tiedä sitten onko vaivan väärti, pahimmassa tapauksessa lvv kuumenee joka tapauksessa vieläkin kalliimman sähkön aikaan ja hyöty muuttuu haitaksi, itte kun ymmärtäs enemmän niin olis tehty jo :cool:
 
M

Mikki

Hyperaktiivi
jytkis sanoi:
Tiedä sitten onko vaivan väärti, pahimmassa tapauksessa lvv kuumenee joka tapauksessa vieläkin kalliimman sähkön aikaan ja hyöty muuttuu haitaksi, itte kun ymmärtäs enemmän niin olis tehty jo :cool:
Klikkaa laajentaaksesi..

Tämän tyyppisissä virityksissä käy juuri niin, että ensinnäkin saavutettavissa oleva hyöty menee minimaaliseksi ja toisekseen että alkaa tulemaan väistämättä myös erinäisiä haittoja, joiden ratkaiseminen on sitten todellakin taas entistä vaikeampaa.

Insinöörin aivoille toki hyvää jumppaa, mutta ekonomi tekee mieluummin jotain muuta.
 
M

MarjoC

Jäsen
Temez sanoi:
Pientä hiljaiseloa taas hetki tullut. Meille tuli perheenlisäystä, joten aktiivinen kirjoittelu jäänyt vähemmälle. Varmaan aktiivisuustaso vaihtelee tässä lähiviikkoina kovastikin.

Tästä taisitkin aiemmin jo puhua. Voisin lisäillä peruspakettiinkin tuon, koska sen lisääminen on todella nopea homma. Tilausta tälle ehkä on?


Juurikin näin. Ajatuksena oli tuoda jokin aloittelijan helposti käyttöönotettava systeemi, jolla saa halvoilla tunneilla nostettua lämpöä ja/tai laskettua kalliilla.

Tämmöinen avustava graafi tuon tutkimiseen tuli joskus tehtyä. Eli kun sähkö oli yöllä halvimmillaan, niin "SHF Control Factor 0-1" -sensorin arvo on 1. Kalleimmailla tunnilla sen arvo on 0. Näin voi ilmalämpöpumpulle käskeä, että pyyntilämpötila on (22 °C + 2°C*"SHF Control Factor 0-1") pyöristettynä haluttuun tarkkuuteen (templatena esim {{ (22 + states('sensor.shf_control_factor_0_1') | float * 2) | round(0) }} ). Silloin ILPin lämpötilapyynti vaihtelisi 22°C ja 24°C välillä riippuen kuluvan ajanhetken kalleudesta.
katso liitettä 89647
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: true

Tähän taidettiinkin jo vastailla, mutta tosiaan tämä on HomeAssistantissa "sensori", jonka arvo oli tarkasteluhetkellä 13. Ja kuvaaja näyttää HomeAssistantin tietokantaansa tallentamaa historia-arvoa eli mitä Rank on ollut joskus aiemmin.

Rank-tiedot ovat kuitenkin HomeAssistantissa olemassa jo kyllä "tulevaisuuteen". Sensorit vain näyttävät arvoja nykyhetkestä. Tässä apex-chart-koodi, jolla saat hinnan ja Rankin näkymään myös tulevaisuuteen graafina:
katso liitettä 89656

Koodi: 
type: custom:apexcharts-card
now:
  show: true
  color: '#ff0000'
apex_config:
  xaxis:
    tooltip:
      enabled: false
yaxis:
  - id: rank
    show: true
    decimals: 0
    apex_config:
      forceNiceScale: true
      title:
        text: Rank
  - id: price
    show: true
    opposite: true
    decimals: 2
    apex_config:
      forceNiceScale: true
      title:
        text: c/kWh
show:
  last_updated: false
header:
  standard_format: false
  show: true
  show_states: true
  colorize_states: true
  title: Price and Rank without extra fees
span:
  start: day
  offset: +0h
update_delay: 2s
series:
  - entity: sensor.shf_electricity_price
    yaxis_id: price
    name: Electricity price 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: true
      name_in_header: true
      extremas: true
  - entity: sensor.shf_electricity_price
    yaxis_id: rank
    name: Rank now (current day)
    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["Rank"]];
      });
    show:
      header_color_threshold: true
      legend_value: false
      in_header: true
      name_in_header: true
      extremas: false
Klikkaa laajentaaksesi..
Millä konstilla saisi tuon Price and Rank without extra fees headerin näyttämään tämän tunnin/nykyhetken arvoja, nyt näyttää päivän viimeistä?
 
T

Temez

Aktiivinen jäsen
MarjoC sanoi:
Millä konstilla saisi tuon Price and Rank without extra fees headerin näyttämään tämän tunnin/nykyhetken arvoja, nyt näyttää päivän viimeistä?
Klikkaa laajentaaksesi..
Enpäs tullut tuota ajatelleeksi, että tämmöinen "ominaisuus" siinä esimerkkikoodissa. Tutkailin dokumentaatiota ja ilmeisesti Apex Chart olettaa oletuksena niin, että aikaleimaltaan isoin arvo on nykyinen arvo. Vaihtamalla seriesin show-kohdan alta asetus in_header asentoon before_now tuntuisi toimivan.

YAML: 
type: custom:apexcharts-card
now:
  show: true
  color: '#ff0000'
apex_config:
  xaxis:
    tooltip:
      enabled: false
yaxis:
  - id: rank
    show: true
    decimals: 0
    apex_config:
      forceNiceScale: true
      title:
        text: Rank
  - id: price
    show: true
    opposite: true
    decimals: 2
    apex_config:
      forceNiceScale: true
      title:
        text: c/kWh
show:
  last_updated: false
header:
  standard_format: false
  show: true
  show_states: true
  colorize_states: true
  title: Electricity Price and Rank without extra fees
span:
  start: day
  offset: +0h
update_delay: 2s
series:
  - entity: sensor.shf_electricity_price
    yaxis_id: price
    name: Electricity price 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: before_now
      name_in_header: true
      extremas: true
  - entity: sensor.shf_electricity_price
    yaxis_id: rank
    name: Rank now (current day)
    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["Rank"]];
      });
    show:
      header_color_threshold: true
      legend_value: false
      in_header: before_now
      name_in_header: true
      extremas: false
 
D

dillon

Jäsen
jytkis sanoi:
Nyt lvv kytkeytyy kolmen halvimman tunnin aikana päälle, mutta mitä jos hinta onkin niin korkea että varaajan lämmitys kannattaakin jättää seuraavalle päivälle? Sekin on vielä helposti tehtävissä kyllä, mutta entäs jos hinta on sitä seuraavanakin päivänä taivaissa niin sitten alkaa lämmin vesi jo loppua..
Klikkaa laajentaaksesi..
Halvimmat tunnit on kyllä lähes poikkeuksetta aina aamuyöstä, jolloin seuraavan päivän hinnat ei vielä ole tiedossa.

Eikö yksinkertaisinta olisi, että varaajan lämmitystunnit lasketaan seuraavan päivän hintojen tultua esim. 22-06 välin halvimmille tunneille?
 
M

MarjoC

Jäsen
Temez sanoi:
Enpäs tullut tuota ajatelleeksi, että tämmöinen "ominaisuus" siinä esimerkkikoodissa. Tutkailin dokumentaatiota ja ilmeisesti Apex Chart olettaa oletuksena niin, että aikaleimaltaan isoin arvo on nykyinen arvo. Vaihtamalla seriesin show-kohdan alta asetus in_header asentoon before_now tuntuisi toimivan.

YAML: 
type: custom:apexcharts-card
now:
  show: true
  color: '#ff0000'
apex_config:
  xaxis:
    tooltip:
      enabled: false
yaxis:
  - id: rank
    show: true
    decimals: 0
    apex_config:
      forceNiceScale: true
      title:
        text: Rank
  - id: price
    show: true
    opposite: true
    decimals: 2
    apex_config:
      forceNiceScale: true
      title:
        text: c/kWh
show:
  last_updated: false
header:
  standard_format: false
  show: true
  show_states: true
  colorize_states: true
  title: Electricity Price and Rank without extra fees
span:
  start: day
  offset: +0h
update_delay: 2s
series:
  - entity: sensor.shf_electricity_price
    yaxis_id: price
    name: Electricity price 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: before_now
      name_in_header: true
      extremas: true
  - entity: sensor.shf_electricity_price
    yaxis_id: rank
    name: Rank now (current day)
    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["Rank"]];
      });
    show:
      header_color_threshold: true
      legend_value: false
      in_header: before_now
      name_in_header: true
      extremas: false
Klikkaa laajentaaksesi..
Kiitos, kyllä nää joskus on kryptisiä - enpä olisi ikinä osannut tuota before_nowta edes arvata :D :D Mutta tosiaan näyttää toimivan minullakin!
 
K

Kaimax

Jäsen
Onko muilla toiminut sensor.shf_electricity_price_now anturin tieto miten.
Mulla eilen klo 23:00 jälkeen ohjaus rele kytkeytyi päälle vaikka asetus oli korkeampi kuin anturin antama tieto ja sama tilanne tähän asti.
Vaihdoin sähkön hinta tiedon antavaksi nordpool sensorin, tällä ohjaus ei kytkeytynyt päälle ja toimii sliderin asettaman arvon mukaisesti.
Alla koodi millä ohjaan

1700234983683.png
 
J

jytkis

Tulokas
dillon sanoi:
Halvimmat tunnit on kyllä lähes poikkeuksetta aina aamuyöstä, jolloin seuraavan päivän hinnat ei vielä ole tiedossa.

Eikö yksinkertaisinta olisi, että varaajan lämmitystunnit lasketaan seuraavan päivän hintojen tultua esim. 22-06 välin halvimmille tunneille?
Klikkaa laajentaaksesi..
Niinhän ne yleensä on. Pitää tätä sumplia vielä kunhan ehtii.
Huomenna näyttäisi halvimmat tunnit sattuvan päiväl loppuun ja mahdollisesti seuraavan päivän halvimmat heti perään aamuyöstä. Ehkä tässä meinasi mopo keulia turhankin paljon kun kerran sai automaatiot käyttöön niin tottahan se pitää heti viilata kaikki mitä pystyy, vaikka hyödyt jäisi mitättömiksi ;)

Seuraavaksi olisikin siirryttävä ilpojen säätöön
 
D

dillon

Jäsen
Kaimax sanoi:
Onko muilla toiminut sensor.shf_electricity_price_now anturin tieto miten.
Mulla eilen klo 23:00 jälkeen ohjaus rele kytkeytyi päälle vaikka asetus oli korkeampi kuin anturin antama tieto ja sama tilanne tähän asti.
Vaihdoin sähkön hinta tiedon antavaksi nordpool sensorin, tällä ohjaus ei kytkeytynyt päälle ja toimii sliderin asettaman arvon mukaisesti.
Alla koodi millä ohjaan

katso liitettä 90252
Klikkaa laajentaaksesi..
Onhan tuo slide_spot_min euroja eikä senttejä?
Olethan huomioinut, että shf_electricity_price_now sisältää myös siirrot ja verot jos ne on asetettu?
 
T

Temez

Aktiivinen jäsen
Kaimax sanoi:
Onko muilla toiminut sensor.shf_electricity_price_now anturin tieto miten.
Mulla eilen klo 23:00 jälkeen ohjaus rele kytkeytyi päälle vaikka asetus oli korkeampi kuin anturin antama tieto ja sama tilanne tähän asti.
Vaihdoin sähkön hinta tiedon antavaksi nordpool sensorin, tällä ohjaus ei kytkeytynyt päälle ja toimii sliderin asettaman arvon mukaisesti.
Alla koodi millä ohjaan

katso liitettä 90252
Klikkaa laajentaaksesi..
Jännittävä juttu. Näyttää ihan järkevältä tuo automaatio. Kannattaa ehkä koettaa Logbookin/History-työkalun kautta, että onko sensor.shf_electricity_price_now tila muuttunut kyseisellä hetkellä. Lisäksi heti ongelman tapahduttua kannattaa tutustua kyseisen automaation Traces-kohtaan. Sieltä näkee, että mikä automaation triggeröi ja muita tietoja. Esimerkiksi, että mistä tilasta siirryttiin mihinkin tilaan ja mitkä olivat tilat/attribuutit ennen ja jälkeen triggeröinnin. Kuvana se siis näyttää tältä ja sen kautta ehkä pääsisit kiinni siihen, että mitä tapahtui:
1700300252526.png



Lisäksi huomion arvoista se, että jos haluaa triggeröidä automaation VAIN tilamuutoksista eikä sensorin attribuuttien muutoksista (joita tosin en äkkiseltään tunnista tapahtuvan kello 23), niin pitää vähän muuttaa konffia: https://www.home-assistant.io/docs/automation/trigger/#state-trigger

Lainaus tuon linkin takaa:
If only entity_id is given, the trigger will fire for all state changes, even if only state attributes change. If at least one of from, to, not_from, or not_to are given, the trigger will fire on any matching state change, but not if only attributes change. To trigger on all state changes, but not on changed attributes, set at least one of from, to, not_from, or not_to to null.
Klikkaa laajentaaksesi..

Suosittelen myös muita raportoimaan, jos havaitsette tämmöisiä haasteita.
 
haraldh

haraldh

Vakionaama
Näinhän tässä kävi että LVV lähti päälle kello 22, koska vuorokauden halvimmat hinnat sattuivat välille 22-24. Onneksi huomasin että käppyräs lähtivät nousuun ja sain käsin sammuttaa sen odottaen halvempia tunteja. Jos odottaisi vain 04 asti niin olisi 9.7 c/kWh sijaan ~4 c /kWh tunteja tarjolla.

Jotenkin tykkäsin fission tavasta tehdä suunnitelma miten tulevat pörssisähköhinnat käytetään, mutta siinäkin oli ikkuna rajattu kello 24 asti, vaikka tiedossa oli seuraavan vuorokauden hinnat. Olisi tosiaan hyvä jos tuosta aikaikkunasta mistä lasketaan rankkeja olisi aina laskettu tiedossa olevien hintojen loppuun. Tämä tietysti aiheuttaa sen että rankkeja voi olla yli 24. Tai että tehtäisiin uusi suunnitelma aina kun tiedossa on enemmän hintoja.

Screenshot at 2023-11-18 22-08-57.png
 
T

Temez

Aktiivinen jäsen
haraldh sanoi:
Näinhän tässä kävi että LVV lähti päälle kello 22, koska vuorokauden halvimmat hinnat sattuivat välille 22-24. Onneksi huomasin että käppyräs lähtivät nousuun ja sain käsin sammuttaa sen odottaen halvempia tunteja. Jos odottaisi vain 04 asti niin olisi 9.7 c/kWh sijaan ~4 c /kWh tunteja tarjolla.

Jotenkin tykkäsin fission tavasta tehdä suunnitelma miten tulevat pörssisähköhinnat käytetään, mutta siinäkin oli ikkuna rajattu kello 24 asti, vaikka tiedossa oli seuraavan vuorokauden hinnat. Olisi tosiaan hyvä jos tuosta aikaikkunasta mistä lasketaan rankkeja olisi aina laskettu tiedossa olevien hintojen loppuun. Tämä tietysti aiheuttaa sen että rankkeja voi olla yli 24. Tai että tehtäisiin uusi suunnitelma aina kun tiedossa on enemmän hintoja.

katso liitettä 90291
Klikkaa laajentaaksesi..
Onhan tämä tosiaan mahdollista, mutta se täytyy tehdä itse. Fissio oli suunniteltu täsmälleen lämmitysoptimointiin, joten siinä oli sisäänrakennettuna tämmöinen ominaisuus. HomeAssistant sen sijaan on kotiautomaatioalusta, jolla "voi tehdä mitä vaan".

Tein esimerkkikoodin, jolla tämä onnistuu. Lisää tämä configuration.yaml-tiedostoon ja muokkaa max_rank haluamaksesi (tuon voisi tehdä myös käyttöliittymässä näkyväksi slideriksi halutessaan, jotta voi säätää lennosta). Käynnistä HA uudelleen. EDIT: jos sinulla on jo siellä määriteltynä Template-sensoreita, niin joudut ehkä yhdistelemään konfiguraatiota käsin. HA ei muistaakseni tykkää, että samassa tiedostossa on useampi "template:" -rivi. Mutten ole ihan varma.
YAML: 
template:
  - sensor:
    - name: Own Rank based control ON/OFF
      unique_id: rank_based_control_on_off
      state: '{{ ((this.attributes.control | selectattr("Timestamp", "lt", now() | as_timestamp) | sort(attribute="Timestamp", reverse=True) | first )["state"]) if this.attributes.control is defined else none }}'
      availability: '{{ state_attr("sensor.shf_data", "data") is iterable }}'
      attributes:
        control: >
          {% set max_rank = 5 %}
          {% set output = namespace(value=[]) %}
          {% for value in state_attr("sensor.shf_data", "data") %}
            {% set output.value = output.value + [ dict(value, **{"state": value.Rank <= max_rank}) ] %}
          {% endfor %}
          {{ output.value }}
Graafin aiheesta saat tällä ApexChart-koodilla:
Koodi: 
type: custom:apexcharts-card
now:
  show: true
  color: '#ff0000'
apex_config:
  xaxis:
    tooltip:
      enabled: false
yaxis:
  - id: left
    show: true
    decimals: 0
    apex_config:
      forceNiceScale: true
      title:
        text: Control
  - id: right
    show: true
    opposite: true
    decimals: 0
    apex_config:
      forceNiceScale: true
      title:
        text: Rank
show:
  last_updated: false
header:
  standard_format: false
  show: true
  show_states: true
  colorize_states: true
  title: Calculation of Rank control in advacne
graph_span: 48h
span:
  start: day
update_delay: 2s
series:
  - entity: sensor.own_rank_based_control_on_off
    yaxis_id: left
    name: Control
    extend_to: false
    type: column
    opacity: 0.5
    stroke_width: 1
    data_generator: |
      return entity.attributes.control.map((d, index) => {
        return [d["Timestamp"]*1000, d["state"] ? 1 : 0];
      });
    show:
      header_color_threshold: true
      legend_value: false
      in_header: before_now
      name_in_header: true
      extremas: true
  - entity: sensor.shf_electricity_price
    yaxis_id: right
    name: Rank now (current day)
    extend_to: false
    type: area
    curve: stepline
    opacity: 0.02
    stroke_width: 1
    data_generator: |
      return entity.attributes.data.map((d, index) => {
        return [new Date(d["DateTime"]).getTime(), d["Rank"]];
      });
    show:
      header_color_threshold: true
      legend_value: false
      in_header: before_now
      name_in_header: true
      extremas: false

Ulos tulee tämän tyyppinen kuvaaja ja automaatioissa voisit käyttää sensorin "Own Rank based control ON/OFF" arvoa käynnistämään esim. LVV-lämmityksen:
1700391957522.png


Yhtenä vaihtoehtona nykyiseen automaatioosi voisi olla tarkistaa koodilla ennen LVV:n sähköjen kytkemistä, että onko seuraavan x tunnin aikana (varmaankin esim. 9h aikana, jotta "katsotaan" tuleva yö ennen kuin lämmitetään kello 22) hinta halvempi (tällöinhän Rank toki saattaisi olla asetettua isompi yöllä, joten lienee parempi katsoa hintaa ja koettaa optimoida sitä tässä lisätarkistuksessa).

EDIT: Koodissa voi olla bugeja. Kirjoitin sen äsken suht nopeasti. Käytä harkiten :)
 
Viimeksi muokattu:
haraldh

haraldh

Vakionaama
Kiitos paljon. Tarkoitukseni ei ollut valittaa muuta kuin että kun ei itse osaa

Pitää lisätä nuo ja seurailla miten käyttäytyvät.

Ainakin kännyn näytöllä näyttää siltä että sensorikoodin pisin rivi on leikkaantunut.
 
T

Temez

Aktiivinen jäsen
haraldh sanoi:
Kiitos paljon. Tarkoitukseni ei ollut valittaa muuta kuin että kun ei itse osaa
Klikkaa laajentaaksesi..
Ja oma tarkoitukseni ei ollut olla ilkeän kuuloinen vaan lähinnä neutraalisti todeta, että mikä omasta mielestäni Home Assistantin rooli on. Tekstin kautta tietysti kaikki kuulostaa aina helposti negatiivisemmalta kuin mitä muutoin. Hyvä tahto kantaa pitkälle :)
haraldh sanoi:
Ainakin kännyn näytöllä näyttää siltä että sensorikoodin pisin rivi on leikkaantunut.
Klikkaa laajentaaksesi..
Erinomainen havainto! Korjattu.
 
haraldh

haraldh

Vakionaama
Olet oikeassa että HA on alusta eikä palvelu. Pitää muistuttaa itseäni tästä koko ajan tässä siirtymävaiheessani. Erinomaista työtä, kiitos kaikille.
 
K

Kaimax

Jäsen
Temez olitko tehnyt myös aikaisemman koodinkin missä laskettiin kannattava lämmitys muoto (ILP tai PUU tai ÖLJY)?
Miten siitä koodista saisi sensorin luotua joka antaisi ilmoituksen kun tulisi hetki kun on edullisempaa polttaa puuta kuin lämmittää ilpillä?
Puun hinta ilmeisesti tarvitsee antaa €/kWh?
Lopussa on vielä kohta muokkaa tästä/tähän, mitä tähän olisi tarkoitus laittaa?

Olen juuri tämän tapaista koodia etsinyt mistä saisi ilmoituksen puun poltosta.

1700404740871.png
 
T

Temez

Aktiivinen jäsen
Kaimax sanoi:
Temez olitko tehnyt myös aikaisemman koodinkin missä laskettiin kannattava lämmitys muoto (ILP tai PUU tai ÖLJY)?
Miten siitä koodista saisi sensorin luotua joka antaisi ilmoituksen kun tulisi hetki kun on edullisempaa polttaa puuta kuin lämmittää ilpillä?
Puun hinta ilmeisesti tarvitsee antaa €/kWh?
Lopussa on vielä kohta muokkaa tästä/tähän, mitä tähän olisi tarkoitus laittaa?

Olen juuri tämän tapaista koodia etsinyt mistä saisi ilmoituksen puun poltosta.

katso liitettä 90311
Klikkaa laajentaaksesi..
Joo, olin sellaista aiemmin puuhaillut ja jonkin pohjan laitoinkin tänne. Olen jatkojalostanut omaan käyttööni siitä vähän hienomman version.

Saatko jostain laskettua/arvioitua, että mikä on päivän kokonaisenergiatarve? Vai onko ajatus antaa ILPin puksuttaa vaikkapa lämpötilapyynnillä 21C ja jos sähkön hinta pomppaa tai ulkolämpötila laskee niin alas, että COP heikkenee hirveästi (nostaen €/kWh hintaa kalliimmaksi kuin polttopuut), niin sitten tulisi puhelimeen ilmoitus?

Jos kelpaa sellainen, että lasketaan vain nykyhetkessä tilannetta, niin tämmöisellä Template-koodilla saat verrattua ILPin €/kWh (muuttuva COP ulkolämpötilan mukaan) johonkin staattisen hinnan lämmönlähteeseen:

YAML: 
{# Returns True if alternative source is currently cheaper  #}
{# SETTINGS  #}
{% set copmap =
        [
          (7, 6.5),
          (5,6),
          (0, 5),
          (-10, 4),
          (-15, 3),
          (-20, 2)
        ]
        %}{# (Temperature, COP) #}
{% set temperature = states('sensor.out_temperature_2') %} {# Out Temperature now #}
{% set alternative_source_price = 0.05 %} {# For example wood price €/kWh #}

{# CALCULATION: calculate cop and check whether alternative source is cheaper per kWh #}
{% set map = copmap | sort(attribute='0') %}
{% set value = temperature | float %}
{% set upper = (map | selectattr("0", 'gt', value) | list) %}
{% set lower = (map | selectattr("0", 'le', value) | sort(attribute='0', reverse=True)| list) %}
{% set cop =  (((value-lower[0][0])*(upper[0][1]-lower[0][1])/(upper[0][0]-lower[0][0]) + lower[0][1]) if upper and lower else map[0 if upper else -1][1]) %}
{{ alternative_source_price < states('sensor.shf_electricity_price_now') | float / cop }} {# Returns True if alternative source is currently cheaper  #}

EDIT: tästä voi tehdä oman Template-helperin, jolloin tästä saa sitten sensorin. Tai voi käyttää sellaisenaan automaatioissa Template Conditionina.

Lisäksi Disclaimer, että testasin tätä totuttuun tapaan vain hyvin pikaisesti Developer Toolseilla. Toivottavasti ei hirveitä bugeja, kun oli 80% copypastea muista jo aiemmin kirjoittamistani koodeista.
 
K

Kaimax

Jäsen
Temez sanoi:
Joo, olin sellaista aiemmin puuhaillut ja jonkin pohjan laitoinkin tänne. Olen jatkojalostanut omaan käyttööni siitä vähän hienomman version.

Saatko jostain laskettua/arvioitua, että mikä on päivän kokonaisenergiatarve? Vai onko ajatus antaa ILPin puksuttaa vaikkapa lämpötilapyynnillä 21C ja jos sähkön hinta pomppaa tai ulkolämpötila laskee niin alas, että COP heikkenee hirveästi (nostaen €/kWh hintaa kalliimmaksi kuin polttopuut), niin sitten tulisi puhelimeen ilmoitus?

Jos kelpaa sellainen, että lasketaan vain nykyhetkessä tilannetta, niin tämmöisellä Template-koodilla saat verrattua ILPin €/kWh (muuttuva COP ulkolämpötilan mukaan) johonkin staattisen hinnan lämmönlähteeseen:

YAML: 
{# Returns True if alternative source is currently cheaper  #}
{# SETTINGS  #}
{% set copmap =
        [
          (7, 6.5),
          (5,6),
          (0, 5),
          (-10, 4),
          (-15, 3),
          (-20, 2)
        ]
        %}{# (Temperature, COP) #}
{% set temperature = states('sensor.out_temperature_2') %} {# Out Temperature now #}
{% set alternative_source_price = 0.05 %} {# For example wood price €/kWh #}

{# CALCULATION: calculate cop and check whether alternative source is cheaper per kWh #}
{% set map = copmap | sort(attribute='0') %}
{% set value = temperature | float %}
{% set upper = (map | selectattr("0", 'gt', value) | list) %}
{% set lower = (map | selectattr("0", 'le', value) | sort(attribute='0', reverse=True)| list) %}
{% set cop =  (((value-lower[0][0])*(upper[0][1]-lower[0][1])/(upper[0][0]-lower[0][0]) + lower[0][1]) if upper and lower else map[0 if upper else -1][1]) %}
{{ alternative_source_price < states('sensor.shf_electricity_price_now') | float / cop }} {# Returns True if alternative source is currently cheaper  #}

EDIT: tästä voi tehdä oman Template-helperin, jolloin tästä saa sitten sensorin. Tai voi käyttää sellaisenaan automaatioissa Template Conditionina.

Lisäksi Disclaimer, että testasin tätä totuttuun tapaan vain hyvin pikaisesti Developer Toolseilla. Toivottavasti ei hirveitä bugeja, kun oli 80% copypastea muista jo aiemmin kirjoittamistani koodeista.
Klikkaa laajentaaksesi..
Jees, kiitos taas vaivan näöstä!

Mulla on vesikeskus lämmitys, jossa on vanha puupannu jolla lämmitän tarvittaessa energia varaajaa, muuten lämmitys toteutetaan maalämmöllä. Maalämpöön on oma energia mittaus, josta saan energia määrän tietoon. Saan myös COP:n laskettua.
Tuohon koodiin kun muutan MLP:n COP:n niin luulen et saan homman toimimaan.
Tarkoitus olisi saada HA:n lähettämään viestin puhelimeen kun olisi puun poltto edullisempi. Vaihtoehto. (Notify->callbot)

Lisäksi pari ilppiä on lämmittämässä, tuli joskus asennettua jäähdytykseen kun kämpän lämpötila nousi korkeammaksi kuin ulko lämpötila (+35'c). Myös näillä on erillinen energia mittaus, joten aika tarkasti saan asunnon lämmitykseen käytettävän energia laskettua. Ilppien asetus arvoa olisi tarkoitus ohjata IR-sensorin ja sun aikaisempaa tekemääsi koodia käyttäen.

Ps. Kuten jo joku muukin totesi et sulta puuttuu linkki mistä voisi kahvit sulle tarjota.
 
J

jämä67

Aktiivinen jäsen
Minulla on käytössä tuo Temezin koodi ILP/puu/öljy. Siinähän ideana on, että ILP:n tai minun tapauksessani VILP:n lämpökerreoin muuttuu ulkolämpötilan mukaan. Eikös se maalämmön tapauksessa pysy suhteellisen vakiona? Eikös siinä riittäisi, kun laittaa ihan suoraan jonkun hintarajan ohjaukseen/viestin lähetykseen?
 
J

jämä67

Aktiivinen jäsen
Temez sanoi:
Joo, olin sellaista aiemmin puuhaillut ja jonkin pohjan laitoinkin tänne. Olen jatkojalostanut omaan käyttööni siitä vähän hienomman version.

Saatko jostain laskettua/arvioitua, että mikä on päivän kokonaisenergiatarve? Vai onko ajatus antaa ILPin puksuttaa vaikkapa lämpötilapyynnillä 21C ja jos sähkön hinta pomppaa tai ulkolämpötila laskee niin alas, että COP heikkenee hirveästi (nostaen €/kWh hintaa kalliimmaksi kuin polttopuut), niin sitten tulisi puhelimeen ilmoitus?

Jos kelpaa sellainen, että lasketaan vain nykyhetkessä tilannetta, niin tämmöisellä Template-koodilla saat verrattua ILPin €/kWh (muuttuva COP ulkolämpötilan mukaan) johonkin staattisen hinnan lämmönlähteeseen:
Klikkaa laajentaaksesi..
Täytyypi testailla tätä jossain kohtaa, kun on aikaa. Koodin "copmap" vaikuttaa mielenkiintoiselta ja monipisteinen käyrä ottaa varmaan paremmin huomioon todellisen käyrän muodon, kun vanha koodi. Vanhakin on kyllä sinänsä ihan riittävän hyvin hehtaarilla, mutta voihan sitä aina koittaa parantaa.
 
T

Temez

Aktiivinen jäsen
Kaimax sanoi:
Ps. Kuten jo joku muukin totesi et sulta puuttuu linkki mistä voisi kahvit sulle tarjota.
Klikkaa laajentaaksesi..
Joo, olen tähän mennessä tietoisesti jättänyt sen tekemättä. Tämä homma lähtenyt liikkeelle harrastuksena ja -22 lopulla haluna jotenkin auttaa sähköjärjestelmää sekä toki yksittäisiä kotitalouksia/ihmisiä vaikean ajan yli. Ja samalla voin ajatella tekeväni työtä, jolla ihmiset myös kuluttavat sähköä mahdollisimman "vihreään aikaan" (kai se niin on, että fossiiliset on kalleimpia tuotantomuotoja). En ole ajatellut tätä tuotteena, josta haluaisin tehdä rahaa. Toisaalta eivät nämä kai ole ristiriidassa keskenänsä.
 
T

tk-

Aktiivinen jäsen
Temez sanoi:
Joo, olen tähän mennessä tietoisesti jättänyt sen tekemättä. Tämä homma lähtenyt liikkeelle harrastuksena ja -22 lopulla haluna jotenkin auttaa sähköjärjestelmää sekä toki yksittäisiä kotitalouksia/ihmisiä vaikean ajan yli. Ja samalla voin ajatella tekeväni työtä, jolla ihmiset myös kuluttavat sähköä mahdollisimman "vihreään aikaan" (kai se niin on, että fossiiliset on kalleimpia tuotantomuotoja). En ole ajatellut tätä tuotteena, josta haluaisin tehdä rahaa. Toisaalta eivät nämä kai ole ristiriidassa keskenänsä.
Klikkaa laajentaaksesi..
Ehkä se on jopa ihan järkevää olla tekemättä donationwarea kyseisellä rajapinnalla.
 
T

Temez

Aktiivinen jäsen
tk- sanoi:
Ehkä se on jopa ihan järkevää olla tekemättä donationwarea kyseisellä rajapinnalla.
Klikkaa laajentaaksesi..
Niin, kai sitä voisi teoriassa vaihtaa tämän käyttämään tuota virolaista Eleringin julkista APIa: https://dashboard.elering.ee/assets/api-doc.html#/nps-controller/getPriceUsingGET

Nyt kun sanoit, niin voisi olla hyvä ajatuskin itseasiassa tehdä tästä versio sitä vasten, jotta käyttäjät voisivat sitten valita datalähteen. Ei varmaan olisi vaikea temppu tehdä.
 
T

Temez

Aktiivinen jäsen
Toisaalta nykyinenkin toimii minusta mallikkaasti. Omalla kohdallani en ole törmännyt mihinkään merkittävään ongelmaan. Suurimmat ongelmat taitavat olla olleet allekirjoittaneen koodissa :)

Huvikseni akateemisesta kiinnostuksesta katselin, että mistä muualta hintatietoja osaava voisi halutessaan saada. Tuntuu olevan autentikointivapaa ei-dokumentoitu API aika monella sähkönmyyjällä, kun nettisivuillaan niitä julkaisevat. Ja on noita sääennusteilla leipänsä tekeviä firmojakin, jotka nykyään noita tietoja sivuillaan esittävät. Aika monesta eri paikasta saisi siis halutessaan imaistua hintatiedot. Mennee harmaalle alueelle, mutta eroaisiko se sitten merkittävästi siitä, että yksityishenkilö niitä tietoja käy katsomassa vaikkapa sähköyhtiön sivuilta. Kun sähköyhtiöt harvemmin mitään mainostulojakaan sivuilla vierailevista käyttäjistä saavat. Noh, kunhan tässä pohdin.
 
T

tk-

Aktiivinen jäsen
Temez sanoi:
Toisaalta nykyinenkin toimii minusta mallikkaasti. Omalla kohdallani en ole törmännyt mihinkään merkittävään ongelmaan. Suurimmat ongelmat taitavat olla olleet allekirjoittaneen koodissa :)

Huvikseni akateemisesta kiinnostuksesta katselin, että mistä muualta hintatietoja osaava voisi halutessaan saada. Tuntuu olevan autentikointivapaa ei-dokumentoitu API aika monella sähkönmyyjällä, kun nettisivuillaan niitä julkaisevat. Ja on noita sääennusteilla leipänsä tekeviä firmojakin, jotka nykyään noita tietoja sivuillaan esittävät. Aika monesta eri paikasta saisi siis halutessaan imaistua hintatiedot. Mennee harmaalle alueelle, mutta eroaisiko se sitten merkittävästi siitä, että yksityishenkilö niitä tietoja käy katsomassa vaikkapa sähköyhtiön sivuilta. Kun sähköyhtiöt harvemmin mitään mainostulojakaan sivuilla vierailevista käyttäjistä saavat. Noh, kunhan tässä pohdin.
Klikkaa laajentaaksesi..
Juu ja saahan ne api-keyllä myös entso-e:stä ladattua kuka tahansa. Itse ajattelisin asiaa niin, että yksityishenkilölle on paikkoja mistä hinnat saa, webscrapingia ei kannata harrastaa kun se haittaa alkuperäisten palveluiden toimintaa ja NordPoolin lakimiesten kanssa ei kannata kokeilla onneaan. NordPool sinällään ei taida kieltää muuta kun webscrapingin omalta sivultaan ja sitten lisenssiehdoissa kielletään uudelleenjakaminen, eli hintoja omaan käyttöön hakiessaan ei välttämättä tee mitään "väärin".

Mutta ei varmastikaan olisi tosiaan ollenkaan hullumpi asia jos tämä paketti osaisi laskea "rankit", sitten se jäisi käyttäjän vastuulle mistä rajapinnasta hakee hinnat vai hakeeko ne valmiiksi laskettujen rankien kera. Entso-E taitaa olla rajapintana vähän Eleringiä haastavampi, ja sinne tarvitsee sen autentikoinnin mukaan myös.
 
Sinun on kirjauduttava sisään tai rekisteröityä kirjoittaaksesi tänne.
Back
Ylös Bottom