Witam, mam problem z czujnikami ruchu Xiaomi Mi na zigbee. Otóż 3 z nich sparowały mi się bez problemu z bramką (mam dev3 i conbee) a 2 widnieją jako niewspierane. Mimo że to ten sam model każdego z nich. Wcześniej działałem na dev 1 i conbee i nie było takiego problemu. Ma ktoś jakiś pomysł co jest tego przyczyną?
Oczywiście usuwałem i parowałem kilkukrotnie, czujniki parują się z xiaomi gateway 3 bez problemu
Jesteś za daleko od bramki, miałem podobnie.
1 polubienie
Dzięki, pomogło
Chociaż dziwi mnie fakt że czujniki które są dalej połączyły się bez problemu a tu mają ok 3m i był problem
Do parowania lepiej jak są blisko bramki, potem i tak dobrze działają .
Kupiłem czujnik Aquara / Xiaomi RTCGQ11LM. Zanim go sparowałem z moim Conbee II wykonałem mod z lutowaniem dla zmniejszenia czasu raportowania “brak ruchu” po 5s. Niestety najwyraźniej potrzeba jeszcze gdzieś ustawić odpowiednią konfigurację dla zmniejszenia tego czasu w oprogramowaniu. Czujnik nadal odświeża stan po 90s.
Czy tej zmiany muszę dokonać w Z2M czy może w ustawieniach czujnika poprzez inne oprogramowanie typu deCONZ?
Znalazłem taki poradnik ale jestem ostrożny i wolę dopytać Was… proszę o radę.
EDIT:
@bartik22 - widzę, że udzielałeś rad w tej kwestii… czy informacje w tym temacie są aktualne z bramką AIS i Conbee II?
Jo
Wszystko działa cały czas
Occupancy będzie działało jak działa teraz chyba 90s
Tylko czujnik częściej sprawdza stan chyba co 5s
A tym wpisem robisz sobie info kiedy ostatni ruch był wykryty.
Więc nie patrzysz już na ten Occupancy standardowy tylko ten nowy atrybut.
1 polubienie
Dokladnie
Mozna tak powiedzieć 
OK - Konfigurację nadpisałem, kod trochę się różni wcięciami od tego z mojego przykładu powyżej.
Nie znajduje jednak żadnego nowego atrybutu?
Nadal mija 90 zanim zmieni się stan w HA.
devices:
'0x00158d00075f86e2':
friendly_name: Aqara PIR
no_occupancy_since:
- 30
- 60
- 90
- 120
- 180
- 240
- 300
retain: true
Dzięki @bartik22. Protestowałem, starałem się czytać ze zrozumieniem Twoje sugestie z drugiego forum i dochodzę do wniosku że atrybut jest prosty, z łatwo formułowanymi interwałami, pod automatyzacje w NR. Po moich testach zostanę chyba przy konfiguracji jedynie opcji occupancy_timeout. Przy ustawieniu 20s myślę, że będzie dobrze działać w zwykłych automatyzacjach w HA.
No ja mam w NR
Zrób sobie z atrybutu encje
Możesz też dać interwały 5,10,15,20,25 itd
Czyli będziesz miał ence która pokazuje jak dawno temu był wykryty ostatni ruch
Możesz też zrobić template ze jak jest np. Ponad 20s to zmienia na off, a poniżej na on…
Możliwości masz multum
1 polubienie
Czy te interwały no_occupancy_since odpytują czujnik? Czy tylko sprawdzają status w zZ2M? Chodzi mi o żywotność baterii…
Nie do końca jeszcze potrafię odczytywać, ze zrozumieniem składni, logi z Z2M.
To nie tak
Przez to polaczenie/zlutowanie czujnik wysyła sygnał wykrycia ruchu częściej, normalnie chyba po 60s zaczyna być znowu aktywny
Czyli jak się ruszasz to bez hacka w 65 sekund wyślę dwa razy że się ruszyłeś, a z hackiem 13 razy…
Ten wpis to zliczenie czasu od ostatnio otrzymanego sygnału.
Jak widzisz u mnie na screenie 100 procent baterii, od ponad roku 
1 polubienie
Czyli no_occupancy_since jest licznikiem zerowanym wykryciem ruchu, podawanym w definiowanych interwałach czasu.
Czyli occupancy_timeout jest zwłoką po jakiej Z2M opublikuje stan? Możemy nadpisać tym fabryczny czas zwłoki czujnika i dlatego nie powinien być mniejszy. Dobrze to rozumiem?
Pierwsze tak
A drugie nie… Z tego co wiem
Stan podstawowego Occupancy jest nadawany przez urządzenie, jak jest po 90s brak ruchu to czujnik wysyła ze jest Occupancy false i tego nie obejdziesz.
Ten wpis z tego co rozumiem to takie sztuczne zmienienie stanu…
Szkoda, że w logach Z2M nie ma znacznika czasu. Nadal nie rozumiem jednak dlaczego occupancy nie pryzmuje 5s zamiast 90s. Chyba już jest dziś na to za późna pora…
Jutro będę przy kompie to Ci pomogę to ogarnąć
1 polubienie