Gizmo

Synser litt om dette: Jeg tenker at det ikke er noe enkelt svar her og at mange faktorer kan spille inn. Krever kanskje litt måling og testing for å finne ut hva og under hvilke betingelser ting vil lønne seg. Dette vil vel eksempelvis være avhengig av energikilden man bruker (hvor effektiv den er), varmetapet til huset, og om man har mulighet for å lagre energi. Eksempelvis: Dersom man har vannbårent varmesystem og 800 liters akkumulatortank, så vil det vel fremdeles kunne lønne seg å kjøre nattsenking, og booste 800 liters tanken med varme på nattestid dersom prisen er lav. Men sparepotensialet blir kanskje mer knyttet til flytting av forbruket til et tidspunkt når prisen er lav, enn nattsenkingen i seg selv?

Delen om feilretting av assosiering og manglende on last level bør kanskje oppdateres. Ser ut til at det ble fikset i versjon 3.0.1.246 av z-wave plugin. Jeg har i alle fall kjørt reskann og med den versjon ble asossiasjoner og last level satt riktig. Som beskrevet her:

20% på Clas Ohlson er verdt å nevne, ellers har jeg ikke funnet noen superdupertilbud.

AMS er installert og er i gang med å sette opp alternativ 1. Venter på at BKK skal åpne porten men setter opp softwaresiden nå. Har kommet til Node-red, men den liker ikke helt koden som @Salvesen har tilbudt i den vakre guiden. Koden blir ikke akseptert av node-red og kan ikke importeres. Muligens bare copy-paste feil med linjeskift? Men finner ikke feilen. Noen som kan lime inn korrekt kode fra node-red her? Fant feilen. Dessuten litt annet oppsett i siste versjon av node-red. Her er den som fungerte hos meg:

Kult! Noen som har fått dette til å fungere med mqtt mot HS også? Ingen grunn til at det ikke skulle fungere? (Bortsett fra alle tings iboende f..nskap)

Jeg bruker også SDJ-VStat, genial plugin! Men jeg bruker ikke auto-funksjonen i pluginen. Siden plugin tillater tre statuser - høy, lav, frost - så har jeg istedenfor latt veksling mellom disse bli styrt av tidsstatusen til huset (lav på natten og når vi er ute). Bruk av autofuksjonen til vanlig lar vel seg også kombinere med f.eks : Når vi drar på ferie - sett SDJ-VStat til "frost" OG "definer setpoint temperatur for frost til x grader".

Kan jo løses på mange måter, men jeg har løst tilsvarende problemstillinger ved at husets virtuelle tidsstatus (Natt, morgen, dag etc) også kan ha verdien "tidsstyring slått av". Dersom denne er gyldig slutter huset å veksle tidsstatus gjennom døgnet (dette er en "group condition" i eventene som får tidsstatusen til å veksle gjennom døgnet). Dermed kan alt varme og lysstyring følge døgnrytme, men en annen logikk tre inn når vi drar bort på ferie.

Riktig - fremgår tydelig av manualen at det kun er Bluetooth direkte mot lås og at det hele settes opp via appen: https://danalock.com/wp-content/uploads/2018/10/PADV3-BT-EN-manual.pdf

Jeg vet ikke om APIet til Nobø tillatter at man får rapportert inn målt temperatur fra hver ovn? Dersom det kan sendes helt til Homeseer så er jo Nobø ovnene muligens en ok løsning siden det gir deg temperaturavlesning i hvert rom. Løsningen jeg skisserer koster jo fort minst 800-900 kroner pr. rom dersom man kun bruker z-wave produkter. Det blir en god del billigere dersom man velger å bruke 433mhz kommunikasjon (f.eks NEXA produkter), ulempen er enveis kommunikasjon så jeg droppet det. Dersom huset skal bli smart så har man i praksis behov for bevegelsessensor og lysmåler i de fleste rom. Så det er også en del av regnestykket dersom man vil gå den veien. For min del var det også et poeng at jeg ville ha styring av to varmepumper og varmekabler på badet inn i samme system. Strømregningen vår har nok godt ned noe på grunn av et bra styringssystem, men tviler sterkt på at jeg vil sparer penger på denne hobbyen. Forøvrig er det relativt lett og ikke minst skikkelig gøy å gjøre huset smart.

