berland

Takk til innspill her i tråden. Jeg fikk endelig fingen ut og kontaktet Smappee support (etter at målerbytte til AMS viste samme avvik). Jeg hadde misforstått 3-fase stjerne med 3-fase delta under oppsett, og satt feil opsjon. Riktig var 3-fase stjerne. Avvik over 3 dager er nå nede i 0.01%

Kodesnutten som lager strømforbruksmodellen kan kanskje brukes av flere, hvis man har influxdb som datalager, eller har en annen måte å få dataene over til Pandas. def analyse_history(): """Extract historical data from InfluxDB and build bilinear model for power usage as a function of indoor and outdoor temperature returns a sklearn model. """ from influxdb import DataFrameClient from sklearn import linear_model pdclient = DataFrameClient('influxservernavn', influx_port, '', '', 'openhab_db') indoormeasurename = u'Sensor_fraluft_temperatur' outdoormeasurename = u'Netatmo_ute_temperatur' powermeasurename = u'Smappee_avgW_5min' outdoor = pdclient.query("select mean(value) from " + outdoormeasurename + " group by time(1h)")[outdoormeasurename] outdoor.columns = [outdoormeasurename] indoor = pdclient.query("select mean(value) from " + indoormeasurename + " group by time(1h)")[indoormeasurename] indoor.columns = [indoormeasurename] power = pdclient.query("select mean(value) from " + powermeasurename + " group by time(1h)")[powermeasurename] power.columns = [powermeasurename] dataset = pandas.concat([indoor, outdoor, power], axis=1).dropna() dataset['indoorvsoutdoor'] = dataset[indoormeasurename] - dataset[outdoormeasurename] dataset['indoorderivative'] = dataset[indoormeasurename].diff() dataset.dropna(inplace=True) # Drop edge NaN due to diff() # Linear regression: lm = linear_model.LinearRegression() X = dataset[['indoorderivative', 'indoorvsoutdoor']] y = dataset[[powermeasurename]] model = lm.fit(X, y) print("How much can we explain? %.2f" % model.score(X, y)) print("Coefficients %s" % str(model.coef_)) return model Hos meg blir 'score' på modellen bare 26%, som ikke er særlig høyt. Ved å ha ute og innetemperatur som uavhengige variabler klarer jeg oppnå 38% forklaringsgrad, men etter noe tenking, så har jeg kommet til at det bare beskriver gamle data og er ikke like interessant når man skal predikere (det betyr f.eks. at når innetemperatur er høy, så er vi hjemme og bruker varmtvann og komfyr samtidig, og den effekten har du ikke lyst å ha inn i forvarmingsregnestykket). Fysikk tilsier at strømforbruket skal være lineært i de to størrelsene jeg bruker, og det trumfer støyen i dataene. Denne snutten kjører nå hver time for meg, og strømoptimaliseringen vil således hele tiden oppdatere seg (om enn marginalt). Maskinlæring!

Det er kjedelige dager, her er bilde fra optimaliseringen som ble gjort i natt (og med temperaturprofil som har blitt fulgt i løpet av dagen). Besparelse ett øre! Her er det ikke annet å gjøre enn å håpe på mange og store kabler til utlandet for å få til større prissvingninger, samt en eller annen form for ikke-konstant nettleie!

Den siste ja. Hvis klokka nå er 15:00, og du vet at kl. 16:00 så stiger prisen med mer enn 10% relativt prisen nå (kl. 15:00), så vil det lønne seg å varme så mye mellom 15:00 og 16:00 at forbruket mellom 16:00 og 17:00 er null. Termostatverdi mellom 15 og 16 kan (må) da settes høyere enn hva den skal være mellom 16 og 17. Det kan hende det også lønner seg å forvarme mellom 14:00 og 15:00 pga. prisøkningen som kommer kl. 16:00 men den formelen har jeg ikke regnet ut analytisk. Koden min finner sannsynligvis ut om det er tilfelle.

