Søk i nettsamfunnet

Nå skal vi ikke kuppe tråden her helt, men borte og ferie er helt uavhengig av "morgen/dag/kveld/natt"-status. Bruker gjerne klokkelsett og utendørs/innendørs lysnivå, men de bryr seg ikke om hvilken tidsstatus huset har.

Hei godtfolk, Jeg er ganske ny i feltet, og har hatt et såkalt kjedelig, fjernstyrt hus ei stund. Automatikken står på agendaen fremover nå, og støtte på et problem her om dagen. Har satt opp tidsstatus, MDEN, og bruker dette for det det er verdt. Om morgenen ønsker jeg at taklys på bad skal gå på 30% ved bevegelse. Så fort samboeren står opp, ønsker hun 100% lys i taket + speillys på, uansett om jeg er der eller ei. Lyset går av etter 15 min uten bevegelse. Tenker da at den enkleste løsningen foreløpig må være å kunne bruke lysbryteren for å overstyre denne automatikken. Har Fibaro Dimmer 2 på taklyset, og Fibaro Double Switch 2 på speillys. Finnes det noen måte å skille om lyset er slått på fra bryteren, eller fra bevegelsessensoren? På Fibaro Dimmer 2 har jeg kun enkel impulsbryter som er koblet inn på bryter 1. Er klar over at det finnes en bryter 2, som man brukes, men ønsker i hovedsak ikke doble brytere på alle dimmerne i huset. Hvis det er en måte å skille om bryteren er trykket inn, eller om hjernen slår på bryteren, så er vi kommet langt, men er redd for at det ikke er det? Jeg prøvde å løse det slik, uten suksess: Lys på 30% IF Bevegelse bad changes and becomes BEVEGELSE AND IF Tidsstatus is MORGEN AND IF Taklys bad has a value not equal to ON THEN Set Taklys bad to 30% THEN Remove delayed action for Taklys bad THEN Remove delayed action for Speillys bad Lys av etter 15 min IF Bevegelse bad changes and becomes INGEN BEVEGELSE AND IF Tidsstatus is MORGEN THEN Set Taklys bad to OFF after a delay of 15 min THEN Set Speillys bad to OFF after a delay of 15 min Lys på 100% IF Taklys bad had its value set to OFF AND IF Tidsstatus is MORGEN AND IF Taklys bad has a value equal to 30% THEN Set taklys bad to ON THEN Set speillys bad to ON For å unngå at bevegelsessensoren tar over styringen igjen når lyset er satt til 100%, la jeg inn en condition på dette i første event. Problemet her i siste event, er jo at når lyset er på 30%, og man trykker på bryteren, så går lyset av. Da er ikke condition 30% aktiv lengre, og lyset forblir avslått. Noen som har en løsning for nybegynneren i andre enden her, og evt kan forklare litt rundt dette?

Er det mulig for homeseer å registrere forskjell på om lyset blir slått på/av med sensor eller på/av manuelt med bryter? Har satt opp tidsstatus for natt ved at lys på bad blir slått av etter kl 21, og dermed kan jeg ikke har automatisk lysstyring etter kl 21 for da vil nattmodus aktiveres

Igjen passer det å gjenta at det kan være en fordel å faktisk lese HS-skolen. Jeg har eventer som setter tidsstatus. "Morning" bestemmes av klokkeslett og om det er arbeidsdag eller fridag. (Holder på med et lite prosjekt for å gjøre noe med dette...) "Day" bestemmes av utelyset hvis alarmen er på, eller faktisk manuelt når det er fridag (Når "Day" blir satt går alle rullegardinene opp, og det er greit å sikre seg at alle har nok klær på før man gjør det) "Evening" settes av når jentenes rullegardiner går ned etter kl. 18:30. "Night" settes enten manuelt eller hvis det ikke er bevegelse på ca. 1 time i huset OG TVen er av. Det er også lov å søke på forumet. Jeg har også et script som bestemmer om det er arbeidsdag eller fridag, og det i kombinasjon med @Guahtdim sin plugin så klarer du nok å dekke alle alternativer. Du kan jo legge til så mange hensyn som du bare vil. "Partallsuke" f.eks. eller "google kalender sjekk" om en entry inneholder "kid hos meg"

Kan jo løses på mange måter, men jeg har løst tilsvarende problemstillinger ved at husets virtuelle tidsstatus (Natt, morgen, dag etc) også kan ha verdien "tidsstyring slått av". Dersom denne er gyldig slutter huset å veksle tidsstatus gjennom døgnet (dette er en "group condition" i eventene som får tidsstatusen til å veksle gjennom døgnet). Dermed kan alt varme og lysstyring følge døgnrytme, men en annen logikk tre inn når vi drar bort på ferie.

Prøver meg litt frem med tidsstatus for natt. Ønsker tilbakemelding hvordan andre gjør det og om jeg er helt på jordet

Har open løysing mellom stove og spisestove, med separat dimmer for kvart "rom". Pga. at romma i praksis ikkje er delte, har eg ein Fibaro multisensor (bevegelse, temp, lysstyrke) som står akkurat i overgangen, og som dermed detekterer bevegelse i begge romma. For å skru på lyset har eg laga events som dimmer lyset til passande lysstyrke alt etter tid på dagen (morgon, dag, kveld eller natt). Har éitt event som blir trigga av bevegelse, vurderer lysstyrken og trigger tre nye events slik: Dei tre påfølgande events ser slik ut: Altså blir alle tre eventa trigga "MANUALLY", men kun éitt av dei skal jo gå vidare, sidan Tidsstatus kun har ein status av gangen. Tidsstatus ser for øvrig slik ut, og denne devicen oppdaterer seg som den skal. Problemet er dette: Alle tre events ser ut til å gå gjennom kvar gong, uansett kva for tid på døgnet det er. Når vurderingseventet blir trigga, køyrer altså dei andre tre heile løpet. Resultatet er at det er heilt vilkårleg kva slags lysstyrke som blir satt. Loggen ser slik ut - alle tre events blir trigga "på rappen", i dette tilfellet var det morgen/dag som vant og lyset vart satt til 80% og 50%. I dette tilfellet vart eventet trigga manuelt i HomeSeer, men resultatet er det samme ved trigging av bevegelse. Det kan virke som om at det oftast er morgen/dag som står igjen som vinnar, men ikkje alltid. Tips til kva i all verden som kan vere feil? Takk for alle gode forslag!

Vera har innlagt house modes - Home, Away, Night, Vacation. Den siste bruker jeg når jeg skal være borte over mange dager, og kan senke temperaturen, samt kjøre en plugin som leker med lysene så det ser ut som man er hjemme. Kan noen ta et eksempel på bruk av tidsstatus kontra å sette kalendersettings(når på døgnet og hvilke dager) på hver scene? Sikkert lurt, har ikke tenkt sånn på det før.

Ja, min tilnærming er enkel, har kun fire modi for tidsstatus: Morning Day Evening Night Forkortes "MDEN". Kombineres med en alarm-status "Home" & "Away". Klart man kan ha flere, men det spørs om det har noe for seg. Hadde veldig detaljert tidligere, men startet fra scratch og endte opp med MDEN.

Lager denne tråden i håp om at flere av automasjonsguruene på forumet vil dele sine erfaringer. Etter jeg begynte med Homeseer for halvannet år siden, oppdaget jeg raskt av det lønte seg å ha forskjellige "hus-modus". (Kan jeg foreslå operasjonsmodus?) I mitt system ble det tre forskjellige modus; hjemme, borte og natt. Det dekker jo mange behov, men når man begynner i legge inn diverse klokkeslett inn i noen dusin med eventer, blir det fort rot. I tilegg, når man har automatiske lys kan det dukke opp problemer hvis man vil stille de manuelt av og til. @DiderikFrom ser ut til å ha en smart løsning på dette her som "disabler" automatiske frem til neste dag, hvis de er blitt tuklet med. Jeg har plukket opp at bla @Moskus og andre har en virtuell device, kalt "tidsstatus" i flere tråder, som jeg vil tro forenkler en del oppsett av events. @Automatikk ser ut til å bruke 8 forskjellige hus-statuser. Hva fungerer/fungerer ikke for ditt oppsett?