Det har du jo rett i. Men sammen med temperatursensor og Homeseer e.l. og litt smarte eventer så blir det skikkelig smart - inklusiv automatisk veksling mellom komfort, sparetemperatur, frostvakt, automatisk overstyring av dagsenking på en fridag eller når noen kommer hjem litt tidlig, osv, osv. Alt dette kan oppnås ved å koble Nobø til HS eller et annet system med et åpent API. Men man kan altså oppnå det samme uten å måtte styre med Nobø sitt API, og ovnene kan man beholde slik de er.

Jeg var i en lignende situasjon som deg @SteinarH. Hadde fem Nobø ovner mot Hub og var nyskjerrig på smarthus. Er jo mange muligheter, men selv om det er kult at Nobø nå har åpent API er det er fullt mulig å beholde ovnene og gjøre dem smarte(re) uten å gå veien via Nobø hub. Jeg valgte å gå for Homeseer (HS). HS styrer om ovnene er av eller på via en Fibaro wallplug (z-wave). Nobø er altså koblet ut, har bare satt max temperatur rimelig høyt som en ekstra forsikring mot for høy temperatur (det samme kan selvsagt gjøre med vanlige dumme ovner @kvisle). Har installert temperatursensorer i disse rommene (diverse varianter). I HS styres det hele med en fin plugin for virtuelle termostater som heter SDJ-VStat. Dags og ukeprogram, samt overstyring når vi er bort på ferie eller en helg skjer dermed i HS. Ulempen med å gjøre det slik når man først har Nobø hub er at det koster litt ekstra penger (plugg for å slå av/på strømmen til ovnen). En fordel er at jeg opplever at temperaturstyringen er blitt mer nøyaktig. Ovnene står stort sett under vinduer, de nye temperatursensorene er plassert i en sone hvor vi oppholder oss. Dette er stort sett multisensorer som også registrerer bevegelse og lysintensitet. Litt som å gå over bekken etter vann, men er ganske fint på HS siden av bekken ?

Nå sporer vi vel av tråden til @Dag.... men for å fortsette med det (og siden jeg selv gjerne vil lære lure triks): Er det en betydelig bedre angrepsvinkel å gjøre det med flere triggere i samme event (oversikt/mindre systemressurser i HS?) eller er det mest et spørsmål om organisere ting på en måte man liker? Det er litt tilfeldig at jeg har gjort det slik, men fordelen er at jeg kan organisere alle eventer som gjør noe i en gruppe. Så jeg har eventer som styrer lys i soverom x i en gruppe, og eventer som styrer varme i hele huset i en annen gruppe. Hva som utløser eventene kan så organiseres på lignende vis: lysbrytere, sensorer, tidspunkt, husstatus, etc i ulike grupper. Lurer forøvrig på om det finnes en teknikk for å få til smooth dimming med denne typen brytere. Fungerer det med at "button held" dimmer ned/opp (hvordan kan det implementeres helt konkret) og at "button released" avslutter dimmeoperasjon?

Enig! Men jeg har gjort dette siden jeg også kjører slike lys-events i andre sammenhenger også, eksempelvis som del av en scene som utløses av en sensor etc. Er det ikke viktig lærdom fra HS-skolen dette å splitte opp i subrutiner? ?

Jeg er ingen superekspert, men har en del Nodon brytere (av typen Wall Switch). Disse er satt opp slik at et trykk på bryteren kjører et event. Knappen fungerer jo slik at når den pressen skifter den status. Status er avhengig av om knappen er trykket 1 eller 2 ganger, holdt inne, osv. Så hver bryter kan styre flere eventer. Godt mulig at det finnes en fin måte å få til gradvis dimming ved å holde inne knappen, men jeg har ikke forsøkt dette. Eksempler på et enkelt event under. Lag først et event som utløses manuelt - her er det zigbee lyspærer som styres, men er det samme logikken for en Fibaro dimmer: Lag så et nytt event, dette knytter endret status for Nodon bryteren til det første eventet, slik at lyset blir styrt.

