psv021

Det var jo merkelig, hadde ingen problemer med det. Du kan jo sende de en mail og høre: [email protected]

TIps til de som vil kjøpe: Jeg sleit litt med å få betalingen gjennom. Til slutt kontaktet jeg Hydreon, og fikk dette svaret: Dette fungerte fint, og betalingen gikk gjennom da. Jeg valgte billigste fraktalternativ.

Vet ikke om det blir så mye debatt når valget står mellom IDlock og Yale Doorman, hvorav kun IDlock kan gjøre det du planlegger å gjøre (koble den til en interface med z-wave). Eller har jeg glemt noe nå angående Yale Doorman? Det er vel fortsatt bare mulig å koble den til Verisure? Edit: Relevant link, selv om den begynner å bli litt gammel: http://www.duppeditten.com/blog/smart-locks-for-scandinavian-doors

Tja, nå kjenner jeg ikke FutureHome i detalj, men litt av konseptet er vel at de skal støtte "alt mulig". Nå støtter de selvsagt ikke "alt mulig", i alle fall ikke enda, men konseptet skulle jo tilsi store muligheter for custom løsninger. La oss si at noen definerte et sett med "standard" komponenter for en hjemmeboende & pleietrengende, så burde det være mulig å lage en plug&play type pakke med f.eks FutureHome som kjerne (eller andre)...

FutureHome har vel siktet seg inn på det markedet. Jeg betviler ikke at det finnes et enormt marked der. Det BURDE i alle fall finnes et enormt marked der. Spør du meg burde vi investere betydelig i teknologiutvikling for akkurat dette. Pensjonsbølgen er vel allerede på vei, og kommende generasjon kommer ikke til å ville bo på gamlehjem...

Vanlig måte, tror jeg? Har ikke forsøkt rescan. Har egentlig ikke tenkt på dette som et stort problem. Noden fungerer som den skal, men jeg får slike feilmeldinger hver gang jeg starter HS3 (kommer i oppstartsloggen)...

Jeg får også denne meldingen. Hos meg refererer Node-nummeret til en Fibaro Multisensor.

Ja, skalering er nok trikset. Jeg har laget hele interfacen i 1:1. Har irritert meg bittelitt over dette med zoom, kan man si...

Lager (stående) interface til mobilen, som har 2550 px eller noe slikt i høyden. Laptopen har 768px i høyden, og selve editoren er jo enda litt mindre enn det. Dermed ser jeg jo bare en fjerdedel av skjermen jeg designer. Det er utrolig klønete å jobbe med. I HStouch-manualen står dette: ...men jeg får ikke dette til å gi noe som helst mening... Finnes det en måte å zoome ut (altså se hele skjermen man designer, selv om den har høyere oppløsning enn skjermen man bruker?)

Lot loggingen stå på for se litt hvordan den fungerte her om dagen. Så kom det en regnbyge... Nå er loggingen avslått

Ja, det er varmeelement. Det er svakt og vil, i følge bruksanvisningen, ikke smelte store mengder is. Får se til vinteren hvordan det fungerer, spesielt dersom det rimer på den over natten.

Takk for hyggelig tilbakemelding. Jeg har, som du ser av bildene, bare koblet begge inngangene sammen. Så jeg får samme signal på begge to samtidig (men trenger jo bare 1 av dem, selvsagt). Man kan ha temperaturmåler koblet til universalsensoren, og man kan også bruke utgangene som du skriver. Jeg vil også tro at for eksempel et billig skumringsrelé kunne ha blitt koblet til den andre inngangen, som et eksempel. Eller en ringeklokke. Hvis man trenger en bryter for [et eller annet] ute kunne man ha koblet det til den andre inngangen, og dermed slippe unna med en enkel mekanisk bryter som oversettes til z-wave via universalsensoren. Siden dette er en regnsensor, kunne det være aktuelt å bruke den til å styre takvinduer. Automatisk lukking av takvinduer høres for meg ut som et "bedre" bruksområde enn mitt (men jeg har ingen motoriserte takvinduer). Den vil være godt egnet til det. Etter noen dagers bruk ser jeg at den er utrolig følsom. En eneste liten dråpe, og den gir utslag.

