RVM

Så bra! Siden du la det inn i dag vil du sikkert legge til data fra 01-06. oktober manuelt. Du kan legge inn noe sånt for hver dag du mangler denne måneden, lagre, og ta det bort igjen: pyscript.electricity_monthly_average_price.stored_values['2022-10-01'] = [1.053, 0.875, 0.69, 0.302, 0.24, 0.228, 0.223, 0.334, 0.621, 1.005, 1.505, 1.463, 1.235, 1.017, 0.91, 0.92, 0.96, 1.885, 2.314, 2.674, 2.463, 1.982, 1.511, 1.064]

Ifølge feilmeldingen eksisterer ikke pyscript.electricity_monthly_average_price, så du glemte kanskje å definere den første gang før state.persist? Prøv å endre begynnelsen av scriptet til: pyscript.electricity_monthly_average_price = 0.0 pyscript.electricity_monthly_average_price.stored_values = {} state.persist('pyscript.electricity_monthly_average_price') @state_trigger("sensor.nordpool_kwh_krsand_nok_3_10_025") def calculate_monthly_average_price(): ...og så lagre fila. Deretter fjerner du de to første linjene, slik at det ser slik ut før du lagrer igjen: state.persist('pyscript.electricity_monthly_average_price') @state_trigger("sensor.nordpool_kwh_krsand_nok_3_10_025") def calculate_monthly_average_price():

Noe sånt kanskje? {% set l=state_attr('sensor.nordpool_xxx_xxx_xxx_x_xxx_xxx', 'raw_today')|sort(attribute='value') %} {% set ns = namespace(out=false) %} {% set n = states('input_number.xxx')|int %} {% for i in range(n) %} {% if (now() >= l[i].start and now() <= l[i].end) %} {% set ns.out = true %} {% endif %} {% endfor %} {{ns.out}} Husk å legge inn din egen Nordpool-sensor og input_number.

Mulig det finnes andre måter, men på min kan man i alle fall sette den i Eco mode, og så stille opp terskelverdien for temperaturdifferansen som skal til før varmeelementet slår inn. Men varmeveksleren vil gå etter behov likevel.

Jeg tror ikke det finnes et universelt svar, tipper det avhenger av standard, klima og årstid. Og varmepumpen selvfølgelig. Vi bor i en nyere enebolig bygd etter TEK17-standard. Varmepumpa står i hovedoppholdsrommet (stue/spisestue/kjøkken), og etasjeskillet mot soverommene over er isolert. Varmepumpa er alltid i laveste tenkelig modus ("stillegående" og "økonomi"), og da den var på i 26.5 minutter i dag tidlig rapporterte den 0.2 kWh. Jeg kan ikke tenke meg at det skulle lønne seg å la den stå på helt til vi kommer hjem fra jobb, men nå er det tidlig høst i vestlandsklima. Det endrer seg kanskje når vinteren kommer.

Så man kan altså skrive til en inngang som egentlig er dedikert til en fysisk digital input? Høres jo rart ut, så jeg måtte leite opp dokumentet du har et utklipp fra. I kapittel 5 skriver de i alle fall at alle innganger og coils er tilgjengelige som registere med en formel for addressen: (Register Address * 16) – 15. Jeg tipper at du kan lese register 701, og få en eller to bytes som du må dekode til bits iht. oversikten over. Og så kan du skrive til (701*16)-15 = 11201 for DI1 osv for å sette inngangene. Men det er nå bare et gjett, du får prøve deg fram. Hvis du har satt opp modbus slik at du kan bruke modbus.write_register osv som postet over, kan du prøve: service: modbus.write_coil data: address: 11201 slave: 1 state: True hub: VTR300 Forutsetter selvfølgelig at du har definert modbus i configuration.yaml med hub VTR300. Usikker på om state må være 1 eller True.

Ja, i "developer tools" i venstre marg ("utviklerverktøy" på norsk?), jeg "simulerte" det jeg kopierte over, for å sjekke at jeg får en liste som er sortert på pris for de timene du hadde valgt ut:

Hva om du bytter ut: {% set l=state_attr('sensor.nordpool_kwh_trheim_nok_3_095_025', 'raw_today') |selectattr('start', '>=', now().replace(hour=0,minute=0,second=0,microsecond=0)) |selectattr('start', '<', now().replace(hour=6,minute=0,second=0,microsecond=0)) |selectattr('start', '<', now().replace(hour=9,minute=0,second=0,microsecond=0)) |selectattr('start', '<', now().replace(hour=15,minute=0,second=0,microsecond=0)) |selectattr('start', '<', now().replace(hour=20,minute=0,second=0,microsecond=0)) |sort(attribute='value') %} ...med: {% set l = (state_attr('sensor.nordpool_kwh_trheim_nok_3_095_025', 'raw_today') |selectattr('start', '<', now().replace(hour=6,minute=0,second=0,microsecond=0)) |list + state_attr('sensor.nordpool_kwh_trheim_nok_3_095_025', 'raw_today') |selectattr('start', '>=', now().replace(hour=9,minute=0,second=0,microsecond=0)) |selectattr('start', '<', now().replace(hour=15,minute=0,second=0,microsecond=0)) | list + state_attr('sensor.nordpool_kwh_trheim_nok_3_095_025', 'raw_today') |selectattr('start', '>=', now().replace(hour=20,minute=0,second=0,microsecond=0)) | list) | sort(attribute='value') %} Hjelper det?

Den skal trigge hver gang entityen i @state_trigger har en ny state, du har sikkert en annen Nordpool sensor entity enn meg? Oppdater i så fall sensoren inni funksjonen også med din Nordpool-sensor. Og husk å legg til state.persist('pyscript.electricity_monthly_average_price') øverst i fila. Hvis den pyscript-entityen ikke er definert, må den defineres første gang.

Hvis det er ting som MÅ funke uten at du sjekker HA daglig, så kan det jo være lurt å legge inn: En automasjon med notify service for opplagte feil, f.eks. at VVB ikke har vært på siste 24 timer hvis logikken tilsier det. Men du får kun notifikasjon hvis HA kommuniserer, så da bør du også ha... ...en konto på f.eks. Healthchecks.io, sånn at du blir varslet på e-post hvis din HA ikke er koblet til internett.

Pyscript: @state_trigger("sensor.nordpool_kwh_krsand_nok_3_095_025") def calculate_monthly_average_price(): date = sensor.nordpool_kwh_krsand_nok_3_095_025.raw_today[0]['start'].strftime('%Y-%m-%d') pyscript.electricity_monthly_average_price.stored_values[date] = [n['value'] for n in sensor.nordpool_kwh_krsand_nok_3_095_025.raw_today] avg_num, avg_den = 0, 0 for k,v in pyscript.electricity_monthly_average_price.stored_values.items(): avg_num += sum(v) avg_den += len(v) pyscript.electricity_monthly_average_price = round(avg_num / avg_den, 3) @time_trigger("cron(@monthly)") def reset_monthly_average_price(): pyscript.electricity_monthly_average_price.stored_values = {}

Jeg brukte Pyscript til det. I korte trekk har jeg en sensor der jeg lagrer prisene fra raw_today i attributtene hver gang raw_today oppdateres, og så beregner jeg snittet fra alle timene så langt i måneden. Tenker man må finne en løsning som beholder eventuelle mellomlagrede data etter en restart, og da er Pyscript veldig praktisk pga. state.persist. Kunne sikkert også brukt aggregateWindow i InfluxDB hvis man har det satt opp.

Funker det hvis du legger det inn i et utility meter?

Forresten, er det noen grunn til at du/dere legger på enda et lavpassfilter på PID output når timesestimatet allerede er filtrert? Blir mest nysgjerrig siden du til og med lagrer PID gains til en entity, så du bruker dem tydeligvis andre steder. Men de reelle PID parametrene er vel ikke de samme som de du lagrer siden outputen går gjennom et filter (dvs. filteret y[n] = 0.9*y[n-1] + 0.1*x[n])? Edit: Ser nå at pid.components ikke gir gains direkte, men hvert av bidragene i PID outputen. Men spørsmålet består

