DiderikFrom

Suverent! Kanskje ConBee er mest relevant for meg, men tror kanskje jeg må lese meg litt opp først.

Er ikke dette det beste fra to verdener? Jeg gjentar kanskje meg selv her inne, men det fins ingen som har bedre lys enn Hue. Dimmere som bor i veggboksen gjør svært sjelden en god job (bare se gjennom forumet her på alle problemen folk har), og jeg vet ingen som kan justere fargetemperatur (i alle tilfelle ikke dersom vi snakker 220v). Hue klarer alt dette, men kan ikke bruke tradisjonelle brytere. "Fordelen med å ha dobbelt opp" er at du kan bruke bryteren som før, men dimme perfekt (også langt ned), og justere fargetemperatur, ved hjelp av events trigget av bryteren. Sånn gjør i alle tilfelle jeg det. Det meste skjer jo automatisk, men det hender jeg vil bruke bryteren, eller gjester gjør det.

Mitt favorittprogram! Jeg har sett alle episodene!

Prøv å se i manualen som fulgte med wall-plug'en (dersom du har den). Jeg har opplevd lignende feilmeldinger når jeg forsøker å sette en ikke-eksisterende variabel -- da fordi jeg ser i en manual tilhørende en nyere (eller eldre) versjon av produktet. Fibaro har i noen tilfeller helt forskjellige variabler på v1 og v2 av produktene.

Hue har definitivt de beste lyspærene og er best på justering av lyset, men det er dog et viktig poeng med lysbryter. Jeg ville gjort det slik (for å få det beste fra to verdener): Hue i spottene dine, og (f.eks.) en to-kanals bryter for z-wave på veggen. Spottene er koblet til S2 uten fysisk bryter, og du har en fysisk bryter koblet til S1 (med impulsfjær). Så setter du opp regler i kontrolleren din for hva som skal skje med spottene avhengig av hva du gjør med S1. Alternativt kan du sette opp en scenekontroller (eller en dimmer dersom du vil ha mulighet til enkelt å bytte til full z-wave). Det blir jo ikke den billigste løsningen, men den beste (mener jeg).

Nå så jeg at det hos meg også har dukket opp en «Gallons». Jeg har fire rgbw (to 22.22 og to 25.25). Jeg har kun "Gallons" på én av de med firmware 25.25. Jeg er på nyeste versjon av z-wave plugin, men "Gallons" kan ha dukket opp når som helst i løpet av det siste året.

Jeg kan ikke huske sist jeg hadde kræsj, så oppetid er her også tid mellom oppdateringer som krever omstart, men det kan fort gå en måned eller to. Hos meg starter systemet også på ca. 15 sekunder. Trror jeg har 8 plugins. (Det gjelder å ha et skikkelig operativsystem, som linux... )

Slik var det ikke hos meg. Google forteller meg at udevadm oppfører seg noe forskjellig i forskjellige linux flavours. Jeg fikk ingen symlink. 'sudo ls -al /dev/ttyUSB-UZB1' ga meg ingen output etter å ha brukt SYMLINK+="ttyUSB-UZB1”. (Jeg forsøkte med flere reboot, samt 'sudo udevadm trigger' uten at noe skjedde.) Da jeg som foreslått i lenken jeg la ved i posten over, byttet til SYMLINK+="ttyUSB-ZStick-5G", dukket symlinken opp, og jeg kunne endre til SYMLINK+="ttyUSB-UZB1” (som tråde i effekt ved neste reboot). $ sudo ls -al /dev/ttyUSB-UZB1 lrwxrwxrwx 1 root root 7 Jul 26 17:47 /dev/ttyUSB-UZB1 -> ttyACM0 Jeg vet ikke hvorfor, men da jeg for et år eller to siden drev med dette sist, sluttet dette å virke da jeg oppgraderte fra raspbian wheezy til jessie (jeg er nå på stretch). Sisteposten her oppsummerer godt: http://www.domoticz.com/forum/viewtopic.php?t=15364 Men igjen, jeg tror dette er noe forskjellig fra linux til linux.

