Czyli próba wysłania ustawień do sterownika
No i po tym tracę komunikację ze wszystkim :
Zigbee2MQTT:error 2024-01-11 13:54:50: Failed to execute LQI for 'Coordinator'
Zigbee2MQTT:error 2024-01-11 13:54:56: Failed to execute LQI for 'Garaz - Blaszkax2'
Zigbee2MQTT:error 2024-01-11 13:55:02: Failed to execute LQI for 'Wtyczka '
zmieniłem port USB
2 - zmieniłem kanał z 11 na 25
3 - podłączyłem wszystkie urządzenia od nowa (wczesnej je wykasowałem oczywiście) zachowując zasadę ze podpinam od najbliższego do najdalszego, tak aby siatka się poprawnie zbudowała
Przez 1 dzień wyglądało że jest lepiej , ale znowu pojawiają mi się te same błędy i wrażenie że zawiesza się Z2M. W logach mam błędy o braku możliwości wysłania komendy do urządzenia i nic poza tym
Inny użytkownik forum używa na takim sprzęcie v7.3.1.0 (choć nie podaję linka, bo moim zdaniem wgrał nieprawidłowy plik firmware)
“poza konkurencją”
Ja stawiam na jakieś konkretne urządzenie w twojej sieci Zigbee, które powoduje problemy, mam konkretnie na myśli to
więc nie paruj tego sterownika w ogóle do sieci Zigbee, nawet nie podawaj mu zasilania po usunięciu z sieci
No i skoro zignorowałeś wszystkie INNE możliwe przyczyny w ogóle nie powiązane z Z2M
W ogóle skorzystałeś z sugestii i wyłączyłeś NR chociaż na jakiś czas, by się przekonać czy on nie zabiera całych zasobów serwera?
Swój koordynator możesz wysłać do mnie na testy (lub przegadaj sprawy wsparcia z jego autorem, możesz go też zaprosić do nas na forum), ale jego wymiana może być bezcelowa, jeśli problem pochodzi z jakiegoś innego źródła.
sorry pomyliłem osoby - jest kilka podobnych wątków na forum powstałych w zbliżonym czasie, a dotyczących różnego sprzętu.
Ponieważ to Sonoff ZBDongle-E to nie widzę sensu jego wymiany (no chyba, że masz wadliwy egzemplarz, jakkolwiek wciąż możesz go podesłać na testy do mnie, testy za free, natomiast nie gwarantuję żadnego szybkiego terminu - zdrowie mi się posypało, więc nie chcę nic obiecywać, przesyłkę w obie strony pokrywasz sam).
Mój komentarz do wypustów Dresden Elektronik (celowo zapisuję II jako 2 i III jako 3)
conbee2 jest sprzętowo przestarzały i mimo, że to naprawdę majstersztyk producenta, sens jego zakupu zmalał do zera w momencie premiery conbee3, pewne opcje (np. parowanie przez QR) są w nim niedostępne i nie wiadomo czy będą
conbee3 jest sprzętowo niemal bliźniakiem Sonoffa ZBDongle-E, wprawdzie wsparcie niemieckiego wytwórcy jest o niebo lepsze niż chińskiego iTead, to jednak Dresden Elektronik będzie moim zdaniem w pierwszej kolejności przygotowywać firmware pod współpracę z innym ich sztandarowym produktem deConz, a sam sprzęt w Z2M i ZHA będzie korzystał dokładnie z tego samego sterownika co zbdonglee czyli
Dobra wyjaśnię czemu tak uważam, wprawdzie nie kopałem po dokumentacji, a pewnie by się przydało.
Moim zdaniem hw oznacza sprzętową kontrolę przepływu, a z tego co kojarzę ZBDongle-E ma kontrolę programową…
edit
tak się nazywa oryginalny firmware iTead/Sonoff (tu przy okazji wychodzi druga kwestia - jak bardzo producent sprzętu ma wylane na wydawanie aktualizacji…)
ncp-uart-sw_EZNet6.10.3_V1.0.1.gbl
w każdym razie nabieram pewności, że mi się nie zdawało, iż kontrola przepływu jest programowa.
A w kwestii wersji protokołu, to nie twierdzę, że protokół MQTT w wersji 4 jest całym złem tego świata (w ogóle to istnieje taka wersja?), ale Z2M jest w stanie wykorzystywać 5.
Broker Mosquitto też go obsługuje od dawna
U siebie z koordynatorem na MCU TI CC2652P używam 5, ale sprzęt jest zupełnie inny - na stacku zstack, ponadto to może mieć powiązania z innymi ustawieniami (też nie wszystko pamiętam i znam od podszewki)
Byłoby fajnie gdyby inni użytkownicy ezsp, którym ten sprzęt działa bezproblemowo się podzielili swoimi konfiguracjami.
Tam jest opis flashowania dualstack, to w ogóle jest oderwane od tematu, bo firmware dualstack działa CAŁKOWICIE inaczej i jest niekompatybilne z normalnymi integracjami Zigbee, bo wymaga dodatkowego oprogramowania - pośredniczącego dodatkowego serwera, bo wtedy dongle nie jest samodzielnym koordynatorem, a de facto jedynie modemem Zigbee+Thread, a funkcje koordynatora pełni ten dodatkowy serwer.
Standardowy disclaimer - nie jestem nieomylny, niech się inni obeznani w temacie wypowiedzą…
Troszkę poeksperymentowałem z uwzględnieniem Waszych uwag i sugestii - proszę nadal o wyrozumiałość bo moja wiedza jest jeszcze co najmniej skromna.
Mam małe postępy ale jeszcze chyba długa droga przede mną.
Na tą chwilę uzyskałem efekt że przez cały dzień nie miałem zawieszenia , ale jak chciałem odtrąbić sukces to …
Zrobiłem zgodnie z sugestiami
odłączyłem prawie wszystkie urządzenia
wyłączyłem dodatek Node-Red
ponownie dodałem urządzanie - co niektóre “lepiej” się dodały chodzi o1 termostat , w którym nie widziałem harmonogramów, teraz już widzę.
uruchomiłem node-red ponownie
i tak działało od wczoraj , aż do momentu chęci dodania kolejnego modułu - zwykłego switcha mini .
Po próbie włączenia trybu dodawania error -
2024-01-17 20:30:41,"error","local0","Zigbee2MQTT","localhost","Request 'zigbee2mqtt/bridge/request/permit_join' failed with error: 'Connection not initialized'/n"
Co ciekawe drugi raz uruchomienie trybu dodawania wszystko zadziałało
Nie chodzi że sie nie powiodło , tylko że nie można było nawiązać kontaktu z koordynatorem - tak jakby się uśpił
Nie napisałem że wtedy nie działały także odczyty i wysyłanie poleceń do już dodanych urządzeń
Po “wybudzeniu” wszystko wróciło do normy
Zupełnie nie rozumiem tej procedury, chyba nie zrozumiałeś co dany krok miał przetestować…
Wyłączenie NR na zawsze! w skali eksperymentu miało zagwarantować, że żaden wadliwy proces uruchomiony wewnątrz niego nie zabierze całych zasobów systemu. Więc jego włączenie niweczy cały wykonany eksperyment. Wyciek pamięci, którego się tu spodziewam nie jest szybkim zabójcą tylko powolnym i utajonym.
Ale nie musimy tak kombinować, po prostu powinieneś zacząć monitorować kluczowe zasoby, czyli instalujesz integrację
i uruchamiasz jakiś minimalny zestaw sensorów, np. taki jaki sugerowałem kiedyś tam (tylko weź poprawkę, że teraz tą integrację konfiguruje się w GUI, a NIE w YAMLu, ale kod kart wciąż można wykorzystać, po zmodyfikowaniu na swoje encje)
Może podkreślę - najważniejsze jest procentowe wykorzystanie RAMu i swapa, ale polecam monitorować wszystkie ważne zasoby, w tym obciążenie procesora czy jego temperaturę (to akurat w inny sposób), bo wiedza o nich bywa kluczowa w diagnozowaniu sytuacji mało powtarzalnych.
Teoretycznie pojedyncza sesja dodawania urządzeń do sieci Zigbee nie może trwać dłużej niż 4 minuty z groszami, więc trudno czasem się zmieścić w okienku czasowym.
Z2M do niedawna umożliwiało obejście tego ograniczenia przez włączenie stałego parowania (to jest w ustawieniach i oczywiście bezwzględnie należy je wyłączyć po robocie), no nie mam pod ręką żadnego upierdliwego sprzętu by sprawdzić czy nadal jest możliwość realizacji parowania w sesji bez time-outu.
Rzeczywiście źle zrozumiałem z NR - zrobię monitor , aczkolwiek patrząc w supervisior na stan pamięci nie zauważam przeciążenia.
Co do uruchamiania sesji dodawania to źle interpretujesz - chodzi o to że 1 próba włączenia trybu dodawania daje mi komunikat błędu
2024-01-17 20:30:41,"error","local0","Zigbee2MQTT","localhost","Request 'zigbee2mqtt/bridge/request/permit_join' failed with error: 'Connection not initialized'/n"
i nie włącza się , natychmiastowe drugie włączenie tej procedury już uruchamia proces. Więc nie chodzi o to że nie mogę dodać tylko że nie mogę uruchomić procedury dodawania .
Tak na bieżąco po uruchomieniu monitora
NR jest włączone
Pojedynczy odczyt stanu jeszcze o niczym nie świadczy - wartości masz wręcz idealne, ALE stan zasobów trzeba analizować w funkcji czasu, do tego wystarcza najzwyklejszy wykres historii, zawierający kilka czujników naraz (dlatego wykorzystanie procentowe się przydaje, bo znamy granice i jest wspólna skala).
Natomiast samo monitorowanie póki co nie zastępuje wyłączenia NR - nie wiemy czy w procesach uruchomionych w NR odwołujesz się do jakichkolwiek urządzeń Zigbee, jeśli tak, to go wyłącz; jeśli natomiast żaden proces nie dotyka niczego związanego z Zigbee, to NR może zostać włączony (mamy już monitorowanie, to potencjalny wyciek pamięci będzie widoczny na wykresie).
Nie miałem siły na analizę wszystkiego, ale w końcu jest coś, co może dość jednoznacznie wskazywać na bezpośredni problem z koordynatorem lub jego komunikacją z Z2M.
Teraz pytanie dodatkowe - czy ten problem występuje zawsze i bezwzględnie?
również po zrestartowaniu systemu?
Co rozumiesz przez wybudzenie, jak to realizujesz?
Próbowałeś bez przedłużacza USB?
Innego ortu USB?
Czy w ogóle się skutecznie pozbyłeś integracji ZHA? Co z firmware koordynatora?
NR w zasadzie mam tylko dla urządzeń ZigBee - przynajmniej na razie bo dopiero buduję automatykę, ale oczywiście zrobię testy z wyłączonym NR na stałe.
Co do wartości wiem że są dobre , zwłaszcza że używam zwykłego PC a nie RaspberryPI (Jakoś po krótkim zachwycie nie przemawia do mnie ten sprzęt w szczególności wydajność do ceny).
Ten źle dodany termostat to podejrzewam że przyczyna było to iż był/jest w dość niekorzystnym miejscu na granicy zasięgu.
A teraz
Problem występuje zawsze i bezwzględnie również po restarcie systemu/ hosta
wybudzanie - czyli jak kliknę 1 raz na funkcje dodawania urządzeń mam komunikat jak pisałem , ponowne kliknięcie juz jest poprawny komunikat , czyli tak jakby pierwsze kliknięcie budziło śpiący koordynator / połączenie z koordynatorem.
tak próbowałem bez przedłużacza
tak obecnie mam na innym porcieUSB
tu nie dam odpowiedzi wydaje mi się ze tak skutecznie pozbyłem sie integracji z ZHA ale nic nie dam sobie uciec Jak to sprawdzić?
Frimware koordynatora mam 6.10.3.0 build 297 i nie mogę znaleźć nowszej - może źle szukam
Objawy skłaniają mnie do sugestii, sprawdź czy w BIOS nie masz usypiania zasilania dla USB.
W Dell są chyba wybrane gniazda USB gdzie zasilanie jest włączone na stałe.