Etter at man har gjort implementasjonen, så begynner man å tenke. Jeg har regnet på papir på hva som er kriteriet for hvorvidt det er lurt å forvarme huset i en billig time, gitt en modell for strømforbruk. Resultatet var at det for mitt hus, så vil det lønne seg å forvarme når prisen pr. time stiger med mer enn ca 10% (inkludert nettleie). Det er ikke sikkert at dette tallet varierer fryktelig mye fra hus til hus, så andre kan sikkert bruke samme kriterie, og lage seg noen enklere regler for forvarming (enn min brute-force python-kode som bruker flere minutter på å finne svaret). Høy varmekapasitet i huset (mye betong f.eks) og/eller god isolasjon gjør at 10%-tallet blir lavere (det skal mindre til for at det lønner seg) og dårlig isolasjon gjør at tallet øker. De matematisk inklinerte kan ta en titt på utregningen som er forsøkt ført inn i vedlagte jupyter-dokument (pdf). Forvarmingsanalyse.pdf Et resultat av analysen var at jeg skjønte at nettleien også måtte inkluderes i optimaliseringen, det var den ikke i første post, så den har overestimert sparepotensialet noe.

Det er ikke meningen å holde koden hemmelig, men den er ikke triviell å sette i drift for andre. Hvis noen har lyst å forsøke selv så deler jeg villig. Det er kun Python-kode, og man trenger en Python-Tibber modul (samt Tibber-abbonnement for API-tilgang) eventuelt tilgang til framtidas strømpriser på annet vis. Temperaturværmelding fra yr er noen få linjer med Python og en XML-modul. Du trenger et interface til ditt eget smarthussystem, jeg bruker en Python-OpenHAB modul, men det er ikke mange linjene som må endres for å tilpasse noe annet så lenge Python har en vei inn i systemet ditt. Dernest er det Pandas-biblioteket som er arbeidshesten i koden, så for å kunne debugge og modifsere selv så er det en fordel å kunne det. Uten masing venter jeg noen dager for å se om noen bugfikser hjelper littegranne. Det er krevende å sjekke og verifisere koden da den er så avhengig av øyeblikkets tilstand, som aldri gjentar seg. Kode for automatisk testing hadde selvsagt vært kjekt, men det har jeg ikke laget.

Fra artikkelen på forskning.no står det: "De er redde for at den nye forskriften vil medføre enda tykkere vegger og tettere bygg enn i dag - uten tilstrekkelig ventilering." Dette er jo helt riktig -uten tlistrekkelig ventilasjon vil et tett hus kunne medføre helseplager. Å ikke ventilere et godt isolert og tett hus er galskap. Jeg kjenner ikke din historie, men tviler på at årsaken til at ungene ble dårlige kan tilskrives tett hus, eller at det var ventilasjonsanlegg i huset.

Riktig at vedfyring krever noen ekstra tilpasninger når man har balansert ventilasjon, men det er helt feil at et helt tett nytt hus med balansert ventilasjon er usunt. Det motsatte er tilfellet. Får man usunne forhold i et tett hus gjør man noe feil, og feil er mulig å gjøre i alle typer hus, tette eller ikke. Det er mye lurere å finne feilen enn å skylde på tetthet eller ventilasjon, det ender opp med dårlige valg. Men det er forøvrig en diskusjon som passer bedre på byggebolig.

Jeg vil gjette det, fra en pdf-brosjyre jeg fant: Eclipse Smarthome er den kommersielle varianten av OpenHAB, så når det virker, så gjetter jeg på at OpenHAB også vil virke. Ihvertfall teknisk gjennomførbart, men om det er noen hindre på veien man må passere skal jeg ikke uttale meg om. https://www.develcoproducts.com/media/3471/squidlink-gateway-brochure-v31.pdf

