Hva har du automatisert idag/Hva har du gjort på dine prosjekter idag

[DeVille]

stigvi skrev (1 time siden):

en rekke med ikoner som viser status.

 

Stilig. Hvilket kort bruker du til dette? 

 

[RVM]

I dag er den Store Dagen, så i morges lagde jeg noen funksjoner for å følge med på snittet av de tre timene med høyest strømforbruk i inneværende måned:

 

@state_trigger('sensor.accumulated_consumption_current_hour < sensor.accumulated_consumption_current_hour.old')
def update_last_hour(**kwargs):
    try: pyscript.electricity_consumption_last_hour = float(kwargs['old_value'])
    except ValueError: pass # kwargs['old_value'] = 'unavailable' at HA startup, ignore value

@state_trigger('pyscript.electricity_consumption_last_hour')
def update_daily_peak():
    new = float(pyscript.electricity_consumption_last_hour)
    if new > float(pyscript.electricity_daily_peak):
        pyscript.electricity_daily_peak = new

@time_trigger("cron(@daily)")        
def reset_daily_peak():
    pyscript.electricity_daily_peak = 0.0
    pyscript.electricity_monthly_peak_average.today_used = False
    pyscript.electricity_monthly_peak_average.today_used_value = 0.0
    
@state_trigger('pyscript.electricity_daily_peak')
def update_monthly_peak_avg():
    new = float(pyscript.electricity_daily_peak)
    top_3 = pyscript.electricity_monthly_peak_average.top_3_kwh
    today_used = pyscript.electricity_monthly_peak_average.today_used
    today_used_value = pyscript.electricity_monthly_peak_average.today_used_value
    
    if new > top_3[-1]:
        if not today_used:
            top_3[-1] = new    
        else:	# Update todays value
            top_3[top_3.index(today_used_value)] = new
        
        top_3.sort(reverse=True)
        pyscript.electricity_monthly_peak_average.top_3_kwh = top_3
        pyscript.electricity_monthly_peak_average.today_used_value = new
        pyscript.electricity_monthly_peak_average.today_used = True  
    
    top_3_avg = sum(top_3)/count_nonzero(top_3)     # Beware of div0, consider try/except
    pyscript.electricity_monthly_peak_average = round(top_3_avg , 3)

@time_trigger("cron(@monthly)")
def reset_monthly_peak_avg():
    pyscript.electricity_monthly_peak_average = 0.0
    pyscript.electricity_monthly_peak_average.top_3_kwh = [0.0, 0.0, 0.0]

 

Gjenstår å se hvor den evt. feiler, men som et tips til alle som bruker Pyscript kan det anbefales å sette opp varsling for alle system_log_event med level: error fra Pyscript.

Endret 4. juli 2022 av RVM
Oppdatert kode med sjekk for dagens peak. 04/07: La inn try/except i update_last_hour. Glemte også å nevne at jeg bruker state.persist på alle pyscript-entities

[stigvi]

DeVille skrev (På 28.6.2022 den 15.24):

Stilig. Hvilket kort bruker du til dette?

Paper Buttons Row

RVM skrev (33 minutter siden):

Gjenstår å se hvor den evt. feiler

En "feil" er at du ikke tar hensyn til at de tre timene skal være i tre forskjellige døgn.

[RVM]

stigvi skrev (7 minutter siden):

En "feil" er at du ikke tar hensyn til at de tre timene skal være i tre forskjellige døgn.

 

Se det ja, du hadde lest litt nøyere enn meg, jeg tok det bare fra husken Men det er en kjapp fiks heldigvis.

[stigvi]

RVM skrev (11 minutter siden):

Men det er en kjapp fiks heldigvis.

Er det? Dine skript var korte og du må gjerne vise fram hvis du fortsatt klarer å holde de korte.

RVM skrev (11 minutter siden):

 

Se det ja, du hadde lest litt nøyere enn meg, jeg tok det bare fra husken Men det er en kjapp fiks heldigvis.

I tillegg sliter jeg litt med å forstå den første funksjonen. Hva om accumulated_consumption_current_hour er økende på slutten av timen? Da får du ikke oppdatert electricity_consumption_last_hour
Edit: Glem det. Jeg ser det nå........ Jeg overså at dette var en akkumulert verdi.

