stigvi

24. januar

Håvardgj skrev (11 timer siden):

Fikk endelig renovasjonen inn i Home Assistant til å se ut slik jeg ville:

reinstallerte "minrenovasjon" (https://github.com/eyesoft/home_assistant_min_renovasjon) etter at den sluttet å fungere etter en oppdatering. Satte opp template for å få endret fra å vise dato, til å vise gjenværende dager.

så nå blir det enklere å se når søppeldunken må trilles ned til veien

kode:

Skjul innhold

Jeg er ikke veldig flink med template-funksjonen, så det er ikke sikkert dette er den mest optimale løsningen, men det ser ut til å fungere

type: vertical-stack
cards:
  - type: custom:mushroom-title-card
    title: Renovasjon
    alignment: center
  - type: horizontal-stack
    cards:
      - type: custom:mushroom-template-card
        primary: Restavfall
        secondary: >-
          {% set days_left = (strptime(states('sensor.restavfall'), '%d/%m/%Y',
          today_at()) | as_local - today_at()).days %}

          {% if days_left >= 2 -%}

          Om {{ days_left }} dager

          {% elif days_left == 1 %}

          I morgen

          {% elif days_left == 0 %}

          I dag!

          {% else %}

          Ukjent

          {%- endif %}
        icon: mdi:trash-can-outline
        multiline_secondary: true
        icon_color: grey
        fill_container: true
        entity: sensor.restavfall
        badge_icon: >-
          {% set days_left = (strptime(states('sensor.plast'), '%d/%m/%Y',
          today_at()) | as_local - today_at()).days %}

          {% if days_left == 1 %} 

          mdi:exclamation

          {%- endif %}
        badge_color: red
      - type: custom:mushroom-template-card
        primary: Plastavfall
        secondary: >-
          {% set days_left = (strptime(states('sensor.plast'), '%d/%m/%Y',
          today_at()) | as_local - today_at()).days %}

          {% if days_left >= 2 -%}

          Om {{ days_left }} dager

          {% elif days_left == 1 %}

          I morgen

          {% elif days_left == 0 %}

          I dag!

          {% else %}

          Ukjent

          {%- endif %}
        icon: mdi:spray-bottle
        multiline_secondary: true
        icon_color: purple
        fill_container: true
        entity: sensor.plast
        badge_icon: >-
          {% set days_left = (strptime(states('sensor.plast'), '%d/%m/%Y',
          today_at()) | as_local - today_at()).days %}

          {% if days_left == 1 %} 

          mdi:exclamation

          {%- endif %}
        badge_color: red
  - type: horizontal-stack
    cards:
      - type: custom:mushroom-template-card
        primary: Glass/Metall
        secondary: >-
          {% set days_left = (strptime(states('sensor.glass_metallemballasje'),
          '%d/%m/%Y', today_at()) | as_local - today_at()).days %}

          {% if days_left >= 2 -%}

          Om {{ days_left }} dager

          {% elif days_left == 1 %}

          I morgen

          {% elif days_left == 0 %}

          I dag!

          {% else %}

          Ukjent

          {%- endif %}
        icon: mdi:bottle-wine
        multiline_secondary: true
        icon_color: orange
        fill_container: true
        entity: sensor.glass_metallemballasje
        picture: ''
        badge_icon: >-
          {% set days_left = (strptime(states('sensor.plast'), '%d/%m/%Y',
          today_at()) | as_local - today_at()).days %}

          {% if days_left == 1 %} 

          mdi:exclamation

          {%- endif %}
        badge_color: red
      - type: custom:mushroom-template-card
        primary: Bioavfall
        secondary: >-
          {% set days_left = (strptime(states('sensor.matavfall'), '%d/%m/%Y',
          today_at()) | as_local - today_at()).days %}

          {% if days_left >= 2 -%}

          Om {{ days_left }} dager

          {% elif days_left == 1 %}

          I morgen

          {% elif days_left == 0 %}

          I dag!

          {% else %}

          Ukjent

          {%- endif %}
        icon: mdi:food-apple-outline
        multiline_secondary: true
        icon_color: green
        fill_container: true
        entity: sensor.matavfall
        badge_icon: >-
          {% set days_left = (strptime(states('sensor.plast'), '%d/%m/%Y',
          today_at()) | as_local - today_at()).days %}

          {% if days_left == 1 %} 

          mdi:exclamation

          {%- endif %}
        badge_color: red
  - type: horizontal-stack
    cards:
      - type: custom:mushroom-template-card
        primary: Papir
        secondary: >-
          {% set days_left = (strptime(states('sensor.papir'), '%d/%m/%Y',
          today_at()) | as_local - today_at()).days %}

          {% if days_left >= 2 -%}

          Om {{ days_left }} dager

          {% elif days_left == 1 %}

          I morgen

          {% elif days_left == 0 %}

          I dag!

          {% else %}

          Ukjent

          {%- endif %}
        icon: mdi:book-open-blank-variant
        multiline_secondary: true
        icon_color: blue
        fill_container: true
        entity: sensor.papir
        badge_icon: >-
          {% set days_left = (strptime(states('sensor.plast'), '%d/%m/%Y',
          today_at()) | as_local - today_at()).days %}

          {% if days_left == 1 %} 

          mdi:exclamation

          {%- endif %}
        badge_color: red

Dette du har gjort her med maler skal i teorien og i praksis ikke være nødvendig. Home Assistant skal vise noe tilsvarende helt på egenhånd.

Her har jeg satt en sensor til

.. og HA viser "Neste uke" i kortet.

Settes dato til sensoren til 20. januar, viser kortet dette:

For at dette skal virke, må sensor ha device_class satt til timestamp og sensor må ha en tilstand som tolkes som en dato og tid med tidssone, altså at den faktisk er en timestamp.

Og i samme åndedrag - hvis en sensor har device_class satt til duration så vil et flyttall vises som timer, minutter og sekunder.
Her er en sensor brukt som har verdien 1,2 og dette vises som 1:12:00

Men du har fått det til å virke slik du vil ha det og det er det viktigste. Min kommentar er bare til info om at det skal være mulig å gjøre dette på en lett måte.

23. januar

Og i visning av priser så setter jeg en "opacity" mindre enn 1 slik at jeg må ha kurvene for Tibber, Nordpool og Entso oppå hverandre for å gi en mørk blåfarge. Da er det lett å se på kurven om pris fra en av de mangler.

23. januar

minim skrev (13 minutter siden):

Det høres bra ut. Da skal jeg prøve å legge over til node red i kveld å se hvordan det ser ut. Jeg jobber med bygg automasjon til dagen og eksperimentering med hjemme automasjon er virkelig noe helt annet. Savner Basic ting som å fritt kunne lage seg bilder og ikke bare "kort" samt mye friere funksjons programmering, men det ser ut som at node red har noe mer av dette enn home assistant. Man kan sikkert gjøre det meste i alt dette med åpen kildekode, men terskelen er såpass høy at jeg har ikke orket å bruke tid på å sette meg inn i det enda.

Sikkert dumt spørsmål, men har den statisk ip eller kan den ha fått tildelt ny ip ved strømstans?

Om du kjører Wireshark på maskinen modbus tcp kjører fra så har Wireshark ferdig filter for modbus tcp så du kan se om trafikk sendes ut og om det kommer noe svar.

Home Assistant har også bilder som en kan legge UI på. Men i utgangspunktet er det "kort" som er den enkle måten å lage det på.
De fleste tror jeg løser dette

Sitat

mye friere funksjons programmering

med å installere pyscript modulen. Da kan en lage rutinene i python. https://hacs-pyscript.readthedocs.io/en/stable/overview.html

Jeg tror nok du går på en liten blemme med å introdusere enda et nytt verktøy i automatiseringen istedenfor å sette seg inn i hvordan modbus konfigureringen virker i HA. Men det er jo bare min mening. Uanz, du får det nok til med node-red også.

23. januar

Jeg endrer stadig på dette og har tatt med mulighet for å hente strømpris fra Tibber. Skriptet velger selv hvor den skal hente prisen i fra, men hvis dette gjøres feil, kan jeg slå av kildene med brytere i UI.

from datetime import datetime,timedelta
import holidays

YEAR = datetime.today().year
NOR_HOLIDAYS = holidays.NO(years=[YEAR, YEAR+1])

state.persist('pyscript.total_pris_for_strom', default_value=0, default_attributes={"unit_of_measurement":"NOK"})
state.persist('pyscript.snittpris_for_strom', default_value=0, default_attributes={"unit_of_measurement":"NOK/kWh"})
state.persist('pyscript.spart_paa_strom', default_value=0, default_attributes={"unit_of_measurement":"NOK"})
state.persist('pyscript.strompris', default_value=0, default_attributes={"unit_of_measurement":"NOK/kWh"})
state.persist('pyscript.totalstrompris', default_value=0, default_attributes={"unit_of_measurement":"NOK/kWh"})
state.persist('pyscript.nettleie', default_value=0, default_attributes={"unit_of_measurement":"NOK/kWh"})
state.persist('pyscript.stromstotte', default_value=0, default_attributes={"unit_of_measurement":"NOK/kWh"})
state.persist('pyscript.spotpris', default_value=0, default_attributes={"unit_of_measurement":"NOK/kWh"})
state.persist('pyscript.gjennomsnittlig_strompris', default_value=0, default_attributes={"unit_of_measurement":"NOK/kWh"})
state.persist('pyscript.peak_strompris', default_value=0, default_attributes={"unit_of_measurement":"NOK/kWh"})
state.persist('pyscript.offpeak_1_strompris', default_value=0, default_attributes={"unit_of_measurement":"NOK/kWh"})
state.persist('pyscript.offpeak_2_strompris', default_value=0, default_attributes={"unit_of_measurement":"NOK/kWh"})
state.persist('pyscript.hoyeste_strompris', default_value=0, default_attributes={"unit_of_measurement":"NOK/kWh"})
state.persist('pyscript.laveste_strompris', default_value=0, default_attributes={"unit_of_measurement":"NOK/kWh"})

@time_trigger("cron(59 * * * *)")
def akkumulere_stromkostnad():
    p = round(float(pyscript.totalstrompris) * float(sensor.estimated_hourly_consumption) + float(pyscript.total_pris_for_strom), 2)
    pyscript.total_pris_for_strom = p

    if float(sensor.consumption_thisday) > 0:
        pyscript.snittpris_for_strom = round(float(pyscript.total_pris_for_strom) / float(sensor.consumption_thisday), 4)
    
    pyscript.spart_paa_strom = round(float(sensor.consumption_thisday) * (float(pyscript.gjennomsnittlig_strompris) - float(pyscript.snittpris_for_strom)), 2)

@time_trigger("cron(0 0 * * *)")
def nullstille_stromkostnad():
    pyscript.total_pris_for_strom = 0

@time_trigger("cron(0 * * * *)")
@state_trigger("input_button.oppdater_strompris")
def strompris():
    #state.set("pyscript.strompris", new_attributes={})
    
    grid_night = float(input_number.nettleie_natt) / 100.0
    grid_day = float(input_number.nettleie_dag) / 100.0
    additional_costs = float(input_number.paslag_strom) / 100.0
    
    entso_valid = False
    if sensor.average_electricity_price_today.prices is not None and len(sensor.average_electricity_price_today.prices) >= 48:
        ld = datetime.strptime(sensor.average_electricity_price_today.prices[47]["time"], "%Y-%m-%d %H:%M:%S%z")
        if datetime.now() < ld.replace(tzinfo=None):
            entso_valid = True
    
    if input_boolean.strompriskilde_tibber == 'on' and sensor.energy_price_gabriel_edlands_veg_16.tomorrow_valid == True:
        pyscript.strompris.updatetime = datetime.now().isoformat()
        pyscript.strompris.source = "Tibber"
        l = []

        for sourceprice in sensor.energy_price_gabriel_edlands_veg_16.raw_today + sensor.energy_price_gabriel_edlands_veg_16.raw_tomorrow:
            pr = {}
            d = datetime.strptime(sourceprice["time"], "%Y-%m-%dT%H:%M:%S.000%z")
            pr["start"] = d.isoformat()
            pr["end"] = (d + timedelta(hours=1)).isoformat()
            pr["spotprice"] = round(float(sourceprice["total"]) - float(additional_costs), 4)
            pr["gridprice"] = round(grid_day if is_peak(d) else grid_night, 4)
            pr["payback"] = round(payback(float(pr["spotprice"])), 4)
            pr["totalprice"] = round(float(pr["spotprice"]) + float(pr["gridprice"]) + float(additional_costs) - float(pr["payback"]), 4)
            l.append(pr)

        pyscript.strompris.prices = l
    elif input_boolean.strompriskilde_nordpool == 'on' and sensor.nordpool.tomorrow_valid == True:
        pyscript.strompris.updatetime = datetime.now().isoformat()
        pyscript.strompris.source = "Nordpool"
        l = []

        for sourceprice in sensor.nordpool.raw_today + sensor.nordpool.raw_tomorrow:
            pr = {}
            d = sourceprice["start"]
            pr["start"] = d.isoformat()
            pr["end"] = (d + timedelta(hours=1)).isoformat()
            pr["spotprice"] = round(float(sourceprice["value"]), 4)
            pr["gridprice"] = round(grid_day if is_peak(d) else grid_night, 4)
            pr["payback"] = round(payback(float(pr["spotprice"])), 4)
            pr["totalprice"] = round(float(pr["spotprice"]) + float(pr["gridprice"]) + float(additional_costs) - float(pr["payback"]), 4)
            l.append(pr)

        pyscript.strompris.prices = l
    elif input_boolean.strompriskilde_entsoe == 'on' and entso_valid == True:
        pyscript.strompris.updatetime = datetime.now().isoformat()
        pyscript.strompris.source = "Entso-e"
        l = []
        
        for sourceprice in sensor.average_electricity_price_today.prices:
            pr = {}
            d = datetime.strptime(sourceprice["time"], "%Y-%m-%d %H:%M:%S%z")
            pr["start"] = d.isoformat()
            pr["end"] = (d + timedelta(hours=1)).isoformat()
            pr["spotprice"] = round(float(sourceprice["price"]), 4)
            pr["gridprice"] = round(grid_day if is_peak(d) else grid_night, 4)
            pr["payback"] = round(payback(float(pr["spotprice"])), 4)
            pr["totalprice"] = round(float(pr["spotprice"]) + float(pr["gridprice"]) + float(additional_costs) - float(pr["payback"]), 4)
            l.append(pr)
        
        pyscript.strompris.prices = l
    
    price_sum = 0.0
    peak_sum = 0.0
    offpeak1_sum = 0.0
    offpeak2_sum = 0.0
    high = -1000
    low = 1000

    for sourceprice in pyscript.strompris.prices:
        if datetime.now() >= datetime.fromisoformat(sourceprice["start"]).replace(tzinfo=None) and datetime.now() < datetime.fromisoformat(sourceprice["end"]).replace(tzinfo=None):
            pyscript.strompris = round(float(sourceprice["totalprice"]), 4)
            pyscript.totalstrompris = round(float(sourceprice["totalprice"]), 4)
            pyscript.nettleie = round(float(sourceprice["gridprice"]), 4)
            pyscript.stromstotte = round(float(sourceprice["payback"]), 4)
            pyscript.spotpris = round(float(sourceprice["spotprice"]), 4)
        
        if datetime.now().day == datetime.fromisoformat(sourceprice["start"]).day:
            price_sum += sourceprice["totalprice"]

            if datetime.fromisoformat(sourceprice["start"]).hour < 8:
                offpeak1_sum += sourceprice["totalprice"]
            elif datetime.fromisoformat(sourceprice["start"]).hour < 20:
                peak_sum += sourceprice["totalprice"]
            else:
                offpeak2_sum += sourceprice["totalprice"]
            
            if high < sourceprice["totalprice"]:
                high = sourceprice["totalprice"]
            
            if low > sourceprice["totalprice"]:
                low = sourceprice["totalprice"]
    
    pyscript.gjennomsnittlig_strompris = round(float(price_sum) / 24.0, 4)
    pyscript.peak_strompris = round(float(peak_sum) / 12.0, 4)
    pyscript.offpeak_1_strompris = round(float(offpeak1_sum) / 8.0, 4)
    pyscript.offpeak_2_strompris = round(float(offpeak2_sum) / 4.0, 4)
    pyscript.hoyeste_strompris = round(float(high), 4)
    pyscript.laveste_strompris = round(float(low), 4)

def is_peak(t : datetime):
    if t.isoweekday() >= 6 or t.hour <= 5 or t.hour >= 22 or t.date() in NOR_HOLIDAYS:
        return False
    else:
        return True

def payback(spot : float):
    return max((spot - 0.9125) * 0.9, 0.0)

23. januar

minim skrev (8 timer siden):

Snippet litt fra configen din. da jeg hadde noen spørsmål rundt hvordan du har bygget opp configen. I modbus config dokumentasjonen så viser de et oppsett lignende det jeg har brukt under her. Dette er et Heru S160ec anlegg hvor det meste fungerer, men "climates" ble feil etter at heru ga ut 1.10 firmware som endrer skalering på temperatur innganger (input registers), men ikke utganger (holding reister). Det er et sidespor til spørsmålet, men for å løse dette problemet tenkte jeg å sette opp et enkelt setpunkt som du har gjort med "number", men da ser jeg at du har bygget det opp veldig ulikt min config med "modbus_controller"/platform. Dette med platform og modbus hvor finner jeg dokumentasjon på måten du har løst dette på så jeg får lest litt om dette evnt har du en enkel forklaring på hvordan det henger sammen?

Jeg er rimelig lost i oppsett av home assistant så det er mulig jeg gjør ting helt feil i utgangspunktet her 😛 Configen min er noen år gammel også så mulig noe av det er en utdatert måte å gjøre det på.

Edit: Da fant jeg ut at det var en egen komponent knyttet til ESPn dere bruker så da får jeg gruble videre på min løsning som bruker modbus tcp direkte 🙂

https://esphome.io/components/modbus

modbus:
  - name: hub1
    type: tcp
    host: 10.0.0.11
    port: 502
    sensors:
      - name: Utetemperatur
        unit_of_measurement: °C
        slave: 1
        address: 1
        input_type: input
        unique_id: 400
        scale: 0.1 
        precision: 1
      - name: Tilluftstemperatur
        unit_of_measurement: °C
        slave: 1
        address: 2
        input_type: input 
        unique_id: 401
        scale: 0.1
        precision: 1
      - name: Fraluftstemperatur
        unit_of_measurement: °C
        slave: 1
        address: 3
        input_type: input
        unique_id: 402
        scale: 0.1
        precision: 1 
      - name: Avkasttemperatur 
        unit_of_measurement: °C
        slave: 1
        address: 4
        input_type: input
        unique_id: 403
        scale: 0.1
        precision: 1
      - name: Etter varmegjenvinner
        unit_of_measurement: °C
        slave: 1
        address: 6
        input_type: input
        unique_id: 404
        scale: 0.1
        precision: 1
      - name: Filter tid til skifte
        unit_of_measurement: dager
        slave: 1
        address: 19
        input_type: input
        unique_id: 405
      - name: Tilluftsvifte
        unit_of_measurement: '%'
        slave: 1
        address: 24
        input_type: input
        unique_id: 406 
      - name: Fraluftsvifte
        unit_of_measurement: '%'
        slave: 1
        address: 25
        input_type: input
        unique_id: 407 
      - name: Varmebatteri 
        unit_of_measurement: '%'
        slave: 1
        address: 28
        scale: 0.3921568
        input_type: input
        unique_id: 500        
      - name: Gjenvinner
        unit_of_measurement: '%'
        scale: 0.392156
        slave: 1
        address: 29
        input_type: input
        unique_id: 408
      - name: Setpunkt økonomi
        unit_of_measurement: °C
        slave: 1
        address: 0
        input_type: holding
        unique_id: 409
      - name: Setpunkt comfort
        unit_of_measurement: °C
        slave: 1
        address: 1
        input_type: holding
        unique_id: 410
      - name: heater type
        slave: 1
        address: 65
        input_type: holding
        unique_id: 417
      - name: heater enabled
        slave: 1
        address: 66
        input_type: holding
        unique_id: 418
    switches:
      - name: "Heater"
        slave: 1
        address: 66
        command_on: 1
        command_off: 0
        write_type: holding
        scan_interval: 6
        verify:
            input_type: holding
            address: 66
            state_on: 1
            state_off: 0
      - name: "Boost"
        slave: 1
        address: 2
        command_on: 1
        command_off: 0
        write_type: coil
        scan_interval: 6
        verify:
            input_type: coil
            address: 2
            state_on: 1
            state_off: 0

    climates:
      - name: "Setcomfort"
        address: 2
        input_type: input
        max_temp: 35
        min_temp: 15
        offset: 0
        precision: 1
        scale: 1
        target_temp_register: 1
        temp_step: 1
        temperature_unit: °C
        unique_id: 419

template:
  - sensor:
      - name: "varmebatteri_effekt"
        unit_of_measurement: W
        state: "{{ states('sensor.varmebatteri') | int * 12 }}"
      - name: "virkningsgradtil"
        unit_of_measurement: '%'
        state: "{{ (((states('sensor.etter_varmegjenvinner') | int - states('sensor.utetemperatur') | int ) / (states('sensor.fraluftstemperatur') | int -  states('sensor.utetemperatur') | int )) * 100)|round(1) }}"
      - name: "virkningsgradfra"
        unit_of_measurement: '%'
        state: "{{ (((states('sensor.fraluftstemperatur') | int - states('sensor.avkasttemperatur') | int ) / (states('sensor.fraluftstemperatur') | int -  states('sensor.utetemperatur') | int )) * 100)|round(1) }}"

Ja, som du så er min yaml for esp noden.

21. januar

NilsG skrev (4 timer siden):

og lurte på om problemene ville vært unngått hvis du hadde brukt zigbee

Nei, det tror jeg ikke. Ikea sine lyspærer hadde for noen år siden en bug som gjorde at de ikke videresendte meldinger. Hjemme hos meg førte det til treg respons og ikke respons i det hele tatt. Men samtidig var deconz og conbee II ikke verdens beste så mulig annen programvare som feks zigbee2mqtt hadde fanget det opp bedre.

18. januar

Dette med strømpris siste time var et eksempel og ikke noe jeg bruker selv. Min mal for strømpris siste time ser slik ut:

    - unique_id: be7b58ab-a2da-4f51-b770-9583e1da4cb9
      name: "Energy price last hour"
      unit_of_measurement: "NOK/kWh"
      device_class: monetary
      state: >-
            {% set s = (now()-timedelta(hours=1))|as_timestamp|timestamp_custom('%Y-%m-%dT%H:00:00+01:00') %}
            {{ (state_attr("pyscript.strompris", "prices")|selectattr("start", "eq", s)|list)[0].totalprice }}

Den gjør samme jobben, bortsett fra at den endres på hver hele time istedenfor 1 minutt før. Men den er mer kryptisk og å bruke en mal-trigger istedenfor, viser at det går å lage slikt enkelt. Sannsynligvis er mal-triggere også mer effektive i og med at den evalueres en gang i timen, mens denne som er i dette innlegget evalueres hvert minutt.

18. januar

Et annet eksempel er strømpris for forrige time. Som kjent vil strømmåler i huset sende forbruk noen sekunder etter hver hele time. I "Energi" oppsettet til HA kan en knytte opp en sensor som inneholder strømpris, men dette bør da være pris som var i forrige time og ikke i den gjeldende timen.

template:
  - trigger:
      - platform: time_pattern
        minutes: 59
    sensor:
      - unique_id: be7b58ab-a2da-4f51-b770-9583e1da4cb9
        name: "Energy price last hour"
        unit_of_measurement: "NOK/kWh"
        device_class: monetary
        state: "{{ states('pyscript.totalstrompris')|round(6) }}"

18. januar

Thomas_E skrev (8 minutter siden):

Jeg sendte en mail Amina, og de bekreftet at de jobbet med en offisiell Homey-app. Kunne ikke love noen spesifikk dato, men da ser det ut til at jeg går for den. Tikker de fleste bokser for meg.

Mon tro om de vurderer en offisiell Home Assistant integrasjon. Home Assistant har 314.000 aktive brukere og 12500 av disse bor i Norge og Sverige. Hvor mye har Homey solgt i disse to landene?

17. januar

Det er noe jeg ikke har tenkt så mye over. Men Amina S ser interessant ut. Jeg hadde letet etter en som har lokal styring. Jeg ønsker ikke å være avhengig av en skytjeneste. Det er noe som ser trygt ut der og da, men i et 20 år langt perspektiv har jeg ikke så mye tro på det.

Jeg bruker Home Assistant og har mye utstyr basert på esphome. Så det er mulig jeg hadde sett på en ladeboks som jeg kunne styre via noen enkle releer. Jeg ser at min egen styring av easee boksene begrenser seg til å slå av og på lading for å treffe billige timer og å holde meg under effekttariff-trinn. I tillegg setter jeg ladestrøm to ganger i året til en vinter- og sommerinnstilling.

Jeg henter ut ladeeffekt og ladekostnad fra easee, men dette havner i kategorien "kjekt å ha".

17. januar

Jeg har to easee ladebokser. Er litt skeptisk til å anbefale disse, nettopp pga uavklart situasjon for selskapet. Og så er de styrt via en skytjeneste. Fordelen med det er at de er lette å integrere, men samtidig er det noen problemer innimellom. Det har blitt langt mer stabilt siste årene, så det går rette veien. De har også lagt til lokal styring via mobil i tilfelle easee går dukken. Men da forsvinner nok app også så min plan B er i så fall å reklamere ovenfor forhandler på boksene hvis det skulle gå helt ille.

16. januar

Jeg lader to biler på 1,3kW hver (VW eGolf og VW Passat GTE) og klarer å holde meg under 5kWh/h i 8 av årets måneder. Men om vinteren må jeg opp i 10kWh/h for å kunne lade biler på natt, varme vann på natt og samtidig ha varmt badegolv om morgenen.

15. januar

MrE skrev (2 timer siden):

Z-Water2 kan ikke brukes slik hvis det kobles iht. skjemaet nei.

Det var heller ikke det jeg kommenterte ..........

15. januar

Hvis de ikke tillater forskjellige kabler så bryter de med standarden såpass mye at jeg ikke kan forstå at de får lov å kalle det bil med type 2 kontakt.

15. januar

MrE skrev (12 minutter siden):

Husk at Z-Water2 er for 230V aktuatorer, ikke 24V aktuatorer. Du må sjekke at aktuatorene dine er 230V.

Z-Water kan fint brukes med både 230V, 24V og alle andre typer aktuatorer sålenge spenningen til aktuator er lavere eller lik 230V.

15. januar

For Nobø sin termostat kan en spesifisere disse verdiene:

Gulvsensor (Ekstern temperatursensor) 22kOhm ved 25˚C (standardinnstilling) Andre kompatible gulvsensorverdier: 47kOhm v/25˚C 10kOhm v/25˚C 15kOhm v/25˚C 2kOhm v/25˚C 12kOhm v/25˚C

Og her finnes verdier som ikke lar seg stille inn på Namron. Så det er tydeligvis ingen standard og heller ingen garanti for at eksisterende føler kan brukes. Men normalt er de lette å dra ut så hvorfor ikke bytte den?

15. januar

TBA skrev (57 minutter siden):

I teorien kan en "dum" ladeboks gjøres "smart" ved å lage eget 12V PWM signal, som signaliserer annen fortrinnsvis lavere effekt, eller planlagt start og stopp av lading. Men, en kan ikke lese ut aktuelt ladenivå via PWM signalet.

Et annet alternativ er å bytte ut ledningen til en tynn hvis målet er å redusere ladestrøm. Eventuelt åpne opp støpselet og bytte ut motstand som er der.

15. januar

Thomas_E skrev (20 minutter siden):

Vil gjerne også kunne styre at den stopper lading på X% på Seat-en hvis mulig.

Dette punktet må du løse med muligheter som eventuelt finnes i bilen. Ladestasjonen vet ingenting om batteritilstand.

Jeg har lest at dette kan endre seg i fremtiden, men det gjelder i så fall for nye biler sammen med nye ladestasjoner.

14. januar

Innlegget er ment som et tips eller noe en kan dra nytte av til andre ting.

Når en lager en malsensor, vil denne malen evalueres hver gang en entitet som er brukt i malen, endres. Dette er stort sett ønskelig, men noen ganger er det en hindring. I eksempelet under, beregner jeg oppvarmingstid for VVB og setter en binær sensor til På i de billigste timene og i så mange timer som det er nødvendig å varme vann. Problemet oppstår når temperaturen i vannet øker og da vil beregnet oppvarmingstid synke. Dette lager kluss når en skal plukke de billigste timene. En kan starte å varme vann i den billigste timen, men når en kommer til den nest billigste kan oppvarmingstiden sunket så mye at denne timen utelates. Å varme vannet krever bare en time til og den billigste timen er jo nettopp passert.

Denne problemstillingen kan en omgå ved å bruke en ny funksjonalitet i HA. Så veldig ny er den derimot ikke. Mulig den har eksistert i et par år nå.
Det dreier seg om å skille trigger / evaluering av mal til noe en selv bestemmer. Det kan være tid, tilstand, hendelse eller egentlig hva som helst.
Dokumentasjon for dette, finner en her: https://www.home-assistant.io/docs/automation/trigger/ Triggere for automatisering er prikk lik triggere en kan bruke i maler og dokumentasjonen for disse er lik.

I eksempelet nedenfor, trigger jeg beregning av oppvarmingstid kun i start på hver time og kun hvis VVB er avslått. Så snart en starter på å varme vann, vil ikke ny oppvarmingstid bli beregnet. Unntaket er når en setter ny temperatur en skal varme til, bare for å ta med det og å vise at en kan ha mange triggere.

Etter min mening er dette en svært nyttig egenskap til mal-sensorer som ofte kan forenkle ganske mye.

template:
  - trigger:
      - platform: template
        value_template: "{{ now().minute == 0 and states('sensor.effekt_varmtvann')|float(0) == 0 }}"
      - platform: state
        entity_id:
          - input_number.vvb_temperatur
    sensor:
      - unique_id: vvb_heating_time
        name: "vvb oppvarmingstid"
        unit_of_measurement: 'h'
        device_class: duration
        state: >-
          {{ ((states('input_number.vvb_temperatur')|float(80)
            - average(states('sensor.varmtvannstank_topp_temperatur')|float(60),
              states('sensor.varmtvannstank_senter_temperatur')|float(60),
              states('sensor.varmtvannstank_bunn_temperatur')|float(60)))
            / (iif(float(states('sensor.effektbegrensing')) > 8, 1.0, 2.0) / 194.0 / 0.001163))|round(1) }}

  - binary_sensor:
    - unique_id: billigste_timer_vvb
      name: billigste_timer_vvb
      state: >-
        {% set l=state_attr('pyscript.strompris', 'prices')[14:39]|sort(attribute='totalprice') %}
        {% set t = now().hour %}
        {% set d = now().day %}
        {% set h = states('sensor.vvb_oppvarmingstid')|float(0) %}
        {{ iif(h > 0, (t == as_datetime(l[0].start).hour and d == as_datetime(l[0].start).day), false)
          or iif(h > 1, (t == as_datetime(l[1].start).hour and d == as_datetime(l[1].start).day), false)
          or iif(h > 2, (t == as_datetime(l[2].start).hour and d == as_datetime(l[2].start).day), false)
          or iif(h > 3, (t == as_datetime(l[3].start).hour and d == as_datetime(l[3].start).day), false)
          or iif(h > 4, (t == as_datetime(l[4].start).hour and d == as_datetime(l[4].start).day), false)
          or iif(h > 5, (t == as_datetime(l[5].start).hour and d == as_datetime(l[5].start).day), false)
          or iif(h > 6, (t == as_datetime(l[6].start).hour and d == as_datetime(l[6].start).day), false) }}

12. januar

Hva med fordeler og bakdeler med å samle alle eggene i en kurv?

For meg er det et poeng å spre hjemmeautomasjonen utover på flere "dingser". Og å ha en raspberry pi4 liggende på lager i skuffen, koster heller ikke mye. Å ha en i reserve, klar til å brukes, gir en viss trygghet på at automasjonen ikke er nede i dagevis. Jeg har en Sonoff zigbee koordinator liggende på lur også. Og vitale data fra den som brukes nå, er kopiert slik at den nye kan settes opp som en nøyaktig kopi.

Å samle alt på en server, skaper ikke det problemer med hjemmeautomasjon når denne serveren skal vedlikeholdes?

11. januar

Har drivstoff/bensinapp'en en intent med pris? I så fall kan en jo prøve dette hvis en er på Home Assistant.

https://community.home-assistant.io/t/android-intents-sending-receiving-list-starting-activities-too/276192

Edit: Siste "Varsel" på tlf kan også plukkes opp av HA appen og sendes til HA. Så hvis drivstoff/bensinapp sender varsler på prisendringer, kan det også plukkes opp via appen. Men intents hadde vært kult. Da skulle jeg også vurdert dette........

Edit2: Regner med dette gjelder kun android appen. Iphone brukere er jo forskånet for kule ting som dette..............

10. januar

largie skrev (23 minutter siden):

hvilke styreboks ville dere ha kjøpt i 2024 for dette

Hva er "dette"?

10. januar

En trenger ikke noe som helst "spesielt" for å kjøre backup. Selv den enkleste raspberry pi (som kan kjøre HA) kan kjøre backup til skytjenester automatisk.

PS. Dette er ment som et svar til andre som eventuelt leser tråden. Hardware hindrer definitivt ikke muligheten til å kjøre automatisk backup.

9. januar

SveinHa skrev (4 minutter siden):

En kjenning rapporterte om 20 år gammel Daikin og still going strong... Det er i denne klassen vedr. levetid jeg ville forvente...

Hva er standard vedlikehold på en varmepumpe? Skal en skifte olje etter X antall timer?

8. januar

hflatoey skrev (1 time siden):

Takler nettet all strømmen som blir brukt om vinteren så burde det takle strømmen som blir levert om sommeren også

Som thoralex skriver, netteiere skrur opp spenningen på transformatorer for å kompensere for spenningsfall. Når solceller leverer så får en da ekstra høy spenning etter trafo fordi spenningsfallet blir for lite. Selvsagt kan netteiere redusere spenning. Men jeg tipper det er en manuell jobb som også krever at de må skru av strømmen et lite øyeblikk (med forbehold om uvitenhet)

SveinHa skrev (1 time siden):

Nå vet ikke jeg om der har vært strømrasjonering noen plass enda men det kommer

Nå er det svært lite sannsynlig med rasjonering, men hvis det skulle bli så er det bedrifter som må stenge ned først. Jeg jobbet en stund som innleid konsulent for et smelteverk i Trondheim. De hadde kjøpt strøm til fast lav pris. Når spotprisen ble høy nok, stengte de ned verket og solgte strømmen videre til spotprisen. Dette skjer av seg selv uten at det blir tvungen rasjonering. Når spotprisen blir høy nok, er det masse kraft som blir frigjort til husholdninger og bedrifter som ikke kan stenge ned.

Logg inn

Profiler

Forum

Blogger

Nedlastninger

Artikler

Regler

Hendelser

Galleri

Store

Innlegg skrevet av stigvi

Viktig informasjon