berland

Takk for tips, jeg har akkurat fått 3 stk i posten og de tydeligvis av ekte sort.

Det er ikke noe poeng i dag å skru av varme når man bruker mye strøm ellers, først må prismodellen endres. Det håper vi jo skjer, siden noen av oss har investert tungt fysisk og mentalt for dette. Dermed kan man ikke argumentere overfor Hafslund at man taper penger på at de ikke overholder fristen. Jeg ville valgt andre argumenter.

Vel, det mest ekstreme her er jo påstanden om 30% besparelse. 30% besparelse kan man nok i ekstreme tilfeller få fra å gå fra konstant høy temperatur døgnet gjennom, til natt og dagsenking, i et dårlig isolert hus. Data fra HAN-porten kan gi folk bevissthet om dette, men besparelsen kommer fra automatikken som gjør natt- og dagsenking, og det kan også gjøres uten HAN-port. (NB: sitatet fra Ewave over sier ikke at det er HAN-porten som gir 30% besparelse)

Har du en Hue Bridge også liggende, som du ikke ser for deg å ha aktivert med FutureHome? (forstår deg slik at FutureHome ikke støtter Hue) I så fall hadde jeg venta og sett på hvilke muligheter som kommer med FutureHome, hva behovet ditt er, og om du muligens vil bytte ut FutureHome med noe annet.

I smappee-appen så oppdaterer liveforbruket seg med kanskje 2-5 sek mellomrom, men antar den sampler oftere uten å publisere det. Dataene går via skyen og til telefonen min.

Jeg regnet på det i vår i tråden https://www.hjemmeautomasjon.no/forums/topic/2896-berlands-strømoptimalisering/ (Hold varmtvannstank unna, det er en annen problemstilling, slik som bjornepappa skriver) Jeg har kode som hver time estimerer utfra historiske strøm- og temperaturdata for huset (og ute) hva som er lurest å gjøre. Modellen min sier at det koster meg 130-170 W/differansegrad-ute-inne å holde temperaturen i huset (forskjell i tall kommer av hvilken temperaturlogg jeg ser på, det er et ikke-trivielt tema). Si at utetemp er null grader, og innetemp er 22 grader 14 timer i døgnet og 20 grader 10 timer i døgnet. Anta også at at det "ikke koster" noe å varme opp fra de to gradene med nattsenk, dette er ca. riktig fordi det kanselleres når du slipper temperatur ned. Hos meg vil jeg da spare 2 grader * 10 timer * 150W/grad = 3000Wh = 3kWh i døgnet ved å senke temperaturen med 2 grader i 10 timer. Husk at det å spare 3kWh ikke er det samme som å spare x kroner, fordi strømprisen varierer, men ved høstens kjedelig lave strømprisvariasjoner er det definitivt nattsenking som gjelder hos meg (så kan jeg juble over de ca. 3 kr som blir spart hver dag!)

1) Vanskelig å forutse om du er uheldig med elektriker, men jeg ville satset på at det går greit. Det kan være lurt å være opplest på temaet her på forumet. Ingen problem for min elektriker. 2) Bypass er ikke nødvendigvis enten/eller. Det kan funke fint uten bypass, men så kan det funke enda bedre med (kan dimme lavere). Kjøp bypass til alle hvis du for all del vil unngå et ekstra elektrikerbesøk (hos meg er det ikke vits i å innbille seg at jeg ikke engang i løpet av de neste 12 mnd må ha elektriker innom for et eller annet..). For installasjonen du skisserer vil jeg påstå at det er rimelig sannsynlig at du må ha inn elektriker på en strafferunde. Murphy. 3) Hvis du setter dimmere på pærer som ikke tåler dimming, så kan pærene bli ødelagt hvis du likevel dimmer (så bytter du til dimbare pærer, og problemet er løst). Jeg hadde nok kjøpt dimmer.

Fra dokumentasjonen til bindingen på https://www.openhab.org/addons/bindings/dmx/ så gjetter jeg på at det er nettverksadressen til lib485-broa di, som det står er localhost som default (som da peker tilbake til pi'en din). Vil da gjette på at du kan la denne stå blank, altså default.

