HomeSeer-skolen #7: Events - automatikkens kjerne

[Moskus]

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

[mk1 black limited]

Superbra, @Moskus, jeg lærer ting (jeg burde visst) for hvert nytt avsnitt!

 

En ting jeg stusset på - er dette riktig:

 

Quote

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.

 

Jeg mener å ha lest at RFXCOM-pluginen holder styr på slike ting?

[Moskus]

Et øyeblikk siden, mk1 black limited skrev:

Jeg mener å ha lest at RFXCOM-pluginen holder styr på slike ting?

Her siterer jeg faktisk bare @Fermate for å være helt ærlig. Jeg mener også det, men han har praktisk erfaring så det er vanskelig å argumentere mot.  

Jeg skal se om jeg får dobbeltsjekket dette i kveld.

[mk1 black limited]

OK - jeg har flere RFXtrx-transceivere ikke så langt fra hverandre, og har ikke registrert dette i det hele tatt, derfor ble jeg litt overrasket.

[Moskus]

Jeg tror det kan være forskjell på å ha flere trx'er og en blanding av RFXtrx'er og RFXLAN også. Men poenget er at det kan være at det er flere triggere av et event, og Do Not Trigger er en grei måte å unngå det på.

 

Hadde tidligere en Nexa-bryter for å styre dørlåsen å kjelleren (nevnte Danalock), og der måtte jeg bruke det i tilfelle du skulle rekke å dobbeltrykke på knappen. Da pusset den tenner igjen...  

[Fermate]

Om du bare sender en ON Melding til en Device som allerede er ON så merker du ikke dette. 

Men om meldingen toggler noe er det verre.

Husker ikke helt om dette både gjelder X10 og Nexa men mener det.

Uansett, se i loggen så ser du der.

[Lumzk]

Herlig,@Moskus! Homeseer-skolen fikk meg til gå fra HCL til HomeSeer. Det lugga litt i starten, og vikene dro seg nok litt lengre opp i panna, men heldigvis hadde jeg innleggene dine å støtte meg på. Huset blir stadig mer automatisert og det meste spiller på lag! Takk for at du tar deg tid til å dele av kunnskap og erfaring - det hjelper virkelig! Gleder meg til fortsettelsen! [emoji4][emoji106]

[Moskus]

26 minutter siden, Lumzk skrev:

Huset blir stadig mer automatisert og det meste spiller på lag! Takk for at du tar deg tid til å dele av kunnskap og erfaring - det hjelper virkelig!

Kjekt å høre og velkommen til en mer automatisk hverdag!  

 

26 minutter siden, Lumzk skrev:

Gleder meg til fortsettelsen!

Bare skrik ut hvis noe er vanskelig å forstå eller savnes forklart. Jeg vet jo ikke om alt som det er mulig å lure på...  

[mk1 black limited]

5 hours ago, Fermate said:

Om du bare sender en ON Melding til en Device som allerede er ON så merker du ikke dette. 

Men om meldingen toggler noe er det verre.

Husker ikke helt om dette både gjelder X10 og Nexa men mener det.

Uansett, se i loggen så ser du der.

Spurte Bert føgende:

Quote

Hi! If one has two RFXtrx433 transceivers close by, I guess a signal from e.g. a Nexa on/off switch will be received by both transceivers.
In HS3, will the RFXCOM plugin handle this, or will an event to be triggered by this signal be run twice?

Og han svarte:

Quote

It will be seen as 1 command.

...så da tror jeg kanskje det bare gjelder X10.  

[iceball]

En liten kommentar/hjelp til de som er nye på eventer, basert på egne erfaringer. Det er litt forskjell på hva du får opp som mulige trigger-kategorier og condition-kategorier. Så hvis du tenkte å kun ha en trigger for en event, men ikke finner igjen akkurat sånn du så inne på forumet, så kanskje du må legge til en condition også og vips så er det litt andre valg.

 

Ellers takk igjen, endelig har jeg skjønt hvordan sjekke om døra er låst ?

 

[Nettopp]

Takk for nok en bra guide, og du nevner at det er viktig å tenke gjennom strukturen på Events-oppsettet.

 

Jeg diskuterer med meg selv hva som er det beste oppsettet for lysstyring av rom/soner. F.eks. "Alt lys av", "Alt lys på i stue", osv.

Det jeg opprinnelig har planlagt er å ha en virtuell device som "master" med forskjellige lys-scener som kan aktiveres. F.eks. nevnte "Alt lys av".

 