Har montert en regnsensor som forteller meg når det begynner å regne. Sensoren var såpass billig, og oppsettet er såpass enkelt, at dette kanskje også kan være interessant for andre. Dermed blir det en kjapp tutorial med utgangspunkt i hva jeg har gjort. Det behøver på ingen måte være den beste måten å gjøre det på, så kommentarer er velkomne! Kjapp bakgrunn og rasjonale for å bestille en regnsensor fra USA... Har to verandadører uten overbygg så når det regner (og det gjør det jo), regner det rett inn på parketten dersom dørene står åpne. Ønsket meg derfor en regnsensor som kunne gi varsling når det begynner å regne. Vurderte flere løsninger, da det finnes en del regnmålere på markedet (Netatmo, Oregon, div NoName, osv). Problemet er at selv om disse nok fungerer greit for å måle regn over tid, er de basert på "Tipping Bucket"-prinsippet og har dermed en terskel før de reagerer. Dermed vil ikke fungere til mitt bruk. Jeg trenger varsel når første dråpen faller. Jeg vurderte også et oppsett med en lekkasjedetektor, men det tankeeksperimentet strandet også ganske kjapt. Etter litt research og gode tips på Facebook, gikk jeg til innkjøp av en RG-11 regnsensor fra Hydreon. Den ankom, og ble liggende i boksen en stund, men fikk i helgen endelig somlet meg til å montere den. Hadde egentlig tenkt å vente noen uker før jeg skrev dette, for å se hvordan dette fungerer over tid. Men jeg vet jo at alt er glemt om 2 uker, så det er like greit å bare få det ned. Så dette blir med et par forbehold Utstyr Regnsensor, Hydreon RG-11 Fibaro Universal Binary Sensor, FGBS-321 Koblingsboks Ledninger Kinderegg Annet som man trenger, f.eks. sammenkoblinger (jeg har bare brukt sukkerbiter) Kostnader RG-11: ~700 kr. (USD59 + USD27.50 (frakt) + NOK300 (fortolling)) Universal sensor: ~500 inkl frakt Div: kr 200 Totalt: 1400,- Her antar jeg at man fra før detekterer om dørene er åpne eller ikke. Dersom det ikke er tilfelle, trenger man en dørsensor i tillegg. Kilder http://www.openremote.org/display/docs/OpenRemote+2.0+How+To+-+Sense+rain+-+Hydreon+RG-11+Rain+Sensor+using+Fibaro+Universal+Sensor http://manuals.fibaro.com/content/manuals/en/FGBS-321/FGBS-321-EN-A-v1.01.pdf http://hydreon.com/wp-content/uploads/sites/3/2015/documents/rg-11_instructions.pdf Jeg har i store trekk fulgt oppskriften fra OpenRemote i den øverste lenken for selve koblingen av RG-11 og FGBS-321 Jeg bruker Homeseer, men jeg antar at prinsippene her vil fungere på tvers av ulike systemer. Sammendraget RG-11 leveres klar til bruk. Dvs den er tett, og underdelen fungerer også som monteringsbrakett. Trenger bare koble ledningen og skru den opp. I grove trekk skal både RG-11 og Universalsensoren forsynes med lavvolt likestrøm (jeg har brukt 12V i mitt oppsett), og RG-11 skal gi en puls på en egen krets som kobles som input til universalsensoren. Så når RG-11 gir en puls, skal universalsensoren reagere og videresende via z-wave. RG-11 har flere ulike innstillinger, ulik følsomhet, osv, som jeg kommer tilbake til. RG-11 gir signal ved å bryte én krets (Normally Closed), og lukke en annen (Normally Open) når den detekterer regn. Når en av disse kretsene loopes innom Universal Sensor, vil endringen plukkes opp og signalet videresendes av FGBS-321. Universal Sensor håndterer både NO og NC. Jeg har brukt NO (Normally Open) i mitt oppsett. Det er nok mange måter å gjøre dette på, men jeg koblet på denne måten: Edit 17. jan 2017. NB! Mulig korreksjon, se post i tråden fra bruker mk1 black limited (17. januar): "(...) i den guiden du linker til står det at COM på RG11 skal til GND, ikke 12V som du har på tegningen." Her er det viktig å understreke at dette på ingen måte er noe jeg KAN eller er god på, så her famler jeg meg frem. Fungerer greit hos meg med dette oppsettet. Mulig skissen min er "feil" ift hvordan en med relevant utdannelse ville ha tegnet den osv, men det får stå sin prøve. Slik så det ut i et tidlig testoppsett. Jeg koblet opp alt, og testet ut ulike innstillinger både på RG-11, universalsensoren og i Homeseer. For å få RG-11 til å trigge et signal, kan man dryppe en dråpe vann på den, eller rett og slett bare puste litt på glasset slik at det dugger litt. RG-11 har en LED som lyser, og man hører også tydelig lyd, når et signal trigges. Dermed er det lett å vite om sensoren har sett en dråpe eller ikke. RG-11 fungerer på samme måte som regnsensorer typisk montert i frontruten på biler: Den sender lys, som reflekteres i glasset, og detekterer dette lyset igjen med mottakere. Når vann treffer glasset endres refleksjonsegenskapene til glasset, og dette detekteres av RG-11. Det betyr at den er svært følsom, helt ned til enkeltdråper. Så kan man stille inn hvor høy terskel den skal ha før den faktisk sender et signal ut. Her er brukermanualen ganske god, og gir en OK oversikt over ulike "programmer" man kan bruke. For å programmere RG-11, finnes 8 binære knapper (switcher) på selve kortet i RG-11. Ulike kombinasjoner av disse gir ulike programmer/innstillinger. Man kan f.eks. stille inn RG-11 til å fungere som en "tipping bucket" (henviser til andre regnmålere der en liten bøtte fylles opp før den vipper rundt - vippen detekteres, og når man vet hvor stor bøtten er og hvor mange ganger den har blitt fylt opp, vet man hvor mye det har regnet) (det er denne teknologien som i praksis gjør det umulig for meg å bruke tradisjonelle regnmålere til å detektere første dråpe, fordi regnmåleren vil ikke vite at det regner før bøtten vipper minst én gang.). RG-11 kan brukes i dette moduset og emulere ulike bøttestørrelser. Hvor nøyaktig det blir, tør jeg ikke spå. Man kan bruke RG-11 til å gi konstant output når det regner - nyttig f.eks. dersom man vil kjøre en motor, eller la være å kjøre en motor, kun når det regner. RG-11 vil f.eks. være mulig å bruke for å automatisk lukke takvindu når det regner. Eller dersom man samler takvann på en hytte, kan RG-11 brukes for å åpne til regntank når det regner, men lukke når det ikke regner. I det hele tatt finnes mange mulig bruksområder, hvorav noen er beskrevet i manualen. Derfra er det vel bare fantasien som setter grenser. Anyway, i mitt oppsett har jeg valgt å bruke program nr 6: "Drop Detector". I denne modusen vil RG-11 sende et signal når den detekterer en vanndråpe. Årsaken til at jeg valgte dette programmet, og ikke f.eks. "Tipping bucket" er et resultat av prøv-og-feil. Jeg hadde problemer med å trigge Universal Sensor i "Tipping bucket"-programmet. I "Tipping bucket" sendes 50 mS-pulser, mens i "Drop detector" sendes pulser på 200 mS eller lengre. Min teori er at Universal Sensor ikke plukket opp de korteste signalene, mens de litt lengre signalene trigger den. Det er et element av spekulering her, da det er mange flere potensielle feilkilder ute og går. Jeg har foreløpig satt opp RG-11 til "default"-verdiene innenfor dette programmet ("Normal drop threshold"), men følsomheten kan justeres både opp og ned. Montering Nå er oppsettet klart, og det er på tide å montere. Strøm kommer innefra i mitt tilfelle, og jeg sniker ledningen ut gjennom en dør. Ideelt sett ville jeg også ha hatt universalsensoren innendørs, men etter en liten WAF-runde og andre vurderinger endte jeg opp med å montere begge sensorer sammen utendørs. Brukte en standard koblingsboks ment for utemontering (Clas Ohlson, 149,-) til dette. I tillegg la jeg universalsensoren inne i en tett, gul spesialbeholder med åpne/lukkemekanisme som kan kjøpes på dagligvarebutikker. Irriterende nok leveres disse kun med et lag sjokolade rundt... Mellom RG-11 og Universalsensor skal det gå 4 ledere. Brukte en 4-leders telefonledning (Clas Ohlson) til dette. Den er ikke beregnet for utebruk, så vi får se hvordan den tåler tidens tann... Slik ser montasjen ut: ...og slik ser den ut ferdig montert på vegg ute: Bruk i Homeseer Primærformålet mitt var å gi varsling dersom det regner og en av, eller begge, dørene står åpen. Fra før har jeg dørsensor på verandadørene, så Homeseer vet om dørene er lukket eller åpne. Jeg har også et veggmontert nettbrett som kjører HSTouch, og som fungerer som primær varslingsplatform i huset (så går varsling på epost dersom ingen er hjemme). På dette tidspunktet er Universalsensoren inkludert i nettverket og kjent av Homeseer. Jeg har også definert om jeg bruker Normally Closed eller Normally Open. Dette gjøres ved å sette parameter 3 eller 4, avhengig av hvilken input man bruker (universalsensoren har 2 stk) til 0 eller 1. Se manualen for detaljer. Jeg har også slettet noen unødvendige child-devicer som dukker opp når man inkluderer universalsensoren i nettverket. I tillegg definerer jeg en virtuell device som skal flagge om det regner eller ikke. Årsaken til at jeg bruker en virtuell device, er at det da skapes et ledd mellom universalsensoren og variabelen som skal brukes til videre aksjoner. Det gjør oppsettet litt mer robust samt at det gir litt mer fleksibilitet med et ekstra ledd i rekken mellom deteksjon og aksjon. Jeg definerer eventer for å slå av og på "DetRegner". "DetRegner" slås på umiddelbart når et signal kommer fra RG-11, men jeg legger inn en forsinkelse på når den slås av, for å unngå vakling. Jeg ønsker ikke å ta med meg pulsene fra RG-11 helt ut til der varslingen skjer. Da blir det fort mye varsling... Det gjør det også mulig å stille inn varslingen skikkelig før varslingen faktisk aktiveres. I oppsettet nå har jeg satt forsinkelsen til 30 sekunder, så får vi se hvordan dette fungerer over tid. Så kan man tenke at det er en rar antagelse å si at dersom det ikke kommer en dråpe på 30 sekunder så betyr det at det har sluttet å regne. Og det er helt korrekt, det betyr jo ikke det. Men i denne sammenhengen er det OK. I et tenkt tilfelle der det ikke ble noen reaksjon på første alarm, er det greit å få en ny etter en liten stund. Så det er OK at systemet begynner på nytt etter rundt 30 sekunder, som i praksis, ved lett regn, vil gi opp mot et minutt pause mellom alarmene. Nå har jeg en virtuell device som flagger om det regner eller ikke. Den skrur seg på når en dråpe treffer RG-11, og den skrur seg av igjen dersom ingen dråper har truffet RG-11 de siste 30 sekundene. Neste steg er å bygge alarmer som skal trigges av endringer i den virtuelle devicen. For dette formålet lager jeg også en virtuell device. Det behøves i prinsippet ikke kun for alarmens del, men jeg bruker denne for visuell varsling i HStouch. Jeg bruker den også for å trigge ekstern kommunikasjon dersom det ikke er noen i huset. Denne devicen har en transparent pixel som bilde for "OK", og en rød trekant som bilde for de andre tilstandene. I HStouch vil den dermed være usynlig inntil en alarm er trigget. Men, primært er det eventer som brukes for alarm og varsling: Litt omvendt rekkefølge på bildet ser jeg, men det er 2 eventer relatert til hver dør. Eksemplet her er verandadør, 1.etg. Den ene eventen trigger alarmen, mens den andre resetter den. Alarmen skal trigges dersom døren står åpen og det begynner å regne. Selve triggeren er at det begynner å regne, mens kriteriet/tilstanden er at døren er åpen. I mitt oppsett vist her: Dersom det begynner å regne, og døren er åpen, skru på alarmdevicen og kommuniser alarmen. Dersom alle disse kriteriene, mot formodning, skulle oppfylles og ingen er hjemme (ingen hører alarmen), kan egne eventer plukke opp at alarmen trigges mens "tilstede-status" er "borte", og reagere med å sende mail. Jeg skriver mot formodning, for man får også en alarm dersom dørene står åpne når man forlater huset. Så i praksis skal det aldri inntreffe (Murphys Lov, sier du? Ikke hørt om...). Det konkluderer egentlig denne beskrivelsen av oppsett av RG-11 sammen med FGBS-321. Ble litt lengre tekst enn jeg hadde tenkt dette. Dersom noen har tanker om andre bruksområder for en dings som sier fra når første regndråpe faller er det alltid interessant. Også supert dersom andre vil supplere med annen kunnskap om hvordan det kunne blitt gjort annerledes eller bedre. Til slutt, og litt på siden, om programmeringsvaner og hvorfor oppsettet er som det er hos meg Det kan virke litt rart å bruke kriteriet "has a value that is not equal to Door Closed" i stedet for bare "equal to Door Open", som i prinsippet ville være det samme. Årsaken er at det i teorien kan opptre flere tilstander her. Siden dette er en alarm, er holdningen min at det er bedre med en alarm for mye enn en for lite. "...not equal to" i stedet for "equal to" er en god måte å gjøre oppsettet mer robust. Da snur man kravet slik at man favner mye bredere, enn om kravet er "equal to". Jeg bruker konsekvent egne eventer for å spille av alarmlyd, og for å snakke, i stedet for legge kommunikasjonen direkte inn som hendelser i de enkelte eventene. Det er flere årsaker til dette. For det første er det praktisk å kunne bytte ut en lydfil kun ett sted, og slippe å lete gjennom alle alarmer som benytter seg av samme lydfil. Alle slike fellesfunksjoner er greie å isolere ut i en egen event. Når det gjelder snakking er det også praktisk å isolere i en egen event, da den trenger egne kriterier. Hos meg er det f.eks. ikke alltid interessant at HomeSeer snakker. Alle snakke-eventer sjekker mot en virtuell device, "HomeSeerSnakker". Når denne er av, blir det ingen snakking. For å kalle en spade for en spade; det ER litt kleint med en engelsksnakkende datastemme av og til... Jeg forsøker alltid å sjekke om eventen er nødvendig eller ikke i kriteriene. Dersom en event skal sette device X til verdi 1, er det greit å sjekke om device X faktisk har en verdi som ikke er lik 1. Da unngår man at eventen kjøres og setter device X til verdien den allerede har. Det betyr ingenting når det er snakk om 10 "unødvendige" events, men all erfaring tilsier at 10 eventer i dag fort kan bli 1000 eventer i morgen. For virtuelle devicer har det neppe stor betydning, men for faktiske devicer kan det bli mye unødvendig trafikk på nettet av slikt. Spesielt dersom en slik event blir gående i loop. Jeg har opplevd dette et par ganger, og en enkelt slik loop tok effektivt ned hele mitt nettverk. Forstod ikke hvorfor ting ikke fungerte, før jeg oppdaget at HS-loggen hadde 100.000 hendelser and counting... Uansett, håper dette kan være nyttig for noen! Vis full oppføring

