Czujniki T/H/P/IL i IAS - zgłoszenia, uwagi, pomysły [bramka Zigbee]

[vajera]

Rozumiem ,że tą flagą wyłączę wszystkie ikony baterii czujników podłączonych do tego modułu? Jeśli tak to niech i tak będzie jeśli wyłączanie dla każdego urządzenia indywidualnie to duży kłopot. Nie chcę marudzić bo wiem ,że są ważniejsze sprawy niż jakieś tam 2 ikony baterii. I tak jestem mega wdzięczny za wkład pracy i czasu poświęconego aby ten sygnalizator zaczął prawidłowo rozmawiać z bramką.

Właśnie się zastanawiam, co jest lepszym rozwiązaniem - flaga per kanał Supla czy flaga per całe urządzenie Zigbee - ilość kodu w zasadzie identyczna.

EDIT Ty chyba miałeś na myśli całą bramkę? Tego nie chciałem robić - od początku brałem pod uwagę pojedyncze urządzenie Zigbee - zastanawiam się tylko czy flaga ma być dla każdego kanału oddzielnie czy jedna na czujnik.

Ja tak tylko z przypomnieniem ,dodasz @vajera funkcję wyłączania wyświetlania baterii per całe urządzenie ZIGBEE ?

Pracuję nad tym od kilku dni bo połączyłem to z gruntowną aktualizacją kodu odpowiedzialnego za baterię.

[endrju_88]

Pracuję nad tym od kilku dni bo połączyłem to z gruntowną aktualizacją kodu odpowiedzialnego za baterię.

Wybacz , myślałem ,że zapomniałeś . Heh , bez urazy. Pozdrawiam.

[lukasz06]

Ok przetestuję i dam znać.
Edit. U mnie to polecenie nie działa. Sparowałem z bramką Sonofa i tam nic nie trzeba potwierdzać. po prostu po wyciągnięciu czujnika z wody zmienia mu się ikona. Parując z Suplą dostajemy 2 kanały: Alarm i Low Batery
Po kontakcie z wodą zmienia się stan Alarm A drugi nic. Nie wiem o co chodzi, czy rzeczywiście mam słabą baterię? Jednak Ewelinku pokazuje 100% Tutaj nie mam podglądu. Po co w ogóle ten kanał Alarmu? Można w Cloud ustawić powiadomienie.
Podpowiedzcie coś, jakaś odwrócona logika, czy coś?

Szczerze mówiąc to chyba mie do końca Cię rozumiem?

Kanał ALARM reaguje na sygnał zalania z czujnika, więc nie do końca rozumiem pytanie o jego sens?
Na którym kanale chciałbyś ustawić powiadomienie w Cloud nie mając tego kanału ALARM?

Rozumiem, że ten stan kanału ALARM zmienia się u Ciebie po zalaniu i już taki pozostaje? Czy wraca do stanu pierwotnego gdy czujnik straci kontakt z wodą?

LOW BATTERY to element komunikatu z klastra IAS - możliwe, że skoro się nie zmienia to batería jest OK.

Dobra to trochę mnie oświeciło
Myślałem, że kanał Alarm służy do wł/wyl powiadomień o zalaniu. A kanal Low Batery zmieniłem mu nazwę i ikonę, i temu się nie zmieniał
Tylko, że ten kanał jest niepotrzebny, bo mamy stan baterii przy Alarmie. A nie lepiej, żeby po sparowaniu pojawił się poprostu czujnik zalania? Wiem że można to sobie samemu zmienić, ale może nie byłoby takich pomyłek.

[vajera]

Dobra to trochę mnie oświeciło
Myślałem, że kanał Alarm służy do wł/wyl powiadomień o zalaniu. A kanal Low Batery zmieniłem mu nazwę i ikonę, i temu się nie zmieniał
Tylko, że ten kanał jest niepotrzebny, bo mamy stan baterii przy Alarmie. A nie lepiej, żeby po sparowaniu pojawił się poprostu czujnik zalania? Wiem że można to sobie samemu zmienić, ale może nie byłoby takich pomyłek.

