Czujnik otwarcia - Develco WISZB-120 - dramatyczne opóźnienia w sieci zigbee

Urządzenia Urządzenia inteligentnego domu
,
1

Moi Drodzy,

Od dłuższego czasu używam czterech identycznych czujników otwarcia drzwi/okien Develco WISZB-120. W funkcji sygnalizacji otwarcia wszystkie pracują bez zarzutu. Ale od ponad 3-ech miesięcy dwa z nich wysyłają potwierdzenie zamknięcia z gigantycznym opóźnieniem, sięgającym nawet kilkunastu minut! Pozostałe dwa nie mają takiego problemu i sygnał zamknięcia wysyłany jest natychmiast.
Nigdy nie zmieniałem lokalizacji tych sensorów, ten problem pojawił się dość nagle. Zasilanie bez zarzutu, baterie wymieniane regularnie. Mam po domu rozsiane różne inne urządzenia zigbee (zasilane z sieci 230V), które pełnią rolę wzmacniaczy sygnału, więc trudno podejrzewać, że jest za mały zasięg (tym bardziej, że przy otwieraniu sensory te wykazują bezbłędną orientację - problem dotyczy tylko zamykania).
Próbowałem chyba wszystkiego, łącznie z ‘twardym’ usunięciem obu feralnych sensorów z HA i powtórnym ich sparowaniem (zawsze udanym). Wygląda na to, że eletronika jest OK, źródło błędu leży chyba gdzie indziej… Ale gdzie?
A może jest tak, że błędne czujniki wysyłają komunikat o zamknięciu całkiem poprawnie, ale sam komunikat zostaje gdzieś zbuforowany i czeka na coś? (np. na powtórne potwierdzenie zamknięcia?) Byłoby to jednak niezgodne z zasadą działania sensora binarnego, który wysyła przecież swój stan z chwilą jego zmiany a nie w momencie, który sobie ‘upodoba’.

Jedyna widoczna różnica w ustawieniach urządzeń jest następująca:

  1. Poprawnie dziające czujniki mają tak:

    image
    image979×266 6.41 KB

  2. Natomiast te dziające błędnie mają tak:

    image
    image1077×257 6.78 KB

Oczywiście widać różnicę w polu genPollCtrl, problem jest jednak taki, że w błędnych czujnikach nie da się tego odznaczyć (chwilę po odznaczeniu pole to samoczynnie zaznacza się z powrotem).

Proszę Was o pomoc, gdyż dziwne zachowania obu czujników uniemożliwiają poprawną pracę m.in. system alarmowego, generuje też szereg innych niepożądanych implikacji…

2

Połącz przez inny/ router ZigBee I zobacz czy jest tak samo.

1 polubienie
3

A jesteś pewien że te czujniki są identyczne? tj. czy mają identyczne firmware (oprócz tego samego sprzętu).

4

Dzięki @artpc za wskazówkę, chcę spróbować pójść tą drogą. Ale nie mam pojęcia, w jaki sposób w Z2M wymusić podłączenie konkretnego sensora do innego (konkretnego) routera? Dotychczas wszystkie urządzenia wykrywane były automatycznie i podłączały się same (tzn. bez mojego udziału) do koncentratora Conbee II lub do któregoś (stojącego w topologii sieci przed koncentratorem) routera zigbee (gniazdko el., przełącznik, sterownik rolet), który z jakiegoś prowodu (nie wiem z jakiego?) uznały za właściwy. (Powinien istnieć chyba jakiś mechanizm wymuszający podłączanie się sensora zawsze (ew. przynajmniej domyślnie) do routera o najsilniejszym dla niego sygnale sieci zigbee).
Dziś moja sieć zigbee wygląda więc tak:

image
image1502×836 110 KB

Na tym zbliżeniu widać, że oba problematyczne sensory (Drzwi Garaż oraz Drzwi Front) podpinają się do routerów fizycznie im najbliższych:

image
image530×514 45.5 KB

Te z kolei łączą się bezpośrednio z koncentratorem Conbee II.
Zatem pozostaje pytanie jak wymusić połączenie wybranego sensora z wybranym/wskazanym (przez użytkownika) routerem?

Tak, raczej jestem tego pewien. Dotychczas wszystkie cztery śmigały aż miło. Kupione w jednej dostawie, numery seryjne prawie po kolei. Urządzenia oryginalne Develco (nie “china edition”). Teraz Develco to po rebrandingu Frient , ale to nie ma przecież znaczenia.

