RVM

Gullars skrev (9 minutter siden):

Jeg har fulgt med litt de siste dagene. Akkurat nå har jeg den gående de 10 billigste timene i døgnet, og den kommer enkelt ned i 0W flere ganger i døgnet, hvilket vel må tolkes som at vannet er oppvarmet(?).

 

Jeg lurer da på: er det egentlig vits i å styre med temperaturmåling av tanken? Det er vel ingen mulighet for å utvikle legionella så lenge tanken er fullstendig oppvarmet flere ganger daglig?

Nei, hvis du uansett tenker å varme opp fullstendig (over 70°C) hver dag, trenger du ikke temperaturmåling for legionellaen sin del.

Mener å huske en artikkel fra Teknisk Ukeblad for noen år tilbake, fant igjen denne nå men jeg får ikke lest uten abonnement:

Sitat

Nå kommer sensorene som måler fukt inne i gulv og vegger. Trådløst

 

Du trenger ikke løsne en eneste flis for å vite fuktighetsnivået bak membranen.

 

Den svenske fuktsensoren er tynnere enn et frimerke og kommer for salg i Norge i februar eller mars. Snart kommer også «Bergeskruen», et norsk patent med batteri som gir varsel når fuktighetsnivået stiger inne i veggen.

Link: https://www.tu.no/artikler/na-kommer-sensorene-som-maler-fukt-inne-i-gulv-og-vegger-tradlost-br/455374

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

Per-Chr skrev (6 timer siden):

Så det er når man ønsker utvidet funksjonalitet man setter opp ekstra database, UI?

Ja, jeg ville ikke tenkt så mye på det før du er kommet i gang.

Per-Chr skrev (6 timer siden):

Ser for meg å begynne med en Pi da det er lavest start kost.

Men den kan vel kanskje gå tom for ”umf” etter hvert.
Så da er spørsmålet om du har noen anbefaling for hvordan å spece. en NUC?

En Raspberry Pi 4 har mer enn nok "umf" til å kjøre et alminnelig smarthus-system (med et lite forbehold om skrivesykluser på SD-minne, som du har fått med deg). Jeg har en NUC fra 2014 som sikkert er passé på alle vis, men den har aldri hatt problem med å kjøre Home Assistant + 5-6 andre tjenester.

Per-Chr skrev (7 timer siden):

Så har jeg lest en eller annen plass at man kan ta "USB dingsen" ”mobil” for å komme nærmere f eks dørlåsen etc uten å måtte flytte HW plattformen for paring. Men jeg kan ikke finne tilbake til dette så har du peil?

Zwave-sticken min (Z-Stick Gen5+) er mobil, men Zigbee-sticken (Sonoff ZigBee 3.0 USB dongle) er det ikke. I praksis er det nokså lang rekkevidde for paring, så jeg har aldri hatt behov for det, men den dagen det evt. blir et problem finnes det jo USB-over-Ethernet forlengere slik at du kan ha en "USB-kabel" på 30+ meter.

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å

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:

Kanskje du bare kan tilpasse noe som allerede er laget, f.eks. https://github.com/balmli/com.nordpoolspot ?

OlavT skrev (14 minutter siden):

Hvorfor skulle du ønske å styre etter 2.97kWh? Du kan jo i dette tilfellet styre etter 6.93kWh.

Da blir det fort smalhans resten av måneden

Per-Chr skrev (7 timer siden):

Slik jeg forstår det er Node-Red(Data Bridge) plassen til smart hus systemet man bruker(Home Assistent etc)?

Ja, men mange smarthus-systemer kan også fylle alle de fire rollene på figuren din (mellomtjener, smarthusmiljø, database, UI). For Home Assistant som du nevner er det kun MQTT du må sette opp i tillegg, og det kan være så lett som at du velger det inn som en add-on i en add-on store inni Home Assistant.

Jeg tenker at de færreste klarer å prosjektere hele smarthuset sitt bare ved å google; man må nesten bare komme i gang et sted, og da er det så mye lettere å forstå sammenhengen og terminologien når man har et eget system å utforske. Hvis du har en gammel laptop e.l. liggende hjemme kan du jo prøve å installere det du ser for deg på den, bare for å prøve det ut. Ellers må du nok uansett ta kostnaden med å kjøpe en Pi eller NUC eller lignende.

Per-Chr skrev (7 timer siden):

Dette for om mulig å avverge kommende små eller store frustrasjoner/fadeser.

De små frustasjonene tror jeg ikke du slipper unna dessverre, men det skal litt til å gå på noen store fadeser hvis du bare kjøper en Pi for utforskingens skyld

Lykke til!

DeVille skrev (21 minutter siden):

 