Et tilsvarende ET-plot for huset mitt ser slik ut: og er veldig kompatibel med plottet du lenket til iceball, men det illustrerer at jeg har hentet inn mindre forbruksdata (17 uker) enn jeg påstod i første post. Jeg har Smappee-data for ca. ett år liggende hos Smappee-skyen, men har bare fra data fra i høst liggende lokalt. Datagrunnlaget for ET-plott er det samme som det jeg bruker for optimaliseringen, men man må inn på samme tidsskala som strømprisvariasjonene, og så må man også få eksplisitt inn i modellen hvordan strømforbruket responderer på endring i innetemperatur.

Jeg laget for to uker siden en liten(?) kode for å optimalisere strømforbruket med tanke på strømutgifter (ikke strømforbruk) for å ta hensyn til varierende pris gjennom døgnet (og siden jeg for et par uker siden fikk timesavlesning gjennom ny måler fra BKK og strømregning hos Tibber). Grunntanken er å forvarme huset når prisen er billig. For å kunne gjøre dette må man ha en modell av huset som beskriver strømforbruk som funksjon av husets tilstand (temperatur) og hvilken temperatur man ønsker. Jeg har i et halvt år samlet strømforbruk hvert 5. minutt og samtidig logget temperatur. Ved å se på midlere strømforbruk for hver time og sammenligne det med temperaturer og temperaturendring over hver time så kan man bygge en modell på dette (hvis jeg gjentar denne analysebiten kontinuerlig, så kan det kalles maskinlæring). Jeg bruker da sklearn i Python til å lage en (multi)lineær modell som predikerer strømforbruk utifra temperaturendring og differanse mellom ute og innetemperatur. Det er betydelig med støy i denne modellen, se plott av alle dataene mine her: Som en bilineær modell i Python, så implementerer jeg den slik, dette blir nesten analogt med de rette linjene i plottet over: def hourly_power_usage(tmpincrease, insideoutsidediff): """This function could do multlinear regression on the dataset or use finished regression coefficients. It answers what power (in KwH) is needed for the whole house to reach the delta temperature in one hour. """ # from sklearn import linear_model # model = lm.fit(X, y) # X = [inne_diff, inne_diff_ute], y=Smappee5minavg(hour)] coef = [2.150, 0.189] # beware W vs KW intercept = 0.5735 return coef[0] * tmpincrease + coef[1] * insideoutsidediff + intercept Her er det tallene 2.150 og 0.189 kW som man kan tolke: 2150 er ekstraeffekten som kreves for å øke temperaturen med en grad i løpet av en time, samt at man må legge på 189W for hver grad differanse det er på ute og inne, og blir et mål på hvor godt huset er isolert. Kaldere utetemperatur gir høyere pådrag på 189-koeffisienten. I tillegg passer det modellen å legge på 573 watt uansett hvordan temperaturforholdene er. Når denne modellen er på plass, så kan man ved å kjenne framtidas strømpris, framtidas temperaturbehov (ønsket termostatinnstilling) og framtidas utetemperatur (yr) estimere strømforbruk og tilhørende kostnad. I tillegg kan man få tilpasset start av oppvarming for å møte et framtid temperaturønske. Jeg har delt "optimaliseringen" i to deler. Først en kodesnutt som flytter oppvarming tidligere i tid i tilfelle estimert effektpådrag blir for stort. Hvis man skal hoppe fra 18 grader til 25 grader i ett jafs, så tilsier modellen et effektuttak på omtrent 14KW. Jeg har ikke nok variabel effekt (Multireg x 5 (snart 10) + varmepumpe) til å klare dette, så det betyr at jeg må starte en eller to timer tidligere. Koden er enkel brute-force som øker termostatverdien timen forut for høyt estimert effektuttak og gjør dette omigjen helt til effektuttaket går under en viss grenseverdi. Resultatet av det steget ligger i den blåe linja i plottene lenger nede, kalt 'Kwh-adjusted'. Neste steg er optimalisering - her gjør jeg det med hjemmelaget brute-force (jeg tror optimaliseringsteknikken kalles 'simulated annealing'). Jeg øker temperaturen med 0.5 grader på tilfeldige tidspunkt (untatt i nedkjøliingsperioder) og rekalkulerer kostnad. Hvis en viss temperaturøkning resulterer i redusert kostnad, bevares forslaget, ellers forkastes det. Dette gjøres iterativt, og endel ganger omigjen for å øke sannsynligheten for at man ender opp på et globalt minimum. Resultatet blir som man kan se i plottet under. Optimaliseringen gjentas hver time, og jeg har justert antall iterasjoner slik at det tar ca 1 minutt å kjøre. Her kan man se blå kurve som startpunkt, og rød kurve som ferdig produkt. I natt har altså huset tenkt å begynne med forsiktig oppvarming allerede klokka ett for å på billigst mulige måte klare holde 25 grader mellom 7 og 8 i morgen tidlig når prisen er 80 øre (25 grader er 'master-termostat', faktiske termostater har en viss delta i forhold til denne utifra rommets behov). Det regnes også ut hvor mye man sparer på optimaliseringen, akkurat i denne perioden er det hele 2.37 kr (det er mye i forhold til det jeg har sett de i ukene dette har vært i drift..). (i plottet ser man at jeg også skrur av varmtvannstank i døgnets tre-fire dyreste timer) Så, virker det? Vel, jeg har ikke kontroll på alt effektuttak ennå (venter på 5 stk multireg som skal monteres av elektriker), men jeg er ihvertfall i stand til å observere historisk strømforbruk og pris som ser slik ut: og gjetter på at akkurat her har jeg spart noen titalls øre