Helt enig! Min NodOn remote kommer opp helt likt og har da laget minst en event per funksjon. Du kan også knytte funksjon mot tid/tidsstatus osv. slik at samme knappen skrur på taklampen til forskjellige nivåer avhengig av hvor mørkt det ca. er. Husk å bruke 'changes and becomes'

Hvordan ser "Status Graphics" til Tidsstatus ut? På skjermdumpen viser du Tidsstatus1 (altså Tidsstatus med 1 bak, det er vel en annen device?)

Jeg har satt opp en virtuell tidsstyringsdevice med verdiene 0-3... Etter noen dager, en uke kanskje eller noe, så fungerer det ikke lenger, og kona sender melding om at ho helst vil ha vanlig bryter på badet... Da er devicen blitt tilbakestilt til vanlig On/Off.. Så jeg laget en ny vr device tidsstatus1, alt fungerte fint etter å ha oppdatert eventene. Så etter en noen dager... kona vil ha vanslig bryter og tidsstatus er on eller off.... Hvorfor skjer dette??

OK. Tidsstatus Virtuell Device er opprettet Event er laget. Kan jeg kjøre alle forandringene i 1 event, eller må jeg ha 4 stk, en for hver "tidssone"? Jeg ser at når jeg lager en Event, så får jeg disse valgene på tid. Men om jeg har en AND IF, får jeg mange flere valg på tid...? Noen av disse hadde kanskje vært bedre å bruke for IF. Tenker f.eks. om man har hatt et strømbrudd, så ønsker man den skal velge riktig tidspunkt på døgnet når den starter, og ikke bare vente til neste trigger, som er ved neste tidssone... Så tenker da at BEFORE THIS og AFTER THIS, må jo fungere til dette... Tanker??

Tror du må til med en virtuell device, og sjekke i bevegelses-eventet ditt om denne er på. Så kan du sette opp en ny regel som skrur av denne virtuelle devicen hvis lyset blir satt til noe annet enn 80% ( men høyere enn 0/Off). Bare husk å lag et passende event som skrur på den virtuelle devicen igjen, f.eks. ved bytte av Tidsstatus eller et klokkeslett.

Takk! Takk! Døgnet har det med å bli startet på ny når klokken slår 00:00. Dermed vil en regel som har conditions som dette: ... AND IF the Time is after 23:00 AND IF the Time is before 06:00 aldri inntreffe for et klokkeslett innenfor et døgn ikke kan både være "høyere enn" 23:00 og "lavere enn" 06:00. Nei, du må dessverre splitte det opp. Men jeg kan spare deg litt tid: Du trenger ikke å sette opp "etter kl 2200 og før kl 2359" og "etter kl 0000 og før kl 0600. Det holder med "etter kl 2200" og "før kl 06:00". Døgnets null-punkt er kjent uansett. MEN: Når det er sagt så er det jo et spørsmål om du kan komme rundt det på en enklere måte, spesielt hvis du skal ha flere eventer med slike hendelser. Hvis du ikke har det allerede, kan det være greit å begynne å tenke på hvordan dagssyklusen ser ut i heimen. Som nevnt i del 6 har jeg "Morgen, "Dag", "Kveld" og "Natt" (andre velger å dele det enda mer opp). Jeg antar att "mellom 22:00 og 06:00" er typisk for noe som skjer på natt. Hvis du ikke har en Tidsstatus-device som beskrevet over, kan du bruke en enkel device som sier om det er "natt eller ei". Lag en virtuell device og kall den natt. Lag så to små eventer som skrur den på og av. IF the Time is 22:00 THEN Set device Natt to On og IF the Time is 06:00 THEN Set device Natt to Off Dermed kan du bruke ... AND IF device Natt is On istedenfor det mer tungvinte (og ikke-fungerende): ... AND IF the Time is after 23:00 AND IF the Time is before 06:00 Du kan også bruke "Natt" (eller Tidsstatus om du vil) som en trigger direkte. For de som har vært innom objekt-orientert programmering, så kan de sikkert være med å bekrefte at dette mer å foretrekke enn en haug med eventer som trigger på samme (eller forskjellige) tidspunkter. Det blir mer dynamisk og vesentlig enklere å endre senere. Jeg lurte også på dette, men jeg finner ikke den muligheten her...

Aha, men det er ikke slik bruken av "Else" fungerer. Siden det er to forskjellige Actions, så er det også mest hensiktsmessig å lage to forskjellige Events. Men sett dem i en gruppe (jeg kaller min "MDEN", for "Morning, Day Evening, Night"), så er det enklere å finne tilbake. Har du imidlertid samme Actions, men vil ha to forskjellige triggere (eller samme trigger, men conditions før og etter midnatt), kan du ha dem i samme Event: IF Bevegelse trigget AND IF Time is after 22:00 OR IF Bevegelse trigget AND IF Time is Before 07:00 THEN Device Tidsstatus = Night

