ZoRaC

Interessant! Kanskje er det en deCONZ-bug likevel? Hos meg var default 1/300/1, så kanskje deCONZ håndterer disse verdiene med feil datatype, eller noe sånt? Kunne du sjekket hva dine har som verdi i deCONZ? Og evt teste om det blir noen forskjell om du endrer på dem?

Alle enheter bidrar til å «fylle begeret», men det kan godt hende det fungerer helt greit til jeg f.eks om ett år kjøper lyspære nr 40 og at da er nettverket «fullt». Akkurat nå har jeg 17 lys og 31 sensorer. Kan være tilfeldig, men dagen etter Apex ble lagt til så ble en IKEA RGB-pære «unresponsive» (og 3 brytere, som brukte den pæren som mesh) og måtte tas strømmen av og på. Et godt eksempel på lignede problemer er Heatit Z-trm2. Der har mange opplevd ustabile Z-Wave nettverk, fordi den rapporterer for ofte og overbelastet nettet. Så jeg ønsker jo å justere ned trafikken til bare det som er nødvendig, for å slippe evt problemer senere. Men siden du opplever rapport hver 20. sekund, har du da endret på den første parameteren fra 1 til 20? Hva hvis du endrer den til f.eks 600, får du da rapport bare hvert 10. minutt?

Det hjalp ikke... Virker jo som innstillingene blir lagret i pluggen, for «read config» leser jo tilbake de verdiene jeg har satt. Virker dette hos dere? Enten i deCONZ eller i andre hub'er? Kan ikke skjønne det skal være et problem i deCONZ, så lenge config faktisk blir lagret så skal jo ikke deCONZ kunne forårsake at pluggen rapporterer oftere enn config tilsier...? Slik det er nå tror jeg ikke jeg kan ha mer enn 1 stk, for flere vil rett og slett kunne gi for mye trafikk i nettet...

Kjører du siste versjon av deCONZ og firmware? Og JowiHue? Når du sier «mister kontakt med bridge», mener du at HomeSeer (JowiHue) mistet kontakt med deCONZ? Virker da fortsatt deCONZ/Phoscon? Sier loggen i HomeSeer noe rundt tidspunktet det skjer?

Nei, men jeg har tenkt samme tanke og skal teste når jeg kommer hjem.

Er det da riktig at de to første angis i sekunder og den siste i watt?

Ser ikke ut til at det fungerer likevel, har nå satt 60/3600/50, men likevel oppdaterer den både hyppigere enn 1 gang i minuttet og ved mindre endring enn 50 watt (eller prosent): Når jeg tar "read config", så leser den tilbake 60/3600/50, så innstillingene blir lagret. Noen innspill, @Datek Harald? Er jeg på villspor eller er det en bug som gjør at den ignorerer disse innstillingene?

På Z-wave-enhetene mine er det faktisk prosentmessig endring. Fant dette: Endret det til 60/3600/10. Ser ut til at den i hvertfall sluttet å rapportere 6/7 watt hele tiden (endret for noen min siden): Får vel se når jeg får vasket neste maskin, om den fortsatt rapporterer det jeg trenger da... Takk for hjelpen, @stigvi!

Kan det være at må bruke punktum i stedet for komma som desimaltegn?

Jo, men det er "hendelsen" som da må være trigger, ikke condition. Du må altså "snu om" på eventet: "If bevegelse changes and becomes on-motion AND fellesbryter is off".

Nei, en trigger er aldri «er», den er «blir». I ditt tilfelle har du satt «når felleslys blir satt til natt», ikke «når felleslys er natt». Det skjer altså bare akkurat i det sekundet (dvs kl 00:00:00) felleslys settes til natt. I loggen skal det være mulig å filtrere og bare vise type=Event. Da ser du bare logglinjene som omhandler events som har kjørt. Sjekk da først tidspunktet lyse slo seg av og se hvilket event som kjørte i ca samme sekund.

Jeg har deCONZ, er bare ikke så kjent med UI og hvordan man endrer slike ting der. Er da «report interval» prosentmessig endring for at den skal rapportere, slik som det er på Z-Wave-enheter?

I eventet så sier du «hvis klokka er 00:00:00 (dvs fellesbryter settes til natt) og det er bevegelse, slå på lyset». Tiden er «trigger» og bevegelse er en «condition». Hvis et event skal reagere på bevegelse så må bevegelse være «trigger» og evt tid/felleslys være «condition». Ser ikke ut til at setting av felleslys kan være årsaken til problemet heller, for det ser helt riktig ut. Men hva sier loggen? Hvilket event slo av lyset når det var bevegelse?

