sbarmen

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

Kjører du Sid kan du være ganske bleeding også. Valgene er mange. Lurer på om de klarer å bake inn raskere oppdateringer på core. Vi får se 🤷

Jeg har Shelly Pro 3 og den har potensialfrie kontrakter i alle fall. 🙂

Konverterte fra Deconz til Z2M selv for 2-3 år siden. Angrer ikke et sekund. For å konvertere mest mulig effektivt kjørte jeg opp begge systemer samtidig, med hver sin stick. Z2m sto konstant i pairing mode. Når jeg slettet enheter i Deconz så går de over i pairing mode, noen ganger måtte et power-switch til, så da la de seg til i Z2M - en etter en. Da ble det veldig enkelt å ta over løsningen steg for steg. Faktisk valgte jeg å kjøre den ene sticken på en laptop (den som hadde Z2M), for da kunne jeg også bruke Touchlink på enheter som av en eller annen grunn ikke kom over. I praksis brukte jeg dette bare på 2-3 Hue enheter før jeg begynte å kontrollert fjerne de fra Deconz heller.

God poeng! Jeg bruker Tibber, de har vel et påslag per kWt ... jeg glemmer at de har en rolle å spille her. Basert på rask research ser det ut til at Tibber legger til 2,95 øre pr. kWt så da er fast påslag 0.0295 om jeg skjønner det rett. Med påslag på 0.0295 (hourly_fixed_cost) ble prisen min for samme timen: - start: '2024-07-25T11:00:00+02:00' end: '2024-07-25T12:00:00+02:00' value: 0.8756 som er det samme som 87,6 øre som Tibber sier det koster i appen. 🙂 Da tror jeg vi er på rett spor.