Endret 1. juli 2022 av stigvi

[RVM]

stigvi skrev (1 time siden):

Er det? Dine skript var korte og du må gjerne vise fram hvis du fortsatt klarer å holde de korte.

 

Tja, alt er relativt. Dette er jo bare enkel aritmetikk og tunga-beint-i-munnen-holding, ikke akkurat differensiallikninger, transformer eller matriser.

 

Prioriterer å holde skriptene lettleste heller enn korte, men min umiddelbare tanke var å mellomlagre last hour i en daily peak, og så mate daily peak inn i monthly average hvis verdien er større enn top_3[-1]. Kan oppdatere posten over når jeg har korrigert og testet scriptet.

 

Ang. accumulated_consumption_current_hour, så er den (hos meg) monotont økende fra Tibber Pulsen til den slår over til 0 ved timeskift. Hvis ny verdi er lavere enn forrige verdi har den altså begynt på en ny time. Men det er klart, det vil feile når det er nettverks- eller skytrøbbel, så jeg søker egentlig bort fra å være avhengig av Tibber.

 

Edit: Fikk oppdatert skriptet i lunsjen, men har bare testa det med noen dummy-verdier. Oppdaterer etterhvert som jeg finner feil de kommende dagene. Om det var en "kjapp fiks" eller "kort" er jo subjektivt, så mulig @stigvi vurderer det annerledes

Endret 1. juli 2022 av RVM

[gullfrode]

RVM skrev (På 1.7.2022 den 9.12):

I dag er den Store Dagen, så i morges lagde jeg noen funksjoner for å følge med på snittet av de tre timene med høyest strømforbruk i inneværende måned:

 

@state_trigger('sensor.accumulated_consumption_current_hour < sensor.accumulated_consumption_current_hour.old')
def update_last_hour(**kwargs):
    try: pyscript.electricity_consumption_last_hour = float(kwargs['old_value'])
    except ValueError: pass # kwargs['old_value'] = 'unavailable' at HA startup, ignore value

@state_trigger('pyscript.electricity_consumption_last_hour')
def update_daily_peak():
    new = float(pyscript.electricity_consumption_last_hour)
    if new > float(pyscript.electricity_daily_peak):
        pyscript.electricity_daily_peak = new

@time_trigger("cron(@daily)")        
def reset_daily_peak():
    pyscript.electricity_daily_peak = 0.0
    pyscript.electricity_monthly_peak_average.today_used = False
    pyscript.electricity_monthly_peak_average.today_used_value = 0.0
    
@state_trigger('pyscript.electricity_daily_peak')
def update_monthly_peak_avg():
    new = float(pyscript.electricity_daily_peak)
    top_3 = pyscript.electricity_monthly_peak_average.top_3_kwh
    today_used = pyscript.electricity_monthly_peak_average.today_used
    today_used_value = pyscript.electricity_monthly_peak_average.today_used_value
    
    if new > top_3[-1]:
        if not today_used:
            top_3[-1] = new    
        else:	# Update todays value
            top_3[top_3.index(today_used_value)] = new
        
        top_3.sort(reverse=True)
        pyscript.electricity_monthly_peak_average.top_3_kwh = top_3
        pyscript.electricity_monthly_peak_average.today_used_value = new
        pyscript.electricity_monthly_peak_average.today_used = True  
    
    top_3_avg = sum(top_3)/count_nonzero(top_3)     # Beware of div0, consider try/except
    pyscript.electricity_monthly_peak_average = round(top_3_avg , 3)

@time_trigger("cron(@monthly)")
def reset_monthly_peak_avg():
    pyscript.electricity_monthly_peak_average = 0.0
    pyscript.electricity_monthly_peak_average.top_3_kwh = [0.0, 0.0, 0.0]

 

Gjenstår å se hvor den evt. feiler, men som et tips til alle som bruker Pyscript kan det anbefales å sette opp varsling for alle system_log_event med level: error fra Pyscript.

I latskapens navn, hvordan implementere dette?