Hvordan finner du de 6 billigste timene? 

 

Det finnes noen varianter rundt omkring på forumet. I Home Assistant er det nokså greit å bruke Nordpool-integrasjonen og sortere prisene i enten today eller raw_today attributtene.

Eksempel:

Kan du se i Homey når VVB er "på" uten at den trekker strøm? Da vet du når den ferdig oppvarmet. Hvis du følger med noen døgn med varierende varmtvannforbruk klarer du sikkert danne deg et bilde over hvor mange timer i døgnet den må være på.

Vi er en familie på 4 med et badekar som brukes jevnt og trutt. VVB er 300L/3kW, og den har ennå aldri vært aktiv i mer enn 4 timer i døgnet, så jeg lar den være på de billigste 6 timene.

OlavT skrev (9 minutter siden):

 

Ja, det er smart. Men nye modeller for nettleie bør en forøvrig optimalisere basert på totalpris inkludert nettleie (da den variable delen varierer over døgn / helg / helligdager).

Ja jeg vet, men forskjellen mellom nettleie dag/natt/helg er omtrent neglisjerbar (8 øre/kWh hos Lnett) sammenlignet med døgnvariasjonen for spotprisen, så det ligger langt nede på prioriteringslista.

Interessant!

Jeg gjør noe lignende, men har ikke lagt like mye arbeid i det. Følger bare med på at snittprisen for mitt forbruk ligger under tidsgjennomsnittet av strømprisen i inneværende døgn (fra midnatt til nåtid). Det er mest fordi det går litt "sport" i det, men jeg har sjekket noen ganger at snittprisen på fakturaene er lavere enn det snittet strømstøtten tar utgangspunkt i.

Det er vel akkurat det de skriver på nettsida også? De mener nok implisitt at de er billigst på spotpris (dvs. 0,01 øre/kWh billigere).

Men ja, da er vel Tibber billigst totalt sett om man har et månedlig forbruk på over 390 000 kWh eller noe sånt...

SveinHa skrev (23 minutter siden):

Hei og velkommen til forumet 🥂

 

Har planer om å bygge en ESP32 med strømtrafoer til det bruket og har handlet inn deler fra Kina men foreløpig har jeg hatt så mye annet å putle med at det prosjektet er lagt på is inntil videre...

 

Ellers har jeg måling på de store forbrukeren med alt fra wallplug til Aeotec HD relay og OWON 32A rele og det gir et greit bilde av forbruket men jeg savner litt mer detaljert oversikt likevel. Det er en del ganger jeg ser et litt større forbruk uten at det ligger helt oppe i dagen hva det er...

Sånn har jeg det også, så jeg ser fram til hva du kommer opp med.

Ser at jeg akkurat klarte å tyne meg under 5 kWh-grensa da strømprisen var på sitt laveste i går (med vaskemaskin/oppvaskmaskin/VVB gående samtidig), takket være en variant av PID-regulatoren fra forumet, men en uforutsett last fra kjøkkenet e.l. kunne veltet hele lasset

Hvis du prøver å laste ned en integrasjon som ikke er i repoet til HACS, kan du som oftest velge "custom repository" i HACS og lime inn github-linken. Da dukker den opp som en ny tilgjengelig integrasjon i HACS.

SveinHa skrev (27 minutter siden):

Det er akkurat det vi allerede betaler nettleie for men i stedet for at overskuddet blir investert i nettet prioriteres utbetaling av aksjeutbytte og sutring over for dårlig økonomi til utbygging...

Nettleie går vel stort sett til drift og vedlikehold (og sikkert noe småskala utbyggingsprosjekter), men hvis du har indisier på brudd på inntektsrammen kan det sikkert rapporteres til RME.

Enig med @hjemmedude. Kraftprodusentene og netteiere drar dessverre i hver sin retning, slik at når strømmen er lett å produsere (mye sol/vind/vannstand) blir man "straffet" av netteier for å benytte seg av overfloden pga. begrenset kapasitet i distribusjonsnettet.

Jeg kan ikke forstå annet enn at samfunnet på sikt bare må ta den kostnaden det er å bygge ut distribusjonsnettet i stor stil, koste hva det koste vil. Personlig håper jeg at den regninga blir fordelt på en sosial måte, altså stort sett over skatteseddel heller enn økt nettleie.

Vet ikke hvilken netteier du sogner til, men Lnett oppgir disse kostnadene for bl.a oppgradering av transformatorkapasitet:

Link: https://www.l-nett.no/tilknytning-til-nett/utrede-nettkapasitet/

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

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.

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 = T₀ + 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 T₀ 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.

SK951 skrev (6 timer siden):

Hvordan håndterer du legionella uten temperaturføler?

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).