toonwolf

20 svar siden i går ettermiddag og av disse har 11 svart at dette problemet skjer av og til, mens 6 svarer alltid. Så altså tilsammen 17 som har svart at dette er et problem. Kun 3 svarer aldri og det er de som bruker SmartThings, Domoticz og Vera. Vera har forresten en som svarer at det skjer av og til. Dette mener jeg er nok til å konkludere med at dette er et generelt problem som gjelder i alle typer systemer og at feilen må ligge i selve låsen og ikke i systemene. Er det noen som er uenig i denne konklusjonen? Se svarene her https://docs.google.com/spreadsheets/d/1xH00DStt7_-U94c5E4f1JeYqOZdplSL0YaO1nyQUaMM/edit?usp=sharing

Enig, dette ser ut til å være eksakt samme adapter som han på finn.no skal ha 170 kr + 30 i frakt for. Om du kan vente 1 mnd. så får du den til under kr 30,-! Godt å vite at det finnes alternativer ? Han skriver "NB! slike adaptere selges av andre / andre steder også, men ikke alle lar adapteren hente ut lyden, dersom det ikke er koblet til en VGA skjerm - min klarer dette.", vet ikke om det du har bestilt fra ali fungerer uten VGA adapter @ZoRaC , men det finner du vel ut etterhvert...

Så ut som en genial løsning, har noen GEN1 som ligger å samler støv, smart om de kan brukes til dette istedet

Driver fortsatt kun i Z-Wave, men har skjønt at når det gjelder lysstyring et det ZigBee som gjelder. Takk for en meget god guide. Den vil bli god å ha!

Det som er "litt" snodig er jo at akkurat dette problemet ikke eksisterer i SmartThings ved bruk av Rboy Handler. Så langt vet jeg om HomeSeer, Fibaro Home Center og Home Assistant som har dette problemet. ID Lock har jo fått Z-wave sertifisering av ID Lock 150 så det kan jo tyde på at et eller annet har blitt gjort for at Rboy Handleren i ST skal fungere (den er forresten veldig bra). Takk til @cscheiene for tips . Her kan dere forresten se resultatene av spørreundersøkelsen

Dette går i samme kategori. Jeg har nå oppdatert spørreundersøkelsen slik at den er mer generell. Fint om du tar deg tid til å svare @Odd Erling

Da kan ALLE som har en ID Lock 150 svare på spørreundersøkelsen (også du @Mastiff ). Jeg tror nemlig at dette problemet ikke bare gjelder HomeSeer https://goo.gl/forms/xqk14rsjliT5TyUw2

Tips: ID Lock 150 "menu map"

Ok, takk for tilbakemelding. I utgangspunktet ønsker jeg å begrense dette til kun å gjelde HomeSeer og ID Lock 150 siden det er det systemet som jeg har og hvor jeg daglig irriterer meg over at dette ikke fungerer som det skal. Kan noen hjelpe meg å komme ut av det? ?

Jeg har ikke oversikt over om dette er et problem sammen med andre systemer. Jeg har kun erfaring med HomeSeer og SmartThings V3 sammen med ID Lock 150. I ST fungerer dette uten noen som helst problemer med Rboy Handler og det var også grunnen til at jeg valgte dette for en lås da jeg var avhengig av skyhøy WAF og at all funksjonalitet fungerte "out of the box". Om problemet med at brukerkoder ikke blir rapportert også gjelder andre systemer som Home Assistant kunne det kanskje være smart å legge inn dette som et valg. Fint med tilbakemelding på dette.

"kryssposter" litt siden det er veldig mange brukere av HomeSeer og ID Lock 150 som følger denne tråden. Håper det er greit ? Jeg har laget enn spørreundersøkelse som skal brukes for å dokumentere omfanget av problemet med at HomeSeer ikke alltid klarer å sende info om hvilken kode som ble brukt for å låse opp. Se mer info:

Jeg er fortsatt i kontakt med HomeSeer og ID Lock for i første omgang få løst problemet med at Access Control Notification noden i Homeseer er veldig ustabil og sjelden rapporterer riktig status. HomeSeer sier de må ha låsen for å kunne løse problemet. ID Lock har svart at de skal følge opp dette, men så langt er det ikke noe som tyder på at det faktisk har blitt sendt avgårde en låse fra ID Lock til HomeSeer. For å bedre kunne dokumentere dette problemet og finne ut av omfanget har jeg laget en liten spørreundersøkelse som det er fint om alle som har ID Lock 150 låsen og bruker den sammen med HomeSeer svarer på. Det er fint om du svarer på den også om du aldri har hatt dette problemet også! Det bør ikke ta mer enn 1 minutt å svare på undersøkelsen. Link: https://goo.gl/forms/b3zADw6EgKRUNyRm2

