thoralex

Jeg har nok rotet en del med tallene underveis ja, og er egentlig veldig usikker på hvordan det er riktig å bruke dem. Lista i sensoren starter jo på "00:00:00+01:00" som betyr klokka ett i mitt hode, men prisene skal vel gå fra midnatt så det kan jo ikke stemme? Og starter lista på 0 eller 1? Tallene er uansett bare veiledende, må fundere litt mer på hva som er optimalt. Edit: ser at jeg har tolket xx:xx som "fra og med":"til og med", mens det riktige ser ut til å være fra:til. Så 14:16 gir to timer og ikke tre som jeg trodde.

Selvfølgelig, listen oppdateres jo der. Da har jeg endt opp med dette: - platform: template sensors: billigste_6_timer_entsoe_offpeak: value_template: >- {% set l= ( state_attr('sensor.entsoe', 'prices')[14:15]|list + state_attr('sensor.entsoe', 'prices')[21:30]|list + state_attr('sensor.entsoe', 'prices')[33:37]|list ) |sort (attribute='price') %} {% set t = now() %} {{ (t >= as_datetime(l[0].time) and t <= as_datetime(l[0].time) + timedelta(hours = 1)) or (t >= as_datetime(l[1].time) and t <= as_datetime(l[1].time) + timedelta(hours = 1)) or (t >= as_datetime(l[2].time) and t <= as_datetime(l[2].time) + timedelta(hours = 1)) or (t >= as_datetime(l[3].time) and t <= as_datetime(l[3].time) + timedelta(hours = 1)) or (t >= as_datetime(l[4].time) and t <= as_datetime(l[4].time) + timedelta(hours = 1)) or (t >= as_datetime(l[5].time) and t <= as_datetime(l[5].time) + timedelta(hours = 1)) }} Ser det fornuftig ut?

Er det ikke bare å dele 1600? Eller rettere sagt starte 2100? state_attr('sensor.average_electricity_price_today', 'prices')[21:31] + state_attr('sensor.average_electricity_price_today', 'prices')[33:41] Er det ikke det denne templaten vil gjøre? Starte 2100 i dag og gå til 1600 i morra?

Målet var å lage en liste og plukke de 6 billigste uavhengig av hvilken av de to periodene de er i. Eller rettere sagt: plukke de 6 billigste timene i et døgn untatt periodene 0600-0900 og 16-21. Nordpool sensoren jeg postet over fungerte etter hensikten bortsett fra at den oppdaterte ved midnatt som var et veldig ugunstig tidspunkt.

Glemte kanskje å presisere at jeg prøver å få det til basert på entso-e. Men jeg tror jeg fikk det til nå, må bruke bare 6 og ikke 06 i timene. - platform: template sensors: billigste_6_timer_entsoe_offpeak: value_template: >- {% set l= state_attr('sensor.entsoe', 'prices')[21:6] + state_attr('sensor.entsoe', 'prices')[9:16] |sort(attribute='price') %} {% set t = now() %} {{ (t >= as_datetime(l[0].time) and t <= as_datetime(l[0].time) + timedelta(hours = 1)) or (t >= as_datetime(l[1].time) and t <= as_datetime(l[1].time) + timedelta(hours = 1)) or (t >= as_datetime(l[2].time) and t <= as_datetime(l[2].time) + timedelta(hours = 1)) or (t >= as_datetime(l[3].time) and t <= as_datetime(l[3].time) + timedelta(hours = 1)) or (t >= as_datetime(l[4].time) and t <= as_datetime(l[4].time) + timedelta(hours = 1)) or (t >= as_datetime(l[5].time) and t <= as_datetime(l[5].time) + timedelta(hours = 1)) }}

