Mechanizm komunikacji między nadajnikiem a odbiornikiem w sieci WiFi

Nie wiem, czy piszę we właściwym dziale, ale może ktoś tutaj spotkał się z tematem, który mnie interesuje. W wielu miejscach można się spotkać z panelami lub pilotami do sterowania czegoś, które wykorzystują WiFi jako sygnał komunikacyjny. Teraz często robi się nowoczesne panele sterujące, które są zbudowane w oparciu o HTML i JavaScript i ten wirtualny panel pozwala np. z poziomu tabletu sterować czymś, np. załączać światło, załączać silnik. Jednak taki panel musi się jakoś komunikować z modułem odbiorczym. Jeśli jest to WiFi, to panel (tablet) łączy się poprzez WiFi z siecią i wtedy wysyła odpowiednie instrukcje do modułu sterującego, ale pytanie, jak jest to realizowane, w oparciu o jaki mechanizm, aby taka komunikacja była możliwa.

Często wykorzystuje się następujące protokoły: standardowy HTTP, WebSocket, MQTT, UDP, ale każdy ma swoje wady i zalety. WebSocket jest dobry, bo umożliwia komunikację w czasie rzeczywistym, nadajnik może otrzymywać np. dane z czujników z odbiornika, a odbiornik może być sterowany nadajnikiem. Jednak, kiedy testowałem to rozwiązanie, to zauważyłem, że występują tu timeouty, krótko mówiąc połączenie WebSocket jest zrywane i komunikacja staje się utrudniona.

Jak więc stworzyć, w oparciu o jaki mechanizm, taką komunikację, że np. połączony tablet poprzez sieć WiFi z jakimś modułem będzie utrzymywał stabilne połączenie i będzie możliwe sterowanie danym urządzeniem?

Ja to testowałem w oparciu o ESP32 i panel zbudowany w HTML-u i uruchomiony na tablecie, ale nie wiem, czy ESP32 to słabe moduły i do profesjonalnego rozwiązania się nie nadają, bo jak wspomniałem, miałem problem z utrzymywaniem stabilnego połączenia, ale testując WebSocket, odniosłem wrażenie, że to ten mechanizm jest delikatny i to on zrywa połączenia, bo już na HTTP było lepiej, ale też zdarzyły mi się zerwane połączenia.

Pytanie więc, jak zbudować pilot, aby połączony np. z takim ESP32 komunikował się bez problemu i aby nie było tego zrywania połączeń?

Problemem może być tablet. Android bardzo chętnie ogranicza łączność programów celem oszczędzania energii a czasem i przesyłu danych.
Http będzie w miarę działać, zakładając że robisz łączność w jedną stronę, jak potrzebujesz odczytywać stan sterownika, to przez odświeżenie strony.
Websocket wymaga otwartego połączenia i robi pooling w tle za ciebie, ale co byś nie projektował, musisz się liczyć że połączenie z jakiegoś powodu się zamknie / stracisz pakiety.
Jeśli robisz to dla sieci lokalnych, możesz rozważyć wysyłanie danych na adres tabletu i napisać sobie apkę, która je odbierze i jakoś wyświetli (no i oczywiście która też coś będzie potrafiła wysłać do sterownika).
Pytanie na czym miałeś serwer websocketa i w którą stronę była inicjalizowana łączność. Ja kiedyś robiłem sobie łączność z łódką rc przez websocket, androida i serwer pośredniczący (o czym też pomyśl), ale nie testowałem tego w długich przedziałach czasu.

Ogólnie android nie lubi mieć aplikacji która cały czas coś aktywnie robi, on je lubi wyświetlać i pilnować żeby nie robiły Nastaw się na łączność na zasadzie zdarzeń - coś się zdarzyło, nawiązujesz połączenie, wysyłasz powiadomienie, zamykasz połączenie. Możesz do tego dodać jakiś cykliczny pooling na wszelki wypadek, byle nie za często.

Wspomniałem tablet, ale panel sterujący może być uruchomiony na dowolnej przeglądarce, bo to kod HTML, więc uruchamiałem to na laptopie, na tablecie, ale z systemem Windows 10.

Przy WebSocket jest taki problem (czytałem o tym na necie, inni też mieli podobne problemy Timeout), że pomimo że mam połączenie i wysyłam jakby PING, np. jak wcisnę przycisk i trzymam go ponad minutę, np. Emergency Stop, to zrywane jest połączenie, tylko nie do końca wiem, czy WiFi, czy to połączenie WebSocket.