Wiadomość z ostatniej chwili: Firmware’y są w identycznej wersji: 3.4.16. Zajrzałem do [About] i tam znalazłem szczegóły. Niczym nie różnią się od siebie, wszystkie 4 sensory mają dokładnie to samo…

5

Wniosek - te routery do których się łączą są “trefne”, musisz prawdopodobnie pożonglować innymi urządzeniami.

6

Mapa wygląda jak Gwiazda Śmierci :slightly_smiling_face:
Usuń urządzenie z sieci, tam gdzie masz, Permit join (All) wybierz inny router z listy i Permit join (All) - > sparuj urzadzenie

7

Tak jak radziliście, oba problematyczne czujniki otwarcia podpiąłem do innych routerów , ale zupełnie nic to nie zmieniło.
Generalnie zaobserwowałem, że od pewnego czasu opóźnienia sygnałów z urządzeń zigbee (nie tylko z tych dwóch czujników) ciągle wzrastają. Pojawiły się problemy opóźnień nawet w zwykłych switchach z pomiarem energii. Załączenie/wyłączenie switcha wykonywane (i sygnalizowane) jest natychmiast, ale dane o chwilowym obciążeniu (poborze mocy) są mocno opóźniane. Lagi sięgają czasem nawet kilkunastu minut, co z pewnością nie jest normalne…
Zastanawiam się nad przyczyną… Czy to możliwe, żeby sieć zigbee została przeciążona ilością urządzeń? (w sumie mam ich 102). Czy dodanie kolejnego kooordynatora Conbee II i sparowanie z nim połowy urządzeń zigbee (o ile to w ogóle jest wykonalne) rozwiązałoby problem?

Inną opcją byłoby całkowite przeinstalowanie dodatku Z2M, ale wtedy boję się, że wszystkie urządzenia bedę musiał parować od początku (co z powodu b. utrudnionego już dostępu do części z nich byłoby zdaniem lekko karkołomnym i mocno czaochłonnym. Nie wiem czy warto.). Chyba, że istnieje jakiś sposób zapisania bazy danych urządzeń zigbee (wraz z ustawieniami) gdzieś do pliku i ponowny jego odczyt już po przeinstalowaniu Z2M.

Zupełnie nie mam pomysłu i nie wiem jak sobie z tym poradzić… Podpowiecie, proszę?

8

Przez parę lat, kiedy zaglądam na to forum był jeden podobnie opisywany przypadek i… wtedy przyczyną okazał być się wyciek pamięci w jakimś zupełnie innym komponencie (prawdopodobnie NR, jak w zdecydowanej większości innych podobnych przypadków).
Monitorujesz zasoby hosta na którym pracuje HA?

Przy takim rozmiarze sieci jest to w sumie prawdopodobne i możliwe (CC2531 wymięka przy około 40 urządzeniach)
Jeśli planujesz drugi koordynator pomyśl jednak nad jakimś mocniejszym sprzętem z obsługą Zigbee3 - może do rozważenia “oficjalny” dongiel Zigbee dla HA? (niedostępny póki co w PL, ani w sumie nigdzie :stuck_out_tongue: ale kolejna partia ma być pod koniec miesiąca), 3 przykładowe sklepy, w których rozpatrywałbym ewentualny zakup, gdybym musiał
SeedStudio (Chińczycy z dość drogą przesyłką, ale to w 100% wiarygodny sklep, swoją drogą nietypowy sprzęt sam u nich kupowałem i robią to też niektórzy znajomi)
RaspberryPI.dk (nie mam doświadczenia, nie sprawdzałem czy jest wysyłka do PL)
m.nu (mają dostawę do PL, nie kupowałem, ale byli tacy, w tym wypadku osoby dla mnie obce, to info z któregoś z forów)

Istnieje, przeczytaj dokumentację…
Jakkolwiek nie sądzę, aby to mogło pomóc - jeśli przyczyna tkwi w samym Zigbee to właściwie niemal jedyne potencjalne jej źródło (oczywiście poza brakiem zasobów w samym koordynatorze), to właśnie uszkodzona baza konfiguracji sieci, którą zamierzasz przywrócić.
Radziłbym usunąć z sieci te urządzenia, które podejrzewasz, że mogą być problematyczne, a gdy się już dorobisz drugiego koordynatora, to oczywiście sugeruję problematyczne urządzenia właśnie z nim sparować, stosując oczywiście regułę by sprawiedliwie rozłożyć routery (nie znam topologii, ale do rozważenia są 2 strefy pokrywające różne powierzchnie lub, jeśli masz duże zagęszczenie sprzętu strategia 2 osobnych sieci tak by miały funkcjonalnie inne zadania), oczywiście drugi koordynator sugeruję mieć na innym kanale (“zdrowe” kanały to 11,15 20 i 25, nie wiem na którym masz obecną sieć, ale drugą sugeruję na 25).

