anderssv

Ikke som jeg vet. Vet at noen på Smartthings forumet forsøkte å sende e-post, men at de ikke har fått svar. Anders,

Hehe, blir nok vanskelig å konkludere på denne. @Moskus jeg har Smartthings, men driver og skriver device handleren selv så har full kontroll på gruppene selv om ST default assosierer med gruppe 1. Har kjørt factory reset på pluggen og kun assosiert med gruppe 1, men får samme oppførsel. Dvs: uten last så slutter den å svare på on/off signaler fra huben. Med last så oppfører den seg fint. Men jeg skjønner ikke helt logikken med at gruppe 2/3 skal påvirke det heller. Så uansett om det hjelper eller ikke så mistenker jeg en større eller mindre bug. Når man assosierer noe i gruppe 2/3 så er det fordi man skal få on/off meldinger basert på kriteriene for de. (Param 21-23 definerer "reglene" for gruppe 3 på denne) F.eks. trykk på knappen på device sendes også til sentralen på gruppe 1, så det er bare meningen at man skal putte ting i gruppe 2/3 dersom det skal styres av denne devicen. Det varierer nok fra device til device, men jeg kan ikke skjønne noe annet enn at man burde sende alt av informasjon på gruppe 1 (lifeline). Mens andre grupper er for ting som skal styres. Så hva skjer hvis man er med i gruppe 2/3 da? Jo huben får informasjon fra devicen når disse "terskelverdiene" (on/off + min/maks forbruk) passerer. I de fleste tilfeller ønsker man jo å ha disse reglene og konsekvenser for andre devicer i huben, ikke "hardkodet" i devicen. Men det finnes definitivt omårder for bruk av disse f.eks. dersom huben er nede etc. Så hvis dette påvirker devicen, hva skjer da? Én av disse tror jeg: Devicen reagerer på sine egne terskelverdier. Det er mulig det er by design, men det blir fort komplisert å operere sånn. Er det fornuftig å nekte å slå seg på utenfor verdiene (slik den gjør)? Er et signal om å slå seg på en override av reglene eller skal man ignorere det? Sånn som det er hos meg nå: Knappen fungerer, men ikke signal fra huben. Huben får signlaet og sender off til devicen selv, evt. også nekter å sende on basert på at den fikk off. Synes det virker rart om huben sender signal tilbake til devicen den fikk det fra, og kan heller ikke helt skjønne at den skulle holde en state basert på det som nekter å forsøke å skru den på igjen. (Mens jeg skriver det skjønner jeg at jeg må dobbeltsjekke loggingen ift. hvilke meldinger som pushes når). Makes sense? Bare tenker høyt nå, og spennende å lære mer om konseptene i z-wave. Anders,

Jeg har nå forsøkt å fjerne gruppe 2 og 3 hos meg, men ser ingen forskjell i oppførsel ved liten/null last. Det er et bra spor, men synes egentlig det er rart om den skal påvirke det ut i fra min begrensede forståelse av z-wave... Fint om andre får testet skikkelig. Anders,

Her er forresten gruppe beskrivelsene for den bryteren: http://products.z-wavealliance.org/products/1653/assoc?noFilename=True

I Smartthings så er det koden i Huben som velger hvilke grupper den asossierer med. Men jeg tipper de fleste huber melder seg på alle gruppene som default, da det er ganske flytende hvilke meldinger som går i hvilken gruppe.

Ah... Der ser det ut som det er noe ja... Har lest (dvs. sett over parameterne kjapt) manualen, men tydeligvis ikke skjønt det... Ikke helt overbevist siden det står association group (3) men verdt å eksperimentere med. Ser jo at det matcher 30/50W verdiene som @JxxxIxxx eksperimenterte seg frem til. Kan jo sette de til min og max, men egentlig sånn jeg tolker det så burde man sette param 23 til noe slik at man ikke opplever dette i det hele tatt. Men det ser det ikke ut som man kan? Noen som skjønner dette bedre enn meg som kan forklare?

Har ikke sett sånn oppførsel. Det jeg har sett har bare vært relatert til om den har last eller ikke. Jeg bruker den nå bare på oppvaskmaskinen, og der fungerer det bra så har ikke returnert min selv om jeg sikkert burde. Anders,

Noen som har handlet den nye versjonen? Det har jeg... Og mistenker problemer... https://community.smartthings.com/t/beta-fibaro-wall-plug-zw5/71527/33?u=anderssv