WiFi station и тормоза

[bstsoft]

Привет всем. Написал универсальный интерфейс, вот готовое решение

Все бы хорошо, но столкнулся с одной проблемой. Прихожу к другу пытаемся подключиться к модулю ESP12F не работает Web интерфейс. Я еду домой, дома все работает. Еду снова к другу. С горем пополам заработало. Мои подозрения пали на то, что в настройках было подключение к домашней точке доступа. Через некоторое время я столкнулся с такой же проблемой.

Тормоза и глюки в работе Web проявляются:
1.если домашнюю точку доступа выключить.
2.в ESP12F будут включены настройки подключения к домашней точке доступа.
3.сама ESP12F работает как точка доступа для управления ей со смартфона.
Если интерфейс загрузится и получится отключить подключение к домашней точке доступа, то все потом работает как положено.

Пришлось даже сделать возможность сброса настроек на уровне железа.

Кто то с таким сталкивался? Есть ли решение проблемки? Если к примеру будут проблемы с роутером, то повисания и глюки ESP12F могут не дать зайти на модуль.

 

[pvvx]

При поиске AP (роутера) ESP8266 не реагирует практически ни на что другое (на свою AP). Управления поиском AP в SDK не предусмотрено. В старом SDK, используемым в Arduino IDE, реализация поиска и подключения к внешней AP сделана хуже, чем в последнем SDK именно по реакции на запросы к AP ESP во время её поиска-сканирования подключения к внешней AP. При включенном авто-реконекте процедура поиска-подключения к внешней AP выполняется непрерывно и доступа к SoftAP ESP нет. Чтобы отслеживать все состояния вам необходимо задействовать менеджер событий WiFi. Он вам будет отдавать состояния по событиям (отключение от внешней AP и причину, подключение/отключение клиента к SoftAP ESP и т.д.).

Т.е. вам требуется переписать алгоритм системы поиска-подключения ESP к внешней AP. У меня это было реализовано вставкой паузы между процедурами поиска внешней AP.

Процедура поиска для подключения внешней AP занимает около 2-х секунд, пока не выйдет с ответом – не найдено. В это время никакие другие соединения на ESP не возможны. Ставите вызов подключения к внешней AP, а по событию, что не найдена, делаете паузу в N секунд для обеспечения работы SoftAP на ESP, далее выбираете следующую по списку AP указанную для разрешенного подключения и так повторяете цикл. При этом, если к SoftAP ESP подключился клиент, то процедуру поиска и подключения к внешним AP останавливаете, а возобновляете только по указанию клиента или его отключению.

На Web-свалке это реализовано, кроме списка внешних AP для возможных подключений (желательно редактированием приоритетов подключения пользователем, если в эфире две внешних AP из списка допустимых, по уровню сигнала или просто по объявленному порядку). Примерно такое (типа на автомобиль с автоматическим подключением к разным роутерам на стоянках для слива статистики и контакта с другими для передачи маршрута) тоже уже делал, но на другом модуле (RTL) и там таких бед (глухоты на время поиска) меньше...

 

[bstsoft]

@pvvx
Решил протестировать отключая роутер. Ситуация не из приятных. Сделал реконект каждые 10 секунд, используя данные от WiFi.onEvent(wifi_event);
Получаем как минимум до 5 сек потерю пакетов WEB. Что сказывается на WEB интерфейсе. При плохой работе роутера глюки будут неприятные.

Частично проблему решил. Теперь интерфейс отрабатывает. Хоть и со второго раза. Интерфейс работает в потоках браузера и если хоть один поток заглючит жми обновить. Это тоже наверно вылечу, через браузер, но коду будет написано больше из за обработок ошибок.

Еще одним неприятным моментом после reconnect(), смартфон теряет связь с модулем и приходится на смартфоне делать реконнект WiFi.

 

[bstsoft]

@pvvx
Если использовать WiFi.scanNetworks(); то ситуация получше, тормозов меньше. Если точка найдена, то делаем коннект. Но тут еще один момент, у точки доступа может быть скрытый SSID и такой метод не поможет.

 

[pvvx]

@pvvx
Если использовать WiFi.scanNetworks(); то ситуация получше, тормозов меньше. Если точка найдена, то делаем коннект. Но тут еще один момент, у точки доступа может быть скрытый SSID и такой метод не поможет.

Это всё беды Arduino IDE. Пишите на SDK в СИ - там всё это решается очень просто.

 

[bstsoft]

Это всё беды Arduino IDE. Пишите на SDK в СИ - там всё это решается очень просто.

А разве user_interface.h это не SDK? Я начал вызывать напрямую wifi_station_connect и wifi_station_disconnect. Судя по логу который я сделал wifi_station_connect выполняется параллельно работе. То есть не прерывает работу, на прерываниях или в потоке. Видать наружу у них отклик сделан не фонтан. wifi_station_connect отрабатывает так, что режим точки доступа отваливается. Мне кажется они даже не тестировали такой ход событий. На практике основная точка доступа не будет так часто исчезать, как я это тестирую. Если реконнект сделать через 30 или 60 сек, то можно вообще забыть про эту проблему так как у обычных пользователей таких проблем не возникнет.

В тех местах где показания нужны по секундно там будут затыки. Но при условии что будет подключение к роутеру. Я так думаю, что возможно на внешних датчиках, с критерием быстроты, просто датчики делать как AP без STA.

 

[pvvx]

А разве user_interface.h это не SDK?

Я имел в виду использование wifi_set_event_handler_cb(wifi_handle_event_cb).
Пример: esp8266web/wifi_events.c at master · pvvx/esp8266web · GitHub
В Arduino это неудобно описывать - тогда надо переписывать много её либ...
Обрабатываете EVENT_STAMODE_DISCONNECTED и нет нужды в постоянном принудительном отключении. Ну а если решились обрабатывать события, то тогда надо обрабатывать их все...
В той, указанной реализации для Web-свалки, включается и полуспящий режим, если AP выключена на паузы между соединениями к внешней AP (ну если они заданы и разрешены спящие режимы)... Т.е. там условий более 5.
И как уже писал - в Arduino старая SDK, а в более новой поиск и подключение к внешней AP сделан немного по другому, как и окружающие её процедуры. Т.е. на старой версии SDK было больше всяких мелких недочетов именно в данном процессе...
Но смысла утруждаться с решением этого всего на ESP8266 нет, т.к. драйвер его WiFi всё равно имеет ошибки, которые вы не исправите и не подходит для серьезных поделок. Station там всё равно виснет, и даже програмный пересброс чипа не помогает. Восстановление работы Station, после приема каких-то внешних пакетов, возможно только через ногу RESET или питание. А SoftAP работает не по стандартам и мешается другим в эфире, да учитывая её глухоту в HT40 и прочих нормах современного WiFi - у неё дурная реализация всего WiFi - ESP8266 ужасно работают в группе - мешают всему WiFi. + В Arduino ещё беда с нарушениями времени арбитража WiFi (из-за отъема времени обработки WiFi не вовремя и как попало отдачи управления драйверу WiFi), приводящим к куче коллизий и сдвигам beacon, что увеличивает потребление у участников сети WiFi, находящихся в спящем режиме и с разными DTIM(N) (итог - если в сети ESP8266, смарт сядет быстрее).
Ну и т.к. требует непрерывного надзора оператора - из класса "Игрушка" ESP8266 и не вылез по данным причинам. По этому все реализации на ESP8266 ограничены на уровне: "как-то работает, да ладно".