1 polubienie
9

Dziękuję, za - jak zawsze - cenną poradę. Właśnie kliknąłem zakup dongla w SeedStudio. Jak tylko go dostanę, natychmiast zaraportuję efekt rekonfiguracji sieci zigbee. Jeszcze raz baaaardzo dziękuję… :beer:

10

Kurczę, szkoda, że się nie odezwałeś wcześniej - przesyłka 2 sztuk by się rozłożyła na 2 osoby.

11

No faktycznie, nie pomyślałem o tym do końca… ale z powyższego tekstu wnioskowałem, że nie masz potrzeby zakupowej. Przepraszam, jeśli zawiodłem :wink:

12

Luzik, nie potrzebuję “na gwałt”, bardziej mnie to kusiło jako eksperyment (bo sprzętu jak na obecne potrzeby mam i tak już za dużo), a nie wiem skąd, ale kojarzyło mi się, że jesteś z Wrocławia.

13

Masz całkowicie poprawne skojarzenie :smiley: choć nie pamiętam, żebym gdziekolwiek o tym wspominał… Czyżby Pegasus? hihi… :smile: :smile:

14

Już wiem skąd - masz w profilu :stuck_out_tongue:

15

Nie bardzo wiem wiem jak rozumieć “wyciek pamięci”… bo pewnie wcale nie chodzi o to, czy w moim serwerku HA (Dell WYSE Z90D7) RAM jest dziurawy i coś z niego kapie lub leje się strumieniem… :smile:

Do monitorowania zasobów hosta używam karty typu button-card, która odczytuje/wyświetla wartości kilku podstawowych encji monitorujących, a wygląda to tak:

image

Na pokładzie hosta porządny dysk SSD 480GB, RAM 8GB, 2-rdzeniowy procek 1.65GHz.
Instalacja HA zrobiona - z resztą także za Twoją poradą - na “gołą blachę” (bare metal).
Mógłbyś mnie jakoś naprowadzić na sposób ustalenia żródła potencjalnego “wycieku”? (fajne słowo… ) Jak to sprawdzić? Czy są do tego dostępne w HA jakieś narzędzia diagnostyczne? Czy np. NR (którego ja też podejrzewam o pewną niestabilność) ma w sobie takie narzędzie? Bedę wdzięczny nawet za link do poczytania… :wink:

PS: Dodam jeszcze, że coraz częściej zdarzają mi się “puste ekrany”:

image
image575×537 14.2 KB

Wyraźnie coś cieknie…

16

Wyczyść cache w przeglądarce.

Wracając do potencjalnego wycieku (to była tylko teoria poparta prawdopodobieństwem zdarzenia :stuck_out_tongue: nie twierdzę że akurat masz ten problem).
Karta prezentująca bieżące wartości się nie przyda, do tego potrzebne są wykresy, konkretnie prezentujące użycie swapa i RAMu (najwygodniejsze w obserwacji są wartości w %). Oprócz tego warto w ten sposób monitorować też inne zasoby hosta - tu już nie pod kątem wycieku pamięci, ale w ogóle wykorzystania sprzętu - tu przydatne są sensory procka - obciążenie procentowe i linuksowa miara “load” obrazująca czy system pracuje realtime czy łapie lagi z powodu zbyt słabego procka.

Tu masz świetny przykład wycieku pamięci - pierwszy post

albo wykresik w tym moim poście (jeśli dobrze pamiętam to był wyciek pamięci w jednym z Dodatków)

PS Na obrazku widzę, że prawdopodobnie monitorujesz ruch przychodzący i wychodzący z karty sieciowej - podziel się informacjami jak zrobiłeś te sensory tam (ja nie wiem)

17

Post został scalony z istniejącym tematem: Monitoring sprzetu hosta, HAOS-ova, wirtualizacja pod Windows

18

Dodaj sobie jeszcze sensory z integracji Supervisor usługi

Screenshot - 13.01.2023 , 21_01_50

Np. Dla NR

Screenshot - 13.01.2023 , 21_02_12
Screenshot - 13.01.2023 , 21_02_121070×747 50.4 KB

i innych które podejrzewasz że ciekną, dorób automatyzację/powiadomienie przy przekroczeniu parametrów.
Tu masz Flow NR pokazujący wykorzystanie przez NR

https://forum.arturhome.pl/t/rozbieganie-zuzycia-cpu-wraz-z-uplywem-czasu/6972/15?u=artpc

