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

Søk i nettsamfunnet

Viser resultater for emneknaggene 'guide'.

  • Søk etter emneknagger

    Skriv inn nøkkelord separert med kommaer.
  • Søk etter forfatter

Innholdstype


Kategorier

  • Generelt
    • Automasjonskaféen
    • Annen Elektronikk
    • Ditt system
    • Grafikk og design
    • Nettverk
    • Nybegynner
  • Bruksområder
    • A/V-kontroll
    • Belysning
    • Klimakontroll
    • Overvåking
    • Sikkerhet
    • Strømsparing og strøm-overvåkning
    • Talestyring
  • Systemer
    • Domoticz
    • Fibaro Home Center
    • Futurehome
    • HDL
    • Home Assistant
    • HomeKit
    • HomeSeer
    • Homey
    • Indigo Domotics
    • Node-Red
    • openHAB
    • Sensio
    • SmartThings
    • Telldus Live!
    • Vera
    • Z-Way
    • Zipato
    • Øvrige systemer
  • Teknologi / Protokoller
    • Blåtann
    • irDA
    • KNX
    • Mikrokontrollere
    • MQTT
    • RF
    • xComfort
    • Z-Wave
    • ZigBee
  • Utlån, kjøp og salg
    • Prisjakt
    • Kjøp / Salg
    • Powerbuy
    • Kommersielle tilbud
    • Utlån
  • Nettstedet
    • Kunngjøringer
    • Nyheter
    • Ris, ros og spørsmål om forumet

Blogger

  • En teknologisk hverdag
  • Enda en hobby?
  • Smånytt
  • en guide til elektro-verdenen

Kategorier

  • Nyheter
    • Produkter
    • Programvare
  • Tester
    • Systemer
  • Guider
    • Fibaro
    • HomeSeer
    • Nettverk
    • openHAB
    • Z-Wave
    • ESP32

Finn resultater i...

Finn resultater som inneholder...


Startdato

  • Start

    Slutt


Sist oppdatert

  • Start

    Slutt


Filtrer etter antall...

Ble med

  • Start

    Slutt


Gruppe


