stigvi

En enklere måte er å gjøre som dette (etter inspirasjon fra et annet innlegg i dag) {% set l=state_attr('sensor.average_electricity_price_today', 'prices')[14:38]|sort(attribute='price') %} {% set t = now().hour %} {{ (t == as_datetime(l[1].time).hour) or (t == as_datetime(l[1].time).hour) }}

Forklar heller hva du ønsker som sluttresultat? Er det for å vise i en graf eller søylediagram? Eller er det noe annet du ønsker? Grunnen til at jeg spør, er fordi veien til mål er så forskjellig.

Takk for langt og godt svar. Nei, jeg har definitivt ikke tenkt å bytte 🙂

Jeg kjenner ikke til HomeSeer, men jeg ser stadig påstander om at den er så enkel og rask å sette opp. Dere som er kjent med begge systemer - hvordan er det egentlig? Er HomeSeer et bedre alternativ for de som ikke ønsker å fikle? Er det komplisert å lage automasjoner i Home Assistant i motsetning til tilsvarende i HomeSeer? Home Assistant har et greit system for å gi tilbakemelding på ting som bør forbedres. Og dette tar utviklere også hensyn til. Så innlegg her kan fint ende opp i en konstruktiv tilbakemelding til Home Assistant.

Dette er vel litt 2018, er det ikke? Home Assistant har et brukergrensesnitt som har endret seg dramatisk siste årene.

Den bruker vel regionale innstillinger som er gjort i nettleser?

Du kan jo prøve med å sette tykkelse på sensor.amsleser_houruse på samme måte som du har gjort med rød pris

Den populære mini-graph-card har også en slik "group_by" mulighet. Ganske nyttig, ja 🙂

Fordi jeg som bruker har ingen kontroll på hva dette nettstedet gjør. Du sier jeg kan sjekke kildekode, men jeg kan ikke være 100% sikker på at det er denne koden som kjøres på watty.nu. Men nå setter jeg deg i et dårlig lys. Jeg mistror ikke deg spesielt, men det går litt på slike løsninger på generelt grunnlag. Watty.nu er ikke alene. Nå skriver du at dette er et hobbyprosjekt, men hvis du vil ta det videre og gjøre dette kommersielt, så må en jo forholde seg til et strengere regime pga et lovverk.

Når en oppgir dette på et nettsted som heter watty.nu så er det rimelig spesielt å påstå at en ikke oppgir det til deg. Men greit nok, jeg har ikke så mye bruk for dette uansett. Jeg er kommet litt lenger i hjemmeautomasjonen enn kun å sjekke forbruk på en VVB. Å vise kostnad er forsåvidt interessant nok. Jeg har løst det på en annen måte, derimot.

Så hvis jeg ville brukt dette (noe jeg ikke har noen planer om) så må jeg altså oppgi til deg (watty.nu) både tibber token og shelly token. Tror nok svært mange på dette forumet ville vært veldig skeptisk til det.

Konklusjon: Bruk heller amsToMqttBridge. Maskinvare koster mindre enn 100 kroner. Men tilfredsheten av å lage det selv er vanskelig å verdsette 🙂

Det ser fornuftig ut, men om det er rett, vet jeg ikke. Det er i allefall ikke tidsperiodene du oppga i en tidligere post. 14:16 21:30 33:38 stemmer det?

Nei, for i morgen klokken 14 vil de to timene mellom 14 og 16 flytte seg fram 24 timer i listen. Hvis de har indeks 38 og 39 i dag, så er de på indeks 14 og 15 i morgen etter 1400

Det er enkelt å få til hvis entso-e alltid oppdateres klokken 14. Det er de dagene dette ikke skjer, som blir litt utfordrende. Perioden 0900 til 1600 ville jeg delt opp i to der 1400 var grensen mellom de.

