Urządzenie IoT traci połączenie: przyczyny i szybka diagnoza

Urządzenie IoT traci połączenie to jeden z częściej spotykanych problemów w systemach automatyki i monitoringu – pozornie prosta usterka, która w rzeczywistości może mieć kilkanaście różnych przyczyn rozłożonych na różnych warstwach sieci. Samo komunikat „offline” nie mówi nic o tym, gdzie dokładnie doszło do zerwania. Ten artykuł pomoże Ci przejść przez diagnozę krok po kroku i skutecznie wyeliminować przyczynę.

Najważniejsze informacje z tego artykułu:

• Utrata połączenia w urządzeniach IoT może wystąpić na różnych warstwach – od radia, przez IP i TCP, aż po sesję MQTT lub błąd TLS.
• Dobry sygnał Wi-Fi lub rejestracja w sieci komórkowej nie gwarantują działającego połączenia na poziomie aplikacji.
• Tryby oszczędzania energii, takie jak PSM i eDRX w sieciach LTE-M/NB-IoT, mogą powodować, że urządzenie jest formalnie zarejestrowane, ale niedostępne dla komunikacji przychodzącej.
• Błędy TLS, wygasłe certyfikaty i nieprawidłowy zegar systemowy urządzenia mogą wyglądać jak losowe zrywanie połączenia.
• Skuteczna diagnostyka wymaga rozdzielenia stanu warstwy radiowej, adresacji IP oraz sesji aplikacyjnej i logowania każdej z nich osobno.

Dlaczego urządzenie IoT traci połączenie – od czego zacząć diagnozę?

Pierwsza i najważniejsza zasada: komunikat „urządzenie offline” nie wskazuje miejsca awarii. Zanim zaczniesz cokolwiek restartować, musisz ustalić, na której warstwie doszło do zerwania. To decyduje o tym, gdzie szukać przyczyny i jak ją usunąć.

Wyróżniam osiem warstw, na których może dojść do rozłączenia:

• Warstwa radiowa lub fizyczna – urządzenie utraciło dostęp do medium transmisyjnego (Wi-Fi, LTE, Zigbee).
• Warstwa IP i routingu – brak adresu IP, błędna brama lub niedostępny DNS.
• Wygaśnięcie stanu NAT lub firewalla – router lub firewall usunął wpis sesji podczas bezczynności.
• Zerwanie sesji TCP – połączenie transportowe zostało przerwane lub wpadło w stan half-open.
• Nieudany handshake TLS – błąd negocjacji szyfrowania, często z powodu złego czasu lub wygasłego certyfikatu.
• Odrzucenie uwierzytelnienia – błędne dane logowania, wygasły token lub certyfikat klienta.
• Rozłączenie na poziomie MQTT lub CoAP – przekroczony Keep Alive, błędny client ID lub limit brokera.
• Zawieszenie procesu aplikacyjnego – interfejs sieciowy działa, ale pętla obsługi zdarzeń stoi w miejscu.

Statystyki z raportu rSIM pokazują skalę problemu: 97% badanych firm doświadcza jakiejś formy utraty łączności co miesiąc, a 43% zgłasza przynajmniej jeden taki incydent tygodniowo. Ponad połowa przedsiębiorstw deklaruje problemy z łącznością urządzeń IoT wpływające na procesy krytyczne – w tym terminale płatnicze i zdalne monitorowanie pacjentów. Szacuje się, że 83% wszystkich połączeń IoT ma charakter mission-critical, business-critical lub life-critical, mimo że realna dostępność często jest istotnie niższa niż nominalne SLA. Przy SLA na poziomie 99% oznacza to realnie nawet 7 godzin i 15 minut przestoju miesięcznie.

Dlatego diagnozę zawsze zaczynam od ustalenia, na której warstwie doszło do awarii – i dopiero wtedy przechodzę do naprawy.

Jak sprawdzić, na której warstwie doszło do zerwania połączenia?