Denne fikk jeg ikke til å virke siste jeg brukte Domoticz, nå tester jeg domoticz igjen, og fortsatt ingen suksess... Men svaret er her: http://www.domoticz.com/forum/viewtopic.php?t=15364 Når man setter dette opp må man bruke nøyaktig samme symlinknavn som i wiki'en første gang. F.eks. SYMLINK+="ttyUSB-ZStick-5G" selv om man har en UZB1. Man kan så heller endre til det man vil etter at man har sett at det fungerer. (Jeg har også en liten mistanke om at navnet må begynne med ttyUSB, men det er jeg ikke sikker på.)

Jeg har totalt gitt opp dokumetasjonen -- den er uforståelig. Her er det prøv og feil... Dog fungerer det PI'en utmerket for mine behov etter noen tweaks.

Jeg mener dette er et kjent problem, også for andre custom implementasjoner av lyd til sonos, men jo enklere oppsett og mindre kompleks kommandoer man sender, jo mindre problemer. Jeg hadde mye av det da jeg tidligere kjørte jishi-sonos-node med lengre kombinasjoner. (Men sluttet med jishi-sonos-node da jeg byttet til HomeSeer.) Nå kjører jeg ingen tts, men spiller bare av ferdige lydfiler (der jeg på noen allerede har brukt google tts). En veldig sjelden gang får jeg nå noen slike problemer du nevner, men det er etter enkelte forholdsregler. Jeg kan ikke se at dette har endret seg etter hvert som jeg har oppgradet PI-versjon. Mine forholdsregler er at at jeg spiller av en lydfil (play URL lenket til en share ev. på HS-maskinen) med stillhet etter (ev. før) jeg skal kjøre noe gjennom sonos. Det kan også være et poeng at man kjører "unlink(?)"-kommandoen først, i hvertfall på den som skal være master, og dersom jeg skal legge til flere soner, kjører jeg først ungroup på dem også før jeg legger til. Dette har jeg spesielt merket dersom jeg prøver å sende noe til en gruppert sone -- da kan det fort komme noe helt annet.

On/off enhetene har også dimming på det firkantede lyset på selve dingsen. "Dimme-dra-dings" er der fortsatt i HS3 selv om parametrene er satt slik at lyset på dingsen alltid er av. (Så, ja, du kan slå av lyset på dingsen dersom det var et spørsmål.) Mine to on/off-enheter har det med å pipe innimellom, ikke særlig høyt, men nok til at vi innimellom begynner å gå rundt å lure på hvor lyden kommer fra. Det er verst dersom man bruker USB-utgangen, men den kan fint pipe allikevel.

Du setter opp polling under root-devicen, men etter å ha googlet Neo Coolcam PIR ser det ut som om den er batteridrevet? Da blir det kanskje vanskeligere. Dersom den er "always on", kan du fint polle.

Dersom du ikke skal kjøpe noe nytt, er eneste løsningen jeg ser å legge inn en poll på lux etter at LED-list-PÅ-eventen har kjørt. Så bruker du resultatet tilå avgjøre om LED-listen skal på eller ikke. Det vil funke, men du vil sannsynligvis få en ganske merkbar forsinkelse.

Nei, i tidligere versjoner av skriptet brukte jeg en funksjon som kallet eksterne funksjoner hele tiden (hver gang jeg ikke fikk det il i LUA....) Edit: Slik dyttet jeg output til linux/bash-funksjonen awk: local handle = io.popen("curl -s 'http://localhost/JSON?request=getstatus&ref="..idxUserVarOcta.."' | awk -v FS=',\"value\":' '{print $2}' | awk -v FS=',' '{print $1}' | tr -d '\n'")

Hm! Jeg kjenner ikke MQTT, men JSON er jo bare et curl call til en nettadresse. Kan du bruke curl (http) til å nå MQTT? I så tilfelle er det bare å bytte ut curl-callet i skriptet, og du trenger ikke kunne noe LUA.

