sbarmen

Fordi jeg bruker masse spesielle settinger for å legge til moms, nettleie osv. Det er mye enklere i configuration.yaml.

Jeg fiksa det nå, fikk oppdaterte priser ved å endre til NO1 istedenfor Oslo i configuration.yaml. - platform: nordpool VAT: true currency: "NOK" low_price_cutoff: 0.95 region: "NO1" precision: 6 price_type: kWh friendly_name: "Nordpool med Elvia" Denne endringen er nok også grunnen til at mange må slette integrasjonen og legge den til på nytt. Se mer info her: https://github.com/custom-components/nordpool/pull/413 Synes dette var meget dårlig dokumentert....

Ja og da er du på .15. Er en kjent feil det der også.

Slett integrasjonen og legg den til igjen så er du 100% sikker.

Jeg har den i configuration.yaml, funka ikke med oppgradering her. Gå i hacs og reinstaller. Den viser feil versjon etter oppgradering, vet ikke helt hvorfor.

Håper det er så enkelt....

Nå kan det se ut som vi synger på siste verset ifm Nordpool integrasjonen. https://github.com/custom-components/nordpool/issues/417 Om jeg har forstått det riktig kan det set ut som Nordpool begrenser tilgangen på APIet til betalende kunder. https://www.nordpoolgroup.com/api

På tide å sette opp nå? Eller? 🙂

Jeg har et akutt behov for å styre en smartplug på hytta, men det er ikke wifi eller noen form for smarthub der enda. Jeg ønsker å kunne styre en smartplug med en bryter på veggen (gjerne i elko ramme) som er så enkel som en helt standard bryter, uten å måtte legge ledninger. Jeg tenker automatisk på Nexa med RF433 men er det noe annet jeg burde tenke på? Ila 1-2 år kommer det nok en Wifi router og en HA installasjon her, men inntil videre må vi klare oss uten. Er det noen andre forslag eller ideér?

Jeg tenker det er helt nødvendig. Det er kritisk viktig at man har en eller annen mekanisme for å begrense brute-force av passord. Password manager burde være en obligatorisk del av alles kjernesoftware, like viktig som antivirus (nesten).

Nei, linjen har bare en farge. Det er samme farge som prisen i mitt eksempel. Men du kan kun ha 1 farge på linja. Alternativt til fyll er å bruke column.