Poniższa kolejność kroków pozwala systematycznie izolować przyczynę bez strzelania na oślep:

1. Sprawdź, czy urządzenie działa i wykonuje pętlę aplikacyjną – czy diody LED reagują, czy logi lokalne się aktualizują, czy watchdog nie wywołał restartu.
2. Sprawdź stan radia lub modemu – w Wi-Fi: czy urządzenie jest skojarzone z AP i ma adres IP. W LTE: czy modem jest zarejestrowany w sieci i czy ma aktywny kontekst danych (PDP/PDN).
3. Zweryfikuj adres IP, bramę i DNS – sprawdź, czy urządzenie dostało poprawny adres od DHCP i czy rozwiązuje nazwy domenowe. Wiele awarii zaczyna się właśnie tutaj.
4. Przetestuj TCP – spróbuj nawiązać połączenie TCP z endpointem chmurowym. Jeżeli to się uda, sprawdź TLS.
5. Sprawdź handshake TLS – zweryfikuj, czy urządzenie ma aktualny czas, ważny certyfikat klienta i kompletny łańcuch CA.
6. Sprawdź stan sesji MQTT – czy broker widzi urządzenie jako połączone, czy ostatni CONNACK był poprawny, jaki jest reason code rozłączenia.
7. Porównaj czas awarii z logami – sprawdź, czy awaria zbiegła się z odnowieniem DHCP, zmianą komórki, aktualizacją firmware routera lub wygaśnięciem tokenu.

Wskazówka: Jeśli broker MQTT twierdzi, że klient jest aktywny, a urządzenie nie odbiera danych, podejrzewaj stan half-open TCP, wygasły wpis NAT lub zawieszoną pętlę aplikacyjną – a nie problem z radiem.

Jeżeli urządzenie wraca po restarcie, ale nie wraca po samym reconnect, przyczyną są najprawdopodobniej wycieki zasobów, niewyczyszczony socket lub zablokowany automat stanów.

Jak NAT i firewall mogą zrywać połączenie bez żadnego ostrzeżenia?

To jeden z najczęściej pomijanych mechanizmów. TCP nie wysyła żadnych pakietów podczas bezczynności – jedna strona może więc trwać w stanie ESTABLISHED, mimo że router dawno usunął wpis NAT i odpowiedzi z chmury przestają wracać. Jest to tzw. stan half-open opisany w specyfikacji RFC 9293.

Sytuacje, w których dochodzi do tego problemu:

• restart routera lub modemu,
• zmiana komórki w sieci LTE,
• rekonfiguracja firewalla,
• przejście między punktami dostępowymi Wi-Fi,
• długa bezczynność urządzenia, np. czujnik wysyłający dane co 30 minut przy timeoucie NAT wynoszącym 20 minut.

Jeśli urządzenie wysyła dane rzadziej niż wynosi timeout NAT w routerze lub sieci operatora, odpowiedzi z chmury przestają docierać mimo pozornie aktywnego połączenia. Typowe timeouty NAT dla TCP to od kilku do kilkunastu minut, zależnie od producenta i konfiguracji.

Rozwiązanie polega na ustawieniu interwału aktywności krótszego niż timeout NAT. Należy tu rozróżnić dwa mechanizmy – TCP keepalive i heartbeat aplikacyjny – bo to nie jest to samo:

Samo TCP keepalive nie wystarczy w środowisku z NAT, bo niektóre routery ignorują pakiety keepalive albo mają osobny timeout dla połączeń uśpionych. Heartbeat aplikacyjny potwierdza działanie całego stosu, od TCP po brokera.

Co może zrywać połączenie w sieci Wi-Fi poza słabym sygnałem?

Dobry RSSI nie gwarantuje stabilnego połączenia. Poziom sygnału to tylko jeden z wielu czynników, a w praktyce rzadko jest bezpośrednią przyczyną rozłączeń w urządzeniach IoT działających w pobliżu routera.

Częstsze przyczyny po stronie Wi-Fi:

• Interferencja na kanale – zasilacze impulsowe, mikrofalówki, kamery bezprzewodowe, sąsiednie sieci Zigbee na nakładających się kanałach. Rozłączenia pojawiające się wieczorami to klasyczny objaw tej przyczyny.
• Band steering – router wymusza przełączanie między 2,4 GHz a 5 GHz; moduły IoT obsługujące tylko 2,4 GHz mogą reagować na to rozłączeniem zamiast prostą odmową.
• Tryb power save i DTIM – punkt dostępowy buforuje dane i informuje urządzenie przez beacon z flagą TIM/DTIM. Zbyt długi okres DTIM zwiększa latencję i może kolidować z timeoutami aplikacyjnymi.
• Sticky client – moduł Wi-Fi utrzymuje połączenie z słabym AP, bo nie obsługuje 802.11r/k/v i nie przechodzi samodzielnie do silniejszego punktu dostępowego.
• Aktualizacja klucza grupowego podczas snu urządzenia – urządzenie budzące się ze zbyt długiego uśpienia może nie mieć aktualnego klucza i zostać rozłączone.
• Aktualizacja firmware routera – może zmienić domyślne ustawienia WPA, PMF/802.11w lub szerokości kanału; starsze moduły IoT zamiast całkowicie odmówić połączenia, zaczną działać niestabilnie.

Przydatne narzędzie diagnostyczne to przechwytywanie ramek zarządzających 802.11 – ramki disassociation i deauthentication zawierają reason code. Reason code 4 oznacza rozłączenie z powodu bezczynności, reason code 5 – brak zasobów po stronie AP. Analiza reason code pozwala ustalić, czy rozłączenie zainicjował AP, klient, czy środowisko radiowe.

Badania nad niezawodnością sieci przemysłowych IoT pokazują, jak bardzo interferencja radiowa wpływa na stabilność: przy prostym sekwencyjnym skakaniu po kanałach aż 33,5% łączy charakteryzowało się 50-procentowym wskaźnikiem niepowodzenia retransmisji. Po zwiększeniu odstępu między kanałami do 5 odsetek ten spadł do 13,5%.

Wskazówka: Jeśli urządzenie traci połączenie głównie wieczorami lub w określonych porach dnia, sprawdź najpierw interferencję i obciążenie kanału, a nie siłę sygnału.

Jak tryb uśpienia i oszczędzanie energii wpływają na utratę połączenia?

Zbyt agresywne oszczędzanie energii to jedna z bardziej podstępnych przyczyn rozłączeń, bo efekt wygląda jak losowa utrata internetu, choć mechanizm jest zupełnie inny.

W sieciach LTE-M i NB-IoT funkcjonują dwa główne tryby:

• PSM (Power Saving Mode) – wyłącza odbiornik na uzgodniony czas. Urządzenie jest formalnie zarejestrowane w sieci, ale przez cały czas PSM jest nieosiągalne dla ruchu przychodzącego.
• eDRX (Extended Discontinuous Reception) – pozostawia krótkie okna nasłuchu, ale wiadomości downlink mogą być buforowane lub odrzucane przez operatora.

Jeśli jednocześnie używasz PSM i eDRX, Active Timer T3324 musi obejmować odpowiednią liczbę cykli eDRX – inaczej urządzenie może wejść w PSM, zanim serwer zdąży dostarczyć dane.

Typowy błąd architektoniczny polega na utrzymywaniu długiego MQTT Keep Alive na urządzeniu regularnie przechodzącym w PSM. Takiej sesji nie wolno traktować jak ciągłego połączenia. Poprawny model dla urządzeń z PSM wygląda następująco:

1. Wybudź urządzenie zgodnie z harmonogramem.
2. Zarejestruj się w sieci i sprawdź dostępność.
3. Wyślij bufor telemetrii.
4. Odbierz ograniczoną kolejkę poleceń.
5. Jawnie zamknij sesję lub wróć do trybu oszczędzania energii.

