Покрай вируса някак се захванах с ESP32 за нещо , което ми трябва.
Свалих Ардуино, питах Гугле как се почва,
краднах от Гитхъб , навързах 2 кита ESP32-PICO
https://store.comet.bg/Catalogue/Product/51155/ и я докарах донякъде
(В кода има някакви следи от блутут и ОТА, но не съм се
занимавал с тях).

Едната платка тръгва като AP и стартира 3 WiFi сърверa за трите физически кома.
Втората платка тръгва като STA и стартира 3 WiFi клиента към трите сървера на AP.
Не съм пробвал 3-те канала, само 2 - COM0 и COM1, предават и приемат на двете платки.

На второ четене нещата загрубяват, най-вече защото ми е мъгла в главата.
Когато рестартирам AP , клиентите се свързват отново - предполагам STA "зачиства" клиентите.
Когато изключа STA, сърверите в AP отказват да видят , че клиентите са отпаднали.
Когато рестартирам STA , Wifi-то се свързва към AP, клиентите не успяват да се свържат.

Когато по единия от терминалите, свързани към AP, опитам да предам нещо от клавиатурата -
опитът за предаване някак ресетва съответния сървер и след малко съответният клиент се закача.
През втория терминал се получава същото.

На практика излиза , че WiFiClient::connected() не може да ми покаже отпадане на
отпадане на връзката.
Моля за съвет и акъл.

Не съм гледал кода ти, но принципно можеш да ползваш събитията, генерирани от esp-то, например EVENT_SOFTAPMODE_STACONNECTED и EVENT_SOFTAPMODE_STADISCONNECTED.
Оттам нататък истината е keep-alive да правиш.

Edit: за справка може да погледнеш тук:
https://github.com/tonyp7/esp32-wifi-manager/blob/15cbd08bd28130e92893d881ef09d32f81acc3e0/src/wifi_manager.c

WiFiClient::read/write не ти ли връща грешка?
щото socket FD се "скапва"....

не го проверявам за грешка, но изглежда като се опитвам да пращам (в АП, Ком->сървер)
сърверът вижда грешката и се "самоАнулира". Вариант е по таймер да пускам някаква комбинация,
която да филтрирам и ползвам за хендшейкинг, но не ми харесва - надявам се да го има някак си
реализирано.
Опитах се да включа и лаптопа в тая мрежа...доста спорно..Wireshark показва някаква активност ..
но нищо смислено, поне за мене.

Нямам идея и пример как да търся състояние на сокета и съм забравил FD какво беше,
не виждам в хедърите "колбак" функционалност...

ами редно е да ги проверяваш както и errno ... щото затова е return error
по принцип WiFiClient е class имплементация на lwip socket за ESP32
тези грешки и информация за lwip ги има из целия интернет
пример:
http://api.tst-sistemas.es/apitsmart-1. ... ebdfa9c7fe

Returns
Number of bytes sent
-1 - Failure .... а номера на истинската грешка е в errno

ако активираш лога на WiFiClient ще ти принтва и дебъг текста
https://github.com/espressif/arduino-es ... t.cpp#L392
https://github.com/espressif/arduino-es ... t.cpp#L436

Разбирам какво казваш, не разбирам защо.
АP-Сърверът сам се ресетва , когато тръгна да натискам клавиши, а неговият клиент не е закачен след реконект на WiFi връзката откъм STA .
Моят въпрос е -при липса на серийни данни - как да следя за наличие/отпаддане на връзка, тоест да възстановя връзката -преди да са дошли данни за изпращане.

а и виж gicho ко рече
WiFiGeneric има event call-баци за диконект...

На ниво тцп има keep-alive (дето му викаш хендшейк-а). Само той може да се спаси от внезапно прецакана връзка - иначе правилното затваряне ще се индицира и ще е ясно за стека че тоя сокет (FD) не е ок.
Каква ти е генералната концепция за това нещо? Какво ще рече "wifi сървър" - това TCP сървър ли е, или нещо друго (http, ...)? Как събираш байтовете от уарт-а и кога ги пращаш - на време, на натрупан размер, при наличие на поне един?

Edit: погледнах кода, ползва ардуино-есп32. Ето пример как да ползваш евенти от вифи:
https://github.com/espressif/arduino-esp32/blob/master/libraries/WiFi/examples/WiFiClientEvents/WiFiClientEvents.ino

В ESP-IDF имаше примери за работа с уарта, които също са евент-базирани. Би трябвало да пасне на твоя дизайн.

edit: ей ги тук:
https://github.com/espressif/esp-idf/tree/master/examples/peripherals/uart

Благодаря,Гичо,


Намерих в библиотеките от Еспресиф нещо , за MQTT,базирано на Микрософт сокет библиотека - нещо съдържащо keep alive словосъчетанието.
Засега не гледам натам, искам нещо просто, примитивна замяна на сериен кабел, прозрачна,без АТ команди.
Тоя евент хандлер, от линка ти - не помага за случая, когато и двата адаптера са STA и са свързани през произволен АП.
Май без усложняване на сокетите не може да стане.

Засега май ще се ориентирам да поддържам сокета с периодични пакети.

=============
Най вероятно бъркам терминологията , но обектът WiFiserver е нещо като сокет сървер или
IPсървер, но не чак TCP сървер.

Мисля че с уартовете нямам проблем...поне логически.

P.S. В оригинала има три сървера ,по един на уарт.
Работят като разклонител/обединител - до 4 клиента пращат към един уарт, данните от този уарт
се препращат към до 4 клиента.

Ами приемаме, че транспарентният режим е безжичният еквивалент на серийния кабел. Обикновеният кабел няма такова следене на връзката... ...Всъщност там има RTS DTR CTS DSR RI , които ако са имплементирани в прозрачният режим, може да се използват за следене на връзката.

Не разбрах съвета

WiFiServer е TCP сокет сървър
WiFiClient е обратното ... TCP socket client

TCP в името не предполага ли, ако не "гарантираност" на връзката, то поне нотификация за
разпадане?
Или аз бъркам TCP или IP e по-горното в съчетанието TCP/IP.

RTS и DTR се сетват от теб, през UART програмата. Един вид освен символи да пращаш, може да им задаваш нива. От другата страна ( приемащата ) трябва да имат пинове които съответно се вдигат/слизат във ниско ниво. На първо виждане от това което изгуглих се вижда, че са имплементирани дори в ESP8266.

ESP32 pdf страница 6 :
3.2.7. AT+UART_CUR
.............................
............................
• <flow control>: flow control
‣ 0: flow control is not enabled
‣ 1: enable RTS
‣ 2: enable CTS
‣ 3: enable both RTS and CTS