[Zgłoszenie] ZigBee repeater (HOBEIAN::CK-BL702-ROUTER-01(7018)) [bramka ZigBee]

[Beholder]

To byś musiał wgrać sobie te oprogramowanie przez Ota

Mam wgrane przez programator, jest klaster OTA w oryginale ale podobno nie działa(co sprawdzilem). W custom już są aktualizacje. Chodzi tylko o to, żeby Łukasz dołożył te dodatkowe opcje i identyfikatory bo inaczej się nie sparuje ale o tym chyba wiesz.

Z tego opisu na GitHub wynika, że to firmware implementuje cluster On/Off Switch Configuration (0x0007) a nie On/Off (0x0006). W teorii oznacza to, że bramka może odbierać informacje o naciśnięciu tego przycisku na routerze i wykorzystać ją, tak jak w przypadku bateryjnych przycisków ZigBee np. do sterowania oświetleniem lub innym urządzeniem.

Możliwe bo pvvx pisał na swojej wersji, że LED jest bezpośrednio wiązany a nie wiem jak dużo slacky1965 z tego wziął. Nie miałem jeszcze dość czasu żeby to przeanalizować.

[vajera]

Możliwe bo pvvx pisał na swojej wersji, że LED jest bezpośrednio wiązany a nie wiem jak dużo slacky1965 z tego wziął. Nie miałem jeszcze dość czasu żeby to przeanalizować.

+BWNU:1.5.151-09/08/26

Przeanalizowałem kod źródłowy tego firmware'u - wydaje się, że na ten moment jedynym efektem naciśnięcia tego przycisku jest zaraportowanie stanu baterii oraz wysłanie rozkazu ON/OFF w zależności od zdefiniowanych progów napięcia baterii - pytanie czy widzisz jakieś zastosowanie dla takiego mechanizmu?

[Beholder]

Przeanalizowałem kod źródłowy tego firmware'u - wydaje się, że na ten moment jedynym efektem naciśnięcia tego przycisku jest zaraportowanie stanu baterii oraz wysłanie rozkazu ON/OFF w zależności od zdefiniowanych progów napięcia baterii - pytanie czy widzisz jakieś zastosowanie dla takiego mechanizmu?

Faktycznie w kodzie przycisk nie steruje świeceniem diody tylko wymuszonym raportem. baterii i resetem. Nie mam pomysłu na ten przycisk, może cos wyjdzie w trakcie użytkowania. Trochę się pośpieszyłem i wgrałem najnowszą wersję z GH u tu czerwono. Mam log w razie potrzeby prześlę. Patrząc na kod konwertera zależy mi na regulacji txPower w SlackyDiyCustomCluster z poziomu GUI fajnie jakbyś dorobił do tego opisy klastrów i atrybutów jak w np. Sonoff. Poziom baterii i uptime wyświetlane w apce pod (i) i cloud, do tego alarm low battery na VB. Ewentualnie dodatkowy kanał z napięciem baterii.

[Beholder]

+BWNU:1.5.151-09/08/26

Już wiem dlaczego mi nie zadziałało z GH puściłeś pusty release bez zmian.

[Beholder]

@vajera mam nadzieję, że odpocząłeś na plaży. Ja tez miałem urlop stąd przerwa w testach.
Bramka testowa Z2S-1.5.152-13/08/26. - urządzenie dodaje się z dwoma kanałami GPM: UPTIME i VOLTAGE. Niestety wartości nie są aktualizowane - wygląda na brak obsługi raportów (log poniżej). W GUI ręcznie mogę odczytać atrybut TIME z klastra TIME, który dodałeś. BATTERY VOLTAGE z POWER CONFIG także w GUI odczytuje poprawnie razem z ustawieniami raportowania.

Code: Select all