Har lagt til pyscripts via HACS og lagt til i integrasjoner, er det bare å legge til hele scriptet i /pyscript som feks. tibber.py, eller er det mer komplekst?

[RVM]

gullfrode skrev (50 minutter siden):

I latskapens navn, hvordan implementere dette?

Har lagt til pyscripts via HACS og lagt til i integrasjoner, er det bare å legge til hele scriptet i /pyscript som feks. tibber.py, eller er det mer komplekst?

I prinsippet skal det ikke mer til, med noen forbehold. Sjekk aller først at du har satt opp konfigurasjonen iht. dokumentasjonen: https://hacs-pyscript.readthedocs.io/en/latest/reference.html

 

Jeg har brukt funksjonen count_nonzero fra numpy siden jeg uansett har numpy i requirements.txt (ref. dokumentasjon), så den linja kan du enten skrive om eller legge til numpy i requirements og deretter importere i .py-fila di:

 

from numpy import count_nonzero

 

Bruker også state.persist for alle pyscript-variabler så de ikke forsvinner ved neste reboot:

state.persist('pyscript.electricity_monthly_peak_average')
state.persist('pyscript.electricity_consumption_last_hour')
state.persist('pyscript.electricity_daily_peak')

 

Disse entitiene (med sine attributer, hvis de leses før de skrives) må deklareres først en-eller-annen plass, jeg gjør det typisk i Jupyter mens jeg skriver koden. Du kan gjøre det i scriptet ved første gjennomkjøring, og evt. fjerne det etterpå. Vil likevel anbefale å sette opp Jupyter mot Pyscript, det gjør det mye lettere å feilsøke og skrive ny kode.

 

Både import og state.persist må kjøre før resten av scriptet, enten bare i toppen i .py-fila eller i en startup-funksjon med @time_trigger som decorator.

 

Edit: Scriptet har fungert bra til nå, har sjekka at alle verdiene stemmer:

Endret 6. juli 2022 av RVM

[stigvi]

gullfrode skrev (38 minutter siden):

I latskapens navn, hvordan implementere dette?

Har lagt til pyscripts via HACS og lagt til i integrasjoner, er det bare å legge til hele scriptet i /pyscript som feks. tibber.py, eller er det mer komplekst?

Jeg har denne katalogstrukturen for skript

[RVM]

stigvi skrev (13 minutter siden):

Jeg har denne katalogstrukturen for skript

Dette kan vi kanskje ta i en annen tråd, men del gjerne hvis du også har noe vi andre kan bruke i /pyscript/modules/ og /apps/ også

[Kim123]

Hadde ikke fått med meg at effektleddet var gjennomsnitt av de 3 høyeste den måneden, så i dag var det unnagjort. 

 

stigvi skrev (På 1.7.2022 den 9.43):

Paper Buttons Row

En "feil" er at du ikke tar hensyn til at de tre timene skal være i tre forskjellige døgn.

Hvor står det? På bkk.no sine sider (vestlandet) står det

Sitat

Kapasitetsleddet er et fast beløp per måned etter hvor mye strøm du bruker samtidig. Gjennomsnittet av de tre timene i måneden med høyest strømbruk legges til grunn. Det er viktig å merke seg at det er gjennomsnitt i disse tre timene som gjelder. Kortvarig bruk av effektkrevende utstyr har derfor ikke stor betydning, om det ikke skjer samtidig med mye annet strømforbruk. For eksempel vil bruk av et apparat som bruker 12 kilowatt i 10 minutter måles som en timesverdi på 2 kilowatt.

 

[stigvi]

Kim123 skrev (7 timer siden):

Hvor står det? På bkk.no sine sider (vestlandet) står det

Ja, hvor står det? Det var dette de store netteiere sammen med huseierforening osv ble enige om og mange netteiere har fått det med seg i sine avtaler. Men om det står i forskriften at det skal være slik, det finner jeg ikke.

[RVM]

Kim123 skrev (8 timer siden):

Hadde ikke fått med meg at effektleddet var gjennomsnitt av de 3 høyeste den måneden, så i dag var det unnagjort. 

 

Hvor står det? På bkk.no sine sider (vestlandet) står det

 