19

Zrobiłem jak radziliście, @artpc i @szopen . Oto pierwsze wyniki inwestygacji:

  1. Stworzyłem wykresy statystyk wszystkich integracji, które udostępniają encje memory_percent:

    image
    image808×747 53.8 KB

  2. Wyłączyłem całkowicie wszystkie flowy w NR, wykonałem powtórny Deploy i odpaliłem zaimportowany flow wskazany przez @artpc

[{"id":"da3d35e1314f395a","type":"inject","z":"58aa202c0d7e669e","name":"","props":[{"p":"payload"},{"p":"topic","vt":"str"}],"repeat":"","crontab":"","once":false,"onceDelay":0.1,"topic":"","payload":"","payloadType":"date","x":270,"y":460,"wires":[["1b4aac38a3d0cd92"]]},{"id":"1b4aac38a3d0cd92","type":"function","z":"58aa202c0d7e669e","name":"","func":"let mem = process.memoryUsage()\n\nconst formatMem = (m) => (m / 1048576).toFixed(2)\n\nmsg.topic = 'Memory Use (MB)'\nmsg.payload = {\n    RSS: formatMem(mem.rss),\n    HeapUsed: formatMem(mem.heapUsed),\n    HeapTotal: formatMem(mem.heapTotal),\n    'External C++': formatMem(mem.external)\n}\n\nreturn msg","outputs":1,"noerr":0,"initialize":"","finalize":"","libs":[{"var":"process","module":"process"}],"x":410,"y":460,"wires":[["24ec3a426815da70"]]},{"id":"24ec3a426815da70","type":"debug","z":"58aa202c0d7e669e","name":"","active":true,"tosidebar":true,"console":false,"tostatus":false,"complete":"false","statusVal":"","statusType":"auto","x":560,"y":460,"wires":[]}]

Dostałem następujące wyniki:
image

I tu następuje moja pierwsza konsternacja: zupełnie nie umiem zinterpretować tych wyników. Nie wiem, czy są w normie, czy odbiegają (jak bardzo?) od oczekiwań, od czego zależą i jak te wartości są powiązane z RAMem (8 GB) zainstalowanym w hoście.

  1. Zauważyłem jedną niepokojącą (chyba) rzecz:
    image

Czy to oznacza, że z jakichś (jakich?) powodów plik swap w ogóle się nie utworzył (kolejna konsternacja)? A może wcale nie musi się tworzyć, skoro zapotrzebowanie na RAM (patrz wykres powyżej) nie przekracza (i nigdy nie przekraczało) 50% dostępnej pamięci? Myślę trochę “windowsowo”, gdzie plik swap tworzy się w przypadku zapotrzebowania na pamięć przekraczającą dostępność RAM’u, ale HAOS to przecież linux, więc może kompletnie tu odleciałem…

  1. Przekroczenie parametrów:

Jakie wartości parametrów ustawić jako graniczne aby powiadomienie miało sens?

20

Ta rzecz to podstawa do bycia oazą spokoju - swap w HAOS ma takie ustawienia by najpierw maksymalnie wykorzystać RAM (uruchamia się gdzieś przy 80% zajęcia RAMu i takie zachowanie jest całkowicie normalne, bo dostęp do dysku jest od tysięcy do milionów razy wolniejszy niż do RAM), generalnie to jest “rozwiązanie ratunkowe” na okazję braku pamięci.

Póki wykorzystanie swapa jest 0% to jest jak najbardziej w porządku.

Co do analizy danych, no cóż sądząc po wykresie, który wrzuciłeś wyciek pamięci jest prawdopodobny, ale za często restartujesz serwer, aby zauważyć skutki, to po prostu musi pracować w niezakłócony sposób kilka- kilkanaście dni (minimum bez żadnych restartów niczego przez tyle dni ile masz ustawiony recorder) by było widać trendy - jeśli nie masz wycieku pamięci, to wykorzystanie RAMu musi się w końcu ustabilizować, póki co widać trend rosnący po każdym restarcie.

Monitoruj też obciążenie procesora + load (polecam 1- i 15- minutowy - to w powiązaniu z liczbą procesorów = rdzeni widzianych przez linux da jakieś pojęcie o faktycznym obciążeniu procesora - optymalnie gdy load nigdy nie przekracza ilości procesorów, wtedy bezwzględnie wszystko dzieje się realtime).

A co do sieci Zigbee, to stawiam, na brak zasobów koordynatora (ale tego nie umiem sprawdzić i nawet nie wiem czy jest możliwe).