10:20:54:096 -> [723492][D][ZigbeeCore.cpp:528] zb_apsde_data_indication_handler(): APSDE INDICATION - Received APSDE-DATA indication, status: 0
10:20:54:097 -> [723492][D][ZigbeeCore.cpp:532] zb_apsde_data_indication_handler(): APSDE INDICATION - dst_endpoint: 1, src_endpoint: 1, dst_addr_mode: 255
10:20:54:097 -> APSDE INDICATION - src_addr_mode: 202, cluster_id: 0x000a, asdu_length: 10
10:20:54:097 -> APSDE INDICATION - dst_short_addr: 0x0000, src_short_addr: 0xc6ca
10:20:54:097 -> APSDE INDICATION - profile_id: 0x0104, security_status: 0, lqi: 61, rx_time: 0
10:20:54:097 -> [723494][I][ZigbeeHandlers.cpp:246] zb_raw_cmd_handler(): cluster id: 0xa, command id: 10
10:20:54:097 -> [723494][I][ZigbeeHandlers.cpp:249] zb_raw_cmd_handler(): src endpoint (0x1, dst endpoint 0x1
10:20:54:097 -> [723495][I][ZigbeeHandlers.cpp:253] zb_raw_cmd_handler(): is common comand 1, disable_default_response 1, is_manuf_specific 0
10:20:54:097 -> [723495][I][ZigbeeHandlers.cpp:257] zb_raw_cmd_handler(): manuf_specific 0x0
10:20:54:097 -> [723496][I][ZigbeeHandlers.cpp:261] zb_raw_cmd_handler(): RAW bufid: 19 size: 7
10:20:54:097 -> [723496][I][ZigbeeHandlers.cpp:264] zb_raw_cmd_handler(): 0x00 
10:20:54:097 -> [723496][I][ZigbeeHandlers.cpp:264] zb_raw_cmd_handler(): 0x00 
10:20:54:097 -> [723497][I][ZigbeeHandlers.cpp:264] zb_raw_cmd_handler(): 0xE2 
10:20:54:097 -> [723497][I][ZigbeeHandlers.cpp:264] zb_raw_cmd_handler(): 0x0F 
10:20:54:097 -> [723497][I][ZigbeeHandlers.cpp:264] zb_raw_cmd_handler(): 0x45 
10:20:54:097 -> [723498][I][ZigbeeHandlers.cpp:264] zb_raw_cmd_handler(): 0x07 
10:20:54:097 -> [723498][I][ZigbeeHandlers.cpp:264] zb_raw_cmd_handler(): 0x00 
10:20:54:097 -> [723498][I][ZigbeeHandlers.cpp:274] zb_raw_cmd_handler(): ZigbeeHandlers rawCMD 0xc6ca, 0xc6ca, 0x0, 0x0
10:20:54:097 -> [723499][I][z2s_devices_table.cpp:7766] Z2S_onUpdateDeviceLastRssi(): short addr 0xC6CA, rssi -68
10:20:54:097 -> [723499][I][z2s_devices_table.cpp:7059] Z2S_onCustomCmdReceive(): short address 0xC6CA, endpoint 0x01, cluster 0x000A, cmd id 0x0A
10:20:54:097 -> [723500][I][z2s_devices_table.cpp:382] Z2S_findZ2SCore(): sub id -1
10:20:54:098 -> [723500][I][ZigbeeHandlers.cpp:301] zb_raw_cmd_handler(): -----------------raw command not processed------------------
10:20:54:099 -> [723501][I][ZigbeeHandlers.cpp:89] zb_action_handler(): Receive Zigbee action(0x2000) callback
10:20:54:099 -> [723501][V][ZigbeeHandlers.cpp:344] zb_attribute_reporting_handler(): Received report from address(0xc6ca) src endpoint(1) to dst endpoint(1) cluster(0xa)
10:20:54:099 -> [723502][I][ZigbeeGateway.cpp:1399] zbAttributeReporting(): short address 0xC6CA
10:20:54:100 -> [723502][I][ZigbeeGateway.cpp:1384] zbProcessAttributeReporting(): 
10:20:54:100 -> Unknown report from device (0xC6CA):
10:20:54:100 -> endpoint (0x02X)        cluster (0x0001)
10:20:54:100 -> attribute id = 0x000A   attribute datatype = 0x00

W linii poniżej jest literówka 0x02X->0x%02X powodująca złe przypisanie argumentów.
https://github.com/lsroka76/Z2S_Library ... .cpp#L1386

TX POWER w SLACKY DIY zapisuje się i odczytuje poprawnie u mnie bez użycia manufacturer code. Nie przeprowadzałem jeszcze prób zasięgu w zależności od ustawionego wzmocnienia.

Według mnie warto byłoby wdrożyć do Z2S mechanizm alarmowania o stanie zasilania ze standardu ZigBee i klastra POWER CONFIG. Myślałem o LOCAL ACTIONS wtedy można sobie ustawić albo Virtual Binary albo wysłać powiadomienie. Przykre, że TUYA robi jakieś koszmarne protezy mając odpowiednie atrybuty w bibliotece. Poniżej część wykorzystana w routerze.

Code: Select all

#define ZCL_ATTRID_BATTERY_ALARM_MASK                   0x0035
#define ZCL_ATTRID_BATTERY_VOLTAGE_MIN_THRESHOLD        0x0036
#define ZCL_ATTRID_BATTERY_VOLTAGE_THRESHOLD_1          0x0037
#define ZCL_ATTRID_BATTERY_VOLTAGE_THRESHOLD_2          0x0038
#define ZCL_ATTRID_BATTERY_ALARM_STATE                  0x003E

wartość ZCL_ATTRID_BATTERY_ALARM_STATE jest w typie ZCL_BITMAP32 i w GUI się nie odczytuje poprawnie "Data type is Unknown data type(0x1B)

[vajera]

@vajera mam nadzieję, że odpocząłeś na plaży. Ja tez miałem urlop stąd przerwa w testach.

Odpocząłem, mam nadzieję, że Ty również.

Bramka testowa Z2S-1.5.152-13/08/26. - urządzenie dodaje się z dwoma kanałami GPM: UPTIME i VOLTAGE. Niestety wartości nie są aktualizowane - wygląda na brak obsługi raportów (log poniżej). W GUI ręcznie mogę odczytać atrybut TIME z klastra TIME, który dodałeś. BATTERY VOLTAGE z POWER CONFIG także w GUI odczytuje poprawnie razem z ustawieniami raportowania.

Potwierdzam, nie dodałem jeszcze obsługi tych komunikatów - zrobię to w najbliższym czasie.

W linii poniżej jest literówka 0x02X->0x%02X powodująca złe przypisanie argumentów.
https://github.com/lsroka76/Z2S_Library ... .cpp#L1386

Dziękuję, już poprawiłem.

Według mnie warto byłoby wdrożyć do Z2S mechanizm alarmowania o stanie zasilania ze standardu ZigBee i klastra POWER CONFIG. Myślałem o LOCAL ACTIONS wtedy można sobie ustawić albo Virtual Binary albo wysłać powiadomienie. Przykre, że TUYA robi jakieś koszmarne protezy mając odpowiednie atrybuty w bibliotece. Poniżej część wykorzystana w routerze.

Można wykorzystać Local Actions i warunkowanie, tylko wtedy potrzebny jest dodatkowy kanał GPM dla każdego urządzenia ze stanem baterii. Alternatywnie mogę dodać generowanie odpowiedniego zdarzenia dla urządzeń bateryjnych, np. ON_BATTERY_LEVEL_5_PERCENT?

[Beholder]

Można wykorzystać Local Actions i warunkowanie, tylko wtedy potrzebny jest dodatkowy kanał GPM dla każdego urządzenia ze stanem baterii. Alternatywnie mogę dodać generowanie odpowiedniego zdarzenia dla urządzeń bateryjnych, np. ON_BATTERY_LEVEL_5_PERCENT?

Myślałem bardziej o generowaniu zdarzeń, tam poziomy ustawiasz w atrybutach *THRESHOLD które chyba można ustawić z GUI w POWER CONFIG (nie sprawdziłem jeszcze) a na pewno są ustawiane przez firmware. Dodatkowo jest maska alarmów aktywnych - też można ustawić(teraz jest ustawione przez firmware na 7 czyli 0b00000111). Według mnie w atrybucie ZCL_ATTRID_BATTERY_ALARM_STATE pojawi się konkretny alarm. Wtedy bramka może generować zdarzenia:
ON_BATTERY_VOLTAGE_MIN_THRESHOLD
ON_BATTERY_VOLTAGE_THRESHOLD_1

Jeżeli będzie raportowana wartość do GPM VOLTAGE dodatkowo można sobie ustawić reakcję na napięcie.

[vajera]

Można wykorzystać Local Actions i warunkowanie, tylko wtedy potrzebny jest dodatkowy kanał GPM dla każdego urządzenia ze stanem baterii. Alternatywnie mogę dodać generowanie odpowiedniego zdarzenia dla urządzeń bateryjnych, np. ON_BATTERY_LEVEL_5_PERCENT?

Myślałem bardziej o generowaniu zdarzeń, tam poziomy ustawiasz w atrybutach *THRESHOLD które chyba można ustawić z GUI w POWER CONFIG (nie sprawdziłem jeszcze) a na pewno są ustawiane przez firmware. Dodatkowo jest maska alarmów aktywnych - też można ustawić(teraz jest ustawione przez firmware na 7 czyli 0b00000111). Według mnie w atrybucie ZCL_ATTRID_BATTERY_ALARM_STATE pojawi się konkretny alarm. Wtedy bramka może generować zdarzenia:
ON_BATTERY_VOLTAGE_MIN_THRESHOLD
ON_BATTERY_VOLTAGE_THRESHOLD_1

Jeżeli będzie raportowana wartość do GPM VOLTAGE dodatkowo można sobie ustawić reakcję na napięcie.

Problem polega na tym, że te atrybuty są opcjonalne i to firmware DIY do tego routera jest jednym z niewielu (jedynym), które je implementuje. Nie widzę natomiast większego problemu żeby rozwiązać to programowo na poziomie bramki.

[vajera]

Bramka testowa Z2S-1.5.152-13/08/26. - urządzenie dodaje się z dwoma kanałami GPM: UPTIME i VOLTAGE. Niestety wartości nie są aktualizowane - wygląda na brak obsługi raportów (log poniżej). W GUI ręcznie mogę odczytać atrybut TIME z klastra TIME, który dodałeś. BATTERY VOLTAGE z POWER CONFIG także w GUI odczytuje poprawnie razem z ustawieniami raportowania.

Począwszy od wersji 1.5.156-27/08/26 wartości UPTIME i VOLTAGE powinny się już aktualizować zgodnie z ustawieniami raportowania - proszę o informację zwrotną.

[Beholder]

Począwszy od wersji 1.5.156-27/08/26 wartości UPTIME i VOLTAGE powinny się już aktualizować zgodnie z ustawieniami raportowania - proszę o informację zwrotną.

Wartości kanałów się aktualizują poprawnie, może nie do końca zgodnie z oczekiwaniami tj. UPTIME raportuje samodzielnie co 75s z przycisku nie wysyła raportu z bieżącym czasem pracy. Natomiast VOLTAGE działa tylko z przycisku. Czekałem około 60 minut żeby zaraportował (może trzeba dłużej). Ogólnie jest dobrze. Tematowi tych alarmów jeszcze się przyjrzę bo przy analizie kodu źródłowego wyszło parę ciekawych rozwiązań tam zastosowanych, które można wykorzystać.