Rett før vinterferien programmerte jeg opp en "innbruddsmodus" med blinkende lys. Tanken er at hvis noen av bevegelsessensorene trigges når husalarmen er på, så er det kanskje innbrudd, og da kan godt lyset si fra på sitt vis, ved å dimme opp og ned alle lysene i huset (godt synlig ute), samt at RGB led-striper blinker rødt. Jeg hadde mine anelser om at sensorene kunne trigge feilaktig, så jeg satte dette til kun å blinke i ett minutt. I OpenHAB programmerte jeg dette med en virtuell switch (item) som settes på når huset tror det er innbrudd, og så skrus den av igjen med 'expire'-bindingen etter ett minutt. Et minutt er vel ikke for flaut at huset ditt står og blinker. På telefonen på hytta i vinterferien får jeg beskjed om at huset er "innbruddsmodus" - vel det var vel neste å forvente tenkte jeg. Sjekket det jeg kunne fra remote at lyset ikke stod og blinka - så bra ut da den virtuelle switchen var avskudd slik den skulle. Dagen etterpå gjør jeg av andre grunner en restart av OpenHAB-instansen (tror det var Netatmo-bindingen som trengte et spark, og sparket var enklest med en restart). Senere samme kveld blir kona oppringt av en nabo som hinter om at huset står og blinker!! #%&? (og ja, i timesvis) Rask innlogging i huset fikk skrudd av blinkinga, men jeg måtte tenke endel før jeg skjønte hva som hadde skjedd. Det skulle jo bare kunne blinke i ett minutt. Teorien min er at expire-bindingen kun satte item til 'undefined'. 'Undefined' ble ikke lagret til InfluxDB som en gyldig verdi, så i InfluxDB (som er mitt "persistence storage") så var innbruddsswitchen fortsatt på. Når OpenHAB restarter, henter den forrige verdi på alle items/devices fra InfluxDB - og der var jammen innbrudsswitch på. Og expire-binding blir ikke aktivert når en item startes opp på denne måten, så da var det ingen regler igjen for å skru av blinkinga... Fikser i etterkant: Expire-binding bør sette tilstand til OFF, ikke bare til undefined, slik at OFF også lagres. Når blinkeregelen aktiveres, setter den også i gang sin egen timer på ett minutt som også skrur av modusen - dobbelsikring i tilfelle krøll med expire. Og med litt ekstra pushovermeldinger når blinking startes opp. Og som siste skanse: For øyeblikket er linjene som faktisk gjør blinking kommentert ut