Moduł radiowy może też przejść w głęboki stan uśpienia szybciej, niż stos TCP lub MQTT skończy retransmisję lub potwierdzenie QoS. Efektem są pozornie losowe rozłączenia, które bardzo trudno powiązać z trybem energetycznym bez szczegółowego logowania.

Osobnym problemem są krótkie spadki napięcia zasilania. Mogą one resetować sam moduł komunikacyjny bez resetowania mikrokontrolera – efekt wygląda identycznie jak utrata internetu, choć przyczyną jest niestabilne zasilanie, szczególnie podczas pików nadawania radiowego.

Jak ustawienia DHCP, DNS i TLS mogą powodować zrywanie połączenia?

Cykliczne rozłączenia pojawiające się co kilka lub 24 godziny to klasyczny objaw problemów z DHCP. Jeśli urządzenie niepoprawnie obsługuje odnowienie lease’u, może utracić bramę lub DNS bez zauważalnej zmiany adresu IP. Warto sprawdzić, czy awaria zbiegła się z momentem odnowienia dzierżawy DHCP.

DNS to kolejny obszar, który łatwo pomylić z awarią połączenia. Typy błędów DNS, które mogą wyglądać jak utrata internetu:

• brak odpowiedzi serwera DNS,
• błąd NXDOMAIN (nieistniejąca domena),
• timeout zapytania,
• odpowiedź z prywatnego DNS operatora zamiast publicznego,
• niezgodność IPv4 i IPv6,
• błędnie zakeszowana odpowiedź.

Urządzenie powinno używać co najmniej dwóch resolverów i nigdy nie powinno mieć zakodowanego na stałe adresu IP usługi chmurowej – utrudnia to rotację endpointów i może łamać weryfikację SNI w TLS.

TLS potrafi wyglądać jak losowe rozłączenia, bo błąd handshake pojawia się przed nawiązaniem sesji MQTT i urządzenie raportuje jedynie „connection failed”. Lista przyczyn:

• nieprawidłowy zegar urządzenia (certyfikat serwera odrzucony jako nieważny lub wygasły),
• brak synchronizacji NTP po restarcie lub utracie zasilania RTC,
• wygasły certyfikat klienta,
• brak aktualnego łańcucha CA,
• niezgodność SNI z nazwą hosta endpointu,
• brak wspólnego cipher suite lub nieobsługiwana wersja TLS,
• problem z MTU – małe pakiety przechodzą, a duże ramki handshake TLS są odrzucane przy wyłączonym Path MTU Discovery.

Odnowienie tokenów czasowych (SAS, OAuth) powinno następować z marginesem kilku minut, a nie w chwili wygaśnięcia.

Jak konfiguracja MQTT wpływa na stabilność połączenia?

MQTT uznaje klienta za nieaktywnego, jeśli w czasie 1,5-krotności zadeklarowanego Keep Alive nie otrzyma od niego żadnego pakietu. Pakietem podtrzymującym może być PUBLISH, SUBSCRIBE, PUBACK lub PINGREQ – broker odpowiada na PINGREQ komunikatem PINGRESP.

Dobór wartości Keep Alive to kompromis:

Wybór poziomu QoS powinien wynikać z semantyki danych:

• QoS 0 – dla danych cyklicznych, które można zastąpić kolejnym pomiarem, np. odczyty temperatury.
• QoS 1 – wymaga deduplikacji po stronie odbiorcy, bo dostarczenie „co najmniej raz” może skutkować powtórzeniem tej samej wiadomości.
• QoS 2 – ogranicza duplikaty, ale zwiększa liczbę kroków protokołu i zużycie zasobów.

Dane sterujące (komendy do urządzenia) powinny mieć identyfikator polecenia, czas wygaśnięcia i mechanizm potwierdzenia wykonania – sam QoS 1 nie wystarczy.