Jeg har bare hatt min i rundt tre uker. Står montert i kjellerdør. Brukes 3-4 ganger daglig. Er nå på 92% batteri. Registrering ved bruk av nøkkel fungerer helt fint, og jeg har ikke det problemet som @Televimsen beskriver på sin. Men ser at dette kan være et problem, jeg måtte ha et par runder med kalibrering før vrideren registrerte riktig punkt for åpen/lukket. Den låste opp/igjen i starten også, men fikk statusen "lock jammed" - sannsynligvis fordi punktet for å sette vrideren for låst førte til at den dro til for hardt. Nå fungerer dette feilfritt hver gang. Enig med beskrivelsen av hvor responsiv den er, 2-3 sekunder er typisk. Jeg bruker PPlocation & geofency for å fortelle huset om jeg er hjemme eller borte. Har koblet dette til låsen med events slik at den låser opp døren når jeg kommer inn i hjemmesonen og låser døren når jeg forlater sonen (hvis låsen har status som ulåst). Digg å komme hjem på sykkel fra jobb til åpen kjellerdør. Også kjekt å kunne slippe å låse etter seg. Danalock appen tilbyr en tilsvarende løsning med tracking på telefon i kombinasjon med blåtann, har ikke prøvd denne. Ungene bruker imidlertid danalock appen for å gå inn og ut uten nøkkel. Opplåsing skjer da med blåtann. Det har vært populært i starten, men de blir nok snart lei, men kjekk mulighet de dagene de har glemt nøkkel. Av negative ting kan det nevnes at den er relativt stor og klumpete, samt støyer litt. Greit på kjellerdør, mindre aktuelt på vår hoveddør (vi har ikke vindfang/lukket yttergang).

Takk for oppklaring - da blir jo Nest litt mindre aktuell. Selv om det er mye annet som trekker opp, så er det kjipa at de ikke er Z-wave.

Er i tenkeboksen på løsning for røykvarslere. Pusser opp rom for rom, så har mulighet for å kjøre dem på 230 volt. Fungerer bevegelsessensoren bra mot Homeseer? Følsom nok til å kunne droppe multisensor 6? Regner med at kommunikasjonen mot HS skjer via wifi?

Jeg er ingen låsekspert men har forstått det slik at det normale er at innvendig låssylinder roterer selv om ikke synlig vrider gjør det. Er slik jeg tolket informasjonen som Intin gir om Danalock og som gjorde at jeg satset på teste ut denne låsen. Intin skriver https://www.intin.no/wp-content/uploads/2017/06/passerdanalock.pdf

Har nylig installert Danalock V3 på kjellerdør, gammel tråd men rapporterer min erfaring: Låsen skiller mellom trådløs opplåsning (Z-wave/blåtann) og manuell opplåsning (nøkkel utenfra/vrider innenfra). Dette rapporteres også til HS. Så med Danalock v3 man vet om døren er låst eller ei. I alle fall så lenge man har en "normal" låskasse hvor vrider inne roterer når man bruker nøkkel ute. Men for å være helt sikker på at døren faktisk er låst bør man vel ha magnetsensor som sjekker at døren faktisk også er lukket. Montering og integrasjon i HS gikk forøvrig knirkefritt. Og den er skikkelig klumpete, stor og litt bråkete. Men fungerer fint til vår kjellerdør!

OK. Jeg er litt allergisk mot å holde Google kontinuerlig oppdatert på min posisjon, så jeg pleier kun å skru på GPS når jeg faktisk trenger den for å navigere. Men dersom man skal tro de mest paranoide ga jeg fra meg store deler privatlivet idet jeg puttet en smartphone i lomma, så det er mulig jeg bare lurer meg selv... Det fine med Geofency appen er at den ikke sender data rundtomkring, kun en post/webhook til HS når den skal (om man stoler på dem da). På min Iphone står Geofence for 1% av batteribruken, GPS bruk er minimalisert men må/bør stå på. Fungerer glitrende!

Alltid noe å lære. Slo av omstarten i natt og kjører fremdeles stabilt. 13 timer uptime nå. Ikke spesielt imponerende (har jo kjørt en måned før), så kan vel ikke friskmeldes helt enda. Men arbeidshypotesen om at dette skjedde pga treigt nettverk / dårlig plassering av controllere - i kombinasjon med at nettverket øker med en node eller to i uken - må ansees som styrket.

Da har jeg skaffet meg 2 meter USB forlengelse og flyttet sticken bort fra tv-benken, rundt et hjørne slik at den skal være betydelig mer skjermet fra andre tign som kan forstyrre. Og jeg har kjørt en ny runde med testing i Z-seer. Dette forbedret responstiden på command testen til rundt 1-1,5 sekunder. De fleste response testene ender noe høyere, rundt 2-2,5 sekunder. Noen få noder ender fremdeles på 4-5 sekunder på responstesten. Jeg er altså ikke nærheten av ditt halve sekund @Moskus, men tydelig at det var en bedre løsning enn den jeg hadde. Hvorfor noen av nodene er treige er litt vanskelig å forstå. Noen av de som er langt unna er kjappe, mens et par av dem som står 2-3 meter fra sticken uten hindringer i veien er fremdeles treige. Men dette er Fibaro 2 dimmere, så kan jo handle om plassering av antennen? Uansett - krysser fingrene for at dette løser problemet.