Jest coś takiego jak Bobcat, firma, która ma maszyny budowlane i oni oferują np. sterowanie do tych maszyn w oparciu o WiFi — odpalasz telefon, masz aplikację i sterujesz maszyną. Pytanie, jak oni to zrobili, aby ta komunikacja była niezawodna.

Wyobraź sobie, że projektujesz pilot do sterowania wyciągarką i wszystko jest OK, sterujesz załączaniem silnika, przesuwaniem, ale zrywa się połączenie, a Ty musisz wcisnąć przycisk Emergency Stop. Jak wtedy zatrzymać system, jak łączność padła?

Generalnie zauważyłem, że w tym WebSocket jest tak, że jak nawiążę połączenie panel -> ESP32 poprzez WiFi, to ono jakby jest — widzę na tablecie, w komputerze ikona systemowa informuje, że jest połączenie sieć WiFi. Problem zaczyna się, kiedy wciskam przycisk i go trzymam ponad minutę. Zrywa połączenie. Normalnie niby sieć działałaby i godzinę, ale kiedy wcisnę przycisk, potrafi to połączenie się rozsypać po minucie.

Moim pomysłem jest stworzenie systemu, który pozwala komunikować się z (nadajnik pilot) odbiornik i tylko w sumie jedno urządzenie ma pracować w tej sieci, czyli pilot.

„Pytanie na czym miałeś serwer WebSocketa i w którą stronę była inicjalizowana łączność. Ja kiedyś robiłem sobie łączność z łódką RC przez WebSocket, Androida i serwer pośredniczący (o czym też pomyśl), ale nie testowałem tego w długich przedziałach czasu.”

Trochę nie rozumiem pytania, na czym miałem WebSocket.
Mam kod na ESP32, który ma zaimplementowaną bibliotekę do WebSocket, a panel HTML odpalany w przeglądarce to zwykły kod HTML i JavaScript, z tym że do obsługi z WebSocket. Po prostu to mechanizm z odpowiednią biblioteką do komunikacji.

Przeszedłem nawet na inną bibliotekę WebSocket, ale to nie rozwiązało problemu. Jest jakaś dobra biblioteka do WebSocket Mongoose, ale nie mogłem za bardzo tego odpalić, aby to przetestować — niby wgrałem bibliotekę do szkicu (pliki odpowiednie, jak jest w instrukcji), ale przy zapisywaniu programu na ESP32 wywalało błędy.

Teraz w sumie nie jest problemem Android, bo jak coś, mogę to odpalać na tablecie z Windowsem, ale problemem jest stworzenie połączenia, które będzie cały czas stabilne. Przy WebSocket szybko się to sypie, HTTP lepiej, ale też zdarzyło się, że w testach coś padło, także szukam rozwiązania, które raz spięte pozwala katować ESP32 i nic się nie rozsypie. Może to wina ESP32, może przy dłuższym działaniu ono się wysypuje. Nie wiem, resetować, zawieszać mi się nie zawieszało, tylko to połączenie nawala, co powoduje, że sterowanie jest niestabilne.

Do suwnic itp normalnie stosuje się specjalne piloty, nie oparte o wi-fi. "Odbiornik" monitoruje łączność z pilotem i jak mu coś nie pasi otwiera styki od E-Stop. W gestii projektanta jest je tak podłączyć, żeby zatrzymać maszynę.
Nie można polegać na łączności bezprzewodowej w kwestii bezpieczeństwa z założenia (zakłócenia, rozładowana bateria na dobry początek).

Czyli serwer http i websocket (to osobna usługa, działająca na innym porcie) masz na ESP32.
Piszesz że trzymasz guzik długo i się wtedy wywala. A jak masz zrobioną jego obsługę? Normalnie jest 'onclick' i to działa tylko przy wciśnięciu. Jedyne co mi przychodzi do głowy, to potem ciągle sprawdzać czy nadal jest wciśnięty, co jest marnym rozwiązaniem.
Ewentualnie zdarzenie wciśnięty, zdarzenie puszczony.
Chyba że robisz coś na zasadzie pilota RC / działającego w czasie rzeczywistym, to wtedy musisz pakiety wysyłać bez przerwy, ale to mi się przeglądarka do tego nie widzi.