Takk, da var jeg på rett spor med mine også. Har du innspill på hvordan man kan plukke fra bestemte tidsrom? Jeg har brukt denne med nordpool for å unngå å koble inn store laster i perioder hvor forbruket vanligvis er høyt, selv om de timene skulle være billigere: - platform: template sensors: billigste_6_timer_offpeak: value_template: >- {% set l = (state_attr('sensor.nordpool', 'raw_today') |selectattr('start', '<', now().replace(hour=6,minute=0,second=0,microsecond=0)) |list + state_attr('sensor.', 'raw_today') |selectattr('start', '>=', now().replace(hour=9,minute=0,second=0,microsecond=0)) |selectattr('start', '<', now().replace(hour=16,minute=0,second=0,microsecond=0)) | list + state_attr('sensor.', 'raw_today') |selectattr('start', '>=', now().replace(hour=21,minute=0,second=0,microsecond=0)) | list) | sort(attribute='value') %} {{ (now() >= l[0].start and now() <= l[0].end) or (now() >= l[1].start and now() <= l[1].end) or (now() >= l[2].start and now() <= l[2].end) or (now() >= l[3].start and now() <= l[3].end) or (now() >= l[4].start and now() <= l[4].end) or (now() >= l[5].start and now() <= l[5].end) }}

Nordpool-integrasjonen liker ikke når du har to av den, men det går på et vis. Sensorene må konfigureres i .yaml, og den siste bruker veldig lang tid (minst 10 minutt og opptil et par timer) på å komme i gang etter restart så den du bruker til styring må ligge først. Ellers fungerer stigvi sin config for nettleie fint, har brukt den lenge med tilpasninger til mitt selskap.

Ser ut som det er samme som før her og ja...

Det var sånn jeg oppfattet det ja. Jeg styrer bare en varmtvannsbereder, så for meg er det nok mer praktisk å bare bruke de billigste timene. Når de billigste timene vanligvis er mellom 2200-0600 på grunn av nettleia så blir en slik sensor ikke en god løsning tror jeg.

Ser fin ut den der, men jeg tror det blir litt overkill for min bruk. Har kun en device å styre, og den overstyres delevis av andre automasjoner for å holde effektleddet på nettleien. Ser ikke ut som man kan velge antall timer som skal settes som billig, eller når på døgnet?

Kommet ny versjon nå, hvor dette skal være endret på. Har oppdatert testsensorene mine, så får vi se hvordan resultatet ser ut...

Takker så mye! Det er hovedgrunnen til at jeg vil eksperimentere med dette. De billigste seks timene er ofte mellom 2200 og 0600 på grunn av lavere nettleie, men når det blir delt på to forskjellige døgn av nordpool-integrasjonen gir det litt uønskede resultater. Har laget et lite utvalg forskjellige sensorer basert på koden din nå for å se hvordan de oppfører seg noen dager.

Du har alt for mye tiltro til mine kodekunnskaper Dette er sensoren jeg hadde laget, rett og slett sensoren for billigste timer fra en annen tråd her hvor jeg har prøvd å erstatte nordpool prissensoren og attributtene med entso-e sine. Regnet jo ikke med at det var så enkelt. - platform: template sensors: billigste_6_timer_entsoe: value_template: >- {% set x = states("sensor.time") %} {% set l=state_attr('sensor.current_electricity_market_price', 'prices')|sort(attribute='price') %} {{ (now() >= l[0].start and now() <= l[0].end) or (now() >= l[1].start and now() <= l[1].end) or (now() >= l[2].start and now() <= l[2].end) or (now() >= l[3].start and now() <= l[3].end) or (now() >= l[4].start and now() <= l[4].end) or (now() >= l[5].start and now() <= l[5].end) }}

Har noen laget sensorer for billigste timer basert på entso-e enda? Jeg har prøvd å modifisere de jeg har basert nordpool (som er kopiert fra forumet her) men får dem ikke til å fungere med entso-e.

Har du lest tråden Nordpool sensor for Home Assistant? Mange gode eksempler der du kan kopiere i den. Jeg startet med et av dem og laget min egen, det er ganske greit å modifisere når man har et utgangspunkt man liker.

Takk stigvi, du gjør det enkelt for oss amatører som vanlig!

Skjønner. Praktisk at det skjer automatisk, men som du sier er det egentlig ikke så nøye for strømstyringen sin del.