Dette er noe jeg har/hadde planer om å gjøre. Har ikke kjøpt noen CCA ennå, men skjønner at jeg ikke bør vente for lenge med å gjøre dette nå.

Jeg har nå testet versjon 0.0.1.0 og kan konkludere at den ser ut til å fungere uten noen bugs/problemer! Det som har blitt testet er at start og slutt fungerer både med og uten offset og triggerord brukt sammen med ..and the summary text contains... Videre har jeg også testet "Do not trigger if adjacent events" under Advanced options. Denne er kun nødvendig å bruke sammen med "Trigger after" siden "Trigger before" aldri vil ha behov for dette siden eventen har/bør ha en IF test som gjør at den ikke vil trigges om lyset er ON. Dette er nødvendig for å unngå at du trigger "before" eventen hele tiden mens aktiviteten pågår. Jeg føler meg såpass trygg på denne versjonen nå at jeg vil installerer den i "Produksjons-miljø" hvor GCalSeer vil starte eventer som styrer fysiske lys og låser. Om det dukker opp feil rapporterer jeg selvsagt. Takk for denne plugin-en @Guahtdim, så snart du legger den tilgjengelig i Updateren har du din første kunde!

Jeg synes også det var snodig at jeg fikk disse resultatene. Foreslår jeg tester det samme etter at jeg har installert ny versjon.

Hvilken sjekk bruker du (og hvilken versjon)? Jeg har nå testet følgende "IF" triggere for eventer i versjon 0.0.0.7 for både Start og End. Det ble brukt aktiviteter som hadde 1 minutt varighet og eventer uten bruk av offset (No offset trigger). Jeg har kun testet for om IF trigges slik de skal (testen slår til), ikke om de trigges av noe de ikke skal. Jeg har brukt samme IF logikk for start og end. A calendar event has a summary text: containing: start OK, end NEI (vil ikke trigges på end) matching exactly: start NEI, end NEI (vil ikke trigges på start eller end, problemer med end kan skyldes at start ikke slår lys på som er sjekken som gjøres for at end event skal trigges.) starting with: start NEI, end NEI (vil ikke trigges på start eller end, problemer med end kan skyldes at start ikke slår lys på som er sjekken som gjøres for at end event skal trigges.) Any calendar event: start NEI, end NEI (vil ikke trigges på start eller end, problemer med end kan skyldes at start ikke slår lys på som er sjekken som gjøres for at end event skal trigges.)

NB: Problemet med at det ikke trigges på slutt-tidspunkt for aktiviteten ser også ut til å gjelde om du ikke bruker offset after. ref kommentar over

Flott, en liten "feature request". I BLGData er det mulig å trigge en event ved å legge inn flere "triggerord" som skilles med en |. Jeg har behov for å kunne trigge en og samme event om det eksisterer en event som inneholder 7-8 forskjellige tekst i emnet. "test 1|test 2|test 3" osv. Om du hadde fått til å lagt til dette som et valg på en eller annen måte så hadde det spart meg å måtte lage en egen event for hvert eneste trigger-ord. Du begynner å nærme deg nå ift "mitt" behov, bare noen små justeringer nå føler jeg. BLGData er som du skriver tidligere avansert, men det du har laget er akkurat det jeg ønsker + at måten du har løst det på er bedre IMHO ved å gjøre plug-inen tilgjengelig i Event-motoren i HS.

Testet med 5 min. aktiviteter i kalenderen, fungerer ikke med "No offset trigger" eller med offset trigger satt til "after" (1 min) Har ikke testet med lengre eventer, litt "upraktisk" å teste med om du skjønner hva jeg mener..

