Ważny komunikat [bramka ZigBee]

[vajera]

Muszę Was niestety poinformować, że począwszy od wersji 1.3.0 do kodu wkradł się pewien subtelny błąd mogący mieć wpływ na brak raportowania stanu różnych czujników. Niewykluczone, że ten błąd sporadycznie pojawiał się również we wcześniejszych wersjach - poniżej krótki opis sytuacji i wnioski.

Każde urządzenie Zigbee ma swój stały adres IEEE (8 bajtów), który jest unikalny i pozwala jednoznacznie zidentyfikować urządzenie.

Dodatkowo urządzenia Zigbee posługują się tzw. short address (nwk address, 2 bajty), który jest unikalny w obrębie danej sieci i zmienia się przy każdym parowaniu.

Tworząc podstawy bramki oparłem się na tych adresach IEEE traktując je jako unikalne identyfikatory.

Wkrótce okazało się, że urządzenia, które raportują swój stan poprzez tzw. attribute reporting zgłaszają się poprzez short address - ponieważ miałem już sporo kodu opartego o ieee_addr użyłem funkcji znajdującej ten adres na podstawie tego krótkiego i wszystko wydawało się działać prawidłowo...aż do wersji 1.3.0.

W wersji 1.3.0 pozbyłem się tzw. bindowania lokalnego, tzn. tworzenia powiązań koordynator->urządzenia, zostawiając tylko bindowania w drugą stronę tzn. urządzenie->koordynator. Nie wchodząc w szczegóły tej decyzji wydawało się to korzystnym rozwiązaniem dla bramki (nadal tak uważam) i w dodatku bez skutków ubocznych.

Wkrótce pojawiły się jednak subtelne problemy z niektórymi czujnikami, np. Aqara P1, o których pisałem w oddzielnym wątku. Za każdym razem, gdy wydawało mi się, że rozwiązałem problem, on wracał.

Wczoraj wieczorem spędziłem kilka godzin z moją bramką SALON szukając przyczyny braku połączenia z powyższymi czujnikami. Po sparowaniu czujnik raportował prawidłowo, ale wystarczył restart i zapadało milczenie. Podłączyłem bramkę do komputera, włączyłem logi i nadal byłem w polu.

W końcu jednak udało się (na 99%) znaleźć źródło problemu:

- czujnik raportuje stan przez short address,
- bramka wywołuje funkcję mapującą short address na ieee_addr,
- na podstawie ieee_addr szuka odpowiedniego kanału Supla i wysyła do niego dane,
...
- chyba, że...w sieci pojawi się repeater, z którym połączy się czujnik...bo wtedy funkcja mapujaca zamiast prawidłowego ieee_addr zwraca FF:FF:FF:FF:FF:FF:FF:FF...dlaczego?...bo okazuje się, że nie ma skąd wziąć danych do mapowania - repeater zostawia je dla siebie, puszcza tylko short address a przed wersją 1.3.0 prawdopodobnie stos Zigbee brał te dane z lokalnej tablicy powiązań, której teraz już nie ma...

W związku z powyższym mam dwie wiadomości:

- dobra - mam już rozwiązanie problemu - muszę poprawić funkcje obsługujace komunikaty, tak żeby używały short address (1-2 godziny pracy wliczając testy),

- mniej dobra - zrobię to najwcześniej w niedzielę wieczorem albo w poniedziałek.

[Zibi_007]

Muszę Was niestety poinformować, że począwszy od wersji 1.3.0 do kodu wkradł się pewien subtelny błąd mogący mieć wpływ na brak raportowania stanu różnych czujników. Niewykluczone, że ten błąd sporadycznie pojawiał się również we wcześniejszych wersjach - poniżej krótki opis sytuacji i wnioski.

Każde urządzenie Zigbee ma swój stały adres IEEE (8 bajtów), który jest unikalny i pozwala jednoznacznie zidentyfikować urządzenie.

Dodatkowo urządzenia Zigbee posługują się tzw. short address (nwk address, 2 bajty), który jest unikalny w obrębie danej sieci i zmienia się przy każdym parowaniu.

Tworząc podstawy bramki oparłem się na tych adresach IEEE traktując je jako unikalne identyfikatory.

Wkrótce okazało się, że urządzenia, które raportują swój stan poprzez tzw. attribute reporting zgłaszają się poprzez short address - ponieważ miałem już sporo kodu opartego o ieee_addr użyłem funkcji znajdującej ten adres na podstawie tego krótkiego i wszystko wydawało się działać prawidłowo...aż do wersji 1.3.0.

W wersji 1.3.0 pozbyłem się tzw. bindowania lokalnego, tzn. tworzenia powiązań koordynator->urządzenia, zostawiając tylko bindowania w drugą stronę tzn. urządzenie->koordynator. Nie wchodząc w szczegóły tej decyzji wydawało się to korzystnym rozwiązaniem dla bramki (nadal tak uważam) i w dodatku bez skutków ubocznych.

Wkrótce pojawiły się jednak subtelne problemy z niektórymi czujnikami, np. Aqara P1, o których pisałem w oddzielnym wątku. Za każdym razem, gdy wydawało mi się, że rozwiązałem problem, on wracał.

Wczoraj wieczorem spędziłem kilka godzin z moją bramką SALON szukając przyczyny braku połączenia z powyższymi czujnikami. Po sparowaniu czujnik raportował prawidłowo, ale wystarczył restart i zapadało milczenie. Podłączyłem bramkę do komputera, włączyłem logi i nadal byłem w polu.

W końcu jednak udało się (na 99%) znaleźć źródło problemu:

- czujnik raportuje stan przez short address,
- bramka wywołuje funkcję mapującą short address na ieee_addr,
- na podstawie ieee_addr szuka odpowiedniego kanału Supla i wysyła do niego dane,
...
- chyba, że...w sieci pojawi się repeater, z którym połączy się czujnik...bo wtedy funkcja mapujaca zamiast prawidłowego ieee_addr zwraca FF:FF:FF:FF:FF:FF:FF:FF...dlaczego?...bo okazuje się, że nie ma skąd wziąć danych do mapowania - repeater zostawia je dla siebie, puszcza tylko short address a przed wersją 1.3.0 prawdopodobnie stos Zigbee brał te dane z lokalnej tablicy powiązań, której teraz już nie ma...

W związku z powyższym mam dwie wiadomości:

- dobra - mam już rozwiązanie problemu - muszę poprawić funkcje obsługujace komunikaty, tak żeby używały short address (1-2 godziny pracy wliczając testy),

- mniej dobra - zrobię to najwcześniej w niedzielę wieczorem albo w poniedziałek.

Tutaj nie jest ważne. czy nowa wersja będzie w niedzielę, poniedziałek czy nawet we wtorek.
Ważne jest, że nie zlekceważyłeś zgłoszeń i zlokalizowałeś przyczynę. A później znalazłeś rozwiązanie.
Przy tak rozbudowanym kodzie bramki (buszowałem tam wczoraj) jestem pełen podziwu
Brawo!

[Lector]

Ok, poczekamy
Nikt nie będzie miał żalu - miłych Walentynek.

Dla przypomnienia, to święto murarzy i tynkarzy

[Robert Błaszczak]

[...]
W związku z powyższym mam dwie wiadomości:

- dobra - mam już rozwiązanie problemu - muszę poprawić funkcje obsługujace komunikaty, tak żeby używały short address (1-2 godziny pracy wliczając testy),

- mniej dobra - zrobię to najwcześniej w niedzielę wieczorem albo w poniedziałek.

Obie wiadomości są bardzo dobre. Nawet jakby poprawki trafiły w następny poniedziałek. To to też będzie bardzo dobra wiadomość.

[george1255]

No i minie jest ta przypadłość. Dodaje czujniki, więc bramka się restartuje, kilka dodanych na początku przestaje raportować. Trzeba je dodawać albo wyjąć baterię na dłuższą chwilę

[vajera]

Za mniej więcej kwadrans dostępna będzie wersja 1.4.22-15/02/26, w której obsługa raportowania z urządzeń Zigbee jest już oparta o tzw. short address.

W związku z tym mam ogromną prośbę o przetestowanie tej wersji - jestem na wyjeździe i mam ze sobą tylko gniazdko IKEA i czujnik otwarcia Aqara - oba wydają się pracować prawidłowo, ale opcji do przeanalizowania jest znacznie więcej. Ta aktualizacja niczego nie zepsuje i w każdym momencie można wrócić do poprzedniej wersji.

[Lector]

Wgrane, czekam na efekty

[Lector]

Jeszcze brak pobrania stanu baterii.
Dziś dodałem nowy też bez baterii - za wcześnie pewnie.
Ale....
W nowym pod (i) mam siłę sygnału radia, a tej informacji nie ma w starych wcześniej dodanych.

Trzeba będzie sparować na nowo, czi coś?

[vajera]

Jeszcze brak pobrania stanu baterii.
Dziś dodałem nowy też bez baterii - za wcześnie pewnie.
Ale....
W nowym pod (i) mam siłę sygnału radia, a tej informacji nie ma w starych wcześniej dodanych.

Trzeba będzie sparować na nowo, czi coś?

Jaki to model czujnika? W przypadku niektórych czujników zaraportowanie stanu baterii może zająć do 24h. W teorii, jeżeli problem dotyczył tego adresowania, to nie jest konieczne ponowne parowanie.

[Lector]

Jaki to model czujnika? W przypadku niektórych czujników zaraportowanie stanu baterii może zająć do 24h. W teorii, jeżeli problem dotyczył tego adresowania, to nie jest konieczne ponowne parowanie.

Brak siły radia dla"

Code: Select all

Slot# 00 | Manufacturer name _TZ3000_yxqnffam | model ID TS0203 | Z2S model Unknown Zigbee model [0x2040]
IEEE address A4:C1:38:6A:A0:44:17:44 | Short address 0xBEDD | Power source 0x00
Battery percentage 255 | Last seen (ms) 4836221 Last RSSI 0
Device flags 0x00000121 | ud(1) 0x00000000 | ud(2) 0x00000000

oraz

Code: Select all

Slot# 01 | Manufacturer name _TZ3000_k4ej3ww2 | model ID TS0207 | Z2S model Unknown Zigbee model [0x2040]
IEEE address A4:C1:38:E9:DA:55:DD:6C | Short address 0x7E34 | Power source 0x00
Battery percentage 255 | Last seen (ms) 4825886 Last RSSI -94
Device flags 0x00000121 | ud(1) 0x00000000 | ud(2) 0x00000000

Siła radia pojawiła mi się na nowo dodanym:

Code: Select all

Slot# 05 | Manufacturer name _TZ3000_ww9i3e0y | model ID TS0207 | Z2S model Unknown Zigbee model [0x2040]
IEEE address A4:C1:38:F2:4C:6A:73:9F | Short address 0x5026 | Power source 0x00
Battery percentage 255 | Last seen (ms) 96098 Last RSSI -88
Device flags 0x00000021 | ud(1) 0x00000000 | ud(2) 0x00000000

Baterii jeszcze nie pokazał żaden pomimo wzbudzania czujników - daje czas jeszcze.