Nå er det jo snakk om tredjepartsutviklede plug-ins, stort sett, så de har ikke sett så mye til de pengene man har brukt på å kjøpe HS. Så kan man diskutere hvor dyrt det egentlig er da. Personlig syntes jeg komponentene svir betydelig mer i lommeboka... Så er det vel alltid en kost/nytte-vurdering når man kjøper noe. Når det er snakk om selve hjernen i smarthuset er det kanskje ikke her man bør knipe mest igjen. Da er det kanskje heller noen komponenter man kan klare seg uten

Ja, jeg mistenkte også det. Det begrenser jo interaksjonen litt, spesielt mtp reaksjon på alarm. Leste et tips på et annet forum som jeg tenker litt på av og til, uten at jeg har gjort noe med det ennå: Koble en lampe eller en annen strømforbruker via en SmartPlug OG en Fibaro PowerMeter. Smartplug kan aktiveres direkte ved alarm via Verisure. Powermeter vil da plukke opp strømforbruket. Dermed vet HS3 umiddelbart. Kan brukes til både alarm, og hjemme/borte-styring. Da får man en mer umiddelbar kommunikasjon, men det har litt preg av jalla over seg da (selv om det er vanskelig å mislike et så løsningsorientert opplegg ). Vedkommende som kom med dette tipset brukte dette til hjemme/borte-status, og hadde microbølgeovnen koblet til SmartPlug/PowerMeter. Slo to fluer i en smekk: Slo av microen når han var borte, og fortalte det samtidig til HS3.

