Wczoraj zdemontowałem moją bramkę produkcyjną STRYCH, wgrałem do niej wersję z logami i rozpocząłem intensywne testy. Zacytuję tutaj @Krzysztofa - logi trzeba czytać - i to powinno być credo każdego programisty systemów embedded (i nie tylko
).Tak naprawdę mamy tutaj do czynienia ze zbiegiem kilku czynników/błędów, więc po kolei:
- Najbardziej oczywisty błąd wprowadziłem w wersji 1.5.42 w kodzie dedykowanym obsłudze termometru SNZB-02DR2 - w metodzie iterateAlways() dodałem wysłanie wartości T/H w zadanych odcinkach czasu, ale...zapomniałem dodać linię resetującą odmierzany czas po upływie danego interwału, co powodowało, że po 5 minutach moja bramka zaczynała zalewać ten termometr morzem komunikatów, blokując m.in. wysyłanie default response w odpowiedzi na komunikat o temperaturze z termostatu ZWT198, co z kolei powodowało, że ten termostat wysyłał komunikaty w tempie kilku/sekundę.
Powyższy scenariusz wymuszał na bramce takie tempo pracy, że minimalne opóźnienie (Telnet, GUI) mogło doprowadzić do restartu. - Kolejny czynnik to ...same urządzenia ZigBee. Wczoraj wróciłem do logów @zzrr, ale spojrzałem na nie pod innym kątem, a mianowicie przyjrzałem się znacznikom czasowym. Wiadomości z tej czujki PIR lecą z prędkością karabinu maszynowego, co może dawać objawy podobne do pkt. 1.
- Kolejny drobiazg, to zmiana w kodzie obsługi komunikatów TUYA_SYNC_TIME, którą wprowadziłem walcząc z termometrem kolegi @Jaroni, a które dla odmiany nie do końca współgrały np. z termostatami ściennymi Tuya.
@zzrr Prośba do Ciebie o logi z bramki z tą czujką PIR w wersji 1 5.64.
Od tego momentu wznawiam pracę nad dalszym rozwojem bramki, równolegle pracując nad kwestią usprawnienia krytycznych elementów kodu.