Du har altså en Altibox sentral med ruterfunksjonalitet, men den kan ikke «kontrollere dhcp»? Dersom du kvier deg for å kjøpe noe nytt, kan du sannsynligvis fint ha to rutere/to kommuniserende subnet? Den gamle (med kun 10/100 og dhcp) kan du bruke på homeseer og ting du ikke trenger full hastighet på, mens du knytter det som trenger full hastighet til den nye fra Altibox? Jeg har ikke erfaring med Altibox, men ut fra bildesøk, ser dne ut til å ha en switch med fire utganger. Ellers er mikrotik veldig bra (om enn noget kompleks å sette opp), men min døde, så nå bruker jeg en gammel Netgear med tomato firmware, og en ekstra 20-port gigabit switch samt to Ubiquiti Unifi.

Det gjør nok ikke det. Som det fremkommer over, går man fra homeseer konfigurert på mono v 3.x til mono 4 eller høyere (eller Windows), mister man triggerne, og må bygge opp eventene på nytt.

Ja, dersom man ikke kjører på linux er det sikkert best med noe som er native for HomeSeer/Windows. Lurte på å skrive det i .NET selv, men skriptet har ganske mange conditions og .NET er jeg ganske grønn på, så da måtte jeg gjøre det på en måte jeg kan godt. Ikke alt er like godt annotert i skriptet, men bare spør dersom noe er uklart.

Det er det samme for meg. Søk er ikke enkelt, google funker best.

Og nå kommer det viktigste: skriptet. Det er et bash-skript og må lagres med endelsen .bash. Jeg har et for hver rullegardin, og kaller dem Blinds_{ROM}.bash, f.eks. Blinds_Living_Room.bash Du må bestemme deg for hvor du skal lagre disse, og etter at de er lagret, må de gjøres kjørbare med f.eks. 'chmod ug+x Blinds_Living_Room.bash'. Da får eier og gruppen rettigheter til å kjøre/eksekvere skriptet. Skriptet baserer seg på at du har tatt tiden det tar for rullegardinene å rulle fra helt åpen tilstand til helt lukket tilstand (downtime), og fra helt lukket tilstand til helt åpen tilstand (uptime). Denne tiden (i millisekunder) plottes inn begynnelsen av skriptet sammen med referenceID til den virtuelle devicen du noterte over. Du må også notere og plotte inn ID'en til motoren i RFXcom. Jeg brukte litt tid før jeg skjønte at dette fungerer veldig bra med kun disse to målene -- jeg forsøkte å regne ut akselerasjon og forskjellige hastigheter ut fra hvor åpen/lukket rullegardinen var, men det var helt unødvendig. Det er veldig liten forskjell fra 40% lukket fra gang til gang. Dersom man kjører mye opp og ned i halvåpen tilstand vil det bli en liten forskyvning, men dette nullstilles hver gang man åpner eller lukker helt. Blinds_RoomName.bash Se nå post 2 igjen. Hver gang verdien til den virtuelle devicen endres, kjøres skriptet og når rullegardinene har endret posisjon, oppdateres verdien til den virtuelle devicen. Første gang du kjører, er det best å kjøre helt opp et par ganger, og så ev. helt ned slik at de midlertidige filene kan skrives.

Opprett en virtual device som du kaller «Roller Blinds» og legger til rommet der du har rullegardinene. Dersom du vil bruke den med Alexa, passer du på at «Voice command» er avkrysset. Noter deg «Reference ID». Under Status Graphics, setter du det hele opp som følger (men du kan senere endre prosentknappene til å passe akkurat dine favorittposisjoner): Endre «Slider» til «Drop down» dersom du foretrekker det. Du må nå opprette en ny event: Trykk senere på «Edit» og legg til banen til der du har lagret skriptet som kommer i neste post. Poenget her er at hver gang denne virtuelle device'n settes til en verdi, kjører dette skriptet.

