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

Vinnerliste

  1. Godot

    Godot

    Medlemmer


    • Poeng

      6

    • Innlegg

      90


  2. Tore Andre Rosander

    • Poeng

      3

    • Innlegg

      113


  3. ZoRaC

    ZoRaC

    Crew


    • Poeng

      2

    • Innlegg

      5 744


  4. Alpøy

    Alpøy

    Medlemmer


    • Poeng

      2

    • Innlegg

      145


Populært innhold

Viser innholdet med mest poeng fra 09. des. 2016 i alle områder

  1. Jeg har planer om å lage en lett konfigurerbar versjon som det skal være enkelt å tilpasse til sitt eget sted. Ruter snakker jeg direkte med fra klienten og tolker svaret i javascript. For YR så har de blokkert direkte adgang, så der er det er liten proxy i PHP som går på serveren min som henter inn data og masserer det litt. Kan legge ut alle filene straks jeg har ryddet litt, her er imidlertid den enkle Ruter-koden i jQuery. Skulle bare være å bytte ut nummeret i GetDepartures-kallet med din egen stasjon, og passe på at "direction" i if-loopen er korrekt. Eventuelt legge på mer avanserte regler hvis du f.eks. bare er interessert i én av linjene. Resultatet havner i to div-er med id tubetime1 og tubetime2. function getRuter() { $.getJSON( "http://reisapi.ruter.no/StopVisit/GetDepartures/3011310?callback=?", function( data ) { var count = 0; $.each( data, function( key, val ) { var direction = val.MonitoredVehicleJourney.DirectionRef; if (direction == 2) { /* Kun togene som går i retning sentrum */ count++; var departuretime = new Date(val.MonitoredVehicleJourney.MonitoredCall.ExpectedDepartureTime); var now = new Date(val.RecordedAtTime); var minutesuntil = Math.floor((departuretime - now) / 1000 / 60); var tubetime = minutesuntil + '<span class="m">m</span>'; if (minutesuntil == 0) { tubetime = "nå"; } else if (minutesuntil > 100) { tubetime = ''; } document.getElementById('tubetime' + count).innerHTML = tubetime; } if (count > 1) { return false; } }); }); }
    3 poeng
  2. Jeg har nettopp gått over fra Domoticz til HomeSeer, benyttet meg av november-tilbudet deres på software til Raspberry Pi3. Overgangen gikk greit, byttet pga. bedre støtte på IDLock og Multireg-termostater. HomeSeer virker bedre å jobbe med på å organisere mange enheter, føler jeg har mere kontroll på ting enn jeg hadde med Domoticz. Jeg savner imidlertid det kjekke desktop- og mobilvennlige interfacet man får ut av boksen i Domoticz, og statistikk/grafingmulighetene. (Mulig det finnes som en overpriset plugin i HomeSeer? ) Jeg har laget meg eget interface til en tablet ved utgangsdøra, den kommuniserer med kontrolleren via JSON, så det var bare små omskrivinger som skulle til for å bytte fra Domoticz til HomeSeer. Her hentes det værmelding og live nedbørsgraf fra YR, og de to neste T-bane-avgangene til sentrum fra Ruter. I feltet til høyre er det kontroll for Roombaen, vi har hund, så mest praktisk å starte støvsuger på vei ut til luftetur enn å la den gå automatisk. Eventuelle alerts dukker også opp her, foreløpig har jeg bare laget for når vaskemaskin og tørketrommel er ferdig, kommer for postkasse og røykvarslere etter hvert. Når man trykker på temperatur sklir de øvrige hustemperaturene ut, og her kan man også styre gulvvarmen av og på. Natt/dagsenking skjer automatisk, men helt av/på styrer jeg herfra. Bare "ny" gulvvarme jeg har Multireg-termostater på. De rommene som hadde varmekabler fra før jeg flyttet inn har jeg ikke prioritert å bytte, det er dessuten greit at bad, gang og peisestue har varmen på hele tiden... Her er screenshoteksempel med kjørende vaskemaskin og ferdig tørketrommel. (De blinker så klart ) Idéen er at elementer som ikke er viktige akkurat nå er skjult.
    3 poeng
  3. Ble ferdig for noen uker siden, men får skryte litt av meg selv: Dette er en MySensors scene kontroller med LCD-skjerm for temperatur og fuktighet med mulighet for V_TEXT for å vise hvilken som helst tekst i displayet. Det er 2 touchknapper på baksiden av plexiglasset som aktiverer 2 forskjellige scener, plexiglasset er semitransperent slik at lyset fra displayet lyser gjennom. Den består av en arduino nano, LCD-skjerm, 2 touchmoduler og nrf24 for kommunikasjon, bruker den på soverommet så måtte ha antenne stikkende ut :\ Etter at bildene ble tatt har jeg også lagt en RGB ledlist som en firkant rundt rammen på baksiden slik at jeg kan bruke lyset til å indikere forskjellige varsler fra Domoticz. Den kan enten henges rett på vegg eller stående. Man kan ikke se det på bildene men jeg teipet hele baksiden av plexiglasset med duct tape så ikke annet lys skulle skinne gjennom, men jeg lot det være igjen en liten glipe rundt touchmodulene sånn at man kan se hvor knappene er. Har en versjon 2 på gang hvor touchknappene er bakgrunnsbelyste (4 x 0.9" OLED skjermer) hvor du kan sette egne ikoner fra domoticz. Textdisplayet vil også være OLED slik at det kun er teksten som skinner gjennom og ikke både tekst og bakgrunnsbelysningen. Jeg vil måtte bruke en PIR eller avstandsmåler som kan se gjennom plexi-en for å forhindre innbrenning når jeg bruker OLED skjermer.
    2 poeng
  4. Angående standard så er jo denne en klassiker ?
    2 poeng
  5. Hstouch er jo bare alt for artig å holde på med. Har begynt på ett enkelt grensesnitt, som mor og barn kan benytte.
    2 poeng
  6. 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!
    1 poeng
  7. Hei! Jeg får introdusere meg da jeg endelig har funnet ett Norsk forum med likesinnede Jeg heter Tore og er 28 år, alenefar og litt for mye fritid etter en arbeidsulykke for en liten stund siden. Er ganske kreativ og liker mestringsfølelsen ved å lage noe selv, driver en del med web/SEO og teknologi generelt. Kontroller/Gateway Raspberry Pi 2 med OSMC (strippet versjon av debian jessie) Domoticz Aeotec Z-stick gen 5 Tellstick Duo MySensors Serial Gateway Jeg har mye standard utstyr for styring av lys med zwave og 433mhz dimmere og vegg adaptere, men jeg kjører egentlig utelukkende DIY løsninger for det meste. Varme Kun vanlige elektriske ovner styrt med zwave stikkontakt adaptere men har også en del multifunksjon noder basert på ESP-er med reléer og temp/fuktighetsmålere. Varme blir styrt automatisk. Har en løsning for hvordan jeg skal klare å tenne opp peisen via Domoticz men det spørs hvor praktisk det blir. Lys Mye standard rett ut av boksen zwave/433mhz for dimming av vanlige lys, men også en del "moodlights" med Mysensors (Arduino + 2.4ghz nrf24). Har en del LED striper med WS2811/12b som styres av mysensors, ungene har feks stemningslys over klesskapet, har ett par større potteplanter med forskjellige effekter fra fastLED biblioteket. Jeg har også ett par hjemmelagede vegglamper med WS2811 LED striper. Alle RGB lysene i leiligheten kan aktivere alarm-modus som får alt til å blinke rødt og blått. Automasjon Her går det meste av seg selv, lys blir dimmet opp om ungene våkner om natten. Varmeovner går av og på i løpet av dagen etter temperaturen. Jeg setter vekkeklokke med en Selectorswitch i Domoticz som starter radioen på soverommet og som dimmer opp lyset både i stuen og soverommene på morgenen. Jeg har en dum robotstøvsuger som jeg styrer med en MySensors IR sender. Multimedia Har en RPi koblet til tv-en og anlegget i stuen som kjører OSMC (Kodi), her får domoticz beskjed om jeg ser på film slik at lys kan dempes automatisk. Jeg har også satt opp Hyperion som ambilight bak TV-en som både viser fargene fra skjermen og forskjellige effekter om jeg ønsker det. Totalt har jeg 4 RPi-er koblet til forskjellige typer høyttalere rundt om i leiligheten som alle har Squeezelite installert og jeg har en gammel laptop som LMS-server. Annet 4 IP-kameraer som sender snapshots ved bevegelse hos de aktuelle bevegelsesensorene om jeg har aktivert nattmodus eller bortemodus. Minstemann (3år) kan av og til vandre rundt i leiligheten på natten, så om det registreres bevegelse mellom 24 og 06 vil en stemme gi han beskjed om å gå å legge seg (jeg har en hysterisk morsom video fra den dagen jeg testet systemet). Har flere MySensors scenekontrollere som jeg har laget selv rundt om i leiligheten pluss 2 nettbrett på vegg med FlatZ temaet til Domoticz. 2 stk "clapper" som skrur av og på en gruppe med lys. 6 stk temp/fuktmålere 3 stk MySensors gass/røykvarslere (pluss gode gamle dumme røykvarslere) 4 MySensors PIR 4 Vindu/dør sensorer Pluss en del andre småting man glemmer at man har fordi det bare virker Nesten klart IKEA LED Bord med tetris og snake Hva som kommer Stemmestyring med RPi, trolig med Jasper som er knyttet opp mot Domoticz og andre moduler jeg setter sammen selv DMX styring av WS2811 led stripene Tåke/luftfukting basert på MySensors/Arduino
    1 poeng
  8. Jeezes. Jeg hadde fjernet haken på "No Password Required for Local/Same Network Login" under setup. Når jeg huket av så fungerte alt. ? Jeg får i hvertfall oppdatert sun azimuth og altitude. Jeg regner med mer data når det er sol. ? Det er liksom alltid en sånn liten fisefeil som kan ødelegge dagen.
    1 poeng
  9. Har hørt mye bra om å bruke Kinect kameraet til stemmegjenkjenning, men da anbefales Kinect SDK, som kun funker på Windows... sies det. Det finnes også noen gode søkeord som: boundary microphone og Condenser microphone Men jeg er på ingen måte ekspert i dette. Så andre må gjerne rette på meg hvis noe av dette er helt på jordet.
    1 poeng
  10. Som du sier er akustikk viktig. Men etterklangstiden i en typisk stue ligger vanligvis rundt 0,5-0,7 sekunder, så SÅ lang er ikke klangen. Med flere mikrofoner har man flere valg med signalbehandling for å få et enda bedre signal. Dette kunne vi snakket mye om men det hjelper ikke på problemstillingen. Men mikrofonvalget er ikke uviktig (uansett hva noen påstår). Man kan ikke programmere seg bort fra en dårlig mikrofon, eller; det er i det minste ganske vanskelig. Webkameraer er f.eks. stort sett laget for å ikke plukke opp for mye bakgrunnstøy og lyd på lang avstand, nettopp fordi personen som bruker dem vanligvis sitter rett foran PCen.
    1 poeng
  11. «Nye lysbrytere» for bord. David Andersen ca. 1910 sterling sølv med guilloche emalje. Dette er vel opprinnelig »tjernerbjeller», men de blir fine med passende ledning (som er i bestilling) koblet til den binære inngangen på en (gjemt) Fibaro dørsensor. Da får de scene-funksjonalitet dersom man ønsker. Bruk er ikke helt bestemt, men på nattbordet for nattmodus, for å styre rullegardiner, i stua for å endre lysmodus &c.
    1 poeng
  12. Hvis man kun ønsker å se tidspunkt for siste hendelse, f.eks. hvis man har en oversikt i HStouch over siste bevegelse på alle multisensorer, så finnes det en superenkel måte å gjøre dette på. Lag en virtual device for hver sensor du ønsker å logge - merk deg device id. Lag en event pr. enhet, sett den opp til å trigge på at multisensor registrerer "motion". Velg så å kjøre en script kommando, endre da det første tallet i kommandoen til din "Reference ID". "NOW" er jo en kjekk måte å sette inn tid/dato i en string, alternativt kan man gjøre som Iblis og benytte "DeviceLastChangeRef" som peker til device id for multisensor. I HSTouch Designer kan du nå legge til den virtuelle device i en visning, endre til StatusTrackingNormal, plukk frem den virtuelle devicen, endre til "Use Status Text".
    1 poeng
  13. Har jobbet en stund med selvlaget termostat for varmekabel, basert på arduino, arduino plugin til HS og z-wave on/off modul som tar seg av selve varmekabelen. Forsatt endel finpuss igjen på kodingen, men det ser lovende ut Har fått 3D printet et hus til den og lakkert det i Elko sin polarhvite farge, passer i standard veggboks og ramme. Planen var å bruke en NodemCU/ESP8266, men hadde ikke nok inn/utganger, så valgte å gå for en Arduino Mega med kablet nettverk, hadde en liggende fra før. Strøm hentes fra en USB lader for veggboks, i veggboksen der selve termostathuset sitter vil det bare være skjerm, knapper og et rele som styrer z-wave pillen direkte, arduinoen vil ligge i en separat veggboks for seg selv. Gulvføler er en vanntett 2m DS18B20, romføler DHT11, 128x128 OLED skjerm, mini kapasitive touch brytere (virker fint gjennom plasten) HS kan styre ønsket temperatur, samt lese ut alle temperaturer og luftfuktighet, den vil også vise om varmekablene er av/på og evt feilmeldinger. Satser på å legge ut litt mer info når den etterhvert blir helt ferdig.
    1 poeng
  14. Ikke noe kompliserte greier, men har fått ordnet "termostat" på kontoret, med nattsenking og mulighet for å skru opp temperaturen i 3 timer hvis jeg skal jobbe på kontoret. Største utfordringen jeg støtte på var at jeg ønsket en nedtelling i HSTouch som viste hvor lenge det var til "kontormodus" slo seg av, men timere i HS3 teller jo bare oppover! Takket være en del hjelp fra @Moskusfikk jeg ordnet nedtelling (https://www.hjemmeautomasjon.no/forums/topic/723-løst-timer-telle-nedover/) Utstyr: * Pluginmodul fra Nexa * Temperatursensor fra Clas Ohlson * Homeseer og RFXcom-plugin. La til virtuell termostat i RFXcom-plugin, koblet denne mot pluginmodulen og temp.sensoren. Opprettet devicer kalt "kontormodus" ("on"/"off"), "kontormodus-timer-pretty" og en timer kalt "kontormodus-timer". HSTouch (bruker IFTTT Maker Channel til å sende iOS-push når kontormodus slås av): Event for å slå på kontormodus: Event for å slå av kontormodus/etter 3 timer: Event "kontormodus-timer-pretty" (koden ligger i tråden lenket til lengre opp): Nøkkelen for å få til en timer som teller oppover er altså å ha en event som i utgangspunktet er disablet og som enables/disables når timeren startes/stoppes. Scriptet henter verdien timeren har og trekker den fra på totaltiden. Deretter formatteres tiden på ønsket format og settes som devicestring til en virtuell device, som igjen brukes i HSTouch.
    1 poeng
  15. Har satt Fibaro PowerMeter's på både vaskemaskin og tørketrommel. Det er flere formål her; 1) Varsling når vaskemaskin/tørketrommel er ferdig. Begge står litt bortgjemt i en etasje vi normalt ikke befinner oss i. 2) Varsling dersom vi drar fra huset når enten tørketrommel eller vaskemaskin går 3) Varsling dersom huset settes i nattmodus mens tørketrommel eller vaskemaskin fortsatt går. Egentlig mye det samme som GeneralVirus tidligere har beskrevet. Utstyr 2 x Fibaro PowerMeter HS3 med HStouch på ekstern klient (nettbrett på vegg) Siden verken vaskemaskin eller tørketrommel kommuniserer med noe, er tanken å derivere status via strømforbruket. Dermed starter hele øvelsen med en kjapp analyse av strømforbruket på en typisk syklus. Dette logges lett med PowerMeter. Brukte opprinnelig et script som skrev tidspunkt og forbruk til en tekstfil, men oppdaget kjapt at det var enklere å bare hente informasjonen rett fra loggen i HS3. Slik ser forbruket ut for vaskemaskinen på to tilfeldige programmer: Vaskemaskinen har ganske varierende forbruk, inkludert noen "spikes" opp til like over 2000 W. Forbruket vises derfor best på logaritmisk skala. Det er en utfordring at forbruket varierer såpass mye. Det som imidlertid er klart er at et ultralavt forbruk over tid er en god indikasjon på at programmet er ferdig. Slik ser samme grafen ut zoomet inn på de siste minuttene: Jeg legger derfor opp til å detektere den flate linjen etter at vasken er ferdig. For tørketrommelen ser forbruket litt annerledes ut (vist på lineær skala): Tørketrommelen har en funksjon som gjør at den vender (ikke "vente" slik det står i grafikken...) tøyet litt ca hvert 30 sekund etter at den er ferdig. Samme type forbruk kan ses flere ganger langs syklusen, så det i seg selv er ikke diagnostisk. Forbruket i pausene på slutten er imidlertid bittelitt lavere enn forbruket ellers, og fungerer som diagnose. Slik ser Fibaro PowerMeter ut i HS3. Det er subdevice "Power" som brukes i dette oppsettet: I HS3 setter jeg opp virtuelle devicer for å kategorisere strømforbruket. Det er nyttig, fordi man da får et ledd mellom statusen og selve forbruket. Da kan man legge inn krav om en viss varighet på forbruk osv, og man kan dermed fjerne effekten av de ultrakorte spikene i forbruk. Statusen er også en virtuell device. Som dere ser hadde jeg opprinnelig en plan om å detektere sentrifugering, men den kjappe dataanalysen viser at det blir vanskelig. Teksten i status-devicene er laget for å gi grammatisk mening når den vises i HStouch. Eventer endrer proxyene basert på avlest forbruk, og andre eventer (vist under) fanger opp endringene i proxyene, og setter selve statusene. Her er eventen som fanger opp om vaskemaskinen er ferdig med et program. Her har jeg valgt å bake inn varslingen i samme event. En litt mer ryddig måte å gjøre det på vil være å ha en egen event som styrer kommunikasjonen basert på om statusen endres til "er ferdig". Smak og behag, I guess. Verdiene for "lav" og andre forbrukskategorier justeres etter forbruket og signaturen til de ulike programmene. Utfordringen er å finne noe som er diagnostisk på tvers av alle ulike programmer. Her er det også viktig å bruke "has been XX for exactly", i stedet for "at least". Sistnevnte vil fortsette å trigge eventen i all evighet, mens førstnevnte kriterier oppfylles bare 1 gang. I praksis ble det ganske mange eventer ut av dette, og det hadde nok vært best med et script. Det får bli på sikt. Etter at screenshot ble tatt har jeg lagt inn en sjekk i disse eventene for om statusen er noe annet enn "er ferdig".
    1 poeng
Vinnerlisten er satt til Oslo/GMT+01:00
×
×
  • 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.