Interessangt! Jeg har lagt den til nå, ser ut til å fungere. Noen av sensorene den lager ser ut som kan være nyttig. Får knote litt og se om jeg får den inn i en apexchart lik den jeg har for nordpool så jeg kan sammenligne resultatene litt. Må valutakursen oppdateres manuelt? Hvordan gjør nordpool-integrasjonen det? Blir spennende å se hvordan den utvikler seg og hva folk finner på med den.

Takk, da ser jeg hvor jeg har rotet til ting!

# Loads default set of integrations. Do not remove. default_config: # Text to speech tts: - platform: google_translate automation: !include automations.yaml script: !include scripts.yaml scene: !include scenes.yaml #Sensordel: sensor: #Nordpool sensor inkludert nettleie - platform: nordpool # Should the prices include vat? Default True VAT: True # What currency the api fetches the prices in # this is only need if you want a sensor in a non local currency currency: "NOK" # Option to show prices in cents (or the equivalent in local currency) price_in_cents: false # Helper so you can set your "low" price # low_price = hour_price < average * low_price_cutoff low_price_cutoff: 0.95 # What power regions your are interested in. # Possible values: "DK1", "DK2", "FI", "LT", "LV", "Oslo", "Kr.sand", "Bergen", "Molde", "Tr.heim", "Tromsø", "SE1", "SE2", "SE3","SE4", "SYS", "EE" region: "Tr.heim" # How many decimals to use in the display of the price precision: 4 # What the price should be displayed in default # Possible values: MWh, kWh and Wh # default: kWh price_type: kWh # This option allows the usage of a template to add a tariff. # now() always refers start of the hour of that price. # this way we can calculate the correct costs add that to graphs etc. # The price result of the additional_costs template expects this additional cost to be in kWh and not cents as a float # default {{0.0|float}} additional_costs: '{% set s = { "hourly_fixed_cost": 0.0, "winter_night": 0.3139, "winter_day": 0.4226, "summer_day": 0.4224, "summer_night": 0.3139, "cert": 0.00 } %} {% if now().month >= 5 and now().month <11 %} {% if now().hour >=6 and now().hour <22 %} {{s.summer_day+s.hourly_fixed_cost+s.cert|float}} {% else %} {{s.summer_night+s.hourly_fixed_cost+s.cert|float}} {% endif %} {% else %} {% if now().hour >=6 and now().hour <22 %} {{s.winter_day+s.hourly_fixed_cost+s.cert|float}} {%else%} {{s.winter_night+s.hourly_fixed_cost+s.cert|float}} {% endif %} {% endif %}' #Nordpool sensor uten nettleie - platform: nordpool # Should the prices include vat? Default True VAT: True # What currency the api fetches the prices in # this is only need if you want a sensor in a non local currency currency: "NOK" # Option to show prices in cents (or the equivalent in local currency) price_in_cents: false # Helper so you can set your "low" price # low_price = hour_price < average * low_price_cutoff low_price_cutoff: 0.95 # What power regions your are interested in. # Possible values: "DK1", "DK2", "FI", "LT", "LV", "Oslo", "Kr.sand", "Bergen", "Molde", "Tr.heim", "Tromsø", "SE1", "SE2", "SE3","SE4", "SYS", "EE" region: "Tr.heim" # How many decimals to use in the display of the price precision: 3 # What the price should be displayed in default # Possible values: MWh, kWh and Wh # default: kWh price_type: kWh # This option allows the usage of a template to add a tariff. # now() always refers start of the hour of that price. # this way we can calculate the correct costs add that to graphs etc. # The price result of the additional_costs template expects this additional cost to be in kWh and not cents as a float # default {{0.0|float}} additional_costs: "{{0.0|float}}" #RPI #rpi system monitor - platform: systemmonitor resources: - type: disk_use_percent arg: / - type: disk_use arg: / - type: disk_free arg: / - type: memory_use_percent - type: processor_use - type: processor_temperature - type: disk_use_percent arg: /dev/mmcblk0p1 #Strøm: #akkumulert strømforbruk denne time - platform: integration name: stromforbruk denne time unit_time: "h" unit_prefix: k source: sensor.ams_p round: 3 #derivert strømforbruk denne time - platform: derivative source: sensor.stromforbruk_denne_time name: stromforbruk derivert effekt round: 1 unit_time: "h" time_window: "00:05:00" #bergnet forbruk denne time template: - sensor: - name: "estimert timeforbruk ufiltrert" unit_of_measurement: "kWh" device_class: power state: "{{ (states('sensor.energy')|float(15)+states('sensor.stromforbruk_derivert_effekt')|float(0) *(3600-now().minute*60-now().second)/3600) | round(3) }}" #utility meter setup utility_meter: hourly_energy: #testing? source: sensor.energy name: Hourly Energy cycle: hourly tariffs: daily_energy: source: sensor.energy name: Daily Energy cycle: daily tariffs: monthly_energy: source: sensor.energy name: Monthly Energy cycle: monthly tariffs: accumulated_energy_hourly: source: sensor.energy_per_hour cycle: hourly template: - sensor: - name: 'Daily Energy Total' device_class: energy unit_of_measurement: kWh state: > {% if is_number(states('sensor.daily_energy_offpeak')) and is_number(states('sensor.daily_energy_peak')) %} {{ states('sensor.daily_energy_offpeak') | float + states('sensor.daily_energy_peak') | float }} {% else %} None {% endif %} #Klimastyring: #thermostat bad climate: - platform: generic_thermostat name: Thermostat bad heater: switch.varme_bad_switch target_sensor: sensor.lumi_lumi_weather_temperature min_temp: 5 max_temp: 20 ac_mode: false # target_temp: 18 cold_tolerance: 0.5 hot_tolerance: 0 min_cycle_duration: minutes: 2 keep_alive: minutes: 5 initial_hvac_mode: "heat" away_temp: 14 comfort_temp: 18 precision: 0.1 Her er alt fra start til slutten på sensordelen. Resten av dokumentet er en haug med binærsensorer som plukker billige strømtimer på forskjellige måter, så de er neppe av interesse...