Dette er en guide for custom oppsett av RollerTrol RF rullegardinmotorer (m.nu selger vel den minste versjonen av disse) i HomeSeer 3. Dette baserer seg på en virtual device og en event som trigger et eksternt skript. Dette er et bash-script, så i utgangspunktet er dette for de som har en linux-installasjon av HS3, men det burde være mulig å kjøre et bash-skript fra windows også, og det vil være veldig lett å få dette til å kjøre på domoticz. Dette er min v2 av et slikt skript. Grunnen for å lage dette er å få inn følgende funksjonalitet på en RollerTrol rullegardinmotor som allerede er oppe og går med RFXcom på homeseer: 1. HS3 skal vite om rullegardinen er oppe, nede eller hvor mange prosent åpen/lukket den er. 2. Rullegardinen skal kunne gå direkte fra fra X til Y prosent uten å måtte åpnes eller lukke helt først. 3. Det skal være knapper i HS for de mest brukte posisjonsene og en nedtrekksmeny/slider for antall prosent lukket. 4. En veggbryter/fjernkontroll skal kunne fungere på klassisk vis: en knapp for opp, en for ned, og dersom rullegardinen er i bevegelse skal et trykk til på hvilken som helst knapp stoppe den. I tillegg kan man valgfritt ha ekstra knapper for favorittposisjoner. 5. "Alexa, set Study Roller Blinds to 40%." 6. Dersom rullegardinen er X prosent lukket og man setter den til X prosent nok en gang -- da skal det ikke skje noe (f.eks. trigger grunnet høy direkte stråling). Slik ser det ut i HS3. Jeg har kalt rullegardinene for «Roller Blinds» fordi Alexa ofte misforstår «Blinds». Jeg har gjort dette på alle rullegardinene, og alle heter det samme, men location 2 er forskjellig basert på hvilket rom de er i. «Stop» er egentlig unødvendig siden hvilken som helst knapp stopper rullegardinene dersom de allerede ruller. Ny post følger...

