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

[vajera]

Dodatkowo lina wpisania treści powiadomienia jest zablokowana .

Linia do wpisania treści powiadomienia jest zablokowana przez bramkę, bo wtedy to bramka ustala treść powiadomienia. Zrobiłem tak, żeby w treści można było przekazać stan, bo wpisując treść w Cloud nie masz takiej opcji.

[vajera]

10 urządzeń/ 15 kanałów, Full GUI, 0 opóźnienie, po ponownym wgraniu 9.95 pracuje poprawnie

To ustaw sobie minimal GUI, daj opóźnienie np. 30 sekund i wtedy wgraj 0.9.105.
Co to za urządzenia - czujniki czy np. termostaty?

2 włączniki zasilania, 1 czujnik otwarcia, 1 przycisk potrójny, 3 czujniki temperatury i wilgotności, 3 głowice termostatyczne.
Po wgraniu 9.105, Minimal GUI, opóźnienie 60 s pracuje poprawnie

To już całkiem sporo urządzeń - taka bramka jest idealnym kandydatem na tandem S3+C6/H2. Myślę, że mimo wszystko da radę uciągnąć Full GUI, ale z opóźnieniem startu GUI. Co nie zmienia faktu, że do zastosowań produkcyjnych najlepiej wyłączyć GUI i odpalać je dopiero w razie potrzeby.

[LukiSpajder]

Dodatkowo lina wpisania treści powiadomienia jest zablokowana .

Linia do wpisania treści powiadomienia jest zablokowana przez bramkę, bo wtedy to bramka ustala treść powiadomienia. Zrobiłem tak, żeby w treści można było przekazać stan, bo wpisując treść w Cloud nie masz takiej opcji.

Właśnie dawno nie używałem powiadomień i nie pamiętałem jak było , a jeśli chodzi o czujnik to te podwójne powiadomienia związane są z tym błędem który ostatnio odkryłeś ? Czy on tak ma . Jak są potrzebne aktualne logi to mogę podesłać po południu

[vajera]

Dodatkowo lina wpisania treści powiadomienia jest zablokowana .

Linia do wpisania treści powiadomienia jest zablokowana przez bramkę, bo wtedy to bramka ustala treść powiadomienia. Zrobiłem tak, żeby w treści można było przekazać stan, bo wpisując treść w Cloud nie masz takiej opcji.

Właśnie dawno nie używałem powiadomień i nie pamiętałem jak było , a jeśli chodzi o czujnik to on jest z wiązany z tym błędem który ostatnio odkryłeś ? Czy on tak ma . Ja są potrzebne aktualne logi to mogę podesłać po południu

Tak, jak napisałem, to nie jest ten sam błąd, ale faktycznie musiałbym zobaczyć log z procesu zalania/wysuszenia czujnika.

[LukiSpajder]

Linia do wpisania treści powiadomienia jest zablokowana przez bramkę, bo wtedy to bramka ustala treść powiadomienia. Zrobiłem tak, żeby w treści można było przekazać stan, bo wpisując treść w Cloud nie masz takiej opcji.

Właśnie dawno nie używałem powiadomień i nie pamiętałem jak było , a jeśli chodzi o czujnik to on jest z wiązany z tym błędem który ostatnio odkryłeś ? Czy on tak ma . Ja są potrzebne aktualne logi to mogę podesłać po południu

Tak, jak napisałem, to nie jest ten sam błąd, ale faktycznie musiałbym zobaczyć log z procesu zalania/wysuszenia czujnika.

Ok nie odczytałem przedostatniej wiadomości , dobra wyślę po południu logi z działania

[endrju_88]

1.Pierwszy z nich w GUI jest jako _TZE200_rhgsbacq::TS0601 to czujnik 4w1 .
https://pl.aliexpress.com/item/1005009110210160.html

Rozumiem, że w przypadku tego czujnika pomiar T/H działa?

2.Drugi wygląda tak samo i zgłasza się jako : HOBEIAN::ZG-204ZV , na opakowaniu ma napisane TZ-10G-Z3.0_E ,jest to czujnik 2w1 , PRESENCE i ILLUMINANCE ale oprócz tego w Cloudzie pojawia się kanał T&H ,który to nie jest aktywny ( pomiar cały czas --- ) .