Ok. Det var en nyttig tilbakemelding i feilsøkingen! Jeg har vel ca. 25 noder på fast strøm, 35 totalt. De er fordelt på 3 etasjer (trehus), rundt 60 kvm (10x6 meter) i hver etasje. Batterinodene står slik at det stort sett er 2-3 meter til en strømnode, men med 1 unntak (Der er det vel 5 meter og 2 vegger). I Z-seer får jeg omtrent uten unntak opp at ruten til alle nodene er direkte. Og alle unntatt to står med 100K. Men pakketesten er jo en bedre indikasjon. Gitt det du sier så kan det altså være at problemene skyldes tregt nettverk, og at dette har blitt verre etterhvert som antall noder har økt (fremdeles under oppbygging)? Jeg hadde på en måte avskrevet dette som mulig feilkilde siden det virker kjapt og responsivt i lange perioden. Men det kan kanskje ha skyldes likevel? Må også innrømme at jeg ikke har en veldig lang USB kabel fra maskinen som kjører HS til sticken. Den er vel kanskje 30cm, nok til å få sticken "ut i det fri" bak TV benken. Men det er mye annet stæsj under TVen: 1 macmini, 1 switch med POE og en ubiquiti ac pro.... Så kanskje jeg skal bruke lunsjen til å kjøpe en 2 meter lang USB kabel? Eller er det en dårlig idé med så lang kabel? Heller flytte hele HS serveren vekk fra dette området? Det med støyende strømkurser er vel utenfor mitt kompetanseområde (hvordan finner man ut det?). UZB1 krever russisk doktorgrad i fysikk og datateknologi - eller at jeg kjøper enda én, med med riktig firmware.

OK. Da starter jeg med en dobbelsjekk i Z-seer. Blir først i kveld Jeg gjorde dette i går. Er det vanlig å vekke opp batterinoder for å teste slikt. Det gjorde jeg ikke. Men sjekket alle de andre. Ingen noder med pakketap. Kan sende 10 command pakker til alle på under 2 sekunder (typisk 1,25). På respons er det større variasjon. Noen går like kjapt, mens andre bruker opp til 6 sekunder. Forsøkte å optimalisere de som var treige når jeg var igang, men det hadde ingen effekt. Men når jeg først var i gang så optimaliserte jeg en god del av nodene i systemet. Likevel: Fikk en ny "breakdown" sent i går kveld. Men som alltid er alt fint etter restart. Har også satt opp en automagisk restart av HS hver natt kl 05.30, så det skumper og går. Skal jo ikke være slik! Gjenstående alternativer i feilsøking (???): 1. kjøre pakketest med z-seer på batterinoder 2. resette oppsettet av COM port hvor jeg har Z-wave controlleren (?) 3. enable detailed bug logging for en kortere periode for å se om det er noe som skaper mye traffikk... 4. kjøpe (enda!) en ny controller Litt av utfordringen er at jeg altså kan ha en kjapt og rensposivt systemet i x timer før det hele clogger seg helt... Og X varierer ganske mye. Tror det er den siste versjonen som er ute. 5.32 er trekt tilbake. Men du må nok bruke Z-Wave plugin 3.0.1.210 eller høyere for å få det til å virke på versjoner over 5.06 Jeg har faktisk forsøkt å bruke UZB1 stick med en betaversjon av Z-wave pluginen. Var vel rundt 10 dager siden. Gjorde dette pga problemene jeg har. Men heller ikke den versjonene av Z-wave aksepterte firmwareversjonen jeg har på UZB1. Siden det var en betaversjon valgte jeg å gå ned igjen til .190

Det burde være OK, men hva skjer hvis du fjerner dem? Alltid gøy med eksperimenter. Fjernet dem nå. Så får vi se. Gjorde samtidig en trippelsjekk på hva jeg faktisk poller. Har faktisk fremdeles 17 devicer som blir pollet. Dette er temperatur, luftfuktighet og KWh. Samtlige av disse devicene tilhører noder som går på nettspenning og er således i kontinuerlig "lyttemodus". Tenker at jeg lar de stå foreløpig.