Hm, men det står også:

Sitat

For beregning av kapasitetsleddet er det laget en trappetrinnmodell. Gjennomsnittet av de tre timene med høyest forbruk, på tre ulike dager i forrige måned, vil avgjøre hva slags trinn du havner i

Link: https://bkk.no/artikkel/b6e3df43-e183-41bd-8f43-88701cfd99e4

 

[ArnieO]

Jet tipper det er upresishet i teksten. Kanskje noen tilknyttet BKK Nett kan kontakte de for å få oppklart?

[Kim123]

Fått bekreftet at dere har rett. Gjennomsnitt tre timer på tre forskjellige døgn

[ArnieO]

37 minutes ago, Kim123 said:

Fått bekreftet at dere har rett. Gjennomsnitt tre timer på tre forskjellige døgn

"Fantastisk".

Dette lukter/stinker av en kompromissløsning hvor det har vært viktigere å komme til en enighet enn at resultatet er noenlunde forståelig, kommuniserbart - og kan føre til endret bruksmønster hos forbruker (som jo er målet).

Det er meg en gåte hvordan noen tror dette skal kunne bidra til å jevne ut effektbelastningen - annet enn aldeles marginalt (de få av oss som klarer / gidder å forsøke å styre forbruket på dette).

 

Eneste farbare vei jeg kan se er å skru av store laster (varmekabler etc) dersom målingene underveis i et timeintervall viser at man ligger an til å passere nettselskapets terskelverdi (som heller ikke er standardisert, ulike nettselskap har ulike terskler). Dersom man ved et uhell likevel skulle passere terskelverdien er det jo bare å glemme den for inneværende døgn (fordi det er kun èn "overskridelse" per døgn som teller). Og skulle man bikke over tre ganger i en måned (tydeligvis da i tre separate døgn) så kan man glemme terskelen resten av måneden; ingen grunn til å være forsiktig lengre da - men kun kjøre strengt etter laveste timepris.

 

Og dette skal liksom "tante Olga" klare å henge med på... jeg vet ikke om jeg skal le eller gråte!

[mroek]

ArnieO skrev (28 minutter siden):

"Fantastisk".

Dette lukter/stinker av en kompromissløsning hvor det har vært viktigere å komme til en enighet enn at resultatet er noenlunde forståelig, kommuniserbart - og kan føre til endret bruksmønster hos forbruker (som jo er målet).

Det er meg en gåte hvordan noen tror dette skal kunne bidra til å jevne ut effektbelastningen - annet enn aldeles marginalt (de få av oss som klarer / gidder å forsøke å styre forbruket på dette).

 

Eneste farbare vei jeg kan se er å skru av store laster (varmekabler etc) dersom målingene underveis i et timeintervall viser at man ligger an til å passere nettselskapets terskelverdi (som heller ikke er standardisert, ulike nettselskap har ulike terskler). Dersom man ved et uhell likevel skulle passere terskelverdien er det jo bare å glemme den for inneværende døgn (fordi det er kun èn "overskridelse" per døgn som teller). Og skulle man bikke over tre ganger i en måned (tydeligvis da i tre separate døgn) så kan man glemme terskelen resten av måneden; ingen grunn til å være forsiktig lengre da - men kun kjøre strengt etter laveste timepris.

 

Og dette skal liksom "tante Olga" klare å henge med på... jeg vet ikke om jeg skal le eller gråte!

 

Ja, det er klart det er en kompromissløsning, og det er helt korrekt som du sier at det kun er de mest ihuga som faktisk vil kunne ta praktiske hensyn via laststyring. Men så er det den psykologiske effekten, da. Det er jo tenkbart at siden folk flest nå vet at det er innført en ny nettleiemodell hvor det kan være smart å unngå høye effekttopper, så vil de mer eller mindre ubevisst passe på å fordele forbruket som best de kan (f.eks ikke kjøre tørketrommel/vaskemaskin/oppvaskmaskin/stekeovn etc.. samtidig), eller rett og slett bare prøve å spare mest mulig strøm.

 

Slik sett kan den nye modellen altså få en effekt (pun intended) selv om det for folk flest er vanskelig å styre forbruket godt nok.

 