Under der hadde jeg sett for meg å sette opp en event som da heter "Alt lys av", og når denne trigges slås alle devices av i tur og orden. Forsåvidt enkelt, men kan være vanskelig å holde orden på ser jeg for meg, etterhvert som lyspunkter legges til, flyttes, gis nytt navn osv. Og tilsvarende events for "alt lys på i stue", osv. osv.

 

Etterhvert har jeg fundert på om det kan være lurere å bygge opp strukturen med events pr. lyspunkt, og at man for hvert lyspunkt har en Event som definerer hvordan punktet skal reagere på endringer i status på virtuell device som styrer lysscenene. If ....changes and becones "Alt lys av", then .... Selv om dette blir et langt Event pr. enhet vil det være lett å kopiere og definere, og det bør være greit å holde orden på at man skal endre det tilhørende Eventet om det gjøres endringer i det fysiske oppsettet.

 

Jeg har også sett litt på Z-wave scenes, men dette virket ikke spesielt intuitivt eller gjennomarbeidet...

 

Er det noen som vil dele litt erfaringer om hvordan de har strukturert denne typen gruppe-kommandoer?

 

Edit: Vil tro at assosiasjon også er et aktuelt alternativ.

Endret 9. januar 2017 av Nettopp

[Marhil]

Kjempebra guide! Ser at en del ting som jeg savner i Zipatos rule builder er tatt høyde for i HS. F.eks logikken «device was set to». Tisynelatende liten filleting som ikke er det. Zipato krever en statusendring for å trigge, noe som irriterer meg grønn noen ganger ?

Skal ikke se bort i fra at jeg må teste HS når jeg får tid. Det var dette med tid, da...

[Vitellius]

30 minutter siden, Nettopp skrev:

Takk for nok en bra guide, og du nevner at det er viktig å tenke gjennom strukturen på Events-oppsettet.

 

Jeg diskuterer med meg selv hva som er det beste oppsettet for lysstyring av rom/soner. F.eks. "Alt lys av", "Alt lys på i stue", osv.

Det jeg opprinnelig har planlagt er å ha en virtuell device som "master" med forskjellige lys-scener som kan aktiveres. F.eks. nevnte "Alt lys av".

 

Under der hadde jeg sett for meg å sette opp en event som da heter "Alt lys av", og når denne trigges slås alle devices av i tur og orden. Forsåvidt enkelt, men kan være vanskelig å holde orden på ser jeg for meg, etterhvert som lyspunkter legges til, flyttes, gis nytt navn osv. Og tilsvarende events for "alt lys på i stue", osv. osv.

 

Etterhvert har jeg fundert på om det kan være lurere å bygge opp strukturen med events pr. lyspunkt, og at man for hvert lyspunkt har en Event som definerer hvordan punktet skal reagere på endringer i status på virtuell device som styrer lysscenene. If ....changes and becones "Alt lys av", then .... Selv om dette blir et langt Event pr. enhet vil det være lett å kopiere og definere, og det bør være greit å holde orden på at man skal endre det tilhørende Eventet om det gjøres endringer i det fysiske oppsettet.

 

Jeg har også sett litt på Z-wave scenes, men dette virket ikke spesielt intuitivt eller gjennomarbeidet...

 

Er det noen som vil dele litt erfaringer om hvordan de har strukturert denne typen gruppe-kommandoer?

 

Edit: Vil tro at assosiasjon også er et aktuelt alternativ.

 

Om det primært er Av/På eventer du er ute etter her, så kan du jo benytte deg av "All off" og "All on" kommandoene (som de fleste av dine noder sikkert støtter), som ligger under "z-wave actions".

[ZoRaC]

Flott guide, igjen!

 

Liten skrivefeil av litt betydning - her skal det vel være med en "ikke":

Sitat

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.

 

[Moskus]

10 timer siden, Nettopp skrev:

Jeg diskuterer med meg selv hva som er det beste oppsettet for lysstyring av rom/soner. F.eks. "Alt lys av", "Alt lys på i stue", osv.

Det jeg opprinnelig har planlagt er å ha en virtuell device som "master" med forskjellige lys-scener som kan aktiveres. F.eks. nevnte "Alt lys av".

 