Co do sprawdzenia czy pada wifi czy websocket, poszukaj logów z esp, wydaje mi się że wiele bibliotek wysyła informacje po serialu, po stronie przeglądarki - konsola no i też tak napisać obsługę ws w js żeby zgłaszało błędy.

Ja miałem problem z ESP32 żeby go w ogóle podłączyć do istniejącej sieci, mówimy o gołym przykładzie z Arduino IDE. Niby inny przykład pokazywał że sieć w powietrzu jest, ale próba połączenia nie robiła. Za to ustawiony w tryb AP działa i da się połączyć do niego z telefonu.

Rozważ czy nie postawić serwera pośredniczącego i łączyć się do niego jako klient z esp i jako klient z "tableta".

No i jeszcze możesz zapuścić zwykły ping i popatrzeć ile wytrzyma. To właściwie robi to co chcesz - wysyła cyklicznie pakiet danych do serwera i patrzy co wraca. Jeśli na pingu będzie długo działać a przez przeglądarkę nie - to masz podpowiedź gdzie szukać.
Na windowsie ping -t żeby chodził w nieskończoność. (tyle że windows lubi sobie potem nie poradzić z wyświetlaniem efektów lub nie reaguje na ctrl+c zbyt żwawo )

ademba napisał:

Problem zaczyna się, kiedy wciskam przycisk i go trzymam ponad minutę. Zrywa połączenie. Normalnie niby sieć działałaby i godzinę, ale kiedy wcisnę przycisk potrafi to połączenie się rozsypać po minucie.

Sprawdź co się dzieje gdy naciskasz przycisk. Być może tak napisałeś program, że jest wykonywana jakaś pętla całkowicie absorbująca procesor i nie są obsługiwane połączenia sieciowe.

Do suwnic itp normalnie stosuje się specjalne piloty, nie oparte o wi-fi.

Są różne rozwiązania. Bobcat firma produkująca maszyny budowlane umożliwia sterowanie telefonem z wykorzystaniem WiFi. Widziałem też inne piloty innych firm i tam oprócz standardowych 433MHz wykorzystują też częstotliwości 2.4MHz i rozwiązania oparte na WiFi. Każde rozwiązanie ma swoje plusy i minusy. Zrobiłem jedno sterowanie oparte na 433MHz, ale tutaj muszę mieć odbiornik i pilot. Czyli muszę wykonać dwa urządzenia fizyczne. Da się zrobić panel na tablet bez potrzeby używania fizycznego pilota, ale wtedy trzeba podczepić nadajnik więc do tabletu trzeba wpiąć moduł nadawczy, aby komunikacja była możliwa z odbiornikiem poprzez tablet komputer.

Wziąłem się za ESP32, bo trochę mi upraszać to robotę. Mogę wykonać tylko odbiornik, a pilota zrobić na tablecie, komputerze. Tutaj nie ogranicza mnie miejsce przycisk może być w każdym miejscu, bo nie ma kabli, nie ma ograniczeń fizycznych pod spodem jest tylko kod. Łatwiej więc taki pilot rozbudowywać. Problemem jest jednak łączność. Wziąłem więc na testy mechanizm http i WebSocket. Użyłem konsoli, aby przez konsolę wysłać komendy i sprawdzać co się stanie.

Mój system działa tak, że są przyciski bistabilne EMERGENCY STOP jak i monostabilne. Wciśnięcie przycisku monostabilnego wysyła komendę np. 10 (załącz diodę led nr 1) puszczenie wysyła komendę 00 (wyłącz diodę Led). Jeśli przycisk zostanie wciśnięty to wysyła co sekundę komendę powtarza ją. Wtedy odbiornik wie, że przycisk jest cały czas w użyciu. Jeśli zginęłaby łączność, pilot wypadłby z rąk coś by się stało to, jeśli odbiornik nie otrzyma komendy przez 2 sekundy to wyłącza wszystkie uruchomione rzeczy (w tym przypadku diody Led). Po co to jest np. rozpalasz silnik, ale odbiornik otrzymałby komendę ROZPAL, ale nie otrzymałby komendy przycisk zwolniony to rozrusznik cały czas by pracował. Jeśli coś się stanie a odbiornik nie otrzyma komendy to wtedy rozłączy ten rozrusznik.