Ja, det gjelder å være konsistent. Da du rundet av til 0 desimaler med limits på 0 og 1 hadde du bare to mulige utfall, 0.0 og 1.0, og du hadde sikkert høyere terskelverdier enn det for å skru av hvis du hadde lagt opp til PID output mellom 0 og 100.

Ville ikke rundet av mot 0 desimaler hvis PID outputen skal gå fra 0-1. Eller bruker du 0-100 for PID output andre steder? I så fall bør pid.output_limits gå opp til 100.0.

Vet ikke hvor mye akkurat det har å si, men etter å ha tenkt meg litt om tror jeg både venstre- og høyre-metoden vil konvergere mot "riktig" areal over lang nok tid siden effekten over tid vil stige og synke like mye (venstremetoden vil underestimere når effekten stiger, og overestimere når den synker, sånn at feilen til slutt kansellerer). Hvor stor den unøyaktigheten er tror jeg bare er av akademisk interesse.

Har ikke brukt Riemann-integral i HA, men generelt er trapes-metoden mest nøyaktig. Venste/høyre vil hhv. under- og overestimere. Jeg får forbruket så langt i timen direkte fra Tibber Pulse, så har ikke hatt behov for å integrere effekten.

Det var kanskje ikke dette du hadde i tankene, men du oppnår vel sikkert et FIR filter med derivasjonen (ser den er basert på SMA vektet med tid), mens et IIR filter fra eksponensiell glatting fort kan dra med seg eventuelle feil inn i uendeligheten I praksis tror jeg ikke det spiller noen rolle, det er mange veier til målet.

I industrien er det jo vanlig med clamp-on ultrasoniske flowmetere, men det stiller litt krav til rette rørstrekk og sikkert rørdimensjon. Har ikke sett det til hjemmebruk, men de industrielle ville du aldri klart å tjene inn med å spare varmtvann dessverre.

Forsåvidt, prøvde bare å forstå hva cut-off frekvensen ville vært i Hz. Tenker sånn intuitivt at man ønsker at PID-regulatoren (som diskutert i andre tråder) er treigere enn effektleddet i ekstrapolert forbruk, sånn at estimatet rekker å reagere på endring i PID output. Uten at jeg har brukt mye energi (pun intended) på å gruble så mye på det. Edit: Men unnskyld, det var ikke meningen å spore av denne tråden også

Så du integrerer effekt til energi, og deriverer tilbake til effekt før du ekstrapolerer? Det funker jo, men oppnår du ikke i praksis lavpass-filtrert effekt med en litt uklar tidskonstant? Hvis det er hensikten, hvorfor ikke bare bruke Home Assistant sitt innebygde filter? Jeg spør fordi jeg er nysgjerrig, jeg bruker samme framgangsmåte men med filter istedenfor integrasjon/derivasjon for effektleddet i estimatet.

Litt avhengig av hvordan du vil ha outputen din, så legger du bare til en slice (hhv. [0:6] og [9:17]) i templaten i åpningsposten. Eks: Edit: Fikset slicen, blandet start og end-tidspunkter.

Siden du bruker Home Assistant finnes det mange gode tips rundt om på forumet. Tråd for Nordpool integrasjon: https://www.hjemmeautomasjon.no/forums/topic/5225-nordpool-sensor-for-home-assistant/ Tråd for å finne billigste timer: https://www.hjemmeautomasjon.no/forums/topic/7315-finne-de-billigste-str%C3%B8mtimene-i-home-assistant/

Har sjekka nå, sånn ser update_regulator funksjonen ut hos meg: @state_trigger("pyscript.electricity_estimated_hour_consumption") def update_regulator(): global pid last_c = float(pyscript.regulator_electric_power) now = datetime.now() if now.minute < 15: pid.output_limits = (last_c, 1.0) # Only allow increase first 15 mins else: pid.output_limits = (0.0, 1.0) c = pid(float(pyscript.electricity_estimated_hour_consumption)) if round(c, 2) != last_c: pyscript.regulator_electric_power = round(c, 2)