Czołem. Od dwóch dni mam problem z ZigBee2Mqtt na DEV3 (najnowsza Ola beta) z Conbee II. Zaczęło się od tego, że czujnik ruchu (Aquara) nie zadziałał – zdarza się – pomyślałem. Następnie sensor otwarcia drzwi (Aquara) po wykryciu ich otwarcia już nie zauważył zamknięcia – a to już się raczej nie zdarza. A potem już było coraz gorzej: przyciski (zarówno fizycznie jak w kartach) działają co któryś raz, a jak już zadzialałają to często nie raportują stanu. Niestety nie jestem w stanie zaobserwować jakiejkolwiek reguły – tak jakby losowe urządzenia w losowym czasie traciły połączenie z bramką, by po chwili je odzyskać.
Próbowałem restartować bramkę, fizycznie wyłączać ją z prądu, odłączać i podłączać Conbee, oczywiście przywracać kopię z portalu integratora… W logach niczego nie potrafię wypatrzeć oprócz typowego w takich przypadkach błędu:
Error 2023-03-11 20:07:29 Publish 'set' 'state' to 'Plug C' failed: 'Error: Command 0xa4c138023571018a/1 genOnOff.on({}, {"sendWhen":"immediate","timeout":10000,"disableResponse":false,"disableRecovery":false,"disableDefaultResponse":false,"direction":0,"srcEndpoint":null,"reservedBits":0,"manufacturerCode":null,"transactionSequenceNumber":null,"writeUndiv":false}) failed (no response received)'
Spróbuję jutro podmienić Conbee na inny egzemplarz, choć ponoć one się nie psują. Poradzcie proszę, co mogę jeszcze sprawdzić/zrobić?
Edit: wygląda to może tak, jakby jakaś magistrala danych się zatykała. I tak np.: pierwsze w ciągu dnia wykrycie ruchu włącza pierwszą lampkę, drugi czujnik włącza drugą, ale już nie raportuje tego w Lovelace, a kolejny czujnik ruchu już nic nie zauważa. Podobnie przy odłączeniu Conbee i ponownym podłączeniu (zgodnie z zaleceniami na przedłużaczu) – przez chwilę wszystko zdaje się działać prawidłowo, ale tylko przez chwilę
U mnie to samo się dzieje. Znikają czujniki, a za chwilę się pojawiają. Bywa,że trzeba ponownie parować. Dzieje się tak na bramkach z termux. Mam jedną bramkę ze starszym softem i tu działa wszystko jak należy. W czym jest problem?
Nie wiem czy Wam to cokolwiek podpowie, ale opisane objawy są łudząco podobne do sytuacji w której “zwyczajny” HA pracuje przy braku zasobów maszyny - Z2M się wtedy wysypuje w identyczny sposób, może więc coś zwalone w aktualizacji prowadzi np. do wycieku pamięci i po prostu RAM się kończy?
Z bramkami AIS nie mam żadnego doświadczenia, ale zasoby sprzętowe są w nich skończone i niewielkie, więc warto się temu przyjrzeć.
Zapewne htop (lub top jeśli nie ma htop) coś tam pokaże jak wygląda zajętość zasobów.
Na pecetach ludzie czasem dokładali RAM (gdy powodem jego braku była “rozbuchana” konfiguracja - im nowsza wersja HA tym bardziej zasobożerna), ale w przypadku permanentnego wycieku pamięci dokładanie RAMu oczywiście nie pomaga (widziałem za to wiele razy realizowanie takiej protezy jak restart systemu co jakiś czas i to w pewnym stopniu pomaga na objawy bez usuwania źródła problemu).
Z tą pamięcią może być coś na rzeczy…
U mnie co jakiś czas zapełnia się 256M swapu, pomimo że normalnego RAMu zżera 1,4G z 3,7G dostępnego. No i zaczyna się HA krztusić
Node Red świruje, bo nagle wyczerpują się sockety http i teraz go raz dziennie restartuję, żeby działał z HA. Do tego co kilka dni restart bramki HA, bo reakcja na sterowanie czasek trwa kilka(naście) sekund.
A przecież bramka PRO1 nie jest słaba, jeśli chodzi o zasoby.
Mam bridge do MQTT Supli, jak mi zaczynają urządzenia zigbee stawać się niedostępne, to muszę usunąć bridge do Supli, zrestartować MQTT, zrestartować Zigbee2MQTT, zrestartować AIS, potem dodać bridge do Supli i zrestartować MQTT. I przez kilka dni to chodzi.
Nie znalazłem sposobu jak zwiększyć swap ani też jak go bez fizycznego restartu opróżniać.
Dlatego co jakiś czas wymagany jest fizyczny restart bramki. Aby nie mieć problemów z PostgreSQL muszę go wyłączyć przez reboot, bo potem nie chce wstać razem z bramką, gdyż reboot nie usuwa pidów i locków.
No i taka jest jazda bez trzymanki…
Dzięki za sugestię. Bramka sprawiająca problemy obsługuje raptem kilkanaście prostych urządzeń ZigBee, a jedyna integracja – poza fabrycznie zainstalowanymi – dotyczy telewizora Sony, więc zasobów chyba aż nadmiar Chyba, że faktycznie jakiś wyciek, czy swap się zapchał lub inne temporary… Ale czy w takim przypadku restart poprzez fizyczne odłączenie zasilania nie powinien pomóc? Prawda, że coś mogło pójść nie tak przy aktualizacji. Moja druga bramka DEV3 – znacznie bardziej obciążona urządzeniami ZigBee (około 50) – w takiej samej konfiguracji pracuje bezproblemowo (odpukać!!!).
Obawiam się, że po ewentualnym przywróceniu bramki do stanu fabrycznego (bo już nie mam innego pomysłu poza odesłaniem do serwisu na gwarancji) nie poradzę sobie z odtworzeniem kopi konfiguracji.
Jeszcze raz dzięki za pochylenie się nad problemem.
Jak mówiłem nie mam pojęcia o bramkach AIS, ale w głowie mi się nie mieści, że nie ma opcji normalnego restartu systemu, skoro piszesz o odcinaniu zasilania…
(w starych wersjach HA była to funkcja pod nazwą reboot host, swoją drogą sądzę, że jaki by nie był system, to z konsoli da się wykonać jakieś polecenie w guście reboot), a jak sądzę masz to gdzieś w GUI
Może ujmę to tak - moja testowa instalacja HA (HAOS-generic) była swego czasu na sprzęcie z 2GB RAM, ale mimo, że dostanie się do płyty głównej w monitorze (bo to monitor z wbudowanym TC) to był hardkor, to jednak w końcu wsadziłem tam 4GB (było nie było używam Dodatków w HA i to one wymagają nieco więcej pamięci).
@Goral64 Jak dla mnie dziwne, że system się wywraca z powodu zapełnienia swapa skoro nie jest wykorzystany równocześnie cały RAM.
Aktualizacja Oli na kanale Alfa nic nie dała. Dodatkowo monitorowałem bramkę przez dobę i choć pamięć pomalutku się zapełnia, to jej użycie nie przekroczyło 37% (1,5 GB), obciążenie procesora jest z grubsza na stałym poziomie 11% a temperatura 52°C. Swap w ogóle nie był używany, tak więc to chyba nie kwestia zasobów.
Co jeszcze mogę zrobić, by przywrócić bramkę do stanu używalności?!
Ja mam to samo. Myślałem że może to wynik ilości urządzeń - ponad 70 na conbee II. Ale tak jak piszecie to pokazuje mi to że to nie tylko u mnie.
Jestem na wersji Ola Beta.
Ciekawi mnie też dlaczego nowo kupiona bramka na wersję zigbee 1.30.2 z HA 2023.3.1 na tym samym kanale a aktualizacja daje tylko 1.30.0 z HA 2023.2.5.
Być może to wynika że robiłem pełen restart na nowej i zaciąga nowsza jeszcze wersję.
W release notes ma wiele wpisów ta wersja wiec może ona naprawia ta kwestie. Spróbuję dzisiaj zrobić restart i odtworzenie z backup. Zobaczę która wersja będzie i czy będzie lepiej.
Czołem! No właśnie – jak bezpiecznie wykonać reset, by nie stracić Termuxa i nie zmieniło się id bramki? Bo chyba tylko w takim przypadku można przywrócić backup z Portalu Integratora (?).
Świeżo zrobiona aktualizacja na kanale Alfa przynosi ZigBee 1.30.2 oraz AIS HA 2023.3.4.
W sumie to nie założyłem że będzie trzeba cały termux instalować raz jeszcze.
Finalnie zrobiłem zmianę na alfa i upgrade do 1.30.2 oraz zrobiłem upgrade firmware ConBee2 to wersji z maja 2022 - wersja 0x26780700 - http://deconz.dresden-elektronik.de/deconz-firmware/deCONZ_ConBeeII_0x26780700.bin.GCF)
Niestety ale dalej mam to samo, czyli niektóre wyłaczniki wogóle nie działają. Zastanawiam się czy oby napewno to jest ten sam problem o którym pisał @Ciutnik.
U mnie objaw jest taki że dla pewnych wyłaczników co jakiś czas da się niektóre przestawiać, ale w większości nie działają - tak jakby nie było z nimi połączenia zigbee.
Tak, podobnie obserwuję u siebie. Encje niby są dostępne ale po prostu nie działają. I tak, np. dla zestawu wlacznik + światło: czasem włącznika nie da się przestawić i nic się nie dzieje, czasem się nie przestawi ale światło się zapali, czasem się przestawi a światło nie zaświeci, a czasem wszystko jest OK – czyli wszystkie możliwe kombinacje. Wynika z tego, co czwarta próba kończy się sukcesem
Jak już zacytowałem log, typowym jest no response received.
Może zakłócenia w paśmie 2.4GHz kanały ZigBee od 11 do 26 na tym paśmie pracują nakładają się na sieć WiFi. Może warto zmienić kanał w konfiguracji Conbee2 (chyba ponownie trzeba parować)
Chyba wyższy, bo Zigbee ma ogółem 27 kanałów na 3 pasmach:
kanał 0 - 868MHz (Europa), 20kbps
kanały 1-10 - 902-928MHz (USA), 40kbps
kanały 11-26: 2.4-2,4835GHz, 250kbps
i zasadniczo używa się kanałów od 11 w górę.
Ja dzisiaj trochę posprawdzalem bo generalnie po aktualizacji zigbee, conbee i HA do najnowszych wersji bez jakichkolwiek zmian. Zacząłem włączać te urządzenia które mają największy problem w stan dołączania. Od razu się dołączały do tego samego urządzenia które były. Niby nic ale… zaczęły poprawnie działać. I wniosek mój dalszy taki że przestały one być ruterami wcześniej więc i sieć zaczęła być mniej rozpropagowana (3 kondygnacje). Teraz zaczyna wszystko śmigać bo zmienił się pewnie ruting tras. Wydaje mi się że być może nie trzeba wchodzić w tryb dołączania na przekaźniku tylko wyłączyć prąd (ale nie na AIS) i po włączeniu wejść w dołączanie na AIS. Powinien znaleźć. Dzisiaj nie będę tego już próbować żeby nie pobudzić rodziny przypadkowym włączeniem światła
Racja! Czyli zgodnie z powyższym diagramem, jeżeli WiFi Analyzer pokazuje mi kanały WiFi 10–14 jako najmniej używane w mojej lokalizacji, kanał ZigBee 25 może być stosunkowo najlepszy?
Właściwie to ze względów kompatybilności z tej całej “palety” kanałów od 11 do 26 jako użytkowe można uznać tylko cztery: 11, 15, 20 i 25 (bo tylko one są obsługiwane przez wszystko, łącznie z osprzętem ZGP i celowo są wybrane te kanały, które mają stosunkowo najmniejsze kolizje z pokrywającymi się z nimi kanałami WiFi - tu też jest dość optymistyczne założenie, że ludzie będą korzystać z optymalnych kanałów WiFi w paśmie 2,4GHz tj. 1, 6 lub 11 i tylko te uwzględniono na rysunku powyżej).
PS Numeracje kanałów dla WiFi nie ma nic wspólnego z numeracją dla Zigbee.
(to samo pasmo jest podzielone na kilka różnych sposobów w zależności od tego jaka technologia je wykorzystuje)
PPS W tym pasmie jest sporo zaszłości historycznych, jakkolwiek robiłem testy w mało przyjaznym środowisku (blokowisko, gdzie mój sprzęt “słyszy” dziesiątki sieci WiFi sąsiadów) i… wniosek jest taki - jeśli nie mamy lokalnych źródeł silnych zakłóceń (np. ściemniacze świateł ulokowane bezpośrednio przy sprzęcie Zigbee) to sieć Zigbee pracuje dobrze na dowolnym z tych kanałów pod warunkiem posiadania dostatecznej liczy routerów.
W trakcie tych testów miałem uruchomione kilka własnych oddzielnych sieci Zigbee (oczywiście każda na innym zalecanym kanale - niektóre zamknięte systemy wręcz nie umożliwiają ręcznego wyboru i pracują już na jednym z zalecanych a niektóre mają na liście wyboru tylko zalecane).
W ramach ciekawostek Z2M we współczesnych wersjach (nie wiem od kiedy ma takie możliwości) aktywnie odmawia uruchomienia koordynatora jeśli usłyszy w okolicy na tym samym kanale inną sieć Zigbee stosującą te same klucze (więc pracy na defaultowych kluczach nie polecam).
Chyba, że faktycznie jakiś wyciek, czy swap się zapchał lub inne temporary… Ale czy w takim przypadku restart poprzez fizyczne odłączenie zasilania nie powinien pomóc? Prawda, że coś mogło pójść nie tak przy aktualizacji. Moja druga bramka DEV3 – znacznie bardziej obciążona urządzeniami ZigBee (około 50) – w takiej samej konfiguracji pracuje bezproblemowo (odpukać!!!).