Endelig, litt automatikk! For at heimen faktisk skal bli smart, må heimen gjøre som du vil uten at det er du som gjør det. Alt vi har gjort til nå er å legge til rette for fjernstyring, som i "weee, jeg kan styre lyset fra mobilen" (noe som man blir lei av ganske raskt), men HomeSeer har en fantastisk motor for automatikk. Og den skal vi nå benytte oss av. Bli kjent, med begrepet Event Ordet Event er selvfølgelig engelsk, det mest passende norske ordet er vel "hendelse". Jeg bruker ordet "Event" på norsk, akkurat som jeg bruker ordet "Device". Et Event er delt i to: Det har en trigger (med en eller flere conditions) og en eller flere actions. Trigger En trigger er det som setter Eventet i gang. Som i "kjør dette eventet når klokka slår 06:00" eller "kjør dette eventet når lyset i gangen blir skrudd på". Condition En condition (altså "betingelse") hører til en trigger. De begrenser triggeren, som i: "kjør dette eventet når klokka slår 06:00 men bare på en mandag" eller "kjør dette eventet når lyset i gangen ble skrudd på men bare hvis klokken er 17:00 eller senere, det har regnet 3 mm OG ingen har ringt på døra på 4 timer". Action En action (en "handling") er det som faktisk skal skje. F.eks. at man skrur på av eller på et lys, kjører et annet event eller et script. I utgangspunktet ganske enkle verktøy som man, med litt trening, kan bruke på ganske så avanserte måter. Event-oppsett Vi går til View -> Events. Hvis vi ikke har lagt til noen eventer, blir vi bedt om å navngi vårt første Event. betyr selvfølgelig "Legg til". Det kan være legg til et Event til gruppa, en trigger/condition eller en action. kjører Eventet slik det er nå, helt uten å ta hensyn til eventuelle conditions. deaktiverer eller aktiverer et event. sletter et event, en trigger/condition eller en action. kopierer eventet slik det er. utvider eller minimerer alle Events eller conditions. indikerer at du nå kun viser basis-valg, trykk denne for å se: avanserte valg. MERK: Det er en god idé å minimere triggers og actions når man er ferdig med dem, for da får man opp eventuelle feilmeldinger. Hvis et en trigger, condition eller action ikke lar seg minimere, så er det et tegn på at noe er galt eller at linjen ikke er ferdig konfigurert. Vi kan velge en trigger (i den blå linjen, øverst). Her er trigger-kategoriene som kommer med en helt vanlig HS-installasjon: En trigger-kategori har flere tilhørende triggere: For actions er lista lenger: Igjen har Actions flere underalternativer. Hvis man velger "Control a Device" får man opp valg om å velge en device å controllere. Når man har gjort det, blir alle CAPI-verdiene (se del 6) listet opp. ... så hvordan ser et Event ut? I sin enkleste form, kan det se slik ut: Dette leser vi som at kl. 06:00 blir lyset satt til 17%. Organisering Ved siden av Event-navnet, kan man velge en Type hvis man ønsker det. Ved siden av Typen, kan man flytte eventet til en annen gruppe (eller lage en ny). Grunnen til dette er at man skal finne igjen eventene sine. Når man har 5-10 stykker så er det enkelt. Når det er 300 så er det verre. Jeg sorterer forskjellige typer Eventer i forskjellige grupper (jeg bruker ikke "Event Types" så mye). Men det gjør det overraskende fort å finne frem i eventene. Skal du kikke på eventet som styrer lyset i gangen basert på en bevegelsessensor? Kikk i gruppa "Bevegelse". Hva med lyset som går automatisk i ferien? Kikk i gruppa "Automatisk (ferie)". Hva med de trådløse bryterne? "Brytere". Og hvordan får dere beskjed tilbake? "Notifikasjoner". "Referencing Device(s)" er veldig hendig hvis du skal finne eventene som styrer eller blir styrt av en bestemt device. Si at et lys skrur seg på og av når det ikke skal, og du lurer på hvorfor. Da er det bare å velge devicen i Referencing Device(s), så blir Eventene dine filtrert til å kun vise de som har med denne devicen å gjøre. MERK: Hvis du bruker scripts vil disse komme med i filtreringen, det er kun de som har en Device spesifisert i en ren Event trigger, condition eller action. Når du er ferdig med filtreringen er det en god vane å trykke på "Show All" etterpå... Blant de mest brukte: Bevegelsessensor I utgangspunktet er det enkelt. Vi velger bevegelsessensoren som device, og velger CAPI-verdien "Motion" som trigger. I dette eksempelet vil jeg styre lyset på badet i kjelleren. De to nederste linjene er enkle. Den ene skrur lyset PÅ, og den andre skrur lyset AV etter 10 minutter. Så langt er alt vel. Men hva skal vi med "Remove Delayed Device Actions"? Jo, "lyset av etter 10 minutter" blir nettopp det; en "Delayed Action". Disse Delayed Action'ene blir kjørt etter den aktuelle forsinkelsen. Når bevegelsessensoren blir trigget, så blir alle eventuelle slike Actions (som i vårt tilfelle skrur lyset av) fjernet først. Sluttresultatet er at lyset blir værende på så lenge det er bevegelse i rommet, men blir skrudd av etter 10 minutter hvis bevegelsen stopper (for da blir IKKE denne Delayed Actions fjernet). På toalettet i 1. etg er det både en bevegelsessensor og en magnetsensor på døren. Det kan jo selvfølgelig løses med å lage to forskjellige eventer, men siden det er det samme som skal skje uavhengig av trigger, så velger vi heller at Eventet skal ha flere forskjellige triggere. For å få til flere triggere trykker du på den grønne -knappen, men istedenfor "AND IF" til venstre, velger man "OR IF". Dette blir en ny trigger. I tillegg har jeg her noen conditions som gjør at dette Eventet kun kjører når det ikke er natt (dvs. på morgen, dag og kveld). Da jeg skulle lage Natt-versjonen av dette Eventet, kopierte jeg det ved å trykke på -knappen. Så endret jeg condition fra "Device Value Not Equal To" til "Device Value Equal To". Lys-kontrollen ble endret fra "On" (som betyr 100%) til "Dim 10%". Planlegging Hvis du ikke har sett på Events før nå, så vil det sannsynligvis begynne å demre for deg at det er enormt med muligheter her. Og det har du helt rett i! Hemmeligheten for å finne frem i kaoset er rett og slett å prøve seg frem, og å spørre hvis det feiler og du ikke finner ut hvorfor. Andre her har lang erfaring med å sette opp Eventer og har sikkert gjort samme feil selv som du har gjort. Alt koker ned til en ting: Logikk. Dette er programmering. Men istedenfor å måtte bruke et tastatur og kode hver linje, er de aller fleste valgene bakt inn i programmet. Hvis man installerer plugins, vil disse også kunne ha sine egne triggere og actions. Det man må gjøre når man skal begynne å automatisere er å planlegge. Det er veldig fristende å kaste seg hodestups ut i eventene, men man sparer seg mye frustrasjon hvis man tenker gjennom problemstillingen først. Hvorfor skal noe skje? Er det en bestemt hendelse? Som at noen kommer hjem? Eller står opp av senga? Eller noe så enkelt som et bestemt klokkeslett på bestemte dager? Hva er det egentlig som skal skje? Er "Når det er morgen skal ganglyset komme på" det eneste som skal skje? Skal det skje noe annet? Er det andre betingelser man skal ta hensyn til? Skal ting skje i en bestemt rekkefølge? Har jeg nok inn- eller ut-data? Hvordan kan man eventuelt ordne det? Eller kan jeg komme rundt det på en akseptabel måte? Hvis jeg vil koke kaffe når jeg står opp, så må jeg faktisk vite når jeg står opp OG jeg må ha muligheten til å koke kaffen. Hvis man alltid står opp kl 07:00 så kan det være så enkelt som å ha en trigger 15 minutter før. Alternativt kan en bevegelsessensor i gangen på utsiden av soverommet være en indikasjon på det ("HVIS bevegelse AND Time is after 07:00"), eller man kan (etter hvert) bruke en sensor, som et smart sengelaken. For å trakte kaffen kan man bruke en vanlig kaffetrakter med en plugin-modul, eller man kan integrere en smartere kaffetrakter. For å sette opp en dagsrutine, må man faktisk tenke gjennom hva man gjør gjennom en vanlig dag, og hvordan man ønsker at det skal være. Del dagen i små biter og ta del for del, så blir problemstillingen mindre og mer overkommelig. Utenom det er det bare å sette i gang! Eventer justeres etter hvert, og automatikken bygges ut fortløpende. Event-valg Hvis man kikker under selve Event-definisjonen (under actions), så ser man teksten "Options". Utvider man denne menyen, ser man dette: Her gis det enda flere valg til hvordan eventet skal trigges. "Priority Event" skal visstnok prioritere denne triggeren, som navnet antyder, men jeg har ikke hørt om situasjoner som blir løst av å bruke denne. "Include in Powerfailure Recovery" kan være grei hvis du har Eventer som MÅ kjøre etter at HS har blitt avsluttet av et strømbrudd (ikke blitt avsluttet skånsomt). Jeg bruker ikke noen av disse. "Security" er derimot hendig. Hvis man velger "Time is 14:00" som trigger, og huker av Security, vil dette eventet få en ny random tid etter hver gang det er blitt kjørt. Tiden som brukes til å gi intervallet den nye random-tiden er valgt fra, definerer du under valget Setup -> "Security Offset +/- (minutes)". Hvis du velger 15 minutter, så kan altså neste trigger for eventet være alt mellom 13:45 og 14:15. Veldig hendig hvis du ikke vil at det skal se ut som om hverdagen avsluttes kl 23:00 hver ukedag hele året uansett. "Remove This Event After Trigging" er det sjeldent man bruker på eventer man definerer selv. Men de er mer praktiske når vi kommer til Scripting. Alle Actions som er satt som delayed, blir i praksis et nytt event med dette valget huket av. "Do Not Log This Event" velger jeg på de fleste Eventer. Jeg trenger ikke fylle opp loggen min med unyttig informasjon om eventer som gjør som de skal. "Cannot Re-Run for XYZ time" er også veldig viktig. Av og til kan en trigger bli trigget svært raskt etter hverandre, og det kan gi litt kluss for Action'ene som dermed kjører nesten dobbelt. F.eks. kan man ha flere RFXtrx433-tranceivere, og alle disse vil motta et signal fra en Nexa-bryter. Dermed vil et event som bruker Nexa-bryteren som trigger kjøre flere ganger etter hverandre. Da er det lurt å sette "Cannot Re-Run For" til minimum 1 sekund. Betingelser for Actions En trigger har betingelser/conditions, men det hender at det er praktisk å ha betingelser for Actions også. F.eks. har jeg en dørlås (en Danalock v1) som man kan "låse" så mange ganger den vil. Det vil si: Hvis jeg velger "Lock" vil kjøre motoren uansett hvor mye den er låst fra før, og resultatet er at tannhjulene i låsen "pusser tenner". Jeg er redd det går ut over låsen i lengden. (Dette gjør heldigvis ikke Yale-låsen vår, eller ID-lock). Men jeg vil jo fremdeles at huset skal låse døra når vi går ut eller legger oss HVIS dørlåsen er opplåst! Da ville det vært praktisk å ha conditions for Actions, men HS støtter ikke dette direkte. Man må bruke et ekstra Event. Først definerer vi selve eventet som låser døren. Merk at det er en MANUELL trigger, men MED conditions. ... som vi leser som "lås døren hvis den ikke er låst". I Eventet som kjøres når nattmodus blir satt, eller som kjøres når hus-alarmen blir aktivert, så legges denne Action'en inn. Det viktige her er avkryssingen for "Run Only If Other Event Conditios are TRUE", som du muligens må trykke på det røde -ikonet for å få se. Dermed blir kjellerdøren kun låst hvis den ikke er låst fra før! Dette gir også andre muligheter. Jeg vil at huset skal gjøre en vurdering av Lux-nivået i stua, og justere lyset deretter. Dette skal vurderes hver gang Lux endrer seg, eller når vi kommer hjem (alarmen blir skrudd av) eller at det blir morgen (Tidsstatus skiftes fra Natt til Morgen), altså er det tre forskjellige triggere. Dette kunne jeg løst med å lage 6 forskjellige eventer, og bruke en haug med (forholdsvis like) conditions for hvert event. Det blir mye å holde styr på, så jeg samlet triggere i et Event, og Lux-vurderingene i to andre (fordi de har forskjellige Actions, et skrur lyset på et annet skrur det av). Først selve vurderingen for å skru lyset av: ... eller på: Og så et event for når disse vurderingene skal skje: Som du ser er det ingen overlapping i Lux i eventene som skrur det av eller på, så de to øverste kan ikke bli trigget samtidig. Og en bonus er at siden jeg sjekker om lyset er "På" eller "Av" istedenfor hhv. "ikke Av" eller "ikke På", så vil ikke automatikken ta over hvis jeg har dimmet lyset i stua. Og som du ser i devicen "Settings - Options - Automatisk lys i stue" kan jeg overstyre automatikken med en virtuell device. At Lux-vurderingen gjøres når Tidsstatus blir "Morning" er hendig både om sommer og om vinter. Hvis det er behov for lys, så får du det. Men om sommeren kan det jo fint være lyst nok til å slippe det når klokka er 06:30. Den skarpe leser vil legge merke til at det ikke er definert hva som skal skje hvis Lux blir målt til å være mellom 300 og 650, og svaret er enkelt: Det skal ikke skje noe, og det er faktisk et poeng at det er et relativt stort sprik mellom av eller på, ellers ville en lettskyet himmel være nok til at lyset omtrent ville flimre (avhengig av hvor ofte Lux-verdien blir lest). Tips: Bruker du slike virtuelle devicer for å styre når automatikken skal virke, så er det alltid en god idé å lage et Event med en gang som setter devicen tilbake til det du mener skal være standard-verdien. "Settings - Options - Automatisk lys i stue" blir hos oss satt til "On" når huset går i natt-modus. Da er det bare å begynne å automatisere. Vanne plenen, anyone? FAQ Q: Hva er forskjellen på triggerne "Device Changes and Becomes" og "Device Was Set To"? Er de ikke like? A: Nei, de er ikke helt like. Hvis et lys er på, og det får et nytt PÅ-signal vil "Device Was Set To" bli trigget, mens "Device Changes And Becomes" ikke blir. For at "Device Changes And Becomes" må verdien være en annen før triggeren skjer. Q: Hva er forskjellen på triggerne "Device Has Been X for Exactly Y time" og "Device Has Been X for At Least Y time"? Vil det ikke være best å bruke "At Least"? A: Som trigger er "At Least" veldig skummel å bruke, et eksempel på hvor galt det kan gå kan du lese her. Grunnen er forskjellen i hvordan disse to trigges. Nå er det litt mer komplisert enn det som forklares her (og sjekkene skjer oftere enn det), men la oss for enkelhets skyld si at alle eventer blir sjekket hvert sekund. Normalt skal et Event kun kjøre en gang, med mindre det er gode grunner til å kjøre det flere ganger, men sannsynligvis aldri så ofte som hvert sekund Et event med trigger "Taklys has been OFF for exactly 2 minutes" vil kun kjøre den ene gangen, og ferdig med det. Et event med trigger "Taklys has been OFF for at least 2 minutes" vil kjøre etter 2:00, 2:01, 2:02... altså hvert sekund etter at det har gått to minutter siden taklyset ble skrudd av. Jeg tror grunnen til at folk ofte velger "at least" istedenfor "exactly" er at "exactly" høres så usikkert ut. "Oi, tenk hvis den bommer! Da vil jo 'At Least' være sikrere". Og det finnes tilfeller der "At Least" absolutt kan være nyttig, den er spesielt hendig som en condition. Men hvis du vil bruke den som trigger, så må du legge til andre conditions som gjør at eventet ikke trigges i det uendelige... Q: Hvordan kan jeg endre rekkefølgen på Actions (eller conditions)? Må jeg slette alle Actions og legge dem til i rett rekkefølge? A: Neida, det er rett og slett "drag and drop". Minimer action/condition, og ta tak i den. Dra de så oppover (eller nedover) og slipp når du er fornøyd. Dette kan du ikke gjøre med en touch-skjerm, dessverre, man trenger en mus. Oppsummering Da har vi vært gjennom en kort introduksjon til automatisering, tro det eller ei. Og ja, nå begynner det å dra seg til! Event-motoren er utmerket, og det er enkelt å redigere og utvide etter hvert. Event-motoren er et kraftig verktøy, som tidvis kan være ganske komplisert. Det vil ta seg litt tid å lære, men når man har satt opp de første Eventene (og navngitt dem skikkelig), så går det raskt å sette opp flere. Øvelse gjør mester! Det er mulig vi kommer tilbake til eventer senere, det er litt avhengig av tilbakemeldingene. Savner du noe, gi lyd i kommentarfeltet under. HomeSeer-skolen har tidligere dekket innkjøp (del 1), oppsett (del 2), Z-wave-konfigurasjon (del 3 og del 4), 433 MHz utstyr (del 5) og device-håndtering, -sortering og -oppsett (del 6). I del 8 skal Fermate vise oss hvordan vi kommer i gang med HStouch Designeren! Vis full oppføring

