berland

Har du noe særlig vinkel utover på den sensoren? Jeg klarer ikke se at den peker noe annet enn loddrett.. Hvor langt ute er punktet på bakken den treffer, relativt vertikalen? (og hva heter de RJ45-modulene, finner de ikke på aliexpress. Den hilink-trafoen fant jeg, og har bestilt noen av. Trygg nok til at du kobler den på 230V?)

Det har de, derfor er de tatt med i plottet over. Maksbesparelse pr. døgn er på 2 kr og 50 øre for noen få dager med stor variasjon (nedi 20 øre om natta), og det er ikke utenkelig at en slik variasjon kan bli normalt, hjulpet av en eller annen form for effekttariff. Da snakker vi ihvertfall rundt tusenlappen i året. Bruker man mer varmtvann er det selvsagt mer å spare.

Etter drøye 2 måneder, så har jeg gjennomsnittlig estimert døgnbesparelse på 51 øre (!)

Det er mye "støy" i form av datagrums fra disse sensorene når man gjør kontinuerlige målinger, selv innendørs (eller er det bare mine slike sensorer?). Tullemålepunkt må man klare fange opp i programvare og fjerne, så om fallende snøflak rett foran sensoren gir utslag, så gjør det neppe saken verre. Eksempel fra yr sine nylige snømålinger: (jeg skal ikke spekulere i hva som er feilkilden her, men noe er det nok..)

For vamtvannstank har jeg denne tråden: I høst har det vært utrolig kjedelig lite variasjon i strømprisene, både med tanke på utslag og når på døgnet det er billig. Så i høst har min algoritme ikke klart å tjene noe mer enn en enklere algoritme som f.eks. "ha på varmen de to billigste timene mellom 00:00 og 06:00", og pga. tilstrekkelig varmekapasitet har det heller aldri vært kaldt dusjvann om kvelden, verken med min algoritme eller denne enklere.

Data fra første 9 dager. Om ikke nyttig, så har datastrømmen ihvertfall klart å holde meg underholdt så lenge. Tidspunkt for nedgraving er helt til venstre. De første timene er temperaturene preget av å være nedgravd med nedkjølt jord, men den nederste er mest påvirket av fjellet under og ble fort varm og stabil. Varmen fra "dypet" kom så sakte oppover. På 20 cm dyp (gul) så tok det hele 3 døgn før den var stabil i forhold til varmen nedenifra. Etter 3-4 døgn ser jeg at den nederste sensoren (blå) mister varme. Det ser ikke ut som om den mister varme oppover, da det ikke er en slik trend på 35 cm (turkis), hypotesen min er at kulden kommer fra at fjellet er eksponert mot kald luft 5 meter til siden for hullet. 30. november trodde jeg noe var galt, siden temperaturen plutselig faller helt ned til 80 cm dyp. Så slår deg meg at det har jo begynt å regne. 20 cm dyp merker nedkjøling 2 timer før 80 cm dyp. Interessant at 20 cm dyp mister temperatur når det regner, når lufta over er 10 plussgrader. Dette kommer nok av det er tele mellom 0 og 20 cm som forsvinner på få timer. Siste døgn har temperatur i fjellet begynt å ta seg opp igjen, dette er nok fordi fjellet selv ikke har gått like mye ned i temperatur som den blå sensoren. Rød og oransj er på vei opp igjen i temperatur raskere enn blå, dette er nok på grunn av stor temperaturdifferanse ned til blå akkurat nå, høyere enn likevekt tilsier (det er 15 cm mellom alle sensorer, så ved likevekt vil det være like mange grader mellom hver kurve, innenfor noe plasseringsnøyaktighet).