Nei, for eventet sier ikke at lyses skal være av NÅR felleslys ER av. Den sier at lyset skal SLÅ SEG AV når felleslyset SLÅS AV. Altså er det en engangshendelse, ikke en «tilstand». Hvordan ser eventet som setter felleslys til av ut? Det slo meg at det kan være der feilen ligger. En løsning er å enere fra «set to» til «changes and becomes». I tilfelle det er et event som konstant setter felleslyset til off på nytt hele tiden (hvert sekund). Det nederste eventet ditt vil kun slå til hvis det er bevegelse akkurat kl 00:00:00 (når felleslys settes til natt). Hvis det et bevegelse kl 00:00:01 eller senere så vil ikke det eventet kjøre...

@Datek Harald: Er det mulig å endre noen setting for hvor store endringer som skal til for at den skal rapportere effekt (slik man ofte har på Z-wave-enheter)? Nå står den bare påslått med en blinkende LED på vaskemaskina og da melder den en endring på 1 W relativt hyppig. Ikke så stort problem i et lite Zigbee-nett, men det kan skape en del unødvendig trafikk i et stort nett eller hvis man har flere slike plugger...

Kan du vise hvordan denne "hovedregelen" ser ut? Hvis den er satt opp som du har vist tidligere, med "if felleslys is set to off, then lys gang off" så skal ikke det eventet bli kjørt med mindre felleslys akkurat da settes til off. Hva sier loggen, hvilket event er det som slår av lyset?

Den har innebygget temp.sensor også, ser den er opp mot 50 grader på maks.

Ja, når norsk produsent (@Datek Harald) spesifikt sier de kan brukes på vaskemaskin og at den har både overbelastning- og termiske vern som skal slå ut, og at jeg belaster den «bare» 2/3 av rating, så ja.

Kjøpte en slik i går. Gikk rett inn i deCONZ (2.10.1-beta) og JowiHue. Vaskemaskinen min peaker på ca 2300w.

Jeg har hatt Danalock et par år nå. Aldri hatt noen problemer har fungert 100%. Tok en time og montere og etter det har det bare fungert helt feilfritt. Batteriene holder ca ett år. Bruker bare Z-Wave, ikke Bluetooth. Har også en Danapad, den var litt treg i responsen i starten, men det har bedret deg med ny FW. Jeg har lest utallige flere innlegg her og på FB om problemer med IDLock...

Ja, det er det du skal bruke. Endre fra «On-open-motion» til «off-closed-nomotion» i stedet.

Nei, det er ikke slik. Når fellesbryter ENDRES til off, så endres gang til off. Gang påvirkes ikke av hva fellesbryter ER, den påvirkes bare av ENDRING av fellesbryter. Sikkert lurt å dele opp i 2 events her også. Sette til «borte» når det har vært «no-motion» i 12 timer i stedet for å bruke delayed action.

Bevegelse kan du løse ved å dele det i to, som @Moskus nevnte. if bevegelse changes and becomes motion and fellesbryter is off set lys on if bevegelse has been no-motion for exactly 10 min and fellesbryter is off sett lys off Ved bevegelse kl 0850-0900 vil ikke lyset slå seg av etter 10 min, for man slår bare av lyset når det har vært ingen bevegelse i 10 min (i stedet for 10 min etter siste bevegelse). For da ville den kl 0906 sjekket om felleslys fortsatt var off og dermed ikke slått av lysene når den var on.

Les HomeSeer-skolens del om trigger og condition. Når man har skjønt den delen så blir alt mye enklere. Man KAN sette et event til å trigge hvert 10 min, med bryteren som condition, men vil man det? Vil du ikke bare at når fellesbryter endres til on så skal lysene også bli on (og tilsvarende for off)? Jeg har 400 events og nesten ingen av dem er av typen som kjører hvert x min... Jeg har også en virtuell bryter, kalt «nattmodus». Når den settes til «natt» slås alle lys av og termostater i nattmodus. Tilsvarende når den settes til «morgen». Jeg sjekker ikke hvert 10 min om det fortsatt er natt/morgen, men trigger eventet når den endrer seg.

Men om du ser på klokkeslettene så har du jo ikke kjørt eventet på nytt etter kl 9? Da vil det jo ikke skje noe med lyset. Ser også at lyset slo seg av 09:06, så da tipper jeg det var bevegelse kl 0856?