Postaram się pamiętać, żeby zmienić definicję tego modelu, chociaż w sieci widnieje on jako 4w1?

Teraz do rzeczy - chciałbym Ci bardzo podziękować, bo Twoje zaangażowanie pomogło mi zlokalizować złośliwy błąd dotyczący czujników obecności Tuya, które zgłaszają atrybut presence poprzez Tuya datapoints.

Część z tych czujników, m.in. obydwa Twoje, działa poprzez Tuya datapoints a jednocześnie raportuje przez cluster IAS ZONE - to oznacza, że gdy wzbudzisz czujnik przetwarzane są dwa komunikaty - na pierwszy rzut oka nie wydaje się to być poważnym problemem, ale...IAS ZONE raportuje obecność poprzez "1" TDP przyjmuje wartość "1" (w przypadku części czujników) lub "0" (w przypadku innych).

W sytuacji wzbudzenia takiego czujnika najpierw leci TDP z "0", które bramka interpretuje jako OFF, za ułamek sekundy leci IAS ZONE z "1", więc bramka widzi ON, gdy czujnik wraca do stanu czuwania najpierw leci 1 (TDP) - bramka widzi ON i na koniec IAS ZONE z 0 -> OFF.

Tak było, wersja 0.9.102-19/10/2025 wprowadza korektę dla tych czujników, które udało mi się zidentyfikować, lista poniżej:

_TZE200_2aaelwxk::TS0601
_TZE200_kb5noeto::TS0601
_TZE200_rhgsbacq::TS0601
HOBEIAN::ZG-204ZV
_TZE204_mtoaryre::TS0601
HOBEIAN::ZG-204ZL

cdn.

Ten pierwszy czujnik _TZE200_rhgsbacq::TS0601 ma odczyt T&H. Cieszę się ,że znalazłeś przyczynę tych powielanych powiadomień. Jutro wgram wsad i te czujniki posprawdzam. Jeszcze raz Dzięki.

Coś nie tak z działaniem tych czujników. Testowałem na tych dwóch co ostatnio czyli:

Code: Select all

4w1
Manufacturer name _TZE200_rhgsbacq | model ID TS0601 


2W1
Manufacturer name HOBEIAN | model ID ZG-204Z

Wgrałem plik merged . i jest dziwna sprawa. Czujniki PRESENCE zmieniają się na 1 sec.po jakimś dłuższym czasie. Zauważyłem taką zależność : jak ustawiam parametr Motion Keep time np: 30 sec , to zmiana stanu po wzbudzeniu czujnika następuje po 30 sec.,z tym ,że jest powiadomienie State changed - ON mija 1 sec. i jest 2 powiadomienie State changed - OFF. Jak ustawię Motion Keep time np: 60 sec , to zmiana stanu PRESENCE następuje po 60 sec., i też zmiana jest na State changed - ON i po 1 sec na State changed - OFF . W dwóch czujnikach jest to samo.

[bokk]

Czy aktualizacja również wpłynie na zmianę logiki przy czujnikach Aqara do okien i drzwi DW-S03D

Sprawdź 0.9.105-19/10/2025

po aktualizacji dla prawidłowych wskazań trzeba odwrócić logikę w cloud

[vajera]

Czy aktualizacja również wpłynie na zmianę logiki przy czujnikach Aqara do okien i drzwi DW-S03D

Sprawdź 0.9.105-19/10/2025

po aktualizacji dla prawidłowych wskazań trzeba odwrócić logikę w cloud

Czyli bez zmian? Ja Ciebie chyba nie zrozumiałem - z tego poprzedniego posta wyczytałem, że też masz problem, więc zrobiłem korektę w kodzie. Teraz chyba dotarło do mnie, że działało prawidłowo a ja to "zepsułem", tak?

[bokk]

Sprawdź 0.9.105-19/10/2025

po aktualizacji dla prawidłowych wskazań trzeba odwrócić logikę w cloud