Jeg har tullet en stund med dette, kanskje det er flere som prøver med det samme? Målet mitt var å få fargekodet strømpriser dynamisk basert på dagens prisnivåer. Jeg mener nå jeg har funnet et oppsett som er ganske bra. Grafen i bakgrunnen er prisene for i dag (og i morgen når tilgjengelig), og de fargekodes ut ifra dagens min, max og mean fra nordpool sensorens attributter. Fargen i tittelen (60 øre/kWh) endres også basert på prisen 'nå', og det samme gjør linjen på grafen. Jeg er litt usikker på hva jeg liker best, men du kan skru av og på linjen på grafen ved å endre stroke_width: under series: mellom 0 og 1 (eller større / tykkere om du vil). Dark mode på mobil. Her er kortet i lovelace. Bare endre sensor_price og sensor_usage, samt oppdater enhet for low_price, high_price og mean_price. type: custom:config-template-card variables: sensor_price: '"sensor.nordpool"' sensor_usage: '"sensor.accumulated_consumption_current_hour_gatenavn_1"' low_price: states['sensor.nordpool'].attributes.min high_price: states['sensor.nordpool'].attributes.max mean_price: states['sensor.nordpool'].attributes.mean current_price: states['sensor.nordpool'].state state_color: | (low, high, current) => { const range = high - low; const third_low = low + range / 3; const third_high = high - range / 3; if (current <= third_low) { return '#42a047'; // Grønn } else if (current <= third_high) { return '#ffa600'; // Oransje } else { return '#db4437'; // Rød } } entities: - ${sensor_price} card: type: custom:apexcharts-card experimental: color_threshold: true header: show: true title: Strømpris og Forbruk show_states: true standard_format: true colorize_states: true now: show: true label: Nå graph_span: 2d span: start: day apex_config: dataLabels: enabled: true legend: show: true chart: height: 210px yaxis: - id: price show: true decimalsInFloat: 0 floating: false forceNiceScale: true extend_to: end - id: usage show: true opposite: true decimalsInFloat: 0 floating: false forceNiceScale: true extend_to: end series: - entity: ${sensor_price} yaxis_id: price extend_to: now name: Pris unit: ' øre/kWh' stroke_width: 1 type: area curve: stepline float_precision: 0 color: ${state_color(low_price, high_price, current_price)} color_threshold: - value: ${low_price} color: '#42a047' - value: ${mean_price} color: '#ffa600' - value: ${high_price} color: '#db4437' show: legend_value: false in_header: before_now data_generator: > return (entity.attributes.raw_today.map((start, index) => { return [new Date(start["start"]).getTime(), entity.attributes.raw_today[index]["value"]]; })).concat(entity.attributes.raw_tomorrow.map((start, index) => { return [new Date(start["start"]).getTime(), entity.attributes.raw_tomorrow[index]["value"]]; })); - entity: ${sensor_usage} yaxis_id: usage type: column name: Forbruk stroke_width: 2 invert: false group_by: func: max show: legend_value: false Før morgendagens priser:

Bare jeg som var rask og kjøpte feil orientering på låsen. Trenger venstre modellen. De har en tjeneste på nettsiden hvor du kan sende bilder av døra di for at skal kunne sjekke for deg. Jeg gjorde det på kjøkkendøren og de bekreftet med en gang om det var en lås som ville fungere.

Har fått montert to stk av Secuyou låsene og de fungerer kjempebra! Rett inn på home assistant med Matter satt opp. Conbee II sticken fikk jeg ikke til å fungere. Prøvde 100 ganger men til slutt gikk jeg til Kjell og kjøpte en Sky Connect. En, to, tre så var det fiksa. Montering var helt elementært. Måtte frese opp litt hullet slik som står i flere videoer på YouTube. Beholdt håndtak ute og måtte tilpasse litt lengde på selve firkant-staget for å få det til å passe. Frakt var inkludert og norsk moms. Jeg gikk litt bananas og hadde tenkt å montere på hytta og boden men de passer ikke (burde sjekket). Jeg har derfor lagt ut to på Finn til kostpris minus frakt i retur om noen er interessert. Det er høyre utgaver. Kjøpt for 4 uker siden ca. Uansett så var dette et bra produkt 🤙 https://www.finn.no/365536092

Det siste forslaget er ikke dumt. Da kan man lagre den i et array og ha den liggende. Den jeg har nå kjører hver dag, bør være like robust men jeg liker tanken.

Jeg har nå laget en input_text.helligdager hjelper: Denne oppdateres via workday med følgende automasjon: alias: Arbeidsdag i dag, eller i morgen? description: >- Vi sjekker om det er arbeidsdag i dag eller i morgen, og så lagrer vi det i et array for å hjelpe med å sette prisen riktig i Nordpool-integrasjonen. trigger: - platform: time at: "00:00:00" - platform: homeassistant event: start condition: [] action: - service: input_text.set_value data: entity_id: input_text.helligdager value: "" - if: - condition: state entity_id: binary_sensor.arbeidsdag_sensor state: "off" then: - service: input_text.set_value data: entity_id: input_text.helligdager value: "{{ now().strftime('%d%m') }}" - if: - condition: state entity_id: binary_sensor.arbeidsdag_i_morgen state: "off" then: - if: - condition: template value_template: >- {# Sjekk om i dag var helligdag (da er ikke array tomt), i tilfelle må begge dager legges til i arrayet. #} {{ states('input_text.helligdager') != '' }} then: - service: input_text.set_value data: entity_id: input_text.helligdager value: > {% set current_value = states('input_text.helligdager') %} {% set aditional_value = (now() + timedelta(days=1)).strftime('%d%m') %} {{ current_value + ',' + aditional_value }} else: - service: input_text.set_value data: entity_id: input_text.helligdager value: "{{ (now() + timedelta(days=1)).strftime('%d%m') }}" mode: single Så har jeg oppdatert templaten slik: {% set s = { "winter_day": 0.3959, "winter_night": 0.3209, "summer_day": 0.4825, "summer_night": 0.4075, "hourly_fixed_cost": 0.0295 } %} {# Strømstøtte på 90% på priser over 91,25 øre (ink. mva) trekkes ifra #} {% set pb = max((current_price - 0.9125) * 0.9, 0.0) %} {% set helligdager = states('input_text.helligdager').split(',') %} {% set today = now().strftime('%d%m') %} {# Er det arbeidsdag? #} {% if today not in helligdager %} {# Sommerpriser fra april til og med desember #} {% if now().month >= 4 and now().month <= 12 %} {% if now().hour >= 6 and now().hour <= 22 %} {# dagtid mellom 6 og 22 #} {{ (s.summer_day + s.hourly_fixed_cost - pb) | float }} {% else %} {# ellers er det natt #} {{ (s.summer_night + s.hourly_fixed_cost - pb) | float }} {% endif %} {% else %} {# ellers er det vinter #} {% if now().hour >= 6 and now().hour <= 22 %} {{ (s.winter_day + s.hourly_fixed_cost - pb) | float }} {% else %} {{ (s.winter_night + s.hourly_fixed_cost - pb) | float }} {% endif %} {% endif %} {% else %} {# ellers er det helg eller fridag (helligdag) #} {% if now().month >= 4 and now().month <= 12 %} {{ (s.summer_night + s.hourly_fixed_cost - pb) | float }} {% else %} {{ (s.winter_night + s.hourly_fixed_cost - pb) | float }} {% endif %} {% endif %} Dette burde fungere. Ser ut til å gjøre det i alle fall. Litt hack å få til men da vil workday med to integrasjoner, den ene med offset 1 for i morgen kunne brukes videre. Ved å gjøre det på denne måten ble isoweekday() overflødig da workday tar med alle uansett. Viktig å kategorisere automasjoner og hjelpere nå så man holder oversikt 😛 Og gode kommentarer på toppen så man husker tilbake.

Jeg ønsker å slippe pyscript kjenner jeg... forsker litt til.

Ok skjønner. Så da må vi prøve å bruke datologikk utenfor Nordpool integrasjonen for å få opp datoen i dag og i morgen lik det du gjorde i ditt array tenker jeg.

Good point 🙂 Det har jeg helt glemt, godt du er djevelens advokat her! Jeg kan lage en workday med 1 dag offset for å håndtere morgendagens priser mer korrekt. Burde ikke noe slikt virke? Jeg tester! {% set s = { "winter_day": 0.3959, "winter_night": 0.3209, "summer_day": 0.4825, "summer_night": 0.4075, "hourly_fixed_cost": 0.0295 } %} {# Strømstøtte på 90% på priser over 91,25 øre (ink. mva) trekkes ifra #} {% set pb = max((current_price - 0.9125) * 0.9, 0.0) %} {# Sjekk om vi ser på dagens dato eller morgendagens dato #} {% set today = now().date() %} {% set tomorrow = (now().date() + timedelta(days=1)) %} {# Bruk arbeidsdag-sensoren for i dag eller i morgen avhengig av dato #} {% if now().date() == today %} {% set arbeidsdag_status = is_state('binary_sensor.arbeidsdag_sensor', 'on') %} {% elif now().date() == tomorrow %} {% set arbeidsdag_status = is_state('binary_sensor.arbeidsdag_i_morgen', 'on') %} {% endif %} {# Er det arbeidsdag? #} {% if arbeidsdag_status %} {# Sommerpriser fra april til og med desember #} {% if now().month >= 4 and now().month <= 12 %} {% if now().hour >= 6 and now().hour <= 22 %} {# dagtid mellom 6 og 22 #} {{ (s.summer_day + s.hourly_fixed_cost - pb) | float }} {% else %} {# ellers er det natt #} {{ (s.summer_night + s.hourly_fixed_cost - pb) | float }} {% endif %} {% else %} {# ellers er det vinter #} {% if now().hour >= 6 and now().hour <= 22 %} {{ (s.winter_day + s.hourly_fixed_cost - pb) | float }} {% else %} {{ (s.winter_night + s.hourly_fixed_cost - pb) | float }} {% endif %} {% endif %} {% else %} {# ellers er det helg eller fridag (helligdag) #} {% if now().month >= 4 and now().month <= 12 %} {{ (s.summer_night + s.hourly_fixed_cost - pb) | float }} {% else %} {{ (s.winter_night + s.hourly_fixed_cost - pb) | float }} {% endif %} {% endif %}

Jeg har lekt litt med dette siste dagene og kommet frem til en løsning som jeg liker. Kort fortalt har jeg nordpool satt opp med virkelige priser, med strømstøtte og natt-tarriff osv osv. Så den viser hva det faktisk koster. Se her (takk til @stigvi for masse inspirasjon): Jeg har tidligere brukt priceanalyzer og Node-Red men ikke vært fornøyd fordi jeg får plutselige problemer pga feil på integrasjon eller annet. Nå har jeg brukt bare rene HA automasjoner som skal sikre at det ikke blir et problem. Neste krav er at du har satt opp VVB som en climate sensor. Jeg har en temperatur sensor på VVB og et smart relé for å bryte strømmen. Temp sensor er ESP32 med en dallas_temp sensor styrt av ESPHome. Koden for ESPhome er som følger: one_wire: - platform: gpio pin: GPIO21 sensor: - platform: dallas_temp address: 0xXXXXXXXXXXXXXXXX name: "Water Heater Temperature" unit_of_measurement: "°C" force_update: true bluetooth_proxy: active: true Climate sensor settes opp i configuration.yaml (fordi du får ikke satt maks/min temp i GUI). Unique_id setter du til hva du vil, da kan du endre navn o.l. i GUI om du ønsker, men ikke påkrevd. Fordelen med at det er en climate sensor er at jeg aldri skrur av VVB. Den vil ha en "failsafe" på low temp. Det betyr at man er ganske trygg på at det aldri blir helt iskaldt vann. For å ytterligere sikre mot dette kan du redusere utslagene i automasjonen (juster ned / opp med bare 5 eller 10 grader f.eks.). climate: - platform: generic_thermostat unique_id: 123nn342wwkjnee234 name: Varmtvannsbereder heater: switch.varmtvannsbereder target_sensor: sensor.water_heater_temperature min_temp: 30 max_temp: 80 ac_mode: false target_temp: 65 Min automasjon akkurat nå er å sjekke prisen kvart på hver time, for å se om neste timen er veldig dyr, eller veldig billig sammenlignet med denne timen ( mer enn 20% differanse opp eller ned). Dersom det er tilfelle pusher vi temperaturen kraftig opp eller ned siste kvarteret. Så når Nordpool integrasjonen setter ny pris på hel time så sjekker automasjonen igjen. Dersom det er en billig time (low_price fra nordpool) så setter den ned temperaturen. Dyre timer er valgt som de 12 dyreste timene i døgnet og da setter vi ned temperaturen på climate sensoren. Jeg har også en nedjustering av temperaturen fra 00 til 05, da lader typisk også elbilen (egen automasjon for å passe på effektmaks) men dette kan jo droppes eventuelt. Til sist, dersom ingen av de andre tingene slår inn så setter man "default temperatur". Default temperatur er basert på egen hjelper som jeg kaller VVB Target. Den har jeg satt opp som hjelper i HA. I denne automasjonen bruker jeg 2 hjelpere, en input number for target temperatur, og en input_boolean for å kunne gjøre det slik at brukeren kan endre target temperatur selv på climate sensoren. Når automasjonen kjører og justerer temperaturen så slår den på input_boolean.vvb_auto_update, så "vet" den neste automasjonen at det er automatisk justering av VVB temp som pågår. Dersom brukeren skifter temperatur på climate sensoren manuelt så skjer ikke dette og da justeres Måltemp input_number. Automasjon for å justere temp automatisk på VVB: alias: Optimal styring av varmtvannsbereder basert på strømpriser trigger: - platform: time_pattern minutes: 45 id: kvart-på - platform: state entity_id: sensor.nordpool attribute: current_price id: ny-pris - platform: homeassistant event: start id: ny-pris condition: [] action: - variables: current_price: "{{ states('sensor.nordpool') | float }}" next_price: > {% set now = now().hour %} {% set next_price = state_attr('sensor.nordpool', 'today')[now + 1] if now < 23 else state_attr('sensor.nordpool', 'tomorrow')[0] %} {{ next_price }} low_price_threshold: "{{ state_attr('sensor.nordpool', 'off_peak_2') }}" high_price_threshold: "{{ state_attr('sensor.nordpool', 'max') }}" current_setpoint: "{{ states('input_number.vvb_target') | float }}" price_change_threshold: 0.2 today_prices: "{{ state_attr('sensor.nordpool', 'today') }}" sorted_prices: "{{ today_prices | sort(reverse=True) }}" top_12_prices: "{{ sorted_prices[:12] }}" - service: input_boolean.turn_on target: entity_id: - input_boolean.vvb_auto_update data: {} - choose: - conditions: - condition: trigger id: kvart-på - condition: template value_template: "{{ next_price / current_price <= (1 - price_change_threshold) }}" sequence: - service: climate.set_temperature data: entity_id: climate.varmtvannsbereder temperature: "{{ current_setpoint - 20 }}" - conditions: - condition: trigger id: kvart-på - condition: template value_template: "{{ next_price / current_price >= (1 + price_change_threshold) }}" sequence: - service: climate.set_temperature data: entity_id: climate.varmtvannsbereder temperature: "{{ current_setpoint + 20 }}" - conditions: - condition: trigger id: kvart-på sequence: [] alias: Når utløst kvart på og ingenting skal gjøres (unngå at default handling kjøres) - conditions: - condition: trigger id: ny-pris - condition: template value_template: > {% set now = now().hour %} {{ today_prices[now] in top_12_prices }} sequence: - service: climate.set_temperature data: entity_id: climate.varmtvannsbereder temperature: "{{ current_setpoint - 15 }}" - conditions: - condition: trigger id: ny-pris - condition: state entity_id: sensor.nordpool attribute: low_price state: true sequence: - service: climate.set_temperature data: entity_id: climate.varmtvannsbereder temperature: "{{ current_setpoint + 15 }}" - conditions: - condition: time after: "00:00:00" before: "05:00:00" sequence: - service: climate.set_temperature data: entity_id: climate.varmtvannsbereder temperature: "{{ current_setpoint - 15 }}" default: - service: climate.set_temperature data: entity_id: climate.varmtvannsbereder temperature: "{{ current_setpoint }}" - service: input_boolean.turn_off target: entity_id: - input_boolean.vvb_auto_update data: {} mode: single Automasjon for å justere måltemp sensor hjelper. Denne lagrer så en ny måltemp med samme offset som gjeldende innstilling. Så f.eks., dersom vi nå er på en dyr time og vi har justert ned varmen med 15 grader så kan input_number.vvb_target stå på 65 grader, climate sensoren er da på 50 grader. Dersom du justerer climate opp med 5 grader, til 55, så vil input_number.vvb_target lagres til 55+15, altså 70 grader. alias: Oppdater varmtvannsbereder måltemp hjelper description: >- Denne automasjonen endrer hjelperen som er måltemperaturen til varmtvannsberederen. Den sjekker at ikke automasjonen har endret prisen først, og så setter den setpunkt med samme offset som climate sensoren har i øyeblikket. trigger: - platform: state entity_id: climate.varmtvannsbereder attribute: temperature condition: - condition: state entity_id: input_boolean.vvb_auto_update state: "off" action: - variables: current_setpoint: "{{ state_attr('climate.varmtvannsbereder', 'temperature') | float }}" previous_setpoint: "{{ trigger.from_state.attributes.temperature | float }}" stored_target: "{{ states('input_number.vvb_target') | float }}" - choose: - conditions: - condition: template value_template: "{{ previous_setpoint == stored_target }}" sequence: - service: input_number.set_value data: entity_id: input_number.vvb_target value: "{{ current_setpoint }}" - conditions: - condition: template value_template: "{{ previous_setpoint != stored_target }}" sequence: - service: input_number.set_value data: entity_id: input_number.vvb_target value: "{{ current_setpoint + (stored_target - previous_setpoint) }}" mode: single Dette er work-in-progress, men så langt fungerer det ganske godt. Neste skritt er at jeg skal sette opp samme logikk på to varmekabler på badene, og så kan det brukes på varme i andre rom slik som stue, kjøkken, soverom osv. Fordelen med å gjøre det på denne måten er at du får god WAF. Dersom kona skifter temp på climate sensorene i GUI eller på veggen, så fungerer det som forventet. Håper dette kan være nyttig for noen. 🙂

Bare en liten oppdatering. Jeg bruker nå workday sensor og det ser ut som det fungerer så langt. Skal følge med for å trippelt-sjekke men her er koden om noen andre vil prøve. For å få dette til må du har workday integrasjonen satt opp og den må hete binary_sensor.arbiedsdag_sensor (eller endre koden under). Jeg har testet både i configuration.yaml og med integrasjonen direkte i GUI i HA. Sistenevnte betyr at man bare limer inn denne delen i "mal for tilleggskostnader". Den går ikke å redigere etterpå men du kan bare slette den og legg til en ny når du vil. Jeg har lagt hele configen i configuration.yaml for safekeeping og fremtidige justeringer og så bare limte jeg den inn i GUI. {% set s = { "winter_day": 0.3959, "winter_night": 0.3209, "summer_day": 0.4825, "summer_night": 0.4075, "hourly_fixed_cost": 0.0295 } %} {# Strømstøtte på 90% på priser over 91,25 øre (ink. mva) trekkes ifra #} {% set pb = max((current_price - 0.9125) * 0.9, 0.0) %} {# Er det arbeidsdag? #} {% if is_state('binary_sensor.arbeidsdag_sensor', 'on') %} {# Sommerpriser fra april til og med desember #} {% if now().month >= 4 and now().month <= 12 %} {% if now().hour >= 6 and now().hour <= 22 %} {# dagtid mellom 6 og 22 #} {{ (s.summer_day + s.hourly_fixed_cost - pb) | float }} {% else %} {# ellers er det natt #} {{ (s.summer_night + s.hourly_fixed_cost - pb) | float }} {% endif %} {% else %} {# ellers er det vinter #} {% if now().hour >= 6 and now().hour <= 22 %} {{ (s.winter_day + s.hourly_fixed_cost - pb) | float }} {% else %} {{ (s.winter_night + s.hourly_fixed_cost - pb) | float }} {% endif %} {% endif %} {% else %} {# ellers er det helg eller fridag (helligdag) #} {% if now().month >= 4 and now().month <= 12 %} {{ (s.summer_night + s.hourly_fixed_cost - pb) | float }} {% else %} {{ (s.winter_night + s.hourly_fixed_cost - pb) | float }} {% endif %} {% endif %} Jeg har nå testet gjennom flere arbeidsdager og helgedager og det fungerer knirkefritt. 🙂 Husk å sjekke alle kostnadene i s.array øverst. Dette er Elvia eller hva enn du har som nettleverandør, hourly additional cost er Tibber sitt faste påslag i mitt tilfelle.

Ja jeg kan det, ønsker å holde meg mest mulig uavhengig av cloud og eksterne tjenester så det står egentlig på listen min å bli enda mer uavhengig av Tibber ...

Ok takk. Da er jeg usikker på om det blir rewards på meg. Nå fungerer elbillading og effektregulering perfekt og så lar jeg i praksis Tibber bestemme... nei det tror jeg at jeg dropper.

Jeg har Tibber og signet opp for grid rewards, men jeg styrer mine elbiler og lading selv, ikke med Tibber. Har lagt inn laderoboten i Tibber men de får ikke styre. Vet ikke om jeg da vil få grid rewards, noen med erfaring?

Man kan også få Tibber Pulse til å sende data lokalt til en MQTT tjener på din hjemmeautomasjonsløsning. https://github.com/MSkjel/LocalPulse2Tibber