Dette er helt feil paste 😛 Klassisk copy/paste error. Sorry! - platform: nordpool VAT: true currency: "NOK" low_price_cutoff: 0.95 region: "Oslo" precision: 3 price_type: kWh friendly_name: "Nordpool med Elvia" additional_costs: >- {% set s = { "winter_day": 0.3959, "winter_night": 0.3209, "summer_day": 0.4825, "summer_night": 0.4075, "hourly_fixed_cost": 0.01 } %} {% set helligdager = ["0101", "0328", "0329", "0401", "0501", "0509", "0517", "0520", "1225", "1226"] %} {# 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 i dag en ukedag, og ikke helligdag? #} {% if now().isoweekday() <= 5 and now().strftime("%m%d") 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 5 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 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 lekte litt med "other" og "hourly_fixed_cost" (basert på din versjon @stigvi, og fra dokumentasjonen for nordpool på HACS). Denne er den jeg for øyeblikket kjører. hourly_fixed_cost brukes kun fordi jeg ser at jeg får et resultat som typisk er ca 1 øre for lavt. Noen ganger 2 øre. Så derfor er den lagt til, men i praksis skal den ikke være nødvendig. Eksempel akkurat nå, her fra sensorens attribute: - start: '2024-07-25T11:00:00+02:00' end: '2024-07-25T12:00:00+02:00' value: 0.8661 Mens strømprisen akkurat nå er:

Jeg har lekt litt med denne nordpool sensoren, og jeg har heller ikke klart å få inn noen måte å bruke workday sensoren, så det er manuelt for nå. Men det jeg ikke skjønner er at jeg bommer på prisen med ca 1 øre her og der. Det har jo ingenting å si, men jeg skjønner ikke helt hvorfor. Elvia har alle priser inkludert i på slaget sitt ifm deres dokumentasjon (se her https://www.elvia.no/nettleie/alt-om-nettleiepriser/nettleiepriser-for-privatkunder/). Så langt ser dette ut å være 99% riktig men om noen skjønner hvorfor den noen ganger bommer så tar jeg gjerne imot tips. - platform: nordpool VAT: true currency: "NOK" low_price_cutoff: 0.95 region: "Oslo" precision: 4 price_type: kWh friendly_name: "Nordpool med Elvia" additional_costs: >- {% set s = { "winter_day": 0.3959, "winter_night": 0.3209, "summer_day": 0.4825, "summer_night": 0.4075, "other": 0.01 } %} {% set helligdager = ["0101", "0328", "0329", "0401", "0501", "0509", "0517", "0520", "1225", "1226"] %} {# 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 i dag en ukedag, og ikke helligdag? #} {% if now().isoweekday() <= 5 and now().strftime("%m%d") 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 5 og 22 #} {{ (s.summer_day + s.hourly_fixed_cost + s.other - pb) | float }} {% else %} {# ellers er det natt #} {{ (s.summer_night + s.hourly_fixed_cost + s.other - pb) | float }} {% endif %} {% else %} {# ellers er det vinter #} {% if now().hour >= 6 and now().hour <= 22 %} {{ (s.winter_day + s.hourly_fixed_cost + s.other - pb) | float }} {% else %} {{ (s.winter_night + s.hourly_fixed_cost + s.other - pb) | float }} {% endif %} {% endif %} {% else %} {# ellers er det helg eller helligdag #} {% if now().month >= 4 and now().month <= 12 %} {{ (s.summer_night + s.hourly_fixed_cost + s.other - pb) | float }} {% else %} {{ (s.winter_night + s.hourly_fixed_cost + s.other - pb) | float }} {% endif %} {% endif %} Har lurt på om det kan være MVA kanskje. At jeg burde regne alt før moms og legge på moms til slutt. Men her _skal_ jo alt være inkludert MVA. Jeg har også prøvd litt forskjellig på precision, men jeg tror alt over 3 gir ganske gode resultater.

Ja jeg har også basert automasjon på den Tibber current hour sensoren for mine automasjoner. Siden jeg har to elbiler og en halvstor enebolig blir det å sikte særlig lavere enn 15 litt utopisk. Men kanskje nå på den varme årstiden. Jeg tester å sette target til 10 nå, og så har jeg satt opp noen regler for dynamisk å øke nivået om det brytes fordi mine begrensninger av en eller annen grunn ikke gjør susen. Så får vi se når vi kommer dit hvor vi må prioritere mer på oppvarming i vinter. Akkurat nå er en god tid til å teste litt.

Basert på det jeg leser her: https://www.elvia.no/nettleie/alt-om-nettleiepriser/priser-ny-nettleiemodell/ så er regelen: "gjennomsnittet av de tre timene i måneden du bruker mest strøm (fordelt på tre ulike dager) utgjør hvilket fastleddstrinn du havner på" Så kanskje disse 3 sensorene er hver av disse dagenes maks, løsningen kan derfor være å ta en gjennomsnitt av disse tre. Så da blir det en hjelper for å ta snittet av disse. Følger med i august så ser vi om dette blir rett.

Tror jeg fant en "bakvei" til mål på dette. Lastet inn ha-elvia via HACS (den offisielle Elvia integrasjonen fant jeg ikke noe doc på, klarte ikke finne ut hvor den lagrer dataene ...). En kar på github har laget en "fixed" versjon som fungerer: https://github.com/andreabl/ha-elvia La inn denne integrasjonen. Token fra "min side" og API key fra Elvia developer portal, pluss målerpunkt ID og da fikk jeg opp alt dette: Antar jeg riktig at effektleddet kan jeg lese ut fra "max hour 3 current month"? Altså, er den > 10 så er vi på 10-15, er den > 15 så er vi på 15-20. Nå har jeg 16,3 altså derfor jeg er på 15-20 akkurat nå. Noen som vet?

Jeg har fortsatt Tibber (en av de som ikke hoppet av :P) og har Tibber Pulse. Bruker en tilpasset variant av @Kim123 sin smartstyring av lader og effekttrinn (Git: https://github.com/kimmilde/home-assistant) og det ser så langt ut som det fungerer bra. Nå prøver jeg å komme meg bort fra Node-Red og powersaver.no (som forøvrig har vært veldig bra, men jeg prøver å komme meg mer HA "native"). En ting jeg da savner er å finne ut hvilket trinn jeg er på nå. Har jeg gått over 10kW effekttrinnet så er det ingen grunn til å holde seg under resten av denne måneden. Men Tibber APIet ser ikke ut til at det deler denne informasjonen så jeg må i tilfelle manuelt sjekker i Tibber appen. Er det noen som har klart å finne en god måte å lese dette ut på? Jeg har Elvia, kanskje de deler den informasjonen?

Jeg er med! 🙂 Har fått opp mine første 3 Matter / Thread enheter nå. Skal inn med fler i løpet av uken.

Se noen videoer på youtube. Er så mange gode eksempler.

Jeg gjør også dette. Trigger ID er veldig smart og blitt en standard del av verktøykassen min.

Jeg har hatt en Google Nest Hello i mange år, og den virker ganske bra. Har en ringeklokke i gangen (Honeywell) som virker litt dårlig. Tror den ikke er glad i 24V ringetrafo, dette er et eget tema som jeg skal ta tak i senere (bytte ut ringeklokka). Men jeg har prøvd å få en automasjon til å virke i Home Assistant slik at jeg kunne få f.eks. Sonos høyttalerene på kjøkkenet, badet, soverommet til ungene osv til å si ifra at det ringer på døra. Dessverre har event baserte automasjoner vært alt for trege. Det gikk 10 sekunder fra noen ringte til noe varsel kom, gjerne mer. Men nå har jeg funnet en løsning. Lag en hjelper i Home Assistant under Innstillinger -> Enheter og Tjenester -> Hjelpere Klikk på "Opprett hjelper", type veksle/toggle. Jeg kalte min "Ringeklokke". Eksponer denne til Google Assistant ved hjelp av å klikke på "Taleassistenter". Nå skal du få denne opp i "Home" appen på telefonen din (altså Google Home appen, den du styrer f.eks. Chromecaster med). Gå inn i den appen og lag en automasjon. Den skal trigge når noen trykker på Nest ringeklokka, og aksjonen er at den skal slå "Ringeklokke" veksleren "på". Så Google får ansvaret å ta "ringeknappen trykket på" og gi beskjed til HA ved hjelp av hjelperen Ringeklokke. Håper det gav mening. Selve vekslingen av Ringeklokke gjør du ved å trykke på Action, og velge "Try adding your own" nederst. Siden Google "snakker norsk" hos meg måtte jeg skrive "Skru Ringeklokke på". Det fungerer. Kanskje du må skrive det på engelsk? Når jeg prøvde på engelsk fikk jeg en melding på mobilen når jeg trykket på ringeklokka at du må sjekke denne automasjonen, den fungerer ikke som den skal. Meldingen var "jeg skjønner ikke handlingen" eller noe slikt. Når jeg skrev det på norsk fungerte det tvert. Nå har du fått beskjed til HA om at noen har ringt på døra. Jeg ønsker en "ding-dong" lyd først på mitt varsel, så jeg gjorde følgende: Last ned en ringeklokke lydfil, jeg tok denne: https://freesound.org/people/kwahmah_02/sounds/319041/ Lagre den på Home Assistant i mappen: /config/www (Bruk Studio Code eller noe slikt for å laste opp). Jeg døpte om fila til "doorbell.wav" Varsle med høyttalere. Jeg har Sonos i mange rom så jeg bruker de til formålet. Man kan sikkert bruke andre også. Sjekk om TTS og Announce virker likt på din høyttaler, det gjør den kanskje ikke. Automasjonen min ser slik ut: alias: Ringeklokka Ringer description: Gi beskjed på høyttalere at det ringer på døra trigger: - platform: state entity_id: - input_boolean.ringeklokke to: "on" condition: [] action: - service: input_boolean.turn_off target: entity_id: input_boolean.ringeklokke data: {} - service: media_player.play_media data: media_content_id: http://x.x.x.x:8123/local/doorbell.wav media_content_type: music announce: true extra: volume: 40 target: entity_id: media_player.kjokken - delay: hours: 0 minutes: 0 seconds: 2 milliseconds: 0 - service: media_player.play_media data: media_content_id: media-source://tts/google_translate?message="Det ringer på inngangsdøra"&language=no media_content_type: music announce: true extra: volume: 40 target: entity_id: media_player.kjokken mode: single Her fra den visuelle editoren: Kort fortalt så trigger den på at hjelperen blir slått på (av Google Assistant), så skrur den hjelperen av (så den er klar til neste gang noen ringer på), så kjører den en "ding-dong" med volum 40%. Den kjøres som "announce" som betyr at den spilles over hva enn som spilles på høyttaleren i øyeblikket (om noe). Vent 2 sekunder og så send meldingen med TTS "Det ringer på inngangsdøren". Uten "vent" automasjonen var det litt lotto om "ding-dong" kom først eller TTS kom først. Etter meldingen er ferdig fortsetter eventuell musikk å spille. Det går også å gjøre TTS tts.speak eller tts.cloud_say i automasjonen, men det fungerer ikke sammen med announce. Fordelen med announce er at den legger seg over det som spilles og den avbryter ikke det som spilles på høyttalerene i utgangspunktet. Du må nesten sjekke litt med dine innstillinger/mediaspillere hva som virker. Denne måten å gjøre det på kan jeg nå bruke til alle rom. Bad, soverommet til ungene osv. Det er ofte noen kommer på døra her uten at noen får det med seg så dette vil hjelpe veldig. Tidligere gikk ikke dette fordi Google Nest event automasjonen bare ble alt for treg. Honorable mention, selve idéen om denne løsningen kom fra denne luringen: https://github.com/home-assistant/core/issues/87234#issuecomment-1772854149

Pi 5 er veldig mye raskere enn Pi 4. Den kan kjøre 4K oppløsning, men YouTube i 4K blir kanskje i meste laget. Se denne videoen:

Ok skjønner. Så da vil faktisk mitt forslag med en enkel liten Raspberry Pi 5 kunne brukes på skjermene dine. Kjør Raspbian på denne og så kan du bruke Chrome / Chromium mot Proxmox og så Spice for å remote VMene. Da vil du få full oppløsning. Slik ville jeg løst det i alle fall 🙂

Ok skjønner. Jeg ville unngått å ha skjermer direkte på proxmox servere og heller kjørt remote administrasjon på alle VMer, dette er jo en uvanlig use-case så det er sikkert ikke så mange som har erfaring med dette oppsettet. Hvorfor må du har 2 fysiske skjermer tilkoblet?