RVM

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

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 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 det siste har jeg har lekt med tanken på å gjøre reguleringen mer prediktiv ved å innføre et slags feed forward-ledd ved å regne ut tidspunktet for framtidige forutsigbare laster, i mitt tilfelle gulvvarme. Det ser jo tilsynelatende ut som temperaturen faller fint ihht. Newton's law of cooling (altså med en eksponensiell decay, se bilde under), så jeg tenkte jeg kunne bruke curve_fit fra Scipy-biblioteket inni Pyscript til å modellere temperatur som T = T0 + c*e-kt, men resultatet jeg får fra curve_fit er altfor sensitivt for hvilke datapunkter jeg tar utgangspunkt i. For de første 4-6 datapunktene får jeg konsekvent en T0 som er mye høyere enn omgivelsestemperaturen, så det kan ikke være en særlig god fysisk løsning, og gir ikke riktig tidspunkt for når temperaturen faller ned til setpunkt. Skal prøve å finne en temperaturfunksjon som gir et bedre estimat en eller annen gang. Målet er selvfølgelig at det beregnes kontinuerlig i Home Assistant, ikke at jeg modellerer temperaturfallet med hardkodede parametre utenfra.

Usikker på hva du tenker på, men FHI har en veileder på nett som fortjener gjentakelse, https://www.fhi.no/nettpub/legionellaveilederen/ I korte trekk handler det om å oppnå minst 70 grader minst en gang i uka, bakteriene dør over 55 grader. Det skal altså gå greit så lenge VVB regelmessig får jobbet seg opp til driftstemperatur. I praksis er nok dusjslangen en større risiko ifølge veilederen (det minner meg på at jeg må kjøre varmtvann gjennom gjestedusjen før vi får besøk neste gang).

Da ville jeg nok ha mistenkt pluggen/nettverksforbindelsen istedenfor automasjonen. Har ingenting Tuya selv, men ser jo på internett at ryktet til Tuya(-integrasjonen) er litt ymse. Regner forresten med du er klar over at de færreste ville anbefalt stikkontakt og vanlig smartplugg til VVB (ref. NEK400 og effektgrensa på 1500 W).

Det er jo en nokså enkel automasjon, så det er ikke så mye som kan feile. Ville ha gått inn på show trace ("vis sporing"?) for automasjonene for å feilsøke, der får du litt mer historikk for hvert steg av automasjonen hver gang den blir triggered. Hva slags smartplugg er det?

Jeg bruker også pyscript til omtrent samme formål, og essensen hos meg er: [...] today = [e for e in pyscript.electricity_prices.today if type(e) is float] # Remove any Nones today_dict = {} for i, v in enumerate(today): today_dict[i] = v today_prices_sorted_dict = {k: v for k, v in sorted(today_dict.items(), key=lambda item: item[1])} today_prices_sorted_list = [k for k,v in today_prices_sorted_dict.items()] state.setattr("pyscript.electricity_prices.today_hours_by_price_dict", today_prices_sorted_dict) state.setattr("pyscript.electricity_prices.today_hours_by_price_list", today_prices_sorted_list) [...] Så bruker jeg de sorterte dict- eller list-objektene avhengig av hva jeg vil oppnå.

Jepp, det viser bare at automasjonen ikke er deaktivert. Automasjoner som objekt er omtrent som en switch, og kan skrus av og på med sine egne services ("automation.toggle" osv.). Ser ut som automasjonen virker ja, men det kan bli en del støy i logbook når man restarter HA ofte eller enheter dropper ut og inn.

Ja, hvis du bare vil finne de rimeligste timene er det sikkert nøyaktig nok. Og så må du kanskje legge inn et forbehold hvis det blir skikkelig kaldt ute, regner ikke med COP blir negativ...