En mer korrekt modell ville ha vært å ha timesoppløsning på effektavgiften. Den kunne vært helt flytende (altså fulgt en passende kurve, lineær eller eksponentiell), eller man kunne beholdt dagens trappetrinnsmodell om man absolutt vil det.

 

 

[ArnieO]

Men er det virkelig hensiktsmessig med to parallelle insentiver? Det er bare få år siden (takket være smarte strømmålere) det ble innført timesavregning, dvs prisen endrer seg for hvert timesintervall. Noe av hensikten med dette var at prisdifferensieringen (dyrere strøm når mange vil forbruke) skulle bidra til lastutjevning.

 

Med en egnet smart dings på strømmåleren kan du få god oversikt over hva strømmen vil koste neste døgn, og dette er noenlunde greit å styre laster etter - om man er utstyrt for det. Selv "tante Olga" klarer å lese av grafen som viser når prisene er høyest kommende døgn - og forsøke å tilpasse seg.

Paradoksalt nok er det da det andre ytterpunktet som er problematisk. I Midt- og Nord-Norge er strømmen nå nesten gratis - og prisdifferensieringen er helt uinteressant. Vi har for tiden spotpris under 2 øre, og ingen gidder anstrenge seg for å styre lasten etter det. Men når strømmen er gratis tror jeg uansett ikke det vil endre noen adferd å ilegge disse effektgebyrene.

[stigvi]

ArnieO skrev (1 time siden):

Det er meg en gåte hvordan noen tror dette skal kunne bidra til å jevne ut effektbelastningen - annet enn aldeles marginalt (de få av oss som klarer / gidder å forsøke å styre forbruket på dette).

En kollega av meg hadde et frustrert øyeblikk i lunsjen og kunne fortelle at han sitter ikke med mobilen i fanget hele ettermiddag og kveld og sjekker Tibber-appen om han går over 6kWt/t. Men hittil har han hatt flaks og klart å holde seg under. Helt til jeg fortalte at grensen er 5kWt/t. Den beste fryd er skadefryd, er det noe som heter 🙂

[stigvi]

Jeg har en garasjeportåpner som styres opp og ned med en enkel knapp. Dvs at den veksler mellom å gå opp og ned når en trykker. Dette har skapt litt utfordringer i visningen i Home Assistant. Jeg styrer porten ved hjelp av en "cover" i EspHome. Dette har vært en tidsbasert og der "assumed state" er satt til true. Det har gått fint å styre porten opp og ned, men noen ganger (ofte) så har visningen av portens status vært ute av synk med virkligheten. Jeg har en IKEA zigbee knapp i gangen som jeg åpner porten med om morgenen og så bruker jeg garasjeportens fjernkontroll i bilen for å stenge. HA får dermed vite at porten åpnes, men den vet ikke at porten er stengt.

Nå med siste versjon av EspHome er det endelig løst. Der er det kommet en ny "cover" som baseres på "feedback". Da kan en lett integrere en aqara dørsensor som trigger når porten er stengt og/eller er åpen. Cover integrasjonen i EspHome sørger da for å synkronisere status med virkligheten. Ikke fryktelig viktig, dette har fungert i to år uten dette. Men nå blir det litt enklere å løfte porten opp på gløtt med en skyvebryter i HA når en vet at utgangspunktet alltid er riktig.

 

cover:
  - platform: feedback
    name: "Garasjeport"
    id: garasjeport
    has_built_in_endstop: true
    assumed_state: false
    direction_change_wait_time: 5s
    #icon: "mdi:garage-open-variant"

    open_action:
      - if:
          condition:
            lambda: 'return (id(state_nodstopp) == false);'
          then:
            - switch.turn_on: gararasjeport_opp
            - delay: 0.5s
            - switch.turn_off: gararasjeport_opp
    open_duration: 15s

    close_action:
      - if:
          condition:
            lambda: 'return (id(state_nodstopp) == false);'
          then:
            - switch.turn_on: gararasjeport_opp
            - delay: 0.5s
            - switch.turn_off: gararasjeport_opp
    close_duration: 18s
    close_endstop: portstatus

    stop_action:
      - if:
          condition:
            lambda: 'return id(state_nodstopp) == false;'
          then:
            - switch.turn_on: gararasjeport_stopp
            - delay: 0.5s
            - switch.turn_off: gararasjeport_stopp

 