MQTT 5 rozdziela parametry Clean Start i Session Expiry Interval, co pozwala precyzyjnie określić, jak długo broker ma przechowywać sesję po rozłączeniu. W MQTT 3.1.1 sesja trwała może pozostać na brokerze bezterminowo, bo protokół nie definiuje standardowego czasu wygaśnięcia. Kolejka offline powinna mieć określony limit rozmiaru i politykę odrzucania – bez tego urządzenie może zużyć całą dostępną pamięć po dłuższej niedostępności.

Warto też pamiętać, że Last Will and Testament nie daje natychmiastowej informacji o awarii zasilania. Broker publikuje Will dopiero po przekroczeniu timeoutu Keep Alive – mogą upłynąć minuty, zanim inne urządzenia dowiedzą się o rozłączeniu.

Wskazówka: Jeśli widzisz, że broker zgłasza rozłączenie z reason code wskazującym na duplikat client ID, sprawdź natychmiast, czy ta sama instancja klienta nie jest uruchomiona równolegle na innym urządzeniu lub w innym procesie.

Jak błędy firmware powodują utratę połączenia IoT?

Urządzenie może mieć aktywny interfejs sieciowy i nadal być niezdolne do komunikacji, jeśli problem tkwi w oprogramowaniu. To jeden z trudniejszych do zdiagnozowania obszarów, bo objawy wyglądają jak problem sieciowy.

Najczęstsze błędy firmware prowadzące do utraty połączenia:

• Wyciek pamięci po wielokrotnym reconnect – każde nieudane połączenie zostawia nieuwolnione zasoby, a po kilkunastu cyklach urządzenie przestaje działać.
• Wyczerpanie deskryptorów socketów – wiele modułów IoT ma ograniczoną liczbę gniazd; jeśli aplikacja nie zamyka poprawnie połączeń po rozłączeniu, szybko osiąga limit.
• Niepoprawne czyszczenie starego socketu – ponowne połączenie MQTT bez zamknięcia starego TLS/socketu prowadzi do wycieków zasobów i ostatecznie do trwałego offline.
• Zakleszczenie mutexu między modemem a MQTT – oba zadania blokują się nawzajem, pętla aplikacyjna stoi, a watchdog resetuje modem bez resetowania stosu TCP.
• Błędna obsługa URC (Unsolicited Result Code) z modemu – nieobsłużone zdarzenia modemu blokują komunikację bez widocznego błędu.

Poprawna implementacja powinna mieć jednoznaczny automat stanów:

POWERED → REGISTERING → PDP_ACTIVE → DNS_READY → TCP_CONNECTED → TLS_ESTABLISHED → MQTT_CONNECTED → ONLINE

Każde przejście musi mieć timeout, a każda ścieżka błędu powinna zamykać zasoby wszystkich niższych warstw. Reconnect bez prawidłowego zamknięcia poprzedniej sesji to przepis na stopniową degradację, która objawia się po godzinach lub dniach pracy.

Jak powinien działać mechanizm ponownego łączenia?

Prosta nieskończona pętla reconnect to jeden z częstszych błędów projektowych. Gdy chmura lub sieć ma przejściową awarię, tysiące urządzeń próbujących się połączyć natychmiast i jednocześnie mogą wywołać efekt thundering herd – lawinę żądań, która przeciąży broker i sieci, przedłużając awarię.

Poprawna strategia to wykładniczy backoff z losowym jitterem:

• Zacznij od krótkiego interwału, np. 1–2 sekund.
• Po każdej nieudanej próbie podwój czas oczekiwania.
• Wprowadź górny limit, np. 5–15 minut.
• Dodaj losowy składnik niezależny dla każdego urządzenia, żeby uniknąć synchronizacji floty.

Strategia powinna rozróżniać rodzaj błędu, bo inaczej obsługuje się każdy z nich:

• Błąd radiowy – odczekaj i ponów rejestrację w sieci.
• Timeout TCP – zamknij socket, odtwórz kontekst PDP.
• Błąd TLS – ponów dopiero po weryfikacji czasu, łańcucha CA i certyfikatu.
• Odmowa uwierzytelnienia – nie próbuj agresywnie od nowa; wygeneruj alarm operatorski.
• DUPLICATE_CLIENTID – sprawdź, czy nie działa równoległe wystąpienie klienta.
• Wielokrotne awarie z rzędu – wykonaj kontrolowany restart modemu lub całego urządzenia.

Według raportu Eseye tylko 1–2% firm osiąga dostępność floty powyżej 98%, a 34% organizacji wskazuje słabą łączność IoT jako barierę dla wdrożeń AI. Dobra strategia reconnect to jeden z elementów, który realnie przekłada się na statystyki dostępności.

Jak analizować logi i mierzyć jakość połączenia?

Skuteczna diagnoza wymaga logowania właściwych danych. Samo RSSI lub liczba kresek sygnału nie wystarczy – badania potwierdzają, że analiza wyłącznie RSSI i LQI nie pozwala wiarygodnie ocenić niezawodności łącza. Konieczne jest uwzględnianie interwałów między pakietami i liczby utraconych pakietów.

W sieci LTE zamiast RSSI używaj:

Stabilny RSRP przy pogarszającym się RSRQ lub SINR wskazuje na interferencję lub przeciążenie komórki, a nie na brak zasięgu. Właśnie ta różnica często decyduje o tym, czy szukasz problemu po stronie radia, czy po stronie sieci operatora.

Co zapisywać przy każdej sesji na urządzeniu:

• czas UTC i monotoniczny, powód ostatniego rozłączenia,
• stan modemu i adres IP,
• czas TCP SYN–SYN/ACK i czas handshake TLS,
• wersję TLS i kod błędu,
• MQTT CONNACK/DISCONNECT reason code,
• Keep Alive, czas ostatniego PINGREQ/PINGRESP,
• liczbę prób reconnect i długość kolejki offline,
• reset reason i stan pamięci.

Po stronie serwera warto monitorować: timestamp CONNECT/DISCONNECT, reason code, liczbę równoległych sesji z tym samym client ID, odsetek duplikatów QoS 1 i liczbę wygasłych wiadomości. AWS IoT udostępnia reason code rozróżniający rozłączenie zainicjowane przez klienta, serwer i sieć – to znacznie skraca czas lokalizacji problemu.

Ważna zależność: jeśli spadek SINR poprzedza wzrost retransmisji i timeoutów, problem leży w warstwie radiowej. Jeżeli parametry radiowe są stabilne, a zmienia się tylko adres IP lub pojawia się RST, badaj NAT, routing albo konfigurację operatora.

Badanie eksperymentalne z wykorzystaniem MQTT i HTTPS wykazało średnią niezawodność dostarczania danych na poziomie 98,3% i średnie opóźnienie end-to-end wynoszące 180 ms. Utrata pakietów koncentrowała się w epizodach chwilowego pogorszenia łącza, a nie była równomiernie rozłożona w czasie – to potwierdza, że diagnostyka powinna szukać zdarzeń korelujących z momentem awarii, a nie oceniać średnią jakość łącza.

Jak zapobiegać ponownemu zrywaniu połączenia?

Niezawodność w IoT nie polega na utrzymaniu jednej sesji przez cały czas. Zakładaj, że połączenie będzie okresowo tracone i projektuj system tak, żeby poprawnie to obsługiwał.

Checklista działań zapobiegawczych:

• Ustaw interwał heartbeat lub Keep Alive krótszy niż timeout NAT w routerze lub sieci operatora.
• Używaj statycznego IP lub rezerwacji DHCP dla urządzeń IoT, żeby uniknąć problemów przy odnowieniu lease’u.
• Włącz synchronizację NTP przed pierwszą próbą połączenia TLS, szczególnie po restarcie lub długim przechowywaniu urządzenia.
• Monitoruj daty ważności certyfikatów i tokenów – odnawiaj je z marginesem co najmniej kilku minut.
• Wyłącz band steering dla sieci IoT lub użyj osobnego SSID tylko na 2,4 GHz.
• Zablokuj agresywne zarządzanie zasilaniem radia w routerze dla sieci IoT.
• Zadbaj o filtrowanie zakłóceń zasilania – kondensatory buforujące lub UPS dla urządzeń wrażliwych.
• Stosuj wykładniczy backoff z jitterem w każdym mechanizmie reconnect.
• Loguj powód każdego rozłączenia po stronie urządzenia i brokera.
• Regularnie sprawdzaj aktualizacje firmware routera i testuj kompatybilność modułów IoT po aktualizacji.

Selektywne stosowanie mechanizmów niezawodności (ACK, wyższy QoS) jest uzasadnione tam, gdzie faktycznie jest potrzebne. Większa liczba potwierdzeń i retransmisji zwiększa zużycie energii i czas spędzany w stanie połączenia. Dla urządzeń bateryjnych w NB-IoT lokalne buforowanie z opóźnioną retransmisją to często lepszy kompromis niż wysoki QoS przy każdym pakiecie.

Podsumowanie

Urządzenie IoT traci połączenie z wielu powodów naraz i na różnych warstwach stosu sieciowego. Dobry RSSI, rejestracja w sieci komórkowej ani aktywny interfejs sieciowy nie wykluczają awarii na poziomie TCP, TLS lub MQTT. Skuteczna diagnoza wymaga rozdzielenia warstwy radiowej, IP, sesji transportowej i aplikacyjnej, a następnie logowania ich stanów niezależnie. Kluczowe obszary to konfiguracja Keep Alive, obsługa wygasania NAT, poprawność zegara i certyfikatów TLS, tryby oszczędzania energii oraz jakość implementacji automatu stanów w firmware. Dobrze zaprojektowany mechanizm reconnect z wykładniczym backoffem i jasną polityką obsługi błędów to fundament stabilnego systemu IoT.

FAQ

Q: Czy urządzenie IoT może tracić połączenie z powodu zbyt wielu urządzeń w sieci Wi-Fi?

A: Tak. Każdy punkt dostępowy ma ograniczoną tabelę klientów. Po jej przepełnieniu nowe żądania asocjacji są odrzucane, a istniejące połączenia mogą być przerywane przez AP w celu zwolnienia zasobów.

Q: Czy zmiana kanału Wi-Fi może poprawić stabilność połączenia urządzenia IoT?

A: Tak, jeśli obecny kanał jest przeciążony lub koliduje z innymi sieciami. Kanały 1, 6 i 11 na 2,4 GHz nie nakładają się, dlatego wybór wolnego kanału może wyraźnie zmniejszyć liczbę retransmisji i rozłączeń.

Q: Co to jest sticky client i dlaczego powoduje problemy z połączeniem?

A: Sticky client to urządzenie, które utrzymuje połączenie ze słabym punktem dostępowym, mimo że silniejszy AP jest dostępny. Dzieje się tak, gdy moduł Wi-Fi nie obsługuje standardów 802.11r/k/v i nie wykonuje samodzielnie roamingu.

Q: Jak sprawdzić, czy przyczyną rozłączeń jest wygasający certyfikat TLS?

A: Porównaj czas rozłączenia z datą NotAfter certyfikatu klienta lub serwera, a także sprawdź czas lokalny urządzenia. Jeśli urządzenie nie ma synchronizacji NTP po restarcie, może odrzucać poprawne certyfikaty jako nieważne.

Q: Czy warto używać stałego adresu IP zamiast DHCP w urządzeniu IoT?

A: Statyczne IP eliminuje problemy z odnowieniem lease’u DHCP i cyklicznymi rozłączeniami wynikającymi ze zmiany bramy lub DNS. Jest to uzasadnione szczególnie przy urządzeniach wymagających stabilnego, długotrwałego połączenia.