testet denne versjonen litt nå. Autentiseringsproblematikken mot Google ser ut til å være helt fikset nå slik du også har testet. Har ikke hatt en eneste feil som jeg kan se etter at jeg installerte denne versjonen. Når det kommer til testing av Eventer fungerer det fint med start, men ikke end Jeg har to events. En for lys på og en av. Begge er satt med 1 minutt offset Har laget en virtuell device som brukes i sjekk for å hindre at den trigges flere ganger "Virtual Lights TEST" Testet med å opprette en aktivitet: "Test 2 - kl 2335-2336" Den starter kl 2334 som den skal, men vil ikke trigge "Lights off test" som jeg hadde forventet skulle startet kl 2337. Jeg har ikke kommet så langt med å teste tilstøtende (adjacent) aktiviteter. Fra loggen til HS: jan-11 23:34:00 Device Control Device: Virtual Lights Test to On (100) jan-11 23:34:00 Event Event Trigger "TEST Lights on test" Her er min event for lys på: Her er min event for lys av: Jeg har sjekket at Virtual LIghts Test er "On" etter at event lys på har kjørt noe loggen også bekrefter. Skjønner derfor ikke hvorfor event for å skru lys av ikke fungerer..

Det var snakk om at @INTIN RuneV skulle sende en lås, men det tror jeg ikke ble gjort. Jeg har vært i kontakt med både Intin og ID Lock flere ganger og siste informasjon jeg fikk fra de var i november om at de hadde vært i kontakt med HomeSeer om muligheten for å sende en lås. De fikk da beskjed om at utviklerne deres hadde andre oppdrag som hadde høyere prioritet og at de ikke hadde mulighet til å gjøre jobben nå. Jeg har som sagt sendt en ny henvendelse til ID Lock hvor jeg oppgir kontaktperson og forsendelsesadresse til HomeSeer så får vi se om de kan få ut "finger'n" og få sendt over en lås til Unaiten.

Stemmer nok det du skriver her. I følge han som oppdaterte firmware med siste oppdatering som varslet når låsen gikk i dvalemodus tok det ca 10 sek før han hørte "lyden" som varslet om dette. Det tok jo mer enn 10 sek fra jeg kjørte optimalisering til jeg testet å låse opp. Har forresten fått tilbakemelding fra HomeSeer at de tar gjerne i mot en lås for å kunne optimalisere den med HomeSeer. Har sendt forespørsel til ID Lock om de nå endelig kan sende en lås til de! Skjønner ikke hvorfor det skal ta så lang tid med å få gjort dette...

Kan det ikke være slik at grunnen til at Access Control Notification fungerte etter at jeg hadde utført optimalisering på låsen var fordi låsen ikke var i dvalemodus da jeg låste opp? Jeg får vel svar på dette i løpet av de nærmeste dagene. Har bedt om tilbakemelding fra ID Lock på hvor lang tid det går før ID Lock 150 går i dvalemodus. Da blir det enklere å sjekke om "dvalehypotesen" stemmer. Det ser forresten ut som om de nå kommer med en oppdatering av firmware hvor låsen kan sende statusoppdatering på når den går i dvalemodus. Ved en feil ble det lagt ut en oppdatering av Android-appen som gjorde at den ga en lyd etter 10 sek? som varslet om at den hadde aktivert dvalemodus. Synes det høres ut som vel kort tid for å gå i dvalemodus, men hva vet jeg.

Hypotese: ID Lock 150 går i dvale modus for å spare strøm. Access Control Notification noden i Homeseer er veldig ustabil og rapporterer sjelden riktig. Istedet for å rapportere koden som ble brukt for å låse opp vil du få "Manual lock" som er status for at døren har blitt låst, altså sist registrerte status. Min hypotese er at dvalemodus gjør at status for opplåsning ikke blir registrert av Homeseer fordi Z-wave modulen ikke "rekker" å sende denne informasjonen til Homeseer. Grunnen til at den registrerer låsing av dør nesten alltid er fordi da er ikke døra i dvalemodus. Jeg har vært i kontakt med Homeseer support flere ganger og siste melding fra de var å forsøke "optimization" under Z-wave fanen for root. Etter å ha gjort dette fungert Access Control Notification som den skulle og viste hvilken kode(plassering) som ble brukt. Jeg kommer til å la det gå noen dager nå for å se om optimization fikset problemet, men om den gjør det blir jeg veldig overrasket og det har jeg ærlig talt ikke noe tro på. Uansett så hadde det vært fint å fått tilbakemelding fra dere andre som har denne låsen og Homeseer om hva dere tror om denne hypotesen.

Dette var gode nyheter!