import metpy.calc as mcalc from metpy.units import units # https://www.engineeringtoolbox.com/enthalpy-moist-air-d_683.html # Specific heat for air c_pa = 1.006 # kJ/KgC # Specific heat for water vapor c_pw = 1.84 # kJ/kgC # Evaporation heat h_we = 2501 # kJ/kg def enthalpy(temp, rh, pressure): """Temperatur er i Celsius, rh er i tall mellom 0 og 100, trykk er i millibar. Returenhet er i kJ/kg """ return c_pa * temp + hum_ratio(temp, rh, pressure) * h_w(temp) def h_w(temp): """Specific enthalpy of water vapor - the latent heat""" return c_pw * temp + h_we def hum_ratio(temp, rh, pressure): """Mixing ratio (water content), returned as kg/kg""" saturated_mixing_ratio = mcalc.saturation_mixing_ratio(\ pressure*units('mbar'), temp*units('degC')).magnitude return rh/100. * saturated_mixing_ratio # Eksempel ved 5.4 grader celcius, 91% RH og 997 mbar lufttrykk: print("Entalpi: {:.2f} kJ/kg".format(enthalpy(5.4, 91, 997))) print("Fuktinnhold: {:.2f} g/kg".format(1000 * hum_ratio(5.4, 91, 997))) Dette er utdrag av noe kode jeg kjører hvert 15. sekund på de fire temp+rh-sensorene i ventilasjonsaggregatet. Husets fuktproduksjon er da bare differansen i fuktinnhold for to luftstrømmer. Se bildet i dette innlegget for eksempel:

Hvis jeg titter på døgnmiddel av husets fuktproduksjon, så ligger det ganske fint mellom 0 og 2 (skalen er til høyre!), med en liten dip i sommer (da var vi borte!) Så jeg påstår at fuktproduksjonen jeg måler(/regner ut) stort sett er koblet til menneskelig aktivitet i huset, og ikke i særlig grad påvirket av vær. I sommer ser jeg at fuktproduksjonen var negativ, det er sikkert når huset har tørket av lite mennesker og tørt vær, og så kommer det kanskje fuktig vær som et tørt hus sluker litt fuktighet fra. Når noen dusjer, observerer jeg typisk en slik situasjon: hvor det er ingen heksekunst å klare plukke ut hva som skjer klokka 23:32. Jeg har satt grensene for 3.5 for å gå fra normal til høy ventilasjon, og 2.5 for å gå fra høy til normal igjen (litt hysterese).

Har ikke denne Airthings-sensoren selv..

Styring av baderomsvifte krever noe mer kompleksitet enn dette. Du må ta hensyn til hva som er normal luftfuktighet inneværende dag, dette kan variere mye. Jeg har klart å lage en ganske god algoritme for å fange opp dusjing utifra RH-målinger. Den har aldri tatt feil på et helt år, men den er muligens mer kompleks enn nødvendig. Jeg har temp og RH-sensor i tilluft og fraluft-kammerene i ventilasjonsanlegget. Utifra disse fire tallene beregner jeg husets fuktproduksjon (gram vann pr kg luft som går gjennom ventilasjonen). Dette ligger stabilt under 2 gram vann/kg luft når ingen dusjer, men får en spike etter ca 30 sekunds dusjing, og da går ventilasjonsanlegget på maks. Dette krever altså to RH+temp-sensorer, og det krever en grunnventilasjon som går hele tiden. Hvis man skal klare seg med bare en sensor, og ingen grunnventilasjon, så tipper jeg at man må lage noe kode som hele tiden beregner hva som er normal temp+rh for gjeldende dag. Jeg ville sannsynligvis basert det på duggpunkt. Så må man klare skille mellom spike i duggpunkt (som betyr at man dusjer) og bare vanlig "drift" i duggpunkt, som bare betyr at det blir fuktigere av andre årsaker (utevær f.eks.). Det vil hjelpe litt hvis du har en annen temp+rh-sensor et annet sted i huset som du kan gjøre løpende sammenligninger med.

Takk for delingen! Jeg kan komme med noen forbedringsforslag 1: Gjør det uavhengig av JSON, her tilfører det lite av nytte, det gjør det hele bare mer vanskelig 2: Dropp bash-scriptet. Hvordan? Du definerer deg 4 MQTT-topics for hver "item", istedet for å pakke alle dataene inn som JSON inn til ett "topic". Python-scriptet skriver direkte ut til hvert av disse fire "topic"-ene. Hvis du bruker paho-mqtt biblioteket i Python, så lar du Python publisere direkte på MQTT. Da kan bash-scriptet skrotes, og du kjører python fra cron. Dette vil også gjøre det enklere for andre smarthus-systemer å bruke koden, da det er ikke sikkert at alle smarthus-systemer har muligheten til å gjøre en JSONPATH-operasjon på en MQTT-payload for å finne fram til akkurat det tallet man var ute etter. Men, for din del er det ingen stor grunn til å fikse på dette før noe eventuelt brekker. Det virker jo slik også!