Men vær oppmerksom på at prices listen oppdateres klokken 14 så ditt ønske om billig pris fra 09 til 16 må du tenke mer på. Spørs om det ikke er lurt å dele det opp i to malsensorer...... Eller ha det slik du hadde med å bruke selectattr. Den søker jo opp timene uavhengig av hvor i listen den timen faktisk er og da unngår en problem med at alle prisene forskyves et døgn. Men du må være obs på døgnskifte når du bruker now()

Det er ikke timer som skal inn her, men indeks i listen (elementnummer). Så her må du bruke 21 og 31 Test det ut i Home Assistant sitt mal-verktøy med {{ state_attr('sensor.entsoe', 'prices')[9:16] }} for å se om listen du får, starter og stopper med riktig time. state_attr('sensor.average_electricity_price_today', 'prices')[21:31] + state_attr('sensor.average_electricity_price_today', 'prices')[33:41]

Disse to gjør stort sett det samme {{state_attr('sensor.nordpool', 'raw_today') |selectattr('start', '>=', now().replace(hour=9,minute=0,second=0,microsecond=0)) |selectattr('start', '<', now().replace(hour=16,minute=0,second=0,microsecond=0)) | list }} {{state_attr('sensor.nordpool', 'raw_today')[9:16]}}

Med nordpool integrasjonen kan en ofte oppleve at dagens billigste timer er mellom 23:00 og 0:00 samtidig som prisen fortsetter å falle utover natten. Da er det dumt å varme vannet mellom 23:00 og midnatt. Selvfølgelig kunne en også sjekke listen med morgendagens priser også, men da startet utfordringene. Nordpool integrasjonen sletter "dagens" priser ved midnatt og det som var morgendagens priser blir nye dagens priser. Det gjør det komplett umulig å lage mal-sensorer som vist ovenfor fordi historikken til prisene blir borte. Hvordan skal en finne de 2 billigste timene i løpet av natten når en ikke vet noe om det som skjedde før midnatt? Med entso-e integrasjonen er det nå blitt lett. Med nordpool-integrasjonen må en ty til automasjoner eller skripting sammen med hjelpe-sensorer.

Nå ser det ut som om entso-e integrasjonen fungerer bedre og prices attributten endres ikke ved midnatt. Så da har jeg endret mine mal-sensorer som er på i de billigste timene til det som er vist nedenfor. Nye priser kommer vanligvis klokken 14:00 så mine mal-sensorer ignorerer prisene som allerede er blitt gamle og tar kun hensyn til de fremtidige prisene. - unique_id: billigste_timer_1_2 name: billigste_timer_1_2 state: >- {% set l=state_attr('sensor.average_electricity_price_today', 'prices')[14:]|sort(attribute='price') %} {% set t = now() %} {{ (t >= as_datetime(l[0].time) and t <= as_datetime(l[0].time) + timedelta(hours = 1)) or (t >= as_datetime(l[1].time) and t <= as_datetime(l[1].time) + timedelta(hours = 1)) }} - unique_id: billigste_timer_1_3 name: billigste_timer_1_3 state: >- {% set l=state_attr('sensor.average_electricity_price_today', 'prices')[14:]|sort(attribute='price') %} {% set t = now() %} {{ (t >= as_datetime(l[0].time) and t <= as_datetime(l[0].time) + timedelta(hours = 1)) or (t >= as_datetime(l[1].time) and t <= as_datetime(l[1].time) + timedelta(hours = 1)) or (t >= as_datetime(l[2].time) and t <= as_datetime(l[2].time) + timedelta(hours = 1)) }}

I så fall er Nobø sitt system enkelt og greit med sin hub og app. Og det er et system som det er lite og ingenting "tull" med. Og hvis en vil utvide med annen styring så fungerer det lett med Home Assistant som kan styre Nobø sin hub.

Det kunne jeg gjort, men de krever internett for å kunne styres "hjemmefra". Det nytter ikke med noe gsm-modem-løsning.

Nei

KNX - Home Assistant (home-assistant.io)

New Volue Analysis: Falling Prices Ahead in Long-Term Forecast for Electric Power in Central Europe – Volue