Under der hadde jeg sett for meg å sette opp en event som da heter "Alt lys av", og når denne trigges slås alle devices av i tur og orden. Forsåvidt enkelt, men kan være vanskelig å holde orden på ser jeg for meg, etterhvert som lyspunkter legges til, flyttes, gis nytt navn osv. Og tilsvarende events for "alt lys på i stue", osv. osv.

Jeg har et Event som heter "Alt lys av", der jeg definerer hvilke lys som skal skrus av (f.eks. er det enkelte noder som skal være på selv om lyset er av). Dette eventet trigger jeg fra de forskjellige tilfellene når det er nødvendig (f.eks. "Alarm på", "Nattmodus", etc).

 

Det er mulig å bruke Z-wave actions som "All On" og "All Off" og begrense det pr. rom, men jeg ville ha større problemer med å ha oversikten med den måten, så jeg har personlig valgt det bort.

 

10 timer siden, Nettopp skrev:

Etterhvert har jeg fundert på om det kan være lurere å bygge opp strukturen med events pr. lyspunkt, og at man for hvert lyspunkt har en Event som definerer hvordan punktet skal reagere på endringer i status på virtuell device som styrer lysscenene. If ....changes and becones "Alt lys av", then .... Selv om dette blir et langt Event pr. enhet vil det være lett å kopiere og definere, og det bør være greit å holde orden på at man skal endre det tilhørende Eventet om det gjøres endringer i det fysiske oppsettet.

Nå spør du etter personlige preferanser, men jeg hadde ikke gjort det på denne måten. Om ikke annet fordi det mange-dobler antall events du må ha kun for å skru av noen lys. Det er jo ikke så mye ekstra et slikt event vil ta, men til slutt så blir det jo litt...

 

10 timer siden, Nettopp skrev:

Vil tro at assosiasjon også er et aktuelt alternativ.

Assosiasjon har i utgangspunktet med hvor en node sender sine beskjeder, så det er ikke så aktuelt her.

 

 

10 timer siden, iceball skrev:

Det er litt forskjell på hva du får opp som mulige trigger-kategorier og condition-kategorier. Så hvis du tenkte å kun ha en trigger for en event, men ikke finner igjen akkurat sånn du så inne på forumet, så kanskje du må legge til en condition også og vips så er det litt andre valg.

Jeg er ikke sikker på hva du mener. Hvis du ser en (standard) trigger (eller condition) på forumet, så skal du være i stand til å finne nøyaktig den samme triggeren. Men de er muligens beskrevet litt annerledes i nedtrekksmenyen enn det som vises i tekst etterpå...

 

 

29 minutter siden, ZoRaC skrev:

Liten skrivefeil av litt betydning - her skal det vel være med en "ikke":

Wops, det har du rett i!

Fixed.  

[Nettopp]

10 timer siden, Vitellius skrev:

 

Om det primært er Av/På eventer du er ute etter her, så kan du jo benytte deg av "All off" og "All on" kommandoene (som de fleste av dine noder sikkert støtter), som ligger under "z-wave actions".

 

Jeg har forsøkt med litt med dette, men da jeg også bruker plugin moduler til ting som panelovner, vaskemaskiner, osv. ble det litt uoversiktlig. Er klar over at man kan deaktivere om de reagerer på "all off" eller ikke. 

[Superzite]

Tipp topp, Tommel opp, @Moskus Dette er meget informative og fine guider. 
 

[iceball]

Den 9.1.2017 klokken 23.18, Vitellius skrev:

 

Om det primært er Av/På eventer du er ute etter her, så kan du jo benytte deg av "All off" og "All on" kommandoene (som de fleste av dine noder sikkert støtter), som ligger under "z-wave actions".

Jeg måtte kutte ut dette (selv om det var meget raskt og greit å få opp) fordi enhetene (husker ikke om det gjaldt alle eller kun noen typer) ikke rapporterte tilbake at de var skrudd av. Mener å ha lest at det er en bug i HS3.

Valgte derfor heller å bygge opp eventer for de største rommene som skrur av lysene, og deretter opp et nivå over, per etasje som kjører eventene per rom + enkeltlys på mindre rom, og en event på toppen som styrer alt av og som kjører eventene per etasje. Tar ikke lange tiden dette heller egentlig.

Endret 10. januar 2017 av iceball

[Kenneth]

Hei,

Er relativ ny til HS selv (Kjører HS3), men har begynt å skjønne litt av sammenhengen. Mye takk og være HomeSeer skolen, så takk for det