ADS1115 er nå oppe og går på brødbrett. Den gir jevnere avlesninger (mindre støy) enn direkte-inngangen til ESP8266, det er tydelig, men jeg har fortsatt rapportert trykk som et "rolling mean" av de siste 50 avlesningene (brukte de 300 siste avlesningene før). ADS1115 får bare 3.3V strøm, siden den ellers kunne belastet GPIO-inngangene (I2C) på ESP8266, med 5V og da bruker jeg en spenningsdeler fra 5V ned til 3V fra trykkmåleren før den går inn på A0 på ADS1115. Mister vel noe nøyaktighet på det, men det er ikke signifikant her.

Jeg har Fibaro Dimmer 2 i en spotkasse sammen med 12V trafo og 12V led-pære (bra uten Fibaro bypass, men enda neddimmet med bypass koblet inn, på 230V-sida). Skal vel egentlig ha servicebryter også på slikt, men det har jeg ikke, og heller ikke mulighet til, men når elektriker gjorde dette byttet han bare eksisterende Gira Funkbus dimmeenhet med en Fibaro.

Jeg har en snikende følelse av at jeg en gang måtte korrigere en av mine tilbake til 10 Ω, uten at jeg skjønte hvordan den hadde klart å bli endret.

Du har sjekket hvilken motstand temperatursensoren er stilt inn på i termostaten?

Det betyr at termostaten har muligheten til å sende ut reléstatus, men den vet ikke uten videre hvor det skal sendes - så for at Domoticz skal få det med seg må du si fra til termostaten at reléstatus skal sendes tilbake til z-wave kontrolleren (eventuelt kunne du sendt det til en annen termostat eller veggplugg, som da ville vært på samtidig som termostaten). Samme med temperaturene fra luft, ekstern og gulv-sensor. I versjon 1.92 sendes de på hver sine assosiasjonsgrupper, 3, 4 og 5.

Funker som sagt fint på mine. Meldingen om reléstatus kommer på assosiasjonsgruppe 2, så det må typisk settes opp eksplisitt.

Takk, jeg trengte ikke se lenger (men utifra setningen din kunne man tro at også produsenten frarådet det..) Det er utvilsomt en viss dose trøbbel med oppgraderingen, to av mine er fortsatt bricket, av uviss årsak. Trøbbelet med luftsensoren som er påvirket av intern oppvarming i enheten tror jeg ikke har noe med oppgraderingen å gjøre, det er bare mer synlig etterpå. Selve oppgraderingen er også noe skikkelig knot, og kan kreve mye tilpasninger på smarthusprogramvaresida etterpå (og det krever at den nye firmwaren er støtta). Noen rapporterer om ustabile enheter. Jeg har ikke sett noen problemer på de tre jeg har oppgradert.

Hvor står det?

(jeg har en python-kode som vasker mange av mine målte tidsserier for spikes, virker mot data som ligger i InfluxDB - interessert?)

Ny komponent på nettbrettene i huset (HABPanel) Dybden er regnet ut med lineær interpolasjon mellom de målte datapunktene. Selvsagt langt fra millimeternøyaktighet..

https://www.maxbotix.com/Ultrasonic_Sensors/MB7334.htm Trolig veldig brukandes, men været kan få ødelegge mange SR-04 for den prisen.

60 cm? Jeg leser at den har opp til 400 cm rekkevidde. Det er også ca. samme enhet som jeg bruker på garasjeporten og bil-tilstedeværelse i garasjen, der husker jeg oppgitt rekkevidde var 500 cm. Trolig ikke dumt å peke den litt utover for å prøve måle uforstyrret av veggen, og korrigere med Pytagoras i etterkant. Mister kanskje en cm nøyaktighet. (jeg har tenkt på snødybdemåler selv i dag, siden snømengdepåvirker teledybde i hagen..)

Trolig mest det siste, et visst nerdebehov. Jeg vil kunne se fra målte data når telen går i hagen til våren (også om det er tele f.eks. mellom 35 og 50 cm, men ikke over).

I konkurranse med (fuktig) jord tror jeg ikke det tynne, hule og plastbelagte alu-røret gir noe signifikant bidrag til varmetransport. Ingen grunn til å tro det heller fra første døgns målinger. Fortsatt ikke nådd likevekt etter nedgraving (spesielt 35 cm-måleren).