berland

Alt vannet skal uansett gjennom hovedberederen hvor legionella ikke overlever. Det er heller ikke gode vekstvilkår for legionella i en tank som veksler mellom kaldtvann og høy-temp hver dag. En tank som holder 50 grader konstant er vel uheldig, men hadde sikkert gått greit det også siden det skal gjennom en varm tank hvor bakteriene dør. Potensielt litt farligere å skru av hovedtank ved pristoppene gjennom døgnet som vil være et mye billigere tiltak, men ikke farlig nok det heller tror jeg.

Jeg har leflet med tanken på installere en ekstra varmtvannsbereder (120 liter) som kobles i forkant av eksisterende varmtvannsbereder (200 liter). Disse ligger i prisklassen 4000 kr. Inspirert av denne bloggposten https://blog.tibber.com/no/tesla-batteri-i-norge/ så ville jeg gjenta analysesen for mitt case, og med prisene time-for-time i 2017. Priser hentet jeg ned fra https://www.nordpoolgroup.com/historical-market-data/ og brukte kolonnen for Bergen. En slik ekstra varmtvannsbereder kan jeg styre til å kjøre de billigste timene i døgnet, og være avskrudd ellers. Med 2 KW element, så vil en 120 liters tank bruke ca 4 timer å varme opp kaldt vann til 60-70 grader. Primærvamtvannsberederen vil da ha en mye lettere og billigere jobb når den allerede får forvarmet vann, og kan stå på i de dyre timene i døgnet uten å bruke mye strøm. Varmetap fra ekstra bereder regner jeg ikke med, da all varmen kommer huset til gode. Jeg kan anta at varmtvannsbehovet vårt er størst de dyreste timene i døgnet, så for å kunne regne så antar jeg da at jeg kan flytte 8KWh fra de fire dyreste til de fire billigste timene hvert døgn. Jeg må også anta at vi faktisk bruker 8KWh hvert døgn ( = 120 liter varmtvann), dette er kanske noe i overkant. På årets beste dag (med stor variasjon i pris, 29. nov 2017) klarer jeg da få 4.40 kr besparelse med dette grepet, som hadde gitt 1600 kr spart pr. år. Men sum av besparelse for hver dag i 2017 blir ikke mer enn 126 kr, og det er ikke nok til at dette er lønnsomt (største kostnad er egentlig kvadratmeteren med hus som tanken ville opptatt). Vedlagt pythonkode og Jupyter-utskrift av koden i tilfelle noen vil gjenta/verifisere. Ekstra+varmtvannsbereder.py Ekstra+varmtvannsbereder (1).pdf

Den gjorde jobben sin helt fint i to måneder i fjor. Den setter seg fast der jeg har gjort det for trangt å kunne snu seg rundt, blir noen justeringer her og der til våren, men det har lite med klipperen å gjøre.

I fjor (2017) høst hadde OBS tilbud på Landroid Worx WR105SI til 2000 kr. Denne schmellen gikk jeg på. Klipperen har wifi-tilkobling og kan styres via app. På nett finnes bruksanvisning for å emulere app'en slik at jeg får samme funksjonalitet i OpenHAB som appen tilbyr (potensielt). OpenHAB-integreringen gjorde jeg etter at klipperen gjorde seg ferdig for høstsesongen, så det er ikke testet i praksis.

Jeg har laget en liten analyse av egeninnsamlet data, strømforbruk og temperatur i huset. Dette plottet kan brukes til å predikere hvordan huset vil oppføre seg gitt hvor mye effekt man hiver inn. Dataene er all strømforbruk i hele huset, mot bare stuetemperatur, men jeg vil påstå at dataene gir god mening. Ser man på nullpunktet på x-aksen, så ser man hvor mye strøm som trengs for å vedlikeholde temperaturen. Er det f.eks. mellom 15 og 20 graders temperaturforskjell mellom ute og inne, så krever det 3600 W kontinuerlig i en time - altså 3.6 kWh. Skal jeg øke temperaturen med 0.5 grad på en time, så må jeg inn med 4900W. Røde og lilla data ser for glisne ut til at jeg bør stole på regresjonslinjene i plottet. Kombinerer jeg dette med framtidig prisbane for strøm (pr. time), værmelding for temperatur, og ønsket temperaturprofil, så kan jeg regne ut om det er lurt å fyre hardt med strøm om natta. En liten testberegning med noe mulige prisbaner som [35, 40, 95, 95] øre klarte gi meg 10-20% lavere kostnad ved å være i forkant med oppvarming. Feilkilder i analysen er at jeg ikke tar hensyn til varmepumpas COP (som også varierer med effekt og utetemp), varmtvann som stort sett renner ut i sluken, og at det er kun stuetemperatur som tas inn. Ikke alt skal ordnes i første omgang.