Hvis jeg skal gjette, så fanger den opp kanskje 90-95% av hendelsene av enheter som går av på, da snakker jeg om varmekabler fra 500W og oppover. Den fanger opp mye under det også, men det er en stor jobb å lære seg til å stole på at det faktisk er riktig. Og når det ikke er 99,9% riktig, så gidder jeg rett og slett ikke prøve å stole på det. Sannsynligheten for at den fanger opp både på og av for noe som skjer er da to hendelser, som da blir 80% sannsynlig at plukkes opp riktig osv. Og når det ikke er helt å stole på, er det en betydelig jobb å identifisere de ulike lastene som plukkes opp. Du har nødvendigvis ikke annet enn antall watt, og tidspunktet for når det gikk av og på. Sikkert håndterbart i en liten leilighet, ikke håndterbart her. Lastene som er omtrent like, som varmekabler i like store rom. Om den da plukker opp 100% av hendelsen, så vet du jo ikke i hvilken den av huset det gjaldt. Varmtvannstanken er kanskje 99% riktig. Men der har jeg jo egen plugg som er til å stole på. Appen påstår jeg har en klestørker på 28kW. Heftig, men stemmer ikke.. Samme med en oppvaskmaskin på 16kW. Høytrykkspyleren har den plukket opp halvparten av gangene den har vært i bruk, stekeovn er umulig fordi den kan gå på så mange forskjellige wattnivå. Appen påstår jeg har 6 ulike støvsugere. Lys er det bare å glemme, klarer ikke engang telle opp.

Jeg har TN, men regner ikke min Smappee-enhet som en suksess på annet enn at det gav meg strømmåling før AMS kom. Kikker svært gjerne på oppgaven når den er ferdig!

Regner med det er noe av det samme som Smappee også har implementert https://www.smappee.com/be_en/blog/smappee-appliance-recognition/ Dette har jeg også i hus, men hos meg er det ikke robust nok til at jeg kan bruke det i praksis. Kunne i prinsippet hentet ut hendelser som Smappee registrerer for laster som går av og på, men det kan ikke brukes i praksis da jeg ikke kan være sikker på at jeg får med meg av-hendelsen etter en tilhørende på-hendelse. Laster som er like klarer den heller ikke skille, feks varmekabelkurser i ulike rom men som har likt areal. Kanskje det kan være robust nok i små leiligheter med lavt strømforbruk.

Jeg har ihvertfall disse dataene, uten å vite hva jeg skal bruke de til..

Ble bra her med Luxaflex og ingen synlige ledninger. WAF var lav etter innkjøp pga pris, men steg igjen når det ble montert. OpenHAB 2.3 har bug i powerview-bindingen, den er fikset til 2.4 (som ikke er sluppet) - men så oppdaget jeg at Duette-gardinen ikke er støttet, dvs. OpenHAB 2.4 klarer ikke styre den øverste skinna, kun den nederste. Pga. bug i 2.3 lagde jeg meg min egen kobling med MQTT mot Powerview-hub'en i Python. Denne vil virke for alle andre uavhengig av OpenHAB, men krever litt ad-hoc skreddersøm. I tilfelle noen trenger det (Når OpenHAB bare snakker MQTT mot mitt eget Python-script så omgår jeg hele bug'en og også Duette-begrensinngen - hadde jeg vært bedre i Java hadde jeg nok heller fikset OpenHAB enn å gjøre det omigjen i Python..) Åpner seg i topp om morgenen. Lukket på husalarm er på siden det er vinter, og disse isolerer godt. Åpent på dagtid når vi er hjemme. Åpen kun øvre halvdel om kvelden for å minske innsyn.

Bør være verdt et forsøk! "Operating temperature" ned til 10 minusgrader.

Prøve å lage et slags horn som dette? Fra https://www.maxbotix.com/Ultrasonic_Sensors/MB7334.htm som har working temperature fra -40 grader.

Den er god! Sensorene på rørene er forsåvidt ikke godt for annet enn deteksjon av tapping som smaker mer av overvåkning enn nytte. Nå som jeg fikk en sensor plassert på fornuftig plass er de overflødige i forhold til nytteverdi. Det er nå den nye sensoren sine data som brukes i koden som kjører hver time for å planlegge når tanken skal varme vann.

Ja, se bildene øverst til tråden.

