thoralex

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?

Virker som en stor andel av dem som flykter fra Tibber i dag bytter til GE, så de skvatt nok litt når de plutselig fikk en haug nye kunder. Virker fornuftig å avslutte kampanjen da så de kan konsentrere seg om å ta imot de nye kundene fra Tibber.

Mulig jeg må høre med dem da. Har vert kunde hos dem en god stund, er sikker på at det gikk an å finne den i appen før...

Hvor fant du koden din?

Takk, jeg prøver det så får vi se hva som skjer. Er det mulig å "simulere" koden i home assistant på noen måte, uten å måtte vente vente flere dager for å se hva som skjer? Ville gjort det mye enklere å eksperimentere med slikt...

Eksperimentene fortsetter... I dag var plutselig strømprisen høyest i de timene den normalt et lavest, så da må det gjøres litt mer avansert for å takle det. Dette er en videreutvikling av den samme koden som tidligere, men men her er intensjonen å plukke de seks billigste timene i døgnet, unntatt de to periodene hvor forbruket mitt vanligvis er høyest (av hensyn til effektprisingen i nettleia). Jeg laget denne i går ettermiddag. I natt slo den inn fra midnatt til 0600, som er de dyreste timene dette døgnet... Det var jo ikke helt etter planen. Mulig den bare registrer den første tidsperioden og ignorer de andre? Jeg har også prøvd med 8 timer men ved alt over 6 blir sensoren unavailable, som jeg tror støtter teorien om at den bare "ser" den første perioden. Jeg har eksperimentert litt med tegnsetting og slikt, men har ikke nok forståelse av hvordan slik koding fungerer enda så det har bare laget trøbbel. #plukke billigste 6 timer 0000-0600, 0900-1500, 2000-0000 - platform: template sensors: billigste_6_timer_offpeak: value_template: >- {% set x = states("sensor.time") %} {% set l=state_attr('sensor.nordpool_kwh_trheim_nok_3_095_025', 'raw_today') |selectattr('start', '>=', now().replace(hour=0,minute=0,second=0,microsecond=0)) |selectattr('start', '<', now().replace(hour=6,minute=0,second=0,microsecond=0)) |selectattr('start', '<', now().replace(hour=9,minute=0,second=0,microsecond=0)) |selectattr('start', '<', now().replace(hour=15,minute=0,second=0,microsecond=0)) |selectattr('start', '<', now().replace(hour=20,minute=0,second=0,microsecond=0)) |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) }} Noen som har forslag til løsning?

Med en utility meter helper som henter accumulated active import fra pow-u og resettes hver time.

Takk, da får det bare være sånn enn så lenge. Komplisert nok å lære seg yaml når man ikke kan noe koding fra før!

Hei! Etter beskrivelsene i denne tråden har jeg nå endt opp med dette: #Plukke billigste fire timer om natten - platform: template sensors: billigste_4_timer_natt: value_template: >- {% set x = states("sensor.time") %} {% set l=state_attr('sensor.nordpool_kwh_trheim_nok_3_10_025', 'raw_today')|selectattr('start', '>=', now().replace(hour=0,minute=0,second=0,microsecond=0))|selectattr('start', '<', now().replace(hour=6,minute=0,second=0,microsecond=0))|selectattr('start', '<', now().replace(hour=22,minute=0,second=0,microsecond=0))|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) }} Dette fungerer, men ikke helt etter hensikten. Målet er å velge de fire billigste timene i perioden 22:00-06:00, mens denne velger de fire billigste i periodene 00:00-06:00 og 22:00-00:00. Den velger altså fra timene i samme døgn, og ikke fra samme natt (delt på to døgn) som jeg ønsket. Da går jeg potensielt glipp av de to billigste timene ved store prisøkninger om natten. Har noen forslag til kode som løser dette?

Biltema har også denne for dem som vil beholde dusjen de har. Har ikke testet den (enda) så jeg vet ikke hvor godt det funker.

Slår alltid av den om jeg får problemer med en nettside ja, men jeg hadde ikke fått med meg at adlists oppdateres automatisk så det falt meg rett og slett ikke inn at det kunne være det.

Det er utvilsomt penger å spare på flytting av forbruk ja, og også her lenger nord hvor prisene er lavere men likevel kan svinge veldig mye enkelte dager. For et par uker siden varierte prisen fra 8 til 250øre/kwt på samme dag, da vil man ikke at vvb skal gå i den dyreste timen. Håper bare det kommer noe litt mer "ferdig" system for home assistant ettervert!

Da fant jeg endelig feilen! www.nordpoolgroup.com har på en eller annen måte på en av adlistene på piholen min, og ble blokkert av den. Etter å ha whitelistet adressen ser ting ut til å fungere igjen.

Takk. Rart, ingen til skal være endret på nettverket på lenge.

Nei, jeg regner med at det er hos meg det er noe feil. Jeg skjønner bare ikke hva det kan være...

Hei! tenkte jeg skulle lage en egen tråd og ikke rote til den andre med dette problemet. Nordpool-integrasjonen min sluttet å fungere i helgen, virker som den ikke klarer å hente dataene fra nordpool. Jeg har ikke tuklet med HA i helgen utenom å installere et par oppdateringer som dukket opp, så jeg tror ikke det er jeg som har rotet til noe. Har slettet og reinstallert hele integrasjonen og laget sensoren på nytt uten at det hjalp, og også resatt HA til en backup fra før problemet oppsto uten tegn til bedring. Stort lenger enn det kommer jeg ikke med mine kunnskaper... Her er loggen for feilen som opsstår: Håper noen kan få noe nyttig ut av den? Takk