RVM

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: Link: https://www.tu.no/artikler/na-kommer-sensorene-som-maler-fukt-inne-i-gulv-og-vegger-tradlost-br/455374

Hm, men det står også: Link: https://bkk.no/artikkel/b6e3df43-e183-41bd-8f43-88701cfd99e4

Ja, jeg ville ikke tenkt så mye på det før du er kommet i gang. 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. 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.

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å

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 ?

Da blir det fort smalhans resten av måneden

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

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.

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

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.

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/

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