Flere dagers målinger, og ny innsikt. Beregningen av "tele" som jeg har i et innlegg lengre opp er bare tøys. Fysikken er vanskeligere enn som så. Energien som trengs til faseoverganger (is <-> vann) er betydelig, og bare varmeledning er for simpelt. Se på den gule pila, og den gule kurven for 20 cm dyp. Plutselig skyter den i været uten at det skjer som skulle tilsi dette hverken i temperaturene under eller over. Forklaringen på dette er at temperaturen på 20 cm har vært stabil på rundt 0 grader fordi her er det både vann og is! All tilført energi fra neden eller oven går bare til faseoverganger i denne sonen. Faseoverganger "bruker"/"trenger" energi uten at temperaturen endres. Men på det tidspunktet indikert med gul pil, er all is smeltet, så nå blir tilført energi (fra lagene under) til økt temperatur. Samtidig har det blitt kaldere og sannsynligvis frost på 5 cm, og temperaturen er stabil (det ligger ~1-2 cm snø over) i 2-3 døgn, før alt i det laget har smeltet (grønn pil), og temperaturen skyter i været pga varm utetemperatur. Utregning av hvor dypt tela stikker, med nøyaktighet på cm-nivå betinget på målingene krever en termisk simulator med faseoverganger. Ikke et kveldsprosjekt.

Får du avstand til bakken under snøen, eller får du bare støy fra sensoren? Siden det finnes proff-varianter av ultralydsensorer der jeg ser teksten "Recommended for snow level measurement" så er det litt snodig hvis ultralyden fra din hc-sr04 er helt ubrukelig (går gjennom snøen)

Jeg gjetter på at for å få presisjon nok til å detektere dette snølaget, må du peke sensoren loddrett ned, og montert på en pinne som stikker 1-2 meter ut fra garasjen.

Fikk endelig stappet inn en temperatursensor på fornuftig sted i tanken. Som nevnt i post nr 3 i tråden, så går det jo an å få noe på innsida av isolasjonen. Jeg tok derfor en innkapslet D18B20 ferdigmontert på 3 meters kabel (125 grader står det skrevet på kabelen, så da tror jeg den tåler det), og ved hjelp av en pinne dyttet den 30-40 cm oppover på innsiden av isolasjonen. Tanken sin termostat er stilt på 75 grader, den sensoren regner jeg med sitter i bunn sammen med termostaten, for dette nye termometeret har målt opp til 81 grader. Temperaturmålingen (rødt under) fra tanken er veldig brukandes! Dette kan man gjøre analyser på om man vil, og jeg kan gjøre litt marginale forbedringer på algoritmen som optimaliserer. WAF synker litt når det blir synlig hvem som hadde billigst dusj av klokkeslettene 07:00 og 17:00

Fikk 4 stk BME280-sensorer fra aliexpress i dag. Måler fukt, temp og trykk, og ventilasjonsaggregatet er en het kandidat til å bli oppgradert fra bare fukt og temp i hvert kammer til å også ha trykk i hvert kammer (4 stk). Om de blir installert avhenger av om jeg har lyst å bytte ut de Sensirion SHT31-D som jeg lurer på om er bedre på fuktmålinger enn BME280. I tillegg har jeg to stk BME680 på vei i posten, i tillegg til fukt,temp og trykk måler den sensoren også luftkvalitet.

For snømåling så bør jo sensoren stå langt ute på et jorde, og være upåvirket av alle objekter rundt (turbulens som legger snøen ujevnt). For snømåkebehovsensor så er kanskje kravene litt mindre.. Har du tenkt på korrigering av distanse etter temperatur? Lydhastigheten endrer seg noe med temperatur. Hvis lyden skal 2.5 meter ned og 2.5 meter tilbake igjen, så vil en temperaturforskjell på 10 grader gi sånn ca 9 cm forskjell etter et raskt overslag.

'gradient' antar jeg betyr den deriverte av fuktigheten. Verdien vil være avhengig av hvilken enhet som antas - det har du kanskje sjekket? (er rh-tallet mellom 0 og 100, eller mellom 0 og 1, og hva er tidsenheten?) Hva er samplingsfrekvensen din på fuktsensoren - sender den målinger flere ganger pr. minuttet eller sjeldnere. For at en gradient med lengde 60 sekunder (antar jeg) så bør du ha flere målinger innenfor det minuttet. Jeg tror jeg har ca. hvert 15. sekund på mine fuktsensorer i ventilasjonsanlegget. Vær også obs på at støy i fuktmålingene kan trigge noen falske 'bad_fukt-rising'.

Regner du med du kobler snøsensoren din til vekkerklokka, som da vekker deg et kvarter tidligere om det er kommet noen cm snø? (i påvente av automatisert snømåking)