1. Ten czujnik, podobnie jak dziesiątki innych czujników otwarcia, wibracji, zalania, dymu, CO itd., raportuje swój stan z użyciem klastra IAS ZONE (0x500) - w przypadku zmiany stanu wysyłany jest komunikat zawierający 16-bitową zmienną zone status, w której każdy bit odpowiada za inną wartość:
   • bit 0 - ALARM1 - bardzo wiele czujników raportuje tylko ten stan (otwarty/zamknięty, dym/brak dymu itd.),
   • bit 1 - ALARM2 - niektóre czujniki raportują tutaj dodatkowy stan (np. wibracje),
   • bit 2 - TAMPER - niektóre czujniki raportują tzw. naruszenie bezpieczeństwa, np. oderwanie czujnika od okna,
   • bit 3 - LOW BATTERY - niektóre czujniki raportują krytycznie niski stan baterii.
2. kluczowe jest słowo "niektóre" - informacji o zakresie raportowanych stanów nie da się odczytać bezpośrednio z czujnika - trzeba korzystać z informacji znalezionych w Internecie albo ustalić to eksperymentalnie, analizując dane wysyłane przez czujnik,
3. ponieważ ten Sonoff raportuje ALARM1 i LOW_BATTERY to dodałem 2 kanały, bo co do zasady staram się przekazywać do Supla maksymalną porcję informacji z czujnika,
4. zresztą to tylko kwestia czasu, jak ktoś napisze "a ten czujnik to jeszcze zgłasza to i tamto - może uda się dodać " ,
5. taki kanał LOW_BATTERY może być przydatny do wysyłania powiadomień o konieczności wymiany baterii,
6. zawsze możesz go ukryć, jeżeli przeszkadza.

Rozumiem, że Sonoff jednak działa poprawnie w zakresie raportowania zalania?

W temacie czujnika zalania - jeszcze go nie było, jak tworzyłem obsługę IAS zone - teraz można pomyśleć, ale @klew ma chyba plan dodania kilku nowych typów czujnika, więc chwilę poczekam.

[lukasz06]

1. Ten czujnik, podobnie jak dziesiątki innych czujników otwarcia, wibracji, zalania, dymu, CO itd., raportuje swój stan z użyciem klastra IAS ZONE (0x500) - w przypadku zmiany stanu wysyłany jest komunikat zawierający 16-bitową zmienną zone status, w której każdy bit odpowiada za inną wartość:
   • bit 0 - ALARM1 - bardzo wiele czujników raportuje tylko ten stan (otwarty/zamknięty, dym/brak dymu itd.),
   • bit 1 - ALARM2 - niektóre czujniki raportują tutaj dodatkowy stan (np. wibracje),
   • bit 2 - TAMPER - niektóre czujniki raportują tzw. naruszenie bezpieczeństwa, np. oderwanie czujnika od okna,
   • bit 3 - LOW BATTERY - niektóre czujniki raportują krytycznie niski stan baterii.
2. kluczowe jest słowo "niektóre" - informacji o zakresie raportowanych stanów nie da się odczytać bezpośrednio z czujnika - trzeba korzystać z informacji znalezionych w Internecie albo ustalić to eksperymentalnie, analizując dane wysyłane przez czujnik,
3. ponieważ ten Sonoff raportuje ALARM1 i LOW_BATTERY to dodałem 2 kanały, bo co do zasady staram się przekazywać do Supla maksymalną porcję informacji z czujnika,
4. zresztą to tylko kwestia czasu, jak ktoś napisze "a ten czujnik to jeszcze zgłasza to i tamto - może uda się dodać " ,
5. taki kanał LOW_BATTERY może być przydatny do wysyłania powiadomień o konieczności wymiany baterii,
6. zawsze możesz go ukryć, jeżeli przeszkadza.

Rozumiem, że Sonoff jednak działa poprawnie w zakresie raportowania zalania?


Panie, teraz to ja wszystko rozumiem i przyjmuje do wiadomości
Tak, Sonoff działa poprawnie i natychmiastowo, musiałem mu tylko zmienić na "odwrócona logika"
Kanał Low Battery ukryłem, póki co.

W temacie czujnika zalania - jeszcze go nie było, jak tworzyłem obsługę IAS zone - teraz można pomyśleć, ale @klew ma chyba plan dodania kilku nowych typów czujnika, więc chwilę poczekam

Ja też z chęcią poczekam

[Zibi_007]

[*]zresztą to tylko kwestia czasu, jak ktoś napisze "a ten czujnik to jeszcze zgłasza to i tamto - może uda się dodać " ,