System

  1. Del 3: Z-wave-håndtering Nå har vi valgt en HomeSeer-versjon, og vi har satt det opp slik at det i det minste sviver. Men HomeSeer trenger å snakke med omverdenen for å være til nytte. En protokoll til det er Z-wave. Forbehold: Dette er skrevet med HomeSeer-versjon 3.0.0.297 og Z-wave plugin-versjon 3.0.1.93. Deler av det som står her kan ha blitt endret senere. Veldig kort om Z-wave Z-wave er en protokoll som både kan sende og motta beskjeder. Hver Z-wave enhet kalles en node, utenom sjefs-noden som kalles master controller. Flere noder som snakker sammen og med samme master controller er et nettverk. Når en node mottar en beskjed ("skru lyset ditt på") så kvitteres det tilbake til master controller. For å justere et eller annet (f.eks. dimme-tid, følsomhet for bevegelsessensorer, etc) sendes en parameter til noden. Z-wave lager et såkalt "mesh nettverk". Nodene snakker med flere andre noder, og kan sende beskjeder videre fra en til en annen, og dermed har man sjeldent dekningsproblemer. Interface/controller Man trenger et interface slik at programvaren kan kommunisere med den virkelige verdenen. Hvis du har valgt en hardware-boks fra HomeSeer, så følger det med. Hvis du har valgt kun programvare, må du kjøpe et. Mange bruker UZB1 (versjon 5.2 kan med oppdateres), andre bruker Z-stick Gen 5. Disse kobles til maskinen via USB. Noen av oss bruker til og med Z-NET, et ethernet-interface fra HomeSeer (det er hendig hvis du kjører HomeSeer på en virtuell maskin, eller trenger å plassere interfacet et stykke fra serveren). Akkurat nå er det uansett viktig å sørge for at interfacet/controlleren (jeg bruker ordene litt om hverandre) støtter Z-wave Plus. Ellers kan det nevnes at UZB1 har en fordel over Z-stick: HomeSeer kan ta backup av UZB1 og "restore" den tilbake til den samme eller en annen controller/interface. Det er også mulig med Z-stick, men da må du bruke Aeon Labs egen Windows-programvare. Du har valgt et interface? Bra, da fortsetter vi med å legge det til i HomeSeer. Aller først sjekker vi at Z-wave plugin'en kjører. Det gjør vi ved å gå til Plugins → Manage. Når dette er gjort går du til Plugins → Z-wave → Controller Management. Se under overskriften "Z-wave Interfaces". Hvis du ser et interface der, så trykk på den gule pilen for konfigurasjon. Hvis ikke, trykk på knappen "Add Interface" (om du ser det ene eller det andre er versjonsavhengig, men begge deler gir det samme resultatet). Navngi den på en fornuftig måte (jeg har bare kalt den "UZB1"). Velg så riktig interface. Hvis du har en Zee2 med innebygget interface velger du dermed "Internal", har du UZB1 velger du "Z-wave.me UZB", har du Z-stick velger du "Aeon Labs Z-stick". Og så videre. Det siste er å velge riktig COM-port (hvis du ikke har et innebygget interface). I Windows kan du finne COM-porten i Device Manager (Windows-tast + X → Device Manager → COM-ports). Jeg er ingen Linux-expert, men jeg fant den som vist i bildet under: Når alt dette er gjort, trykker vi på det røde symbolet med gul bakgrunn øverst for å aktivere interfacet. Hvis alt nå er vel, endres teksten til "Initializing". Og deretter blir det røde symbolet grønt. Interface'et er "node 1" i nettverket. Voliá! Du kjører nå Z-wave. Gratulerer! Inkludering Men å kunne snakke et språk er jo litt kjedelig hvis det ikke er noen å snakke med! Så vi må legge til noen flere noder. Først en Fibaro Dimmer 2 (FGD-212). Først må du få en elektriker til å koble opp noden hvis det er en mikromodul til fast installasjon. Gå til Plugins → Z-wave → Controller Management, og utvid controlleren din (f.eks. "UZB") ved å trykke på pilen i den gule sirkelen. I nedtrekksmenyen velger du "Add/Include a Node". MERKNAD: Personlig bruker jeg alltid "Add/Include a Node Unsecurely", utenom for dørlåser. Trykk Start. Nå må vi aktivere "inkluder"-funksjonen på noden. Mange noder har en knapp du typisk skal trykke på 3 ganger for å sende en "NIF", en "Node Information Frame". Mikro-moduler fra Fibaro og Qubino har en knapp på selve enheten, men man kan også bruke den eksterne bryteren ("S1") til dette. Etter litt tenking, legger HomeSeer til noden. Som vi ser roter Fibaro det litt til for oss om endpoints (det er en lang historie, den korte er at Fibaro feilaktig rapporterer at den er en multi-endpoint enhet, altså rapporterer den et ekstra endpoint den ikke har). Det skal vi imidlertid fikse i del 4. Naviger så til View → Device Management, og a) trykk på knappen "Show all" under de fler-fargede knappene øverst til høyre, eller b) velg "Node 2" (eller hvilken node du nå legger til) i menyen "Floor". Da får vi opp alt vi har i HomeSeer til nå: Skrur vi av og på "Switch MultiLevel 1" skal lyset gå av og på. Ekskludering Ekskludering, det vil si fjerning av en node fra nettverket, er, som navnet tilsier, det omvendte av å inkludere en node. Og prosedyren er også tilsvarende enkel. Gå til Plugins → Z-wave → Controller Management. Utvid controlleren. Finn "Remove/Exclude a Node" i nedtrekksmenyen og trykk "Start". Aktiver "inkluder"-funksjonen på den fysiske enheten (trykk 3 ganger) på samme måte som når du la den til. Enheten fjernes nå fra nettverket. Optimalisering EDIT: Hvis du har et veldig stort nettverk, la oss si større enn 40-50 noder på fast strøm, så anbefales det ikke å optimalisere hele nettverket lenger. Optimaliser heller kun noen utvalgte (faste) noder. Så helt til slutt noe av det viktigste. Som nevnt innledningsvis er Z-wave et mesh-nettverk, flere noder kan kommunisere med hverandre. Men dermed må en ny node også finne ut hvilke noder som allerede finnes i nettverket. Til det må vi kjøre en "Optimize"-rutine (andre kaller det også "heal"). Hvis du allerede har et nettverk og kun har lagt til en ny node, så går du til den nye nodens root → Z-wave og trykker på knappen "Optimize" (1 gang). Hvis du får beskjed om at det var vellykket, så trykker du på knappen "Full Optimize" (1 gang). Hvis den også er vellykket, så er du ferdig! Hvis ikke, starter du på ny med "Optimize" igjen. Hvis du har lagt til mange noder, så kan du få HomeSeer til å optimalisere alle på en gang. Gå til Plugins → Z-wave → Controller Information. Under controlleren din velger du "Optimize a Network, No Return Route Changes" og trykker "Start". Hvis noen av nodene gir en feilmelding, kan du enten optimalisere nodene manuelt, eller du kan kjøre rutinen en gang til. Når alle nodene er ferdig optimalisert, skal vi gjøre det en gang til, men denne gangen velger vi "Fully Optimize a Network". Feiler noen av nodene må "Optimize" og "Full Optimize" kjøres pr feilet node. Merk: Erfarne HomeSeer-brukere, spesielt de som brukte HomeSeer 2, vet at tidligere var det snakk om at man skulle kjører "Optimize" hele 4 ganger før man kjørte "Full Optimize". Dette er ikke nødvendig lenger. Det holder med 1 gang. Bittelitt teori: "Optimize" for en node oppdager andre noder i nettverket den er i stand til å kommunisere med, og velger ut opptil 4 forskjellige ruter fra master til node som den lagrer. "Full Optimize" gjør det samme, men lagrer også den beste "retur-ruten" tilbake til master. Oppsummering Nå har du et kjørende Z-wave nettverk, med en eller flere noder. I del 4 skal vi se på litt enkel feilretting (i de tilfellene det er nødvendig), justering av parametere og bruk av assosiasjoner for å kontrollere noder. Tidligere har vi sett på valg mellom de ulike versjonene (del 1) og hvordan man setter det opp (del 2). I del 5 skal vi se nærmere på bruk av 433MHz-teknologi med RFXtrx433, og i del 6 det skal vi behandle alle enhetene våre, navngi dem, sortere, og se litt nærmere på mulighetene vi har i grensesnittet. Spørsmål? Kommentarer? Gi et pip i kommentarfeltet!
  2. Det er et gjentagende problem dette med å assosiere forskjellige noder og at det ikke fungerer, ofte er årsaken secure/nonsecure-inkludering av de to nodene. Her kommer en kort oppsummering, som kan gjøre feilsøkingen lettere: 1. To noder som skal assosieres må (som hovedregel) begge være inkludert enten secure eller nonsecure. Unntaket er noen enheter som kan inkluderes secure og sette en parameter som sier den skal sende kommandoer til assosierer enheter nonsecure (f.eks parameter 27 på Fibaro Dimmer 2). 2. Hvis en enhet bare støtter nonsecure og du velger "Add/include node", så vil den bli lagt til nonsecure! 3. Hvis en enhet støtter secure og du velger "Add/include node", så vil den bli lagt til secure! 4. I følge HomeSeer-support så er det ikke mulig å bruke fremgangsmåten nedenfor likevel, en enhet som støtter "secure" vil vise "secure"-feltene uansett om den er lagt til "secure" eller "nonsecure", men har ikke testet og verifisert om det stemmer eller ikke. 4. Her er alternativ måte å sjekke på: 4a. https://hs3-ip/ZWaveConfig 4b. "Log send and receive device information to the HomeSeer log" 4c. Slå av/på noden 4d. Sjekk loggen: Hos meg er node 17 en Fibaro Dimmer 2 og node 35 er en Fibaro RGBW. 5. Du kan sjekke om en node støtter secure i manualen til den (i noen tilfeller). Se etter "COMMAND_CLASS_SECURE". Om det ikke står i manualen, kan du søke opp produktet her: https://products.z-wavealliance.org/regions/1/categories Inne på produktsiden kan du klikke på "View command classes" nederst på siden og se etter "security".
  3. 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
  4. 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): 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!
  5. Beskrivelse: Hvordan legge til en Fibaro vegg plugg i HomeSeer. Denne guiden er basert på "HomeSeer-skolen #3: Grunnleggende Z-wave". Dersom Fibaro Vegg plugg har vært tilkoblet et z-wave nettverk tidligere, må den først resettes før den kan legges til et nytt nettverk. I HomeSeer trykk på "PLUG-INS", "Z-Wave" og "Controller Management" Under "Z-Wave Interfaces" trykker du på , forran "Name: UZB1 z.wave transceiver" På rullegardin menyen "Actions:" velger du "Add/include a Node" Sett Fibaro veggpluggen som du ønsker å legge, til i en kontakt. Det må være kortest mulig avstand mellom Fibaro veggplugg og UZB1, monter UZB1 på en usb skjøteledning for å få disse så nært hverandre som mulig. Er avstanden for stor blir det problemer. Trykk på På siden av Fibaro vegg pluggen, er det en liten bryter, trykk denne 3 ganger. Etter at HomeSeer er ferdig med å kommunisere med Fibaro veggpluggen, trykker du på "VIEW" og "Device Management" Velg "Check all" på filtrene "Eiendom", "Rom" og "Device Type" Du får da opp en liste med 7 devices, merket med "Node 2". Dersom det ikke gikk som vist over: Noen ganger får man opp feilmelding når man legger til en Fibaro veggplugg: "Device may not be added properly to HomeSeer." Noen av device linjene i HomeSeer kan da mangle. Trykk da på linken "Fibaro Switch" på linjen: Trykk på fanen "Z-Wave" Trykk på Trykk "VIEW" og "Device Management" Det skal da være 7 Devices i listen. Dersom det fremdeles ikke fungerte, prøv å reset Fibaro veggplugg. Beskrivelse øverst i denne posten. En Fibaro vegg plugg er en "Node" (fysisk enhet) i HomeSeer, devicen vises som regel med tannhjul icon, som indikerer at det er "root device'en" til noden. Det er under denne devicen man konfigurerer noden. Hver node kan ha mange devices. Med Fibaro dukker det opp noen devices som ikke styrer noe direkte, men som er en del av hvordan veggpluggen rapporterer.. Merk de devicene som ikke har noen direkte funksjon (avkryssningsboksen på hver linje) og velg "Hide" i rullegardinmenyen under "Device List". Alternativt kan du velge "Change Eiendom" i rullegardinmenyen under "Device List" og legge dem i en egen gruppe (IKKE slett dem). Du skal da sitte igjen med: "Root Device", som er den fysiske enheten (noden) Devicen Switch, som er bryteren i Fibaro vegg plugg Devicen Power, som viset effekt (P = U x I) som oppgis i watt (W) Devicen kW Hours, som viser strømforbruk over tid (kWh) Kontrollere enhetens assosiasjoner For at veggpluggen skal kunne kommunisere over z-wave nettverket, må det settes opp assosiasjoner. Parametre for sending av energi rapporter til HomeSeer ---------- Før du fortsetter bør du lese gjennom en annen forumstråd, som beskriver anbefalt inndeling og sortering av devicer. Denne tråden heter "Organisering og sortering av Devicer". ---------- Trykk på linken "Fibaro Switch" Endre feltene "Device Name:", "Eiendom:", "Rom" og trykk på for å endre icon på denne funksjonen. Dersom du ønsker å bruke egne bilder, kan disse legges til i mappen C:\Program Files (x86)\HomeSeer HS3\html\images Når du er ferding med å endre informasjonen, trykk Informasjonen er nå lettere å forholde seg til. Gjør det samme for de siste 3 devicene.
  6. Beskrivelse: Formålet med denne guiden er å opprette regelmessig sikkerhetskopiering av HomeSeer katalogen Oppsettet baserer seg på plug-in "BLBackup" I HomeSeer, gå til "PLUG_INS" og "Manage". Trykk forran "Additional Interfaces" og i listen velger du "Utilities" og huker av for "BLBackup" plug-in. Trykk på "Download and Install" Trykk på for å aktivere plug-in. Trykk på "BLBackup" linken på den aktiverte plug-in. Trykk på "Directories" Fyll inn informasjon i feltene, slik det passer deg best. Trykk deretter på Du har da opprettet en backup i plug-in. Det neste er å få HomeSeer til å kjøre denne gjevnlig. Trykk på "VIEW" og velg "Events" Trykk på "New Group" Legg inn navnet du ønsker å bruke på gruppen Trykk på "New Event" Legg inn ønsket navn i "Event Name" På linjen "IF" trykker du Fra rullegardin menyen bak "IF", velger du "The time is this:" Velg så ønsket tidspunkt Fra rullegardin menyen bak "THEN", velger du "BLBackup: Start Backup" Legg så inn banen til mappen der du ønsker å lagre sikkerhetskopien. Du har da laget en event som kjører sikkerhetskopi av HS3. Det som gjenstår er å sjekke at denne eventen fungerer. Trykk på for å kjøre eventen en gang. Gå deretter inn i mappen der du lagrer sikkerhetskopiene, og det skal da ligge en sikkerhetskopi i mappen.
  7. Beskrivelse: Formålet med denne guiden er å legge til UZB1 Z-Wave interface i HomeSeer. UZB1 kan kjøpes fra bl.a. Tronika.no. Driverne kan lastes ned fra z-wave.me. Mer informasjon om installering av UZB1 Z-Wave interface, finner du i tråden "Løse problemet "Ingen tilgang", under installering av drivere til UZB1" I HomeSeer trykk på "PLUG_INS" og deretter "Manage"   Fra listen "Additional Interfaces" velger du "Lighting & Primary Technology"  Klikk avhukingsboksen for "HomeSeer Z-Wave" plug-in   Trykk på "Download and Install" Plug-in blir installert og legges til i listen over installerte plug-in. Trykk på for å aktivere plug-in, oppdater nettleservinduet, åpne menyen "PLUG-INS" og trykk "Z-Wave"  Velg menyvalget "Controller Management"   Trykk "Add Interface"  Trykk på tekstfeltet "Name:", skriv inn et meningsfylt navn og trykk "Submit".  I feltet "Interface Model:" velger du "Z-Wave.me UZB"   For å finne riktig Serie port (com port), trykker du Startknappen, skriv inn "Enhetsbehandling" og trykk på "Enhetsbehandling" i listen. Se i listen "Porter (COM og LPT)", hvilket port nummer som UZB1 har fått tildelt. I dette tilfellet COM6. Velg rett COM port under nedtrekks menyen "Serial Port:" Trykk knappen "Add"   Trykk deretter på for å aktivere plug-in   Systemet vil da jobbe litt med å aktivere   Dersom alt går som det skal, endres iconet til . Plug-in skal da være klart til bruk.
  8. Beskrivelse for Windows 7: Formålet med denne guiden er å løse installasjons problemer med driverne til UZB1 Z-wave interface. UZB1 kan kjøpes fra bl.a. Tronika.no. Driverne kan lastes ned fra z-wave.me. Mer informasjon om z-wave og interface finner du i tråden HomeSeer-skolen #3 . Installasjonsprossess fra begynnelsen: Hvis problemet "Ingen tilgang" oppstår: Når man åpner filbehandling og ser på de nedlastede filene, er katalogen og filene trolig markert i grønn farge. Dette vil si at filene er krypterte, og det er ikke mulig å installere dem uten å fjerne krypteringen først. For å fjerne krypteringen, gjør følgende. Høyreklikk på katalogen med driverfilene Trykk på "Egenskaper" Trykk på "Avansert..." Fjern markeringen foran "Krypter innhold for å sikre data" Trykk så "OK" Trykk "Bruk" Trykk "Ok" Trykk "Ok" Katalogen og driver filene skal nå være i sort farge. Det er nå mulig å installere driveren for denne enheten.
  9. @Moskus har et script som holder orden på offentlige fridager: Dessverre holder ikke denne styr på dager du er hjemme utover de offentlige fridagene - sykedag, innklemt dag, vinterferie, høstferie, påskeferie, sommerferie, osv, osv. Dvs at hvis du bruker dette til å styre senking av temperatur når du er på jobb, så blir det veldig kaldt disse dagene! Min løsninger er å lage en egen Google Calendar for "huset", som jeg leser av via Google sitt API (med PHP) og oppdaterer HomeSeer utifra det. Jeg kjører på Linux, men ser ingenting i veien for at samme løsning kan kjøres på Windows. PS: Dette bruker PHP fra kommandolinje, så man trenger ikke kjøre en webserver med PHP-støtte eller åpne noen porter i brannmurer, osv. 1. Aller først, implementer @Moskus sitt script fra lenken over og sjekke at det virker. 2. Deretter er det bare følg denne guiden og se at du får tilgang til å lese ut data fra din primære Google-kalender: https://developers.google.com/google-apps/calendar/quickstart/php 3. Så lager du en egen "hus-kalender". Gå deretter inn på innstillinger for kalenderen og finn kalender-ID'en: 4. Legg inn dette scriptet som "HomeSeer.php" (og rediger de 4 øverste linjene): 5. Legg til et event i "hus-kalenderen" og sjekk at den listet opp når du nå kjører "php HomeSeer.php". 6. Sett opp følgende event: Da skal "fridag"-devicen oppdateres seg basert på kalenderen i tillegg til faste fridager fra scriptet til @Moskus.
  10. Del 3: Z-wave-håndtering Nå har vi valgt en HomeSeer-versjon, og vi har satt det opp slik at det i det minste sviver. Men HomeSeer trenger å snakke med omverdenen for å være til nytte. En protokoll til det er Z-wave. Forbehold: Dette er skrevet med HomeSeer-versjon 3.0.0.297 og Z-wave plugin-versjon 3.0.1.93. Deler av det som står her kan ha blitt endret senere. Veldig kort om Z-wave Z-wave er en protokoll som både kan sende og motta beskjeder. Hver Z-wave enhet kalles en node, utenom sjefs-noden som kalles master controller. Flere noder som snakker sammen og med samme master controller er et nettverk. Når en node mottar en beskjed ("skru lyset ditt på") så kvitteres det tilbake til master controller. For å justere et eller annet (f.eks. dimme-tid, følsomhet for bevegelsessensorer, etc) sendes en parameter til noden. Z-wave lager et såkalt "mesh nettverk". Nodene snakker med flere andre noder, og kan sende beskjeder videre fra en til en annen, og dermed har man sjeldent dekningsproblemer. Interface/controller Man trenger et interface slik at programvaren kan kommunisere med den virkelige verdenen. Hvis du har valgt en hardware-boks fra HomeSeer, så følger det med. Hvis du har valgt kun programvare, må du kjøpe et. Mange bruker UZB1 (versjon 5.2 kan med oppdateres), andre bruker Z-stick Gen 5. Disse kobles til maskinen via USB. Noen av oss bruker til og med Z-NET, et ethernet-interface fra HomeSeer (det er hendig hvis du kjører HomeSeer på en virtuell maskin, eller trenger å plassere interfacet et stykke fra serveren). Akkurat nå er det uansett viktig å sørge for at interfacet/controlleren (jeg bruker ordene litt om hverandre) støtter Z-wave Plus. Ellers kan det nevnes at UZB1 har en fordel over Z-stick: HomeSeer kan ta backup av UZB1 og "restore" den tilbake til den samme eller en annen controller/interface. Det er også mulig med Z-stick, men da må du bruke Aeon Labs egen Windows-programvare. Du har valgt et interface? Bra, da fortsetter vi med å legge det til i HomeSeer. Aller først sjekker vi at Z-wave plugin'en kjører. Det gjør vi ved å gå til Plugins → Manage. Når dette er gjort går du til Plugins → Z-wave → Controller Management. Se under overskriften "Z-wave Interfaces". Hvis du ser et interface der, så trykk på den gule pilen for konfigurasjon. Hvis ikke, trykk på knappen "Add Interface" (om du ser det ene eller det andre er versjonsavhengig, men begge deler gir det samme resultatet). Navngi den på en fornuftig måte (jeg har bare kalt den "UZB1"). Velg så riktig interface. Hvis du har en Zee2 med innebygget interface velger du dermed "Internal", har du UZB1 velger du "Z-wave.me UZB", har du Z-stick velger du "Aeon Labs Z-stick". Og så videre. Det siste er å velge riktig COM-port (hvis du ikke har et innebygget interface). I Windows kan du finne COM-porten i Device Manager (Windows-tast + X → Device Manager → COM-ports). Jeg er ingen Linux-expert, men jeg fant den som vist i bildet under: Når alt dette er gjort, trykker vi på det røde symbolet med gul bakgrunn øverst for å aktivere interfacet. Hvis alt nå er vel, endres teksten til "Initializing". Og deretter blir det røde symbolet grønt. Interface'et er "node 1" i nettverket. Voliá! Du kjører nå Z-wave. Gratulerer! Inkludering Men å kunne snakke et språk er jo litt kjedelig hvis det ikke er noen å snakke med! Så vi må legge til noen flere noder. Først en Fibaro Dimmer 2 (FGD-212). Først må du få en elektriker til å koble opp noden hvis det er en mikromodul til fast installasjon. Gå til Plugins → Z-wave → Controller Management, og utvid controlleren din (f.eks. "UZB") ved å trykke på pilen i den gule sirkelen. I nedtrekksmenyen velger du "Add/Include a Node". MERKNAD: Personlig bruker jeg alltid "Add/Include a Node Unsecurely", utenom for dørlåser. Trykk Start. Nå må vi aktivere "inkluder"-funksjonen på noden. Mange noder har en knapp du typisk skal trykke på 3 ganger for å sende en "NIF", en "Node Information Frame". Mikro-moduler fra Fibaro og Qubino har en knapp på selve enheten, men man kan også bruke den eksterne bryteren ("S1") til dette. Etter litt tenking, legger HomeSeer til noden. Som vi ser roter Fibaro det litt til for oss om endpoints (det er en lang historie, den korte er at Fibaro feilaktig rapporterer at den er en multi-endpoint enhet, altså rapporterer den et ekstra endpoint den ikke har). Det skal vi imidlertid fikse i del 4. Naviger så til View → Device Management, og a) trykk på knappen "Show all" under de fler-fargede knappene øverst til høyre, eller b) velg "Node 2" (eller hvilken node du nå legger til) i menyen "Floor". Da får vi opp alt vi har i HomeSeer til nå: Skrur vi av og på "Switch MultiLevel 1" skal lyset gå av og på. Ekskludering Ekskludering, det vil si fjerning av en node fra nettverket, er, som navnet tilsier, det omvendte av å inkludere en node. Og prosedyren er også tilsvarende enkel. Gå til Plugins → Z-wave → Controller Management. Utvid controlleren. Finn "Remove/Exclude a Node" i nedtrekksmenyen og trykk "Start". Aktiver "inkluder"-funksjonen på den fysiske enheten (trykk 3 ganger) på samme måte som når du la den til. Enheten fjernes nå fra nettverket. Optimalisering EDIT: Hvis du har et veldig stort nettverk, la oss si større enn 40-50 noder på fast strøm, så anbefales det ikke å optimalisere hele nettverket lenger. Optimaliser heller kun noen utvalgte (faste) noder. Så helt til slutt noe av det viktigste. Som nevnt innledningsvis er Z-wave et mesh-nettverk, flere noder kan kommunisere med hverandre. Men dermed må en ny node også finne ut hvilke noder som allerede finnes i nettverket. Til det må vi kjøre en "Optimize"-rutine (andre kaller det også "heal"). Hvis du allerede har et nettverk og kun har lagt til en ny node, så går du til den nye nodens root → Z-wave og trykker på knappen "Optimize" (1 gang). Hvis du får beskjed om at det var vellykket, så trykker du på knappen "Full Optimize" (1 gang). Hvis den også er vellykket, så er du ferdig! Hvis ikke, starter du på ny med "Optimize" igjen. Hvis du har lagt til mange noder, så kan du få HomeSeer til å optimalisere alle på en gang. Gå til Plugins → Z-wave → Controller Information. Under controlleren din velger du "Optimize a Network, No Return Route Changes" og trykker "Start". Hvis noen av nodene gir en feilmelding, kan du enten optimalisere nodene manuelt, eller du kan kjøre rutinen en gang til. Når alle nodene er ferdig optimalisert, skal vi gjøre det en gang til, men denne gangen velger vi "Fully Optimize a Network". Feiler noen av nodene må "Optimize" og "Full Optimize" kjøres pr feilet node. Merk: Erfarne HomeSeer-brukere, spesielt de som brukte HomeSeer 2, vet at tidligere var det snakk om at man skulle kjører "Optimize" hele 4 ganger før man kjørte "Full Optimize". Dette er ikke nødvendig lenger. Det holder med 1 gang. Bittelitt teori: "Optimize" for en node oppdager andre noder i nettverket den er i stand til å kommunisere med, og velger ut opptil 4 forskjellige ruter fra master til node som den lagrer. "Full Optimize" gjør det samme, men lagrer også den beste "retur-ruten" tilbake til master. Oppsummering Nå har du et kjørende Z-wave nettverk, med en eller flere noder. I del 4 skal vi se på litt enkel feilretting (i de tilfellene det er nødvendig), justering av parametere og bruk av assosiasjoner for å kontrollere noder. Tidligere har vi sett på valg mellom de ulike versjonene (del 1) og hvordan man setter det opp (del 2). I del 5 skal vi se nærmere på bruk av 433MHz-teknologi med RFXtrx433, og i del 6 det skal vi behandle alle enhetene våre, navngi dem, sortere, og se litt nærmere på mulighetene vi har i grensesnittet. Spørsmål? Kommentarer? Gi et pip i kommentarfeltet! Vis full oppføring
  11. psv021

    Lag din egen regnsensor

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

    Introduksjon til NodeMCU

    Jeg har skrevet en introduksjon om NodeMCU, les den her: https://www.hjemmeautomasjon.no/forums/topic/1690-nodemcuesp8266-hva-er-det-og-hva-kan-det-brukes-til/
  14. Installasjon av Domoticz på Ubuntu Server Tar i denne guiden utgangspungt i nyeste Long-term support versjon av Ubuntu Server, og selvfølgelig siste stabile versjon av Domoticz. Del 1: Installere Ubuntu Server Ubuntu Server 16.04.1 LTS https://www.ubuntu.com/download/server Installasjonen av Ubuntu Server er veldig rett frem, derfor tar jeg ikke hele den prosessen, men det er to ting jeg ville gjort: Velg "pi" som brukernavn, dette fordi veldig mange guider og script, kommandoer osv man finner på nettet tar utgangspunkt i "pi" som brukernavn. Raspberry Pi er tross alt den vanligste plattformen til Domoticz. Legg til "OpenSSH Server" under installasjon der du blir bedt om å velge ekstra programvare. (Greit å ha til SSH senere). Etter installasjon av Ubuntu Server kan det være greit å oppdatere, skriv inn følgende kommandoer: sudo apt update sudo apt upgrade Del 2: Klarkjøre for Domoticz installasjon Etter oppdatering kjør følgende kommando-er for å installere utviklingsverktøy og biblioteker å kompilere Domoticz: sudo apt install build-essential nano cmake git libboost-dev sudo apt install libsqlite3-dev curl libcurl4-openssl-dev libssl-dev libusb-dev zlib1g-dev python3-dev Nå er ting egentlig klart for kompilering, men dersom du vil ha støtte for Z-wave og/eller Tellstik/Tellstic Duo er det noe som må gjøres først (Det kan ikke gjøres i ettertid). jeg regner med Z-Wave ihvertfall er aktuellt for de fleste, Telstik er nok ikke så vanlig å bruke med Domoticz. Jeg gjør ihvertfall ikke det, men viser til følgende guide for de som trenger det: http://www.domoticz.com/wiki/Linux#Add_support_for_Tellstick Z-Wave: Skriv inn følgende kommandoer, den første inneholder et tegn som heter "tilde" og betyr egentlig det samme som %userprofile% i Windows etter hva jeg har skjønt, her er en forklaring på hvordan det skrives: http://superuser.com/questions/190025/how-can-i-type-tilde-in-the-ubuntu-terminal-with-a-norwegian-keyboard cd ~ git clone https://github.com/OpenZWave/open-zwave.git ln -s open-zwave open-zwave-read-only cd open-zwave make "fatal error: libudev.h" feilmelding ved kjøring av make? Prøv følgende: sudo apt-get install libudev-dev Ref https://github.com/OpenZWave/open-zwave/issues/902 Del 3: Installere Domoticz Da er det på tide å installere (vet ikke om det er rett ord men) Domoticz, dette gjøres ved å kjøre følgende kommandoer: cd ~ git clone https://github.com/domoticz/domoticz.git domoticz cd domoticz cmake -DCMAKE_BUILD_TYPE=Release . make Dette vil ta litt tid. Feilmelding "CMake is not able to find BOOST libraries" på cmake?, prøv følgende: sudo apt-get install cmake libblkid-dev e2fslibs-dev libboost-all-dev libaudit-dev Ref https://stackoverflow.com/questions/24173330/cmake-is-not-able-to-find-boost-libraries Har du ting koblet til USB som domoticz må snakke med? (interface f.eks), Se https://www.domoticz.com/wiki/Linux#Allow_non-root_user_to_access_ttyUSB.2A_ports Ferdig . Del 4: Starte Domoticz automatisk ved boot Du er i utgangspunktet nå i rett mappe, men for å vær sikker skriv følgende: cd ~ cd domoticz Kjør så følgende: sudo cp domoticz.sh /etc/init.d sudo chmod +x /etc/init.d/domoticz.sh sudo update-rc.d domoticz.sh defaults Neste sted er å endre oppstarts-scriptet, dette kan gjøres rett i konsollen med "nano" editoren, men for oss Windows-folk er det ganske tungvindt. Jeg bruker WinSCP til å logge meg rett inn på serveren slik at jeg kan redigere filen ved bruk av en normal tekst-editor. WinSCP finnes her: https://winscp.net/eng/index.php gå til /etc/init.d/ og åpne domoticz.sh (da man i utgangspunktet kommer til ~ ved innlogging må man gå tilbake et par kataloger først. Se til at brukernavnet stemmer. Her stemmer det, så jeg gjør ikke noe med det. Men er der feil, så rediger filen til korrekt brukernavn og lagre. Del 5: Starte Domoticz Re-start server med følgende kommando og Domoticz skal starte opp automatisk: sudo reboot Gå til følgende nettadresse fra en klient i nettverket: http://HOSTNAME:8080/ HOSTNAME kan forøvrig eventuelt byttes ut med IP-adresse. Da er Domoticz installert og det var slutt på denne guiden. Den er basert stort sett på følgende wiki-artikkel, men mye er ikke inkludert. http://www.domoticz.com/wiki/Linux Anbefaler derfor å skumlese over den også. Du har nå satt opp Domoticz, men eventyret har såvidt startet Her er forøvrig noen nyttige kommandoer for manuelt starte/stoppe/re-starte, eller sjekke status på Domoticz: sudo service domoticz.sh start sudo service domoticz.sh stop sudo service domoticz.sh restart sudo service domoticz.sh status Håper dette kommer til nytte for noen, installasjon av Domoticz var ikke barebare for meg første gangen som hardbarka Windows bruker
  15. Etter å ha lagt ut noen Powershell Script her, bla for Radnett og Pollenvarsel tenker jeg å lage en guide for å kjøre dem på en hensiktsmessig måte. Windows Task Scheduler, eller bare "Oppgaveplanlegging" som det heter på norsk er en grei funksjon man lenge har hatt i Windows, både på klient og server-siden. Jeg tar i denne guiden utgangspunkt i engelsk Windows 10, men prosedyren er mer eller mindre lik i alle nyere windows-versjoner. Powershell scripts er ikke helt rett frem å kjøre automatisk, det av to grunner. For det første er ikke scriptet i seg selv et program (men et script som skal åpnes i et program, powershell.exe). For det andre er det som standard begrensninger knyttet til Execution Policy (begrensinger ment for å hindre kjøring av ondsinnede script). Det kan så klart settes "unrestricted", men det må gjøres for både x86 og x64 versjonen av Powershell separat og er vel ikke akkurat anbefalt, selv om jeg er veldig glad i å gjøre det selv. Uansett, fremgangsmåte følger: - Start Windows Task Scheduler (kjør taskschd.msc) - Høyreklikk på "Task Scheduler Library" -> "Create Task..." - Nytt vindu spretter opp, her kommer det flere faner, "General", "Triggers,", "Actions", "Conditions" og "Settings". Her fyller du inn følgende: General: Name: Navn på task, f.eks "Test task for kjøring av powershell" Ville også huket av "Run whether user is logget on or not" under "Security options", samt "Run with highest privileges" (Du vet jo hva du kjører) Triggers: Velg "New..." Her er det bare å velge hva man vil, altså når script skal kjøre, f.eks på tid. Det er to ting som er veldig viktig her. For det første dersom start-tiden er satt til før gjeldende dato og tid, da vil denne tasken aldri kjøre. Heller aldri repeteres selv om så er valgt. Det høres litt ulogisk ut, men kan du virkelig repetere noe som ikke er gjort? Nop, og datamaskiner er kverulanter. Den gjør det du sier, ikke det du mener. Nr 2 er så klart å velge "Enabled" i bunnen, dette er dog huket av som standard Klikk så "ok" Actions: Velg "New..." Her kommer triksene for å kjøre et script. Program/script: C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe <-Link til powershell.exe (funfact, uansett PowerShell versjon så ligger den i v1.0-mappa) Add arguments (optional): -noprofile -executionpolicy bypass -file "C:\powershell_script\test.ps1" <- Link til script i apostrof Start in (optional): C:\powershell_script\ <-sti til script Klikk "Ok" Conditions, Setings og History endrer jeg som utgangspunkt ikke noe i. Klikk "Ok", har du som meg fiklet med "Security options" under general må du nå fylle inn brukernavn og passord for brukerkonto med administrative rettigheter. Jeg satt mitt script til å kjøre hver dag hvert 10 minutt fra og med kl 23:15 den 09.03.2017. For å sjekket dette for testens skyld har jeg satt scriptet til å skrive en logg-fil under kjøring. Get-Date >> "c:\powershell_script\testlogg.txt" Funket som en drøm dette
  16. Tenkte jeg skulle dele min erfaring med Tasker, slik at man kan kontrollere enheter i HomeSeer, Domotics, OpenHAB eller lignende. Da jeg kun har erfaring med Homeseer, så vil eksemplene bli mot det systemet, men gjerne del "prefix" for de andre systemene, så kan jeg legge de med i tråden her. Denne Guiden vil kun fungere med Android telefon\nettbrett. Du trenger følgende. Android telefon \ nettbrett. Appen Tasker Det vi skal lage i denne guiden er, knapper på startskjermen hvor man kan kontrollere av\på brytere, slik som illustrert på bildet under. Etter at du har lastet ned og installert Tasker, åpner du appen. Om du ikke har gjort noen prosjekter tidligere i Tasker, så vil du få en lignende skjer som dette etter oppstart. Vil anbefale at du først som sist, deaktiverer "Beginner Mode", fra instillinger (Se videoanimasjon under) Når du har fått god kontroll på Tasker, så vil du garantert lage mange forskjellige prosjekter. Ikke bare mot hjemmeautomasjon, men også andre ting som du kommer på med tiden.. Derfor vil jeg anbefale at du oppretter et nytt prosjekt i tasker, slik at du har kontroll på 'Taskene'. Steg 1 Før vi begynner, så oppretter vi et nytt prosjekt med navnet "Hjemmeautomasjon". Spiller ingen rolle hva du navngir denne, om så det er "HomeSeer", "OpenHAB" eller lignende. Det er bare for at du selv skal ha kontroll på dette. I dette eksemplet bruker jeg "Hjemmeautomasjon" som prosjekt-navn. Hold nede på i et par sekunder. Du vil da få opp en ny meny, hvor du kan trykke "Add" for å opprette nytt prosjekt. Velg et navn og bekreft. Steg 2 Når dette er gjort, så kan man gå igang med å opprette en 'Task'. Dette er noe som skjer når vi trykker på knappen på startskjermen. Gå over til "Tasker" fanen øverst. Trykk på + ikonet nede til høyre Navngi Tasken med feks "Lys Stue" (eller Gang, Kjøkken ol). Dette er navnet som vil havne under knappen på startskjermen, Bekreft. Når dette er gjort vil du få opp en tom skjerm, hvor du kan legge inn forskjellige oppgaver som skal kjøres. Steg 3 Nå som vi har navngitt Tasken, så kan vi legge til en 'Action' eller handling som utføres når knappen på startskjermen trykkes. Trykk på + ikonet nede i midten av skjermen Velg 'Net' som er helt i midten. Deretter velg 'HTTP GET' Du vil da få opp et nytt skjermbilde hvor vi må fylle ut litt informasjon til HomeSeer serveren. I det øverste feltet må du skrive inn IP'en til din HomeSeer I mitt tilfelle så er IP'en: 10.0.0.111, denne er jo selvfølgelig forskjellig hos de fleste, så her må du skrive inn din Homeseer IP. Kjører du på Port 80 (som er standard), så skriverdu kun IP uten port. Bruker du en egen port til Homeseer legger du den til etter IPen. eks: 10.0.0.111:8082 Under "Path", så må man skrive inn JSON-stien til Homeseer, slik at når man besøker den adressen så vil den enten skru lampen av eller på. I dette tilfellet blir det: JSON?request=ControlDeviceByLabel&ref=82&label=On "ref=82" tilsvarer enhet (device) nr 82 i oppsettet. For meg er denne spesifikke lampen nr 82. hos deg kan det gjerne være 10 eller 150. Du finner denne ID'en ved når du går inn på homeseer, velger den av\på bryteren du vil kontrollere Trykker man på navnet på bryteren "Switch Stue/Vindu" (for meg), så vil man se sin egen "ref=ID" i addresselinjen øverst i nettleseren. eks Mens "label=On", vil bety at den skrur på bryteren på den aktuelle enheten. Denne endres til "Off" dersom du skal skru av bryteren igjen. Har du en DimmerSwitch hvor du kan justere lysstyrken, slik som dette: så bruker du følgende Path istedenfor. JSON?request=ControlDeviceByValue&ref=82&value=50 for 50%, eller 100, 25, 0. osv. Dette kommer jeg tilbake til en senere i en annen guide, for hvordan man enkelt kan lage en dimmer switch på hjemskjermen! I dette eksemplet forsetter vi med: JSON?request=ControlDeviceByLabel&ref=82&label=On som path. Når du har fylt ut din IP adresse og ditt eget "ref" nummer, så vil du få noe lignende dette: Trykk deretter "tilbake"-knappen på telefonen. Ikke trykk på som er øverst i menyen, da vil den tro at du vil endre handling og informasjonen du har skrevet inn går tapt. Når du har gått tilbake, så vil du se at du har lagt til én handling, som gir et signal til Homeseer serveren om at den skal skru på lyset. Du kan nå gå inn på Homeseer og skru av bryteren. Når det er gjort trykker du på -knappen i Tasker, så skal lyset\bryteren i teorien gå på. Går lyset på, så fortsetter du videre! Skjer det ingenting så må du gå igjennom koden så se at du har skrevet det inn korrekt. Problemer, så spør du i tråden her Steg 4 Nå som vi har lagd en handling som slår på lyset, så må vi lage det slik at om man trykker knappen igjen så vil knappen skru seg av. For å gjøre dette så må man opprette en "If"-statement, slik at "Om lyset er av, skru det på, ellers skru det av". Når du er inne på tasken "Lys Stue" (eller hva du har navngitt den), så trykker du på + nede, slik man kan legge til en ny handling i tasken. Trykk på + Deretter "Task" Så "If" Du får da opp et nytt vindu hvor du kan lage en variabel. I det første feltet kan du skrive inn %LysStue Man bør alltid starte med stor forbokstav på variablene. Man får da tilgang på de fra andre "Tasker"(oppgaver), noe som er nyttig på langt sikt. I felt nummer 2 skriver du "Off" Når det er gjort vil man oppdage at "IF"-en er under spørringen til HomeSeer. Denne må vi flytte opp et hakk, sli kat den sjekker om lyset er "Off" først. Om man tar tak i høyre delen av linjen på "If", så kan man "dra" den oppover med fingeren (eller nedover), slik at man kan endre rekkefølgen. Nå som vi har fått litt orden i sysakene, så legger vi til at den endrer variablen %LysStue til "On" etter at Tasken har sendt en kommand til homeseer om at den skal skru den på. For å gjøre dette: Trykk + nede i midten for å opprette ny handling Trykk videre på Variables Deretter Variable Set Skriv inn %LysStue i første feltet og "On" i feltet under. Man kan også trykke på merkelappen til høyre, så få opp variablene i en liste, noe som går litt fortere når det på sikt blir en del variabler man vil ha med. Se animasonsklippet under. Når dette er gjort legger man inn en "Else"-statement. Trykk + Deretter Task så Else Så bruker du tilbake-knappen på telefonen. Du vil da se at den har lagt på en "Else" i slutten. Så det tasken nå vil gjøre er å sjekke om variablen "LysStue" er Off, om den er det så skrur den på lyset. viss ikke så gjør den noe annet. I vårt eksempel skal den skru lyset av. Nå må vi kopiere "HTTP GET"-handlingen, slik at vi slipper og fylle ut all informasjonen på nytt. Hold nede fingeren på "HTTP GET" i et par sekunder. Deretter trykker du som kopierer handlingen. Hold ned på "HTTP GET" igjen, så trykk på den vil da lime inn handlingen igjen. Da vi har 2 like handlinger, så må vi flytte ned den ene, slik at den er plassert under "Else". Da de på nåværende tidspunkt er identiske, så spiller det ingen rolle hvilken av dem vi flytter ned. Når dette er gjort går du inn på den nederste "HTTP GET" handlingen og endrer Path'en slik at den slutter på "Off". JSON?request=ControlDeviceByLabel&ref=82&label=Off Gå så tilbake og legg til en "Variable Set", hvor du endrer %LysStue til "Off". Deretter kan du legge til en "End If" som er plassert samme sted som du fant "If" og "Else" Nå som vi har kommet så langt, så kan du igjen forsøke og trykke på -knappen. Trykk gjerne et par ganger (vent litt mellom hver gang), så ser du om lyset går på eller av. Steg 6 Nå som dette er gjort må vi finne et ikon som passer til handlingen. For å gjøre dette trykker man på deretter "Built-in icon" Scroll deg nedover, så finner du noe som passer Nå er handlingen ferdig. Nå må vi bare få den over på startskjermen. Gå til startskjermen på telefonen, legg deretter til en "Widget". Prosedyren for dette er litt forskjellig fra telefon til telefon. Viola! Har du spørsmål, eller problemer eller andre inputs, så kommenter gjerne! Dette er forøvrig min første "Guide" så man kan desverre ikke forvente for mye. På sikt regner meg jeg med at jeg lager guider på hvordan man lager slider på hjemskjermen slik at man kan regulere lysstyrken, eller nivået på rullergardiner ol. Evt 'hurtigtast' på låseskjermen til ting om man befinner seg hjemme i huset, dersom dette er av interesse.
  17. Her er en kort oppsummering om enkle tiltak man kan gjøre for å holde Z-wave-nettverket friskt og raskt: https://drzwave.wordpress.com/2017/01/20/seven-habits-of-highly-effective-z-wave-networks-for-consumers/ Dette er intet nytt, men greit å se det oppsummert: Minimer polling Ha mange nok enheter for å dra nytte av mesh Plasser controller/interface sentralt Optimize/Heal netverket Hvis en node ikke fungerer, eksluder og SÅ inkluder på nytt Batterilevetid, og hvordan maksimere det Fjern døde noder i controller/interface
  18. Baserer meg på @Merkos "mal", så all ære til han for en (forhåpentligvis) vellstrukturert guide.. ? Anbefaler å lese gjennom den ettersom at den tar deg gjennom noen av de mer grunnleggende funksjonene i Tasker. Eksempelet er basert på OpenHAB, men kan "lett"(alt er lett for de som kan det ?) endres til andre systemer. Denne Guiden vil kun fungere med Android telefon\nettbrett. Du trenger følgende. Android telefon \ nettbrett. Appen Tasker Appen AutoVoice Du kan også ha glede av: Appen AutoWear Steg 1 Sett mobilens inndata språk til det ønskede språket. Steg 2 Åpne Tasker og slå på Allow External Access og slå av Beginner Mode. Beginner mode skjuler noen muligheter, slik som variabler, noe vi kommer til å bruke i neste steg. External access brukes av AutoVoice. Steg 3 Før du gjør dette steget så kan du med fordel lage et prosjekt. [Se steg en i denne guiden] Legg inn variabler for server og port. Her kan du selv velge hva variablene skal hete, bare husk å bruke de samme senere. Dette kan selvfølgelig også brukes mot hostname dersom det ønskes. Steg 4 Lag en task for å sende data til systemet, denne delen vil variere fra system til system(i dette tilfellet, OpehHAB med et string item kalt VoiceCommandNor). Trikset her er å sende data til det "itemet"/device-en som brukes til å prosessere tale kommandoer. I OpenHAB bruker jeg en modifisert versjon av dette scriptet. Steg 5 Lag en profil for når talekommando er identifisert fra AutoVoice. Her bruker jeg nøkkelordene "kan du", som vil si at jeg må si "kan du" før hver kommando. For eks. Kan du skru på lyset i stua. Du er nå ferdig med Tasker oppsettet. Nå kommer det bare den delen der du må prosessere kommandoer, du kan eventuelt lage kommandoer i tasker for hver handling. Men det krever mer oppsett i tasker og jeg personlig liker å la sentralen ta seg av all prosessering (har 5 enheter i bruk, så greit med konfigurasjonen på en plass). AutoVoice kan lytte til talekommandoer fra Googles talesøk app, alltid lytte via Continuous mode og via smartklokken din gjennom appen AutoWear. Se her for info rundt oppsett og bruk at AutoVoice.
  19. Flere har nevnt at man kan lage seg en egen antenne til RFXtrx433e, Tellstick og linkende. Jeg tenkte jeg kunne lage en liten guide til hvordan. Deler: 2 stk aluminiumsplater 1. 15 mm bred, 365mm lang 2. 15 mm bred, 465mm lang 1 stk kobberleder lendge: 17,2cm og diameter: 1.5mm2 eller 2,5mm2 1 stk kobling type F(hun-hun) - http://www.ebay.com/itm/10pcs-F-Type-Coax-Coaxial-Cable-Coupler-Female-Jack-Adapter-Connector-/302020170927?hash=item4651ce14af:g:a-EAAOSwqfNXkNRf Litt epoxy 1 stk Overgang fra kobling type F(Han) til SMA(Han) - http://www.ebay.com/itm/181085600157?_trksid=p2057872.m2749.l2649&ssPageName=STRK%3AMEBIDX%3AIT Fremgangsmåte: 1. aluminiumsplate 1 og 2, bøy dem 50° ca 17,5 cm fra den ene enden, etter 1,5 cm bøyer du den igjen 50°. 2. Stripe 2 skal du deretter bøye 50° ut før du bøyer den 90° ned. Du skal da sitte igjen med: 3. Bor deretter et hull i "spissen" på hver aluminiumsstripe (8mm i diameter). Bor også to hull i stripe 2 for skruer til å feste antennen i veggen. 4. Sett kobberledningen i den ene enden av kobling type F(hun-hun) og sikre den med litt epoxy. 5. Monter kobling type F(hun-hun) i "spissen" av begge aluminiumsstripene og skru dem sammen med de medfølgende mutterne. 6. Koble på overgang og du er ferdig.
  • Medlemsstatistikk

    6 780
    Totalt antall medlemmer
    1 891
    Flest pålogget
    phatzz
    Nyeste medlem
    phatzz
    Ble med
×
×
  • 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.