@lilfire, den anbefalte pollefrekvensen på 1 time: Gjelder den alarm også? Altså tar det (maksimalt) en time fra alarm utløses til HS3 får meldingen?

Har du en guide til HStouch på blokka etter hvert også?

Montert en regnsensor og koblet til HS for å få alarm når det begynner å regne og verandadøren står åpen. Liker ikke regn på parketten...

Er det noe kødd med den sensoren, eller har du over 20 varmegrader i kjøleskapet??

Jeg er også skeptisk... Med en million forbehold som plassering av temperaturmåleren (din), bruksmønster, etc, selvsagt. Men det virker kanskje som om skapet ikke måler temperaturen skikkelig. Altså, det blir for varmt før kjølemotoren slår inn, og det blir for kaldt før den stopper. Bør ligge å vake rundt 4 grader, ideelt sett (vi har vårt på 3 grader nå, liker melken iskald). Det er noen tydelige sykluser da, er det relatert til bruken? Eller er det skapet som slår seg på hver 7. time eller noe slikt? Satt akkurat og mekket med noen temperaturmålinger, der det ene kjøleskapet også lå i samme regnearket. Vedlagt bilde. Merk at jeg måler én gang i timen, så det blir en liten oppskalering ift dine målinger. Spikene i dataene er på ettermiddagene når det først typisk puttes inn (varme) matvarer, lages middag, så kveldsmat, osv. Så stabiliseres temperaturen litt utpå kvelden før det kommer en ny liten spike ved frokost. Det er altså relatert til bruksmønster. Min måler ligger litt over midten av skapet (i høyde). Edit: Ser nesten ut som en hjerterytme Edit2: De syklusene i dine data kan jo faktisk se ut som om er relatert til kuldetap. Altså at skapet ikke isolerer godt nok. Så når motoren slås av, begynner temperaturen umiddelbart å stige (ganske raskt)....