Det er mulig denne tutorialen for OpenHAB er av interesse https://community.openhab.org/t/a-state-machine-primer-with-hablladin-the-openhab-genie/17787 OpenHAB sine regler skrives i en Java-utvidelse kalt Xtend, men jeg så vel egentlig ikke spor av så mye objektorientering i koden lenket til over. Interessant hvis dette kan gjøres enda penere med objektorientering, jeg har endel kode som etterhvert begynner å ligne spaghetti.

Jeg har et script for nesten dette i denne tråden

Jo, men ikke hver time (må jo være mulig å scripte sms-innsending av målerstand hver time, basert på egne målinger) Jeg vil gjette at energiselskapene ikke har laget kode for å fange opp misbruk av timesinnmeldinger med lavt forbruk i dyre timer, gevinsten for det er for liten før AMS er rullet ut overalt.

Et av forretningskonseptene til Tibber er å ikke tjene mer penger hvis du bruker mer strøm - til forskjell fra de fleste (alle?) andre. Derfor får du innkjøpspris/spotpris på strøm, men betaler et fast tillegg pr. måned (39 eller 49 - husker ikke helt) uavhengig av forbruk. Så derfor tror jeg ikke uten videre på at man finner billigere kwh-pris enn Tibber, fordi det er nordpool-prisen direkte. Får du billigere øre/kwh hos andre, så er det enten en gave til deg som kunde (som ikke alle andre får, eller så går de konk) eller så blir du lurt av andre påslag.

Høres ut som om det er gode muligheter for å lure nettselskapet sitt hvis de stoler blindt på manuelt innsendte avlesninger..

Jepp, her stemmer det, 380.34 NOK/MWh = 38034 øre /MWh = 38.034 øre/kWh. Det tar tid å gjenopprette tillit til Nordpool sine enheter etter å ha funnet feil tidligere

Det er NOK/MWh Sist jeg hentet data fra nordpool (se tråd og pdf'en som er lenket inn) så var enheten NOrske øre (NOØ?) pr MWh selv om header i HTML-fila sa NOK/MWh. Noe spesielt hvis NOK både kan bety NOrske Kroner og NOrske Ører.

Meget bra at Gilje Tre bruker uavhengig tredjepartsteknologi i stedet for å prøve å lage noe selv og som kun funker med GiljeTreAppen.

Jeg har bestilt denne. Har bedt om åpning av HAN-port, men BKK har ikke fått det til ennå ("for dårlig kommunikasjon til måleren min") - gjør ikke mye så lenge jeg venter på aliexpress uansett.

Betyr 100% bare at den går, eller kan du også ha tall mellom 0 og 100, som da kanskje angir hvor stor andel av tiden den har gått i et eller annet tidsrom. Når du får ut 15% på ettervarmeren - betyr det at det står på 15% av tida, eller er effekten skrudd ned til 15% på den?

I min VSR-300 så måler jeg 1550W ekstra når varmeelementet slår inn (målt med fibaro-plugg). For øyeblikket er varmeveksleren avskrudd pga. av røket drivreim og umulig adkomst for å fikse. Da ser jeg at elementet pulserer, 30 sekund på, og 90 sekunder av, for å heve inntakstemperatur på 2 grader til 17 grader tilluftstemperatur (målt inni aggregaget).

Man får ihvertfall til alt som står på denne lista: https://docs.openhab.org/addons/bindings/sonos/readme.html Jeg ser ikke umiddelbart noe viktig funksjonalitet som mangler, men GUI til dette må du jo ordne selv hvis man ikke vil bruke Sonos sin egen app. Dette er hva OpenHAB støtter, og da kan alle andre systemer også gjøre det samme.

Jeg har hatt noen Sonosenheter i huset en uke (var ikke mine) og de integrerte seg lett med min OpenHAB og bindingen opplevdes mer stabil enn Squeezebox som jeg bruker daglig. Trenger kanskje smarttelefon for noe oppsett men jeg så ingen videre automatiseringsproblemer.