Den ser slik ut: #derivert strømforbruk denne time - platform: derivative source: sensor.stromforbruk_denne_time name: stromforbruk derivert effekt round: 1 unit_time: "h" time_window: "00:05:00" Men jeg tror feilen ligger i sensoren for estimert timeforbruk, for hvis jeg flytter den til et annet sted i dokumentet får jeg alltid samme feilmelding men med navnet som på sensoren som før den i dokumentet. Linje 16 er forresten en tekstlinje med # foran, så den har neppe noe med saken å gjøre. Derivative sensoren starter på linje 136, så jeg ser ikke helt sammenhengen med linje 16...

Da får jeg feilmelding: Ser ut som det blir noe feil med syntaxen og at det blir lest i sammenheng med sensoren over?

Nå har jeg sittet fast på denne i flere uker... Uansett hva jeg prøver så får jeg bare feilmeldinger. #bergnet forbruk denne time - platform: template sensors: - name: "estimert timeforbruk ufiltrert" unit_of_measurement: "kWh" device_class: power state: "{{ (states('sensor.energy')|float(15)+states('sensor.stromforbruk_derivert_effekt')|float(0) *(3600-now().minute*60-now().second)/3600) | round(3) }}" gir: Noen forslag? Disse feilmeldingene er ikke helt enkle å tolke når man er nybegynner...

Snodig, hadde smartspot selv men da fant jeg den på nettsiden også.

GE pleide å ha en billig spotprisavtale som varte i ett år, og så flytte kunden over på en dyrere avtale. Men da var det jo bare å bytte til den nye billigavtalen, ikke noe stort problem, og tok fem minutt å fikse når varselet kom. Mange selskap som operer sånn. Før byttet jeg årlig mellom slike avtaler i forskjellige selskap, men god kundeservice har gjort at jeg har blitt hos GE selv om de ikke er billigst Hvilke avtaler mener du de har som de skjuler på nettsiden, og kan du dokumentere den påstanden?