Gå til innhold
  • Bli medlem
Støtt hjemmeautomasjon.no!
  • Moskus
    Moskus

    HomeSeer-skolen #6: Devicer

    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):

     

    1 En device.png

     

    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:

     

    2 Device Group.png

     

    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.

     

    3 Meny.png

     

    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:

    Add_Below.png 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".

     

    expand-page.png 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. ;)

     

    hide_marked.png 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.

     

    poll-devices.png 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.

     

    group_physical.png 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.

     

    Properties.png

     

     

    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.

     

    Properties Advanced.png

     

     

    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).

     

    Properties StatusGraphics.png

     

     

    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:

    Taklys_Device.png

     

    ... og slik er den konfigurert:

    Taklys_Device_settings.png

     

    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:

    Custom_Status_settings.png

     

    ... gir dette resultatet:

    Custom_Status.png

     

    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):

    Virtual_Device_Time.png

     

     

    Oppsummering

    Phew! Ferdig! Hvis du synes dette tidvis var tungt å lese, kan du trøste deg med at det var også tungt å skrive. :P 

     

    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! :) 

     

    Endret av Moskus

    Brukertilbakemelding

    Anbefalte kommentarer



    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

    Lenke til kommentar
    Del på andre sider

    14 minutter siden, Fredrick skrev:

    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?

    Kommer mer av det. :)

    Jeg vet ikke hvordan andre gjør det, men jeg viser mitt oppsett... ;) 

     

    15 minutter siden, Fredrick skrev:

    Tenkte litt på tidsstatus-devices som du nevner, eller de andre viruelle devices som du bruker for å overstyre automatikken

    Vel, nå har du jo sett tidsstatus-devicen. Selve devicen er ikke så mye hokus pokus. Eventene kommer vi til. :) 

     

    Lenke til kommentar
    Del på andre sider

    1 minute ago, Moskus said:

    Vel, nå har du jo sett tidsstatus-devicen. Selve devicen er ikke så mye hokus pokus. Eventene kommer vi til. :) 

     

     

    Jeg har sett hvordan den ser ut, og kan fint kopiere den, men den vil jo ikke endre status med mindre det settes opp via eventer :)

     

    Venter i spenning på del 7!

    Lenke til kommentar
    Del på andre sider

    Er det mulig å skille mellom belysning PÅ fra bryter (zwave) og fra CAPI/device control? Eller, hvordan kan man enklest gjøre dette?

     

    For å kunne ta et lengre bad så har vi behov for å enkelt kunne koble ut styringen av lys via bevegelsesensor (WAF må være å slippe å ta opp mobil eller installere enda en fysisk enhet/knapp). Hadde planer om å lage en virtuell device på hovedbadet som derfor aktiveres hvis belysningen skrus på først via fysisk bryter slik at event for bevegelsesensor kobles ut. 

    Lenke til kommentar
    Del på andre sider

    9 timer siden, iceball skrev:

    Er det mulig å skille mellom belysning PÅ fra bryter (zwave) og fra CAPI/device control? Eller, hvordan kan man enklest gjøre dette?

    Nei, dessverre. På er på.

     

    9 timer siden, iceball skrev:

    For å kunne ta et lengre bad så har vi behov for å enkelt kunne koble ut styringen av lys via bevegelsesensor (WAF må være å slippe å ta opp mobil eller installere enda en fysisk enhet/knapp).

    Hva med en fuktighetssensor i badekaret? :P 

    Lenke til kommentar
    Del på andre sider

    1 time siden, Moskus skrev:

    Nei, dessverre. På er på.

    Hmm..det var faktisk litt skuffende, for det skilles jo mellom de i loggen. Men, kan løse det med dobbelt-klikk på Qubino flush dimmer til maks/on/99 som trigger eventen, for deretter justere ned lysstyrken automatisk og sette off etter 2 timer f.eks.. Ingen av de vanlige bevegelse-eventene trigger med enn 80 % dim tror jeg.

     

    1 time siden, Moskus skrev:

    Hva med en fuktighetssensor i badekaret? :P 

    Haha. Er boblebadekar så det er diverse hull og gjennomføringer fra før av. ?

    Lenke til kommentar
    Del på andre sider

    16 minutter siden, iceball skrev:

    Hmm..det var faktisk litt skuffende, for det skilles jo mellom de i loggen.

     

    Er det ikke Jon00 som har en "log-scraper"-plugin? Altså som kan trigge ting basert på tekst i loggen?

    Lenke til kommentar
    Del på andre sider

    20 minutter siden, iceball skrev:

    Hmm..det var faktisk litt skuffende, for det skilles jo mellom de i loggen.

    Definér "skilles". Det ene er HomeSeer som logger slik det skal, det andre er plugin'en. Så det er et skille, men ikke i praksis.

     

    2 minutter siden, ZoRaC skrev:

    Er det ikke Jon00 som har en "log-scraper"-plugin? Altså som kan trigge ting basert på tekst i loggen?

    Jo, men begge deler trigger når du skrur på lyset. (Gjør det ikke...?)

     

     

    Lenke til kommentar
    Del på andre sider

    Kan i hvert fall melde om at løsningen jeg skisserte som plan B fungerer bra. Dobbeltklikk på Qubino flush dimmer setter lyset til 100 %, starter en egen event (uavhengig av tid på døgnet, som bevegelsesstyrt belysning følger), dimmer ned downlights fra 100 % til 70 % med en gang, fjerner eventuelle delayed actions (satt av bevegelses event som skrur av lyset), setter OFF etter delay på 1 time og setter en virtuell enhet til ON som gjør at bevegelsesstyrt belysning kobles ut i denne perioden.

    Lenke til kommentar
    Del på andre sider

    Jeg har satt opp en virtuell tidsstyringsdevice med verdiene 0-3...

    58c94d1fbef3b_hs3-tidsstatusdevice.thumb.PNG.b21a65a466108d591df6a6c24e54f5c0.PNG

     

    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??

     

    58c94d1e7f4b3_hs3-tidsstatusdevice-resatt.thumb.PNG.0d825a1fce4e588fcb17d2afda02de91.PNG

    Lenke til kommentar
    Del på andre sider

    14 minutter siden, tonheim skrev:

    Hvorfor skjer dette??

    Det skal ikke skje. Jeg har ingen forklaring på det.

    Jeg har ikke sett det før.

     

    Det eneste er om du ikke har laget en helt ny virtuell device, men kopiert en som hører til en plugin, og at plugin'en resetter det.

    Hvordan ser det ut under tab'en Advanced?

     

    ... og du har ingen backup som blir kjørt tilbake av HS-databasen eller andre slike "tåpeligheter"?

    Lenke til kommentar
    Del på andre sider

    Litt ufrivillig inngang i HS3-verdenen da z-wavechipen på min HC2 visstnok er defekt.  

    Heldigvis så kom jeg på at jeg har stort sett lys gjennom Hue og Domoticz. 

    Jowihue fungerer glimrende til Hue.

    Noen som har tips til måte å sende json-kommandoer fra Homeseer? Har lyst til å fortsette å ha FXtrx433E´en på en egen Pi inntil videre, da jeg foreløpig bare kjører HS3 på en Pi med z-sticken fra Aeotec. Eksempel på luakode fra HC2:

    "msg":"Domoticz = Net.FHttp(\"10.0.0.189\",8080) \nDomoticz:setBasicAuthentication(\"usr\", \"pwd\") \nresponse, status, errorCode = Domoticz:GET(\"/json.htm?type=command&dparam=switchlight&idx=22&switchcmd=Off&level=1\") \nfibaro:log(response) \nfibaro:sleep(3000) \nif errorCode == 0 \nthen \nfibaro:log(status) \nelse \nfibaro:log(errorCode) \nend"

    Lenke til kommentar
    Del på andre sider

    7 timer siden, gullfrode skrev:

    Noen som har tips til måte å sende json-kommandoer fra Homeseer?

     

    jeg anbefaler å lage en ny tråd om det, men du skal få noe å tygge videre på:

     

     

     

     

    • Like 1
    Lenke til kommentar
    Del på andre sider

    17 hours ago, tonheim said:

    Jeg har satt opp en virtuell tidsstyringsdevice med verdiene 0-3...

    58c94d1fbef3b_hs3-tidsstatusdevice.thumb.PNG.b21a65a466108d591df6a6c24e54f5c0.PNG

     

    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??

     

    58c94d1e7f4b3_hs3-tidsstatusdevice-resatt.thumb.PNG.0d825a1fce4e588fcb17d2afda02de91.PNG

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

    Endret av DiderikFrom
    Lenke til kommentar
    Del på andre sider

    On 12/14/2016 at 22:43, iceball said:

    Er det mulig å skille mellom belysning PÅ fra bryter (zwave) og fra CAPI/device control? Eller, hvordan kan man enklest gjøre dette?

     

    For å kunne ta et lengre bad så har vi behov for å enkelt kunne koble ut styringen av lys via bevegelsesensor (WAF må være å slippe å ta opp mobil eller installere enda en fysisk enhet/knapp). Hadde planer om å lage en virtuell device på hovedbadet som derfor aktiveres hvis belysningen skrus på først via fysisk bryter slik at event for bevegelsesensor kobles ut. 

     

    Det er ike mulig direkte, nei. I tidenes løp har jeg implementert ganske mange varianter av løsninger på dette. Hvilken løsning man skal velge, avhenger veldig av systemet ellers og praktisk bruk. Styres lysene automatisk eller ikke, f.eks.? Nå kjører flere slike løsninger. Den «enkleste» løsningen er et skript (eller event) som trigger på "status change" av den aktuelle devicen, og skriptet (eventen) har også en condition som kan inaktivere det. Når du styrer devicen automatisk, slår du først på condition som inaktiverer skriptet (eventen), styrer, og slår av condition.

    Alle Hue-lysene mine går av og på og justeres automatisk, og oppdaterer dette hvert femtende minutt. HS leser av faktisk lysstyrke/fargetemperatur på pærene. Dersom dette ikke stemmer med hva automatikken satte det til ved siste korsvei (dvs. noen har justert manuelt), slår automatikken seg av inntil neste dag eller noen ber Alexa om å slå på automatikken.

    I badekaret trengs ingen slik automatikk. Dersom lyset går av, løfter vi bare hånden og bevegelsessensoren trigges. Eller Alexa kan bes om å stille inn badelyset. (Dog er hun ikke så veldig glad i akustikken på badet.)

    Lenke til kommentar
    Del på andre sider

    @Moskus, der du har etg. hadde jeg tenkt å ha type, lux, temp., lys osv.

     

    Var ikke det fornuftig, men tanke på at jeg kom på det selv?

     

    Hihihi...

     

    Gir nye navn, fjerner logging osv. nå siden google/Moskus sa at det var nødvendig når man ikke har backup.

    Lenke til kommentar
    Del på andre sider

    1 time siden, Erling skrev:

    @Moskus, der du har etg. hadde jeg tenkt å ha type, lux, temp., lys osv.

    Var ikke det fornuftig, men tanke på at jeg kom på det selv?

    Du bestemmer selv. ;)

    Jeg er ikke enig, men jeg vet ikke alt. Bare du finner frem, så er det jo bra. :) 

    Lenke til kommentar
    Del på andre sider

    1 time siden, SteinarH skrev:

    Jeg prøver å få en forståelse av denne tidsstyringen, men har litt utfordringer med hvordan man skal definere døgnskifte. Finnes det en god forklaring på dette?

     

    «Before XX:XX» betyr fra kl 00:00:01 til kl XX:XX. «After XX:XX betyr fra kl XX:XX til kl 23:59:59. 

    Lenke til kommentar
    Del på andre sider




    Bli med i samtalen

    Du kan publisere innhold nå og registrere deg senere. Hvis du har en konto, logg inn nå for å poste med kontoen din.

    Gjest
    Skriv en kommentar...

    ×   Du har limt inn tekst med formatering.   Lim inn uten formatering i stedet

      Du kan kun bruke opp til 75 smilefjes.

    ×   Lenken din har blitt bygget inn på siden automatisk.   Vis som en ordinær lenke i stedet

    ×   Tidligere tekst har blitt gjenopprettet.   Tøm tekstverktøy

    ×   Du kan ikke lime inn bilder direkte. Last opp eller legg inn bilder fra URL.




×
×
  • Opprett ny...

Viktig informasjon

Vi har plassert informasjonskapsler/cookies på din enhet for å gjøre denne siden bedre. Du kan justere dine innstillinger for informasjonskapsler, ellers vil vi anta at dette er ok for deg.