Endret 23. august 2022 av stigvi

[RVM]

stigvi skrev (16 minutter siden):

Nå med siste versjon av EspHome er det endelig løst. Der er det kommet en ny "cover" som baseres på "feedback". Da kan en lett integrere en aqara dørsensor som trigger når porten er stengt og/eller er åpen.

 

Det fungerer sikkert supert, men du kunne vel kanskje gjort det med en template cover direkte i Home Assistant tidligere også?

 

Hos meg er det konfigurert sånn i HA, da er det value_template som gir feedback basert på et 24-volts signal fra portåpneren (en "Tür Auf Meldung" som Tormatic kaller det) til min ESPHome:

cover:
  - platform: template
    covers:
      garage_door:
        device_class: garage
        friendly_name: "Garage door"
        value_template: "{{ is_state('binary_sensor.garage_door', 'on')}}"
        open_cover:
          service: script.garage_open_door
        close_cover:
          service: script.garage_close_door

 

[stigvi]

RVM skrev (2 minutter siden):

 

Det fungerer sikkert supert, men du kunne vel kanskje gjort det med en template cover direkte i Home Assistant tidligere også?

 

Hos meg er det konfigurert sånn i HA, da er det value_template som gir feedback basert på et 24-volts signal fra portåpneren (en "Tür Auf Meldung" som Tormatic kaller det) til min ESPHome:

cover:
  - platform: template
    covers:
      garage_door:
        device_class: garage
        friendly_name: "Garage door"
        value_template: "{{ is_state('binary_sensor.garage_door', 'on')}}"
        open_cover:
          service: script.garage_open_door
        close_cover:
          service: script.garage_close_door

 

Jeg hadde mange forsøk på dette både med timebased og template, men fikk det ikke til å oppdatere cover samtidig som jeg ville ha en tidsbasert cover. Pga pakkelevering så vil jeg gjerne ha muligheten til å løfte porten 20-30cm og det er lett å få til med tidsbasert cover.

Men feedback cover ser ut til å fungere glimrende.

[stigvi]

Jeg hadde en portåpner jeg var ganske fornøyd med. Den hadde tre innganger for å styre den, opp, ned og stopp. Den kunne jo da lett styres i fra HA selv om HA ikke helt viste status på den. 

Men så tok den kvelden, jeg reklamerte og fikk ny. Men en litt annen modell som bare har to innganger, en for stopp og opp/ned. Dette så jeg ikke før montør var reist.

Og her kommer det merkelige. Forhandleren i Rogaland gikk konk og importør sendte en montør fra østlandet for å bytte ut min i Rogaland. De har definitivt gått med et solid underskudd på det salget 🙂 Jeg synes jo litt synd på de så jeg unnlot å surmule pga litt annerledes tilkobling. Men når jeg trigger releet så vet HA altså ikke om porten går opp eller ned. Det begrenser styringen av den, men nå som jeg får synkronisert status er det i alle fall blitt mye bedre enn det var.

[RVM]

Ja, min har også bare en toggle for opp/ned, så jeg berga opprinnelig en Pepperl+Fuchs proximity switch fra søpla på jobb for å få feedback. Ble veldig letta da jeg så i manualen til portåpneren at det var mulig å konfigurere et TAM-signal.

[SveinHa]

NUCen som kjører ESXI med både Node-Red, Mosquitto, restene av HomeSeer, Pi-Hole og slikt har utviklet en stygg lyd i viften og har gått i stopp et par ganger. Ekstern vifte ser ut til å løse problemet men Intel vil ha den innsendt for å skifte selv om jeg lett kunne gjort det selv. Så da har en del tid gått med for å flytte nøkkelfunksjonenene fra eksisterende virtuelle maskiner på NUC/ESXI til en RPi 4. Går jo litt tid men det var egentlig en grei operasjon. Alt forberedt og testet så kjører jeg i gang på torsdag...