Hvis du kan leve med antagelsen om 70 % luftfuktighet og 26°C bassengtemperatur, har du jo grafen i databladet. Med det blotte øyet ser det ut som at COP(T) ≈ 3,2+0,09*T. Deler du strømprisene på COP time-for-time for inneværende døgn, har du pris per kWh varme. Håper det er noenlunde rett fram å sortere timene etter pris i Homey.

Over HAN-porten, ja. Men ikke like hyppig over RF til nettselskapet, såvidt jeg vet. Men det må som sagt bare være en konfigurasjonssak.

Regner med det Stigvi tenker på er at smartmålerne i dag er satt opp til å sende data over forrige time noen sekunder etter at den er fullført, men regner med det ikke er en hardware-messig begrensning i at de kan rapportere oftere om man ville konfigurere dem til det.

Haha! Det er greit, jeg får gå tilbake til tegnebrettet 😀 Edit: Mente ikke noe mer komplisert enn at effektleddet kunne avhenge av timesforbruket. Hos Lnett blir effektleddet ca. 48 øre/kWh på dagtid, og 40 øre natt/helg etter 1. juli. Mitt forslag var så enkelt som at effektleddet kunne vært f.eks. 10 øre/kWh for hver time du bruker 1 kWh, 20 øre/kWh for 2 kWh, ..., 50 øre/kWh for hver time med 5 kWh, ..., 100 øre/kWh for hver time med 10 kWh osv. for å ta noen tilfeldige tall. Forutsigbart for sluttkunden, men kanskje ikke forutsigbart nok for netteier.

Jeg forstår at de må finne en middelvei som er lett å forstå og forholde seg til for folk flest, men jeg syns de har bommet litt med forenklingen. Det hadde vært mye lettere å forholde seg til et konstant fastledd, og et variabelt effektledd som skalerte lineært med timesforbruk. Effektleddet over en måned hadde da blitt tidsintegralet av p(t)*k(p), der p(t) er forbruket hver time, og k(p) er kostnaden som funksjon av effekt. Da er det så enkelt som at du belønnes jo mer du klarer å spre ut forbruket, og blir kun straffet for hver enkelttime du har "overforbruk". Veldig forutsigbart. Nå blir fastleddet variabelt og effektleddet konstant (med unntak av dag/natt/helg variasjonen på 8 øre), forstå det den som kan...

Ser ut som jeg må trikse mer med gains, men må nok leve med at regulatoren ikke nødvendigvis går mot en steady state så lenge jeg ikke kan gi trinnløst pådrag (bare av/på laster). Tenker å fortsette med en soft PI kontroller for å unngå veldig mye switching, og heller ha litt headroom mot effekttrinnsgrensa.

Nettopp, premissene for optimaliseringsproblemet er ukjent på forhånd.

Jeg har vært innom samme tankerekke som deg, og syns det er ufint at systemet har blitt et optimaliseringsproblem som er uløselig uten en matematisk modell over energibehov som funksjon av tid. Hvis du har elbiler i flertall, tror jeg ikke det kommer til å lønne seg å konsekvent styre mot nederste effekttrinn, av årsakene du nevner over. Jeg kjører fortsatt på fossilt (og betaler i dyre dommer for det), og bikker 5 kWh omtrent 1-3 ganger i måneden. Da skal det ikke mye triksing til med gulvvarme/VVB for å klare å komme under grensa. I ditt tilfelle ville jeg også valgt å regulere mot f.eks. 10 kWh i stedet, så lenge døgnvariasjonen på strømprisene fortsetter.

Jeg forsto ikke helt hvorfor du dro inn enda et IIR lavpassfilter her, så jeg fjernet det hos meg og justerte ned gains for å kompensere. Tenker det holder å filtrere effekt og ekstrapolert timesforbruk for mitt bruk.