Czyli bez zmian? Ja Ciebie chyba nie zrozumiałem - z tego poprzedniego posta wyczytałem, że też masz problem, więc zrobiłem korektę w kodzie. Teraz chyba dotarło do mnie, że działało prawidłowo a ja to "zepsułem", tak?

No niezupełnie:) Teraz wystarczy zmienić w cloud logikę i powiadomienia i oraz ikona odpowiadają właściwemu stanowi. Poprzednio po zmianie logiki musiałem podmieniać ikony zamknięte na otwarte i otwarte na zamknięte aby odzwierciedlały faktyczny stan oraz podobna sytuacja przy reakcjach do powiadomień

[LukiSpajder]

Ja ma czujkę zalania który też pojawia się w Cloud pokazując zalanie . Musi być zmieniona logika . Powiadomienia też przychodzą dwa jednoczenie on i off . Dodatkowo lina wpisania treści powiadomienia jest zablokowana .
Może to ten sam problem

Taki czujnik i logi z dnia : śr sty 15, 2025 4:58 pm

https://pl.aliexpress.com/item/10050074 ... pt=glo2pol

Code: Select all

         
[ 22761][V][ZigbeeHandlers.cpp:167] zb_cmd_ias_zone_status_change_handler(): IAS Zone Status Notification: from address(0x2189) src endpoint(1) to dst endpoint(1) cluster(0x500), zone status (0x1), extended status (0x0), zone id (0x0), delay (0x0)
[ 23505][I][ZigbeeHandlers.cpp:21] zb_action_handler(): Receive Zigbee action(0x1031) callback
[ 23506][V][ZigbeeHandlers.cpp:167] zb_cmd_ias_zone_status_change_handler(): IAS Zone Status Notification: from address(0x2189) src endpoint(1) to dst endpoint(1) cluster(0x500), zone status (0x0), extended status (0x0), zone id (0x0), delay (0x0)
[ 24065][I][ZigbeeHandlers.cpp:21] zb_action_handler(): Receive Zigbee action(0x2000) callback
[ 24066][V][ZigbeeHandlers.cpp:72] zb_attribute_reporting_handler(): Received report from address(0x2189) src endpoint(1) to dst endpoint(1) cluster(0x1)
[ 24066][I][ZigbeeGateway.cpp:339] zbAttributeRead(): zbAttributeRead from (0x27e5), endpoint (1), cluster (0x1), attribute id (0x21), attribute data type (0x20)
[ 24067][I][ZigbeeHandlers.cpp:21] zb_action_handler(): Receive Zigbee action(0x2000) callback
[ 24068][V][ZigbeeHandlers.cpp:72] zb_attribute_reporting_handler(): Received report from address(0x2189) src endpoint(1) to dst endpoint(1) cluster(0x1)
[ 24068][I][ZigbeeGateway.cpp:339] zbAttributeRead(): zbAttributeRead from (0x27e5), endpoint (1), cluster (0x1), attribute id (0x20), attribute data type (0x20)
[ 27449][V][ZigbeeCore.cpp:343] esp_zb_app_signal_handler(): ZDO signal: NLME Status Indication (0x32), status: ESP_OK
[ 29361][I][ZigbeeHandlers.cpp:21] zb_action_handler(): Receive Zigbee action(0x1031) callback
[ 29362][V][ZigbeeHandlers.cpp:167] zb_cmd_ias_zone_status_change_handler(): IAS Zone Status Notification: from address(0x2189) src endpoint(1) to dst endpoint(1) cluster(0x500), zone status (0x0), extended status (0x0), zone id (0x0), delay (0x0)

To nie jest ten sam problem, bo Ty masz prosty czujnik 0/1 działający wyłącznie w oparciu o klaster IAS ZONE.

Zwróć uwagę, że w powyższym fragmencie logów on rzeczywiście wysyła 1 I chwilę później 0, natomiast to są logi ze skanera a tutaj potrzebne są logi z uruchomienia bramki i z próby zalania czujnika.

Przepraszam za zamieszanie ale chyba rana to za szybko sprawdzałem , zrobiłem testy na spokojnie teraz i wysyła jedno powiadomienie . Jedynie w Cloud zmieniłem logikę ale tak było od początku .