Endelig, litt automatikk! For at heimen faktisk skal bli smart, må heimen gjøre som du vil uten at det er du som gjør det. Alt vi har gjort til nå er å legge til rette for fjernstyring, som i "weee, jeg kan styre lyset fra mobilen" (noe som man blir lei av ganske raskt), men HomeSeer har en fantastisk motor for automatikk. Og den skal vi nå benytte oss av. Bli kjent, med begrepet Event Ordet Event er selvfølgelig engelsk, det mest passende norske ordet er vel "hendelse". Jeg bruker ordet "Event" på norsk, akkurat som jeg bruker ordet "Device". Et Event er delt i to: Det har en trigger (med en eller flere conditions) og en eller flere actions. Trigger En trigger er det som setter Eventet i gang. Som i "kjør dette eventet når klokka slår 06:00" eller "kjør dette eventet når lyset i gangen blir skrudd på". Condition En condition (altså "betingelse") hører til en trigger. De begrenser triggeren, som i: "kjør dette eventet når klokka slår 06:00 men bare på en mandag" eller "kjør dette eventet når lyset i gangen ble skrudd på men bare hvis klokken er 17:00 eller senere, det har regnet 3 mm OG ingen har ringt på døra på 4 timer". Action En action (en "handling") er det som faktisk skal skje. F.eks. at man skrur på av eller på et lys, kjører et annet event eller et script. I utgangspunktet ganske enkle verktøy som man, med litt trening, kan bruke på ganske så avanserte måter. Event-oppsett Vi går til View -> Events. Hvis vi ikke har lagt til noen eventer, blir vi bedt om å navngi vårt første Event. betyr selvfølgelig "Legg til". Det kan være legg til et Event til gruppa, en trigger/condition eller en action. kjører Eventet slik det er nå, helt uten å ta hensyn til eventuelle conditions. deaktiverer eller aktiverer et event. sletter et event, en trigger/condition eller en action. kopierer eventet slik det er. utvider eller minimerer alle Events eller conditions. indikerer at du nå kun viser basis-valg, trykk denne for å se: avanserte valg. MERK: Det er en god idé å minimere triggers og actions når man er ferdig med dem, for da får man opp eventuelle feilmeldinger. Hvis et en trigger, condition eller action ikke lar seg minimere, så er det et tegn på at noe er galt eller at linjen ikke er ferdig konfigurert. Vi kan velge en trigger (i den blå linjen, øverst). Her er trigger-kategoriene som kommer med en helt vanlig HS-installasjon: En trigger-kategori har flere tilhørende triggere: For actions er lista lenger: Igjen har Actions flere underalternativer. Hvis man velger "Control a Device" får man opp valg om å velge en device å controllere. Når man har gjort det, blir alle CAPI-verdiene (se del 6) listet opp. ... så hvordan ser et Event ut? I sin enkleste form, kan det se slik ut: Dette leser vi som at kl. 06:00 blir lyset satt til 17%. Organisering Ved siden av Event-navnet, kan man velge en Type hvis man ønsker det. Ved siden av Typen, kan man flytte eventet til en annen gruppe (eller lage en ny). Grunnen til dette er at man skal finne igjen eventene sine. Når man har 5-10 stykker så er det enkelt. Når det er 300 så er det verre. Jeg sorterer forskjellige typer Eventer i forskjellige grupper (jeg bruker ikke "Event Types" så mye). Men det gjør det overraskende fort å finne frem i eventene. Skal du kikke på eventet som styrer lyset i gangen basert på en bevegelsessensor? Kikk i gruppa "Bevegelse". Hva med lyset som går automatisk i ferien? Kikk i gruppa "Automatisk (ferie)". Hva med de trådløse bryterne? "Brytere". Og hvordan får dere beskjed tilbake? "Notifikasjoner". "Referencing Device(s)" er veldig hendig hvis du skal finne eventene som styrer eller blir styrt av en bestemt device. Si at et lys skrur seg på og av når det ikke skal, og du lurer på hvorfor. Da er det bare å velge devicen i Referencing Device(s), så blir Eventene dine filtrert til å kun vise de som har med denne devicen å gjøre. MERK: Hvis du bruker scripts vil disse ikke komme med i filtreringen, det er kun de som har en Device spesifisert i en ren Event trigger, condition eller action. Når du er ferdig med filtreringen er det en god vane å trykke på "Show All" etterpå... Blant de mest brukte: Bevegelsessensor I utgangspunktet er det enkelt. Vi velger bevegelsessensoren som device, og velger CAPI-verdien "Motion" som trigger. I dette eksempelet vil jeg styre lyset på badet i kjelleren. De to nederste linjene er enkle. Den ene skrur lyset PÅ, og den andre skrur lyset AV etter 10 minutter. Så langt er alt vel. Men hva skal vi med "Remove Delayed Device Actions"? Jo, "lyset av etter 10 minutter" blir nettopp det; en "Delayed Action". Disse Delayed Action'ene blir kjørt etter den aktuelle forsinkelsen. Når bevegelsessensoren blir trigget, så blir alle eventuelle slike Actions (som i vårt tilfelle skrur lyset av) fjernet først. Sluttresultatet er at lyset blir værende på så lenge det er bevegelse i rommet, men blir skrudd av etter 10 minutter hvis bevegelsen stopper (for da blir IKKE denne Delayed Actions fjernet). På toalettet i 1. etg er det både en bevegelsessensor og en magnetsensor på døren. Det kan jo selvfølgelig løses med å lage to forskjellige eventer, men siden det er det samme som skal skje uavhengig av trigger, så velger vi heller at Eventet skal ha flere forskjellige triggere. For å få til flere triggere trykker du på den grønne -knappen, men istedenfor "AND IF" til venstre, velger man "OR IF". Dette blir en ny trigger. I tillegg har jeg her noen conditions som gjør at dette Eventet kun kjører når det ikke er natt (dvs. på morgen, dag og kveld). Da jeg skulle lage Natt-versjonen av dette Eventet, kopierte jeg det ved å trykke på -knappen. Så endret jeg condition fra "Device Value Not Equal To" til "Device Value Equal To". Lys-kontrollen ble endret fra "On" (som betyr 100%) til "Dim 10%". Planlegging Hvis du ikke har sett på Events før nå, så vil det sannsynligvis begynne å demre for deg at det er enormt med muligheter her. Og det har du helt rett i! Hemmeligheten for å finne frem i kaoset er rett og slett å prøve seg frem, og å spørre hvis det feiler og du ikke finner ut hvorfor. Andre her har lang erfaring med å sette opp Eventer og har sikkert gjort samme feil selv som du har gjort. Alt koker ned til en ting: Logikk. Dette er programmering. Men istedenfor å måtte bruke et tastatur og kode hver linje, er de aller fleste valgene bakt inn i programmet. Hvis man installerer plugins, vil disse også kunne ha sine egne triggere og actions. Det man må gjøre når man skal begynne å automatisere er å planlegge. Det er veldig fristende å kaste seg hodestups ut i eventene, men man sparer seg mye frustrasjon hvis man tenker gjennom problemstillingen først. Hvorfor skal noe skje? Er det en bestemt hendelse? Som at noen kommer hjem? Eller står opp av senga? Eller noe så enkelt som et bestemt klokkeslett på bestemte dager? Hva er det egentlig som skal skje? Er "Når det er morgen skal ganglyset komme på" det eneste som skal skje? Skal det skje noe annet? Er det andre betingelser man skal ta hensyn til? Skal ting skje i en bestemt rekkefølge? Har jeg nok inn- eller ut-data? Hvordan kan man eventuelt ordne det? Eller kan jeg komme rundt det på en akseptabel måte? Hvis jeg vil koke kaffe når jeg står opp, så må jeg faktisk vite når jeg står opp OG jeg må ha muligheten til å koke kaffen. Hvis man alltid står opp kl 07:00 så kan det være så enkelt som å ha en trigger 15 minutter før. Alternativt kan en bevegelsessensor i gangen på utsiden av soverommet være en indikasjon på det ("HVIS bevegelse AND Time is after 07:00"), eller man kan (etter hvert) bruke en sensor, som et smart sengelaken. For å trakte kaffen kan man bruke en vanlig kaffetrakter med en plugin-modul, eller man kan integrere en smartere kaffetrakter. For å sette opp en dagsrutine, må man faktisk tenke gjennom hva man gjør gjennom en vanlig dag, og hvordan man ønsker at det skal være. Del dagen i små biter og ta del for del, så blir problemstillingen mindre og mer overkommelig. Utenom det er det bare å sette i gang! Eventer justeres etter hvert, og automatikken bygges ut fortløpende. Event-valg Hvis man kikker under selve Event-definisjonen (under actions), så ser man teksten "Options". Utvider man denne menyen, ser man dette: Her gis det enda flere valg til hvordan eventet skal trigges. "Priority Event" skal visstnok prioritere denne triggeren, som navnet antyder, men jeg har ikke hørt om situasjoner som blir løst av å bruke denne. "Include in Powerfailure Recovery" kan være grei hvis du har Eventer som MÅ kjøre etter at HS har blitt avsluttet av et strømbrudd (ikke blitt avsluttet skånsomt). Jeg bruker ikke noen av disse. "Security" er derimot hendig. Hvis man velger "Time is 14:00" som trigger, og huker av Security, vil dette eventet få en ny random tid etter hver gang det er blitt kjørt. Tiden som brukes til å gi intervallet den nye random-tiden er valgt fra, definerer du under valget Setup -> "Security Offset +/- (minutes)". Hvis du velger 15 minutter, så kan altså neste trigger for eventet være alt mellom 13:45 og 14:15. Veldig hendig hvis du ikke vil at det skal se ut som om hverdagen avsluttes kl 23:00 hver ukedag hele året uansett. "Remove This Event After Trigging" er det sjeldent man bruker på eventer man definerer selv. Men de er mer praktiske når vi kommer til Scripting. Alle Actions som er satt som delayed, blir i praksis et nytt event med dette valget huket av. "Do Not Log This Event" velger jeg på de fleste Eventer. Jeg trenger ikke fylle opp loggen min med unyttig informasjon om eventer som gjør som de skal. "Cannot Re-Run for XYZ time" er også veldig viktig. Av og til kan en trigger bli trigget svært raskt etter hverandre, og det kan gi litt kluss for Action'ene som dermed kjører nesten dobbelt. F.eks. kan man ha flere RFXtrx433-tranceivere, og alle disse vil motta et signal fra en Nexa-bryter. Dermed vil et event som bruker Nexa-bryteren som trigger kjøre flere ganger etter hverandre. Da er det lurt å sette "Cannot Re-Run For" til minimum 1 sekund. Betingelser for Actions En trigger har betingelser/conditions, men det hender at det er praktisk å ha betingelser for Actions også. F.eks. har jeg en dørlås (en Danalock v1) som man kan "låse" så mange ganger den vil. Det vil si: Hvis jeg velger "Lock" vil kjøre motoren uansett hvor mye den er låst fra før, og resultatet er at tannhjulene i låsen "pusser tenner". Jeg er redd det går ut over låsen i lengden. (Dette gjør heldigvis ikke Yale-låsen vår, eller ID-lock). Men jeg vil jo fremdeles at huset skal låse døra når vi går ut eller legger oss HVIS dørlåsen er opplåst! Da ville det vært praktisk å ha conditions for Actions, men HS støtter ikke dette direkte. Man må bruke et ekstra Event. Først definerer vi selve eventet som låser døren. Merk at det er en MANUELL trigger, men MED conditions. ... som vi leser som "lås døren hvis den ikke er låst". I Eventet som kjøres når nattmodus blir satt, eller som kjøres når hus-alarmen blir aktivert, så legges denne Action'en inn. Det viktige her er avkryssingen for "Run Only If Other Event Conditios are TRUE", som du muligens må trykke på det røde -ikonet for å få se. Dermed blir kjellerdøren kun låst hvis den ikke er låst fra før! Dette gir også andre muligheter. Jeg vil at huset skal gjøre en vurdering av Lux-nivået i stua, og justere lyset deretter. Dette skal vurderes hver gang Lux endrer seg, eller når vi kommer hjem (alarmen blir skrudd av) eller at det blir morgen (Tidsstatus skiftes fra Natt til Morgen), altså er det tre forskjellige triggere. Dette kunne jeg løst med å lage 6 forskjellige eventer, og bruke en haug med (forholdsvis like) conditions for hvert event. Det blir mye å holde styr på, så jeg samlet triggere i et Event, og Lux-vurderingene i to andre (fordi de har forskjellige Actions, et skrur lyset på et annet skrur det av). Først selve vurderingen for å skru lyset av: ... eller på: Og så et event for når disse vurderingene skal skje: Som du ser er det ingen overlapping i Lux i eventene som skrur det av eller på, så de to øverste kan ikke bli trigget samtidig. Og en bonus er at siden jeg sjekker om lyset er "På" eller "Av" istedenfor hhv. "ikke Av" eller "ikke På", så vil ikke automatikken ta over hvis jeg har dimmet lyset i stua. Og som du ser i devicen "Settings - Options - Automatisk lys i stue" kan jeg overstyre automatikken med en virtuell device. At Lux-vurderingen gjøres når Tidsstatus blir "Morning" er hendig både om sommer og om vinter. Hvis det er behov for lys, så får du det. Men om sommeren kan det jo fint være lyst nok til å slippe det når klokka er 06:30. Den skarpe leser vil legge merke til at det ikke er definert hva som skal skje hvis Lux blir målt til å være mellom 300 og 650, og svaret er enkelt: Det skal ikke skje noe, og det er faktisk et poeng at det er et relativt stort sprik mellom av eller på, ellers ville en lettskyet himmel være nok til at lyset omtrent ville flimre (avhengig av hvor ofte Lux-verdien blir lest). Tips: Bruker du slike virtuelle devicer for å styre når automatikken skal virke, så er det alltid en god idé å lage et Event med en gang som setter devicen tilbake til det du mener skal være standard-verdien. "Settings - Options - Automatisk lys i stue" blir hos oss satt til "On" når huset går i natt-modus. Da er det bare å begynne å automatisere. Vanne plenen, anyone? FAQ Q: Hva er forskjellen på triggerne "Device Changes and Becomes" og "Device Was Set To"? Er de ikke like? A: Nei, de er ikke helt like. Hvis et lys er på, og det får et nytt PÅ-signal vil "Device Was Set To" bli trigget, mens "Device Changes And Becomes" ikke blir. For at "Device Changes And Becomes" må verdien være en annen før triggeren skjer. Q: Hva er forskjellen på triggerne "Device Has Been X for Exactly Y time" og "Device Has Been X for At Least Y time"? Vil det ikke være best å bruke "At Least"? A: Som trigger er "At Least" veldig skummel å bruke, et eksempel på hvor galt det kan gå kan du lese her. Grunnen er forskjellen i hvordan disse to trigges. Nå er det litt mer komplisert enn det som forklares her (og sjekkene skjer oftere enn det), men la oss for enkelhets skyld si at alle eventer blir sjekket hvert sekund. Normalt skal et Event kun kjøre en gang, med mindre det er gode grunner til å kjøre det flere ganger, men sannsynligvis aldri så ofte som hvert sekund Et event med trigger "Taklys has been OFF for exactly 2 minutes" vil kun kjøre den ene gangen, og ferdig med det. Et event med trigger "Taklys has been OFF for at least 2 minutes" vil kjøre etter 2:00, 2:01, 2:02... altså hvert sekund etter at det har gått to minutter siden taklyset ble skrudd av. Jeg tror grunnen til at folk ofte velger "at least" istedenfor "exactly" er at "exactly" høres så usikkert ut. "Oi, tenk hvis den bommer! Da vil jo 'At Least' være sikrere". Og det finnes tilfeller der "At Least" absolutt kan være nyttig, den er spesielt hendig som en condition. Men hvis du vil bruke den som trigger, så må du legge til andre conditions som gjør at eventet ikke trigges i det uendelige... Q: Hvordan kan jeg endre rekkefølgen på Actions (eller conditions)? Må jeg slette alle Actions og legge dem til i rett rekkefølge? A: Neida, det er rett og slett "drag and drop". Minimer action/condition, og ta tak i den. Dra de så oppover (eller nedover) og slipp når du er fornøyd. Dette kan du ikke gjøre med en touch-skjerm, dessverre, man trenger en mus. Oppsummering Da har vi vært gjennom en kort introduksjon til automatisering, tro det eller ei. Og ja, nå begynner det å dra seg til! Event-motoren er utmerket, og det er enkelt å redigere og utvide etter hvert. Event-motoren er et kraftig verktøy, som tidvis kan være ganske komplisert. Det vil ta seg litt tid å lære, men når man har satt opp de første Eventene (og navngitt dem skikkelig), så går det raskt å sette opp flere. Øvelse gjør mester! Det er mulig vi kommer tilbake til eventer senere, det er litt avhengig av tilbakemeldingene. Savner du noe, gi lyd i kommentarfeltet under. HomeSeer-skolen har tidligere dekket innkjøp (del 1), oppsett (del 2), Z-wave-konfigurasjon (del 3 og del 4), 433 MHz utstyr (del 5) og device-håndtering, -sortering og -oppsett (del 6). I del 8 skal Fermate vise oss hvordan vi kommer i gang med HStouch Designeren! Vis full oppføring