Jeg har lagt merke til en "uvane" jeg har når jeg lager automasjoner, og vil høre om det er noen som kjenner seg igjen. Jeg ender ofte opp med å måtte duplisere alle conditions i automasjonene som triggers, slik at jeg er sikker på at automasjonene trigger uavhengig av rekkefølge. Enkelt eksempel fra nå nettopp med nytt tariffsystem for nettleie: Jeg vil varsles om ekstrapolert timesforbruk nærmer seg 5 kWh, men bare om det er mindre enn 30 minutter igjen av timen. Begge deler kan jo inntreffe først, så for å være sikker på at den trigger ender jeg opp med triggers som conditions og motsatt: trigger: - platform: numeric_state entity_id: pyscript.electricity_estimated_hour_consumption above: '4.75' - platform: template value_template: '{{ now().minute > 30}}' condition: - condition: numeric_state entity_id: pyscript.electricity_estimated_hour_consumption above: '4.75' - condition: template value_template: '{{ now().minute > 30}}' Dette mønsteret går igjen i sikkert 10-15 automasjoner hos meg, uavhengig av om de er i yaml eller pyscript. Det er strengt tatt ikke et problem så lenge det funker, men det blir ofte litt rotete for mer avanserte automasjoner. Jeg er sikkert litt miljøskadd av å tenke sekvensielt fra PLS-programmering i structured text, mens Home Assistant er mer event-basert. Noen som har vært fastlåst i samme mønster og klart å bryte ut av det? Har Home Assistant en mer elegant løsning for å oppnå samme funksjonalitet?

@stigvi, jeg gikk i gang med å skamløst kopiere pyscript-koden din over, men har ikke lagt inn terskelverdier for å slå av forbrukere ennå. Ser umiddelbart at PID-regulatoren kommer til å reagere litt vel hardt for min smak, og tipper det er på grunn av verdien for derivatleddet. Alle kontrollerbare laster kommer til å slå seg av hver gang VVB slår inn (hopp på 3 kW). Hvordan gikk du fram for å stille inn gains til PID-regulatoren din? Tror jeg kommer til å gå for en mykere PI-regulator (uten D-ledd). Husker du har en SSR-løsning til din VVB, så du får nok styrt det mer trinnløst enn meg. Liker heller ikke hoppene i estimert timesforbruk fra Tibber når man trekker mye strøm akkurat i timeskiftet, så jeg legger også på en lineært økende glattekonstant av estimatet de første 15 minuttene hver time. Da får jeg en nokså myk overgang i estimert timesforbruk mellom hver time.

Her også, men appen får tydeligvis kontakt.

Min elektriker valgte, etter å ha ringt kontoret for råd, å sette inn en "servicebryter" i sikringsskapet rett ved siden av sikringen for å være sikker på å være innafor regelverket. Fibaro Dimmer 2 koblet til LED-lampe uten utskiftbar pære. Jeg har enn så lenge godt med plass i sikringsskapet, så jeg kranglet ikke.

Jeg har én sånn HZC dimmer, og den fungerer bra så langt gjennom Zigbee2MQTT (der dukker den opp som "Eco-Dim.07/Eco-Dim.10"). Den likte ikke helt lyspærer med for lav effekt (2-3 W), så jeg måtte bytte pæra også. Men den virker veldig billig, og jeg er ikke sikker på om jeg ville hatt den på ei lampe der ungene kunne ha lekt med den. Enn så lenge får den leve et beskytta liv høyt oppe i ei bokhylle, den er tross alt CE-merka og solgt gjennom norsk distributør, uten at det trenger å bety all verden.

Har ikke prøvd Ubuntu Desktop på sikkert 10 år (jeg bruker som sagt Ubuntu Server, så "brukergrensesnittet" mitt er SSH gjennom MobaXterm), men syns jo Gnome 42 som vel brukes i Ubuntu Desktop 22.04 ser lovende ut. Har såvidt prøvd Linux Mint med Cinnamon, og det virka også bra. Ja, har ikke prøvd å oppgradere fra en LTS til neste LTS ennå, håper det går smertefritt. Bortsett fra Docker og Docker-compose tror jeg den eneste pakken jeg måtte installere selv var zip, og jeg syns det var rart det ikke var en del av basis-installasjonen ja.