Neida, de er syltynne. Ingen lekkasje, i alle fall ikke noe som er merkbart. Så vidt den lager en liten bulk i tettelisten. Legger ved et bilde tatt på utsiden av fryseren, akkurat der ledningen går inn i skapet.

Njaei kan ikke si at jeg har reagert på det. Den jeg har hatt i 4 år har jeg kanskje byttet batterier på 2-3 ganger eller noe slikt? De andre kjøpte jeg rett før sommeren, så vi får se hvor lenge de varer. Nå er det "vanlige" batterier i disse, så man må ikke ruinere seg på spesialbatterier når de ryker. Bruker andre sensorer i resten av huset, men fordelen med akkurat disse er den tynne ledningen som gjør at man kan måle i kjøleskap/fryser uten å måtte ha batterier og sender også i fryseren.

Jeg bruker målere fra Clas Ohlson til kjøleskap/frys, som snakker 433 MHz. Tror det er denne: http://www.clasohlson.com/no/Ekstra-temperaturgiver-hygrometer/Pr365123000 De er egentlig tenkt som ekstra-målere, men fungerer fint på egen hånd. De jeg har kommer med ca 2-3 meter lang tynn ledning, så det er ingen problem å legge de fra utsiden og inn. Da sitter batteripakken ute av syne, utenfor kjøl/frys. Den ene har jeg hatt i minst 4 år.

God service av Tronika, for øvrig. De var sikre på at dimmeren var i orden, men sendte meg likevel ny over natten, i tilfelle. Jeg endte opp med å kjøpe den de sendte meg i stedet for å sende den tilbake når den egentlige feilen ble oppdaget, så det ble vinn-vinn.