Du kan legge inn flere triggere i et event, det gjør du med å velge "OR IF" istedenfor "AND IF", slik at det kan bli slik: IF Alarm er satt til av OR IF Time = 15:45 AND IF Device Alarm = På AND IF Device Ferie = Ikke ferie OR IF Device Tidsstatus satt til "Morgen" AND IF Device Alarm = Av AND IF Device Ferie = Ikke ferie THEN Set temp "High" Ingen gulvvarme her enda, så det gjør det jo enklere.

Kommer mer av det. Jeg vet ikke hvordan andre gjør det, men jeg viser mitt oppsett... Vel, nå har du jo sett tidsstatus-devicen. Selve devicen er ikke så mye hokus pokus. Eventene kommer vi til.

Godt skrevet, dette er nyttig Skulle gjerne sett fler eksempler fra hvordan du eller andre gjør det hjemme, men da blir det kanskje tungt å forstå for oss nybegynnere? Tenkte litt på tidsstatus-devices som du nevner, eller de andre viruelle devices som du bruker for å overstyre automatikken

Devicehåndtering, organisering og konfigurering Nå begynner vi å få litt utstyr å holde orden på, og siden vi i neste del skal se nærmere på selve automasjonen, så må vi først se nærmere på "devicene" og hvordan vi kan konfigurere dem. Den første delen (organiseringen) av dette er muligens litt kjedelig, men nødvendig for å holde orden i det kaoset som så altfor lett kan oppstå. Den andre delen (device konfigurasjon) er viktig å ha med seg med tanke på automasjonen vi skal se på senere. NB! I enkelte deler av det som følger er fakta blandet med mine erfaringer og meninger. Og bærer nok preg av det. Hva er en "Device"? En device er en "linje" i HomeSeer sin Device Manager-side som kan vise statusen til et lys og tilhørende kontroller eller kun vise informasjon (f.eks. temperatur eller strømforbruk). Som her, dette er taklampen min i stua (Fibaro Dimmer 1 FGD-211): En fysisk enhet (f.eks. en Z-wave node) kan ha flere devicer. Disse har alltid en parent device (som "Root") og de under kalles "child" devices. Her er en Fibaro Wall Plug. Disse grupperes vanligvis sammen: Men hvorfor heter det en "Device"? Historisk sett, altså i 1999 da HomeSeer 1 ble sluppet, var det en én-til-én relasjon for en slik "linje" i HomeSeer og en fysisk enhet. Dette gjaldt stort sett også i 2005 da HomeSeer 2 kom. Dette var da X10 var stort innen hjemmeautomasjon, og X10 hadde i utgangspunktet kun en funksjon pr enhet. X10 bruke et kode-system der en enhet hadde en bokstav fra A-P og et tall fra 1-16 (som gir 256 kombinasjoner), satt sammen til en device code. Rester av dette lever enda i HomeSeer, og er grunnen til at en slik linje i HomeSeer kalles en "device". In HomeSeer, as in real estate, it's location, location, location Når du har lagt inn de to-tre første enhetene dine, så er alt pent og pyntelig. Avhengig av hvilke noder det er kan det være alt fra 2 til 25 devicer, men alt er likevel forholdsvis oversiktlig og grensesnittet reagerer raskt. Hos oss er det rett rundt 1000 devicer. Bare det å laste alt på en gang tar altfor lang tid til at det er et alternativ. Man må filtrere på noe, og til det bruker man location2 og location. Den anbefalte metoden er å bruke location2 som "Etasje" (eller "Floor" på engelsk) og location som "Rom" (eller "Room"), og så standardisere navngivingen så mye du kan. I de rommene du har taklamper, kall hver av dem "Taklampe", men sett locations til tilhøreden etasje og rom. Det samme med "Temperatur", og andre typiske gjengangere. Her er organiseringen hos oss. Hvis jeg sorterer kun ut "Gang", så får jeg opp bevegelsessensorer, taklamper og temperaturer for gang i alle etasjer samtidig. For grupperte devicer, f.eks. bevegelsessensorer eller tilsvarende så setter jeg sensornavnet foran navnet som beskriver selve enheten, f.eks. "Bevegelsessensor, Lux" eller "Taklampe, kWh". Slik er det enkelt å se hva som hører sammen til en fysisk node. (Jeg kunne valgt å gi dem andre navn enn "Taklampe, Switch Multilevel", men siden jeg ofte prøver å hjelpe andre så bruker jeg den originale beskrivelsen i navnet.) Andre liker å bruke location2 til f.eks. klassifisere selve devicen. En fordel er at hvis du skal styre flere lys, så kan det være lettere å finne alle lys i et rom fra web-grensesnittet. En ulempe er at denne organiseringen vil splitte devicer som er gruppert sammen, og at i HStouch (og andre apper/plugins som WinSeer og TextSeer) sorterer enhetene først på location2, så location og deretter navn. Se bevegelsessensoren over. For denne noden setter man da typisk Location2 (Floor) til "Bevegelse", men hva med devicen som angir temperatur? I utgangspunktet virker jo dette nesten likt det å nangi devicene med type foran. Helt til du skal ha tak i root-devicen for en Z-wave node. I HomeSeer er det lov å ombestemme seg. Du kan navngi noder på nytt og du kan gi dem nye plasseringer helt uten at det betyr noe for HomeSeer. Du må bare huske det selv. Norsk eller engelsk? Jeg har en herlig blanding. Mange enheter synes jeg det er enkelst å navngi på norsk, fordi det virker kunstig for meg på engelsk. Dessuten er det småbarn i huset som skal bruke dem, og "Taklampe" i store bokstaver er lettere å forstå enn "Ceiling lamp". Jeg har f.eks. et "floor" som heter "Settings" og et rooms om heter "Options", men inni der ligger det enheter som har navn på norsk. Rett og slett fordi jeg stort sett bruker OSer på engelsk, og da vet jeg hva jeg skal lete etter. (Jeg klarer ikke engang bruke Excel på norsk. "SUM.HVIS" istedenfor "SUMIF"? Nei takk!). Norske .NET feilmeldinger liker jeg heller ikke, om ikke annet fordi det er så mye vanskeligere å søke etter dem på nettet. Men språk er for meg kun en personlig preferanse, HomeSeer vil kjøre like godt på norsk Windows og for HomeSeer spiller det ingen rolle om du navngir enheter på norsk eller engelsk. HomeSeer kan være litt grinete med Voice Recognition hvis du har æøå i navnet. Rommet som egentlig heter kjøkken heter hos meg "Kjokken". Og det kan man jo lage mange dårlige vitser med. Kort oppsummert: Uansett hvilken måte du velger å sortere på, så MÅ DET GJENNOMFØRES. I begynnelsen er det lett å ha oversikten, men senere, når det har gått en tid og du har lagt til mye mer utstyr, så må man ha et system som er så selvsagt at man fremdeles finner fram (og orker å forholde seg til). Husk at du i konfigurasjonsfasen (f.eks. oppsett av Eventer og HStouch-prosjekter) skal bruke devicene mye! Hvis du hver gang du skal ha tak i en device må bruke 7-8 sekunder på å prøve å huske hva den het og hvor du fant den, så taper du fort mye tid. Device Management Device Management-siden, som vi har sett flere ganger nå, er siden som brukes til å se og håndtere alle enhetene i systemet. For å gjøre utvalg har vi nedtrekksmenyer, overskrifter og hurtigvalg-menyer. Nedtrekksmenyene 1 og 2 styrer hvilke rom og etasjer som vises under. Man kan velge flere etasjer og flere rom. Slik er det raskt å vise informasjonen man et interessert i. (En ulempe er at location ikke blir filtrert etter at man har valgt location2, dessverre!) Meny-knappeene (merket 3) har følgende funksjoner: legger til en virtuell device. Location og location2 er satt til "Unknown", så hvis du ikke finner den så legg til visning for både "Rooms" og "Floors". lar deg justere bredden fra å enten være låst til 1000px til å bruke full bredde. HomeSeer 2 brukte hele side-bredden, men det var ikke SÅ vanlig med store 16:9-skjermer i 2005. Da HS3 kom, låste de bredden til 1000px for å unngå å måtte flytte på hodet for å lese en linje. Jeg foretrekker det, men andre brukerer er vanedyr og lager rabalder hvis noe endrer seg, selv om det er til det bedre. Omtrent som noen Windows 7-brukere da Windows 10 kom. lar deg velge å vise eller skjule de enhetene du har markert som skjult. Min står vanligvis på "skjult", for det gir et ryddigere interface. er for kun devicer som kan polles, f.eks. Z-wave-enheter. Polling spør enheten hvilken status enheten faktisk har, og oppdatere HomeSeer hvis det er nødvendig. I "gamle dager" fantes ikke Instant Status for Z-wave, og Z-wave enheter måtte polles. 433 Mhz enheter og mange andre kan ikke polles, og blir dermed bare ignorert av denne funksjonen. lar deg vise gruppere enhetene som har et parent/child-forhold, f.eks. Z-wave-enheter som har en Root, som Fibaro Dimmer2 og alle Z-wave bevegelsessensorer jeg vet om. Checkbox-en helt til venstre på en device er for å kunne velge flere enheter og gjøre operasjoner på alle sammen samtidig. Operasjonene du kan gjøre finner du i dropdown boksen rett under "Device List" som inneholder ting som å vise eller skjule, bytte floor/room, skru av/på voice control, logging, etc. Sortering For å sortere trykker du på overskriften til kolonnen du vil sorterer på. Trykker du på den samme kolonnen en gang til, snur du sorteringsretningen. Kolonner HomeSeer kan vise eller skjule flere kolonner enn de du ser som standard. Dette justeres under Tools -> Setup -> Custom. Device Ref (eller ID), Code og Address Alle enheter i HomeSeer har et unikt referansenummer, slik at hvis man vil gjøre noe mer avansert (f.eks. med scripting) så kan man bruke denne unike koden til å finne en helt bestemt device. "Address" gjør mye det samme, men det er et selvdefinert felt, det vil si at du (eller plugins) kan definere dette som du (eller pluginen) ønsker. Hvis du ser en Address du ikke har definert selv, så er den en dårlig idé å endre på den (me sannsynligvis får du ikke lov til det)… ;-) Og som med tidligere X10-enheter, kan man også definere en "device code" med en bokstav Jeg personlig bruker kun Device Ref da disse er enklest å forholde seg til. Device String, Device Value, Device Status og CAPI En device i HomeSeer kan i utgangspunktet lagre to ting: En tekst-streng (Device String) og en tallverdi (Device Value). Man kan også forhåndsdefinere Device Status'er, som binder en bestemt verdi til en bestemt tekststreng ("hvis verdien er n, vises teksten xyz"). For en typisk dimmer er verdien 0 definert til å vise teksten "Off", 99 (eller 100) viser teksten "On", og verdier mellom 1 og 98 vises som "Dim X%" der X byttes ut med den faktiske verdien (dimme-nivået i vårt eksempel). CAPI, eller Device Control API, er mye brukt i HomeSeer 3. Tidligere, hvis man med et script oppdaterte en dimmer sin value til å være 50, så ble lyset dimmet til 50%. Slik er det ikke lenger. Hvis du gjør det, så vil det tilsynelatende se ut som om det fungerte for devicen vil vise "Dim 50%", men det skjedde ingenting med selve lyset. For å få det til nå må man bruke CAPI (og det skal vi se nærmere på med scripting). Når CAPI blir trigget, så får HomeSeer beskjed om hvilken CAPI som skal bli trigget, og sender beskjeden videre til plugin'en (eller scriptet) som eier devicen hvis det ikke er HomeSeer selv . For eksempel hvis du trykker på "Update" på root'devicen i FitBitSeer, så får plugin'en beskjed fra HomeSeer hvilken CAPI som ble trykket på for hvilken device. Så er det opp til pluginen å gjøre som den får beskjed om. Her, når vi styrer devicer enten fra web grensesnittet, HStouch, eller via Eventer, så gjøres det alltid med CAPI så vi trenger ikke tenke på det. Men for de som vil kikke nærmere på scripting eller plugin-programmering, så er CAPI et veldig kraftig verktøy for device-håndtering. Device-konfigurasjon En device har flere parametere enn bare location og name, og det justerer vi under Device Properties. For å finne disse, så trykker du på navnet til en device. Properties … er det første bildet du møter. Her kan man også sette navn og location, samt device address hvis man ønsker. Her velger man også andre ting, som om verdi-forandringer også skal lagres i loggen, om den skal være skjult, om den skal tas med for enheter som støttes av voice recognition (Speaker Client, Alexa), og en del annet. I tillegg kan man endre på hvilke brukere som har tilgang til den devicen. Advanced Her er det ikke så mye man kan gjøre, men man finner mye nyttig informasjon om enheten. F.eks. om det er lagret en tekststreng som vises istedenfor Device Status, eller hvilken Device Reference den har, om den har et "forhold" til andre enheter, hvilken plugin (se "interface") som eier den og så videre. Status Graphics Her defineres de forskjellige Device Status'ene som enheten kan ha. Beskrivelse fra feltene fra venstre, mot høyre: "Value" er verdien som skal sendes med CAPI eller som devicen settes til. "Status" er teksten som vises istedenfor ferdien. "Control Use" (under Status-teksten): Blir brukt av JSON, Hstouch, Alexa-integrering, etc. F.eks. Hvis jeg har en enhet som heter "coffe machine" og for knappen "Brew" velger jeg "On", kan jeg spørre Alexa: "Alexa, turn the coffee machine on". Da vil CAPIen kalt "Brew" bli utført. "Row": CAPI-control kan arrangeres i rader (f.eks. dimmere har brytere On Off øverst og slider nederst) "Column": Tilsvarende Rows "ColumnSpan": En CAPI-control kan spenne over flere kolonner "Status-Control": En CAPI-control kan bare være en status (altså en tekst som erstatter en verdi), bare en knapp som sender en verdi til plugin'en eller scriptet som håndterer det, eller begge deler. Man kan også spesifisere en verdi to ganger, men med ulik Status-Control. En status kan være både en enkelt-verdi, og en range (altså mellom to verdier). Det beste eksempelet som forklarer mye av dette er å se på hvordan en dimmer device ser ut slik den er konfigurert. Slik ser den ut: ... og slik er den konfigurert: Merk: Det behøver ikke være en 1-til-1 relasjon mellom knappe-tekst og status-tekst. Hvis du lager en Status-Control som kun er "control", verdi 100 og status-status tekst "Skru på!", og deretter enda en med Status-Control til "status", verdi 100 og status-tekst "Du skrudde den på!", så vil teksten på enheten bli "Du skrudde den på!" etter at du trykket på "Skru på!". Denne konfigurasjonen: ... gir dette resultatet: Dermed har man mange muligheter til å lage controller og statuser som gir mening. Det gjør det lettere enn å prøve hva tallet 23 betydde for den aktuelle devicen. Under Status Values finner du Status Graphics. Som med Status-tekst, så viser den et bilde basert på hvilken verdi det er. Status Graphics kan svære enkeltverdi eller en range. Hvis du vil legge inn dine egne bilder, så legges de inn i \html\images-mappen i HomeSeer-området. Virtuelle devicer Virtuelle Devicer kalles dette fordi de ikke styrer eller styres av noe fysisk. Hva disse kan brukes til er muligens enklest å forklare med et eksempel. Vi har en jeg har kalt "Tidsstatus". Der har jeg definert 0 til å være "Morgen", 1 til å være "Dag", 2 til å være "Kveld" og "3" til å være "Natt". Denne devicen styres av automatikken samtidig som den kan brukes som betingelser i andre eventer. Hvis denne brukes som betingelser kan jeg få det slik: "… AND IF the device Tidsstatus is Morgen", men jeg kan også bruke "… AND IF the device Tidsstatus has a value greater than Dag", som da vil bety "... AND IF det er kveld ELLER natt". Jeg har mange slike devicer for å styre eller overstyre automatikken. Det er en glimrende måte å lagre og sette verdier man trenger å huske til en senere anledning. I sin enkleste form ser den slik ut (eller i det minste tidligere, da jeg skulle demonstrere det på det engelske HS-forumet): Oppsummering Phew! Ferdig! Hvis du synes dette tidvis var tungt å lese, kan du trøste deg med at det var også tungt å skrive. Device-håndtering kan være tidkrevende, i hvert fall i begynnelsen. Men tenk på at det er en investering for fremtiden. Virtuelle Devicer gir oss mulighet til å lagre verdier det kan være verdt å ta vare på, og kan brukes både som triggere og som betingelser til eventer, samtidig som de selvfølgelig kan styres fra et Event. Tidligere har vi snakket om innkjøp (del 1), oppsett (del 2), Z-wave-konfigurasjon (del 3 og del 4), og 433 MHz utstyr (del 5). I del 7 skal vi begynne å se nærmere på Events. Det er kanskje det mest spennende med hjemmeautomasjonen, nettopp fordi det er automasjon! Vis full oppføring