psv021

I dag har jeg kjøpt (mottatt) en ny UZB-1 som skal være i reserve i tilfelle den andre svikter, etter at jeg fikk kjeft av @iblis for å ta unødvendig risiko ved å ikke ha reserve-interface tilgjengelig

Jo, absolutt! Akkurat nå har jeg nettopp eskludert/inkludert begge mine IDlocker på nytt, da jeg hadde store nettverksproblemer. I prosessen fjernet jeg alle spor, inkludert disse subdevicene... Så jeg har ingen skjermbilder sånn på rappen. Men her er en kjapp forklaring: Lag en virtuell device som heter "autolås", som har to verdier: "På", og "Av". Lag et event som slår på autolås når devicen autolås settes til "På", og motsatt et event som slår autolås av når devicen autolås settes til "av". Noe slikt, fra hukommelsen: IF [autolås device] changes and becomes "Off" THEN (Z-wave actions) Set configuration parameter 1 on device [din IDlock] to value 0 Motsatt for autolås på (se IDlocks z-wave manual for å bekrefte verdiene. I HStouch bruker jeg en av/på slider, f.eks en slik: (det står en grønn "PÅ" under knappen). Når den legges inn med kun 2 verdier, 1 og 0, blir den binær (av/på) samtidig som den fungerer som en slider.

Du må nok dessverre det... Ellers ser låsen din lik ut i HS3 som mine gjør. Det er noen mangler i matrisen, så du vil få slike meldinger i loggen: Husker ikke detaljene, men den sender verdi 6 på Access Control Notification når den åpnes. Du kan manuelt legge til verdi 6 i matrisen hvis du ikke liker slike meldinger

"Borte" trigges manuelt av bryter, eller uat eller alarm. Har funnet det mest hensiktsmessig, da "borte" også slår av alle lys, kutter strøm til en del apparater, gir alarm dersom vaskemaskin eller tørketrommel står på, osv. Noen ganger vil man ikke nødvendigvis sette huset i Borte-modus hvis man bare skal ut med hunden noen minutter, osv. Men dersom alarmen skrus på, er vi definitivt borte. Jeg poller imidlertid alarmen med 60 minutters intervall, så ønsker ikke å bruke kun den som trigger. "Hjemme" trigges av bevegelse på utvalgte sensorer. Ønsker ikke at hjemme trigges av sensorer på ytterdører. Det skjer mer enn sjelden at jeg må løpe inn igjen fra bilen for å hente noe i gangen, da er det greit å slippe at hele huset slås på bare for å slås av igjen 10 sekunder senere...

Ja, jeg blir ikke kjempeoverrasket om du har rett.

Hehe OK for jeg tenkte på det som "fra node til kontroller". Så da er vi vel enige om at det er en av delene da... Får google litt.

Når det i node information står for eksempel 15 -> 48 som route for en node. Hvilken retning er det som er angitt? Er det fra noden, eller fra kontrolleren?

Vel, foreløpig ser dette veldig bra ut. Trengte ikke restarte UZB1 når jeg kom hjem fra jobb for å få lysene på. Veldig bra. Hvis jeg skal forsøke meg på en teori, så tror jeg at problemet var relatert til IDlock + Fibaro Multisensor. Jeg har 2 stk IDlock i etasjen under interfacen, med ca 3 meters avstand. Mellom dem står en multisensor. Når jeg plukket IDlockene ut av nettverket, mistet multisensoren dekningen. Så jeg antar at den har kommunisert via IDlock. I tillegg har den vært inkludert kryptert. Den ene IDlock'en står montert på en ståldør, som også kan ha påvirket. Om IDlock eller Multisensor, eller kombinasjonen, var problemet vil vise seg når jeg begynner å legge ting tilbake i nettverket. Lar det gå noen dager for å bekrefte at ting er stabile nå. Takker for god hjelp!

For å svare på mitt opprinnelige spørsmål; Hvordan identifisere dårlige noder? Jeg innser nå at spørsmålet er feil. Det riktige spørsmålet er: Hvordan få oversikt over nettverket? Det går opp for meg at mye informasjon er tilgjengelig i node-oversikten. Elementær info for Moskus og iblis og andre, selvsagt, men kanskje kjekt for en random googler som ender opp her. I oversikten står det hvilken kommunikasjonsrute de ulike nodene bruker, og hvilken hastighet de kommuniserer med. Skulle likt å ta den informasjonen inn i et visualiseringsverktøy. I mellomtiden gir det meg litt verdi å kjapt tegne opp mitt nettverk, som da ser slik ut: Opprinnelig laget jeg alle rutene, men har her tatt bort alle direkteruter, og erstattet de med farten som label. Oversikten forteller meg at jeg har et par noder som ikke kommuniserer optimalt mot kontrolleren, for eksempel nr 53 helt til venstre. Dette er en fibaro multisensor. Den har valgt seg en rute via en Fibaro dimmer, og oppnår kun 9.6K. Samtidig står det en Fibaro wall plug (47) ikke langt borte, som har god forbindelse. Så multisensoren burde heller rutes via denne (kanskje). Jeg ser også at node 9, som er en Qubino roller shutter, har blitt veldig populær blant andre noder som gjerne ikke vil snakke med interfacen direkte. Så her går det en del trafikk gjennom. Det er litt merkelig, fordi den er veldig usentralt plassert, men har god forbindelse med interface. En del av disse rutene burde kanskje fjernes, og gjøres direkte. Denne visualiseringen kan garantert automatiseres dersom man har kunnskapen og tiden. All informasjonen ligger i HS3, og kan sikkert hentes både direkte og indirekte (scraping). Jeg savner et slikt analyseverktøy. Dette i seg selv løser ikke problemene mine, men jeg ser jo at jeg må begynne å ha litt mer kontroll på hvordan nettverket mitt ser ut. Jeg skal forsøke å utbedre en del av disse rutene og se om det har en effekt, men kommer til å vente noen dager slik at jeg ikke roter til min egen debugging nå. Ingenting er verre enn å fjerne et symptom uten å vite hva problemet egentlig var... Angrer på at jeg ikke gjorde dette mens IDlock'ene var i nettverket, og før jeg eksluderte/inkluderte 4 multisensorer tidligere i dag for å gjøre de ukrypterte.

Jeg designer på Windows, og bruker på Android... Vet ikke om font-problemet egentlig er SÅ stort, men det kommer vel an på bruken og på hvilke fonter man bruker. Jeg liker sans-serif fonter i mine design, og har brukt Calibri en del. Den vises helt fint også i Android. Om det faktisk er Calibri som vises, eller noe som minner om det, tør jeg ikke garantere. Jeg opplever jo at designet ser annerledes ut på Windows enn det gjør på Android, likevel er det ikke noe stort problem (for meg). Men det hadde vært et problem dersom samme design skulle brukes på begge plattformer. Men nok om det, hvilken kongeklient er det du refererer til??

Grunnen til at jeg ville hatt en 5-minutters buffer der er for å unngå vakling på av/på. Kan skje dersom målt temperatur ligger nøyaktig på target, men svinger litt over og litt under. Hvis man for eksempel bruker 433-temperaturmålere som rapporterer hele tiden, vil man kunne ende opp med mye av og på, teoretisk. I tillegg kan det være greit å ha en liten sikring mot at en sensor rapporterer feil temperatur av og til, eller dersom en feilmelding tolkes som 0, osv osv.

Tenkte jeg skulle ta for meg et par av multisensorene og fjerne krypteringen. De er såpass isolerte fra eventer i HS3 at det er relativt lite jobb å eksludere/inkludere på nytt. Gikk greit med den første, gikk greit med den andre, så oppdaget jeg at den første ikke hadde fått alle subdevicene sine, så jeg tok den en gang til. Da tok det utrolig lang tid å ekskludere den. Til slutt så jeg av loggen at Z-wave var i gang med en komplett rescan av hele nettet. Legger til alle devicer på nytt, setter default polling på alle devicer, lager på nytt alle unødvendige subdevicer jeg har slettet, osv... Iflg UZB1-kontrollsiden holder den fortsatt på med eksludering av en enkelt node....

Ja, enig. Utrolig at jeg ikke har sett den sårbarheten der. Bruker tid på backup og ditt og datt, men har jo ikke tatt høyde for at selve sticken ryker. Jeg smalt avgårde en ordre til Intin nettopp...

Vel, jeg eier bare 1 stk UZB1 kontroller. Akkurat nå har jeg litt problemer med å forstå hvorfor jeg ikke har en ekstra, de er jo ikke akkurat dyre. Mulig jeg må kjøpe meg en ny for å sjekke akkurat det. Det kan vel være greit å ha en i reserve også, som du indikerer. Edit: Bestilt. Hvor enkelt er det å bytte mellom ulike sticks? Er det bare å sette inn den nye og bruke Restore-funksjonen?

Aner ikke - ikke gjort noen bevisste valg om å gjøre det tror jeg. Bruker den vanlige add/include node når jeg legger til noder. Burde jeg bruke "non secure"?

En Fibaro multisensor (batteridrevet)

Denne dukket opp i loggen nå, er det noe jeg burde ta tak i? Dette er en Fibaro multisensor. Måtte for øvrig restarte HS3 nå for å få tak i node-oversikten. Alt som har med z-wave plugin å gjøre var utilgjengelig. Kanskje relatert, kanskje ikke... Kan det være andre plug-ins som forårsaker disse tingene? Burde jeg begynne å disable plug-ins?

Hva med å gjøre følgende: Parametre Avlest temperatur (Netatmo), target temperatur (virtuell device), ovn av/på Regler (eventer) Dersom avlest temperatur har vært høyere enn target temperatur i nøyaktig 5 minutter, slå av ovn. Dersom avlest temperatur har vært lavere enn target temperatur i nøyaktig 5 minutter, slå på ovn. Må det være mer avansert enn det? Via brukerpanel endrer man target-temperatur. Hvis man vil ha natt-/dagssenking, kan det også være eventer som endrer target-temperatur.

Kjører versjon 3.0.1.87. Burde kanskje forsøke en oppgradering av z-wave plug-in? Hvilken forskjell var det du merket?

Ser ikke ut som om det hjalp. Altså: Ser ikke ut til at IDlock var problemet. Nettverket var stabilt og fint i går, men nå svarer ingen av lysene lengre. I tillegg er det flere Fibaro wall plugs som heller ikke mottar signaler. For disse står det "failed" i loggen. For Fibaro dimmer står det ingenting i loggen, men lysene reagerer ikke. Forsøkte en ny Test Connectivity, men den feilet og frøys, så restart kunne ikke tas. Etter å ha disabled z-wave plugin, fikk jeg tatt restart av UZB1, og nå svarer lysene igjen. Og Test Connectivity kjører fint, kontakter alle noder uten problemer innen et par sekunder. Så status er at problemet vedvarer...

Måtte fjerne IDlock'ene med makt... Exclusion fungerte ikke, og til slutt endte de opp uten NodeID, og bare tull. Remove bad node + manuelt slette root + subdevicer fungerte kanskje. Vi får se... Tok ut batteriene fra z-wavedelen av låsene også i tilfelle det fortsatt var liv i dem. Holder på med en komplett rescan nå, men det tar tid og UZB1 sliter. Har holdt på over en time nå, og nå får jeg ikke svar fra UZB1 i det hele tatt. Ser at det hagler med feilmeldinger i loggen, så nettverket er ikke helt i form. Gjenstår å se om IDlock var roten til alt ondt her, eller ikke. Den ene låsen er montert på en branndør av stål, i en brannsluse mot garasje - kanskje det har rotet det litt til for signalene?

Jeg må forsøke det. Er ikke hjemme nå, men det skal jeg prøve ila helgen. Som tidligere beskrevet er det en del, særlig batteridrevne, noder som jeg mistenker kan lage trøbbel. Billigste sort, osv. I tillegg, uten at jeg helt klarer å kvantifisere det, tror jeg at en del problemer oppstod etter at jeg installerte en del termostater. Og IDlock har aldri vært helt helt god. Jeg hadde håpet å slippe å disable en og en detektor, særlig fordi det kan være generelle feil med en type detektorer. Men når IDlock ikke svarer og litt sånt, så er det en god kandidat til et slikt forsøk.

Kjører versjon 3.0.1.87.

Ja, har kjørt den et par ganger uten at jeg har sett problemer. Alle nodene svarer typisk innen 3-4 sekunder. Kjørte jeg den igjen nå, og da manglet jeg svar fra én node (en IDlock).

Nettopp oppgradert den til 5.6, uten at det hjalp. Edit: Oppstartsinfo ved restart av UZB1: