Automatyzacje działają z dużym opóźnieniem

witam wszystkich,
mam HA na raspberry pi4 karta ssd, 16 urządzeń zigbee i cc 2531. W node red ustawiłem sobie kilka scen i tu jest problem, jak przełączam sceny nic się nie dzieje a po kilkunastu sekundach wszystkie sceny zaczynają aktywować sie naraz co powoduje miganie wszystkich zarówek. Czy ktoś spotkał się z takim problemem?
Gdzie leży problem, czy to wina dongla cc2531 czy mozę problem z konfiguracją?

w logach HA nic nie ma, natomiast zigbee 2mqtt wyrzuca takie błęby:

Error Publish 'set' 'brightness' to 'stol2' failed: 'Error: Command 0x588e81fffed49e98/1 genLevelCtrl.moveToLevelWithOnOff({"level":3,"transtime":0}, {"timeout":10000,"disableResponse":false,"disableRecovery":false,"disableDefaultResponse":false,"direction":0,"srcEndpoint":null,"reservedBits":0,"manufacturerCode":null,"transactionSequenceNumber":null,"writeUndiv":false}) failed (Data request failed with error: 'No network route' (205))'

Error Publish 'set' 'color_temp' to 'stol2' failed: 'TypeError: Cannot read property 'manufacturerID' of undefined'

Error Publish 'set' 'color_temp' to 'stol2' failed: 'Error: Command 0x588e81fffed49e98/1 lightingColorCtrl.moveToColorTemp({"colortemp":490,"transtime":0}, {"timeout":10000,"disableResponse":false,"disableRecovery":false,"disableDefaultResponse":false,"direction":0,"srcEndpoint":null,"reservedBits":0,"manufacturerCode":null,"transactionSequenceNumber":null,"writeUndiv":false}) failed (Data request failed with error: 'No network route' (205))'

Error Publish 'set' 'color_temp' to 'stol2' failed: 'Error: Command 0x588e81fffed49e98/1 lightingColorCtrl.moveToColorTemp({"colortemp":490,"transtime":0}, {"timeout":10000,"disableResponse":false,"disableRecovery":false,"disableDefaultResponse":false,"direction":0,"srcEndpoint":null,"reservedBits":0,"manufacturerCode":null,"transactionSequenceNumber":null,"writeUndiv":false}) failed (Data request failed with error: 'No network route' (205))'

Error Publish 'set' 'brightness' to 'stol2' failed: 'Error: Command 0x588e81fffed49e98/1 genLevelCtrl.moveToLevelWithOnOff({"level":60,"transtime":0}, {"timeout":10000,"disableResponse":false,"disableRecovery":false,"disableDefaultResponse":false,"direction":0,"srcEndpoint":null,"reservedBits":0,"manufacturerCode":null,"transactionSequenceNumber":null,"writeUndiv":false}) failed (Data request failed with error: 'No network route' (205))'

Error Publish 'set' 'color_temp' to 'stol2' failed: 'TypeError: Cannot read property 'manufacturerID' of undefined'

Error Publish 'set' 'brightness' to 'stol2' failed: 'Error: Command 0x588e81fffed49e98/1 genLevelCtrl.moveToLevelWithOnOff({"level":60,"transtime":0}, {"timeout":10000,"disableResponse":false,"disableRecovery":false,"disableDefaultResponse":false,"direction":0,"srcEndpoint":null,"reservedBits":0,"manufacturerCode":null,"transactionSequenceNumber":null,"writeUndiv":false}) failed (Data request failed with error: 'No network route' (205))'

Error Publish 'set' 'color_temp' to 'stol2' failed: 'TypeError: Cannot read property 'manufacturerID' of undefined'

CC2531 powinien być wpiety do portu USB 2.0 na kablu z dala od RPi. W logach pojawiają się komunikaty o niedostępności urządzeń Zigbee, sprawdź wartości parametru linkquality w urządzeniach Zigbee.

Jeżeli masz tak duże opóźnienia to sprawdź z jakim obciążeniem działają u ciebie NodeRed i 2mqtt .
Przy zbyt dużym obciążeniu procesora błędy tego typu mogą być czymś normalnym ponieważ dane nie zostały odczytane w żądanym czasie. Może twoja konfiguracja sprzętowa jest zbyt słaba .

Mam RPi3, CC2531 z antenką, 25 urządzeń Zigbee i zero opóźnienien ale masz rację - może coś “zabija” CPU i system ma lagi.

zauważyłem że jak dużo testuje, zmieniam ( wiele razy naciskam deploy) w node red to wtedy najczęściej zaczynają się problemy z opóźnieniami. Nie pomaga restart ani wył/zał. HA. Zależności typu pir załącza swiatło działają bez problemu, jedynie przy scenach gdzie naraz idzie kila komend ( jedna lampa jasniej, druga wyłączona itp.) to wtedy zaczyna się wszystko sypać, najpierw nie ma reakcji a potem kilka scen uruchamia się jedna po drugiej. Dopiero wyłączenie HA i zmiana portu usb dongla przywraca wszystko do normy

z tego co kojarzę restart HA nie restartuje NR. Aby zrestartować NR to w supervisor wyłącz go i włącz.

Zawsze gdy dokonywałem wielu zmian w nodr-edzie i każdorazowo po zmianie używałem deploy zauważałem stopniowy wzrost obciążenie procesora malinki przez nod-reda. Zazwyczaj miało to finalnie wpływ na opóźnienia. Dlatego po takich akcjach ( wiele zmian w node-redzie) restartowałem node-reda tak jak pisał kolega powyżej. Po restarcie natychmiast wszystko wracało do normy.

Cytat CC2531 powinien być wpiety do portu USB 2.0 na kablu z dala od RPi. W logach pojawiają się komunikaty o niedostępności urządzeń Zigbee, sprawdź wartości parametru linkquality w urządzeniach Zigbee.

teraz mam CC2531 na kablu ale niewiele to zmieniło w kwestii opóźnień. Zasięg jest ok, mam kilka urządzeń typu router a odległości nie są duże.

Edit:

CytatJeżeli masz tak duże opóźnienia to sprawdź z jakim obciążeniem działają u ciebie NodeRed i 2mqtt .
Przy zbyt dużym obciążeniu procesora błędy tego typu mogą być czymś normalnym ponieważ dane nie zostały odczytane w żądanym czasie. Może twoja konfiguracja sprzętowa jest zbyt słaba .

sprawdziłem, obciążenie nie jest jakieś duże, ale będę kontrolował

@piopet edytuj Swoje posty - nie pisz jednego pod drugim !

Powiedz jaką masz wersje HA?

Wersja core-2021.7.4

Dzisiaj znowu wszystko się zablokowało, próbowałem najpierw zresetować w supervisor node Red potem mosquito brocker i zigbee 2mqtt.
Żadnych reakcji, pomogło dopiero wyłączenie i włączenie HA. Może to problem z moim CC2531?

Moja propozycja zrób upgrade do najnowszej wersji, ewentualnie do tej z ja ma 2021.9.7.
I od zawsze borykałem się z opóźnieniami. Gdzieś na FB w sierpniu ktoś wrócił by nie instalować wersji 2021.7.x bo ma błąd w kernelu dla cc2652.
I co się okazało że nie tylko da niego był błąd w wersji 2021.8.x jeszcze miałem problemy ale już lepiej chodziło. Od wersji 2021.9.x problem się rozwiązał wszystko śmiga od kopa.

Zrób backup i przetestuj może i tobie pomoże.

Dzięki Marcin za info. właśnie zaktualizowałem do najnowszej wersji. Potestuje trochę, ale myślę że docelowo przejdę na cc2652P. Mocniejszy sprzęt i obsłuży zigbee 3.0
Pozdrawiam

HA nie ma nic do CC2652. HA nie obchodzi co obsługuje, zajmuje się tylko włącz, wyłącz, zmień wartość. Za komunikację i obsługę urządzeń odpowiadają poszczególne integracje i jeśli one maja jakiś bug to występuje problem z urządzeniem. Jeśli miałbyś problem po stronie HA to również z innymi urządzeniami nie zigbee. Problemy jakie ostatnio występowały to w firmware dla CC2652P (20210901) przez bug w SDK. Zauważyłem i nie tylko ja problem ze sterowaniem urządzeń przez zigbee2mqtt w wersji 1.21.1. Zatem wpierw spróbuj zmienić wersje z2m lub firmware dongla.

2 polubienia

po aktualizacji jest znacznie lepiej, czasami przytrafią się lagi ale takie 1-2 sekundowe.
zaktualizowałem HA do wersji 2021.11.03 i z2m do wersji 1.18.1-1

wileu pewnie masz racje, ale jednak CC2652P ma większy zasięg i obsłuży więcej urządzeń z racji mocniejszych podzespołów

Najnowsza wersja Z2M to 1.22.0-2

nie wyświetla mi się nowsza wersja

Na forum znajdziesz informację co trzeba zrobić aby się wyświetlała.

@wileu, dzięki za cynk. Nie wiem czy to w związku z tym konkretnym bugiem, ale mojemu CC2652P (soft egony w wersji 20210901) zdarza się czasem zwiecha. Restart HA, czy nawet całego hosta nie pomaga, muszę wyjąć i włożyć z powrotem dongla USB. Czy jak zrobię downgrade do 20210319, to będę musiał parować na nowo wszystkie urządzenia? Według dokumentacji zigbee2mqtt, zmiana firmware niby nie wymaga ponownego parowania:
https://www.zigbee2mqtt.io/guide/faq/#doesn-t-require-repairing
Czy ktoś z Was to przechodził? Poza tym, nie wiem czy ma to znaczenie, ale używam integracji ZHA.

Wprawdzie z innym koordynatorem (CC2531 na którym psy wszyscy wieszają) nie zauważyłem problemów ze stabilnością integracji ZHA.
Wersji firmware nie zmieniałem (bo nie ma z czego na co), ale skoro autor tak pisze to pewnie tak jest.

Ponowne parowanie jest wymagane gdybyś przechodził ze stacka Zigbee1.2 na Zigbee3 bądź odwrotnie (jeśli jest to w ogóle możliwe na tym koordynatorze).

Właśnie doczytałem, że w przypadku ZHA można dość łatwo zrobić i przywrócić kopię zapasową i nawet zmigrować się na nowego dongla:

Update:
Przed chwilą przeprowadziłem downgrade firmware’u egony 20210901 → 20210319 na moim CC2652P. Wcześniej wykonałem backup według powyższej instrukcji. Przywrócenie danych przebiegło bez problemu, wszystko wstało i się sparowało. Za kilka tygodni dam znać, czy stabilność połączenia się poprawiła :wink:

1 polubienie