Det blir vel en hard måte for meg også, men nå må jeg bare ta en timeout og se om det dukker opp en løsning i løpet av det nærmeste året. Hvis ikke er det vel bare å sette seg ned og brette opp armene. Jeg forsøkte dette i forskjellige implementasjoner, men fikk det ikke til å fungere. Mange av serifikatene listes som ugyldige etter at de er importert. Det gjelder bl.a. noen av sertifikatene diverse tråder hevder trengs for å nå HomeSeers Updater. (Akkurat som Pete her: https://board.homeseer.com/showpost.php?p=1298515&postcount=130). Det er godt mulig dette fungerer på noen plattformer (32-bit?), men jeg tror etter hvert som mono 3.2.8 blir eldre og eldre at det blir vanskeligere og vanskeligere. Jeg har fiklet med mozroots certmgr en god stund for å bruke https for å bruke Telenors SMS API. Etter at APIen ble lagt ned har jeg ikke tenkt på dette, og det er gått enda lenger siden mozroots ble avviklet. Jeg testet å migrerere til Windows i går uten hell. Akkurat samme problem... @Moskus skriver her at han migrerte fra Zee2 med mono 3 til windows med hell, men det funket altså ikke for meg og diverse andre. Kan det ha vært fra en Zee2V2 (som jeg forstår har mono 4)? Men her er jeg på gyngende grunn -- jeg kan ingenting om troller'ene... Men dersom det fins en workaround blir jeg veldig glad.

Jeg skriver dette for å få ut frustrasjon, hjelpe andre i samme situasjon, og dersom noen har bedre forslag tas de imot med takk. Etter at jeg oppdaterte til HS3 3.0.0.318 (Linux) (godt mulig jeg har hoppet over et par versjoner), kommer denne feilmeldingen på Plugins-->Manage: Det vil altså si at man får ikke oppdatert sine plugins eller installert nye... Dette skyldes at fra HS3 3.0.0.312 endret man protokollen fra http til https. På linux kreves mono for å kjøre HomeSeer3. Standard versjon av mono på debian jessie (både raspbian og «vanlig») er mono 3.2.8, og den versjonen har ikke støtte for ssl. Det løste man tidligere ved å laste inn sertifikater fra mozroots, men det er en stund siden mozilla sluttet å tilby dette, og det virker nå på færre og færre distribusjoner etter hvert som mozroots blir mer og mer utdatert. I denne tråden kommer HomeSeer-folka med utdatert info de har sakset fra nettet om hvordan fikse dette, men mozroots er altså ikke lenger støttet, og dette fungerer ikke! https://board.homeseer.com/showthread.php?t=187612&page=7&styleid=8&styleid=1 I debian jessie er det meget enkelt å oppdatere mono ved å legge til monos egen repo: http://www.mono-project.com/download/#download-lin-debian Problemet med dette er: Dersom man migrerer HS3 fra mono 3 til mono 4/5 eller windows, mister man alle triggere på eventene. Man kan ikke bare legge til triggerne, men må lage alle eventen på nytt. For meg er det ikke et alternativ å legge inn alle eventene på nytt -- då må jeg bruke hele ferien. Så hva gjør jeg? Løsningen for meg ble å hacke til en oppgradering til mono 3.12.0 -- den siste versjonen av mono 3, og med innebygd støtte for ssl (ca-certificates-mono installeres som del av mono-complete). Dessverre fins det ingen pakke fra mono-project for mono <5 for debian jessie, så jeg legger i stedet til pakken fra forrige debian-versjon: wheezy. Fjern først mono fullstendig, alle pakker, jeg gjorde (kjør dette som to separate kommandoer): sudo apt remove --purge --auto-remove mono-complete sudo apt remove --purge --auto-remove mono-runtime 'dpkg-query -l | grep mono' skal nå ikke gi noe output. Nå kan du legge til mono 3.12.0 fra monos eget wheezy-repo: #Legg til nøkkel sudo apt-key adv --keyserver hkp://keyserver.ubuntu.com:80 --recv-keys 3FA7E0328081BFF6A14DA29AA6A19B38D3D831EF # Legg til mono repo fra wheezy, låst til versjon 3.12.0 echo "deb http://download.mono-project.com/repo/debian wheezy/snapshots/3.12.0 main" | sudo tee /etc/apt/sources.list.d/mono-xamarin.list sudo apt-get update # Legg til mod_mono repo echo "deb http://download.mono-project.com/repo/debian wheezy-apache24-compat main" | sudo tee -a /etc/apt/sources.list.d/mono-xamarin.list # Legg til libgdiplus echo "deb http://download.mono-project.com/repo/debian wheezy-libjpeg62-compat main" | sudo tee -a /etc/apt/sources.list.d/mono-xamarin.list sudo apt-get update sudo apt-get install mono-complete Og ikke glem å reinstallere de ekstra pakkene HS3 krever iflg installasjonsveiledningen. Noen av dem vil ha blitt slettet da du fjernet den gamle versjonen av mono. sudo apt-get install chromium mono-vbnc libmono-system-web4.0.cil \ libmono-system-design4.0.cil \ libmono-system-web-extensions4.0-cil \ libmono-system-runtime-caching4.0-cil flite (Et annet alternativ hadde vært å nedgradert operativsystemet til debian wheezy, og så lagt til monos repo og låst mono til 3.12.0, men wheezy har ikke så lang tid igjen med oppdateringer/support.) Nå skal HS3 igjen starte, og ssl/https virker i HS3/mono, og du beholder alle eventene! Dette er i det store og hele ganske sløvt av HomeSeer. Dette gjelder ikke bare for oss som kjører HS3 på «vanlig» linux (eller pi), men det gjelder migrasjon fra Zee til Zee2, eller annen troller. Dersom HomeSeer bare hadde nevnt i installasjonsintruksene at man låste seg til mono 3 dersom man brukte det, kunne man bare installert mono 4/5. Mono 4 har vært ute i årevis. Sisteposten her oppsummerer dette godt: https://forums.homeseer.com/showthread.php?t=184607 Jeg håper ommleggingen til ssl tvinger frem en offisiel løsning siden mange har trollere med mono 3, og mozroots kommer nok snart til å slutte å virke. Jeg håper dette hjelper noen...