Jeg har likevel ett spørsmål til hvordan enn best kan sette opp styring i ett tidsrom.

Eks1 mellom kl 2200 til 00600

Eks2 2t etter solnedgang til 2t før soloppgang

Jeg har testet litt på dette og får satt opp reglene slik jeg mener de skal være men HS ser ikke ut til å takle at tidsrommet går over ifra en dag til en annen. Savner også en tis regel som heter "between" dvs mellom kl 2200 og 0600.

jeg kan komme rundt dette med å sette opp flere regler som etter kl 2200 og før kl 2359 og etter kl 0000 og før kl 0600 men dette krever mer oppsette enn strengt tatt nødvendig. Er det noe jeg ikke har forstått eller er det slik det må være i skrivende stund? 

[ZoRaC]

6 minutter siden, Kenneth skrev:

Eks1 mellom kl 2200 til 00600

Jeg har testet litt på dette og får satt opp reglene slik jeg mener de skal være men HS ser ikke ut til å takle at tidsrommet går over ifra en dag til en annen. Savner også en tis regel som heter "between" dvs mellom kl 2200 og 0600.

jeg kan komme rundt dette med å sette opp flere regler som etter kl 2200 og før kl 2359 og etter kl 0000 og før kl 0600 men dette krever mer oppsette enn strengt tatt nødvendig. Er det noe jeg ikke har forstått eller er det slik det må være i skrivende stund? 

 

Det finnes en plugin, EasyTrigger, som gir litt mer muligheter (blant annet "between", tror jeg).

Ellers er nok løsningen slik du sier, med å dele det opp ved midnatt:

 

Et annet alternativ er å løse det med en virtuell device for "MDEN" (Morning, Day, Evening, Night).

Da har du en event som setter den til Night kl 22 og Morning kl 6. Så sjekker du på om den devicen er "Night" i stedet for å sjekke klokka. Da er det også enklere å justere senere, hvis du finner ut at "natt" starter kl 21 i stedet for 22. Da endrer du det i 1 event i stedet for alle events som tar hensyn til tiden.

 

8 minutter siden, Kenneth skrev:

Eks2 2t etter solnedgang til 2t før soloppgang

 

Vet ikke om EasyTrigger har noen bedre løsning for det, men det kan også løses med "OR IF":

[Moskus]

7 timer siden, Superzite skrev:

Tipp topp, Tommel opp, @Moskus Dette er meget informative og fine guider. 

Takk!

 

 

 

46 minutter siden, Kenneth skrev:

Mye takk og være HomeSeer skolen, så takk for det

Takk!  

 

25 minutter siden, Kenneth skrev:

Jeg har testet litt på dette og får satt opp reglene slik jeg mener de skal være men HS ser ikke ut til å takle at tidsrommet går over ifra en dag til en annen.

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.

 

 

31 minutter siden, Kenneth skrev:

jeg kan komme rundt dette med å sette opp flere regler som etter kl 2200 og før kl 2359 og etter kl 0000 og før kl 0600 men dette krever mer oppsette enn strengt tatt nødvendig. Er det noe jeg ikke har forstått eller er det slik det må være i skrivende stund? 

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.  

 

 

 

 

19 minutter siden, ZoRaC skrev:

Det finnes en plugin, EasyTrigger, som gir litt mer muligheter (blant annet "between", tror jeg).

Jeg lurte også på dette, men jeg finner ikke den muligheten her...

[Blodstrupmoen]

Hvis man har en virtuell device som styrer hus status som natt, dag, borte, ferie f.eks trenger man bare ett event for å aktivere natt. Så har man ett som aktiverer dag.

[psv021]

Den ‎28‎.‎12‎.‎2016 klokken 22.20, Moskus skrev:

 

Vanne plenen, anyone?  

 

 

Last ran: Never

 

[Moskus]

10 timer siden, psv021 skrev:

Last ran: Never

 

Nesten!

Kjørte, hvis jeg husker rett, 3 ganger i fjor og 6-7 ganger året før det, men nesten hele sommeren for tre år siden.

[TomB]

On 28/12/2016 at 22:20, Moskus said:

I del 8 skal Fermate vise oss hvordan vi kommer i gang med HStouch Designeren!  

 

Kjempebra innlegg som vanlig, supert!

Og denne neste gleder jeg meg til, jeg har rett og slett ikke orket å begynne på HSTouch ennå, synes det virker VELDIG knotete, gleder meg stort til en guide her