Właśnie zaraz napiszę, bo dostałem jeden taki czujnik drgań (już jest w bazie) ale on powinien raportować dwa alarmy (drgania i przesunięcie) a raportuje tylko jeden. Zbiorę logi (pewnie w nocy) i prześlę, więc tutaj masz 100% racji

W temacie czujnika zalania - jeszcze go nie było, jak tworzyłem obsługę IAS zone - teraz można pomyśleć, ale @klew ma chyba plan dodania kilku nowych typów czujnika, więc chwilę poczekam.

Ale czujnik zalania już jest (jako czujnik binarny). Został wprowadzony razem z zaworem od Auratona. Tutaj już chyba nic nie będzie zmieniane...

[Yepestis]

@vajera czy dało by radę zrobić zapamiętanie stanu czujników binarnych przy restarcie bramki tak jak to zrobiłeś dla przeliczników?
Teraz po restarcie wszystkie czujniki zalania pokazują mi zalanie i same z siebie nie chcą zaktualizować stanu nawet przez kilka dni co jest upierdliwe bo po każdym restarcie muszę je wkładać do wody żeby pokazywały prawidłowy stan. Dla kontrantronow do drzwi i okien też by się to przydało choć to już jest mniej uciążliwe bo okno czy drzwi łatwiej otworzyć żeby powrócił prawidłowy stan.

[vajera]

@vajera czy dało by radę zrobić zapamiętanie stanu czujników binarnych przy restarcie bramki tak jak to zrobiłeś dla przeliczników?
Teraz po restarcie wszystkie czujniki zalania pokazują mi zalanie i same z siebie nie chcą zaktualizować stanu nawet przez kilka dni co jest upierdliwe bo po każdym restarcie muszę je wkładać do wody żeby pokazywały prawidłowy stan. Dla kontrantronow do drzwi i okien też by się to przydało choć to już jest mniej uciążliwe bo okno czy drzwi łatwiej otworzyć żeby powrócił prawidłowy stan.

OK, ale to jest włączone od czasu, gdy @klew dodał taką opcję (styczeń?):

Code: Select all

 auto Supla_Z2S_VirtualBinary = new Supla::Sensor::Z2S_VirtualBinary(true, timeout);
  

[Yepestis]

@vajera czy dało by radę zrobić zapamiętanie stanu czujników binarnych przy restarcie bramki tak jak to zrobiłeś dla przeliczników?
Teraz po restarcie wszystkie czujniki zalania pokazują mi zalanie i same z siebie nie chcą zaktualizować stanu nawet przez kilka dni co jest upierdliwe bo po każdym restarcie muszę je wkładać do wody żeby pokazywały prawidłowy stan. Dla kontrantronow do drzwi i okien też by się to przydało choć to już jest mniej uciążliwe bo okno czy drzwi łatwiej otworzyć żeby powrócił prawidłowy stan.

OK, ale to jest włączone od czasu, gdy @klew dodał taką opcję (styczeń?):

Code: Select all

 auto Supla_Z2S_VirtualBinary = new Supla::Sensor::Z2S_VirtualBinary(true, timeout);
  

Kurcze to dziwna sprawa bo u mnie to nie działa.
Tak się zastanawiam czy to nie przez to że w cloud mam ustawiona odwróconą logikę żeby czujnik pokazywał prawidłowy stan zalania?

[Zibi_007]

[*]zresztą to tylko kwestia czasu, jak ktoś napisze "a ten czujnik to jeszcze zgłasza to i tamto - może uda się dodać " ,

Czujnik wstrząsów. Kiedyś już dodany. W eWelinku (sprawdziłem) może raportować dwa alarmy. W Supli raportuje tylko jeden. W załączniku logi z parowania i pracy. Próbowałem wzbudzić obydwa alarmy. Mam nadzieję, że się udało i to widać (widziałem stan 401 i 801 ale nie wiem czy to jest to). Działa też Twoja metoda powrotu do stanu sprzed wzbudzenia (brawo). Działają też poziomy czułości, ale dokładnie tak, jak opisał to @Zenon tutaj viewtopic.php?p=205763#p205763 (czyli odwrotnie - im mniejsza wartość parametru, tym większa czułość).

Edit:
Dodaję zrzut ekranu tego co raportuje ten czujnik pd bramką Tuya.