Og så blir neste steg å montere motor for å åpne og lukke vinduet automatisk?

Du trenger et mål på absolutt fuktighet, ikke relativ fuktighet. Duggpunkt er et slikt mål, og du kan regne deg fra RH og temperatur for å finne duggpunkt både innendørs og utendørs. Hvis duggpunktet utendørs er lavere enn innendørs, så vil det hjelpe å åpne vinduet. Duggpunkt avhenger egentlig også av trykket, men variasjonen vil ikke være så stor, du kan hoppe over den. Du trenger et programmeringsspråk for å kunne implementere en formel for duggpunkt. Formler kan finnes her: https://en.wikipedia.org/wiki/Dew_point Jeg kjører en slik algoritme for vifter i garasjen. Her varierer det betydelig over tid om det er noe lurt å "lufte".

Python - MQTT - Alsa volumkontroller: https://pastebin.com/RqZTuG0L Scriptet må kjøres av en bruker som har rettigheter til å styre volum, f.eks innlogget bruker. Vil virke å kjøres som root, men da må man stole på MQTT-bibliotekene og at det ikke er hull i koden.

Laget i dag et Python-script som kjøres på husets gaming-maskin for å kontrollere lydvolum. Scriptet rapporterer pc-volum via MQTT og justerer volumet også på MQTT-kommando. Da var det bare å lage seg en item i OpenHAB. Lyden skrus nå av ved barnas leggetid, og også ellers når vi forlater huset. Python-pakker (ubuntu) som trengtes var 'alsaaudio' og 'paho.mqtt'. Script deles på forespørsel.

Se også denne tråden, og tråden som er lenket inni denne:

Jeg har ørten grafer satt opp i Grafana, dataene ligger i InfluxDB. Begge er åpen kildekode og funker meget bra.

Hehe. Riktig programmert så er det mer jobb å legge inn unntak for varselet til egen telefon Bruker opplegget på fire telefoner og noen nettbrett.

Sensiboen klarer seg vel en viss tid på et slikt USB batteri, men siden den står med kontinuerlig Wi-Fi-kobling mot sensibo sine servere så kan det neppe vare mange dager.

Jeg brukte guiden på http://docs.openhab.org/addons/bindings/mqtt1/readme.html

Nå har jeg fått testet. Alarmen ble utløst i dag tidlig (falsk alarm), men det kommer ingenting i loggen som scriptet laster ned (json). Heller ikke i appen på telefonen er det noen som helst spor av utløst alarm (det som heter 'historikk' i appen er samme informasjon som ligger i json-fila jeg får lastet ned via scriptet).

Jeg bruker cloudmqtt for å sende batterinivå fra telefonen min "hjem" (via appen Zanzito) når telefonen ikke er tilkoblet husets wifi-nett. Kjører en MQTT-server innomhus som er koblet mot cloudmqtt i bro-modus slik at meldingen om batterinivået kommer fram til OpenHAB. Jeg ville trolig brukt en slik mqtt-løsning også hvis jeg hadde hatt en wifi-enhet utenfor huset som ville sende statusoppdateringer.

Ventilasjonsanlegget har blitt oppgradert med Sensirion SHT31-D fukt og temperatursensorer, en sensor i hvert kammer, og koblet til samme raspberry Pi zero som også styrer lyset. Beregner duggpunkt og entalpi for dataene i hvert kammer, og bruker dette til å beregne virkningsgrad og hvor mye fukt som produseres i huset. Virkningsgrad vil jeg analysere i forhold til hvordan det skal kobles til optimalisert oppvarming, og fuktproduksjon ser ut til å være en god måling på om noen dusjer eller ikke. Må samle data noen uker/måneder og tenke ut etterhvert hvordan dette kan brukes (og hvor mange feil jeg har gjort i dagens beregninger..)

Grafana-plottet viser avstandsmålingen fra ultralydsensoren, ganget med -1 for å få snudd plottet opp ned. Når den grønne linja går opp, så beveger porten seg oppover, og på -4 cm så er porten helt åpen.

Garasjedatamaskinen er satt i drift, og det funker. Ultralydsensoren er montert på en hylleknekt i taket, og porten stopper 4 cm foran denne når porten er helt oppe. Grafanaplottet viser en åpne og lukkesekvens og avslører at porten min beveger seg med 15 cm i sekundet. Ultralydmålingen av portposisjon er som forventet ikke helt presis. Den måler potensielt i 30 graders bredde, og innenfor en slik kjegle er det mye tak kanskje treffes av og til. Tar høyde for dette i programvaren. Aotec garasjeportkontroller er nå til overs Send melding på PM hvis noen er interessert. Kabelrot er noe man rydder i en annen gang..