Czyli serwer http i websocket (to osobna usługa, działająca na innym porcie) masz na ESP32.

http i WebSocket to po prostu mechanizm komunikacji. WebSocket jest dobry, bo pozwala komunikować się w czasie rzeczywistym coś wysyła coś odbiera i nie zauważysz opóźnień. Chociaż w testach http też nie zauważyłem opóźnień. Na ESP32 mam program, który wykonuje zadania zapala diody tworzy ACCESS POINT WiFi oraz ma wbudowany mechanizm komunikacji albo http albo Websocket. Panel, czyli stronę, bo robię to przez HTML i JavaScrip mogę wrzucić na ESP32 i ładować lub uruchamiać na tablecie komputerze.

Wczoraj więc zrobiłem testy http i WebSocket. Generalnie włączyłem przycisk Emergency Stop i na http działało to chyba z 16 minut aż sam wyłączyłem idąc się myć. Na WebSocket zrobiłem to samo i działało też z około 8 minut, bo wyłączyłem. Potem wziąłem odłączyłem panel HTML (zamknąłem przeglądarkę) zrobiłem testy komunikacji poprzez konsolę CMD wysyłając komendę cyklicznie poprzez pętlę. Działało też z kilka minut aż sam rozłączyłem.

Doszedłem do wniosku, że tu chyba WiFi na tym ESP32 nawala.

Zrobiłem prosty skrypt PowerShell, który bada sieć jej SSID sprawdza czy widoczna jest badana sieć.

Badałem swoją siec WiFi na której pracuję i kiedy ją odłączyłem miałem w logach brak sieci. Zrobiłem to samo dla sieci WiFi z ESP32 i zauważyłem, że tam często ta sieć znika. Wniosek jest taki, że to na ESP32 coś się dzieje z siecią. Może to jakaś podróbka chin albo w ogóle jakiś moduł na tym ESP32 słabej jakości i on tworzy problemy z WiFi.



Dla potomnych zostawię skrypty do badania sieci. Skrypt PowerShell w którym tylko trzeba wprowadzić nazwę swojej sieci. Skrypt zapisuje logi do pliku txt. Dodatkowo kod HTML, który komunikuje się z PowerShell, aby pobierać dane o sieci i prezentować je w czytelny sposób na stronie. W skrypcie HTML trzeba tylko wprowadzić IP naszego komputera.

Skrypt uruchamiamy w konsoli PowerShell (wywołując go do uruchomienia). Skrypt nie łączy się z urządzeniem sprawdza tylko czy sieć istnieje w przestrzeni co pozwala zbadać, czy sieć znika czy działa cały czas. Proste narzędzie mi pomogło trochę na ukierunkowaniu mnie, gdzie jest tak naprawdę problem. W moim przypadku to raczej nie WebSocket tylko niestabilne działanie sieci WiFi z ESP32 i to tutaj najprawdopodobniej jest problem.

Skrypty.
Badanie_Si...i_WiFi.rar (253.51 kB)Musisz być zalogowany, aby pobrać ten załącznik.

Piszesz że trzymasz guzik długo i się wtedy wywala. A jak masz zrobioną jego obsługę? Normalnie jest 'onclick' i to działa tylko przy wciśnięciu. Jedyne co mi przychodzi do głowy, to potem ciągle sprawdzać czy nadal jest wciśnięty, co jest marnym rozwiązaniem.

Każdy przycisk ma przypisany nasłuchiwacz zdarzeń (event listener) w JavaScript, reagujący na akcje użytkownika, takie jak kliknięcie (click), najechanie myszą (mouseover) lub naciśnięcie klawisza.
Ponieważ jest to system zdalnego sterowania przyciski wysyłają komendy do urządzenia (np. poprzez protokół WebSocket, HTTP API lub inny mechanizm komunikacyjny w zależności jaki mechanizm wybierzesz sobie.
Typowe zdarzenie, że klikasz włącz, klikasz wyłącz nie sprawdzi się. Można zastosować rozwiązanie włącz led 1 ale wyobraź sobie, że tym przyciskiem uruchamiasz silnik rozrusznik. W aucie, kiedy go zwolnisz to na rozrusznik nie jest podawane zasilanie więc przestaje działać. W przypadku pilota, jeśli coś się stanie zwalniasz przycisk, ale komenda nie dociera to ten rozrusznik działałby cały czas co doprowadziłoby do tego, że w końcu byś go spalił. Dlatego jest ten mechanizm PING u mnie, że kiedy załączysz przyciskiem coś, ale kiedy go zwolnisz a komenda wyłącz przepadłaby w przestrzeni a nadajnik nie wysyła już sygnału to odbiornik wie, że nowe komendy nie docierają, ale uruchomione zdarzenie wcześniej musi być wyłączone, bo nie ma cyklicznych komend, że dany przycisk działa więc to oznacza, że coś się stało i trzeba to wyłączyć.


Także wniosek taki z moich obserwacji, że problemem jest sieć na ESP32 którą on tworzy, a która jest niestabilna, ale czemu tego nie potrafię powiedzieć. Przykład w logach na zrzutach które załączyłem z badania sieci. Moja domowa sieć. Działa, na czerwono zaznaczyłem moment, kiedy ją rozłączyłem ręcznie wtedy znikła z przestrzeni i skrypt to wykrył, kiedy podłączyłem sieć pojawiła się w logach.
To samo z siecią z ESP32. Esp32 tylko uruchomione z wgranym prostym programem tworzy sieć WiFi Access Point i tylko sprawdzałem, czy jest w przestrzeni. Jak widać działa z przerwami więc to ona robi te problemy. Przetestowałem też inny ESP32, ale to samo.
Chyba muszę kupić jakieś inne moduły od zaufanych źródeł i sprawdzić jak na nich zachowuje się sieć, bo teraz jedyne co mi przychodzi do wniosku to, że to wina ESP32.

ademba napisał:

Chyba muszę kupić jakieś inne moduły od zaufanych źródeł i sprawdzić jak na nich zachowuje się sieć, bo teraz jedyne co mi przychodzi do wniosku to, że to wina ESP32.

Znacznie bardziej prawdopodobne jest to, że popełniłeś jakiś błąd programowy lub sprzętowy w ESP niż to, że kupiłeś podróbki.
Używając aplikacji przeglądarkowej z ESP32 można połączyć się również przez BLE.

@ademba mam jedno esp32 w domu, jak zrobisz jakiś prosty skrypt do testów, to mogę Ci to odpalić na jakiś czas i zdać relacje jak efekty. Wołałbym pod Linuxa, bo tego głównie używam i i tak chodzi serwer 24/7 w domu.
Windowsa też mam, ale odpalam do grania.
Przy czym jak pisałem wcześniej, to esp nie chce się łączyć z moją siecią i nie wiem dlaczego

Jak przyjąłeś własny timeout i stop na okoliczność braku pakietów to dobrze.
Pisałeś że próbowałeś UDP, co z nimi nie tak?

„Pisałeś, że próbowałeś UDP, co z nimi nie tak?”
UDP nie testowałem. W tym całym zestawieniu WebSocket wydaje się najlepszy i najprostszy. Nie potrzebujesz żadnego pośrednika jak w MQTT, komunikacja odbywa się na zasadzie: rozmawiamy ze sobą na żywo i komunikujemy bez problemu.
Krótko mówiąc, UDP – JavaScript w przeglądarce nie ma dostępu do UDP, należałoby tworzyć nową aplikację lub jakiegoś pośrednika zastosować do komunikacji.
Im więcej takich kombinacji, tym większe prawdopodobieństwo, że coś się rozsypie.
Także WebSocket chyba będzie dobrym rozwiązaniem. Kwestia zgrać to tak, aby raz podłączony tablet poprzez to WiFi, bo innej opcji nie ma, był połączony z tym ESP32, aby użytkownik, który używa tego pilota, nie frustrował się, że działa to w kratkę.
Jeśli to będzie działać, to potem można pomyśleć o stworzeniu innej aplikacji, np. na Android czy na Windows, ale sam kod HTML też można upakować w aplikację, aby stworzyć panel i możesz mieć już z gotowej działającej aplikacji teraz aplikację, jaką chcesz, czy na Android, czy na Windows.
Dzięki za propozycję pomocy, ale jestem coraz bliżej odpowiedzi, dlaczego tak się działo. Jeszcze muszę wszystko potestować, aby to dokładnie potwierdzić. Czasami trzeba metodą prób i błędów działać, a to wszystko zajmuje czasu, a czas nie jest z gumy i dokupić się go nie da.