Zanzito rapporterer batteristatus som et heltall mellom 0 og 100 som payload.

Jeg bruker Zanzito for å rapportere batteristatus for alle telefoner og nettbrett i familien (via MQTT).

"Frost ute" er så enkel som den kan være, blinker rødt hvis det er minusgrader ute. "Kondensfare" blinker gult hvis duggpunktet i garasjen er mindre enn temperaturen ute. Hvis bilen kommer utenifra (og karosseriet holder utetemperatur) og kommer inn i en garasje der duggpunktet er høyere, så kondenserer fuktighet på bilen (og ikke bare på lakken hvor det ikke gjør noe, men potensielt overalt på bilen hvor du ikke vil ha fukt). De gangene er det kanskje ikke lurt å parkere inne i garasjen,, men det avhjelpes kanskje ved å holde porten litt lenger åpen. Vifter i garasjen styres etter samme oppskrift, og vil alltid forsøke å lufte ut garasjen når dette er tilfelle.

Jeg har brukt denne koden til the-louie nå i en måned. Jeg poller sector alarm hvert minutt for alarmstatus, og bruker det til å skru av lys, radio og tv når alarmen armeres. Er det noen som vet hva man får fra API'et om alarmen faktisk går? Hvis innbrudd/brannalarm kunne jeg godt tenkt meg å få skrudd på f.eks. lys. Ved innbrudd kunne f.eks. lyset i hele huset dimmes opp og ned for å tiltrekke oppmerksomhet. (Jeg har spurt Sector Alarm kundeservice, men foreløpig har jeg bare høflig blitt satt videre til teknisk uten noe svar)

Varmepumper er kjent teknologi, har kjent fysikk, og testes jevnlig. Det er ikke noe tvil om at en varmepumpe er i stand til å bruke mindre strøm enn direktevarme for å avgi samme varmeeffekt, altså at den har virkningsgrad større enn 1. Panelovner, varmekabler, el-kolber har aldri mer enn virkningsgrad 1. Ved ufordelaktige betingelser for varmepumpa (for kaldt i forhold til hva den er designet for), vil virkningsgraden gå ned mot 1. Gitt at du har både varmekabler og varmepumpe installert, er det aldri tvil om du hver dag ønsker å kjøre varmepumpa, den vil alltid gi deg bedre strømøkonomi den dagen enn varmekablene. Anskaffelse av varmepumpe er en annen diskusjon, der er det flere elementer og forutsetninger som må inn. Varmepumpa er dyrere i anskaffelse enn direktevarme, og dette må du ta stilling til. Du må velge en diskonteringsrente for å kunne sammenligne varmepumpeinvesteringen i dag mot framtidige høyere strømutgifter for varmekablene. Valg av diskonteringsrente vil påvirke lønnsomheten betraktelig og her er ingen fasit! Sammenlign det med å spå framtidens rentenivå. Dernest må du gjøre en spådom om framtidig strømpris, framtidig varmebehov og framtidig vedlikehold (dyrere på varmepumpa). Alt er i stand til å snu lønnsomheten begge retninger. Så kan du legge på andre faktorer, som et personlig ønske om å bruke mer eller mindre strøm for miljøets skyld. Eller om du vil ha varmepumpe for å kunne ha mer komfortvarme. Typisk i et fritt market er at prisen gjenspeiler likevekten, slik at både varmekabler og varmepumper er priset slik at de omtrent kommer ut likt ved en slik investeringsanalyse.

Ikke et forsøk på vinne en designpris, men jeg fant en matboks på butikken, lagde noen hull til LED-pærer og hull til ultralydsensor. Dernest er alt sammen programmert ferdig (bortsett fra all bug'ene jeg ikke har oppdaget) slik at jeg nå * fanger bevegelse på port (testet med håndbevegelse, ultralyd) * fanger bil-tilstedeværelse (ultralyd), indikerer med grønn/rød LED tilsvarende nye parkeringshus * Skrur på relé som kobles til portåpneren om jeg ønsker å åpne porten. * Rapporterer temperatur og fuktighet. Jeg har laget 4 stk python-script som går uavhengig, og kjøres som en 'service' på Raspberry'en, et for å styre LED, et for å styre ultralydsensorene, et for å styre portåpner og et for å kontinuerlig rapportere temperatur og fukt. Scriptene snakker sammen over MQTT, og samme MQTT-buss er også kommunikasjonsveien mot OpenHAB. De tre øverste LED blinker, og har da sin egen tråd inni led-scriptet med løkke over av/på.